這些題目為學習目的而獨立製作，並非 AWS 官方考題、實際考題、外流題或考題庫。
SAA-014
希望讓 Lambda 函式處理失敗的事件能於日後調查與重新處理。對於非同步呼叫的失敗事件,以下哪個保存組態最為合適?
選項
解析與正確答案
閱讀解析與正確答案（劇透：建議先自行作答）
正確答案：A. 設定 Dead-letter queue 或 Lambda Destinations
解析
非同步 Lambda 的失敗事件可透過 DLQ 或 Lambda Destinations 傳送至 SQS / SNS / EventBridge 等,便於後續調查與重新處理。
各選項解析
A. 設定 Dead-letter queue 或 Lambda Destinations
正解。可作為失敗事件的隔離保存目的地。
B. 將 CloudFront 的快取 TTL 設為 0
CloudFront 的 TTL 與 Lambda 失敗事件保存無關。
C. 務必將 Lambda 的記憶體設為最大值
增加記憶體有助於效能改善,但與保存失敗事件無關。
D. 將 Lambda 部署於公用子網路
屬於網路組態的議題,與保存失敗事件無關。
實際使用情境
Lambda 的非同步呼叫(Event 型 invoke)中,經過指定次數重試仍失敗的事件,可透過 Dead Letter Queue(DLQ)或 Lambda Destinations 隔離至外部。DLQ 為傳統機制,將 SQS 佇列或 SNS 主題指定為失敗事件的目的地;Lambda Destinations 則是其擴充,可將成功與失敗各自的結果分別送至 SQS / SNS / EventBridge / 其他 Lambda 函式。失敗事件包含原始 payload、錯誤訊息與堆疊追蹤,便於組建後續的調查與重新處理管線。 替代方案是在 Lambda 函式本體中加入 try/catch,自行通知 SNS。但要涵蓋重試控制與非同步呼叫的內部重試本身較為困難,且傳遞保證也需自行確保。改用受管的 DLQ / Destinations,Lambda 服務端會代為擔保重試、傳遞與順序。若於 Destinations 指定 EventBridge,即可宣告式地組建「以規則過濾失敗事件,再流向其他 Lambda 或 Step Functions」的管線。 SAA-C03 中,題幹若出現「保留非同步 Lambda 的失敗事件」「希望日後調查與重新處理」「不遺失事件」等用語,DLQ / Destinations 即為正答。誤答常以「僅靠 CloudWatch Logs 即足」「以 X-Ray 追蹤即可重現失敗」「改用同步呼叫」等選項出現,將焦點轉至日誌功能或呼叫模型變更。日誌與追蹤屬於事後觀測,並非保留失敗事件本身的機制,此處需加以區分。