模擬問題集一覧

SAA-C03 模擬問題集（練習問題）

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

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

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

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

練習テストの内容

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

説明

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

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

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

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

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

SAA-C03 の対応ラボを見る（22 本）ラボを 1 本無料で試す

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

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

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

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

問題 1最も運用上のオーバーヘッドが少ない方法でこれらの要件を満たすには、ソリューションアーキテクトはどうすべきですか？高パフォーマンスなアーキテクチャの設計
問題
ある企業は、独自開発アプリケーションのログファイルを分析する必要があります。ログは Amazon S3 バケットに JSON 形式で保存されています。クエリは単純で、オンデマンドで実行されます。ソリューションアーキテクトは、既存アーキテクチャへの変更を最小限にして分析を行う必要があります。 最も運用上のオーバーヘッドが少ない方法でこれらの要件を満たすには、ソリューションアーキテクトはどうすべきですか？

選択肢と解説

  • 1
    Amazon Redshift を使ってすべての内容を1か所にロードし、必要に応じて SQL クエリを実行する。
  • 2
    Amazon CloudWatch Logs を使ってログを保存し、Amazon CloudWatch コンソールから必要に応じて SQL クエリを実行する。
  • ✓
    Amazon Athena を Amazon S3 に対して直接使用し、必要に応じてクエリを実行する。
  • 4
    AWS Glue でログをカタログ化し、Amazon EMR 上の一時的な Apache Spark クラスターで SQL クエリを実行する。

解説

【正解】C

【0からの解説】
Amazon Athena は、S3 に保存されたデータに対して標準 SQL で直接クエリを実行できるサーバーレスの分析サービスです。あらかじめデータを別の場所へ移動したり、サーバーやクラスターを用意・管理したりする必要が一切ありません。本問ではログが既に S3 にあり、クエリも単純でオンデマンド(必要なときだけ)なので、Athena を S3 に向けて使うだけで要件を満たせます。サーバーレスゆえインフラ管理が不要で、既存アーキテクチャへの変更も最小限となり、運用上のオーバーヘッドが最も小さくなります。

【誤りの選択肢】
A：Amazon Redshift はデータウェアハウスで、クエリ前にデータのロードが必要なうえクラスターの管理も伴います。単純なオンデマンド分析には過剰で、運用負荷が増えます。
B：Amazon CloudWatch Logs はアプリやインフラのログ監視用サービスで、S3 上に既にある汎用ログに対して標準 SQL を直接実行する仕組みではありません。
D：AWS Glue と Amazon EMR(Spark) の組み合わせは、ETL やビッグデータ処理向けでクラスターの構築・管理を伴います。単純なクエリには重く、運用負荷が大きくなります。

【参考】
Amazon Athena とは
Amazon Athena(製品ページ)
この問題のページを開く →
問題 2これらの要件を最もコスト効率よく満たすソリューションはどれですか？コストを最適化したアーキテクチャの設計
問題
ある企業は、オンプレミスのネットワーク接続ストレージ(NAS)システムから 600 TB のデータを AWS クラウドへ転送する必要があります。データ転送は 2 週間以内に完了しなければなりません。データは機密性が高く、転送中に暗号化されている必要があります。企業のインターネット接続はアップロード速度 100 Mbps をサポートしています。 これらの要件を最もコスト効率よく満たすソリューションはどれですか？

選択肢と解説

  • 1
    Amazon S3 のマルチパートアップロード機能を使い、HTTPS でファイルを転送する。
  • 2
    オンプレミスの NAS システムと最寄りの AWS リージョンの間に VPN 接続を作成し、その VPN 接続でデータを転送する。
  • ✓
    AWS Snow Family コンソールから AWS Snowball Edge Storage Optimized デバイスを複数台注文し、それらのデバイスでデータを Amazon S3 へ転送する。
  • 4
    企業の拠点と最寄りの AWS リージョンの間に 10 Gbps の AWS Direct Connect 接続をセットアップし、その上に VPN 接続を通してデータをリージョンへ転送し Amazon S3 に保存する。

解説

【正解】C

【0からの解説】
まず転送量と回線速度を見積もります。100 Mbps の回線で 600 TB を送ると、理論上の最良ケースでも約 555 日かかり、2 週間にはとうてい収まりません。このように大容量データを限られた回線で短期間に運ぶ場合の定番が AWS Snowball Edge です。物理デバイスを取り寄せてオンプレミスでデータをコピーし、AWS へ郵送して S3 に取り込みます。デバイス内のデータは暗号化され、Storage Optimized は大容量転送向けで、複数台を並行利用すれば 600 TB を 2 週間以内に処理できます。専用線敷設のような高額・長納期の手段に比べてコスト効率も優れます。

【誤りの選択肢】
A：S3 マルチパートアップロードは便利ですが、ボトルネックは 100 Mbps の回線そのものです。アップロード方式を工夫しても 2 週間では到底完了しません。
B：VPN 接続もインターネット回線(100 Mbps)を経由するため、転送時間の問題は解決せず期限に間に合いません。
D：Direct Connect は専用線の手配・敷設に数週間〜数か月かかるのが一般的で、2 週間の期限に間に合わず、初期コストも高くつきます。

【参考】
AWS Snowball Edge とは
AWS Snow ファミリー
この問題のページを開く →
問題 3(2つ選択してください。弾力性に優れたアーキテクチャの設計
問題
ある企業は、Amazon EC2 インスタンス群の上で 3 層構成の e コマースアプリケーションをホストしています。インスタンスは Application Load Balancer(ALB)の背後にある Auto Scaling グループ内で稼働しています。すべての e コマースデータは Amazon RDS for MariaDB のマルチ AZ DB インスタンスに保存されています。 企業はトランザクション中の顧客セッション管理を最適化したいと考えています。アプリケーションはセッションデータを永続的に(durably)保存しなければなりません。 これらの要件を満たすソリューションはどれですか？(2つ選択してください。)

選択肢と解説

  • 1
    ALB でスティッキーセッション機能(セッションアフィニティ)を有効にする。
  • ✓
    顧客のセッション情報を保存するために Amazon DynamoDB テーブルを使用する。
  • 3
    ユーザーのセッション情報を管理するために Amazon Cognito ユーザープールをデプロイする。
  • ✓
    顧客のセッション情報を保存するために Amazon ElastiCache for Redis クラスターをデプロイする。
  • 5
    ユーザーのセッション情報を管理するために、アプリケーションで AWS Systems Manager Application Manager を使用する。

解説

【正解】B、D

【0からの解説】
3 層の Web アプリでセッション(ログイン状態やカート内容など)を扱うとき、各 EC2 インスタンスのメモリにセッションを持たせると、インスタンスが入れ替わるとセッションが失われます。これを避ける定番が「外部のデータストアにセッションを保存する」設計です。本問は「セッションデータを永続的に保存する」ことを明確に要求しているため、データを実際に保持できるストアを選びます。
・Amazon DynamoDB(B)はフルマネージドの NoSQL で、低レイテンシかつ高い耐久性でセッションデータを保存でき、セッションストアとして広く使われます。
・Amazon ElastiCache for Redis(D)はインメモリで高速なうえ、レプリケーションや永続化機能を備え、AWS が推奨する代表的なセッション外部化の手段です。
どちらもインスタンスから独立してセッションを保持するため、スケールイン/アウトしてもセッションが維持されます。

【誤りの選択肢】
A：ALB のスティッキーセッションは同じユーザーを同じインスタンスに固定するだけで、セッションデータ自体をどこかに保存するものではありません。そのインスタンスが落ちればセッションは失われ、「永続的に保存」という要件を満たしません。
C：Amazon Cognito はユーザーのサインアップ/認証(ID 管理)を担うサービスで、アプリのトランザクション用セッションデータを汎用的に保存する用途には合いません。
E：AWS Systems Manager にセッションデータを永続保存する仕組みはありません(Application Manager は運用リソースの可視化・管理用)。要件と無関係です。

【参考】
ElastiCache でのセッション管理(AWS データベースブログ)
Amazon DynamoDB とは
この問題のページを開く →
問題 4(2つ選択してください。セキュアなアーキテクチャの設計
問題
ある病院は、患者から症状を収集する新しいアプリケーションを設計しています。病院はアーキテクチャに Amazon Simple Queue Service(Amazon SQS)と Amazon Simple Notification Service(Amazon SNS)を使うことを決めました。 ソリューションアーキテクトはインフラ設計をレビューしています。データは保存時(at rest)および転送時(in transit)に暗号化されなければなりません。データにアクセスできるのは病院の認可された担当者のみに限られます。 これらの要件を満たすために、ソリューションアーキテクトが取るべき手順の組み合わせはどれですか？(2つ選択してください。)

選択肢と解説

  • 1
    SQS コンポーネントでサーバー側暗号化を有効にする。デフォルトのキーポリシーを更新し、認可されたプリンシパルの集合にキーの使用を制限する。
  • ✓
    AWS Key Management Service(AWS KMS)のカスタマーマネージドキーを使って SNS コンポーネントでサーバー側暗号化を有効にする。キーポリシーを適用し、認可されたプリンシパルの集合にキーの使用を制限する。
  • 3
    SNS コンポーネントで暗号化を有効にする。デフォルトのキーポリシーを更新し、認可されたプリンシパルの集合にキーの使用を制限する。トピックポリシーで TLS による暗号化された接続のみを許可する条件を設定する。
  • ✓
    AWS Key Management Service(AWS KMS)のカスタマーマネージドキーを使って SQS コンポーネントでサーバー側暗号化を有効にする。キーポリシーを適用し、認可されたプリンシパルの集合にキーの使用を制限する。キューポリシーで TLS による暗号化された接続のみを許可する条件を設定する。
  • 5
    AWS Key Management Service(AWS KMS)のカスタマーマネージドキーを使って SQS コンポーネントでサーバー側暗号化を有効にする。IAM ポリシーを適用し、認可されたプリンシパルの集合にキーの使用を制限する。キューポリシーで TLS による暗号化された接続のみを許可する条件を設定する。

解説

【正解】B、D

【0からの解説】
要件は3つです。(1)保存時暗号化、(2)転送時暗号化、(3)認可された担当者だけがアクセスできること。
(1)保存時暗号化は、SQS と SNS の両方でサーバー側暗号化(SSE)を有効にすれば実現できます。ここで KMS の「カスタマーマネージドキー(CMK)」を使うと、誰がそのキーを使えるかを「キーポリシー」で細かく制御でき、認可されたプリンシパルだけに限定できます(=要件3も満たす)。
(2)転送時暗号化は、キューポリシー/トピックポリシーに「aws:SecureTransport が true(=TLS)」の場合のみ許可する条件を入れることで、暗号化されていない接続を拒否できます。
したがって、SNS 側を CMK で暗号化しキーポリシーで制限する B と、SQS 側を CMK で暗号化しキーポリシーで制限したうえキューポリシーで TLS 強制する D の組み合わせが、SQS と SNS の双方をカバーしつつ全要件を満たします。

【誤りの選択肢】
A：CMK ではなく「デフォルトのキーポリシー」を更新する前提で、認可プリンシパルへの制限が CMK ほど厳密に管理できず、さらに TLS 強制(転送時暗号化)の設定がありません。
C：SNS について TLS 強制まで含む点は良いものの、暗号化に CMK を明示せずデフォルトキーポリシーの更新としており、B のように CMK + キーポリシーで認可を厳密に制御する構成のほうが要件に適合します。SQS 側を担保する D と組み合わせるべきは、SNS 側を CMK で固める B です。
E：キーの使用制限を「IAM ポリシー」で行うとしていますが、KMS キーの使用可否を制御する正しい場所は「キーポリシー」です(キーポリシーが KMS アクセス制御の基盤)。この点が誤りです。

【参考】
Amazon SQS のサーバー側暗号化(SSE)
KMS のキーポリシー
この問題のページを開く →
問題 5最も運用上のオーバーヘッドが少ない方法でこれらの要件を満たすソリューションはどれですか？セキュアなアーキテクチャの設計
問題
ある企業は、自社のデータを Amazon S3 バケットへ移行する計画を立てています。データは S3 バケットに保存される際に暗号化されている必要があります。さらに、暗号化キーは毎年自動的にローテーションされなければなりません。 最も運用上のオーバーヘッドが少ない方法でこれらの要件を満たすソリューションはどれですか？

選択肢と解説

  • ✓
    データを S3 バケットへ移行する。Amazon S3 マネージド暗号化キー(SSE-S3)によるサーバー側暗号化を使用する。SSE-S3 暗号化キーの組み込みキーローテーション動作を利用する。
  • 2
    AWS Key Management Service(AWS KMS)のカスタマーマネージドキーを作成する。自動キーローテーションを有効にする。S3 バケットのデフォルト暗号化動作をそのカスタマーマネージド KMS キーを使うよう設定する。データを S3 バケットへ移行する。
  • 3
    AWS Key Management Service(AWS KMS)のカスタマーマネージドキーを作成する。S3 バケットのデフォルト暗号化動作をそのカスタマーマネージド KMS キーを使うよう設定する。データを S3 バケットへ移行する。毎年手動で KMS キーをローテーションする。
  • 4
    データを S3 バケットへ移行する前に、カスタマーキーマテリアルでデータを暗号化する。キーマテリアルなしの AWS Key Management Service(AWS KMS)キーを作成する。カスタマーキーマテリアルをその KMS キーにインポートする。自動キーローテーションを有効にする。

解説

【正解】A

【0からの解説】
S3 のサーバー側暗号化(SSE-S3)は、Amazon S3 が暗号化キーの作成・管理・ローテーションをすべて自動で行ってくれる方式です。利用者はキーの管理を一切意識せず、保存データは自動的に暗号化されます。キーローテーションも AWS が自動的に行うため、「保存時に暗号化」「キーを毎年自動ローテーション」という両要件を、設定一つで・追加の管理作業なしで満たせます。よって運用上のオーバーヘッドが最も小さい選択肢です。

【誤りの選択肢】
B：KMS のカスタマーマネージドキー(CMK)で自動ローテーションも実現できますが、キーの作成・キーポリシー管理・コスト管理など SSE-S3 に比べて運用作業が増えます。要件は単に「暗号化+年次自動ローテーション」だけなので、CMK は過剰で運用負荷が大きくなります。
C：CMK を使いつつローテーションを「毎年手動」で行うため、運用担当者が忘れずに作業し続ける必要があり、自動化されておらず最も手間がかかります。
D：自前のキーマテリアルをインポートする方式(BYOK)は最も複雑です。さらにインポートしたキーマテリアルを持つ KMS キーは AWS による自動ローテーションの対象外となるため、要件(毎年の自動ローテーション)を満たせず、運用も煩雑です。

【参考】
Amazon S3 のサーバー側暗号化(SSE-S3)
S3 のデフォルト暗号化
この問題のページを開く →
問題 6最も運用上のオーバーヘッドが少ない方法でこれらの要件を満たすソリューションはどれですか？コストを最適化したアーキテクチャの設計
問題
ある企業は、開発用 AWS アカウントで稼働する複数の Amazon RDS DB インスタンスを保有しています。すべてのインスタンスには、開発リソースであることを示すタグが付けられています。企業は、開発用 DB インスタンスを営業時間中のみスケジュールに従って稼働させたいと考えています。 最も運用上のオーバーヘッドが少ない方法でこれらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    停止すべき RDS インスタンスを特定するために Amazon CloudWatch アラームを作成する。RDS インスタンスを起動・停止する AWS Lambda 関数を作成する。
  • 2
    起動・停止すべき RDS インスタンスを特定するために AWS Trusted Advisor レポートを作成する。RDS インスタンスを起動・停止する AWS Lambda 関数を作成する。
  • 3
    RDS インスタンスを起動・停止する AWS Systems Manager State Manager のアソシエーションを作成する。
  • ✓
    AWS Lambda 関数を呼び出して RDS インスタンスを起動・停止する Amazon EventBridge ルールを作成する。

解説

【正解】D

【0からの解説】
「特定の時刻になったら処理を実行する(=スケジュール実行)」という要件には、Amazon EventBridge のスケジュールルールが最適です。EventBridge ルールで「平日 9 時に起動」「平日 18 時に停止」のようなスケジュールを定義し、ターゲットとして AWS Lambda 関数を呼び出して RDS インスタンスを起動・停止させれば、サーバーレスかつ少ない構成要素で自動化できます。タグで開発リソースを絞り込んで対象を制御することも容易で、運用上のオーバーヘッドが最も小さくなります。

【誤りの選択肢】
A：CloudWatch アラームはメトリクスのしきい値超過を検知する仕組みで、「営業時間というスケジュール」を表現するのには本来不向きです。スケジュール起点の処理には EventBridge が適切です。
B：AWS Trusted Advisor はコスト最適化やセキュリティのベストプラクティスを助言するサービスで、決まった時刻に起動・停止すべきインスタンスを判定する用途には使えません。
C：State Manager は構成(状態)を一定に保つための機能で、特定時刻に起動/停止を切り替えるスケジュール実行の主目的には合致せず、本問のシンプルな時間制御には EventBridge + Lambda のほうが素直です。

【参考】
Amazon EventBridge のスケジュールルール
Amazon EventBridge(製品ページ)
この問題のページを開く →
問題 7最も運用上のオーバーヘッドが少ない方法でこれらの要件を満たすソリューションはどれですか？高パフォーマンスなアーキテクチャの設計
問題
ある e コマース企業は、AWS 上で「1 日 1 商品」のセールサイトを立ち上げたいと考えています。各日にはちょうど 1 つの商品が 24 時間限定でセール対象となります。企業はピーク時に毎時数百万件のリクエストをミリ秒単位のレイテンシで処理できるようにしたいと考えています。 最も運用上のオーバーヘッドが少ない方法でこれらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    Amazon S3 を使ってサイト全体を別々の S3 バケットでホストする。Amazon CloudFront ディストリビューションを追加する。S3 バケットをディストリビューションのオリジンに設定する。注文データは Amazon S3 に保存する。
  • 2
    サイト全体を、複数のアベイラビリティーゾーンにまたがる Auto Scaling グループで稼働する Amazon EC2 インスタンスにデプロイする。Application Load Balancer(ALB)を追加してサイトのトラフィックを分散する。バックエンド API 用にもう 1 つの ALB を追加する。データは Amazon RDS for MySQL に保存する。
  • 3
    アプリ全体をコンテナで稼働するよう移行する。コンテナを Amazon Elastic Kubernetes Service(Amazon EKS)上でホストする。Kubernetes Cluster Autoscaler を使ってトラフィックの急増に応じてポッド数を増減させる。データは Amazon RDS for MySQL に保存する。
  • ✓
    Amazon S3 バケットを使ってサイトの静的コンテンツをホストする。Amazon CloudFront ディストリビューションをデプロイする。S3 バケットをオリジンに設定する。バックエンド API には Amazon API Gateway と AWS Lambda 関数を使用する。データは Amazon DynamoDB に保存する。

解説

【正解】D

【0からの解説】
「毎時数百万リクエスト」「ミリ秒レイテンシ」「運用オーバーヘッド最小」を同時に満たすには、フルサーバーレス + CDN の構成が最適です。
・静的コンテンツ(HTML/CSS/画像など)は S3 に置き、CloudFront(CDN)で世界中のエッジから低レイテンシ配信。キャッシュにより大量アクセスにも余裕で耐えられます。
・動的なバックエンド API は API Gateway + Lambda で受け、サーバー管理なしに自動でスケールします。
・注文データは DynamoDB に保存。1 桁ミリ秒のレイテンシで、桁違いのリクエスト数にもシームレスにスケールするフルマネージド NoSQL です。
サーバーやクラスターの管理が一切不要で、トラフィック急増にも自動対応するため、運用負荷が最小になります。

【誤りの選択肢】
A：注文(動的なデータ書き込み)を S3 に保存し、API 層が存在しません。S3 は静的ホスティング向けで、注文処理のようなアプリケーションロジックを担えず、要件を満たせません。
B：EC2 + ALB + RDS は自前でインスタンスや DB をスケール・運用する必要があり、サーバーレス構成に比べて運用オーバーヘッドが大きくなります。RDS は超大量の同時アクセスでボトルネックにもなりやすいです。
C：EKS(Kubernetes)はクラスターやノードの管理が必要で運用負荷が高く、RDS も極端なスパイクに対してはスケールしにくいです。"運用最小"の要件に反します。

【参考】
CloudFront + S3 で静的サイト配信
API Gateway + Lambda(サーバーレス)
Amazon DynamoDB とは
この問題のページを開く →
問題 8（3つ選択してください。高パフォーマンスなアーキテクチャの設計
問題
ある企業が、オンプレミスのアプリケーションを AWS へ移行しようとしています。同社はソリューションとして Amazon Redshift を使用したいと考えています。 このシナリオで Amazon Redshift に適したユースケースはどれですか？（3つ選択してください。）

選択肢と解説

  • ✓
    従来型・コンテナ化・イベント駆動型のアプリケーションからデータにアクセスするためのデータ API をサポートする。
  • ✓
    クライアントサイド暗号化とサーバーサイド暗号化の両方をサポートする。
  • ✓
    アプリケーションが稼働していない指定された時間帯に分析ワークロードを構築する。
  • 4
    バックエンドデータベースへの負荷を軽減するためにデータをキャッシュする。
  • 5
    ペタバイト規模のデータと毎分数千万件のリクエストをサポートするためにグローバルにスケールする。
  • 6
    AWS マネジメントコンソールを使用してクラスターのセカンダリレプリカを作成する。

解説

【正解】A、B、C

【0からの解説】
Amazon Redshift は、ペタバイト規模のデータを高速に分析できるフルマネージドのデータウェアハウスです。本問は Redshift に「適した」ユースケースを3つ選ぶ問題です。

A：Redshift には「Redshift Data API」があり、ドライバーや永続的な接続を管理せずに、従来型・コンテナ化・イベント駆動型（Lambda など）のアプリケーションから HTTPS 経由でデータにアクセスできます。これは Redshift の正当なユースケースです。
B：Redshift はクライアントサイド暗号化（データをアップロード前に暗号化）とサーバーサイド暗号化（AWS KMS など）の両方をサポートします。機密データの保護に適しています。
C：Redshift は分析（OLAP）ワークロード向けであり、業務アプリが稼働していない時間帯にまとめてバッチ分析を実行する、といった使い方に向いています。

【誤りの選択肢】
D：データのキャッシュによりバックエンド DB の負荷を軽減するのは ElastiCache（Redis/Memcached）の役割であり、データウェアハウスである Redshift の用途ではありません。
E：「ペタバイト規模かつ毎分数千万件のリクエスト」という超高スループットの低レイテンシーアクセスは DynamoDB のようなキーバリュー型 NoSQL の特性です。Redshift は分析クエリ向けで、このようなリクエスト処理には適しません。
F：Redshift ではマネジメントコンソールから「クラスターのセカンダリレプリカ」を作成するという機能はありません。冗長性はクラスタースナップショットや別 Region への自動コピー等で実現します。

【参考】
Amazon Redshift とは
Amazon Redshift Data API の使用
Amazon Redshift のデータベース暗号化
この問題のページを開く →
問題 9これらの要件を満たすソリューションはどれですか？セキュアなアーキテクチャの設計
問題
ある企業がアプリケーションを AWS に移行しています。これらのアプリケーションは複数の異なるアカウントにデプロイされています。同社は AWS Organizations を使用してアカウントを一元管理しています。同社のセキュリティチームは、すべてのアカウントにまたがるシングルサインオン（SSO）ソリューションを必要としています。同社は引き続き、オンプレミスの自己管理型 Microsoft Active Directory でユーザーとグループを管理しなければなりません。 これらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    AWS SSO コンソールから AWS Single Sign-On（AWS SSO）を有効化する。AWS Directory Service for Microsoft Active Directory を使用し、一方向のフォレスト信頼または一方向のドメイン信頼を作成して、同社の自己管理型 Microsoft Active Directory と AWS SSO を接続する。
  • ✓
    AWS SSO コンソールから AWS Single Sign-On（AWS SSO）を有効化する。AWS Directory Service for Microsoft Active Directory を使用し、双方向のフォレスト信頼を作成して、同社の自己管理型 Microsoft Active Directory と AWS SSO を接続する。
  • 3
    AWS Directory Service を使用する。同社の自己管理型 Microsoft Active Directory との双方向信頼関係を作成する。
  • 4
    オンプレミスに ID プロバイダー（IdP）をデプロイする。AWS SSO コンソールから AWS Single Sign-On（AWS SSO）を有効化する。

解説

【正解】B

【0からの解説】
AWS SSO（現 AWS IAM Identity Center）は、AWS Organizations 配下の複数アカウントへのシングルサインオンを実現するサービスです。本問では「オンプレミスの自己管理型 AD で引き続きユーザー／グループを管理する」ことが条件です。

この場合、AWS Directory Service for Microsoft Active Directory（AWS Managed Microsoft AD）をオンプレミス AD と「信頼関係」で接続し、その AWS Managed Microsoft AD を AWS SSO の ID ソースとして使用します。AWS SSO がオンプレミス AD のユーザーを認証・参照できるようにするには、AWS Managed Microsoft AD とオンプレミス AD の間に「双方向のフォレスト信頼」が必要です。これにより、ユーザー管理はオンプレミスのまま、AWS 側の全アカウントへ SSO できます。

【誤りの選択肢】
A：一方向の信頼では、AWS SSO がオンプレミス AD のユーザーを認証する際に必要な双方向の信頼関係が成立しません。AWS Managed Microsoft AD と AWS SSO の連携には双方向フォレスト信頼が要件です。
C：「AWS Directory Service を使用する」だけでは AWS SSO による複数アカウント横断の SSO を有効化する手順が示されておらず、要件（Organizations 全体への SSO）を満たす構成として不完全です。
D：オンプレミスに別途 IdP を立てる構成は運用が複雑になり、また「自己管理型 AD でユーザー管理を継続する」という要件に対し、AD と AWS SSO を直接信頼で結ぶ B の方が適切かつ要件に合致します。

【参考】
AWS IAM Identity Center（旧 AWS SSO）とは
Active Directory を ID ソースとして接続する
この問題のページを開く →
問題 10これらの要件を満たすために、ソリューションアーキテクトは何をすべきですか？高パフォーマンスなアーキテクチャの設計
問題
あるグローバル企業が、Application Load Balancer（ALB）の背後にある Amazon EC2 インスタンス上で Web アプリケーションをホストしています。この Web アプリケーションには静的データと動的データがあります。同社は静的データを Amazon S3 バケットに保存しています。同社は静的データと動的データの両方について、パフォーマンスを向上させレイテンシーを削減したいと考えています。同社は Amazon Route 53 に登録した独自のドメイン名を使用しています。 これらの要件を満たすために、ソリューションアーキテクトは何をすべきですか？

選択肢と解説

  • ✓
    S3 バケットと ALB の両方をオリジンとする Amazon CloudFront ディストリビューションを作成する。CloudFront ディストリビューションにトラフィックをルーティングするよう Route 53 を構成する。
  • 2
    ALB をオリジンとする Amazon CloudFront ディストリビューションを作成する。S3 バケットをエンドポイントとする AWS Global Accelerator の標準アクセラレーターを作成する。CloudFront ディストリビューションにトラフィックをルーティングするよう Route 53 を構成する。
  • 3
    S3 バケットをオリジンとする Amazon CloudFront ディストリビューションを作成する。ALB と CloudFront ディストリビューションをエンドポイントとする AWS Global Accelerator の標準アクセラレーターを作成する。アクセラレーターの DNS 名を指すカスタムドメイン名を作成し、それを Web アプリケーションのエンドポイントとして使用する。
  • 4
    ALB をオリジンとする Amazon CloudFront ディストリビューションを作成する。S3 バケットをエンドポイントとする AWS Global Accelerator の標準アクセラレーターを作成する。2つのドメイン名を作成し、一方を動的コンテンツ用に CloudFront の DNS 名へ、もう一方を静的コンテンツ用にアクセラレーターの DNS 名へ向ける。これらのドメイン名を Web アプリケーションのエンドポイントとして使用する。

解説

【正解】A

【0からの解説】
Amazon CloudFront は、世界中のエッジロケーションにコンテンツをキャッシュ・配信する CDN（コンテンツ配信ネットワーク）です。静的データ（S3）と動的データ（ALB 背後の EC2）の両方を高速化したい場合、1つの CloudFront ディストリビューションに「S3 バケット」と「ALB」の複数オリジンを設定し、パスパターン（ビヘイビア）でリクエストを振り分けるのが最もシンプルかつ効果的です。静的コンテンツはエッジでキャッシュされ、動的コンテンツも最適化された AWS ネットワーク経由で配信されるため、両方のレイテンシーが下がります。Route 53 で独自ドメインを CloudFront に向ければ完成です。

【誤りの選択肢】
B：Global Accelerator は TCP/UDP のネットワーク高速化サービスで、S3 を直接エンドポイントにすることはできず、静的コンテンツ配信のキャッシュにも不向きです。構成として誤りです。
C：Global Accelerator のエンドポイントに「CloudFront ディストリビューション」を指定することはできません。また静的・動的の両方を最適に扱う構成として不自然で過剰です。
D：B と同様に S3 を Global Accelerator のエンドポイントにはできません。さらに静的・動的でドメインを分ける必要はなく、1つの CloudFront で複数オリジンを扱う方がシンプルです。

【参考】
Amazon CloudFront（CDN）
複数オリジンの使用（CloudFront）
この問題のページを開く →
問題 11これらの要件を満たすストレージオプションはどれですか？コストを最適化したアーキテクチャの設計
問題
あるソリューションアーキテクトが、新しいデジタルメディアアプリケーションのストレージアーキテクチャを Amazon S3 を使って設計しています。メディアファイルはアベイラビリティーゾーンの障害に対して耐性がなければなりません。一部のファイルは頻繁にアクセスされますが、他のファイルは予測できないパターンでまれにしかアクセスされません。ソリューションアーキテクトは、メディアファイルの保存と取得のコストを最小化する必要があります。 これらの要件を満たすストレージオプションはどれですか？

選択肢と解説

  • 1
    S3 Standard
  • ✓
    S3 Intelligent-Tiering
  • 3
    S3 Standard-Infrequent Access（S3 Standard-IA）
  • 4
    S3 One Zone-Infrequent Access（S3 One Zone-IA）

解説

【正解】B

【0からの解説】
ポイントは2つです。(1) アベイラビリティーゾーン（AZ）障害に耐える＝複数 AZ にデータを冗長化するストレージクラスが必要、(2) アクセスパターンが予測不能（頻繁／まれが混在し変動する）。

S3 Intelligent-Tiering は、オブジェクトごとのアクセス状況を自動的に監視し、頻繁にアクセスされるものは高速アクセス階層、しばらくアクセスのないものは低頻度アクセス階層へ自動移動してコストを最適化します。取得料金もかからず、複数 AZ に冗長化されるため AZ 障害にも耐えます。アクセスパターンが読めない本問には最適です。

【誤りの選択肢】
A：S3 Standard は複数 AZ 冗長で耐障害性はありますが、まれにしかアクセスされないファイルにも高めのストレージ料金がかかり、コスト最小化の要件に反します。
C：S3 Standard-IA は低頻度アクセス向けですが、頻繁にアクセスされるファイルには取得料金が積み重なりコスト増になります。アクセスパターンが予測不能な本問では Intelligent-Tiering の方が適切です。
D：S3 One Zone-IA は単一 AZ にしか保存されないため、AZ 障害に耐えるという要件を満たせません。

【参考】
S3 ストレージクラス
S3 Intelligent-Tiering
この問題のページを開く →
問題 12この要件を満たすために、ソリューションアーキテクトは何をすべきですか？弾力性に優れたアーキテクチャの設計
問題
ある企業が Amazon EC2 インスタンス上でバッチアプリケーションを実行しています。このアプリケーションは複数の Amazon RDS データベースで構成されるバックエンドを持っています。アプリケーションはデータベースに対して大量の読み取りを発生させています。ソリューションアーキテクトは、高可用性を確保しつつデータベースの読み取り回数を削減する必要があります。 この要件を満たすために、ソリューションアーキテクトは何をすべきですか？

選択肢と解説

  • ✓
    Amazon RDS リードレプリカを追加する。
  • 2
    Amazon ElastiCache for Redis を使用する。
  • 3
    Amazon Route 53 の DNS キャッシュを使用する。
  • 4
    Amazon ElastiCache for Memcached を使用する。

解説

【正解】A

【0からの解説】
RDS のリードレプリカは、プライマリ DB の読み取り専用コピーを作成し、読み取りクエリをそちらに分散させることで、プライマリへの読み取り負荷を下げる仕組みです。これにより読み取り回数（プライマリ側）を削減できます。さらに、リードレプリカは別の AZ に配置でき、障害時には昇格させてスタンドアロン DB にできるため、可用性の向上にも寄与します。本問の「読み取り削減＋高可用性」を1つの仕組みで満たせるのがリードレプリカです。

【誤りの選択肢】
B：ElastiCache for Redis はキャッシュで読み取り負荷を下げられますが、アプリ側のキャッシュ実装が必要で、本問が直接問う「RDS 自体の読み取り負荷分散と高可用性」を満たす最も適切な選択肢はリードレプリカです。なお Redis はレプリケーション構成も可能ですが、設問はデータベース読み取りの削減手段としてリードレプリカを想定しています。
C：Route 53 の DNS キャッシュは名前解決のキャッシュであり、データベースの読み取り負荷とは無関係です。
D：ElastiCache for Memcached はマルチ AZ のレプリケーション／フェイルオーバーをサポートせず、高可用性の要件を満たしにくいため不適切です。

【参考】
Amazon RDS リードレプリカの使用
Amazon RDS（高可用性）
この問題のページを開く →
問題 13（2つ選択してください。セキュアなアーキテクチャの設計
問題
ある企業が、従業員データを階層的な構造化された関係で保存するアプリケーションを作成したいと考えています。同社は、トラフィックの多い従業員データへのクエリに対して最小限のレイテンシーで応答する必要があり、機密データを保護しなければなりません。さらに同社は、従業員データに金融情報が含まれている場合、毎月メールメッセージを受け取る必要があります。 これらの要件を満たすために、ソリューションアーキテクトはどの手順の組み合わせを実行すべきですか？（2つ選択してください。）

選択肢と解説

  • 1
    Amazon Redshift を使用して従業員データを階層構造で保存する。毎月データを Amazon S3 にアンロードする。
  • ✓
    Amazon DynamoDB を使用して従業員データを階層構造で保存する。毎月データを Amazon S3 にエクスポートする。
  • 3
    AWS アカウントで Amazon Macie を構成する。Macie を Amazon EventBridge と統合し、毎月のイベントを AWS Lambda に送信する。
  • 4
    Amazon Athena を使用して Amazon S3 内の従業員データを分析する。Athena を Amazon QuickSight と統合して分析ダッシュボードを公開し、ユーザーと共有する。
  • ✓
    AWS アカウントで Amazon Macie を構成する。Macie を Amazon EventBridge と統合し、Amazon Simple Notification Service（Amazon SNS）サブスクリプション経由で毎月の通知を送信する。

解説

【正解】B、E

【0からの解説】
要件は3つです。(1) 従業員データを階層構造で保存し、(2) 高トラフィックなクエリに低レイテンシーで応答、(3) 金融情報が含まれていれば毎月メールで通知。

B：Amazon DynamoDB はフルマネージドの NoSQL データベースで、単一桁ミリ秒の低レイテンシーと高スループットを提供します。パーティションキー／ソートキーの設計により階層的な関係を表現でき、高トラフィックなクエリにも強いため要件 (1)(2) に最適です。毎月 S3 へエクスポートすれば分析にも回せます。
E：Amazon Macie は機械学習で S3 内の機密データ（個人情報や金融情報など）を検出するサービスです。Macie の検出結果を EventBridge と統合し、SNS サブスクリプション経由で通知すれば「金融情報があれば毎月メールで通知」という要件 (3) を満たせます。SNS はメール配信をネイティブにサポートします。

【誤りの選択肢】
A：Redshift はデータウェアハウスで、高トラフィックな低レイテンシークエリ（キーバリュー的アクセス）には不向きです。階層構造の保存先としても DynamoDB の方が適切です。
C：Macie + EventBridge までは良いものの、送信先が Lambda では「メールメッセージを受け取る」という要件を直接満たしません。メール通知には SNS が適切です。
D：Athena + QuickSight はダッシュボードによる可視化であり、機密（金融）データの検出やメール通知という要件を満たしません。

【参考】
Amazon DynamoDB
Amazon Macie とは
Amazon SNS（通知）
この問題のページを開く →
問題 14最も少ない運用上のオーバーヘッドでこれらの要件を満たすソリューションはどれですか？セキュアなアーキテクチャの設計
問題
ある企業が、アプリケーションをサーバーレスソリューションに移行したいと考えています。このサーバーレスソリューションは、SQL を使用して既存および新規のデータを分析する必要があります。同社はデータを Amazon S3 バケットに保存しています。データは暗号化が必要で、別の AWS リージョンにレプリケートされなければなりません。 最も少ない運用上のオーバーヘッドでこれらの要件を満たすソリューションはどれですか？

選択肢と解説

  • 1
    新しい S3 バケットを作成する。データを新しい S3 バケットにロードする。S3 クロスリージョンレプリケーション（CRR）を使用して、暗号化されたオブジェクトを別リージョンの S3 バケットにレプリケートする。AWS KMS マルチリージョンキーによるサーバーサイド暗号化（SSE-KMS）を使用する。Amazon Athena を使用してデータをクエリする。
  • 2
    新しい S3 バケットを作成する。データを新しい S3 バケットにロードする。S3 クロスリージョンレプリケーション（CRR）を使用して、暗号化されたオブジェクトを別リージョンの S3 バケットにレプリケートする。AWS KMS マルチリージョンキーによるサーバーサイド暗号化（SSE-KMS）を使用する。Amazon RDS を使用してデータをクエリする。
  • ✓
    データを既存の S3 バケットにロードする。S3 クロスリージョンレプリケーション（CRR）を使用して、暗号化されたオブジェクトを別リージョンの S3 バケットにレプリケートする。Amazon S3 マネージド暗号化キーによるサーバーサイド暗号化（SSE-S3）を使用する。Amazon Athena を使用してデータをクエリする。
  • 4
    データを既存の S3 バケットにロードする。S3 クロスリージョンレプリケーション（CRR）を使用して、暗号化されたオブジェクトを別リージョンの S3 バケットにレプリケートする。Amazon S3 マネージド暗号化キーによるサーバーサイド暗号化（SSE-S3）を使用する。Amazon RDS を使用してデータをクエリする。

解説

【正解】C

【0からの解説】
要件は「サーバーレス」「SQL で S3 のデータを分析」「暗号化」「別リージョンへレプリケート」「運用負荷最小」です。

サーバーレスで S3 上のデータに SQL クエリを実行できるのは Amazon Athena です（RDS はサーバー／インスタンス管理が必要でサーバーレス要件に反します）。暗号化は、最も運用負荷が小さいのが SSE-S3（Amazon S3 マネージドキー）で、キーの作成・管理が不要です。別リージョンへの複製は S3 クロスリージョンレプリケーション（CRR）で実現できます。さらに本問では「データを既存の S3 バケットにロードする」とあり、新規バケットを作ってデータを移し替える A/B より手間が少なく、運用オーバーヘッドが最小です。

【誤りの選択肢】
A：Athena 採用は正しいものの、わざわざ新規バケットを作成しデータを移す手順が含まれ、また SSE-KMS（マルチリージョンキー）は KMS キーの作成・管理が必要で SSE-S3 より運用負荷が増えます。最小オーバーヘッドの要件では C に劣ります。
B：RDS はサーバーレスでなくインスタンス管理が必要で、S3 上のデータを直接 SQL 分析する用途にも不向きです。新規バケット作成の手間もあります。
D：暗号化（SSE-S3）と既存バケット利用は妥当ですが、クエリに RDS を使う点がサーバーレス要件に反します。

【参考】
Amazon Athena とは
S3 のデフォルト暗号化（SSE-S3）
S3 クロスリージョンレプリケーション
この問題のページを開く →
問題 15これらの要件を満たすために、ソリューションアーキテクトは何をすべきですか？コストを最適化したアーキテクチャの設計
問題
ある企業が、AWS クラウドでコンテナ内のアプリケーションを実行したいと考えています。これらのアプリケーションはステートレスであり、基盤となるインフラストラクチャ内での中断に耐えることができます。同社は、コストと運用上のオーバーヘッドを最小化するソリューションを必要としています。 これらの要件を満たすために、ソリューションアーキテクトは何をすべきですか？

選択肢と解説

  • 1
    Amazon EC2 Auto Scaling グループ内のスポットインスタンスを使用してアプリケーションコンテナを実行する。
  • ✓
    Amazon Elastic Kubernetes Service（Amazon EKS）のマネージドノードグループ内でスポットインスタンスを使用する。
  • 3
    Amazon EC2 Auto Scaling グループ内のオンデマンドインスタンスを使用してアプリケーションコンテナを実行する。
  • 4
    Amazon Elastic Kubernetes Service（Amazon EKS）のマネージドノードグループ内でオンデマンドインスタンスを使用する。

解説

【正解】B

【0からの解説】
要件は「コンテナ」「ステートレスで中断に耐えられる」「コスト最小」「運用オーバーヘッド最小」です。

コスト最小化の観点では、スポットインスタンス（最大約90%割引）が最適です。ステートレスで中断に耐えられるため、スポットの中断リスクを許容できます。運用オーバーヘッド最小の観点では、自前で EC2 Auto Scaling グループを組んでコンテナ基盤を管理するより、EKS のマネージドノードグループを使う方が、ノードのプロビジョニング・更新・ライフサイクル管理を AWS に任せられ運用が楽です。よって「EKS マネージドノードグループ＋スポット」の組み合わせ（B）が両方の要件を満たします。

【誤りの選択肢】
A：スポットでコストは下がりますが、EC2 Auto Scaling グループ上に自前でコンテナ実行環境を構築・管理する必要があり、EKS マネージドノードグループより運用オーバーヘッドが大きくなります。
C：オンデマンドはスポットより高コストで、コスト最小化の要件に反します。さらに自前の Auto Scaling グループ管理で運用負荷も高めです。
D：EKS マネージドノードグループは運用面で良いものの、オンデマンドインスタンスはスポットより高コストで、コスト最小化の要件を満たしません。

【参考】
Amazon EKS マネージドノードグループ
Amazon EC2 スポットインスタンス
この問題のページを開く →

SAA-C03 対策のハンズオンラボ

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

Amazon S3 で静的Webサイトをホスティング
beginner・約 30 分
AWS WAF で Web アプリ(ALB)を保護する
intermediate・約 45 分
VPC のネットワーク到達性トラブルシューティング（ルートテーブル・セキュリティグループ・ネットワーク ACL）
intermediate・約 50 分
Terraform(CloudShell)で AWS インフラをデプロイ・管理する
intermediate・約 50 分
3層ネットワークの VPC を一から構築する
intermediate・約 50 分
Lambda + API Gateway + DynamoDB でサーバーレス CRUD API を作る
intermediate・約 50 分
EC2 上に CI サーバー（Jenkins）を構築し ALB 配下で公開する
intermediate・約 55 分
S3 / EBS / EFS ストレージを KMS 暗号化とアクセス制御で保護する
intermediate・約 55 分
SAA-C03 のラボを全て見る（22 件）→

SAA-C03 模擬問題集についてよくある質問

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

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

問題は何問ありますか？

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

解説は付いていますか？

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

SAA-C03 のハンズオン学習もできますか？

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