エラーハンドリング（同期呼び出しの再試行責任）難易度 標準無料
API Gatewayのプロキシ統合経由で同期呼び出しされるLambda関数が、下流のデータベースへの一時的な接続エラーにより例外をスローした。この場合の再試行に関する正しい理解を選べ。（単一選択）
- ALambda自体は同期呼び出しの失敗を自動的に再試行しない。エラーは即座に呼び出し元へ返され、再試行の実装は呼び出し元（クライアントやAPI Gateway側）の責任である
- B同期呼び出しであっても非同期呼び出しと同様に、Lambdaが内部で自動的に最大2回まで再試行してから呼び出し元へ結果を返す
- C同期呼び出しのエラーは自動的にDLQへ送信され、DLQに設定したLambda関数が再試行のトリガーとなる
- D同期呼び出しのエラーはKinesisのストリームベース呼び出しと同様に、成功するかレコードの経過時間上限に達するまで自動的に再試行され続ける
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・AIで再検証済
解説
同期呼び出し（API Gateway、ALB、SDKのInvoke（InvocationType=RequestResponse）等）では、
Lambda自体は失敗した呼び出しを自動的に再試行しない。エラーは即座に呼び出し元へ返される。
- 再試行が必要な場合は、呼び出し元（クライアントアプリケーション、SDKのリトライ設定、API Gateway側の設計）が責任を持って実装する必要がある。
- これは非同期呼び出し（既定で最大2回の自動再試行）やストリームベースのポーリング呼び出し（Kinesis/DynamoDB Streams、 エラー時にバッチ全体を再試行し続ける）とは明確に異なる挙動である。
- 設計上は、下流の一時的なエラーに備えて呼び出し元側で指数バックオフ付きの再試行やサーキットブレーカーを実装するのが定石。
- B自動再試行は非同期呼び出しの挙動。同期呼び出しではLambdaは再試行せず、エラーを即座に呼び出し元へ返す。
- CDLQは非同期呼び出しの失敗イベントを保存する仕組みであり、同期呼び出しには適用されない。
- Dそれはポーリングベース（ストリーム）呼び出しの挙動。同期呼び出しにはそのような自動リトライループは存在しない。
ひっかけ： 「非同期呼び出しと同様にLambdaが自動で2回再試行する（B）」は誤り。再試行の自動化は呼び出しタイプによって異なるのが本問の核心。
同期呼び出しでは再試行の責任は呼び出し元側にある。
公式ドキュメント・関連AWS Lambda Developer Guide ― Synchronous invocation↗AWS Lambda Developer Guide ― Error handling and automatic retries in AWS Lambda↗
AIが作成し、別の手順のAIで誤りを点検した解説です（有資格者による監修は経ていません）