2.1基礎
SQSコンシューマーが特定メッセージの処理に何度も失敗する。
後続メッセージを止めず、失敗原因を調査してから再処理したい。
最も適切な構成はどれか。
× 不正解
DLQへ失敗メッセージを隔離し、メインキューの処理と原因調査を分離する。
詳細解説
誤り失敗したメッセージを無制限に同じキューへ戻し続ける
後続処理を圧迫し、失敗メッセージが処理を繰り返す。
後続処理を圧迫し、失敗メッセージが処理を繰り返す。
正しいSQSのデッドレターキューと最大受信回数を設定する
一定回数失敗したメッセージを隔離し、原因調査と個別再処理を行える。
一定回数失敗したメッセージを隔離し、原因調査と個別再処理を行える。
誤りRoute 53のヘルスチェックでメッセージを削除する
DNSヘルスチェックはキューのメッセージ処理を制御しない。
DNSヘルスチェックはキューのメッセージ処理を制御しない。
誤り失敗したメッセージを常に破棄する
原因調査や再処理のためのデータを失う。
原因調査や再処理のためのデータを失う。
実際に確かめる
一時的な検証環境で実行できる例です。
Amazon SQS dead-letter queueの公式説明を確認する。期待される結果
最大受信回数とDLQによる失敗隔離を説明できる。理解のポイント
- SQS
- デッドレターキュー
- 最大受信回数
確認時の注意
- 確認環境: AWS公式SQSドキュメントの確認
- AWS公式SAA-C03 Domain 2と各サービスの公式ドキュメントを確認する。
基礎のおさらい
判断のポイント
障害ドメイン、データの復旧点、処理の重複、切り替え時間を分けて評価する。
設計の確認
正常系だけでなく、キュー滞留・AZ障害・リージョン障害・依存サービス停止時の動作を確認する。
問題IDAWS-SAA-131
確認環境AWS公式SQSドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告