AWS SAA-C03 模擬問題 30 問 + 頻出アーキテクチャパターン10種 — 解答力を仕上げる

AWS SAA-C03 コスト最適化 完全攻略（2026-06-05 公開）までで、4 ドメインの知識が出揃いました。しかし、知識があることと、試験で正解できることは別物です。SAA-C03 は設計判断を問う試験であり、知識を「解答力」に変換する訓練が欠かせません。

この記事では、AWS SAA-C03 模擬問題 30 問に挑む前に、頻出するアーキテクチャパターンを 10 種整理します。SAA-C03 の問題の多くは、実は限られたパターンの組み合わせで解けます。パターンを先に頭に入れておけば、問題文を読んだ瞬間に「これはあの構成だ」と判断でき、選択肢を素早く絞り込めるようになります。

SAA-C03 の問題はパターンで解ける

SAA-C03 の設問は、一見すると無限のバリエーションがあるように見えます。しかし実際には、出題される構成は「定番アーキテクチャ」の変奏にすぎません。3 層ウェブアプリ、サーバーレス API、静的サイト配信——こうした典型構成を知っていれば、長文の問題文も骨格が即座に見えてきます。

逆に、パターンを知らないまま個々のサービス知識だけで挑むと、毎回ゼロから構成を考えることになり、時間も足りなくなります。65 問を 130 分で解くには、1 問あたり 2 分が目安です。パターン認識による高速化は、合格に直結する実戦スキルなのです。ここから紹介する 10 パターンを、自分の言葉で説明できるレベルまで体に入れてください。

パターンを学ぶ際のコツは、「なぜその構成になるのか」という理由までセットで覚えることです。たとえば 3 層構成で各層を分離するのは、層ごとに独立してスケールさせ、障害を局所化するためです。理由を理解していれば、問題文が少し変形しても応用が効きます。逆に「3 層＝ALB＋EC2＋RDS」と丸暗記しただけでは、サーバーレス化の要件が加わった瞬間に対応できません。AWS SAA-C03 模擬問題に取り組む前に、まず各パターンの設計意図を腹落ちさせておくことが、得点の安定につながります。

パターン① 3 層ウェブアプリケーション

最も基本的で頻出するのが 3 層構成です。プレゼンテーション層・アプリケーション層・データ層を分離し、それぞれを独立してスケールさせます。

典型的な構成は次の通りです。フロントに Application Load Balancer（ALB）を置き、複数の AZ にまたがる EC2 Auto Scaling グループへトラフィックを振り分けます。データ層には RDS を Multi-AZ 配置で置き、可用性を確保します。静的アセットは S3 と CloudFront で配信します。この構成は、可用性・スケーラビリティ・コスト効率のバランスが良く、SAA-C03 の出題の土台になります。「Web アプリの可用性とスケーラビリティを高めたい」という設問では、まずこの形を思い浮かべてください。この基本形を起点に、データ層を Aurora に置き換える、セッションを ElastiCache へ外出しする、読み取りをリードレプリカで分散する、といった変奏が次々と出題されます。土台が頭に入っていれば、変奏部分だけに集中して判断でき、解答が速く正確になります。

パターン② サーバーレス API

サーバー管理を不要にしたい、あるいはアクセスが断続的でコストを抑えたい場合の定番が、サーバーレス API です。

Amazon API Gateway がリクエストを受け、AWS Lambda が処理し、Amazon DynamoDB がデータを保持します。インフラの管理が不要で、リクエスト数に応じて自動でスケールし、使った分だけの課金で済みます。トラフィックの増減が激しいワークロードや、運用負荷を最小化したいケースで威力を発揮します。「サーバー管理をなくしたい」「アイドル時のコストをゼロにしたい」という要件は、このパターンへの誘導です。

このパターンと 3 層構成の使い分けは、SAA-C03 で頻出します。判断軸は、トラフィックの予測可能性と運用負荷の許容度です。常時一定の負荷がかかり、細かな制御が必要なら EC2 ベースの 3 層構成。トラフィックが読めず、運用を極力減らしたいならサーバーレス。問題文に「予測不能なスパイク」「運用チームが小規模」といった語が出たら、サーバーレスへの誘導サインだと捉えてください。

パターン③ 静的サイト・コンテンツ配信

静的なウェブサイトやメディア配信では、サーバーすら不要にできます。

Amazon S3 に静的ファイルを置き、Amazon CloudFront でエッジ配信します。S3 への直接アクセスは Origin Access Control（OAC）で遮断し、CloudFront 経由のみに限定するのがセキュリティ上の定石です。なお OAC は従来の OAI（Origin Access Identity）の後継にあたる現行の推奨方式であり、新規設計では OAC を選ぶのが正解です。この構成は、世界中のユーザーに低遅延で配信しつつ、サーバー運用コストをほぼゼロにできます。「静的サイトを低コストかつ高速にグローバル配信したい」なら、この形が正解になります。

パターン④ 疎結合バッチ処理

大量のジョブを非同期で処理する場面では、疎結合パターンが効きます。

Amazon SQS にジョブをため、EC2 Auto Scaling グループのワーカーがメッセージを取り出して処理します。キューの深さ（未処理メッセージ数）をメトリクスにしたスケーリングを組めば、処理待ちが溜まれば自動でワーカーが増え、捌ければ減ります。送信側と処理側が切り離されているため、片方が落ちても全体は止まりません。「大量のジョブを弾力的に・耐障害性高く処理したい」という要件の定番です。

パターン⑤ クロスリージョン災害復旧

リージョン障害に備える構成です。RTO/RPO の要件に応じて戦略が変わります。

プライマリリージョンのデータを別リージョンへ継続的にレプリケーションし、Amazon Route 53 のフェイルオーバールーティングとヘルスチェックで、障害時に自動で切り替えます。コアだけ稼働させるパイロットライト、縮小版を常時稼働させるウォームスタンバイなど、コストと復旧速度のバランスで戦略を選びます。「リージョン全体の障害に備えたい」という設問では、この構成と DR 戦略の選択がセットで問われます。

パターン⑥⑦ データレイク分析とハイブリッド接続

データ分析の定番が、データレイクパターンです。Amazon S3 をデータレイクの保管層とし、Amazon Athena で SQL クエリ、AWS Glue でデータカタログと ETL を担います。サーバーレスで、保管したデータに対して直接分析をかけられます。「大量のデータを安く貯めて、必要な時に分析したい」という要件の定番です。

オンプレミスと AWS をつなぐハイブリッド接続もパターン化されています。安定した専用線が要るなら AWS Direct Connect、手軽に暗号化接続するなら Site-to-Site VPN。両者を併用し、Direct Connect を主、VPN をバックアップにする冗長構成も頻出します。「オンプレミスと AWS を安全につなぎたい」という設問では、要件（帯域・安定性・コスト）から接続方式を選びます。

ひっかけ選択肢を見抜く 5 つの視点

SAA-C03 では、技術的に「動くが最適ではない」選択肢が巧妙に混ぜられます。これを見抜く視点を 5 つ挙げます。

第一に、要件のキーワードに注目します。「最もコスト効率が良い」「最小の運用負荷」「最高の可用性」——問われている評価軸を取り違えると、正しいサービスでも不正解になります。第二に、「動くが過剰」な選択肢を疑います。小さな要件にマルチサイト DR を持ってくるような、オーバースペックの選択肢は外します。第三に、長期キーのハードコードや手動運用を前提とした選択肢は、ほぼ不正解です。第四に、マネージドサービスで解ける課題に自前構築を選ぶのは避けます。第五に、単一障害点を残す構成は、可用性を問う問題では誤りです。これらの視点を持つだけで、4 択を 2 択まで素早く絞れます。

実戦では、まず明らかに誤った選択肢を 2 つ消し、残った 2 つを評価軸で比較する、という二段構えが効果的です。SAA-C03 の問題は、最後の 2 択で「どちらも動くが、要件に照らすとどちらがより最適か」を競わせてきます。ここで効くのが、問題文の末尾にある評価軸の指定です。同じ構成でも「コスト最優先」なら安い方、「運用負荷最小」ならマネージド度の高い方が正解になります。長文に惑わされず、最後の一文に書かれた「何を最適化したいのか」を見失わないこと。これが満点を狙ううえでの最終関門です。

模擬問題 30 問

ここから AWS SAA-C03 模擬問題 30 問です。Domain 配点に比例して、Domain 1 から順に出題します。各問、最適な選択肢を 1 つ選んでください。解答と解説は次のセクションにまとめています。

Q1. EC2 上のアプリが S3 にアクセスする。最も安全な認証方法は。

A) アクセスキーを環境変数に設定 B) IAM Role をインスタンスプロファイルでアタッチ C) ルートユーザーのキーを使用 D) キーをコードに記述

Q2. 数千人の社員に AWS コンソールアクセスを与えたい。最適な方法は。

A) 全員に IAM User を作成 B) ルートユーザーを共有 C) 既存 IdP とフェデレーション＋IAM Identity Center D) アクセスキーを配布

Q3. IAM ポリシーで Allow したのに操作が拒否される。最も可能性の高い原因は。

A) リージョン設定 B) SCP または明示的 Deny C) MFA 未設定 D) VPC 設定

Q4. RDS のパスワードを定期的に自動で入れ替えたい。最適なサービスは。

A) Parameter Store 標準パラメータ B) S3 に保存 C) Secrets Manager の自動ローテーション D) EC2 に保存

Q5. 特定の IP レンジを VPC で拒否したい。適切な仕組みは。

A) セキュリティグループ B) ネットワーク ACL の拒否ルール C) IAM ポリシー D) ルートテーブル

Q6. 保管データを暗号化し、キーポリシーと監査を自分で制御したい。

A) AWS 管理キー B) カスタマー管理キー（KMS） C) 暗号化しない D) クライアント側で独自実装のみ

Q7. 複数アカウント環境で組織全体に特定操作を一律禁止したい。

A) 各アカウントで IAM ポリシー設定 B) Service Control Policy（SCP） C) セキュリティグループ D) NACL

Q8. API コールの監査ログを記録したい。

A) CloudWatch のみ B) AWS CloudTrail C) VPC フローログ D) S3 アクセスログのみ

Q9. 機械学習でアカウントの脅威を継続検知したい。

A) Config B) CloudTrail 単体 C) GuardDuty D) Trusted Advisor

Q10. Web アプリの可用性を高めたい。最適な構成は。

A) 1 AZ に EC2 を増設 B) 複数 AZ に分散＋ALB＋Auto Scaling C) 単一の大型 EC2 D) オンプレミス併用

Q11. RDS の可用性を高めたい（読み取り分散が目的ではない）。

A) リードレプリカ追加 B) Multi-AZ 配置 C) インスタンスを大型化 D) バックアップ頻度を上げる

Q12. 注文処理を順序通り・重複なく処理したい。

A) SQS Standard キュー B) SQS FIFO キュー C) SNS D) Kinesis のみ

Q13. ひとつのイベントから複数の処理を並行起動したい。

A) 単一の SQS B) SNS と SQS のファンアウト C) 単一の Lambda D) EC2 ポーリング

Q14. スケールインでセッション情報が失われる。原因と対策は。

A) インスタンス内にセッション保持→ElastiCache 等へ外部化 B) AZ 障害 C) ELB 設定ミス D) DNS 問題

Q15. HTTP のパスに応じてバックエンドを振り分けたい。

A) NLB B) Application Load Balancer C) GWLB D) Classic LB

Q16. 超低レイテンシ・固定 IP・高スループットの L4 負荷分散が要る。

A) ALB B) Network Load Balancer C) CloudFront D) API Gateway

Q17. 複数ステップの処理を、再試行・失敗時補償込みで安全に組みたい。

A) 単一の巨大 Lambda B) Step Functions C) cron で順次実行 D) 手動運用

Q18. RTO/RPO がほぼゼロで、コストは問わない DR を実現したい。

A) バックアップ＆リストア B) パイロットライト C) ウォームスタンバイ D) マルチサイト Active/Active

Q19. コスト最優先で、復旧に半日かかってもよい開発環境の DR。

A) マルチサイト B) ウォームスタンバイ C) バックアップ＆リストア D) パイロットライト

Q20. リージョン障害に備えつつ世界中で低遅延の読み取りを提供したい。

A) 単一リージョン RDS B) Aurora グローバルデータベース C) EC2 上に自前 DB D) S3 のみ

Q21. 読み取りが多い RDS の性能が頭打ち。最適な対策は。

A) Multi-AZ 化 B) リードレプリカを追加 C) バックアップ削減 D) リージョン変更

Q22. 同じ DB クエリが大量発生。最も効果的にレイテンシと負荷を下げる手段は。

A) インスタンス大型化 B) ElastiCache でキャッシュ C) リージョン変更 D) バックアップ追加

Q23. 一桁ミリ秒以下・超大規模なキーバリューアクセスが要る。

A) RDS B) DynamoDB（必要なら DAX） C) Redshift D) EFS

Q24. 複数の EC2 から同一ファイルへ同時アクセスしたい。

A) EBS を共有 B) EFS C) S3 Glacier D) インスタンスストア

Q25. 世界中へ静的コンテンツを低遅延配信したい。

A) オリジン増強 B) CloudFront でエッジ配信 C) リージョン追加のみ D) NLB

Q26. 高い IOPS を確実に保証したい DB ボリューム。

A) st1 B) sc1 C) io2（プロビジョンド IOPS SSD） D) 汎用 gp2 の最小構成

Q27. 24 時間安定稼働する本番サーバーのコストを下げたい。

A) オンデマンド継続 B) Savings Plans / Reserved Instances C) Spot のみ D) 大型化

Q28. 中断されても再実行できる夜間バッチを最安で。

A) オンデマンド B) Reserved Instances C) Spot インスタンス D) 専有ホスト

Q29. ログを 1 年保管、30 日以降ほぼ読まない。コスト最適化は。

A) Standard に保持 B) ライフサイクルで Glacier 系へ自動移行 C) 即削除 D) EBS に保存

Q30. アクセスパターンが予測できないデータのコストを自動最適化したい。

A) Standard 固定 B) S3 Intelligent-Tiering C) 手動でクラス変更 D) One Zone-IA 固定

模擬問題 解答・解説

解答は次の通りです。

Q1:B / Q2:C / Q3:B / Q4:C / Q5:B / Q6:B / Q7:B / Q8:B / Q9:C / Q10:B /

Q11:B / Q12:B / Q13:B / Q14:A / Q15:B / Q16:B / Q17:B / Q18:D / Q19:C / Q20:B /

Q21:B / Q22:B / Q23:B / Q24:B / Q25:B / Q26:C / Q27:B / Q28:C / Q29:B / Q30:B。

Domain 1（Q1〜Q9）の核心は「長期キーを疑う」「多層で守る」「評価ロジックを順にたどる」でした。Q1 はアクセスキーのハードコードを避けて IAM Role を使う原則、Q3 は IAM の Allow が SCP や明示的 Deny に阻まれる評価順、Q6 はキーポリシー制御が要るならカスタマー管理キー、という判断が問われています。Q8 と Q9 は、記録（CloudTrail）と検知（GuardDuty）の役割分担を取り違えないことが鍵です。ここで注意したいのは、Q2 のように「ルートユーザーを共有」「アクセスキーを配布」といった、明らかに危険な選択肢がダミーとして混ぜられる点です。これらは技術的には動いてしまうため、知識が曖昧だと選びかねません。セキュリティの問題では「動くか」ではなく「安全か」で判断する、という軸を徹底してください。

Domain 2（Q10〜Q20）は「冗長化」と「疎結合」、そして DR の戦略選択でした。Q11 は可用性なら Multi-AZ、読み取り性能ならリードレプリカという目的の違い、Q12 は順序・重複排除なら FIFO、Q14 はステートレス化の原則です。Q18〜Q20 は RTO/RPO とコストの交点から DR 戦略を選ぶ問題で、要件が厳しいほど高コストな戦略へ、という相関を使えば即答できます。

Domain 3（Q21〜Q26）は、ワークロード特性からの逆引きです。Q21 は読み取り分散のリードレプリカ、Q22 はキャッシュによる DB 負荷低減、Q23 は超低遅延大規模の DynamoDB、Q24 は共有ファイルの EFS、Q26 は IOPS 保証の io2。それぞれ「何がボトルネックか」を見極めれば、サービスは一意に定まります。特に Q22 のような「同じ問い合わせが大量に来る」ケースで、インスタンスの大型化を選んでしまう誤りが目立ちます。スケールアップは一見もっともらしい対処ですが、根本的にはキャッシュで DB アクセス自体を減らす方が、コストも性能も圧倒的に有利です。「問題の根を断つ」発想が、Domain 3 では繰り返し問われます。

Domain 4（Q27〜Q30）は、コストの判断軸です。Q27 は安定稼働ならコミット型、Q28 は中断耐性があれば Spot、Q29 はライフサイクルによる自動階層移行、Q30 はアクセス不明なら Intelligent-Tiering。「コミットできるか」「中断に耐えられるか」「アクセス頻度はどうか」を問えば、最適解が見えます。コスト系の設問でよくある誤りが、Q28 で「Reserved Instances が一番安いはず」と早合点することです。確かに RI は安定稼働には有効ですが、中断されても再実行できるバッチには、より深い割引の Spot が適します。要件文の「中断されても再実行できる」という一語が、Spot を選ばせる決定的なヒントになっている——この読み取りが、AWS SAA-C03 模擬問題で差をつけるポイントです。

なお、本セクションの 30 問はすべて実在の AWS サービス・実在の機能だけで構成しています。本番の試験でも、ダミーの選択肢は「架空のサービス」ではなく「実在サービスの誤用」で作られます。だからこそ、各サービスが「何のための道具か」を正確に理解していれば、誤用を見抜けるのです。

まとめ — 直前の弱点補強法

AWS SAA-C03 模擬問題を解いて間違えた領域こそ、伸びしろです。30 問の中で取りこぼした Domain を特定し、該当する解説をもう一度たどってください。間違いには必ず原因があります。「評価軸を読み違えた」「過剰な選択肢を選んだ」「サービスの目的を取り違えた」——どの視点が抜けていたかを言語化できれば、同じ失敗は繰り返しません。

模擬問題を解くときは、正解した問題も「なぜ正解か」を説明できるか確認してください。たまたま当たった問題は、本番で形を変えて出されると落とします。正解の根拠まで言語化できて初めて、その知識は本物の得点力になります。間違えた問題だけでなく、自信のなかった問題も振り返りの対象にすることが、安定した合格ラインへの近道です。

パターン認識と判断軸が身につけば、未見の問題でも「これはあの構成の変奏だ」と見抜けるようになります。残るは、本番での運用——申込手順、時間配分、当日の心構えです。次は試験直前の実戦運用と、合格後に広がるキャリアの道筋を整理し、このシリーズを締めくくります。

参照

• AWS Certified Solutions Architect – Associate（SAA-C03）公式
• AWS Well-Architected Framework
• Amazon API Gateway 公式
• Amazon CloudFront — S3 オリジンへのアクセス制限（OAC）
• AWS Direct Connect 公式

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.