PASS QUESTSAPを無料で試す

AWS SAP · SAP-C02

AWS SAPの無料問題と勉強ガイド

複雑な条件を、ひとつずつ整理しよう。

AWS SAP — ここでいうSAPは、Solutions Architect - Professional（ソリューションアーキテクト プロフェッショナル）の資格です。組織の複雑さ、新しいソリューション、既存環境の継続的な改善、移行を含む設計を扱います。

組織・移行・障害対応を組み合わせた設計を学ぶ方へ。 このページでは、1問の読み方から、条件を変えた練習、復習の計画までをつなげます。

登録不要 · この試験の無料6問 · スマホ・PC対応

無料6問を解く まず問題と解説を読む

AWS公式教材ではない独自問題です。試験範囲の網羅・模擬試験・合否予測には対応していません。

このページはC02教材です。新試験を検討中の方は SAP-C03との違い を確認してください。

この教材で練習すること

  1. 1複数アカウント・組織をまたぐ設計判断
  2. 2移行、継続性、ガバナンスの制約整理
  3. 3複数の実現案から優先要件に合う案を選ぶ視点

1問を読む前に

正解より先に、答えを分ける条件を探す

「社内とAWSの間で名前解決したい」。VPCの数や共有方法から考え始めると、Resolverの入口と出口を取り違えやすくなります。

DNSの問い合わせは、どちらから？
  1. 社内 → AWSの名前を問い合わせる → inbound
  2. AWS → 社内の名前を問い合わせる → outbound

まず問い合わせの向きを矢印で描き、その後でルールの共有や接続条件を考えます。複数の要件を、一度に解こうとしないのが出発点です。

最初の無料問題はoutbound endpointです。続く長文問題では、方向を分けてから、複数VPCへのルール共有まで考えます。

この例の詳しい条件・比較・公式出典へ

FREE QUESTIONS & EXPLANATIONS

SAP-C02の無料問題6問・解答と解説

短い問題3問と、長い場面設定を読む問題3問です。まず1問目を読み、答えを考えてから解説を開いてみてください。残りの問題はタイトルを押すと開きます。PASS QUESTが制作した独自問題で、AWS公式の問題や実試験問題ではありません。

教材の制作・確認・訂正について

制作：PASS QUEST。補足解説の作成に生成AIを利用し、以下の範囲でAWS公式資料との照合と、作成とは別工程のレビューを実施しました。AWSによる監修ではありません。

2026年9月10日の内容確認は、無料クイック9問の27選択肢の補足解説と、SAPのD3解説例が対象です。各解説の出典から、適用条件を確かめられます。無料シナリオ9問にも選択肢ごとの理由と出典があります。

2026年9月15日には、C03追加編40問の問題文・正答・全選択肢の理由を、生成AIで作成し別工程でレビューしました。AWS公式資料の本文または取得した内容の確認記録と照合しています。人による専門家監修ではありません。各問題の出典で適用条件を確認できます。

これらの確認は、既存1,170問の再検証やAWS環境での実機検証、学習効果の実証を表すものではありません。

再試行と二重処理については、独立したSQLiteの実験教材を追加しています。実行条件・コード・結果と限界を確認できます。ローカルDBでの観測であり、AWSサービスの実機検証、人による専門家監修、受験・学習成果の証明ではありません。

学習案内・週間計画・C03追加編の具体的な更新履歴で、変更した対象・根拠・版と、確認していない範囲を追えます。

誤りや分かりにくい説明を見つけた場合は、コース・問題名・該当箇所をお問い合わせ窓口へお知らせください。出典を照合し、必要に応じて説明と確認日を更新します。

短い問題 1 / 3

Route 53 Resolver：outbound endpoint

問題を開く・閉じる

VPCからオンプレミスDNSへ条件付き転送するResolver endpointは？

  1. A.Inbound endpoint
  2. B.Outbound endpoint
  3. C.Transit Gateway DNS support
正答と解説を読む

正答：B

VPCから自社ネットワークへDNS問い合わせを送る向きはoutboundです。

選択肢ごとに、要件との違いを確認する

  • 選択肢A：選ばない

    Inbound endpointは、オンプレミス側からVPCへ届くDNS問い合わせの入口です。この問題の「VPCからオンプレミスへ」とは向きが逆です。

  • 選択肢B：選ぶ

    Outbound endpointと転送ルールを使い、指定ドメインへの問い合わせをVPCからオンプレミスのDNSサーバーへ転送します。ルールに対象ドメインと転送先を設定する点まで押さえます。

  • 選択肢C：選ばない

    Transit GatewayのDNS supportを有効にすることは、Resolver endpointの選択ではありません。接続経路があっても、今回必要な条件付き転送のendpointとルールの代わりにはなりません。

補足解説の根拠を確認（2026年9月10日確認）

解説の根拠をAWS公式資料で確認

短い問題 2 / 3

AWS KMS：マルチリージョンキー

問題を開く・閉じる

AWS Encryption SDKでKMS multi-Region keyを使う構成は？

  1. A.同じaliasの独立single-Region key
  2. B.片方だけに置くsingle-Region key
  3. C.関連KMS key＋multi-Region-aware keyring
正答と解説を読む

正答：C

関連KMS keyとmulti-Region-aware keyringなら、同じ暗号文を各Regionで復号できます。

選択肢ごとに、要件との違いを確認する

  • 選択肢A：選ばない

    同じaliasは、同じキーマテリアルを意味しません。独立したsingle-Region key同士は、aliasをそろえても関連するマルチリージョンキーにはならず、一方で暗号化したデータを他方のキーでは復号できません。

  • 選択肢B：選ばない

    single-Region keyを片方のRegionだけに置く場合、復号にも暗号化に使ったそのキーが必要です。各Regionにある関連キーで同じ暗号文を復号する構成にはなりません。

  • 選択肢C：選ぶ

    関連するマルチリージョンキーは、同じキーIDとキーマテリアルを共有します。multi-Region-aware keyringなら、暗号化に使ったキーと関連する別Regionのキーで復号でき、KMSへのクロスリージョン呼び出しを避けられます。キーポリシーや権限は各Regionで確認します。

補足解説の根拠を確認（2026年9月10日確認）

解説の根拠をAWS公式資料で確認

短い問題 3 / 3

Step Functions：StandardとExpress

問題を開く・閉じる

数日続き、人の承認callbackが必要なワークフロー種別は？

  1. A.Step Functions Standard
  2. B.Step Functions Express
  3. C.EventBridge Scheduler
正答と解説を読む

正答：A

Standard Workflowは長時間実行、callbackパターン、実行履歴に対応します。

選択肢ごとに、要件との違いを確認する

  • 選択肢A：選ぶ

    Standardは最大1年の実行と、タスクトークンを使うcallback（.waitForTaskToken）に対応します。数日かかる処理で人の承認を待ち、結果を受けて次へ進むという二つの要件に合います。

  • 選択肢B：選ばない

    Expressの実行時間は最大5分で、.waitForTaskTokenによるcallbackにも対応しません。短時間の大量処理に使えても、この問題の数日間の承認待ちは満たせません。

  • 選択肢C：選ばない

    EventBridge Schedulerは時刻や間隔を決めてAPIを呼び出す仕組みです。Step Functionsの実行開始には使えますが、承認待ちと後続処理の状態を管理するワークフローの代わりにはなりません。

補足解説の根拠を確認（2026年9月10日確認）

解説の根拠をAWS公式資料で確認

長い場面設定の問題 1 / 3

Route 53 Resolver：inbound・outboundとルール共有

問題を開く・閉じる

同一リージョンの60のVPCが複数アカウントに分散し、共有サービスVPCを経由してオンプレミスと接続されている。オンプレミスから、共有サービスVPCにも関連付け済みのRoute 53プライベートホストゾーン aws.corp.internal を解決したい。また、全VPCからオンプレミスの corp.example を解決したい。各スポークVPCへResolver endpointを作ることは避ける。

要件を満たすために実施すべき対応を2つ選べ。

  1. A.共有サービスVPCにRoute 53 Resolver inbound endpointを複数AZで作成し、オンプレミスDNSから aws.corp.internal の問い合わせをそのIPアドレスへ条件付き転送する。
  2. B.Transit GatewayのDNS supportを有効化し、全VPCでDNS resolutionとDNS hostnamesを有効にする。共有サービスVPCへのルートとセキュリティグループを追加すれば、オンプレミスと全VPCの条件付き名前解決が自動構成される。
  3. C.aws.corp.internal と corp.example をRoute 53パブリックホストゾーンへ複製する。オンプレミスDNSの変更をLambdaで定期反映し、各VPCとオンプレミスがインターネットの再帰リゾルバーに問い合わせることで、endpointを作らずに双方向の名前解決を実現する。
  4. D.共有サービスVPCにRoute 53 Resolver outbound endpointを作成し、corp.example をオンプレミスDNSへ転送するルールを作る。そのResolver ruleをAWS RAMで組織へ共有し、各スポークVPCへ関連付ける。
  5. E.Inbound endpointを双方向モードに変更し、同じendpointのIPアドレスをAWS RAMで組織へ共有する。各VPCにcorp.exampleの条件付きルールを関連付け、そのendpointからオンプレミスDNSへ問い合わせを送信する。
正答・選ぶ理由・選ばない理由を読む

正答：A と D

ハイブリッドDNSは、オンプレミスからAWSへinbound、AWSからオンプレミスへoutboundを分ける。複数アカウントではoutbound Resolver ruleをAWS RAMで共有する。

  • 選択肢A：選ぶ

    正解。Inbound endpointはオンプレミスからVPC Resolverへ問い合わせを転送する入口になる。プライベートホストゾーンをendpointのVPCへ関連付けることで、そのレコードを解決できる。

  • 選択肢B：選ばない

    Transit GatewayのDNS機能だけでは、オンプレミスDNSとRoute 53 Resolver間のinbound・outbound条件付き転送を作成しない。

  • 選択肢C：選ばない

    プライベート名前空間をパブリックDNSへ公開する設計になり、内部限定の双方向名前解決という要件に合わない。

  • 選択肢D：選ぶ

    正解。共有されたResolver ruleは複数アカウントのVPCから共通outbound endpointを利用でき、VPCごとのendpoint作成を避けながらオンプレミス名前空間へ条件付き転送できる。

  • 選択肢E：選ばない

    Resolver endpointは方向別である。VPCからオンプレミスへ転送するにはoutbound endpointと転送ルールが必要で、inbound endpointを双方向へ変更する設定はない。

解説の根拠をAWS公式資料で確認

長い場面設定の問題 2 / 3

Aurora Global Database：RPO・RTOと災害復旧

問題を開く・閉じる

SaaSのトランザクションDBは東京リージョンのAurora PostgreSQLで稼働している。欧州ユーザーには欧州リージョンから読み取りを提供し、東京リージョン全体の障害時はデータ損失を秒単位、復旧を分単位に抑えたい。通常時の書き込みは東京だけでよく、独自の論理レプリケーション運用は避けたい。

データベースと復旧手順の基盤として最も適切な構成はどれか。

  1. A.Auroraの自動スナップショットを1時間ごとに欧州へコピーする。障害をEventBridgeで検知し、CloudFormationで新しいDBクラスターを復元して、Route 53のDNSレコードを自動的に切り替える。
  2. B.東京のAuroraクラスターに複数AZのreaderインスタンスを配置し、RDS Proxyで接続をプールする。欧州ユーザーも東京のreader endpointへ接続させ、リージョン障害時はDNS TTLが切れるまで再試行する。
  3. C.リレーショナルデータをDynamoDB global tablesへ即時移行し、アプリケーションのSQLとトランザクション処理は変更しない。東京と欧州から常時マルチアクティブ書き込みを行い、競合はサービスに任せる。
  4. D.Aurora Global Databaseを構成し、欧州にDBインスタンスを持つsecondary clusterを置く。レプリケーション遅延を監視し、計画停止はswitchover、リージョン障害はcross-Region failoverを実行してアプリケーションの接続先を切り替える手順を自動化・訓練する。
正答・選ぶ理由・選ばない理由を読む

正答：D

Aurora PostgreSQLのリージョンDRで秒単位RPO・分単位RTOと遠隔読み取りが必要ならAurora Global Databaseを使い、switchoverとfailoverを区別して訓練する。

  • 選択肢A：選ばない

    バックアップ復元は有効なDR方式だが、1時間間隔では秒単位RPOを満たさず、復元と再構成により分単位RTOも不確実になる。

  • 選択肢B：選ばない

    Multi-AZはリージョン内障害へ対応するが、リージョン全体の障害に対する欧州の復旧先を提供しない。欧州からの読み取りレイテンシーも改善しない。

  • 選択肢C：選ばない

    DynamoDB global tablesはマルチリージョン用途に適するが、PostgreSQL互換の既存トランザクションアプリを即時移行するにはデータモデルとアプリケーションの大幅変更が必要で、単一writer要件にも過剰である。

  • 選択肢D：選ぶ

    正解。Aurora Global Databaseはリージョン間の非同期レプリケーションとsecondaryでの低レイテンシー読み取りを提供する。AWS公式文書ではRPOは通常秒単位、RTOは分単位で、計画時のswitchoverは同期後に切り替えるためRPO 0、障害時failoverは遅延に応じた非ゼロRPOになる。

解説の根拠をAWS公式資料で確認

長い場面設定の問題 3 / 3

Step Functions：長時間処理と人による承認

問題を開く・閉じる

既存のEC2モノリスは、注文受付、与信、倉庫処理、人による例外承認、請求を同期的に実行している。処理は数日に及ぶことがあり、失敗時の再試行と補償、承認callback、実行履歴が必要である。請求など非idempotentな処理を不用意に二重実行せず、各段階をLambdaやECS taskへ段階的に分離したい。

モダナイゼーションの中核として最も適切な構成はどれか。

  1. A.EventBridge Schedulerで1分ごとに全注文を走査するLambdaを起動する。LambdaはDBのstatus列で次の処理を判断し、処理失敗時の再試行回数、人の承認待ち、補償処理の進捗も同じ行の列に保存する。
  2. B.SQS standard queueを1つ作り、全段階のworkerが同じqueueから受信する。workflow stateと処理順序は各workerのメモリに保持し、人の承認待ちはvisibility timeoutを数日に延長する。失敗時は各workerが独自に前工程のロールバックを呼ぶ。
  3. C.AWS Step Functions Standard Workflowで各段階をオーケストレーションし、Retry/Catchと補償分岐を定義する。人の承認にはtask token callbackを使い、LambdaやECS service integrationを呼び出して実行履歴を監査する。
  4. D.Step Functions Express Workflowで各段階をオーケストレーションし、Retry/Catchと補償分岐を定義する。人の承認にはtask token callbackを使い、CloudWatch Logsに数日分の処理履歴を保存する。
正答・選ぶ理由・選ばない理由を読む

正答：C

数日続く監査可能な業務フロー、callback、補償、非idempotent処理のオーケストレーションにはStep Functions Standard Workflowを使う。

  • 選択肢A：選ばない

    ポーリングと独自状態管理が残り、callback、retry、compensation、監査可能なworkflow履歴を自前実装する必要がある。

  • 選択肢B：選ばない

    SQSはdecouplingに有効だが、単独では複数段階のdurable state、分岐、callback、補償、全体の実行履歴を提供しない。Worker memoryは障害時に失われる。

  • 選択肢C：選ぶ

    正解。Standard Workflowは最長1年のdurableでauditableな実行、exactly-once workflow execution、実行履歴、callback、Retry/Catch、各種service integrationを提供し、長期・非idempotent処理を含む段階的分離に適する。明示したRetryは再実行を起こし得るため、業務側の冪等性設計も併用する。

  • 選択肢D：選ばない

    Express Workflowは最長5分で、非同期Expressはat-least-once実行である。長期実行や.waitForTaskToken callbackを必要とする本要件にはStandard Workflowが適する。

解説の根拠をAWS公式資料で確認

SAP-C02の問題演習の進め方

  1. 要件を分ける：DNSの問い合わせ方向、通常時の読み書き、障害時の復旧目標を混ぜずに整理します。
  2. 運用まで考える：構成を選ぶだけでなく、リージョン切替や処理の再試行で何が必要かを確認します。
  3. 選ばない理由も確認する：複数の選択肢が動作しそうなときほど、共有範囲・処理時間・実行保証を比べます。

読んで理解した後は、同じ無料6問に回答してみてください。シナリオでは回答と自信を記録し、迷った問題の復習候補を確認できます。学習履歴は端末内に保存されます。

SAP-C02の無料6問に回答する

答えを覚えたら、条件を1つ変えてみる

同じサービスでも、満たすべき条件が違えば選ぶ案は変わります。次は4つのテーマで、その境界を確かめましょう。

条件の違いを見つける練習

SAP-C02：2つのケースで、選ぶ答えを比べよう

各テーマにケース1・ケース2があります。まずケース1で答えを選び、解説を読んでからケース2へ。変わった条件が、答えをどう変えるかを確かめます。

登録不要の独自補助教材です。アプリの無料6問とは別で、アプリの成績・復習履歴には保存しません。試験の再現問題や合否判定ではありません。根拠資料の確認：2026年9月13日。

SAP-C02 · 条件比較の練習

Route 53 Resolver：DNSの問い合わせはどちら向き？

接続済みの社内ネットワークとAWSの間で、相手側が管理する名前を調べます。

まずケース1で答えを選びます。解説を読んだらケース2へ進み、選ぶ理由の違いを確かめましょう。

比べるポイント

ケース1は社内からVPCへ問い合わせる。ケース2はVPCから社内へ問い合わせる。

用語を確認する（3語）
DNS・名前解決
サーバーの名前などから、通信先のアドレスを調べる仕組み・処理。
オンプレミス
ここでは、AWSの外にある自社の設備やネットワーク。
VPC
AWS上に用意する、利用者ごとの仮想ネットワーク。

1 条件を読む

練習するケース

ケース1の条件

社内のアプリから、VPCに関連付けたプライベートな名前を調べたい。逆向きは不要。

  • オンプレミスのアプリケーションが、対象VPCに関連付けられたRoute 53プライベートホストゾーンの名前を解決したい。
  • VPCからオンプレミス側の名前を解決する要件はない。
どちらのケースも共通の前提

オンプレミスとVPCはVPNまたはDirect Connectで接続済み。DNSに必要な経路とセキュリティ設定も用意する。今回の一方向の問い合わせに必要な、最小のResolverエンドポイント構成を選ぶ。

2 答えを1つ選ぶ

指定された一方向の問い合わせに必要な、最小のエンドポイント構成はどれですか？

ケース1の回答

選択肢を1つ選ぶと、答え合わせできます。 ケースを切り替えると回答を選び直します。

3 2つのケースの答え・解説を比べる

両方を解いたら、条件と答えを並べて振り返りましょう。解く前に解説を読むこともできます。

ケース1 · 社内のアプリから、VPCに関連付けたプライベートな名前を調べたい。逆向きは不要。

オンプレミスのアプリケーションが、対象VPCに関連付けられたRoute 53プライベートホストゾーンの名前を解決したい。VPCからオンプレミス側の名前を解決する要件はない。

答え：インバウンドエンドポイントを作り、オンプレミスDNSから対象ドメインの問い合わせを転送する

○ 選択肢1：インバウンドエンドポイントを作り、オンプレミスDNSから対象ドメインの問い合わせを転送する
問い合わせはオンプレミスからVPC側へ入る。インバウンドエンドポイントを受け口とし、オンプレミスDNSが対象ドメインの問い合わせを転送する構成にする。
× 選択肢2：アウトバウンドエンドポイントと転送ルールを作り、対象VPCへルールを関連付ける
アウトバウンドはVPC側からオンプレミス等のDNSへ問い合わせを出すための経路。今回は問い合わせの向きが逆。
× 選択肢3：インバウンドとアウトバウンドの両エンドポイントを用意する
両方向の要件があるなら候補になるが、今回の要件はオンプレミスからVPCへの一方向だけ。必要な最小構成としてアウトバウンドを加える理由はない。

インバウンド／アウトバウンドは、問い合わせがVPC側へ入るか出るかで区別する。DNS応答が戻ることは、逆向きの問い合わせ要件とは別。

ケース2 · VPC内のEC2から、社内DNSが管理する名前だけを問い合わせたい。逆向きは不要。

VPCのEC2インスタンスが、オンプレミスDNSで管理する社内ドメインの名前を解決したい。オンプレミスからVPCの名前を解決する要件はない。対象ドメインだけをオンプレミスDNSへ転送する。

答え：アウトバウンドエンドポイントと転送ルールを作り、対象VPCへルールを関連付ける

× 選択肢1：インバウンドエンドポイントを作り、オンプレミスDNSから対象ドメインの問い合わせを転送する
インバウンドは外部からVPC側へ問い合わせを受けるための受け口であり、今回のVPCから出る問い合わせを転送する構成ではない。
○ 選択肢2：アウトバウンドエンドポイントと転送ルールを作り、対象VPCへルールを関連付ける
VPCからオンプレミスDNSへ出る問い合わせには、アウトバウンドエンドポイントと対象ドメインの転送ルールを使う。ルールのVPC関連付けも必要。
× 選択肢3：インバウンドとアウトバウンドの両エンドポイントを用意する
今回必要な問い合わせはVPCからオンプレミスへの一方向。両方を用意しても、最小構成という指定には合わない。

接続回線が同じでも、問い合わせ元と名前の管理場所を入れ替えると必要なエンドポイントが変わる。ドメインを絞り、転送ループも避ける。

公式資料・復習メモ・確認記録
この例を確かめて、復習メモに残す

ケース1とケース2を解いたら、答えが変わった理由を自分の言葉でメモに残しましょう。ケース1は以前の「条件A」、ケース2は「条件B」に対応します。

以前の操作確認を見る（2026年9月17日）

以下は旧画面での確認記録です。現在は「答えと理由を見る」で答え合わせします。問題の条件と正答は同じですが、ボタンや判定の表現を見直しています。

  1. 条件A：オンプレミスからVPC内の名前を引く

    選ぶ案：インバウンドエンドポイントを作り、オンプレミスDNSから対象ドメインの問い合わせを転送する

    当時の「理由を確かめる」の確認表示：この条件に合っています。

  2. 条件B：VPCからオンプレミスの名前を引く

    選ぶ案：インバウンドエンドポイントを作り、オンプレミスDNSから対象ドメインの問い合わせを転送する

    当時の「理由を確かめる」の確認表示：優先する条件をもう一度見てみましょう。

  3. 条件B：VPCからオンプレミスの名前を引く

    選ぶ案：アウトバウンドエンドポイントと転送ルールを作り、対象VPCへルールを関連付ける

    当時の「理由を確かめる」の確認表示：この条件に合っています。

2026年9月17日に公開画面で3手順を操作し、表示と理由の一致を確認しました。架空条件の教材内の確認です。AWS環境での構築・操作、学習効果、全問題を検証した結果ではありません。

3例の入力・確認結果・限界を見る

メモ本文を読んでコピーする
# SAP-C02 DNSの問い合わせは、どこからどこへ？：条件を変えた復習メモ

記入例は架空の条件比較です。自分の説明欄に、判断が変わった条件を追記してください。
教材の表示確認日：2026-09-17（技術の実機検証・学習効果の測定ではありません）
教材：https://passquest.signalandship.com/aws-sap-c02-practice#lab-sap-resolver-direction

## 前提
オンプレミスとVPCはVPNまたはDirect Connectで接続済み。DNSに必要な経路とセキュリティ設定も用意する。今回の一方向の問い合わせに必要な、最小のResolverエンドポイント構成を選ぶ。

## 手順 1：条件A：オンプレミスからVPC内の名前を引く
条件：オンプレミスのアプリケーションが、対象VPCに関連付けられたRoute 53プライベートホストゾーンの名前を解決したい。VPCからオンプレミス側の名前を解決する要件はない。
選んだ案：インバウンドエンドポイントを作り、オンプレミスDNSから対象ドメインの問い合わせを転送する
操作：理由を確かめる
期待表示・確認時の表示：この条件に合っています。
理由：問い合わせはオンプレミスからVPC側へ入る。インバウンドエンドポイントを受け口とし、オンプレミスDNSが対象ドメインの問い合わせを転送する構成にする。

## 手順 2：条件B：VPCからオンプレミスの名前を引く
条件：VPCのEC2インスタンスが、オンプレミスDNSで管理する社内ドメインの名前を解決したい。オンプレミスからVPCの名前を解決する要件はない。対象ドメインだけをオンプレミスDNSへ転送する。
選んだ案：インバウンドエンドポイントを作り、オンプレミスDNSから対象ドメインの問い合わせを転送する
操作：理由を確かめる
期待表示・確認時の表示：優先する条件をもう一度見てみましょう。
理由：インバウンドは外部からVPC側へ問い合わせを受けるための受け口であり、今回のVPCから出る問い合わせを転送する構成ではない。

## 手順 3：条件B：VPCからオンプレミスの名前を引く
条件：VPCのEC2インスタンスが、オンプレミスDNSで管理する社内ドメインの名前を解決したい。オンプレミスからVPCの名前を解決する要件はない。対象ドメインだけをオンプレミスDNSへ転送する。
選んだ案：アウトバウンドエンドポイントと転送ルールを作り、対象VPCへルールを関連付ける
操作：理由を確かめる
期待表示・確認時の表示：この条件に合っています。
理由：VPCからオンプレミスDNSへ出る問い合わせには、アウトバウンドエンドポイントと対象ドメインの転送ルールを使う。ルールのVPC関連付けも必要。

## 自分の説明
決め手になった条件：
条件Aで正しく、条件Bで不適切になる理由：
別の条件ならどう変えるか：
まだ説明できない点：
参照した公式資料の節：
確認した日：

## 公式根拠
- ハイブリッドDNSとResolverエンドポイント：https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html

## 範囲と限界
- 架空の学習例。AWS環境での構築・削除・移行・通信は実行していない。
- 学習効果、合格可能性、試験範囲の網羅性の測定ではない。
- 3ラボ各3ケースの追試。全問題・全条件の検証ではない。
- モバイルや固定9質問の全経路の検証ではない。
- この教材の判定規則と表示が一致することの確認。技術主張は別途AWS資料と照合。

このメモを保存しても、サイトの成績・週間計画・復習履歴へ自動登録されません。
同じ本文のMarkdownファイルを開く

メモには条件・選択・理由と、自分で説明する空欄が入ります。保存してもアプリの成績や復習履歴には登録されません。

この説明の根拠と、確認した範囲

  • 根拠：Route 53 ResolverのInbound/Outbound説明。まず問い合わせ元と名前の管理場所を決め、必要な方向のエンドポイントを選びます（資料確認2026年9月17日）。

    AWS公式：Resolving DNS queries between VPCs and your network

    適用範囲：VPN/DX経路とDNSセキュリティ設定は前提。両方向要件/共有条件は別に検討。実DNS解決の検証ではない。

主な説明と出典の対応記録を見る
学習マップのタスク1.1を見る

SAP-C02 · 条件比較の練習

AWSの災害復旧：予備の環境を普段からどう使う？

一つのリージョンが使えなくなったときに備え、別のリージョンにも復旧先を用意します。

まずケース1で答えを選びます。解説を読んだらケース2へ進み、選ぶ理由の違いを確かめましょう。

比べるポイント

ケース1は小さい規模で待機し、災害時に拡大。ケース2は普段から両方で利用者の処理を担当。

用語を確認する（3語）
リージョン
AWSのサービスを使う地理的な地域の単位。
トラフィック
ここでは、アプリへ届く利用者からのアクセスやリクエスト。
RTO・RPO
復旧までに許容する時間と、どの時点までのデータを戻す必要があるかを表す目標。

1 条件を読む

練習するケース

ケース1の条件

全体が動く小規模な環境を待機させ、本番の利用者を受けるのは災害時に拡大してから。

  • 復旧先では、アプリケーション全体が動作する環境を縮小した規模で常時維持する。
  • 平常時の本番利用者のトラフィックは主リージョンが処理し、災害時に復旧先の容量を増やして切り替える方針にする。
どちらのケースも共通の前提

複数リージョンを使う災害復旧方針を選ぶ。データの複製方式、依存サービス、必要なサービスクォータは別途検証する。方式名だけでRTO・RPOの達成を保証せず、復旧訓練で確認する。

2 答えを1つ選ぶ

平常時の環境の動かし方に合う、災害復旧の方式はどれですか？

ケース1の回答

選択肢を1つ選ぶと、答え合わせできます。 ケースを切り替えると回答を選び直します。

3 2つのケースの答え・解説を比べる

両方を解いたら、条件と答えを並べて振り返りましょう。解く前に解説を読むこともできます。

ケース1 · 全体が動く小規模な環境を待機させ、本番の利用者を受けるのは災害時に拡大してから。

復旧先では、アプリケーション全体が動作する環境を縮小した規模で常時維持する。平常時の本番利用者のトラフィックは主リージョンが処理し、災害時に復旧先の容量を増やして切り替える方針にする。

答え：ウォームスタンバイ：縮小した稼働可能な環境を待機させ、災害時に規模を増やす

× 選択肢1：マルチサイトのアクティブ／アクティブ：複数リージョンで平常時から利用者の処理を担当する
アクティブ／アクティブでは複数リージョンが平常時から本番利用者の処理を担当する。今回の復旧先は通常の本番トラフィックを受けないため、運用状態が異なる。
○ 選択肢2：ウォームスタンバイ：縮小した稼働可能な環境を待機させ、災害時に規模を増やす
縮小した稼働可能な環境を待機させ、復旧時に規模を増やす条件がウォームスタンバイに当たる。起動するだけでなく、容量拡大や依存先も訓練する。
× 選択肢3：バックアップと復元：保存したデータと構成から、災害時に環境を復元する
バックアップからの復元を中心にする方針では、今回指定された「縮小していても全体が動作する環境を常時維持する」という運用状態を表せない。

復旧先の存在だけでなく、平常時に全体が稼働しているか、本番トラフィックを受けるか、切り替え時に拡張が必要かを読む。

ケース2 · 複数リージョンで普段から本番処理を担い、片方の障害時は残る側へアクセスを寄せる。

複数リージョンが平常時から本番利用者のトラフィックを処理する。データの整合性や競合を扱う設計を行い、一方のリージョンが失われた場合は残るリージョンへトラフィックを寄せられる構成にする。

答え：マルチサイトのアクティブ／アクティブ：複数リージョンで平常時から利用者の処理を担当する

○ 選択肢1：マルチサイトのアクティブ／アクティブ：複数リージョンで平常時から利用者の処理を担当する
複数リージョンが通常時から処理を担う運用状態がアクティブ／アクティブに当たる。片側喪失時の容量・ルーティング・データ整合性を実測で確認する。
× 選択肢2：ウォームスタンバイ：縮小した稼働可能な環境を待機させ、災害時に規模を増やす
ウォームスタンバイの待機環境は、通常時の本番利用者トラフィックを担当する構成ではない。今回は複数側を日常の処理に使う。
× 選択肢3：バックアップと復元：保存したデータと構成から、災害時に環境を復元する
災害時にバックアップから環境を復元する方針だけでは、複数リージョンが通常時から本番処理を担うという要件を満たさない。

アクティブ／アクティブでも、データ破損や誤削除に備えるバックアップは必要。方式名だけで無停止やデータ損失ゼロを結論にしない。

公式資料・復習メモ・確認記録学習マップのタスク2.2を見る

SAP-C02 · 条件比較の練習

AWSアプリの更新：少人数から公開する？ 一斉に切り替える？

Webアプリの新しい版を、利用者へどう届けるかを決めます。

まずケース1で答えを選びます。解説を読んだらケース2へ進み、選ぶ理由の違いを確かめましょう。

比べるポイント

ケース1は少量の本番アクセスで様子を見てから広げる。ケース2は利用を止め、全対象を一斉に更新。

用語を確認する（3語）
デプロイ
新しいプログラムを、実際に動かす環境へ配置・反映すること。
本番トラフィック
実際の利用者からアプリへ届くアクセスやリクエスト。
切り戻し
更新で問題が起きたとき、変更前の版や状態へ戻すこと。

1 条件を読む

練習するケース

ケース1の条件

新旧の同時稼働は検証済み。少量のリクエストで指標を確認し、合格したら範囲を広げたい。

  • 最初にごく一部の利用者のリクエストだけを新しい版へ送り、アプリケーションのエラー率や応答を観測する。
  • 基準を満たしたら範囲を広げ、満たさなければ広げずに戻したい。
  • 新旧の版の同時稼働は検証済み。
どちらのケースも共通の前提

Webアプリケーションの新しい版を展開する。ここでは更新の配り方を選び、別環境を作るかどうかは判断軸に含めない。事前の検証と、要件に対応した切り戻し手順を用意する。

2 答えを1つ選ぶ

最初の公開範囲と、停止・新旧混在の条件に合う更新方式はどれですか？

ケース1の回答

選択肢を1つ選ぶと、答え合わせできます。 ケースを切り替えると回答を選び直します。

3 2つのケースの答え・解説を比べる

両方を解いたら、条件と答えを並べて振り返りましょう。解く前に解説を読むこともできます。

ケース1 · 新旧の同時稼働は検証済み。少量のリクエストで指標を確認し、合格したら範囲を広げたい。

最初にごく一部の利用者のリクエストだけを新しい版へ送り、アプリケーションのエラー率や応答を観測する。基準を満たしたら範囲を広げ、満たさなければ広げずに戻したい。新旧の版の同時稼働は検証済み。

答え：カナリア：最初は少量の本番トラフィックだけを新しい版へ送り、観測してから段階的に広げる

× 選択肢1：ローリング：既存の更新対象を複数のバッチに分けて順番に更新する
バッチ更新だけでは、最初に少量の本番トラフィックを使って観測する手順を必ずしも持たない。ローリングへその条件を追加したカナリア方式が、今回の要求をより直接表す。
○ 選択肢2：カナリア：最初は少量の本番トラフィックだけを新しい版へ送り、観測してから段階的に広げる
最初の影響範囲を少量に絞り、本番の指標を確認してから広げる方針がカナリアに当たる。進行条件と中止条件を設定しておく。
× 選択肢3：一括：指定した更新対象を一度に新しい版へ切り替える
一度に全対象を切り替えるため、最初に少量のリクエストだけで観測する段階を設けるという要件に合わない。

カナリアは最初の影響範囲と観測の方針。ブルー／グリーンの環境構成やローリング更新と組み合わせる場合があり、常に排他的な分類ではない。

ケース2 · 停止時間は承認済み。保守中に全対象を更新し、先行公開やバッチごとの再開は行わない。

対象の全インスタンスで、新旧の版を混在させない運用が必要。利用者向けの停止時間が承認されており、トラフィックを止めた保守時間内に全対象を更新する。今回は少量への先行公開やバッチごとの再開を行わない。

答え：一括：指定した更新対象を一度に新しい版へ切り替える

× 選択肢1：ローリング：既存の更新対象を複数のバッチに分けて順番に更新する
更新対象をバッチに分けると更新途中に新旧の版が残る。全対象を一斉に更新し、バッチごとの再開をしないという指定と異なる。
× 選択肢2：カナリア：最初は少量の本番トラフィックだけを新しい版へ送り、観測してから段階的に広げる
少量だけを新しい版へ先行公開して観測する期間を設けるので、今回の一斉更新・先行公開なしという運用に合わない。
○ 選択肢3：一括：指定した更新対象を一度に新しい版へ切り替える
全対象を一度に更新する方針が、承認済みの停止時間内で版を一斉にそろえる条件に合う。失敗時の再展開や復旧に要する時間も計画する。

常に段階的な公開が正解になるわけではない。許容停止時間、版の混在可否、最初の影響範囲をそろえて配り方を選ぶ。

公式資料・復習メモ・確認記録学習マップのタスク2.1を見る

SAP-C02 · 条件比較の練習

AWS DMS：データを移す前に、保存先の準備はできている？

業務を続けながらデータベースをAWSへ移し、最後に接続先を切り替えます。

まずケース1で答えを選びます。解説を読んだらケース2へ進み、選ぶ理由の違いを確かめましょう。

比べるポイント

ケース1は同じエンジンで準備・検証済み。ケース2は異なるエンジンで、変換できるかの確認から必要。

用語を確認する（3語）
スキーマ
テーブルや索引など、データベースの構造を定めるもの。移行では関連するコードの互換性も確認する。
全件ロード
移行元にある既存データを、移行先へまとめてコピーする処理。
CDC
移行元で発生したデータの変更を取り込み、移行先へ継続して反映する仕組み。

1 条件を読む

練習するケース

ケース1の条件

同じエンジンの移行先は準備・検証済み。全件コピー中に続く業務更新も反映したい。

  • 同じデータベースエンジンへの移行で、必要なテーブル・索引・コード等を含む移行先スキーマは準備済み。
  • アプリケーションとの互換性も検証を終えている。
  • 未完了のスキーマ変換作業はない。
  • 次に必要なデータ移行の手順を選ぶ。
どちらのケースも共通の前提

業務データベースをAWSへ移行する。移行元と移行先は対象のAWS DMS機能でサポートされ、接続・権限・CDCに必要なログ設定は検証する。全件コピー中も元の業務更新を続け、最後に書き込みを止めて変更の反映と検証を終えてから接続先を切り替える。

2 答えを1つ選ぶ

移行先の準備状況に応じて、どの順序でデータを移しますか？

ケース1の回答

選択肢を1つ選ぶと、答え合わせできます。 ケースを切り替えると回答を選び直します。

3 2つのケースの答え・解説を比べる

両方を解いたら、条件と答えを並べて振り返りましょう。解く前に解説を読むこともできます。

ケース1 · 同じエンジンの移行先は準備・検証済み。全件コピー中に続く業務更新も反映したい。

同じデータベースエンジンへの移行で、必要なテーブル・索引・コード等を含む移行先スキーマは準備済み。アプリケーションとの互換性も検証を終えている。未完了のスキーマ変換作業はない。次に必要なデータ移行の手順を選ぶ。

答え：準備済みで互換性を確認した移行先スキーマへ、DMSの全件ロードとCDCを実行する

× 選択肢1：DMSの全件ロードだけを実行し、コピー中の更新は継続レプリケーションしない
全件ロード中も移行元の更新が続くため、全件ロードだけではその後の変更を継続反映するという要件を満たさない。
× 選択肢2：スキーマ変換の評価と必要な手動修正・検証を行い、移行先を準備してから全件ロードとCDCを実行する
異種エンジンの未変換スキーマがある場合は必要になるが、今回その作業は残っていない。すでに準備・検証済みの範囲へ変換工程を追加する条件ではない。
○ 選択肢3：準備済みで互換性を確認した移行先スキーマへ、DMSの全件ロードとCDCを実行する
必要なスキーマは準備・検証済みなので、次は既存データの全件ロードと、その間に発生した変更を反映するCDCを行う段階。切り替え時の残りの変更とデータ検証も確認する。

同種移行だから準備不要なのではなく、この問題ではスキーマ準備と互換性検証が済んでいる。残っている作業と、更新を止められる期間から選ぶ。

ケース2 · 異なるエンジンの移行先は未準備。構造・コードの変換を評価し、業務更新も反映したい。

異なるエンジンへの移行へ変更になった。移行先のスキーマはまだなく、ストアドプロシージャ等を自動変換できるかも未確認。必要な手動変換とアプリケーション検証を含めた移行順序を選ぶ。

答え：スキーマ変換の評価と必要な手動修正・検証を行い、移行先を準備してから全件ロードとCDCを実行する

× 選択肢1：DMSの全件ロードだけを実行し、コピー中の更新は継続レプリケーションしない
スキーマやコードの互換性確認が抜けるうえ、コピー中の更新も継続反映しないため、両方の要件を満たさない。
○ 選択肢2：スキーマ変換の評価と必要な手動修正・検証を行い、移行先を準備してから全件ロードとCDCを実行する
スキーマ変換の評価で自動変換できる対象と手動対応が必要な対象を確認し、修正・検証してからデータを移す。業務更新を続けるため、データ移行には全件ロードとCDCを組み合わせる。
× 選択肢3：準備済みで互換性を確認した移行先スキーマへ、DMSの全件ロードとCDCを実行する
この手順は互換性のあるスキーマが準備済みであることを前提にする。今回はその前提がなく、データの転送だけでプロシージャ等の互換性を保証できない。

データを追従させるCDCと、スキーマ・コードを移行先で動かす変換作業は別。評価レポートは手動対応の発見に使い、完全自動変換や無停止を前提にしない。

公式資料・復習メモ・確認記録学習マップのタスク4.2を見る

AWS SAPの試験概要・難易度・勉強方法

対象者、出題分野、受験料、学習時間の考え方を確認できます。

この案内の制作・更新：PASS QUEST。試験制度はAWSの公式資料、学習の判断例と時間予算は当サイトの提案です。生成AIの利用・確認範囲・訂正窓口を確認できます。

SAP-C02の出題分野と合格スコア：次に学ぶタスクを選ぶ

最低合格スコアは750です。結果は100〜1,000のスケールスコアで報告されます。これは問題セット間の難易度の差を調整するための尺度です。75%の正答が必要という意味ではありません。合否は試験全体で判定され、各分野で個別に合格点を取る仕組みではありません。

下の比重は採点対象の内容に対する公式の割合です。PASS QUESTの問題数配分や学習時間の推奨配分ではありません。「説明してみること」は当サイトの学習例で、各分野から1タスクを挙げています。

この表とスコアはSAP-C02の情報です。SAP-C03の比重や、C03追加編40問の対応範囲を示すものではありません。

SAP-C02：公式ガイドの4分野（分野名は日本語の要約）
分野・出題比重説明してみること・次の学習
D1 組織の複雑さに対応する設計26%

権限の付与と上限の制限を分け、委任先・監査先まで決める。

タスク1.2：組織のセキュリティ統制このタスクで週間計画を作るSCP・IAMとOU移動の具体例を読む
D2 新しいソリューションの設計29%

復旧時の構築を許すか、縮小した稼働環境を維持するかを費用と比較する。

タスク2.2：事業継続このタスクで週間計画を作る
D3 既存ソリューションの継続的な改善25%

推測でサービスを替えず、計測したボトルネックと改善後の指標を結ぶ。

タスク3.3：性能の改善このタスクで週間計画を作る
D4 ワークロードの移行とモダナイゼーションの加速20%

停止時間とエンジン差を分け、スキーマ変換・データ移動・切り替えを計画する。

タスク4.2：移行方法の選択このタスクで週間計画を作る

根拠：AWS公式SAP-C02試験ガイドの採点方法・出題範囲。確認日：。

AWS SAPはどんな人向け？ 推奨経験と受験条件

複数アカウントや組織の制約、既存システムの改善、移行を含めて設計を判断したい人。単一サービスの知識を、複数のシステムや関係者の条件につなげます。

AWS公式の推奨は、AWSサービスを使ったクラウドソリューションの設計・実装について2年以上の経験です。複雑な組織で、要件を評価して設計上の推奨を示す能力も対象者像に含まれます。 公式の対象者・推奨経験

推奨経験は学習の出発点を考える目安で、必要な実務年数としての受験条件とは分けて読みます。AWS公式は指定講座の受講を必須としていません。年齢、本人確認、申込時の同意などの条件は、AWS認定FAQと予約案内で確認してください。

「AWS SAP」の意味：このページはAWS認定 Solutions Architect - Professionalを扱います。業務ソフトウェアのSAPをAWSで動かす「SAP on AWS」とは別の話題です。SAP製品の導入・移行手順を探している場合、この資格教材はその手順書にはなりません。

AWS SAPの難易度：何を説明できるかで学習の入口を決める

SAPでは、技術的に実現できる案を見つけるだけでなく、組織の運用・移行期限・既存環境・費用などの制約を同時に扱う練習が必要です。SAAで扱う構成の理由に加え、変更の順番や複数環境へ展開する方法まで説明できるかを確認します。

例えばハイブリッドDNSでは、最初に「社内からAWSの名前を引く」のか「AWSから社内の名前を引く」のかを矢印で描きます。その後でVPCの数やルールの共有方法を考えます。複雑な問題ほど、先に条件を小さく分ける方が判断の抜けを見つけやすくなります。

DNSの問い合わせ方向を変える例を解説付きで確かめる

基本構成の理由が曖昧

SAAの設計例に戻り、ネットワーク・保存・可用性の選択理由を説明する。

長い要件から優先順位を選べない

期限・運用責任・障害時の要求を分け、変えられる条件と変えられない条件を書く。

正解の構成しか説明できない

不採用案の弱点だけでなく、どの条件ならその案を採用するかも書く。

ここでの分け方と学習例はPASS QUESTの提案です。公式の難易度評価や合格率のデータではありません。無料6問を全問正解しても、その6問での結果であり、試験全体の理解や合格を予測する数値にはなりません。AWS公式FAQは、合格に必要な正答数を公表していないと説明しています。公式FAQの試験の採点と内容を確認し、教材内の正答率と本試験の評価を区別してください。

AWS SAPの勉強時間は？ 必要時間と確保できる時間を分ける

このサイトでは、合格までの平均学習時間を測定していません。「何時間で合格」と一律には示せないため、今の知識で説明できないタスクと、生活の中で確保できる時間から計画を作ります。公式の推奨経験年数を、そのまま必要な勉強時間へ換算することもできません。

時間予算の計算例：平日に30分を3回取ると週90分。休日に60分を加えれば週150分（2時間30分）、同じ枠を4週間確保すると計10時間です。これは予定できる枠の計算で、10時間で試験範囲が終わる、あるいは合格できるという目安ではありません。

最初の週90分を使う架空の例

必要な学習時間の標準ではありません。1テーマを30分×3回で試し、実際に進んだ内容を見て次週の範囲を変えます。

  1. 1回目・30分：公式資料を読む

    Resolverの方向を確認し、社内とAWSの間に問い合わせの矢印を描く。

  2. 2回目・30分：演習で確かめる

    無料シナリオを1問読み、組織・移行・継続性に関する制約を抜き出す。

  3. 3回目・30分：条件を変えて振り返る

    DNSの比較で方向を変え、最初の案をそのまま使えない理由を説明する。

週末には「使った分数」「解説なしで説明できたこと」「残った疑問」を3行で残します。予定より調べ物に時間がかかったら、睡眠時間を削って問題数を合わせるより、次週の重点タスクを絞ります。時間が増えても同じ問題の正答だけが増えるなら、条件を変える演習や公式の問題形式で確かめる時間へ振り分けます。

自分の回数・時間で週間メモを作る問題集を選ぶ確認表を見る

この試験概要・対象者・時間予算の説明の更新日：。基本情報の確認資料は上記のAWS公式試験ページと認定FAQ（確認日：2026年9月17日）です。以下の演習・学習マップの技術資料は、それぞれに記載した確認時点と対象範囲に基づきます。

AWS SAPの勉強方法：範囲・判断・復習をつなぐ

  1. 公式の20タスクから組織・設計・改善・移行の範囲を確認し、自分が条件を分解しにくいタスクを1つ選びます。学習マップで範囲を確認する。
  2. 無料6問で答えと理由を確認し、条件比較では要件を切り替えて、選ぶ案が変わる理由を説明します。条件を変える演習へ進む。
  3. 説明できなかったタスクを次の重点にし、資料を読む・説明する・見直す予定を作ります。自分の1週間の学習計画を作る。

公式の推奨経験と出題範囲を確認し、使える学習時間は自分で決めてください。ここでの自己確認は試験の難易度・合格可能性や必要な学習時間を測定するものではありません。

説明できないところを、次の学習テーマにする

ここまでで迷った理由を、公式の出題範囲に結び付けます。学習マップの問いに答え、次に調べるタスクを1つ選びます。

PLAN YOUR NEXT SESSION

SAP-C02の学習マップ：20タスクから次に学ぶことを決める

公式ガイドのタスクに、PASS QUEST独自の「説明してみること」を添えました。まず気になる領域を開き、問いに自分の言葉で答えてみてください。

  1. 説明できたタスクにチェックする。
  2. 詰まったタスクを1つ選び、その公式資料と演習を読む。
  3. 「1週間の計画」で、説明し直す日を決める。

続きから使う場合は「この端末に保存」を選んでください。チェックした項目は、このブラウザーで次の学習日に読み戻せます。学習メモのダウンロードは、手元にファイルを残す操作です。

タスク一覧は2026年9月13日に公式ガイドと照合しました。シナリオ数は教材の制作時分類の集計です。全問題の技術的正確性や試験範囲の完全な習得を認定する数字ではありません。クイック90問はこの集計に含みません。

保存するのは自己確認のチェックだけです。サーバーには送らず、アプリの成績・購入情報とは別に扱います。保存を外すとこのコースの保存を削除します。別のブラウザーや端末とは共有しません。ブラウザーのデータを消すと失われるため、必要な記録はダウンロードしてください。

自己確認 0 / 20

D1 組織の複雑さに対応する設計 · 5タスク
D2 新しいソリューションの設計 · 6タスク
D3 既存ソリューションの継続的な改善 · 5タスク
D4 移行とモダナイゼーション · 4タスク

図や具体例で、設計を読み解く

権限、DBの改善、DNS、再試行を具体例で確かめます。

SAP-C02 DOMAIN 1 · ORGANIZATIONAL GOVERNANCE

OUを移すと、できる操作はどう変わる？

IAMが同じでも、OUの移動で継承するSCPが変わると、権限は減ることも増えることもあります。SCPは権限を与えず、許可の上限を定めます。新しい拒否だけでなく、移動によって失う拒否も確認しましょう。

SAP-C02のタスク1.2「組織のセキュリティ統制」を考える、独自の架空事例です。採点付きの無料6問とは別の読み物で、問題数には含みません。AWS実アカウントでの検証は行っていません。

要件：参照を続け、新規起動と終了は許可しない

1つのメンバーアカウントを、Sandbox OUからProduction OUへ移します。移動後も運用ロールでインスタンスの一覧を見られるようにし、新規起動と終了は拒否したいとします。移動前に、そのまま移してよいかを判断します。

無対策の移動では、新規起動が許可されて要件を満たしません。Productionという名前だけでは安全性は決まりません。このアカウントに新規起動のDenyを先に付け、移動しても禁止を維持する案を選びます。

なぜ禁止が外れるのでしょうか。ここでは、アカウントをまとめる階層（OU）と、許可の上限を決めるポリシー（SCP）を分けて追います。以下の前提を固定して、移動前・無対策の移動後・禁止を補った移動後を比べます。

  • 対象はメンバーアカウント内の通常のIAMロールです。IAMは一覧取得・新規起動・終了を許可し、停止は許可しません。このIAMの設定は3つの状態で同じです。
  • 組織の全機能とSCPは有効です。組織root・各OU・対象アカウントの各階層に、SCPのFullAWSAccessが付いています。比較する4操作に対するSCPのAllowは各階層にあり、図に示すもの以外の明示Denyはありません。
  • ResourceとConditionによる差や、アクセス許可境界・セッションポリシーなど、他の認可条件は結果を変えないものとして固定します。リソースベースポリシーによる権限付与も扱いません。

FullAWSAccessはここではSCPの名前であり、IAMの管理者権限を与える設定ではありません。「組織root」は組織ツリーの最上位で、管理アカウントやアカウントのrootユーザーとは別です。

同じアカウントの3つの状態を比較する

中央は失敗理由を読むための比較です。実施の順番ではありません。継続する禁止は、移動する前に補います。

共通の組織root

SCP：FullAWSAccess

移動前

↓ OUの層

Sandbox OU

  • SCP：FullAWSAccess
  • 追加SCP：RunInstancesをDeny

↓ アカウントの層

対象メンバーアカウント

  • SCP：FullAWSAccess
  • 追加のDenyなし

無対策で移動した場合

↓ OUの層

Production OU

  • SCP：FullAWSAccess
  • 追加SCP：TerminateInstancesをDeny

↓ アカウントの層

対象メンバーアカウント

  • SCP：FullAWSAccess
  • 追加のDenyなし

禁止を補って移動した後

↓ OUの層

Production OU

  • SCP：FullAWSAccess
  • 追加SCP：TerminateInstancesをDeny

↓ アカウントの層

対象メンバーアカウント

  • SCP：FullAWSAccess
  • RunInstancesをDeny

元のRunInstancesのDenyはSandbox OUだけにあります。無対策で移動すると、このDenyは継承されず、組織rootやアカウントに残るわけでもありません。

4操作を比較：新しく「許可」になる行も探す

表の「許可」は上記のIAM・SCPの前提での判定です。EC2操作の成功を意味しません。実際の新規起動には依存する操作の権限なども必要です。画面が狭い場合は表を横にスクロールできます。

IAMを変えずに、SCPの構成を変えた場合
操作 / IAMの設定移動前無対策で移動した場合比較用禁止を補って移動した後
一覧を見るec2:DescribeInstancesIAM：Allowあり許可IAMの許可があり、SCPの拒否はない。許可移動先でも、この操作をSCPは拒否しない。許可追加する拒否は新規起動だけ。参照は維持する。
新規起動するec2:RunInstancesIAM：Allowあり拒否Sandbox OUの明示Denyが適用される。許可元OUだけのDenyを失い、許可が広がる。拒否移動前にアカウントへ追加したDenyが残る。
終了するec2:TerminateInstancesIAM：Allowあり許可IAMの許可があり、移動前のSCPは拒否しない。拒否Production OUの明示Denyが適用される。拒否Production OUのDenyを引き続き受ける。
停止するec2:StopInstancesIAM：Allowなし拒否IAM側のAllowがない。拒否SCPで拒否されなくても、IAMの許可は増えない。拒否IAMは変更しないため、許可がないまま。

変更する順序と、確かめる結果

  1. 1. 継承経路と業務要件を残す

    元と移動先の組織rootからアカウントまで、各SCPと対象ロールのIAMを確認します。「拒否されるべき操作」と「継続すべき操作」を並べ、移動前の所属・ポリシー内容・添付先を記録します。変更と復旧を担当する権限も事前に確認します。

  2. 2. 検証用の環境で試し、移動前に禁止を補う

    本例では、このアカウントに限って新規起動の禁止を継続するため、RunInstancesを拒否するSCPをアカウントへ追加します。先に、同じ継承経路を再現した検証用OU・テストアカウントで、新規起動の拒否と必要な参照の継続を確認します。確認後、対象アカウントへ適用してから移動します。

    全アカウント共通の要件ならOUの方針として設計します。この1アカウントの移動のために、共有OU全体の許可を広げる必要はありません。

  3. 3. 1アカウントを移し、許可と拒否の両方を確認する

    移動後の所属と継承SCPを読み戻し、対象ロールの必要な通常処理が継続すること、新規起動・終了・未付与の停止が拒否されることを期待結果と照合します。APIの操作記録なども使って確認します。破壊的な操作の検証はテスト用リソースで計画し、本番の終了操作を試す手順にはしません。

  4. 4. 想定外なら広げず、検証済みの手順で戻す

    許可の拡大や必要な処理の停止があれば、他のアカウントへ展開しません。戻す場合も、移動で失うDenyを再確認します。新規起動・終了の禁止を復旧中も維持するなら、必要な拒否をアカウント側などで先に確保・検証してから元の所属へ戻します。元OUの禁止が再び適用されることを確認した後、今回追加したポリシーを残すか外すか判断します。SCPの無効化や一括解除を復旧手順にはしません。

下位にAllowを足せば、Denyを消せる？

消せません。適用されるSCPのどこかに明示Denyがあれば、下位OUのAllowやIAMのAdministratorAccessでは打ち消せません。拒否しているポリシーと要件を特定してから、変更の必要性を判断します。

この表を、そのまま使えない対象は？

SCPは管理アカウントのユーザー・ロールやサービスリンクロールを制限しません。一方、メンバーアカウントのrootユーザーは原則としてSCPの制限を受けます。外部アカウントの主体へのリソースベースの許可も、この通常のIAMロールの例とは分けて考えます。

Control Towerで管理するアカウントの登録・移動手順は、本例の対象外です。実環境ではSCP以外の統制や権限の条件も確認してください。

資料を閉じて、2つの理由を説明する

「無対策で移すと、新規起動ができるようになるのはなぜか」「新規起動のDenyを移動前に補うのはなぜか」を、自分の言葉で説明してください。説明できなかった点を次の学習に使えます。合否判定や習得率の測定ではありません。

タスク1.2の学習マップへこのタスクを1週間の学習計画にする

仕組みの根拠と、この事例の範囲

SCPの適用範囲・評価、OUによる継承、段階的な検証の考え方をAWS公式資料で2026年9月26日に確認しました。操作の組み合わせと変更計画はPASS QUESTが作成した架空の学習例です。実運用の成功実績や、SAP-C03の全試験範囲を示すものではありません。

SAP-C02 DOMAIN 3 · CONTINUOUS IMPROVEMENT

D3の解き方：既存DBの性能を、可用性を保って改善する

読み取り性能を改善する手段と、AZ障害に備える手段を分けて考えます。レポートを別の読み取り先へ移す案でも、最新データが必要な業務と追加費用を確認してから選びます。

D3は、SAP-C02の出題領域3「既存ソリューションの継続的な改善」です。ここでは、その判断手順を独自の架空事例で説明します。採点付きの無料6問とは別の読み物で、問題数には含みません。D3の性能・信頼性・コストを改善する観点を使います。

例：レポート処理で業務DBが遅くなった

RDS for PostgreSQLのMulti-AZ DBインスタンスを運用しています。集計レポートの読み取りが増え、業務画面の応答が遅くなりました。AZ障害時の自動フェイルオーバーは維持します。レポートには多少のデータ反映遅延を許容できますが、注文確定後の画面には最新のデータが必要です。

  1. 1. 変えてはいけない要件を先に固定する

    可用性と、読み取りに必要な鮮度を分けます。コストを下げるためにSingle-AZへ変更すると、維持すべき障害対策を失います。また、今回のMulti-AZ DBインスタンスのスタンバイは読み取りには使えません。読み取り可能なスタンバイを持つMulti-AZ DBクラスターとは区別します。

  2. 2. ボトルネックを測り、候補を比較する

    クエリの実行計画やDB負荷を調べます。非効率なクエリが原因ならクエリ・インデックスの改善を検討し、容量不足ならサイズ変更も比較します。遅延を許容するレポートの読み取り負荷を分離したい場合は、Multi-AZ構成を保ったままリードレプリカを追加し、対象レポートだけ接続先を分ける案が候補です。

    リードレプリカへの複製は非同期です。注文直後など最新データが必要な読み取りは、安易にレプリカへ移しません。レプリカには追加のインスタンス・ストレージ費用がかかるため、「追加すれば最安」とは判断できません。

  3. 3. 同じ負荷で、効果と副作用を確かめる

    変更前後で同じレポートと業務処理を実行し、アプリの応答時間のp95、DBのCPU使用率やReadLatency、レプリカのReplicaLag、追加費用を比べます。p95は応答の95%が収まる時間です。ReplicaLagだけで画面上の鮮度を保証せず、実データの反映遅延も要件と照合します。

    応答時間・許容遅延・費用の上限を事前に決め、満たせなければ対象レポートのレプリカ利用を止めて再評価します。プライマリへ戻す場合は負荷が再集中するため、レポートの実行制限も含めて切り戻しを用意します。この事例の数値効果は未測定です。

技術的な前提をAWS公式資料で確認（2026年9月10日確認）

SAPの無料例題を読む

60のVPCとオンプレミス。DNSの向きをどう分ける？

Route 53 Resolverのinbound・outboundと、AWS RAMで共有するルールを、既存の無料シナリオ1問で整理します。問題文、5つの選択肢、選ぶ理由と選ばない理由を登録なしで読めます。

inbound / outboundの違いを無料例題で読む
再試行と二重処理をSQLiteで確かめる

D3：既存DBの性能・可用性・コストを考える解説例

再試行で二重処理しない？ 停止位置を変えた7つの実験

ローカルのSQLiteで同じイベントを再処理したところ、処理済みの印だけを先に確定すると反映が欠落しました。また、DBの外への追記は、DB内で一連の更新をまとめて確定するトランザクションだけでは重複を防げませんでした。

どこで止まると結果が変わるのか。専用ページでは、入力・中断位置・観測値を比べ、再現コードで確かめられます。

固定した7ケースのローカル実測です。AWS実機の配信保証、実システム全般の安全性、試験の出題を証明するものではありません。

冪等性の7ケース・実測結果・再現手順を読む

次の1週間にやることを決める

苦手が1つ見つかったら、資料を読む・自分で説明する・説明を直す、の3つを予定にします。下の2週間の記入例を参考に、自分の1週間を組み立ててください。

1週間の学習計画を作る

SAP-C02の勉強記録：何を直し、次の週に何を学ぶ？

合格までの総学習時間を一律には示せません。代わりに、最初の説明・根拠で直した点・条件を変えた判断を残し、次に学ぶタスクを選びます。下は、時間が足りなかった週も含めた記入済みの例です。

2週分とも架空の学習記録です。週数・時間は予定と記入方法を示す設定で、合格所要期間や利用者の実績ではありません。試験全体の学習計画・本番問題・合格予測ではなく、収録問題数にも含めません。

この記録はSAP-C02のタスクを使います。SAP-C03の全範囲計画ではありません。

  1. 1週目・タスク1.2：「OUを移してもIAMが同じなら権限も同じ」を直す

    予定：3回 × 45分 = 135分 ／ 記入例の実施：2回 × 45分 = 90分

    1回目にSCPの継承経路を図にした。2回目にOU移動の4操作を比較。3回目の切り戻し説明はできず、翌週へ回した。

    最初の説明（訂正前）
    「IAMを変えなければ、OU移動後も許可される操作は同じ。」
    公式資料で確かめて直した説明
    「通常のメンバーアカウントのロールでも、移動で継承SCPが変わる。この例ではSandboxだけのRunInstancesのDenyを失うと許可が広がり、ProductionのTerminateInstancesのDenyで別の操作は拒否される。」
    条件を変えて、選び直した結果
    移動前にアカウント側へRunInstancesのDenyを補う条件へ変更。新規起動は禁止を維持できる。StopInstancesはIAM Allowがないため、SCPで拒否しなくても許可されない。いずれも具体例の限定モデルでの判定。
    終わらなかったこと・次に残すこと
    持ち越し1回・45分：元OUへ戻すと失うDenyを確認し、必要な禁止をどこに残すか説明する。実AWSでの移動・認可検証は行わない。

    翌週を決める条件

    同じタスクを続ける： SCPを許可の付与と捉えたり、切り戻し時の制限を落とすなら、1.2を続ける。

    別のタスクへ進む： 4操作の変化と切り戻しの確認点を説明できたら、3.3のDB改善へ。管理アカウントやサービスリンクロールへ同じ表を当てはめない。

    この訂正の技術的な根拠

    対応する既存解説の資料確認日：。リンク先の前提・対象外も合わせて確認してください。

  2. 2週目・タスク3.3：変更で失う条件を、DB改善でも先に書く

    予定：2回 × 45分 = 90分 ／ 記入例の実施：2回 × 45分 = 90分

    1回目にOUを戻すと失う制限と、その維持方法を説明して資料で確認。2回目は既存DBの読み取りを分ける案を、鮮度と可用性から検討した。

    最初の説明（訂正前）
    「RDSの読取処理を全部レプリカへ送れば、性能問題は解決する。」
    公式資料で確かめて直した説明
    「まず負荷を測る。PostgreSQLのMulti-AZ DBインスタンスで、遅延を許すレポートはリードレプリカへの分離が候補。注文直後の最新データを要する参照まで移さない。既存の可用性も維持する。」
    条件を変えて、選び直した結果
    レポートにも即時の反映を要求する条件へ変更。非同期レプリカへの振り分けをそのまま採用せず、クエリ・インデックス改善やサイズ変更を含めて再検討する。
    終わらなかったこと・次に残すこと
    応答時間・鮮度・費用の許容値は未設定。翌週はp95、実データの反映遅延、追加費用と、条件を満たさない場合の戻し方を記入する。性能向上は未測定。

    翌週を決める条件

    同じタスクを続ける： 改善効果だけを考え、鮮度・費用・切り戻しを説明できなければ、3.3を続ける。

    別のタスクへ進む： 変更前に守る条件、比べる指標、中止条件を書けたら、未確認の4.2の移行方法へ。実機検証の代わりにはしない。

    この訂正の技術的な根拠

    対応する既存解説の資料確認日：。リンク先の前提・対象外も合わせて確認してください。

自分の記録では、上の正答を書き写す前に説明してみてください。次週の最初に持ち越しを置き、まだ説明できなければ新しいテーマを減らします。時間やチェック数が増えても、試験の準備が完了したとは判断しません。

記入例の制作：PASS QUEST・2026年9月26日。生成AIを用いた独自の架空例です。制作・確認範囲と訂正窓口を確認できます。公式資料は技術的な説明の根拠であり、この週数や学習時間の効果を証明するものではありません。

受験予約・資格の更新・公式資料

受験前に確かめる条件と、AWS公式の案内へ進みます。

申し込む前と、取得した後

AWS SAPの受験条件・予約・資格の更新

制度・料金の確認日：2026年9月26日。初回の受験予約と、すでに保有している資格の再認定を分けて確認します。

先に別の資格や指定研修を終える必要はある？

SAAの取得は、SAPを受けるための必須条件ではありません。AWS指定トレーニングの受講も必須ではありません。これは受験の前提条件の話で、推奨される知識・経験や、学習の準備ができているかとは別です。

年齢・本人確認・規約への同意などの条件は残ります。13〜17歳は親権者の同意が必要です。オンラインと会場では身分証明書の要件が異なるため、自分の受験形式の条件を確認してください。

根拠：AWS「試験前」の資格・本人確認条件、必須トレーニングに関する公式FAQ。

受験料と、予約前後のチェックリスト

日本円の通常試験料金は40,000円／1回（Professional区分の公式掲載額）です。税が適用される場合があるため、割引の適用を含む最終金額は予約画面で確認します。PASS QUESTの教材代とは別の料金です。

  1. 予約前に配慮の要否を確認する。特別な配慮が必要なら、試験を予約する前に申請します。承認後の予約方法は案内に従ってください。
  2. AWS認定アカウントを準備する。AWSサービスを利用するアカウントとは別です。身分証明書と登録名が一致するかを確認し、「新しい試験を予約」から進みます。
  3. 試験・言語・受験形式・日時を照合する。試験名とコードを確認してPearson VUEへ進み、会場またはオンラインを選びます。試験問題の言語と監督員の対応言語、日時・タイムゾーン、最終料金と規約を確かめてから予約を確定します。 SAPはC02とC03の提供日程・範囲の違いも照合してください。
  4. 確認メールを最後まで読む。予約した試験と日時、本人確認・チェックインの条件を再確認します。オンラインなら受験環境の要件、会場なら所在地と当日の案内も確認しておきます。

公式の料金表・配慮申請・予約手順を確認する。

取得後はどう更新する？

有効期限が切れる前に再認定を完了します。以下は現在有効な資格を保有する人の方法で、期限切れ後にそのまま使えるとは限りません。

3年更新する方法
Solutions Architect - Professionalの最新版の試験に合格して更新します。取得時と同じ試験コードを再受験するとは限らないため、提供中の版を確認します。
Skill Builderで1年維持する方法
有効期限まで90日以内の有効な資格と、AWS Skill Builderの有効な有料サブスクリプション（月次・年間・チーム）が条件です。対象の維持アクティビティを完了する方法で、契約するだけで更新されるわけではありません。

新しい有効期間は再認定の完了日が起点です。元の有効期限に3年や1年を足す計算にはしません。まずAWS認定アカウントで自分の資格名と期限を確認し、利用する方法を選んでください。

出典：AWS公式の再認定一覧・参加条件・有効期間の計算。試験コードの提供期間と、取得した資格の有効期限は別です。

AWS公式 試験ガイドAWS公式 試験準備

教材の範囲と購入版について

この試験は390問（無料6問を含む）。購入版は全教材共通・1,000円の買い切りです。

AWS SAPの難易度を考える確認点

取り組みやすさは経験によって変わります。次の判断を自分の言葉で説明できるか、無料問題と条件比較で確かめましょう。

  • 複数アカウント・組織をまたぐ設計判断
  • 移行、継続性、ガバナンスの制約整理
  • 複数の実現案から優先要件に合う案を選ぶ視点

390問の内訳

クイック90問とシナリオ300問、合計390問には無料6問を含みます。無料体験はクイック3問とシナリオ3問、購入後のシナリオは1回12問です。

購入は共通です。既存3資格1,170問＋C03追加編40問、無料26問を含む合計1,210問（有料分1,184問）を、1,000円の買い切りで利用できます。

  1. まずSAPの無料クイック3問で、解説の読みやすさを確かめる。
  2. 無料シナリオ3問を解き、回答と自信に応じた復習候補から理由を読み返す。
  3. 続けたいと感じたら購入し、同じSAPの全390問で別の要件にも取り組む。

解説を読んだら、自分で答えてみよう。

SAP-C02の無料6問は、登録・カード入力なしで始められます。

AWS SAPの無料6問を解く

全1,210問・1,000円の購入案内

ほかのAWS資格を見る（CLF・SAA・SAP）

目安レベル：CLF

AWS CLF

CLF-C02

クラウドの基本と、安全で無理のない選び方から。

AWS CLFの無料問題・学習マップ

目安レベル：SAA

AWS SAA

SAA-C03

よくある要件を整理して、適切な構成を選ぶ。

AWS SAAの無料問題・学習マップ

目安レベル：SAP

AWS SAP

SAP-C02

複数の制約をほどき、設計上のトレードオフを見抜く。

AWS SAPの無料問題・学習マップ