エラーハンドリング（DLQとDestinationsの比較）難易度 標準無料
非同期起動されるLambda関数について、失敗したイベントだけでなく、成功時にも呼び出し結果（レスポンスペイロードや実行コンテキスト）を後続処理へ連携したい。追加のLambda関数を挟まずにこれを実現する設計として最も適切なものを選べ。（単一選択）
- A関数の非同期呼び出し設定でon-success destinationとon-failure destinationの両方を設定し、それぞれSQS/SNS/EventBridge/別のLambda関数へ、レスポンスペイロードを含む実行コンテキストごと送信する
- BDLQ（SQSキュー）を設定する。DLQは失敗イベントだけでなく成功時のレスポンスペイロードも自動的に保存してくれる
- C関数の最後に別のLambda関数を明示的に呼び出すコードを追加し、その中で成功/失敗の分岐処理を実装する
- D関数をすべて同期呼び出しに変更し、呼び出し元が成功/失敗のレスポンスを直接受け取れるようにする
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
従来のデッドレターキュー（DLQ、SQS/SNSのみ対応）は、失敗したイベントの元のペイロードのみを保存する仕組みであり、 成功時の情報連携や、呼び出し結果・エラー詳細などの実行コンテキストの付加情報は持たない。
- これに対しLambda Destinationsは、非同期呼び出しの「成功時（on-success）」「失敗時（on-failure）」の両方について、 SQS・SNS・EventBridge・別のLambda関数のいずれかへ結果を送信できる。
- Destinationsが送る情報には、元のイベント・呼び出しのレスポンスペイロード・タイムスタンプ・呼び出し回数などの実行コンテキストが含まれ、 DLQより豊富な情報を後続の処理（監査ログ、通知、リカバリ処理等）で活用できる。
- DLQとDestinationsは併用も可能だが、新規実装ではDestinationsの利用が推奨されている。
- BDLQは失敗したイベントの元ペイロードのみを保存する仕組みであり、成功時の情報連携やレスポンスペイロードの保存はサポートしない。
- C実装可能ではあるが「追加のLambda関数を挟まずに実現する」という要件に反し、Destinationsというマネージド機能を使わず車輪の再発明になる。
- D呼び出し方式（同期/非同期）自体の変更はトリガー元の設計に影響し、要件（非同期のまま結果連携）を満たす直接的な解決にならない。
ひっかけ： 「DLQを設定すれば成功時の情報も保存される（B）」は誤り。DLQは失敗したイベントの元ペイロードのみを保存する仕組みであり、
成功時の連携やリッチな実行コンテキストが必要な場合はDestinationsを使う、という使い分けが問われている。
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）