以下は問題1を指定のフォーマットで整理した内容です。
■ 問題文（編集せずに出力）
ソリューションアーキテクトは、複数のチームで構成される企業の AWS アカウント構造を設計しています。すべてのチームは同じ AWS リージョンで作業します。同社は、オンプレミスのネットワークに接続された VPC が必要です。同社は、オンプレミスネットワークとの間の合計トラフィックが 50 Mbps 未満になると予想しています。
これらの要件を最もコスト効率よく満たす手順の組み合わせを選択してください。(2 つ選択)
■ 選択肢（編集せずに出力）
- A. VPC と必要なサブネットをプロビジョニングする AWS CloudFormation テンプレートを作成します。テンプレートを各 AWS アカウントにデプロイします。
- B. VPC と必要なサブネットをプロビジョニングする AWS CloudFormation テンプレートを作成します。テンプレートを共有サービスアカウントにデプロイします。AWS Resource Access Manager を使用してサブネットを共有します。
- C. オンプレミスネットワークへの接続には、AWS Transit Gateway と AWS Site-to-Site VPN を使用します。AWS Resource Access Manager を使用して Transit Gateway を共有します。
- D. オンプレミスネットワークへの接続には AWS Site-to-Site VPN を使用します。
- E. オンプレミスネットワークへの接続には AWS Direct Connect を使用します。
■ 問題文の要件の概要
- 複数チーム間の AWS アカウント設計
- 同一リージョン内の作業
- オンプレミスネットワークとの接続が必要
- トラフィックは 50 Mbps 未満
- コスト効率重視
✅ 正解の選択肢と解説
- 正解：B と D
B. CloudFormation + Resource Access Manager (RAM)
- 中央の共有サービスアカウントで VPC を構築し、AWS RAM を用いてサブネットを各アカウントと共有することで、リソースの集中管理・ガバナンスが可能。
- 各チームは同一リージョン内でその共有サブネットを使用できるため、VPC ピアリングや重複構築の無駄を回避できる。
D. AWS Site-to-Site VPN
- IPsec VPN によりオンプレミスと VPC を暗号化接続できる。
- 50 Mbps 未満の帯域に対して、最も安価かつ迅速に導入可能なハイブリッド接続手段。
- 初期費用不要・使用量ベース課金で、固定費も最小化できる。
❌ 不正解の選択肢の理由
A. CloudFormation を各アカウントにデプロイ
- 各アカウントに個別に VPC を構築することで、ネットワークが分散し、重複と運用負荷が増加。
- RAM を使った共有が前提の設計に比べて管理コストと複雑性が高く非効率。
C. Transit Gateway + Site-to-Site VPN
- Transit Gateway は高トラフィック/複数VPC接続向けで、50 Mbps では過剰設計かつコストが高い。
- VPN単体で十分な構成であり、TGW利用によりコストが不要に増加する。
E. Direct Connect
- 専用線で1Gbps以上のポート契約が必要で、月額固定費も高額。
- 本問の50 Mbpsの軽量トラフィック要件とは不釣り合いで、費用対効果が悪い。
🎯 SAP試験で押さえておくべきポイント
- 複数アカウント間でVPCリソースを共有するには AWS Resource Access Manager (RAM) を使う。
- 低帯域のオンプレミス接続には Site-to-Site VPN が最もコスト効率に優れる（低コスト・早期導入・高可用性）。
- Transit Gateway や Direct Connect は中〜大規模接続向け。帯域・用途に応じた選定が必要。
- VPCの集約設計 + RAM の活用により、重複インフラ構築を避け、コスト最適化とガバナンスを両立できる。
引き続き問題があれば、同じ形式で対応しますのでお知らせください。
以下は問題2を指定のフォーマットで整理した内容です。
■ 問題文（編集せずに出力）
ある企業が、ユーザー用の登録フォームを含む、認証されていない静的ウェブサイト (www.example.com) を運営しています。このウェブサイトは、ホスティングに Amazon S3 を使用し、AWS WAF が設定されたコンテンツ配信ネットワークとして Amazon CloudFront を使用します。登録フォームが送信されると、ウェブサイトは Amazon API Gateway API エンドポイントを呼び出し、AWS Lambda 関数を呼び出してペイロードを処理し、ペイロードを外部 API 呼び出しに転送します。
テスト中、ソリューションアーキテクトは Cross-Origin Resource Sharing (CORS) エラーに遭遇しました。ソリューションアーキテクトは、CloudFront ディストリビューションのオリジンに、Access-Control-Allow-Origin ヘッダーが www.example.com に設定されていることを確認します。
このエラーを解決する最適な方法を選択してください。
■ 選択肢（編集せずに出力）
- A. S3 バケットの CORS 設定を変更します。www.example.com の AllowedOrigin 要素に CORS のルールを追加します。
- B. AWS WAF で CORS 設定を有効にします。Access-Control-Allow-Origin ヘッダーが www.example.com に設定される ウェブ ACL ルールを作成します。
- C. API Gateway API エンドポイントの CORS 設定を有効にします。Access-Control-Allow-Origin ヘッダーが www.example.com に設定されているすべての応答を返すように API エンドポイントが構成されていることを確認します。
- D. Lambda 関数の CORS 設定を有効にします。関数のリターンコードに Access-Control-Allow-Origin ヘッダーが www.example.com に設定されていることを確認します。
■ 問題文の要件の概要
- 登録フォームを含む静的WebサイトがS3+CloudFrontでホストされている
- フォーム送信時、API Gateway → Lambda → 外部APIへリクエスト
- ブラウザでCORSエラー発生
- CloudFrontのオリジンレスポンスに
Access-Control-Allow-Originが存在 - CORSエラーの最適な解決策を選択
✅ 正解の選択肢と解説
- 正解：C
C. API Gateway API エンドポイントの CORS 設定を有効にする
- API Gateway は、クロスオリジン通信が発生するHTTPリクエストの入り口。
- CORSを有効にすると、自動的に
Access-Control-Allow-OriginやAccess-Control-Allow-Methods等のヘッダーがレスポンスに付与され、プリフライトリクエスト（OPTIONS）も正しく処理される。 - Lambda などの後段でヘッダーを返しても意味がなく、API Gateway で明示的に設定することが必要かつ正解。
❌ 不正解の選択肢の理由
A. S3 バケットの CORS 設定を変更する
- S3 の CORS 設定は S3オブジェクトへのアクセスにのみ適用され、API Gateway へのリクエストには影響しない。
- 登録フォームは API Gateway エンドポイントに送信されるため、S3の設定を変更してもCORSエラーは解決しない。
B. AWS WAF で CORS 設定を有効にする
- AWS WAF はリクエストをフィルタリングするサービスであり、レスポンスの内容（ヘッダーなど）を変更できない。
Access-Control-Allow-Originなどのレスポンスヘッダーを付加する機能は存在しないため、CORS問題の解決策にはならない。
D. Lambda 関数で CORS ヘッダーを返す
- Lambda 関数は API Gateway の後段で実行される。
- ブラウザが実行するプリフライト OPTIONS リクエストは Lambda に到達しないため、Lambda 側のレスポンスにヘッダーを付けても CORS エラーは解決できない。
🎯 SAP試験で押さえておくべきポイント
- CORSの起点はフロントエンドからのHTTPリクエストがどこに届くかに注目する。
- API Gateway で CORS を正しく設定し、OPTIONS リクエストにも適切なレスポンスを返す必要がある。
- Lambda でのヘッダー追加は最終応答用であり、プリフライトには無関係。
- WAF はリクエスト制御のみ、S3のCORSはS3リクエストにのみ有効という作用範囲を明確に覚える。
- **ブラウザがCORSエラーを出すのは「レスポンスに必要なCORSヘッダーがない場合」**であり、ヘッダーが返されるレイヤーを理解するのが鍵。
次の問題があれば、引き続き同じ形式で解説いたします。お気軽にどうぞ。
以下は問題3を指定のフォーマットで整理した内容です。
■ 問題文（編集せずに出力）
ある企業が AWS CloudFormation を使用して、Transit Gateway に接続された複数の VPC 内にアプリケーションをデプロイしています。パブリックインターネットにトラフィックを送信する各 VPC は、共有サービス VPC 経由でトラフィックを送信する必要があります。VPC 内の各サブネットはデフォルト VPC ルートテーブルを使用し、トラフィックは Transit Gateway にルーティングされます。Transit Gateway は、VPC アタッチメントに対してデフォルトのルートテーブルを使用します。
セキュリティ監査により、VPC 内にデプロイされた Amazon EC2 インスタンスが、会社の他の VPC にデプロイされた EC2 インスタンスと通信できることが判明しました。ソリューションアーキテクトは、VPC 間のトラフィックを制限する必要があります。各 VPC は、事前に定義された限定された VPC としか通信できないようにする必要があります。
これらの要件を満たす最適な方法を選択してください。
■ 選択肢（編集せずに出力）
- A. VPC 内の各サブネットのネットワーク ACL を更新して、承認された VPC へのアウトバウンドトラフィックのみを許可します。デフォルトの拒否ルールを除くすべての拒否ルールを削除します。
- B. VPC 内で使用されているすべてのセキュリティグループを更新して、未承認の VPC 内で使用されているセキュリティグループへのアウトバウンドトラフィックを拒否します。
- C. VPC アタッチメントごとに専用の Transit Gateway ルートテーブルを作成します。許可された VPC にのみトラフィックをルーティングします。
- D. 各 VPC のメインルートテーブルを更新して、Transit Gateway を介して承認された VPC にのみトラフィックをルーティングします。
■ 問題文の要件の概要
- CloudFormation で Transit Gateway 経由に複数 VPC を構成
- 各 VPC は共有サービス VPC を通じてインターネットアクセス
- Transit Gateway のデフォルトルートテーブルが使用されている
- VPC 間通信を制限したい
- 各 VPC が事前定義の限られた VPC のみと通信できるようにしたい
✅ 正解の選択肢と解説
- 正解：C
C. Transit Gateway アタッチメントごとに専用ルートテーブルを作成
- Transit Gateway ルートテーブルは、各アタッチメントごとに個別定義可能。
- アタッチメントごとに異なるルートテーブルを使うことで、許可された通信先のみを明示的にルーティング可能。
- 結果として、未承認のVPCとの通信経路が存在しなくなり、通信が遮断される。
- CloudFormationでも自動化可能で、スケーラブルかつ管理しやすいアプローチ。
❌ 不正解の選択肢の理由
A. ネットワークACLで制御
- NACLはステートレスであり、双方向にルールが必要。
- また、CIDRベースで指定するため、未承認VPCが増えると管理が煩雑でルール数の制限にも引っかかる。
- ACLの粒度と運用負荷の観点から現実的でない。
B. セキュリティグループで未承認VPCをブロック
- セキュリティグループは「許可」しかできず、「拒否」はできない。
- 未承認VPCの通信をブロックするには不向き。
- また、セキュリティグループ間の参照は同じアカウントまたは共有されたセキュリティグループでのみ有効。
D. 各VPCのルートテーブルを更新
- VPC側のルートテーブルを制限しても、Transit Gateway のルートテーブルが共通であれば、他VPCからの通信が届く可能性がある。
- 片方向のみの制限では双方向のトラフィック制御は不完全。
- 正しくはTransit Gateway 側でルート分離を実施すべき。
🎯 SAP試験で押さえておくべきポイント
- Transit Gateway ルートテーブルはアタッチメントごとに分離可能。
- これにより、個別のVPCごとに異なる通信ポリシーを適用できる。
- セキュリティグループは拒否ルールを持たないため、アクセス制限には適さない。
- NACLはCIDRベースでの制御が可能だが、ルール数制限と運用負荷が高い。
- 通信経路をコントロールしたい場合はルーティングレイヤー（Transit Gateway）で制御するのがベストプラクティス。
- SAPレベルでは、構成の分離と拡張性を考慮したセキュリティ設計が問われる。
次の問題があれば、引き続き対応いたします。お気軽に送信してください。
以下は問題4を指定のフォーマットで整理した内容です。
■ 問題文（編集せずに出力）
ある企業はアプリケーションを AWS に移行することを計画しています。アプリケーションは Docker コンテナとして実行され、NFS バージョン 4 のファイル共有を使用しています。
ソリューションアーキテクトは、基盤となるインフラストラクチャのプロビジョニングや管理を必要としない、安全でスケーラブルなコンテナ化ソリューションを設計する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. Fargate 起動タイプで Amazon Elastic Container Service (Amazon ECS) を使用して、アプリケーションコンテナをデプロイします。共有ストレージに Amazon Elastic File System (Amazon EFS) を使用します。ECS タスク定義で、EFS ファイルシステム ID、コンテナマウントポイント、および EFS 認証 IAM ロールを参照します。
- B. Fargate 起動タイプで Amazon Elastic Container Service (Amazon ECS) を使用して、アプリケーションコンテナをデプロイします。共有ストレージに Amazon FSx for Lustre を使用します。ECS タスク定義で、FSx for Lustre ファイルシステム ID、コンテナマウントポイント、および FSx for Lustre 認証 IAM ロールを参照します。
- C. Amazon EC2 起動タイプと Auto Scaling を有効にして、Amazon Elastic Container Service (Amazon ECS) を使用してアプリケーションコンテナをデプロイします。共有ストレージに Amazon Elastic File System (Amazon EFS) を使用します。ECS コンテナインスタンスに EFS ファイルシステムをマウントします。EC2 インスタンスプロファイルに EFS 認証 IAM ロールを追加します。
- D. Amazon EC2 起動タイプと Auto Scaling を有効にして、Amazon Elastic Container Service (Amazon ECS) を使用してアプリケーションコンテナをデプロイします。共有ストレージにマルチアタッチを有効にした Amazon Elastic Block Store (Amazon EBS) ボリュームを使用します。EBS ボリュームを ECS コンテナインスタンスにアタッチします。EC2 インスタンスプロファイルに EBS 認証 IAM ロールを追加します。
■ 問題文の要件の概要
- アプリケーションは Docker コンテナベース
- NFSv4 共有ストレージを利用
- インフラ管理不要（マネージドサービス）
- スケーラブルかつセキュアな設計
✅ 正解の選択肢と解説
- 正解：A
A. ECS Fargate + EFS
- Fargateはインフラ管理不要なサーバーレスなコンテナ実行環境。
- Amazon EFSはNFSv4準拠のマネージド共有ファイルシステムで、Fargateからマウント可能。
- ECSのタスク定義でEFSの情報を設定することで、自動でマウントされる。
- IAMロールでEFSアクセス制御も可能で、セキュアな運用が可能。
- これらにより、要件である「基盤管理不要」「NFSv4対応」「セキュア」「スケーラブル」をすべて満たす。
❌ 不正解の選択肢の理由
B. FSx for Lustre は NFSv4 に非対応
- Lustreは独自プロトコルを使用し、Fargateでマウントできない。
- HPC向けであり、本設問の共有ファイル要件に不適切。
C. EC2起動タイプ + EFS は基盤管理が必要
- EC2起動タイプはインスタンスのプロビジョニング、パッチ適用、スケーリングなどをユーザーが管理。
- 問題文の「インフラのプロビジョニングや管理不要」という条件を満たさない。
D. EC2起動タイプ + EBS マルチアタッチ
- EBSはブロックストレージであり、ファイルレベル共有やマルチAZでの共有には非対応。
- マルチアタッチも同一AZかつEC2に限定され、FargateやNFSv4用途には不向き。
■ SAP試験で押さえておくべきポイント
- Fargate：インフラ管理不要なサーバーレスコンテナ実行基盤
- EFS：NFSv4互換のマネージド共有ストレージ。Fargateとも統合可能
- FSx for Lustre：HPC用ファイルシステム。Fargateからの直接マウントは不可
- EBSはブロックレベルストレージで、コンテナ間のファイル共有には不向き
- 基盤管理不要という要件がある場合、Fargate + EFSが第一選択肢になりやすい
次の問題もあれば、引き続きお送りください。
以下は問題5の出力結果です。
■ 問題文（編集せずに出力）
ある企業が、Application Load Balancer (ALB) の背後にある 4 台の Amazon EC2 インスタンスで動作するウェブサイトを持っています。ALB が EC2 インスタンスが利用できなくなったことを検出すると、Amazon CloudWatch アラームが ALARM 状態になります。次に、会社の運用チームのメンバーが、ALB の背後に新しい EC2 インスタンスを手動で追加します。
ソリューションアーキテクトは、EC2 インスタンスの置き換えを自動的に処理する高可用性ソリューションを設計する必要があります。同社は、新しいソリューションへの切り替え時のダウンタイムを最小限に抑える必要があります。
これらの要件を満たす最適な一連の手順を選択してください。
■ 選択肢（編集せずに出力）
- A. 既存の ALB を削除します。ウェブアプリケーションのトラフィックを処理するように構成された Auto Scaling グループを作成します。新しい起動テンプレートを Auto Scaling グループにアタッチします。新しい ALB を作成します。新しい ALB に Auto Scaling グループをアタッチします。既存の EC2 インスタンスを Auto Scaling グループにアタッチします。
- B. ウェブアプリケーションのトラフィックを処理するように構成された Auto Scaling グループを作成します。新しい起動テンプレートを Auto Scaling グループにアタッチします。Auto Scaling グループを既存の ALB にアタッチし、既存の EC2 インスタンスを Auto Scaling グループにアタッチします。
- C. 既存の ALB と EC2 インスタンスを削除します。ウェブアプリケーションのトラフィックを処理するように構成された Auto Scaling グループを作成します。新しい起動テンプレートを Auto Scaling グループにアタッチします。新しい ALB を作成します。新しい ALB に Auto Scaling グループをアタッチします。Auto Scaling グループが最小数の EC2 インスタンスを起動するまで待ちます。
- D. ウェブアプリケーションのトラフィックを処理するように構成された Auto Scaling グループを作成します。新しい起動テンプレートを Auto Scaling グループにアタッチします。Auto Scaling グループを既存の ALB にアタッチします。既存の ALB が既存の EC2 インスタンスを Auto Scaling グループに登録するまで待ちます。
■ 問題文の要件の概要
- ALB 配下に EC2 が4台稼働している
- ヘルスチェック失敗時は手動でEC2を追加している
- EC2インスタンスの自動置換を行いたい
- ダウンタイムを最小限に抑えたい
- 高可用性（HA）ソリューションの設計が求められている
✅ 正解の選択肢と解説
- 正解：B
解説：
- Auto Scaling グループ（ASG）を作成し、ヘルスチェックで異常なインスタンスを自動で置換可能にします。
- 新しい起動テンプレートを ASG にアタッチすることで、インスタンスの再起動時に最新構成を適用できます。
- 既存の ALB をそのまま利用し、ASG と関連付けることで、DNS名やTLS証明書の再設定が不要で、トラフィックの中断なし。
- 既存の EC2 インスタンスを一時的に ASG に登録することで、移行中のダウンタイムを回避可能です。
❌ 不正解の選択肢の理由
A：
- ALBを削除・再作成しているため、既存のDNS名やTLS設定が無効化され、即座にアクセス不能になる可能性あり。
- 切替時にダウンタイムが発生するため、要件を満たさない。
C：
- ALBとEC2を同時に削除してからASG構築する手順。
- 新しいインスタンスの起動まで完全なサービス停止が発生するため、ダウンタイム最小化という要件を満たさない。
D：
- ALB が ASG に既存インスタンスを自動的に登録することはない。
- ASG に明示的に EC2 を登録しない限り、自己修復やスケーリングが機能しないため、誤り。
🎯 SAP試験で押さえておくべきポイント
- **Auto Scaling グループ（ASG）**はEC2のヘルスチェックを元に、異常インスタンスを自動で再作成できる。
- ALBとASGは連携可能で、DNS名を変えずにトラフィックを維持できる。
- 既存のEC2インスタンスをASGにアタッチすることで、スムーズな移行が可能。
- ASGを導入する際に既存のALBやEC2を削除してはいけない。段階的な移行がベストプラクティス。
- **「ダウンタイム最小化」や「可用性向上」**の要件では、DNSやTLS証明書の再構成を伴う作業は極力避ける。
次の問題があれば、引き続きご提供ください。丁寧に解析・整理いたします。
以下は問題6の出力結果です。
■ 問題文（編集せずに出力）
ある企業は、オンプレミスアプリケーションの災害復旧に AWS を使用したいと考えています。同社には、アプリケーションを実行する数百台の Windows ベースのサーバーがあります。すべてのサーバーは共通の共有をマウントしています。
同社の RTO は 15 分、RPO は 5 分です。ソリューションは、ネイティブのフェイルオーバーとフォールバック機能をサポートする必要があります。
これらの要件を最もコスト効率よく満たすソリューションを選択してください。
■ 選択肢（編集せずに出力）
- A. AWS Storage Gateway ファイルゲートウェイを作成します。Windows サーバーのバックアップを毎日スケジュールします。データを Amazon S3 に保存します。災害時に、オンプレミスサーバーをバックアップから復元します。フェイルバック時に、オンプレミスのサーバーを Amazon EC2 インスタンスで実行します。
- B. 一連の AWS CloudFormation テンプレートを作成してインフラストラクチャを作成します。AWS DataSync を使用して、すべてのデータを Amazon Elastic File System (Amazon EFS) にレプリケートします。災害時は、AWS CodePipeline を使用してテンプレートをデプロイし、オンプレミスサーバーを復元します。DataSync を使用してデータをフェイルバックします。
- C. AWS Cloud Development Kit (AWS CDK) パイプラインを作成して、AWS 上にマルチサイトのアクティブ / アクティブ環境を構築します。s3 sync コマンドを使用して Amazon S3 にデータをレプリケートします。災害時に、DNS エンドポイントを AWS を指すように交換します。s3 sync コマンドを使用してデータをフェイルバックします。
- D. AWS Elastic Disaster Recovery を使用して、オンプレミスのサーバーをレプリケートします。AWS DataSync を使用して、Amazon FSx for Windows File Server ファイルシステムにデータをレプリケートします。ファイルシステムを AWS サーバーにマウントします。災害時に、オンプレミスのサーバーを AWS にフェイルオーバーします。Elastic Disaster Recovery を使用して、新規または既存のサーバーにフェイルバックします。
■ 問題文の要件の概要
- 数百台の Windowsサーバー を災害復旧対象にしたい
- 全サーバーが 共通の共有ストレージ を使用
- RTO: 15分以内、RPO: 5分以内
- フェイルオーバー / フォールバックがネイティブにサポートされていること
- コスト効率の高い構成 が必要
✅ 正解の選択肢と解説
- 正解：D
解説：
- AWS Elastic Disaster Recovery (AWS DRS) は、オンプレミスサーバーのブロックレベルでの継続的なレプリケーションにより、RPO 5分以内、RTO 15分以内の達成が可能。
- 災害時には、ワンクリックでフェイルオーバーしてEC2として起動でき、復旧後はフェイルバックもネイティブに対応。
- ファイル共有については、AWS DataSync で Amazon FSx for Windows File Server に増分レプリケーションし、NTFS ACL や SMB 共有をそのまま移行可能。
- アクティブ/アクティブ構成と比べて、待機コストを最小化できるため、コスト効率が高い。
❌ 不正解の選択肢の理由
A：
- AWS Storage Gateway は災害復旧用途ではなく、バックアップアプライアンス。
- バックアップは継続レプリケーションでないため、RPO（5分）を満たせない。
- EC2を手動で立ち上げる必要があり、RTO（15分）も厳しい。
- フェイルバックも手動で非効率的。
B：
- CloudFormation / CodePipeline で数百台の Windows サーバーを迅速に復元するのは難しく、RTOを超過する可能性が高い。
- AWS DataSync はジョブベースの転送であり、常時レプリケーションに向かない（RPO不達）。
- ネイティブのフェイルオーバー/フォールバックが存在しない。
C：
- マルチサイト アクティブ/アクティブ構成は、待機リソースが常時稼働するためコスト効率が悪い。
- s3 sync はブロック差分転送ではなく、整合性も低く、RPO 5分の要件を満たさない。
- DNS切替はストレージの整合性を保証しないためリスクがある。
🎯 SAP試験で押さえておくべきポイント
- AWS Elastic Disaster Recovery（DRS） はSAP試験頻出の災害復旧サービス。
- ブロックレベルの継続的レプリケーションにより、低RPO / 低RTOを実現。
- フェイルオーバー・フェイルバックをネイティブにサポート。
- Amazon FSx for Windows File Server は、Windowsワークロードの共有ストレージとして最適。NTFS ACL や SMB 対応。
- AWS DataSync は高速かつ増分同期が可能。共有ファイルの同期に適しており、DRSと併用されるケースが多い。
- コスト効率の観点では、アクティブ/アクティブよりDRSによる待機構成が好まれる。
- **「継続レプリケーション」と「バックアップ」や「テンプレートによる自動復元」**の違いを明確に区別することが重要。
次の問題があれば、続けてどうぞ。分析を続けます。
以下は問題7の出力結果です。
■ 問題文（編集せずに出力）
ある企業は AWS Organizations を使用して複数のアカウントを管理しています。規制要件のため、この企業は特定のメンバーアカウントを特定の AWS リージョンに制限し、リソースのデプロイを許可したいと考えています。アカウント内のリソースは、タグ付けされ、グループ標準に基づいて適用され、最小限の構成で集中管理される必要があります。
これらの要件を満たす最適な方法を選択してください。
■ 選択肢（編集せずに出力）
- A. 特定のメンバーアカウントで AWS Config ルールを作成して、リージョンを制限し、タグポリシーを適用します。
- B. AWS Billing and Cost Management コンソールから、管理アカウントで、特定のメンバーアカウントのリージョンを無効にし、ルートにタグポリシーを適用します。
- C. 特定のメンバーアカウントをルートに関連付けます。条件を使用してタグポリシーと SCP を適用し、リージョンを制限します。
- D. 特定のメンバーアカウントを新しい OU に関連付けます。条件を使用してタグポリシーと SCP を適用し、リージョンを制限します。
■ 問題文の要件の概要
- 特定アカウントに対して 使用できるリージョンを制限したい
- リソースにタグを強制し、標準を維持したい
- 最小限の構成で集中管理したい（OUやポリシーなどの継承活用が望ましい）
- Organizationsを使って複数アカウントを統制している状況
✅ 正解の選択肢と解説
- 正解：D
解説：
- AWS OrganizationsでOU（組織単位）を使ってアカウントをグルーピングし、OUに対してSCP（サービスコントロールポリシー）とタグポリシーを適用することで、管理の一元化が可能。
- SCPはリージョンベースでの操作制御をサポートしており、使用可能なリージョンのみを許可する設定が可能。
- タグポリシーをOUに設定すれば、タグのキーや値の準拠強制も組織全体で可能。
- OU単位の分離により、他アカウントへ影響せずに最小構成・スケーラブルに制御できる。
❌ 不正解の選択肢の理由
A：
- AWS Configは後から検出する評価系のサービスで、事前のブロックはできない。
- タグポリシーはOrganizationsルートやOU単位で設定する必要があり、メンバーアカウント単体では集中管理にならない。
B：
- Billing and Cost Managementのリージョン無効化設定は管理アカウント自身にしか適用されないため、他のメンバーアカウントに適用できない。
- また、タグポリシーをルートに適用してもアカウント個別制御ができず柔軟性に欠ける。
C：
- ルート直下にアカウントを置くと、ポリシー適用が他と混在して制御が複雑になり、分離制御ができない。
- OUを活用すれば、対象アカウント群にだけガードレールを適用できるのに対し、ルートではそれが難しい。
🎯 SAP試験で押さえておくべきポイント
- SCP（Service Control Policy） はOU単位で使用し、使用できるリージョンやサービスの制限を明示的に定義するのがベストプラクティス。
- タグポリシー はOrganizationsと組み合わせて、リソース作成時に標準化されたタグを強制できる。タグ名や値も制御可能。
- AWS Config は監視やコンプライアンス評価用で、制御（deny）はできない点を明確に区別して理解すること。
- 組織管理での基本原則：
- OUを使ってグルーピングし、
- SCPとタグポリシーで制御
- 評価系（Config）と制御系（SCPやタグポリシー）の違いを理解
次の問題があれば続けて送ってください。引き続き丁寧に分析します。
