AWS SAAのサンプル問題（本番形式・解説付き）

他の選択肢が誤りである理由

• 「Transit Gateway を新規に構築する」Transit GatewayはVPCやオンプレ拠点を大規模にハブ&スポークで束ねるサービスであり、2つのVPC間の単純な1対1接続には過剰なコストと複雑さを伴います。
• 「両 VPC をインターネット経由で接続する」インターネット経由では通信が外部ネットワークを通るため、プライベートIPで直接通信するという要件を満たせません。
• 「各 VPC に NAT ゲートウェイを置く」NAT ゲートウェイはプライベートサブネットからインターネットへのアウトバウンド変換専用であり、VPC間のプライベート相互通信を実現する手段ではありません。

他の選択肢が誤りである理由

• 「インスタンスタイプを大きくし、1 台あたりの処理量を増やして台数を減らす」台数が減っても OS とミドルウェアの保守作業は利用者に残る。
• 「専用ホストへ移し、ハードウェアを占有して構成を安定させる」ハードウェアの占有は保守の担い手を変えないため運用負荷は下がらない。
• 「Auto Scaling を導入し、負荷に応じてインスタンス数を増減させる」台数の自動調整は可用性と費用の話で、保守責任の所在は動かない。

他の選択肢が誤りである理由

• 「毎晩Lambdaで全件スキャンして期限切れを削除する方式となっており、スキャンをオンデマンドキャパシティモード（On-Demand）のテーブルに対して実行すれば、読み取りコストを追加料金なしでゼロに抑えられる」オンデマンドモードであっても実際に読み取ったリクエスト量に応じた課金は発生するため、テーブル全体を毎晩スキャンする処理自体のコストがゼロになるわけではなく、追加コストや自前のバッチ処理を避けたいという要件には反します。
• 「テーブルを毎日作り直す」テーブルを毎日作り直すとデータ移行・参照先変更が必要になり運用が大幅に複雑化するうえ、アイテム単位の細かな期限管理にも対応できない。
• 「グローバルセカンダリインデックスを追加する方式を採用しており、有効期限の属性をGSIのパーティションキーに設定すれば、期限切れアイテムがインデックス側で自動的に削除される仕組みが働く」GSIはクエリのアクセスパターンを増やすための副次的なインデックスであり、パーティションキーに何を設定してもアイテムを期限に基づいて自動的に削除する機能そのものは持たないため、期限切れデータの自動削除にはTTL属性の設定が別途必要です。

他の選択肢が誤りである理由

• 「ボリューム全体を毎回 S3 へ丸ごとコピーし、コピー先のバケットに S3 ライフサイクルポリシーを設定して古い世代を自動削除する運用にする」毎回ボリューム全体をゼロからコピーする操作は差分検出を伴わない全量転送であり、コピー先にライフサイクルポリシーを設定しても転送そのものの非効率さは変わらず、時間とコストが無駄にかかり続けます。
• 「インスタンスを停止してAMIを手動で作るだけにする方式を採用しており、AMI作成時に自動的に別リージョンへコピーする設定と定期保持ポリシーがデフォルトで有効になっている」AMIの作成はデフォルトでは元リージョンにのみ保存され、別リージョンへのコピーや古い世代の自動削除といった保持ポリシーはいずれも手動または別途の自動化設定なしには行われません。
• 「ボリュームをGlacierに直接移動する方式を用いており、EBSコンソールのストレージクラス変更メニューからボリュームをオブジェクトとしてGlacierへ直接エクスポートできる（Glacier は S3 のアーカイブ向けストレージクラス）」EBSボリュームはブロックストレージであり、S3のようなストレージクラスの概念を持たないため、ボリュームをGlacierへ直接移動・エクスポートする機能はAWSに存在しません。

他の選択肢が誤りである理由

• 「単一の大型 EC2 インスタンス」単一インスタンスでは Spark/Hadoop の分散処理の恩恵が得られず、ペタバイト級のデータ処理には性能が不十分です。
• 「Amazon Athena 単体」アドホッククエリ向けのサーバーレスサービスであり、Spark/Hadoop クラスターを構成してカスタム分散処理を実行する機能はありません。
• 「AWS Lambda の大量並列」最大実行時間が 15 分という制限があり、ステートフルな分散処理フレームワーク（Spark 等）の長時間ジョブには適しません。