正解：C
Amazon EFS（Elastic File System）は、複数のEC2インスタンスから共有アクセスできるフルマネージドのネットワークファイルシステムです。この問題の根本原因と解決策：
- 問題の原因：各EC2インスタンスが独自のEBSボリュームに別々のドキュメントを保存しているため、ALBでどちらに振り分けられるかで表示内容が変わる
- EFSの強み：
- 複数のAZ、複数のEC2インスタンスから同時にマウント可能
- NFSv4プロトコルで共有ファイルシステム
- 自動的にマルチAZ冗長化
- 容量は自動拡張
他の選択肢について：
A. 手動コピーは同期されず、常に不整合が生じます。
B. ALBはレイヤー7ルーティングでもドキュメントの場所を判断できません。
D. 両方のサーバーへの同時送信は非効率で、どちらのレスポンスを返すかの判断も困難です。
正解：D
Amazon SNS + SQSのファンアウトパターンは、疎結合・高スケーラビリティ・メッセージの複数コンシューマーへの配信に最適な設計パターンです。この問題の最適解である理由：
- ファンアウトパターン：1つのSNSトピックから複数のSQSキューに配信（各コンシューマー用）
- 疎結合：パブリッシャーとコンシューマーが直接通信しない
- スケーラビリティ：SNS/SQSは1秒あたり数百万メッセージを処理可能
- 各コンシューマーが独立したペースで処理可能
- マネージドサービス：スケーリング・可用性を自動管理
他の選択肢について：
A. Kinesis Data Analyticsはストリーム分析用で、疎結合メッセージングの主目的ではありません。
B. EC2のCPUベースAuto Scalingは急増するメッセージ対応が遅く、疎結合でもありません。
C. 単一シャードのKinesisではスループット（1,000レコード/秒/シャード）が不足します。
正解：B
SQSキュー + キューサイズベースのAuto Scalingは、疎結合・レジリエント・スケーラブルな分散処理の標準パターンです。この設計の優位性：
- 疎結合：プライマリサーバー（パブリッシャー）とコンピュートノード（コンシューマー）がSQS経由で通信、直接依存なし
- レジリエンス：ノード障害時もメッセージがSQSに残り、他ノードが処理
- キューサイズベースのスケーリング：
- バックログ増加時に自動的にコンピュートノード追加
- 負荷減少時に自動的にスケールイン
- ワークロード変動に正確に追従 - 可視性タイムアウトで重複処理を防止
他の選択肢について：
A. スケジュールスケーリングは変動ワークロードに対応できません。
C. CloudTrailは監査ログ用で、ジョブキューではありません。プライマリサーバーもSPOFです。
D. EventBridgeはイベントルーティング用で、ジョブキューとしての用途には最適ではありません。
正解：B
Amazon SQS FIFO（First-In-First-Out）キューは、メッセージの順序保証と重複排除を提供する専用のキューです。この問題の最適解である理由：
- 厳密な順序保証：FIFOキューでは受信順序でメッセージが処理される
- Exactly-Once処理：重複メッセージを自動的に排除
- スループット：最大3,000メッセージ/秒（バッチ処理時）
- API Gateway連携：API Gatewayから直接FIFOキューにメッセージ送信可能
- Lambdaトリガー：FIFOキューからLambdaを順序通りに起動
他の選択肢について：
A. SNSトピックは順序保証しません（SNS FIFOトピックもありますが、通常のSNSは順不同）。
C. オーソライザーはアクセス制御用で、順序管理のツールではありません。
D. SQS標準キューはベストエフォート順序で、厳密な順序保証はありません。
（2つ選択）
正解：A, B
S3 → SQS → Lambdaパターンは、耐久性があり、ステートレスな画像処理の標準的なサーバーレスアーキテクチャです。
A. S3イベント通知でSQSキューに送信：S3オブジェクトの作成を検出してSQSキューにメッセージを送信。メッセージは耐久性があり、最大14日間保持可能。
B. Lambda関数をSQSトリガーで起動：Lambdaがキューをポーリングし、メッセージを処理後に自動的に削除。再試行メカニズムも内蔵。
この設計の利点：
- ステートレス：Lambdaはステートを持たず、各呼び出しは独立
- 耐久性：SQSでメッセージが保持されるため、Lambdaが失敗しても再処理可能
- 自動スケール：Lambdaが同時実行数を自動調整
- デッドレターキュー（DLQ）対応で失敗メッセージを処理可能
他の選択肢について：
C. Lambdaメモリ内のテキストファイルはステートフルで問題です。
D. EC2は管理が必要でステートレスではありません。
E. メール通知は画像処理の自動化に直接的ではありません。
正解：D
Gateway Load Balancer（GWLB）は、サードパーティの仮想ファイアウォール・IDS/IPS・ディープパケット検査アプライアンスをデプロイ・スケール・管理するために設計されたロードバランサーです。主な特徴：
- L3ルーティング + L4ロードバランシング：IPパケットレベルでの処理
- GENEVE プロトコル（ポート6081）でアプライアンスにトラフィックを転送
- Gateway Load Balancerエンドポイント（GWLBE）：VPC間で透過的にトラフィックを誘導
- サードパーティファイアウォールアプライアンスに最適：AWS Marketplace製品との標準統合
- 最小の運用オーバーヘッド：ルート変更のみでトラフィック誘導
他の選択肢について：
A. NLBは汎用のL4ロードバランサーで、パケット検査用に設計されていません。
B. ALBはL7 HTTPロードバランサーで、IPパケット検査ができません。
C. Transit Gatewayはマルチ VPC接続用で、パケット検査の直接的なツールではありません。
正解：D
Lambda + SQSキューによる疎結合設計は、スケーラビリティの向上と構成の簡素化の両方を実現します：
- 責務の分離：
- Lambda A：API Gatewayから情報を受信し、SQSに書き込み（高速処理）
- Lambda B：SQSからメッセージを読み取り、DBに書き込み（制御されたペース） - バッファリング：SQSがトラフィックスパイクを吸収、DBへの負荷を平滑化
- スケーラビリティ：
- Lambda Aは高頻度起動可能
- Lambda Bは並行実行数を制御してDB接続枯渇を防止 - エラー処理：メッセージが失敗してもSQSで再試行可能、DLQで失敗メッセージ管理
他の選択肢について：
A. EC2 + Tomcatへの移行はサーバーレスの利点を失い、構成の労力が増大します。
B. DynamoDB + DAXは大幅なDBエンジン変更で、アプリケーションコードも書き換えが必要です。
C. SNSはパブリッシュ/サブスクライブで、バッファリング機能がなく、失敗時の再試行が困難です。
正解：A
Network Load Balancer（NLB）+ AWS Global Acceleratorの組み合わせが、UDP + 最低レイテンシー + 自動フェイルオーバーの要件に最適です：
- NLB：
- UDPプロトコルサポート（ALBはTCP/HTTP/HTTPSのみ、UDP非対応）
- VoIPのような低レイテンシーアプリに最適
- 超低レイテンシー（ミリ秒未満） - AWS Global Accelerator：
- 自動レイテンシーベースルーティング：最も近いリージョンへ誘導
- 自動フェイルオーバー：ヘルスチェック失敗時に数秒でルート切替
- Anycast IP：静的IPアドレスを提供（DNS変更不要）
- AWSバックボーンネットワーク経由で最適化ルート
他の選択肢について：
B. ALBはUDPをサポートしません（VoIPの要件違反）。
C. Route 53レイテンシールーティングはフェイルオーバーがTTLに依存して遅く、CloudFrontはUDPをサポートしません。
D. ALBのUDP非対応 + 加重ルーティングはレイテンシーベースではありません。
（2つ選択）
正解：A, B
S3 バージョニング + MFA Deleteの組み合わせが、偶発的削除からのデータ保護に最適です：
A. S3バージョニング：
- 削除しても以前のバージョンが保持される
- 削除マーカーを復元することでファイルを復旧可能
- 上書きからもデータを保護
B. MFA Delete：
- オブジェクトの完全削除やバージョニング状態の変更にMFA認証が必要
- ルートユーザーのみが有効化可能
- 追加のセキュリティレイヤーで偶発的・悪意ある削除を防止
両方を組み合わせることで、多層防御が実現します。
他の選択肢について：
C. バケットポリシーはアクセス制御で、削除防止には有効だが、正当な権限を持つユーザーの誤削除を防げない。
D. デフォルト暗号化はデータ保護だが、削除防止とは無関係。
E. ライフサイクルポリシーは逆に自動削除を行うため、偶発的削除防止には不適切。
（2つ選択）
正解：B, E
SNS → SQS → Lambdaパターンは、失敗時の自動再試行とメッセージの耐久性を提供する堅牢なアーキテクチャです：
B. SQSキューをSNSトピックにサブスクライブ：
- SNSメッセージをSQSキューに永続化
- Lambdaが失敗してもメッセージは最大14日間保持
- ネットワーク問題時もメッセージロスなし
E. LambdaがSQSから読み取るよう変更：
- Lambdaがキューから自動的にポーリング
- 失敗時は自動再試行（設定可能）
- 最終的に失敗したメッセージはデッドレターキュー（DLQ）に送信
- Visibility Timeoutで重複処理防止
他の選択肢について：
A. Lambdaは自動的にマルチAZで実行されます（ユーザー設定不要）。また、AZ障害ではなくネットワーク問題が原因です。
C. CPU/メモリ増加はパフォーマンス改善で、失敗時の再取り込みとは無関係。
D. Lambdaには「プロビジョンドスループット」という概念はなく、プロビジョンド同時実行数（Provisioned Concurrency）は起動遅延削減用です。