模擬問題集一覧

SAP-C02 模擬問題集（練習問題）

AWS Solutions Architect – Professional 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

4 練習テスト 200 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

4 テスト · 全 200 問
1
模擬問題集①先頭 15 問 無料
50 問 120 分 合格 70%
2
模擬問題集② プラン限定
50 問 120 分 合格 70%
3
模擬問題集③ プラン限定
50 問 120 分 合格 70%
4
模擬問題集④ プラン限定
50 問 120 分 合格 70%

説明

SAP-C02（AWS Solutions Architect – Professional）の合格に向けた、本番形式の模擬問題集です。全 200 問を4 回の練習テストに分割し、 試験モード／演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 200 問＋全解説が受け放題

模試プラン（¥980/月）なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

SAP-C02 の操作は、実機のハンズオンラボで身につける

問題集で覚えた知識を、本物の Azure・AWS 環境で手を動かして確かめられます。 Pro プランなら SAP-C02 対応のハンズオンラボ 5 本と、この問題集の全 200 問がすべて使えます。 ラボは会員登録だけで 1 本無料で試せます。

SAP-C02 の対応ラボを見る（5 本）ラボを 1 本無料で試す

SAP-C02 の出題範囲（カバーしている分野）

全 200 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はSAP-C02 の学習ガイドにまとめています。

SAP-C02 の無料練習問題（15 問・解説つき）

会員登録なしで、全 200 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1（2 つ選択してください。組織の複雑さに対応する設計
問題
ある企業は、オンプレミスのシステムから Amazon S3 バケットへデータを送信したいと考えています。この企業は、3 つの異なるアカウントに S3 バケットを作成しました。データはインターネットを経由せず、プライベートに送信される必要があります。この企業には、AWS への既存の専用接続はありません。 これらの要件を満たすために、ソリューションアーキテクトが取るべき手順の組み合わせはどれですか？（2 つ選択してください。）

選択肢と解説

  • ✓
    AWS クラウドにネットワーキングアカウントを設置する。ネットワーキングアカウントにプライベート VPC を作成する。オンプレミス環境とプライベート VPC の間にプライベート VIF を使用した AWS Direct Connect 接続をセットアップする。
  • 2
    AWS クラウドにネットワーキングアカウントを設置する。ネットワーキングアカウントにプライベート VPC を作成する。オンプレミス環境とプライベート VPC の間にパブリック VIF を使用した AWS Direct Connect 接続をセットアップする。
  • ✓
    ネットワーキングアカウントに Amazon S3 インターフェイスエンドポイントを作成する。
  • 4
    ネットワーキングアカウントに Amazon S3 ゲートウェイエンドポイントを作成する。
  • 5
    AWS クラウドにネットワーキングアカウントを設置する。ネットワーキングアカウントにプライベート VPC を作成する。S3 バケットをホストするアカウントの VPC を、ネットワークアカウントの VPC とピアリングする。

解説

【正解】A、C

【0からの解説】
要件は「オンプレミスから S3 へ、インターネットを通さずプライベートに送る」「既存の専用接続はない」です。
まず、オンプレミスと AWS をプライベートに結ぶ専用線が必要なので AWS Direct Connect を新設します。Direct Connect には VIF（仮想インターフェイス）が複数種類あり、VPC 内のプライベート IP リソースに到達するには「プライベート VIF」を使います（選択肢 A）。
次に、オンプレミスから S3 へ完全にプライベートな経路で到達させるには、VPC 内に S3 への「インターフェイスエンドポイント（AWS PrivateLink）」を作成します（選択肢 C）。インターフェイスエンドポイントは VPC 内に ENI（プライベート IP）を持つため、Direct Connect のプライベート VIF 経由でオンプレミスから名前解決・到達でき、トラフィックはインターネットを経由しません。1 つのネットワーキングアカウントの VPC にインターフェイスエンドポイントを置けば、別アカウントの S3 バケットにもバケットポリシー次第でアクセスできます（S3 はリージョン共有サービスのため、エンドポイントは特定バケット専用ではありません）。

【誤りの選択肢】
B：パブリック VIF は AWS のパブリックエンドポイント（パブリック IP）へ到達するためのもので、VPC 内のプライベートリソースには接続しません。また「インターネットを経由しない完全プライベート」という観点でも、S3 ゲートウェイエンドポイントはオンプレミスからは利用できず、要件に合いません。
D：S3 ゲートウェイエンドポイントは、同一リージョンの VPC 内（オンプレミスではなく VPC のサブネット）からのアクセス専用で、Direct Connect/VPN 経由のオンプレミスからは到達できません。オンプレミスからプライベートに S3 へ到達するにはインターフェイスエンドポイントが必要です。
E：VPC ピアリングは VPC 同士を接続するもので、S3 そのものへプライベート到達するための仕組みではありません。S3 はマネージドサービスであり VPC ではないため、ピアリングでは目的を満たせません。

【参考】
Amazon S3 用 AWS PrivateLock（インターフェイスエンドポイント）
Direct Connect の仮想インターフェイス（VIF）
この問題のページを開く →
問題 2（3 つ選択してください。組織の複雑さに対応する設計
問題
ある企業は AWS Organizations を使用しています。この企業は、集約型のネットワーキングアカウントで 2 台のファイアウォールアプライアンスを運用しています。各ファイアウォールアプライアンスは、手動で構成された高可用性の Amazon EC2 インスタンス上で実行されています。Transit Gateway が、集約型ネットワーキングアカウントの VPC をメンバーアカウントの VPC と接続しています。各ファイアウォールアプライアンスは静的なプライベート IP アドレスを使用しており、その IP アドレスを使ってメンバーアカウントからインターネットへトラフィックをルーティングしています。 最近のインシデントで、誤った設定のスクリプトが両方のファイアウォールアプライアンスの終了を開始してしまいました。ファイアウォールアプライアンスの再構築中に、同社は起動時にファイアウォールアプライアンスを構成する新しいスクリプトを作成しました。 同社はファイアウォールアプライアンスのデプロイをモダナイズしたいと考えています。ファイアウォールアプライアンスは、ネットワークが拡張して増加するトラフィックを処理できるよう、水平方向にスケールできる必要があります。同社は会社の方針に準拠するため、引き続きこのファイアウォールアプライアンスを使用しなければなりません。ファイアウォールアプライアンスのプロバイダーは、最新バージョンのファイアウォールコードがすべての AWS サービスで動作することを確認しています。 これらの要件を最もコスト効率よく満たすために、ソリューションアーキテクトが推奨すべき手順の組み合わせはどれですか？（3 つ選択してください。）

選択肢と解説

  • ✓
    集約型ネットワーキングアカウントに Gateway Load Balancer をデプロイする。AWS PrivateLink を使用するエンドポイントサービスをセットアップする。
  • 2
    集約型ネットワーキングアカウントに Network Load Balancer をデプロイする。AWS PrivateLink を使用するエンドポイントサービスをセットアップする。
  • ✓
    新しいスクリプトをユーザーデータとして使用してファイアウォールアプライアンスを構成する起動テンプレートと Auto Scaling グループを作成する。インスタンスターゲットタイプを使用するターゲットグループを作成する。
  • 4
    Auto Scaling グループを作成する。新しいスクリプトをユーザーデータとして使用してファイアウォールアプライアンスを構成する AWS Launch Wizard デプロイを構成する。IP ターゲットタイプを使用するターゲットグループを作成する。
  • ✓
    各メンバーアカウントに VPC エンドポイントを作成する。ルートテーブルを更新して VPC エンドポイントを指すようにする。
  • 6
    集約型ネットワーキングアカウントに VPC エンドポイントを作成する。各メンバーアカウントのルートテーブルを更新して VPC エンドポイントを指すようにする。

解説

【正解】A、C、E

【0からの解説】
サードパーティ製ファイアウォールアプライアンス（インライン検査）を、水平スケール可能・高可用に「モダナイズ」する AWS の標準パターンが Gateway Load Balancer（GWLB）です。
(A) GWLB は、L3 のトランスペアレントなネットワーク仮想アプライアンス（ファイアウォール/IDS/IPS 等）を背後に並べて負荷分散・スケール・ヘルスチェックする専用ロードバランサーです。GWLB は GENEVE プロトコルでトラフィックをアプライアンスへ転送し、AWS PrivateLink を使った「エンドポイントサービス」として公開できます。これにより各 VPC から GWLB エンドポイント（GWLBe）経由でファイアウォール群へトラフィックを送れます。
(C) ファイアウォールアプライアンス群を Auto Scaling グループ＋起動テンプレートで管理し、新スクリプトをユーザーデータで起動時構成すれば、自動復旧と水平スケールが実現します。GWLB のターゲットグループは「インスタンスターゲットタイプ」を使うのが適切です。
(E) 各メンバーアカウントに Gateway Load Balancer エンドポイント（VPC エンドポイント）を作成し、ルートテーブルでそのエンドポイントを指すようにすれば、各メンバーアカウントの送信トラフィックを集約型のファイアウォール群へ検査のため転送できます。
これにより、静的 IP に依存した手作りの脆い構成から、ASG によるセルフヒーリング＆スケールと GWLB による分散検査というマネージドかつ堅牢な構成へモダナイズできます。

【誤りの選択肢】
B：Network Load Balancer（NLB）は通常の L4 ロードバランシング用で、トラフィックを「透過的に検査して元の宛先へ戻す」インライン型のサードパーティアプライアンス連携には向きません。この用途専用の GWLB が正解です。
D：AWS Launch Wizard は SAP や SQL Server など特定のエンタープライズアプリの導入を支援するサービスで、汎用のファイアウォールアプライアンスを ASG でデプロイする用途には使いません。また GWLB のターゲットは通常「インスタンスタイプ」で構成します。
F：エンドポイント（GWLBe）はトラフィックを発生させる各メンバーアカウント側の VPC に置き、メンバーアカウントのルートテーブルからそこへ向ける必要があります。集約アカウント側にだけ作る構成では、メンバーアカウントの送信トラフィックを検査経路に乗せられません。

【参考】
Gateway Load Balancer とは
Gateway Load Balancer エンドポイント（PrivateLink）
この問題のページを開く →
問題 3これらの要件を満たすソリューションはどれですか？ワークロードの移行とモダナイゼーションの加速
問題
ある企業は、ウェブサイトをオンプレミスのデータセンターから AWS へ移行する必要があります。このウェブサイトは、ロードバランサー、Linux オペレーティングシステム上で動作するコンテンツ管理システム（CMS）、および MySQL データベースで構成されています。 CMS はファイルシステム用に NFS 互換の永続ストレージを必要とします。AWS 上の新しいソリューションは、予測不能なトラフィック増加に応じて 2 台の Amazon EC2 インスタンスから 30 台の EC2 インスタンスまでスケールできる必要があります。また、新しいソリューションはウェブサイトへの変更を一切必要とせず、データ損失を防止しなければなりません。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • ✓
    Amazon Elastic File System（Amazon EFS）ファイルシステムを作成する。CMS を Application Load Balancer と Auto Scaling グループを備えた AWS Elastic Beanstalk にデプロイする。.ebextensions を使用して EFS ファイルシステムを EC2 インスタンスにマウントする。Elastic Beanstalk 環境とは別に Amazon Aurora MySQL データベースを作成する。
  • 2
    Amazon Elastic Block Store（Amazon EBS）マルチアタッチボリュームを作成する。CMS を Network Load Balancer と Auto Scaling グループを備えた AWS Elastic Beanstalk にデプロイする。.ebextensions を使用して EBS ボリュームを EC2 インスタンスにマウントする。Elastic Beanstalk 環境内に Amazon RDS for MySQL データベースを作成する。
  • 3
    Amazon Elastic File System（Amazon EFS）ファイルシステムを作成する。CMS をサポートする EC2 インスタンスを起動するための起動テンプレートと Auto Scaling グループを作成する。トラフィックを分散するために Network Load Balancer を作成する。Amazon Aurora MySQL データベースを作成する。EC2 Auto Scaling のスケールインライフサイクルフックを使用して EFS ファイルシステムを EC2 インスタンスにマウントする。
  • 4
    Amazon Elastic Block Store（Amazon EBS）マルチアタッチボリュームを作成する。CMS をサポートする EC2 インスタンスを起動するための起動テンプレートと Auto Scaling グループを作成する。トラフィックを分散するために Application Load Balancer を作成する。MySQL データベースをサポートするために Amazon ElastiCache for Redis クラスターを作成する。EC2 ユーザーデータを使用して EBS ボリュームを EC2 インスタンスにアタッチする。

解説

【正解】A

【0からの解説】
要件を分解します。
(1)「NFS 互換の永続的な共有ストレージ」「2〜30 台の複数 EC2 から同時アクセス」→ 複数の EC2 から同時マウントできる NFS 共有ファイルシステムが必要なので Amazon EFS が最適です。EFS は数千台規模まで同時マウントでき、自動でスケール・冗長化されます。
(2)「ウェブサイトへの変更を一切必要としない」「予測不能なトラフィックに 2〜30 台でスケール」「データ損失防止」→ アプリ無改修で迅速にデプロイ・自動スケールするなら AWS Elastic Beanstalk（ALB＋Auto Scaling グループ）が適しています。.ebextensions を使えば各インスタンス起動時に EFS をマウントする設定をコード化できます。
(3) MySQL データベースは、データ損失防止（マルチ AZ・自動バックアップ）と性能の観点から、Beanstalk 環境とは分離したマネージド DB（Amazon Aurora MySQL）として作成します。Beanstalk 環境内に DB を作ると環境削除時に DB も消えるリスクがあるため、分離が定石です。

【誤りの選択肢】
B：EBS マルチアタッチは同一 AZ の限られたインスタンス（最大 16）にしかアタッチできず、クラスター対応ファイルシステムが別途必要で、NFS 共有でもありません。30 台規模・複数 AZ・無改修の要件に不向きです。さらに Beanstalk 環境内に DB を作る構成はデータ損失リスクがあります。
C：EFS のマウントは「スケールイン」ではなく「スケールアウト（起動）時」に行う必要があります。スケールイン用ライフサイクルフックでマウントするという記述が論理的に誤りです。
D：EBS マルチアタッチは前述の制約に加え、ElastiCache for Redis は MySQL データベースの「代替」にはならない（キャッシュであり永続 RDB ではない）ため、データ損失防止の要件を満たしません。

【参考】
Amazon EFS とは
Elastic Beanstalk と EFS の連携
この問題のページを開く →
問題 4これらの要件を満たすソリューションはどれですか？組織の複雑さに対応する設計
問題
あるソリューションアーキテクトは、クラウドエンジニアのチームが AWS CLI を使って Amazon S3 バケットにオブジェクトをアップロードするための安全な方法を提供する必要があります。各クラウドエンジニアは、IAM ユーザー、IAM アクセスキー、および仮想多要素認証（MFA）デバイスを持っています。クラウドエンジニアの IAM ユーザーは、S3-access という名前のグループに所属しています。クラウドエンジニアは、Amazon S3 で何らかのアクションを実行する際には必ず MFA を使用しなければなりません。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    S3 バケットにポリシーをアタッチし、IAM ユーザーが S3 バケットに対してアクションを実行する際に MFA コードの入力を求めるようにする。AWS CLI で IAM アクセスキーを使用して Amazon S3 を呼び出す。
  • 2
    S3-access グループの信頼ポリシー（trust policy）を更新し、プリンシパルがグループを引き受ける（assume）際に MFA の使用を必須にする。AWS CLI で IAM アクセスキーを使用して Amazon S3 を呼び出す。
  • 3
    S3-access グループにポリシーをアタッチし、MFA が存在しない限りすべての S3 アクションを拒否する。AWS CLI で IAM アクセスキーを使用して Amazon S3 を呼び出す。
  • ✓
    S3-access グループにポリシーをアタッチし、MFA が存在しない限りすべての S3 アクションを拒否する。AWS Security Token Service（AWS STS）から一時的な認証情報をリクエストする。ユーザーが Amazon S3 でアクションを実行する際に Amazon S3 が参照するプロファイルに、その一時的な認証情報をアタッチする。

解説

【正解】D

【0からの解説】
「S3 のすべての操作で MFA を必須にする」には、IAM ポリシーで条件キー aws:MultiFactorAuthPresent が true でない限りアクションを拒否（Deny）するのが基本です。これをグループに付ければチーム全員に適用できます。
ここで重要なのは「MFA が反映されるのはどの認証情報か」です。長期の IAM アクセスキーをそのまま AWS CLI で使っても、その呼び出しには MFA 情報が含まれず、aws:MultiFactorAuthPresent は false になり Deny されます。MFA を効かせるには、まず STS の GetSessionToken などで MFA コードを提示して「一時的な認証情報（MFA セッション）」を取得し、その一時認証情報を CLI のプロファイルに設定して S3 を呼び出す必要があります。これにより一時認証情報には MFA 情報が含まれ、Deny 条件を通過できます。よって D が正解です。

【誤りの選択肢】
A：S3 バケットポリシーは「MFA コードの入力を促す（prompt）」ことはできません。ポリシーはあくまで条件で許可/拒否を判定するだけで、しかも長期アクセスキーのままでは MFA セッションが付かないため要件を満たせません。
B：「グループ」は IAM ロールのように assume するものではなく、信頼ポリシーも持ちません。グループに対する trust policy という概念自体が誤りです。
C：MFA 必須の Deny ポリシー自体は正しいものの、長期 IAM アクセスキーをそのまま使うと MFA セッションが含まれないため、すべての S3 操作が拒否されて動作しません。STS の一時認証情報を取得する D の手順が欠けています。

【参考】
MFA で保護された API アクセスの設定
STS GetSessionToken（一時認証情報）
この問題のページを開く →
問題 5これらの要件を満たすソリューションはどれですか？既存ソリューションの継続的な改善
問題
ある企業は、Amazon Elastic File System（Amazon EFS）ファイルシステムにドキュメントを保存・管理しています。このファイルシステムは AWS Key Management Service（AWS KMS）キーで暗号化されています。ファイルシステムは、独自ソフトウェアを実行する Amazon EC2 インスタンスにマウントされています。 同社はファイルシステムの自動バックアップを有効化しています。自動バックアップは AWS Backup のデフォルトバックアッププランを使用しています。 ソリューションアーキテクトは、削除されたドキュメントを RPO 100 分以内に復元できるようにしなければなりません。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • ✓
    新しい IAM ロールを作成する。新しいバックアッププランを作成する。新しい IAM ロールを使用してバックアップを作成する。KMS キーポリシーを更新して新しい IAM ロールがキーを使用できるようにする。ファイルシステムに対して 1 時間ごとのバックアップスケジュールを実装する。
  • 2
    新しいバックアッププランを作成する。KMS キーポリシーを更新して AWSServiceRoleForBackup IAM ロールがキーを使用できるようにする。30 分ごとにファイルシステムのバックアップを実行するカスタム cron 式を実装する。
  • 3
    新しい IAM ロールを作成する。既存のバックアッププランを使用する。KMS キーポリシーを更新して新しい IAM ロールがキーを使用できるようにする。ポイントインタイムリカバリ用に継続的バックアップ（continuous backups）を有効化する。
  • 4
    既存のバックアッププランを使用する。KMS キーポリシーを更新して AWSServiceRoleForBackup IAM ロールがキーを使用できるようにする。ファイルシステムのクロスリージョンレプリケーションを有効化する。

解説

【正解】A

【0からの解説】
RPO（目標復旧時点）100 分は「直近 100 分以内の状態に戻せること」を意味します。AWS Backup のデフォルトプランは 1 日 1 回のバックアップなので、最大で約 24 時間分のデータを失う可能性があり RPO 100 分を満たせません。よってバックアップ間隔を 100 分より短くする必要があります。
ここで重要なのは、AWS Backup の EFS バックアップは「継続的バックアップ（ポイントインタイムリカバリ）」をサポートしていない点です（継続的バックアップ対象は S3 や RDS、Aurora、DynamoDB など）。そのため、EFS では定期スナップショット型のスケジュールでしか細かい RPO を実現できません。1 時間（60 分）ごとのバックアップスケジュールにすれば、最大の損失は約 60 分となり RPO 100 分を満たします。
さらに、独自の IAM ロールを使ってバックアップを実行する場合は、暗号化に使う KMS キーのキーポリシーで、その IAM ロールに kms:Decrypt 等の使用を許可しておく必要があります。これで暗号化された EFS のバックアップ/復元が成立します。よって A が正解です。

【誤りの選択肢】
B：30 分間隔でも RPO 100 分は満たせますが、AWS Backup のバックアップ頻度（cron）は通常 1 時間より短い間隔をサポートしていません。30 分ごとという設定自体が成立しないため不適切です（A の 1 時間間隔で要件は十分満たせます）。
C：EFS は AWS Backup の継続的バックアップ（ポイントインタイムリカバリ）に対応していません。EFS で PITR を有効化するという前提が誤りです。
D：クロスリージョンレプリケーションは別リージョンへの複製（DR/可用性）であって、削除されたドキュメントを過去時点に戻す「バックアップ」ではありません。削除はレプリカ側にも伝播し得るため、RPO 100 分の復元要件を満たしません。

【参考】
AWS Backup による EFS のバックアップ
AWS Backup で暗号化に使う KMS キーの許可
この問題のページを開く →
問題 6これらの要件を最もコスト効率よく満たすソリューションはどれですか？既存ソリューションの継続的な改善
問題
ある企業は、製造業向けアプリケーションのために AWS 環境を設計しています。このアプリケーションは顧客から成功を収め、ユーザーベースが増加しました。同社は、1 Gbps の AWS Direct Connect 接続を通じて AWS 環境を自社のオンプレミスデータセンターに接続しています。同社はこの接続に BGP を構成しています。 同社は、ソリューションが高可用性・耐障害性・安全であることを保証するために、既存のネットワーク接続ソリューションを更新する必要があります。 これらの要件を最もコスト効率よく満たすソリューションはどれですか？

選択肢と解説

  • 1
    動的なプライベート IP AWS Site-to-Site VPN をセカンダリパスとして追加し、転送中のデータを保護して Direct Connect 接続にレジリエンスを提供する。MACsec を構成して Direct Connect 接続内のトラフィックを暗号化する。
  • 2
    同社のオンプレミスデータセンターと AWS の間にもう 1 つの Direct Connect 接続をプロビジョニングして、転送速度を上げレジリエンスを提供する。MACsec を構成して Direct Connect 接続内のトラフィックを暗号化する。
  • 3
    複数のプライベート VIF を構成する。オンプレミスデータセンターと AWS の間で複数の VIF にわたってデータを負荷分散し、レジリエンスを提供する。
  • ✓
    静的な AWS Site-to-Site VPN をセカンダリパスとして追加し、転送中のデータを保護して Direct Connect 接続にレジリエンスを提供する。

解説

【正解】D

【0からの解説】
要件は「高可用性・耐障害性・安全」を「最もコスト効率よく」です。
Direct Connect は専用線ですが、それ自体は暗号化されていません。安全性（転送中の暗号化）とレジリエンス（冗長経路）を低コストで足すなら、Direct Connect のバックアップとして AWS Site-to-Site VPN を追加するのが定石です。VPN は IPsec でトラフィックを暗号化するため「転送中データの保護」を満たし、Direct Connect 障害時のフェイルオーバー経路として「耐障害性」も提供します。VPN はインターネット経由で低コストに用意できます。
選択肢 A と D の違いは「動的（dynamic/BGP）」か「静的（static）」かです。最もコスト効率を重視する観点では、シンプルな静的ルーティングの Site-to-Site VPN をセカンダリに追加する D が、追加の MACsec 対応機器や複数 DX を必要とせず最安で要件を満たします。

【誤りの選択肢】
A：動的 VPN ＋ MACsec の組み合わせは要件を満たせますが、MACsec は対応する専用の物理ポート（専有接続）やデバイスが必要でコストが高くなります。VPN を足すだけで暗号化要件は満たせるため、MACsec まで足す A は「最もコスト効率が良い」とは言えません。
B：2 本目の Direct Connect を引くのは最もコストが高い選択肢です。さらに MACsec も追加しており、コスト効率の要件に最も反します。
C：複数のプライベート VIF は同一の Direct Connect 物理接続上に作るため、その物理接続自体が落ちると全 VIF が同時に失われます。真の冗長経路にならず耐障害性を満たさず、暗号化（安全性）も提供しません。

【参考】
Direct Connect のバックアップとしての Site-to-Site VPN
AWS Site-to-Site VPN とは
この問題のページを開く →
問題 7（2 つ選択してください。ワークロードの移行とモダナイゼーションの加速
問題
ある企業は、ブログプラットフォームを AWS に移行しています。同社のオンプレミスサーバーは、AWS Site-to-Site VPN 接続を通じて AWS に接続しています。ブログのコンテンツは複数の執筆者によって 1 日に数回更新され、ネットワーク接続ストレージ（NAS）サーバー上のファイル共有から配信されています。 同社は、コンテンツの更新を遅延させることなく、ブログプラットフォームを移行する必要があります。同社は、ブログプラットフォームを実行するために、Application Load Balancer の背後にある複数のアベイラビリティーゾーンに Amazon EC2 インスタンスをデプロイ済みです。同社はまた、オンプレミスサーバーから 200 TB のアーカイブデータを可能な限り早く Amazon S3 に移動する必要があります。 これらの要件を満たすステップの組み合わせはどれですか？（2 つ選択してください。）

選択肢と解説

  • 1
    Amazon EventBridge で週次の cron ジョブを作成する。その cron ジョブで AWS Lambda 関数を呼び出し、NAS サーバーから EC2 インスタンスを更新する。
  • 2
    EC2 インスタンスがコンテンツアクセスのために共有できる Amazon Elastic Block Store（Amazon EBS）Multi-Attach ボリュームを構成する。EBS ボリュームを NAS サーバーと週次で同期するコードを記述する。
  • ✓
    Amazon Elastic File System（Amazon EFS）ファイルシステムを NAS サーバーとして機能させるためにオンプレミスサーバーにマウントする。ブログデータを EFS ファイルシステムにコピーする。EFS ファイルシステムを EC2 インスタンスにマウントしてコンテンツを配信する。
  • ✓
    AWS Snowball Edge Storage Optimized デバイスを注文する。静的データのアーティファクトをデバイスにコピーする。デバイスを AWS に発送する。
  • 5
    AWS Snowcone SSD デバイスを注文する。静的データのアーティファクトをデバイスにコピーする。デバイスを AWS に発送する。

解説

【正解】C、D

【0からの解説】
この問題は 2 つの独立した要件を満たす必要があります。
(1) 複数の執筆者が頻繁に更新する共有ファイルを、複数 AZ にまたがる EC2 インスタンス群から「同時に読み書きできる共有ストレージ」として配信し、更新を遅延させないこと。
(2) 200 TB のアーカイブデータを「可能な限り早く」S3 へ移動すること。

(1) について、Amazon EFS は複数の EC2 インスタンスから同時にマウントできるフルマネージドな NFS 共有ファイルシステムです。オンプレミス側にも（Direct Connect/VPN 経由で）マウントできるため、まず NAS の代わりに EFS を使ってコンテンツをコピーし、移行後は EC2 群が同じ EFS をマウントして配信できます。共有・同時書き込み・複数 AZ という要件に最も合致します（選択肢 C）。

(2) について、200 TB を Site-to-Site VPN（一般に数百 Mbps 〜 1.25 Gbps 程度）でネットワーク転送するには膨大な時間がかかります。物理デバイスで一括輸送する AWS Snowball Edge Storage Optimized（1 台あたり約 80 TB 使用可能）を使うのが最速です。200 TB なので複数台になりますが、それでもネットワーク転送より圧倒的に速く、「可能な限り早く」を満たします（選択肢 D）。

【誤りの選択肢】
A：週次の cron で NAS から EC2 を更新する方式は、1 日数回の更新に追従できず（週 1 回しか反映されない）、各インスタンスにデータを複製する運用も煩雑で、共有ストレージという本質的な要件を満たしません。
B：EBS Multi-Attach は同一 AZ 内のごく限られた条件（Nitro・io1/io2 等）でしか共有できず、複数 AZ にまたがる EC2 では共有できません。また週次同期では頻繁な更新に追従できません。
E：AWS Snowcone SSD は容量が約 14 TB（SSD モデル）と非常に小さく、200 TB の移行には全く足りません。大容量データの一括移行には Snowball Edge が適切です。

【参考】
Amazon EFS とは
AWS Snowball Edge デバイスのオプション
AWS Snowcone とは
この問題のページを開く →
問題 8これらの目標を達成するセットアップはどれですか？組織の複雑さに対応する設計
問題
ある企業に、Auto Scaling グループ内の Amazon EC2 インスタンスを使用するアプリケーションがあります。品質保証（QA）部門は、アプリケーションをテストするために、多数の短命な（short-lived）環境を起動する必要があります。アプリケーション環境は現在、部門のマネージャーが AWS CloudFormation テンプレートを使用して起動しています。スタックを起動するために、マネージャーは CloudFormation、EC2、Auto Scaling の API を使用する権限を持つロールを使用しています。 マネージャーは、テスター自身が自分の環境を起動できるようにしたいと考えていますが、各ユーザーに広範な権限を付与したくはありません。 これらの目標を達成するセットアップはどれですか？

選択肢と解説

  • 1
    AWS CloudFormation テンプレートを Amazon S3 にアップロードする。QA 部門のユーザーにマネージャーのロールを引き受ける（assume）権限を与え、権限をそのテンプレートとそれが作成するリソースに制限するポリシーを追加する。ユーザーに CloudFormation コンソールからテンプレートを起動する方法を教育する。
  • ✓
    環境テンプレートから AWS Service Catalog 製品を作成する。既存のロールを使った起動制約（launch constraint）を製品に追加する。QA 部門のユーザーには AWS Service Catalog API のみを使用する権限を与える。ユーザーに AWS Service Catalog コンソールからテンプレートを起動する方法を教育する。
  • 3
    AWS CloudFormation テンプレートを Amazon S3 にアップロードする。QA 部門のユーザーに、権限をそのテンプレートとそれが作成するリソースに制限する条件付きで、CloudFormation と S3 の API を使用する権限を与える。ユーザーに CloudFormation コンソールからテンプレートを起動する方法を教育する。
  • 4
    環境テンプレートから AWS Elastic Beanstalk アプリケーションを作成する。QA 部門のユーザーには Elastic Beanstalk の権限のみを与える。ユーザーに、既存のロールをサービスロールとして環境に渡しながら Elastic Beanstalk CLI で Elastic Beanstalk 環境を起動する方法を教育する。

解説

【正解】B

【0からの解説】
「広範な権限を各ユーザーに与えずに、ユーザー自身がセルフサービスでプロビジョニングできるようにする」というのは AWS Service Catalog の中心的なユースケースです。

Service Catalog では、管理者が CloudFormation テンプレートを「製品（product）」として登録し、ポートフォリオでユーザーに公開します。ここで重要なのが「起動制約（Launch Constraint）」です。製品に既存のマネージャーのロール（EC2・Auto Scaling・CloudFormation 権限を持つロール）を起動制約として設定すると、実際のリソース作成はその制約ロールの権限で行われます。

そのため、テスターには「Service Catalog の API を使う権限」だけを与えればよく、テスター自身は EC2 や CloudFormation の直接権限を一切持ちません。これにより最小権限を保ちながらセルフサービスを実現できます。

【誤りの選択肢】
A：ユーザーにマネージャーのロールを assume させると、ポリシーで絞っても実質そのロールの権限をユーザーが直接行使できることになり、「広範な権限を付与しない」という意図が崩れます。テンプレート/リソース単位での厳密な制限も運用が複雑です。
C：ユーザーに CloudFormation と S3 の権限を直接付与すると、結局スタックが作成する EC2/Auto Scaling リソースを作る権限も必要になり、最小権限の維持が困難です。Service Catalog の起動制約のような権限分離ができません。
D：Elastic Beanstalk は Web アプリのデプロイ/管理向けのサービスで、既存の Auto Scaling アプリの CloudFormation テンプレートをそのまま「短命なテスト環境」として量産する用途には適しません。要件のセルフサービス＋最小権限という観点でも Service Catalog が最適です。

【参考】
AWS Service Catalog とは
Service Catalog の起動制約（Launch Constraints）
この問題のページを開く →
問題 9移行を最も短時間で完了するために、同社が取るべき一連のステップはどれですか？ワークロードの移行とモダナイゼーションの加速
問題
ある企業が、データセンターを AWS クラウドへ移行しており、移行を可能な限り早く完了する必要があります。同社のデータセンターでは、何百もの VMware VM 上で多数のアプリケーションが稼働しています。各 VM には、共通の共有ファイルを含む共有 Windows フォルダーが構成されています。このファイル共有のサイズは 100 GB を超えています。 同社のコンプライアンスチームは、各 VM へのすべてのソフトウェアのインストールおよび変更について、変更リクエストの起票と承認を必須としています。同社は、AWS とデータセンターの間に 10 Gbps の帯域を持つ AWS Direct Connect 接続を有しています。 移行を最も短時間で完了するために、同社が取るべき一連のステップはどれですか？

選択肢と解説

  • 1
    VM Import/Export を使用して各 VM のイメージを作成する。AWS Application Migration Service を使用してそれらのイメージを管理・閲覧する。Windows ファイル共有のデータを Amazon Elastic File System（Amazon EFS）ファイルシステムにコピーする。移行後、ファイル共有を EFS ファイルシステムに再マッピングする。
  • 2
    AWS Application Discovery Service のエージェントレスアプライアンスを VMware vCenter にデプロイする。AWS Migration Hub で検出された VM のポートフォリオを確認する。
  • ✓
    AWS Application Migration Service のエージェントレスアプライアンスを VMware vCenter にデプロイする。Windows ファイル共有のデータを新しい Amazon FSx for Windows File Server ファイルシステムにコピーする。移行後、各 VM 上のファイル共有を FSx for Windows File Server ファイルシステムに再マッピングする。
  • 4
    AWS Application Discovery Service エージェントと AWS Application Migration Service エージェントを各 VMware ハイパーバイザーに直接デプロイする。AWS Migration Hub でポートフォリオを確認する。各 VM のファイル共有データを新しい Amazon FSx for Windows File Server ファイルシステムにコピーする。移行後、各 VM 上のファイル共有を FSx for Windows File Server ファイルシステムに再マッピングする。

解説

【正解】C

【0からの解説】
この問題のポイントは 2 つの制約です。
(1) コンプライアンス上、各 VM へのソフトウェアのインストール/変更には変更リクエストの承認が必要 → VM ごとにエージェントを入れる方式は承認の手間で大幅に遅くなる、または避けたい。
(2) 移行を最短時間で完了したい。

AWS Application Migration Service（MGN）には「エージェントレスレプリケーション」があり、VMware vCenter にアプライアンスをデプロイすることで、各 VM に個別エージェントをインストールせずにブロックレベルで複製できます。これによりソフトウェアインストールの変更リクエストを VM ごとに起票する必要がなくなり、最短で進められます（選択肢 C）。

共有 Windows フォルダー（Windows のファイル共有）は、Windows ネイティブの SMB ファイル共有をフルマネージドで提供する Amazon FSx for Windows File Server に移行するのが最適です。データは 100 GB 超ですが 10 Gbps の Direct Connect があるためネットワークコピーで十分高速です。移行後、各 VM のファイル共有を FSx に再マッピングします。

【誤りの選択肢】
A：移行先が EFS（Linux/NFS 向け）になっており、Windows のファイル共有（SMB）には不適切です。Windows ファイル共有には FSx for Windows File Server を使うべきです。また VM Import/Export ベースは MGN のエージェントレス継続レプリケーションより手間と時間がかかります。
B：Application Discovery Service は移行の「事前検出（インベントリ把握）」を行うサービスで、これ単体では実際の移行（サーバー複製）が行われません。要件の「移行を完了する」を満たしません。
D：各ハイパーバイザーに Discovery エージェントと MGN エージェントを直接インストールする方式は、ソフトウェアインストールに伴う変更リクエストの承認が大量に発生し、最短時間という要件に反します。エージェントレスアプライアンス方式（C）の方が速いです。

【参考】
Application Migration Service のエージェントレススナップショットベースレプリケーション
Amazon FSx for Windows File Server とは
この問題のページを開く →
問題 10（2 つ選択してください。組織の複雑さに対応する設計
問題
ある企業が、大量の IoT デバイスからデータを収集しています。データは Amazon S3 のデータレイクに保存されています。データサイエンティストは、別の AWS アカウントの VPC 内にある 2 つのパブリックサブネットで稼働する Amazon EC2 インスタンス上で分析を行います。 データサイエンティストは、EC2 インスタンスからデータレイクにアクセスする必要があります。EC2 インスタンスには、Amazon S3 へのアクセス権限を持つロールがすでに割り当てられています。 会社のポリシーにより、許可されたネットワークのみが IoT データにアクセスできるようにする必要があります。 この要件を満たすために、ソリューションアーキテクトが取るべきステップの組み合わせはどれですか？（2 つ選択してください。）

選択肢と解説

  • ✓
    データサイエンティストの VPC に Amazon S3 用のゲートウェイ VPC エンドポイントを作成する。
  • 2
    データサイエンティストの AWS アカウントに、データレイク用の S3 アクセスポイントを作成する。
  • 3
    EC2 インスタンスのロールを更新する。s3:DataAccessPointArn 条件キーの値が有効なアクセスポイント ARN である場合に s3:GetObject アクションを許可する条件付きのポリシーを追加する。
  • 4
    VPC ルートテーブルを更新して、S3 トラフィックを S3 アクセスポイントへルーティングする。
  • ✓
    s3:DataAccessPointArn 条件キーの値が有効なアクセスポイント ARN である場合に s3:GetObject アクションを許可する条件付きの S3 バケットポリシーを追加する。

解説

【正解】A、E

【0からの解説】
要件は「許可されたネットワーク（データサイエンティストの VPC）からのみ S3 データレイクにアクセスさせる」ことです。これを安全かつ確実に実現する組み合わせを選びます。

(A) ゲートウェイ VPC エンドポイント for S3 を作成すると、EC2 → S3 のトラフィックがインターネットを経由せず AWS ネットワーク内を通り、特定の VPC からのアクセス経路を確立できます。これにより「どのネットワークから来たか」を制御する基盤になります。

(E) S3 バケットポリシーに s3:DataAccessPointArn 条件キーを使った条件を追加すると、「特定の S3 アクセスポイント経由のリクエストにのみ s3:GetObject を許可」できます。アクセスポイントは VPC に紐づけて作成できるため、結果として「許可された VPC（ネットワーク）からのアクセスのみ許可」を実現できます。

A でネットワーク経路を、E でアクセスポイント経由を強制することで、許可されたネットワーク以外からのアクセスを排除できます。

【誤りの選択肢】
B：アクセスポイントは原則として「対象バケットと同じ AWS アカウント」に作成します。データレイク（S3 バケット）は別アカウントにあるため、データサイエンティストのアカウントにアクセスポイントを作るのは適切ではありません（必要なのはバケット側＝データレイク側の制御）。
C：EC2 ロール側に DataAccessPointArn 条件を付けても、それは「呼び出し側が自分の権限を狭める」だけで、データレイク（バケット）側で他経路からのアクセスを拒否する効果がありません。許可されたネットワークのみという要件は、リソース側（バケットポリシー）で強制する必要があります。
D：S3 へのアクセスポイント宛トラフィックは、ルートテーブルでアクセスポイントに直接ルーティングするものではありません。S3 へのプライベート経路はゲートウェイ VPC エンドポイント（A）で実現します。アクセスポイントへの「ルーティング」という設定自体が誤りです。

【参考】
S3 のゲートウェイエンドポイント
Amazon S3 アクセスポイントの管理とアクセス制御
この問題のページを開く →
問題 11この要件を満たすソリューションはどれですか？新しいソリューションの設計
問題
ある企業が、Web アプリケーションを AWS でホストすることを計画しており、トラフィックを Amazon EC2 インスタンス群に負荷分散したいと考えています。セキュリティ要件の 1 つは、クライアントと Web サーバーの間で「エンドツーエンド」の転送中暗号化を有効にすることです。 この要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    EC2 インスタンスを Application Load Balancer（ALB）の背後に配置する。AWS Certificate Manager（ACM）を使用して SSL 証明書をプロビジョニングし、その SSL 証明書を ALB に関連付ける。SSL 証明書をエクスポートして各 EC2 インスタンスにインストールする。ALB をポート 443 でリッスンし、インスタンスのポート 443 にトラフィックを転送するように構成する。
  • 2
    EC2 インスタンスをターゲットグループに関連付ける。AWS Certificate Manager（ACM）を使用して SSL 証明書をプロビジョニングする。Amazon CloudFront ディストリビューションを作成し、その SSL 証明書を使用するように構成する。CloudFront がターゲットグループをオリジンサーバーとして使用するように設定する。
  • ✓
    EC2 インスタンスを Application Load Balancer（ALB）の背後に配置する。AWS Certificate Manager（ACM）を使用して SSL 証明書をプロビジョニングし、その SSL 証明書を ALB に関連付ける。サードパーティ製の SSL 証明書をプロビジョニングして各 EC2 インスタンスにインストールする。ALB をポート 443 でリッスンし、インスタンスのポート 443 にトラフィックを転送するように構成する。
  • 4
    EC2 インスタンスを Network Load Balancer（NLB）の背後に配置する。サードパーティ製の SSL 証明書をプロビジョニングして NLB と各 EC2 インスタンスにインストールする。NLB をポート 443 でリッスンし、インスタンスのポート 443 にトラフィックを転送するように構成する。

解説

【正解】C

【0からの解説】
「エンドツーエンドの転送中暗号化」とは、クライアント → ロードバランサー の区間だけでなく、ロードバランサー → EC2 インスタンス の区間も暗号化することを意味します。つまり HTTPS（TLS）が経路全体で途切れないようにする必要があります。

選択肢 C では、ALB に ACM 発行の証明書を関連付け（クライアント↔ALB を暗号化）、さらに各 EC2 インスタンスにはサードパーティ製（自己管理）の SSL 証明書をインストールして、ALB は HTTPS（ポート 443）でインスタンスへ転送します（ALB↔EC2 も暗号化）。これで全経路が暗号化され、要件を満たします。

ここで重要なのは「ACM のパブリック証明書は、ALB や CloudFront などの AWS サービスに関連付けて使うことはできるが、エクスポートして EC2 に直接インストールすることはできない」という制約です。そのため、EC2 側には別途サードパーティ製/自己管理の証明書が必要になります。

【誤りの選択肢】
A：ACM のパブリック証明書はエクスポートできないため「SSL 証明書をエクスポートして各 EC2 にインストールする」という手順が実現不可能です。よって誤りです。
B：CloudFront でクライアント↔CloudFront は暗号化できますが、ALB を介さずターゲットグループを直接オリジンにすることはできません（CloudFront のオリジンはドメインを指す必要があり、構成として成立しにくい）。また EC2 側の暗号化（エンドツーエンド）が明示されておらず、要件を確実に満たしません。
D：NLB でも TLS 終端は可能ですが、本選択肢は NLB に「サードパーティ証明書をインストール」しつつ EC2 にも証明書を入れる構成で、ACM を使う C と比べ管理が煩雑です。ベストプラクティスとしては ALB + ACM（フロント）+ EC2 個別証明書（バックエンド）の C が適切です。

【参考】
ACM 証明書を使用できるサービス（エクスポート不可の説明）
ALB の HTTPS リスナーの作成
この問題のページを開く →
問題 12これらの要件を「最高のパフォーマンス」で満たすために、同社が使用すべきアーキテクチャはどれですか？組織の複雑さに対応する設計
問題
ある企業が、ハイブリッド DNS ソリューションをアーキテクトする必要があります。このソリューションでは、VPC 内に保存されたリソースのために、ドメイン cloud.example.com 用の Amazon Route 53 プライベートホストゾーンを使用します。 同社には次の DNS 解決要件があります。 ・オンプレミスのシステムが cloud.example.com を解決し、接続できること。 ・すべての VPC が cloud.example.com を解決できること。 ・オンプレミスの企業ネットワークと AWS Transit Gateway の間には、すでに AWS Direct Connect 接続が存在する。 これらの要件を「最高のパフォーマンス」で満たすために、同社が使用すべきアーキテクチャはどれですか？

選択肢と解説

  • ✓
    プライベートホストゾーンをすべての VPC に関連付ける。共有サービス VPC に Route 53 インバウンドリゾルバーを作成する。すべての VPC を Transit Gateway にアタッチし、オンプレミス DNS サーバーに cloud.example.com 用の転送ルールを作成して、そのインバウンドリゾルバーを指すようにする。
  • 2
    プライベートホストゾーンをすべての VPC に関連付ける。共有サービス VPC に Amazon EC2 の条件付きフォワーダーをデプロイする。すべての VPC を Transit Gateway にアタッチし、オンプレミス DNS サーバーに cloud.example.com 用の転送ルールを作成して、その条件付きフォワーダーを指すようにする。
  • 3
    プライベートホストゾーンを共有サービス VPC に関連付ける。共有サービス VPC に Route 53 アウトバウンドリゾルバーを作成する。すべての VPC を Transit Gateway にアタッチし、オンプレミス DNS サーバーに cloud.example.com 用の転送ルールを作成して、そのアウトバウンドリゾルバーを指すようにする。
  • 4
    プライベートホストゾーンを共有サービス VPC に関連付ける。共有サービス VPC に Route 53 インバウンドリゾルバーを作成する。共有サービス VPC のみを Transit Gateway にアタッチし、オンプレミス DNS サーバーに cloud.example.com 用の転送ルールを作成して、そのインバウンドリゾルバーを指すようにする。

解説

【正解】A

【0からの解説】
要件は、(1) すべての VPC が cloud.example.com を解決できる、(2) オンプレミスからも解決できる、をできるだけ高性能（低レイテンシー・少ホップ）で満たすことです。

(1) について、プライベートホストゾーン（PHZ）を「すべての VPC に関連付ける」と、各 VPC は自身の VPC リゾルバー（Amazon が提供する .2 リゾルバー）で直接 PHZ を解決できます。リゾルバーへ転送する必要がないため最も高速です。1 つの VPC だけに関連付ける構成（C・D）だと、他の VPC は転送経由でしか解決できず遅くなります。

(2) について、オンプレミスから AWS 内の名前を解決させるには Route 53 Resolver の「インバウンドエンドポイント（インバウンドリゾルバー）」を使います。オンプレミス DNS に cloud.example.com の転送ルールを設定し、インバウンドエンドポイントの IP を向け先にすれば、オンプレミスから AWS の PHZ を解決できます。

さらに、すべての VPC を Transit Gateway にアタッチしてあることで、オンプレミス → インバウンドリゾルバー、および VPC 間の到達性が確保されます。これらを満たすのは選択肢 A です。

【誤りの選択肢】
B：オンプレミスからの解決を「EC2 上の条件付きフォワーダー」で実現する構成は、自前で EC2 を運用する必要があり、Route 53 Resolver インバウンドエンドポイントを使うマネージドな A に比べ運用負荷が高く、パフォーマンス/可用性でも劣ります。
C：PHZ を共有サービス VPC のみに関連付けると、他の VPC は直接解決できません。さらにオンプレミスからの「インバウンド」解決に必要なのはインバウンドエンドポイントであり、アウトバウンドリゾルバー（AWS→オンプレミス方向の転送用）では役割が逆で要件を満たせません。
D：インバウンドリゾルバーの方向は正しいものの、PHZ を共有サービス VPC のみに関連付け、かつ共有サービス VPC のみを TGW にアタッチしているため、「すべての VPC が解決できる」要件を満たせず、各 VPC の直接解決による高性能化もできません。

【参考】
Route 53 Resolver によるハイブリッド DNS
プライベートホストゾーンの複数 VPC への関連付け
この問題のページを開く →
問題 13この要件を最もコスト効率よく満たすソリューションはどれですか？ワークロードの移行とモダナイゼーションの加速
問題
あるオンライン小売企業が、レガシーなオンプレミスの .NET アプリケーションを AWS に移行しています。このアプリケーションは、ロードバランシングされたフロントエンド Web サーバー、ロードバランシングされたアプリケーションサーバー、および Microsoft SQL Server データベース上で稼働しています。 同社は可能な限り AWS マネージドサービスを使用したいと考えており、アプリケーションを書き直したくはありません。ソリューションアーキテクトは、アプリケーションのスケールに応じてスケーリングの問題を解決し、ライセンスコストを最小化するソリューションを実装する必要があります。 この要件を最もコスト効率よく満たすソリューションはどれですか？

選択肢と解説

  • ✓
    Web ティアとアプリケーションティアのために、Application Load Balancer の背後の Auto Scaling グループに Amazon EC2 インスタンスをデプロイする。Babelfish を有効にした Amazon Aurora PostgreSQL を使用して SQL Server データベースをリプラットフォームする。
  • 2
    AWS Database Migration Service（AWS DMS）を使用してすべてのサーバーのイメージを作成する。オンプレミスのインポートに基づく Amazon EC2 インスタンスをデプロイする。Web ティアとアプリケーションティアのために、Network Load Balancer の背後の Auto Scaling グループにインスタンスをデプロイする。データベースティアとして Amazon DynamoDB を使用する。
  • 3
    Web フロントエンドティアとアプリケーションティアをコンテナ化する。Amazon Elastic Kubernetes Service（Amazon EKS）クラスターをプロビジョニングする。Web ティアとアプリケーションティアのために、Network Load Balancer の背後に Auto Scaling グループを作成する。データベースをホストするために Amazon RDS for SQL Server を使用する。
  • 4
    アプリケーションの機能を AWS Lambda 関数に分割する。Web フロントエンドティアとアプリケーションティアに Amazon API Gateway を使用する。データを Amazon S3 に移行する。Amazon Athena を使用してデータをクエリする。

解説

【正解】A

【0からの解説】
キーワードは「アプリケーションを書き直さない」「マネージドサービスを使う」「スケーリング問題の解決」「ライセンスコストの最小化」です。

最大のコスト要因は Microsoft SQL Server のライセンスです。Amazon Aurora PostgreSQL の Babelfish は、SQL Server の通信プロトコル（TDS）と T-SQL 構文を理解する互換機能で、アプリケーションのデータアクセス部分をほとんど書き換えずに、SQL Server から Aurora PostgreSQL へ移行（リプラットフォーム）できます。これにより SQL Server のライセンス費用を排除でき、ライセンスコストを最小化できます。

Web/アプリ層は、ALB の背後の Auto Scaling グループ上の EC2 で動かせば、既存の .NET アプリをほぼそのまま動かしつつスケーリング問題を解決できます。アプリの書き直しが不要で、コスト効率にも優れるため選択肢 A が最適です。

【誤りの選択肢】
B：DMS は「データベースの移行」ツールであり、サーバーのイメージ作成には使いません（用途の誤り）。さらにリレーショナルな SQL Server を DynamoDB（NoSQL）に置き換えるのはデータモデルが根本的に異なり、アプリの大幅な書き直しが必要になります。
C：RDS for SQL Server を使うため SQL Server のライセンスコストが残り、「ライセンスコスト最小化」を満たしません。さらに Web/アプリ層をコンテナ化する作業は「書き直さない」方針に対して負荷が大きいです。
D：アプリを Lambda + API Gateway に再構築し、データを S3 + Athena に移すのは、アプリケーションの全面的な書き直し（リアーキテクト）であり、「書き直したくない」という要件に明確に反します。

【参考】
Babelfish for Aurora PostgreSQL
Amazon Aurora とは
この問題のページを開く →
問題 14この要件を満たすソリューションはどれですか？ワークロードの移行とモダナイゼーションの加速
問題
ある企業は、オンプレミスでホストしているアプリケーションからメタデータを収集するサービスを使用しています。テレビやインターネットラジオなどのコンシューマーデバイスがこれらのアプリケーションにアクセスします。多くの古いデバイスは特定の HTTP ヘッダーをサポートしておらず、レスポンスにこれらのヘッダーが含まれているとエラーを起こします。同社は、User-Agent ヘッダーによって識別した古いデバイスに送信するレスポンスから、サポートされていないヘッダーを削除するように、オンプレミスのロードバランサーを構成しています。 同社は、このサービスを AWS に移行し、サーバーレス技術を採用しつつ、古いデバイスをサポートし続ける能力を保持したいと考えています。同社はすでにアプリケーションを一連の AWS Lambda 関数に移行済みです。 この要件を満たすソリューションはどれですか？

選択肢と解説

  • ✓
    メタデータサービス用に Amazon CloudFront ディストリビューションを作成する。Application Load Balancer（ALB）を作成する。CloudFront ディストリビューションがリクエストを ALB に転送するように構成する。ALB が各タイプのリクエストに対して正しい Lambda 関数を呼び出すように構成する。User-Agent ヘッダーの値に基づいて問題のあるヘッダーを削除する CloudFront 関数（CloudFront Function）を作成する。
  • 2
    メタデータサービス用に Amazon API Gateway REST API を作成する。API Gateway が各タイプのリクエストに対して正しい Lambda 関数を呼び出すように構成する。User-Agent ヘッダーの値に基づいて問題のあるヘッダーを削除するように、デフォルトのゲートウェイレスポンス（gateway responses）を変更する。
  • 3
    メタデータサービス用に Amazon API Gateway HTTP API を作成する。API Gateway が各タイプのリクエストに対して正しい Lambda 関数を呼び出すように構成する。User-Agent の値に基づいて問題のあるヘッダーを削除するレスポンスマッピングテンプレートを作成する。そのレスポンスデータマッピングを HTTP API に関連付ける。
  • 4
    メタデータサービス用に Amazon CloudFront ディストリビューションを作成する。Application Load Balancer（ALB）を作成する。CloudFront ディストリビューションがリクエストを ALB に転送するように構成する。ALB が各タイプのリクエストに対して正しい Lambda 関数を呼び出すように構成する。viewer リクエストにおいて User-Agent ヘッダーの値に基づいて問題のあるヘッダーを削除する Lambda@Edge 関数を作成する。

解説

【正解】A

【0からの解説】
要件は「サーバーレスで」「User-Agent によって識別した古いデバイス向けのレスポンスから、特定の HTTP ヘッダーを削除する」ことです。

CloudFront には軽量・低レイテンシーで HTTP リクエスト/レスポンスを操作できる CloudFront Functions があり、ビューワーリクエスト/ビューワーレスポンスのイベントでヘッダーの追加・削除・書き換えができます。User-Agent を見て、古いデバイスへのレスポンスから問題のあるヘッダーを削る、というまさにこの用途に最適です。CloudFront → ALB → Lambda の構成でサーバーレスにアプリを動かしつつ、エッジでヘッダー整形を行えます（選択肢 A）。

【誤りの選択肢】
B：API Gateway の「ゲートウェイレスポンス（gateway responses）」は、認証失敗やスロットリングなど API Gateway 自身が生成するエラーレスポンスをカスタマイズする機能で、User-Agent に応じて通常レスポンスから任意のヘッダーを動的に削除する用途には設計されていません。
C：HTTP API は機能が絞られた軽量版で、REST API のようなレスポンスマッピングテンプレート（VTL による変換）をサポートしていません。「レスポンスマッピングテンプレートを作成して関連付ける」という構成自体が成立しません。
D：Lambda@Edge でヘッダー操作自体は可能ですが、本選択肢は「viewer リクエスト」イベントで処理するとしています。削除したいのは「レスポンス」のヘッダーなので、本来は viewer レスポンス（または origin レスポンス）で処理すべきで、イベントの選択が誤りです。また単純なヘッダー削除なら、より軽量・低コストな CloudFront Functions（A）が適切です。

【参考】
CloudFront Functions
CloudFront でのレスポンスヘッダーの操作
この問題のページを開く →
問題 15これらの要件を最もコスト効率よく満たすソリューションはどれですか？ワークロードの移行とモダナイゼーションの加速
問題
ある企業は、従来型の Web アプリケーションを Amazon EC2 インスタンス上で実行しています。同社は、このアプリケーションをコンテナ上で実行されるマイクロサービスとしてリファクタリングする必要があります。アプリケーションには、本番（production）とテスト（testing）という 2 つの異なる環境に、それぞれ別バージョンが存在します。アプリケーションへの負荷は変動しますが、最小負荷と最大負荷は既知です。ソリューションアーキテクトは、運用上の複雑さを最小化するサーバーレスアーキテクチャで、更新後のアプリケーションを設計する必要があります。 これらの要件を最もコスト効率よく満たすソリューションはどれですか？

選択肢と解説

  • 1
    コンテナイメージを AWS Lambda に関数としてアップロードする。想定されるピーク負荷に対応できるよう、関連する Lambda 関数に同時実行数の上限を構成する。Amazon API Gateway 内に本番用とテスト用の 2 つの個別の Lambda 統合を構成する。
  • ✓
    コンテナイメージを Amazon Elastic Container Registry (Amazon ECR) にアップロードする。想定される負荷に対応できるよう、Fargate 起動タイプで自動スケーリングする 2 つの Amazon Elastic Container Service (Amazon ECS) クラスターを構成する。ECR イメージからタスクをデプロイする。トラフィックを各 ECS クラスターに振り分ける 2 つの個別の Application Load Balancer を構成する。
  • 3
    コンテナイメージを Amazon Elastic Container Registry (Amazon ECR) にアップロードする。想定される負荷に対応できるよう、Fargate 起動タイプで自動スケーリングする 2 つの Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを構成する。ECR イメージからタスクをデプロイする。トラフィックを各 EKS クラスターに振り分ける 2 つの個別の Application Load Balancer を構成する。
  • 4
    コンテナイメージを AWS Elastic Beanstalk にアップロードする。Elastic Beanstalk で本番用とテスト用に個別の環境とデプロイを作成する。トラフィックを各 Elastic Beanstalk デプロイに振り分ける 2 つの個別の Application Load Balancer を構成する。

解説

【正解】B

【0からの解説】
「サーバーレス」かつ「運用上の複雑さを最小化」しつつ「最もコスト効率よく」コンテナ化したマイクロサービスを動かす、という 3 つの条件で選択肢を絞ります。

AWS でコンテナをサーバーレスに動かす中核は AWS Fargate です。Fargate を使えば EC2 インスタンス（ホスト）を一切管理せず、タスク（コンテナ）単位で課金され、必要なときだけリソースを消費します。Fargate はオーケストレーターとして ECS と EKS の両方で使えますが、ECS は AWS マネージドでクラスター管理に追加料金がかからないのに対し、EKS は各クラスターごとに時間あたりの管理料金（コントロールプレーン料金）が発生し、Kubernetes 自体の運用知識も必要です。本問は「運用の複雑さ最小」「最もコスト効率」が決め手なので、ECS Fargate を選ぶ B が最適です。本番／テストを 2 つのクラスター＋各々の ALB で分離し、負荷に応じて自動スケーリングする構成も要件に合致します。

【誤りの選択肢】
A：Lambda にはコンテナイメージをデプロイできる機能はありますが、Lambda は本来関数実行サービスで、長時間実行や常時稼働ワークロード、既存の Web アプリのコンテナ移行先としては適合しにくく、「マイクロサービスをコンテナで動かす」という要件の趣旨にも合いません。同時実行数の上限でピークを「捌く」設計も不適切です。
C：EKS + Fargate でも要件は技術的に実現できますが、EKS はクラスターごとの管理料金と Kubernetes 運用負荷が加わるため、ECS と比べてコスト効率・運用簡素さの両面で劣ります。本問の「最もコスト効率／複雑さ最小」では B に負けます。
D：Elastic Beanstalk は背後で EC2 インスタンスをプロビジョニングする PaaS であり、サーバーレスではありません（インスタンスのパッチ・キャパシティ管理が残る）。「サーバーレスアーキテクチャ」という明示要件に反します。

【参考】
AWS Fargate とは
Amazon ECS と Amazon EKS の比較（コンテナサービス）
この問題のページを開く →

SAP-C02 対策のハンズオンラボ

実際の Azure・AWS 環境を払い出して手を動かせます。問題演習と組み合わせると理解が定着します。

S3 / EBS / EFS ストレージを KMS 暗号化とアクセス制御で保護する
intermediate・約 55 分
Amazon EKS（標準サポート版）にコンテナ Web アプリをデプロイする
intermediate・約 55 分
AWS Network Firewall を VPC に構成して送信トラフィックを検査する
intermediate・約 55 分
AWS Fault Injection Simulator で回復性の弱点を見つける
intermediate・約 20 分
IAM 権限境界(Permissions Boundary)で委任時の権限上限を設ける
advanced・約 50 分

SAP-C02 模擬問題集についてよくある質問

SAP-C02 の練習問題は無料で試せますか？

はい。SAP-C02 は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン（月額 ¥980）または Pro プラン（月額 ¥4,980）でご利用ください。

問題は何問ありますか？

SAP-C02 は本番形式の練習テスト 4 回・全 200 問を収録しています。全問に解説が付いています。

解説は付いていますか？

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン（出題分野）別の正答率も受験後に確認できます。

SAP-C02 のハンズオン学習もできますか？

はい。SAP-C02 に対応するハンズオンラボを 5 件ご用意しています。実際の Azure・AWS 環境を払い出して手を動かしながら学習できます。