AWS SAA サンプル問題

正解：B

A　アクセスキーは長期認証情報そのもので、要件に真っ向から反する。ユーザーデータはメタデータサービス経由で参照できるため、キーの露出リスクも高い

B（正解）　正解。インスタンスメタデータ経由で自動ローテーションされる一時認証情報が配布され、インスタンス上に静的キーを置かずに済む

C　Parameter Storeを読むための認証情報が別途必要になるうえ、取得後もアクセスキー自体は長期認証情報のまま。問題を先送りしているだけ

D　ルートユーザーのアクセスキーはそもそも作成すべきでない最悪の選択。権限も無制限で最小権限の原則に反する

正解：C

A　AWSが完全に管理するため運用は最も楽だが、キーポリシーによるアクセス制御や個別の使用監査ができない。「使用を追跡したい」要件を満たせない

B　リクエストごとにキーを送信する方式で、キーマテリアルの保管・配布は完全に自社責任になる。「自社で管理したくない」に反する

C（正解）　正解。キーマテリアルはKMSが保護しつつ、自動キーローテーションの有効化、キーポリシーによる制御、CloudTrailでの使用記録がすべて可能

D　クライアントサイド暗号化はキー管理・ローテーション・監査をすべて自前で実装する必要があり、運用負荷が最も高い

正解：D

A　インターネット経由の通信になるうえ、NATゲートウェイは時間課金に加えて処理データ量にも課金される。大量転送では最も高くつく

B　プライベート通信は実現できるが、ENIの時間課金と処理データ量課金が発生する。S3はゲートウェイ型が使えるため、コスト面で最適ではない

C　インスタンスをインターネットに露出させることになり、要件に反する

D（正解）　正解。ゲートウェイエンドポイントはS3とDynamoDBのみ利用でき、エンドポイント自体の追加料金がかからない。VPC内から直接AWSネットワーク経由で到達する

正解：A

A（正解）　正解。aws:RequestedRegion条件でap-northeast-1とap-northeast-3以外を拒否するSCPを、ルートまたはOUにアタッチする。SCPはメンバーアカウント内のIAMプリンシパルが持てる権限の上限を定義するガードレールで、アカウント側の管理者でも上書きできない

B　アカウント内の管理者が新しいロールを作れば制限を回避できるうえ、200アカウント分の運用負荷が膨大。強制力がない

C　Configは作成後の検出と修復であり、作成そのものを防げない。予防的統制ではなく発見的統制

D　Access Analyzerはリソースポリシーによる外部共有の検出が目的で、リージョン制限の強制機能はない

正解：C

A　AWSマネージドキーはサービス側が自動作成・管理するもので、専有ハードウェアでも単一テナントでもない。制御権も最も弱い

B　Secrets Managerは認証情報などのシークレット保管が目的で、暗号化キーを保護するHSMではない。そもそもSecrets Manager自体がKMSに依存する

C（正解）　正解。CloudHSMは単一テナントの専有HSMを提供し、FIPS 140-2レベル3検証済み。AWSはHSM内のキーにアクセスできず、ユーザーがキーの完全な管理権を持つ

D架空　AWS Key Rotation Managerというサービスは存在しない。KMSのキーローテーション機能を独立サービスと誤認させる選択肢

正解：B

A　Shieldはネットワーク層・トランスポート層のDDoS攻撃を対象とする。HTTPペイロードの内容を検査してSQLインジェクションを判定する機能はない

B（正解）　正解。レイヤー7のWebアプリケーションファイアウォールで、SQLインジェクションやXSSのマネージドルールグループを持ち、CloudFrontやALBに直接関連付けられる

C　NACLはIPアドレスとポートによるステートレスなフィルタリングのみ。リクエストボディの内容は判定できず、送信元IPが変わると追随できない

D　VPCの入出力トラフィックを検査するファイアウォールで、CloudFrontディストリビューションには関連付けられない。Webアプリ向けのL7保護にはWAFが適切

正解：C

A　5,000人×アカウント数のIAMユーザー管理が必要で運用負荷が最大。パスワードの二重管理は退職時の失効漏れなど重大なリスクを生む

B　Cognitoはアプリケーションのエンドユーザー向け認証サービス。AWSマネジメントコンソールへの従業員アクセス管理は本来の用途ではない

C（正解）　正解。Organizationsで有効化したうえでADを信頼できるIDソースとして接続する。許可セットを使って複数アカウントへのシングルサインオンを一元管理でき、AWS側でのユーザー作成は不要

D　SCPはアカウントに与えられる権限の上限を定めるガードレールであり、誰がログインできるかを決める仕組みではない。ADのグループを権限に結び付けるにはIDソースとの連携が別途必要になる

正解：D

A　既存の暗号化されていないDBインスタンスに対して、後から暗号化を有効化する変更操作は提供されていない。コンソールの変更画面にも暗号化の項目は現れない。よくある思い込みのひっかけ

B　暗号化されていないDBインスタンスから暗号化されたリードレプリカを作成することはできない。レプリカの暗号化状態はソースを引き継ぐ

C　そのようなパラメータで保存時暗号化を有効化することはできない。パラメータグループはDBエンジンの動作設定であり、ストレージ暗号化の制御は行わない

D（正解）　正解。取得したスナップショットをKMSキーを指定して暗号化コピーし、そこからリストアする。既存DBの暗号化はこの手順が唯一の方法で、切り替え時にアプリのエンドポイント変更とダウンタイムが伴う

正解：A

A（正解）　正解。NACLはサブネット境界で動作し、明示的なDenyルールを書ける。サブネット内の全インスタンスに自動的に適用される

B　セキュリティグループは許可ルールしか書けず、拒否ルールという概念が存在しない。SGとNACLの最重要の違いで、頻出のひっかけ

C　ルートテーブルは送信先に基づく経路制御で、送信元IPによる着信の拒否には使えない

D　インターネットゲートウェイは水平スケールする冗長コンポーネントで、フィルタリングルールを設定する機能を持たない

正解：B

A　組織をまたいで長期のアクセスキーを共有することになり、失効管理や漏洩時の影響範囲の点で最悪の選択

B（正解）　正解。クロスアカウントロールの標準パターン。アカウントB側の信頼ポリシーでアカウントAのプリンシパルを信頼し、アカウントAから引き受ける。有効期限付きの一時認証情報が発行され、信頼ポリシーとアクセス許可ポリシーの両方で権限を絞れる

C　バケットが全世界に公開されてしまう。ACLはそもそも現在は非推奨で、S3ではバケットポリシーの使用が推奨される

D　署名なしURLを知る誰もがアクセスできてしまい、最小権限にならない。認証を伴わないため監査もできない

正解：C

A　MFA Deleteはバージョンの削除にMFA認証を要求するだけで、MFAデバイスを持つルートユーザーは削除できてしまう。「誰も削除できない」要件を満たさない

B　ガバナンスモードはs3:BypassGovernanceRetention権限を持つプリンシパルが保護を解除できる。「例外なく削除不可」という要件には不十分で、コンプライアンスモードとの対比が頻出

C（正解）　正解。コンプライアンスモードでは保持期間中、ルートユーザーを含む誰もオブジェクトバージョンを削除・上書きできず、保持期間の短縮もできない

D　ライフサイクルは期限到来後の自動削除を行うだけで、期間中の手動削除を防ぐ機能はまったくない

正解：D

A　動作はするが、同じサブネットに配置された無関係なリソースからも接続できてしまう。IPベースであるためサブネット構成の変更にも弱い

B　Auto Scalingで起動するインスタンスにElastic IPは自動付与されず、そもそもプライベートサブネットのDB接続にパブリックIPは関係しない

C　NACLはステートレスなので戻りトラフィック用のエフェメラルポート範囲も個別に許可する必要があり、管理が煩雑。インスタンス単位の粒度も出せない

D（正解）　正解。インバウンドルールの送信元にセキュリティグループIDを指定すると、そのSGが付いたインスタンスだけが許可される。インスタンスが入れ替わってもIPを意識せず自動的に追随する

正解：A

A（正解）　正解。指定期間のCloudTrail証跡を解析し、実際に使われたアクションだけを含むIAMポリシーの草案を生成する。使用実績ベースで最小権限へ絞り込む用途に直接使える

B　Trusted Advisorはベストプラクティスの汎用チェック（公開バケット、MFA未設定など）を行うが、特定ロールの使用実績からポリシーを生成する機能はない

C　GuardDutyは脅威検出サービス。悪意ある挙動の検知が目的で、権限の最小化を支援するポリシー生成は行わない

D　管理者権限を持つポリシーを非準拠として検出するだけで、実績に基づく具体的なポリシー案は作らない

正解：A・C・E

A（正解）　正解。REST APIではLambdaオーソライザーで任意のJWTの署名・有効期限・クレームを検証し、認可結果をキャッシュしてバックエンドに到達する前に拒否できる

B　プライベートAPI向けの制御であり、インターネット公開のAPIでは前提が異なる。加えてJWTの検証も呼び出し回数の制限も実現できない

C（正解）　正解。使用量プランは呼び出し元ごとに1日/週/月あたりのクォータとレート上限を設定でき、取引先単位の流量管理をAPI Gateway側で完結できる

D　レイテンシとバックエンド負荷を下げる性能・コスト施策であり、認証・流量制限・攻撃遮断のいずれの要件も満たさない

E（正解）　正解。マネージドルールグループを適用すればSQLインジェクションやクロスサイトスクリプティングなどのリクエストをアプリケーションに届く前に遮断できる

F　流量の上限を外す方向の設定であり、要件の「取引先ごとの上限」と正反対。攻撃を受けた際の影響も拡大する

正解：A・D

A（正解）　正解。ルートユーザーは削除も権限の縮小もできないため、認証を多要素にすることが最も効果的な保護になる。管理アカウントのルートは組織全体に影響するため、ハードウェアMFAなど強度の高いデバイスの利用が推奨される

B　ルートユーザーにはIAMのアイデンティティベースポリシーをアタッチできない。ルートは元からアカウント内のすべての操作が可能であり、ポリシーで権限を定義するという考え方自体が当てはまらない

C　SCPは組織の管理アカウントには一切適用されない。メンバーアカウントのルートには効果があるが、管理アカウントのルートを守る手段にはならない

D（正解）　正解。ルートのアクセスキーは漏えい時の被害が最大級で、しかも代替手段（IAMロールやIdentity Center）が常にあるため保持する理由がない。存在する場合は速やかに削除する

E　Secrets Managerが自動ローテーションできるのはデータベース認証情報などのシークレットであり、AWSアカウントのコンソールパスワードは対象外。保管したところでルート自体の保護強度は上がらない

正解：C

A　リードレプリカは非同期レプリケーションのためデータ損失の可能性があり、昇格も手動操作が必要。自動フェイルオーバーの要件を満たさない

B　バックアップは復旧の最後の砦だが、リストアには長い時間がかかる。数分以内の自動復旧という要件には遠く及ばない

C（正解）　正解。別AZのスタンバイへ同期レプリケーションが行われ、AZ障害時にRDSがDNSエンドポイントを自動的に切り替える。データ損失なく数分以内に復旧できる

D　処理能力は上がるが可用性はまったく向上しない。単一AZのままではAZ障害で停止する

正解：B

A　ピークに合わせた固定サイズは平常時の無駄が大きく、想定を超えるスパイクでは結局取りこぼす。根本的な緩衝機構がない

B（正解）　正解。注文受付APIがキューに書き込み、在庫処理システムが処理できるペースで取り出す。キューがバッファとして働き、生産者と消費者のスループット差を吸収する。スパイクを平準化する疎結合の基本パターン

C　SNSはプッシュ型で、購読側が処理しきれなくてもメッセージが押し込まれる。バッファリングにはならず、SNS+SQSの組み合わせが必要

D　ALBにレート制限機能はなく、仮に制限できたとしても超過した注文を捨てることになる。「注文を失わない」要件に反する

正解：C

A　最も安価だが、インフラを一から構築するためRTOが数時間から数日かかる。RTO 2時間の要件を満たせないと問題文が明示している

B　RPO/RTOはほぼゼロにできるが、本番同等のリソースを二重に持つため維持コストが最大。「コストを抑えたい」要件に対して過剰

C（正解）　正解。アプリ層はAMIとテンプレートを準備して停止しておき、データ層のみ常時稼働させる。RPOを小さく保ちつつ、コンピュート層は災害時に起動するため平常時コストを大きく抑えられる

D　RTOはさらに短くなるがアプリ層も常時課金されるため、パイロットライトよりコストが高い。RTO 2時間で足りるなら過剰投資になる

正解：A

A（正解）　正解。レイヤー4で動作し超低レイテンシと極めて高いスループットを実現する。AZごとに静的IPを持ち、Elastic IPの割り当てにも対応する

B　レイヤー7のHTTP/HTTPS向けで、TCPそのものは扱えない。IPアドレスは可変のDNS名で提供され、静的IPを持てない

C　サードパーティの仮想アプライアンス（ファイアウォールやIDS）を透過的に挿入するためのもので、アプリケーションのフロントエンド用途ではない

D　旧世代のロードバランサーで新規利用は推奨されない。NLB相当の性能や静的IPも提供しない

正解：D

A　同一AZ内の冗長化ではAZ障害時に両方が停止する。またRoute 53のフェイルオーバーはDNS TTLの分だけ切り替えが遅れる

B　Auto Recoveryは同一AZ内で同じインスタンスを復旧する機能。AZ障害には対応できず、負荷に応じた台数の増減も行わない

C　復旧が手動になるため可用性が人的対応に依存する。自動スケーリングの要件も満たさない

D（正解）　正解。複数AZのサブネットにまたがるASGをApplication Load Balancerの背後に置くと、ALBが健全なAZのインスタンスにのみ振り分け、ASGが不足分を他AZで自動補充する。負荷に応じたスケールアウト・インも同時に実現できる

正解：B

A　標準キューはベストエフォート順序で、少なくとも1回配信のため重複が起こりうる。可視性タイムアウトは処理中の再配信を防ぐだけで順序も重複も解決しない

B（正解）　正解。FIFOキューはメッセージグループ単位で厳密な順序を保証し、重複排除IDにより5分間の重複送信を排除する。まさにこの要件のための機能

C　標準トピックは順序保証も重複排除も行わない。順序と重複排除が必要ならSNS FIFOトピックとSQS FIFOキューの組み合わせが必要になる

D　Firehoseは配信先へのバッファリング付きロードが目的で、順序保証も重複排除も提供しない。取引処理のワークフローには適さない

正解：C

A　DLMはEBSスナップショットとEBS-backed AMIが対象。RDSやDynamoDB、EFSは管理できず、一元化の要件を満たさない

B　実現は可能だが、リトライやエラー処理、保持期間の削除処理まで自前で作り込むことになり運用負荷が高い。マネージドサービスがある場面での車輪の再発明

C（正解）　正解。EBS、RDS、DynamoDB、EFSなど多数のサービスを横断して、単一のプランでスケジュール・保持期間・監査レポートを一元管理できる

D　Configが記録するのは構成情報の履歴であってデータのバックアップではない。データの復元はできない

正解：A

A（正解）　正解。既定のEC2ヘルスチェックはインスタンスのステータスチェックしか見ない。ELBヘルスチェックを有効にすると、ターゲットグループの判定で異常なインスタンスが終了・置換される

B　登録解除時に既存接続の完了を待つ時間の設定で、異常インスタンスの検知や置換には関係しない

C　猶予期間は起動直後にヘルスチェックを無視する時間。0にすると起動途中のインスタンスが誤って終了されかねず、今回の原因とは無関係

D　台数は増えるがハングしたインスタンスはグループ内に残り続け、ALBがそこへ振り分ける限り障害は解消しない

正解：B

A　NATゲートウェイは作成時に指定した単一のAZ内で動作するAZサービスで、マルチAZ構成というオプションは存在しない

B（正解）　正解。各AZのパブリックサブネットにNATゲートウェイを作成し、同一AZのプライベートサブネットのルートテーブルをそれぞれのNATゲートウェイに向ける。AZ障害の影響をそのAZ内に閉じ込める標準構成で、AZをまたぐデータ転送料金も削減できる

C　Elastic IPを増やしてもNATゲートウェイが存在するAZは1つのままで、可用性は向上しない

D　インターネットゲートウェイはVPCに1つだけアタッチするもので、サブネット単位では付けられない。またIGW経由の直接通信はプライベートサブネットの定義に反する

正解：D

A　1つのメッセージは1つのコンシューマーにしか渡らないため、3システムのうち1つしか各イベントを受け取れない。ファンアウトにならない典型的な誤り

B　サブシステム間が密結合になり、1つが停止すると関数全体が失敗する。障害の分離という要件を満たさない

C　ファンアウトはできるが、サブシステム停止中のメッセージは再試行の上限を超えると失われる。「復旧後に処理させたい」という要件に対して保持機構が足りない

D（正解）　正解。SNSのファンアウトで全キューに複製配信され、各キューがサブシステムごとのバッファになる。1つが停止してもメッセージはキューに残り、復旧後に処理できる

正解：C

A　通常のCRRは大半のオブジェクトを迅速に複製するが、時間についてのSLAはない。オブジェクト数の監視では個々のオブジェクトの遅延を把握できない

B　SRRは同じリージョン内の別バケットへの複製で、リージョン障害に対するDRにならない

C（正解）　正解。RTCは99.99%のオブジェクトを15分以内に複製するSLAを提供し、レプリケーション進行状況のメトリクスとイベント通知も付随する

D　ライフサイクルルールはストレージクラスの移行と失効を扱うもので、別リージョンや別バケットへのコピーはできない。最短粒度も日単位

正解：B

A　常時余剰インスタンスを抱えることになりコスト効率が悪化する。反応が起きるのが負荷上昇後である点も変わらず、急激な立ち上がりには追いつきにくい

B（正解）　正解。予測スケーリングは過去の負荷履歴から周期的な需要を学習し、負荷が来る前にインスタンスを起動してキャパシティを確保する。繰り返しパターンが明確な今回のケースに最も適合する

C　誤終了は防げるが、起動が始まるタイミング自体は変わらないため立ち上がりの遅れは解消しない

D　上限に達していない限り効果はなく、そもそも問題は上限ではなく起動のタイミングと所要時間にある

正解：A

A（正解）　正解。ライター障害時にAuroraはレプリカを自動的に昇格させる。レプリカが存在すればフェイルオーバーは通常30秒程度で完了し、クラスターエンドポイントが自動で切り替わる

B　バックトラックは論理的な誤操作からクラスターを過去の時点へ巻き戻す機能。インスタンス障害時の自動フェイルオーバーとは目的が異なる

C　ストレージ層の耐久性は確かに高いが、レプリカが1つもない場合はライター障害時に新しいインスタンスの作成が必要になり復旧に時間がかかる

D　リーダーエンドポイントは読み取り専用インスタンスへ振り分けるもので、書き込みには使えない。ライター用にはクラスターエンドポイントを使う

正解：C

A　gp3を含む通常のEBSボリュームは1インスタンスにしかアタッチできない。マルチアタッチ対応のio2でもクラスター対応ファイルシステムが別途必要で、POSIX共有の要件には合わない

B　S3はオブジェクトストレージでPOSIXのファイルロックやパーミッションのセマンティクスを持たない。既存のファイルI/Oを前提としたレガシーアプリはそのまま動かせない

C（正解）　正解。EFSは複数インスタンスから同時にマウントできるフルマネージドNFSで、POSIXセマンティクスを備え、容量は自動的に伸縮する

D　インスタンスストアは停止でデータが消える揮発性ストレージ。rsyncによる事後同期では同時書き込みの一貫性も保証できない

正解：A

A（正解）　正解。キーによるアクセスパターンに対して規模を問わず1桁ミリ秒の性能を出し、オンデマンドキャパシティモードならトラフィック変動に自動で追随してキャパシティ計画も不要

B　リレーショナルDBは複雑なクエリに強いが、数百万同時接続への水平スケールは苦手。接続数の急増にはインスタンスサイズの変更が必要になる

C　列指向の分析用データウェアハウスで、大量の集計クエリ向け。単一行の低レイテンシな読み書きには極めて不向き

D　グラフデータベースで、関係のたどり方が中心のクエリに最適化されている。キーによる単純なルックアップに使うのは過剰かつ不適切

正解：B

A　静的ファイルの配置は近くなるが、ユーザーを最寄りバケットへ導く仕組みを別途作る必要があり、動的コンテンツやAPI応答は速くならない

B（正解）　正解。CloudFrontディストリビューションはエッジロケーションで静的コンテンツをキャッシュしつつ、動的リクエストもAWSバックボーン経由でオリジンへ転送するため全体のレイテンシが改善する

C　複数リージョンに実体がある場合に最寄りへ誘導する機能。単一リージョンにしか環境がない現状では改善効果がない

D　ALBはリージョン内のAZにしか配置できず、他国にエンドポイントを置くことはできない

正解：C

A　SQSはメッセージを1つのコンシューマーが取得すると他からは見えなくなる。複数用途での並行読み取りや、読み終えたデータの再処理ができない

B　S3などへのロードに特化した配信サービスで、複数のリアルタイムコンシューマーがストリームを独立に読む用途には対応しない

C（正解）　正解。ストリーム内のデータは保持期間中は消費されても残り、複数のコンシューマーがそれぞれ独立したチェックポイントで読める。保持期間の設定により24時間さかのぼる再処理も可能

D　ファンアウトはできるがメッセージを保持しないため、過去24時間分の再処理ができない。順序保証もなく高スループットのテレメトリには不向き

正解：D

A　IOPSがボリュームサイズに比例し、4TBでは12,000 IOPS程度が上限。60,000 IOPSには届かない

B　大きなブロックのシーケンシャル読み書きに最適化されたHDDで、IOPS性能は極めて低い。データベースのランダムI/Oには不適

C　アクセス頻度の低いデータ向けの最も安価なHDD。性能要件を到底満たさない

D（正解）　正解。io2 Block ExpressはプロビジョンドIOPS SSDの最上位で、IOPSをサイズと独立してプロビジョニングできる。単一ボリュームで数十万IOPSとサブミリ秒レイテンシに対応する、I/O集約型データベース向けの選択肢

正解：B

A　読み取りは分散できるが、バイナリログベースの非同期レプリケーションのためレプリケーション遅延が相対的に大きく、フェイルオーバーもAuroraより遅い。ストレージも上限を見て拡張を管理する必要がある

B（正解）　正解。Auroraレプリカは共有ストレージ層を直接参照するためレプリケーション遅延が通常ミリ秒台に収まり、リーダーエンドポイントで最大15台まで負荷分散できる。ストレージは10GB単位で自動拡張し、フェイルオーバーも高速

C　パッチ適用、バックアップ、フェイルオーバーをすべて自前で運用することになり、運用負荷が最も高い

D　MySQL互換という前提が崩れ、SQLベースのアプリケーションを全面的に書き換える必要がある。移行コストが要件に見合わない

正解：A

A（正解）　正解。Redisはリスト、ハッシュ、ソート済みセットなどの豊富なデータ構造を持ち、マルチノード構成でのレプリケーションと自動フェイルオーバー、永続化に対応する

B　Memcachedは単純なキーバリューのみでレプリケーションを持たない。ノード障害でそのノードのキャッシュは失われ、要件を満たさない

C　DAXはDynamoDB専用のキャッシュ層で、リレーショナルデータベースの前段には配置できない

D　CloudFrontはHTTPレスポンスのエッジキャッシュであり、アプリケーションとDBの間のクエリ結果キャッシュとしては機能しない

正解：C

A　強力だがクラスターの常時稼働コストとロード作業が発生する。月に数回のアドホック分析には過剰で、コスト効率が悪い

B　大規模なETLや機械学習には適するが、クラスター管理とチューニングの負荷がある。単純なSQL調査にはオーバースペック

C（正解）　正解。サーバーレスでインフラ管理が不要、S3のデータをそのままSQLで検索でき、スキャンしたデータ量に対してのみ課金される

D　Logs InsightsがクエリできるのはCloudWatch Logsのロググループに取り込まれたログだけで、S3上のオブジェクトを直接検索することはできない

正解：B

A　汎用の共有ファイルシステムとしては優れるが、HPC向けの数百GB/秒級スループットとサブミリ秒レイテンシには届かない

B（正解）　正解。LustreはHPC向けの高性能並列ファイルシステムで、S3とネイティブに連携してオブジェクトを透過的に読み書きできる。まさにこの種のワークロード向け

C　共有ファイルシステムにならず、数百台分のデータ複製とコピー時間が問題になる。単一ボリュームの帯域も要件に届かない

D　Windows向けのSMB共有ファイルサーバーで、LinuxベースのHPC並列処理には設計思想が合わない

正解：D

A　一時的には改善するが、行指向のOLTPエンジンで数百TBの集計を行うという構造的なミスマッチは解消しない。垂直スケールには上限もある

B　DynamoDBは複数テーブルのJOINや任意の集計クエリを苦手とする。分析用途にはそもそも向かない

C　同じレポートの2回目以降は速くなるが、毎晩生成する初回のクエリ実行時間はまったく変わらない

D（正解）　正解。列指向格納により集計対象カラムだけを読み、複数ノードで並列処理する。ペタバイト級のデータウェアハウス分析のために設計されたサービス

正解：C

A　スロットリングは避けられるがレイテンシ自体は改善しない。ミリ秒からマイクロ秒への短縮はキャパシティ追加では実現できない

B　整合性は上がるがレイテンシは結果整合性の読み取りより悪化する。要件と逆方向の変更

C（正解）　正解。DynamoDB専用のインメモリキャッシュで、キャッシュヒット時にマイクロ秒の応答を返す。DynamoDB互換のAPIを提供するため、アプリケーションのエンドポイントをDAXクラスターに向けるだけでよくコード変更は最小限で済む

D　レイテンシは改善するが、キャッシュの読み書きと無効化のロジックをアプリに実装する必要があり「コードを変更したくない」条件に合わない

正解：A

A（正解）　正解。Amazon Data Firehose（旧Kinesis Data Firehose）はフルマネージドでシャード管理が不要。バッファリング、Parquetへの形式変換、圧縮、動的パーティショニングによるプレフィックス分けを設定だけで実現できる

B　実現できるがシャードの容量計画とコンシューマーアプリの運用が必要で、要件の「運用を避けたい」に反する

C　バッチ化、形式変換、パーティショニングをすべて自前で実装する必要がある。マネージド機能があるのに作り込む形になる

D　小さなオブジェクトが大量に生成されてS3のリクエスト料金と後段の処理効率が悪化する。ニアリアルタイム性も失われる

正解：B

A　参照頻度が下がった後も最も高い保存単価を払い続けることになる。削除の手動運用もミスの元になる

B（正解）　正解。Standard-IAはミリ秒単位の即時取得を保ちながら保存単価が安い。失効アクションで削除も自動化でき、要件と料金体系が一致する

C　保存単価はさらに安いが、取り出しに数分から数時間かかる。「参照時は即時取得が必要」という要件を満たさない

D　バージョニングは誤削除対策であり、現行オブジェクトのアクセス頻度に応じたコスト最適化にはならない。むしろ保存容量が増える

正解：D

A　柔軟だが単価が最も高い。中断耐性のあるワークロードでこれを選ぶのは機会損失

B　常時稼働するベースライン向け。夜間のみ動く変動ワークロードでは稼働していない時間も課金され、かえって割高になる

C　特定AZのキャパシティを確保する仕組みで、料金はオンデマンド単価のまま。使用していなくても課金され、削減にはならない

D（正解）　正解。中断耐性があり期限に余裕のあるバッチ処理はスポットの理想的なユースケースで、オンデマンド比で最大90%の削減が見込める

正解：C

A　50Mbpsで150TBを送ると理論上でも約280日かかる。帯域が制約である以上、ネットワーク転送では期限に間に合わない

B　帯域は解決するが、専有接続の物理開通には通常数週間から数か月かかり、一度限りの移行のために契約するのはコスト面でも不合理

C（正解）　正解。回線帯域に依存せず大容量を物理輸送でき、複数台を並行して使えば数週間という期間に収まる。ペタバイト未満のオフライン移行における標準的な選択肢。なお、Snowball Edgeは2025年11月に新規注文の受付を終了し、2026年12月末で全商用リージョンでのサポート終了が告知されている（後継はオンライン転送がDataSync、物理搬送がAWS Data Transfer Terminalやパートナーソリューション）。試験ガイドには引き続き掲載されているため出題を維持している

D　Outpostsは設置までに数か月を要する常設の設備で、一度きりの移行には不相応。リージョンへの複製も結局は同じ50Mbpsの回線を通るため期限に間に合わない

正解：A

A（正解）　正解。アクセスパターンを監視して自動的に階層を移動し、頻繁/低頻度階層間の移動に取り出し料金がかからない。予測不能なアクセスに対する標準的な答え

B　保存単価は安いが取り出しごとにデータ取得料金がかかる。突然頻繁に読まれるようになった場合、Standardより高くつく可能性がある

C　さらに安価だが単一AZにしか保存されず耐久性が下がる。取り出し料金の問題も解決しない

D　ライフサイクルは日数ベースの一方向の移行しか定義できず、実際のアクセス状況に追随しない。移行リクエスト料金も無駄に発生する

正解：B

A　割引率は高いがリージョンとインスタンスファミリーに固定され、変更できない。ファミリーやリージョンが変わる可能性があるという条件と噛み合わない

B（正解）　正解。1時間あたりの支出額をコミットする方式で、インスタンスファミリー、サイズ、リージョン、さらにFargateやLambdaにも自動的に適用される。柔軟性を保ったまま最大級の割引が得られる

C　割引率はCompute Savings Plansよりわずかに高いが、特定リージョンの特定インスタンスファミリーに固定される。変更の可能性があるという条件に合わない

D　スポットは中断される前提のため、下回ってはならないベースラインキャパシティの確保には使えない

正解：C

A　フルロード中の更新差分が反映されないため、切り替え時にソースを停止する必要があり長いダウンタイムが発生する。異種エンジン間のスキーマ変換も行われない

B　SQL ServerのバックアップをPostgreSQLへリストアすることはできない。異なるエンジン間ではバックアップ形式の互換性がない

C（正解）　正解。SCTが異種エンジン間のスキーマとストアドプロシージャのコードを変換し、DMSのCDCによる継続的レプリケーションが切り替え直前まで変更を追随させるためダウンタイムを最小化できる

D　DataSyncはファイル/オブジェクトの転送サービスで、データベースファイルをコピーしても異種エンジンのAuroraでは読み込めない

正解：D

A　ミリ秒での即時取得ができる代わりに保存単価はDeep Archiveより大幅に高い。48時間の猶予がある要件では過剰なサービスレベル

B　数分から12時間で取り出せるが、保存単価はDeep Archiveの約4倍。48時間許容できる今回の条件では最小コストにならない

C架空　S3 Glacier Instant Deep Archiveというストレージクラスは存在しない。Instant RetrievalとDeep Archiveの名称を合成した架空の選択肢

D（正解）　正解。S3で最も保存単価が安いクラスで、標準取り出しで12時間、大容量取り出しで48時間以内。年に1回程度の長期アーカイブ用途そのもの

正解：A

A（正解）　正解。リクエストがない時間帯は課金が発生せず、数百リクエスト規模なら無料利用枠に収まる可能性すらある。アイドルコストゼロが要件に完全に合致する

B　台数は半減するが、1台は24時間課金され続ける。アイドル時間の課金をなくすという要件は満たさない

C　単価は下がるものの、依然として常時稼働分の固定費を払い続ける。使用量に対して過大な構成という本質は変わらない

D　単価は下がるが常時稼働コストは残り、さらに中断によりAPIが応答しなくなるリスクを負う。同期的なAPI提供には不適切

正解：B

A　動作はするが、リトライ、帯域制御、整合性検証、失敗時の通知をすべて自前で作り込むことになる。大量ファイルでは性能面でも不利

B（正解）　正解。オンプレミスにエージェントを配置すれば、増分検出、並列転送、転送中の暗号化、チェックサムによる整合性検証、スケジュール実行がすべてマネージドで提供される

C　ボリュームゲートウェイはブロックストレージのバックアップ用途で、S3上に個別のオブジェクトとしてログファイルを配置する形にはならない

D　Snowファミリーは一度きりの大容量オフライン移行向け。毎晩の定常同期に物理デバイスの往復を使うのは非現実的。なお、Snowcone自体も2024年11月に販売を終了しており、Snowball Edgeも2026年12月末でサポート終了が告知されている

正解：C

A　単価は下がるがランダムI/O性能が大幅に劣化する。3,000 IOPSを安定して出せず「性能は維持」という条件に反する

B　EBSボリュームはサイズを縮小できない。さらにgp2ではサイズを減らすとベースラインIOPSも下がり性能が落ちる

C（正解）　正解。gp3はgp2よりGBあたり単価が約20%安く、3,000 IOPSと125MB/秒までがベースラインとして追加料金なしで含まれる。IOPSとスループットは必要に応じて個別に指定でき、ダウンタイムなしで変更できて性能も維持できる

D　io2はgp3より単価が高く、プロビジョンドIOPSにも別途課金される。この要件ではコストが増加する方向