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 関数へ配信できる新しい仕組みである。失敗イベントには元のペイロード・エラーメッセージ・スタックトレースが含まれるため、後続の調査・再処理パイプラインを組みやすい。 代替として、Lambda 関数本体に try/catch を入れて自分で SNS に通知する実装もあるが、再試行制御や非同期呼び出しの内部リトライまでカバーするのは難しく、配信保証も自前で担保することになる。マネージドな DLQ / Destinations を使えば、Lambda サービス側が再試行・配信・順序を担保してくれる。EventBridge を Destinations に指定すると、失敗イベントをルールでフィルタして、別の Lambda や Step Functions に流すパイプラインを宣言的に組める。 SAA-C03 では、「非同期 Lambda の失敗イベントを保持」「後で調査・再処理したい」「イベントを失わない」というキーワードが含まれる場合、DLQ / Destinations が正答となる。誤答として「CloudWatch Logs だけで十分」「X-Ray でトレースすれば失敗を再現できる」「同期呼び出しに切り替える」など、ログ機能や呼び出しモデル変更に逃げる選択肢が混入する。ログ・トレースは事後の観測であり、失敗イベント自体を保持する仕組みではない点を区別する必要がある。