以下に、AWS SAP試験 問題1 を指定フォーマットで出力いたします。
■ 問題文（※文字列を編集せずに出力）
ある企業は、AWS に移行することで、使用頻度は低いがビジネスクリティカルな 20 のアプリケーション群に関連するコストを管理したいと考えています。アプリケーションは、さまざまなインスタンスクラスターに分散された Java と Node.js を組み合わせたものです。同社は、単一のデプロイ方法を使用することで標準化しつつ、コストを最小限に抑えたいと考えています。
ほとんどのアプリケーションは、同時ユーザー数が少ない月末処理ルーチンの一部ですが、他の時間に実行されることもあります。平均的なアプリケーションのメモリ消費量は 1 GB 未満です。ただし、ピーク時の処理では 2.5 GB ものメモリを使用するアプリケーションもあります。このグループで最も重要なアプリケーションは、Java で書かれた請求レポートであり、複数のデータソースにアクセスし、多くの場合数時間実行されます。
最も費用対効果の高いソリューションを選択してください。
■ 選択肢（※文字列をそのまま出力）
A.
アプリケーションごとに個別の AWS Lambda 関数をデプロイします。AWS CloudTrail ログと Amazon CloudWatch アラームを使用して、重要なジョブの完了を確認します。
B.
メモリ使用率が 75% になるように構成された Auto Scaling を使用して、Amazon EC2 上に Amazon ECS コンテナをデプロイします。ECS タスクのスケーリングを使用して、移行するアプリケーションごとに ECS タスクをデプロイします。Amazon CloudWatch を使用して、サービスとホストを監視します。
C.
すべてのリクエストに十分なリソースがあるように、Auto Scaling を使用して、各アプリケーションに AWS Elastic Beanstalk をデプロイします。CloudWatch アラームを使用して、各 AWS Elastic Beanstalk デプロイメントを監視します。
D.
EC2 Auto Scaling と Application Load Balancer を使用して、すべてのアプリケーションを共同ホストする新しい Amazon EC2 インスタンスクラスターをデプロイします。インスタンスのメモリ使用率に設定されたカスタムメトリクスに基づいてクラスターサイズを調整します。Auto Scaling グループの GroupMaxSize パラメータに等しい 3 年間のリザーブドインスタンスを購入します。
■ 問題文の要件の概要
- 使用頻度が低いが**ビジネスクリティカルなアプリ群（20個）**をAWSに移行したい
- アプリの特性：Java / Node.js、メモリ平均1GB未満、ピーク2.5GB、数時間実行もあり
- 単一のデプロイ手段で標準化したい
- コストを最小限にしたい（費用対効果）
■ 正解の選択肢と解説
✅ B.
Amazon ECS（EC2 起動タイプ）を使い、ECS タスク単位でアプリケーションをコンテナ化して管理する方式がベストです。
- タスク単位でアプリごとにスケール可能
- Auto Scaling によってメモリ負荷に応じてスケール可能
- インスタンスの共有化とタスク分離でコスト最小化が可能
- CloudWatch による監視も容易
単一のデプロイモデル（ECS）で統一できる点も重要なメリットです。
■ 不正解の選択肢の理由
❌ A. Lambda 使用
→ Lambda は最大15分の実行制限があるため、「数時間動作」するJava請求レポートアプリケーションには不適。また、2.5GBメモリ使用もLambdaでは上限近くとなり非効率。
❌ C. Elastic Beanstalk 複数展開
→ Elastic Beanstalk はアプリごとに独立環境を作るため、20アプリ×個別環境でコストが高騰。スケールインの柔軟性もECSに比べると低い。
❌ D. 3年RIで固定リソース確保
→ 「使用頻度が低い」アプリケーションに対して3年RIは非効率。負荷変動もあるため、柔軟性のあるスケーリング構成が望ましい。
■ SAP試験で押さえておくべきポイント
- ✅ **Amazon ECS（特にEC2起動型）**は複数アプリをタスク単位で効率的に管理・デプロイ可能
- ✅ 負荷変動のあるアプリ群には Auto Scaling＋CloudWatch監視 が有効
- ✅ Lambdaは短時間/軽量処理向き、長時間/高メモリ利用には向かない
- ✅ Elastic Beanstalkはシンプルだがコスト最適化には不利な場合がある（アプリ単位で環境分離されるため）
- ✅ RI購入は「常時稼働・予測可能な負荷」向きで、変動負荷・低頻度には不向き
他の問題もこの形式で整理可能ですので、続けてご送付ください。
おっしゃる通りです。こちらのミスで、選択肢の出力時に 「（正解）」 の表記を入れてしまいました。申し訳ありません。
改めて、正解が分からない形式で出力し直します。
✅ 問題文（問題2）
ある企業は、Amazon EC2 インスタンスと AWS Lambda 関数でアプリケーションを実行しています。
EC2 インスタンスには継続的かつ安定した負荷がかかります。
Lambda 関数は、変動があり予測不可能な負荷が発生します。
このアプリケーションには、Amazon MemoryDB for Redis クラスターを使用するキャッシュレイヤーが含まれています。
ソリューションアーキテクトは、会社の月々の全体的なコストを最小限に抑えるソリューションを推奨する必要があります。
これらの要件を満たすソリューションを選択してください。
🔘 選択肢（正解がわからない形式）
A.
EC2 インスタンスをカバーするために、EC2 Instance Savings Plans を購入します。
Lambda 用の Compute Savings Plans を購入して、Lambda 関数の予想される最小消費量をカバーします。
MemoryDB キャッシュノードをカバーするためにリザーブドノードを購入します。
B.
EC2 インスタンスをカバーするために、Compute Savings Plans を購入します。
予想される Lambda の使用量をカバーするには、Lambda の予約済み同時実行を購入します。
MemoryDB キャッシュノードをカバーするためにリザーブドノードを購入します。
C.
EC2 インスタンス、Lambda 関数、および MemoryDB キャッシュノードの予想コスト全体をカバーするために、Compute Savings Plans を購入します。
D.
EC2 インスタンスと MemoryDB キャッシュノードをカバーするために、Compute Savings Plans を購入します。
予想される Lambda の使用量をカバーするには、Lambda の予約済み同時実行を購入します。
📌 問題文の要件の概要
- EC2：継続的で安定した負荷 → 長期固定利用
- Lambda：変動・予測困難な負荷
- MemoryDB：キャッシュ層
- 目的：月々の全体コストを最小化
✅ 正解の選択肢と解説
A が正解。
- EC2：EC2 Instance Savings Plans が最もコスト効率が良い（最大72%割引）。
- Lambda：Compute Savings Plans は柔軟性があり、変動の大きい Lambda に適する。
- MemoryDB：リザーブドノード は MemoryDB の専用のコスト削減手段。
これらを組み合わせることで、それぞれのワークロードに最適な割引を適用し、全体のコストを最小限に抑えられる。
❌ 不正解の選択肢の理由
- B：
- EC2 に Compute Savings Plans を使っており、Instance SP より割引率が下がる。
- Lambda の予約済み同時実行はコスト最適化ではなく性能確保用。
- C：
- Compute Savings Plans は MemoryDB には適用されない。
- すべてを Compute SP でまとめるのは不適切。
- D：
- 同上で EC2 に Compute SP を使っているため最適ではない。
- Lambda の予約済み同時実行の使い方も同様に誤り。
🎯 SAP試験で押さえておくべきポイント
- Savings Plans の種類と用途
- EC2 Instance SP：インスタンスタイプが明確で固定的な使用 → 最も割引が大きい
- Compute SP：インスタンスタイプ・リージョン・サービス問わず柔軟な適用が可能
- 予約済み同時実行はコスト削減ではなく性能保証（Lambda）
- MemoryDB には Savings Plans は使えず、リザーブドノードが最適
今後はこの形式で、正解が選択肢からわからないよう注意して出力します。ご指摘ありがとうございました！
以下、ご依頼いただいた形式で問題3を整理しました。
✅ 問題文（問題3）
企業のソリューションアーキテクトは、数年前にデプロイされた AWS ワークロードを評価しています。アプリケーション層はステートレスで、AMI から起動された単一の大規模な Amazon EC2 インスタンス上で実行されます。このアプリケーションは、単一の EC2 インスタンス上で実行される MySQL データベースにデータを保存します。
アプリケーションサーバーの EC2 インスタンスの CPU 使用率が 100% に達することが多く、アプリケーションが応答を停止します。同社はインスタンスに手動でパッチをインストールしています。過去にパッチ適用によりダウンタイムが発生したことがあります。アプリケーションを高可用性にする必要があります。
これらの要件を、最小限の開発コストで満たすソリューションを選択してください。
🔘 選択肢
A.
アプリケーション層を既存の VPC の AWS Lambda 関数に移動します。Application Load Balancer を作成して、Lambda 関数全体にトラフィックを分散します。Amazon GuardDuty を使用して、Lambda 関数をスキャンします。データベースを Amazon DocumentDB (MongoDB 互換) に移行します。
B.
EC2 インスタンスタイプを、より小さい Graviton を搭載したインスタンスタイプに変更します。既存の AMI を使用して、Auto Scaling グループの起動テンプレートを作成します。Application Load Balancer を作成して、Auto Scaling グループのインスタンス全体にトラフィックを分散します。CPU 使用率に基づいてスケーリングするように Auto Scaling グループを設定します。データベースを Amazon DynamoDB に移行します。
C.
Docker を使用してアプリケーション層をコンテナに移行します。Amazon Elastic Container Service (Amazon ECS) の EC2 インスタンスでコンテナを実行します。Application Load Balancer を作成して、ECS クラスター全体でトラフィックを分散します。CPU 使用率に基づいてスケールするように ECS クラスターを構成します。データベースを Amazon Neptune に移行します。
D.
AWS Systems Manager Agent (SSM Agent) で構成された新しい AMI を作成します。新しい AMI を使用して、Auto Scaling グループの起動テンプレートを作成します。Auto Scaling グループでより小さいインスタンスを使用します。Application Load Balancer を作成して、Auto Scaling グループのインスタンス全体にトラフィックを分散します。CPU 使用率に基づいてスケーリングするように Auto Scaling グループを設定します。データベースを Amazon Aurora MySQL に移行します。
📌 問題文の要件の概要
- 単一の大規模 EC2 でアプリ・DB（MySQL）を稼働
- 高い CPU 使用率によってアプリが停止
- パッチ適用で手動作業・ダウンタイムあり
- 高可用性を実現し、開発コストは最小限に抑える必要がある
✅ 正解の選択肢と解説
正解：D
- Systems Manager Agent (SSM Agent) を利用し、パッチ適用などの運用を自動化・安定化。
- Auto Scaling グループにより CPU 使用率に応じてスケーラブルに。
- Aurora MySQL へ移行することで、既存の MySQL と互換性を保ちつつ、可用性・耐障害性を強化。
- 全体的に開発コストが低く、既存構成を活かしたまま高可用化を実現。
❌ 不正解の選択肢の理由
A:
- Lambda + DocumentDB は構成が大きく変わるため、開発コストが非常に高い。
- GuardDuty はセキュリティ監視であり、Lambda の可用性や性能には無関係。
B:
- Graviton はコスト削減にはなるが、既存アプリとの互換性が不明。
- DynamoDB は MySQL とデータ構造が異なり、アプリケーションの再設計が必要で開発コスト大。
C:
- ECS への移行はコンテナ化が前提で、開発コストが大きい。
- Neptune はグラフDBであり、MySQL とは性質が異なる → データベース移行困難。
🎯 SAP試験で押さえておくべきポイント
- 高可用性の実現手段として Auto Scaling + Load Balancer の基本パターンは鉄板
- SSM Agent + Systems Manager Patch Manager → パッチの自動適用・運用の安定化
- データベース移行時は、互換性のあるサービス（例：MySQL → Aurora MySQL）を選ぶことで開発コストを抑える
- 開発・移行コストを評価する視点は SAP 試験で頻出テーマ
他にも問題があれば、同じ形式で整理しますので、お気軽に送ってください。
以下、ご要望の形式で問題4を整理・解説します。
✅ 問題文（問題4）
ある e コマース企業が IT インフラストラクチャを刷新し、AWS サービスの利用を計画しています。同社の CIO は、ソリューションアーキテクトに、シンプルで可用性が高く、疎結合の注文処理アプリケーションの設計を依頼しました。
このアプリケーションは、Amazon DynamoDB のテーブルに保存する前に、注文を受信して処理する役割を担っています。
このアプリケーションは、散発的なトラフィックパターンを持ち、マーケティングキャンペーン中に最小限の遅延で注文を処理するために拡張可能である必要があります。
🔘 選択肢
A.
Amazon EC2 がホストするデータベースで注文を受信し、EC2 インスタンスを使用して注文を処理します。
B.
Amazon SQS キューで注文を受信し、AWS Lambda 関数を呼び出して処理します。
C.
AWS Step Functions プログラムを使用して注文を受信し、Amazon ECS コンテナを起動して注文を処理します。
D.
Amazon Kinesis Data Streams で注文を受信し、Amazon EC2 インスタンスを使用して処理します。
✅ 正解の選択肢と理由
正解：B
Amazon SQS + AWS Lambda により、次の利点を得られるためです：
- 高可用性・高スケーラビリティ：SQS はフルマネージドの高耐久キュー、Lambda はスケーラブルなサーバーレス処理。
- 疎結合：SQS によって注文の受付と処理が非同期に分離される。
- 散発的なトラフィックに強い：Lambda はリクエストに応じて即時起動・スケーリング。
- シンプルな構成：イベント駆動で複雑な運用が不要。
❌ 他の選択肢の誤り
A：Amazon EC2 + 自前DB構成
- EC2はサーバー管理が必要で、自動スケーリングに向かない。
- 可用性・拡張性・疎結合といった要件を満たせない。
C：Step Functions + ECS
- ワークフロー制御に有効だが、構成が複雑かつ過剰設計。
- 簡潔・最小遅延という要件に対してオーバーヘッドが大きい。
D：Kinesis + EC2
- Kinesisはリアルタイムのストリーミングデータ処理向けで、注文処理のような用途には過剰。
- EC2使用もスケーラビリティや自動化に不利。
🎯 SAP試験で押さえるべきポイント
| 観点 | ポイント |
|---|---|
| ✅ 疎結合設計 | SQSやSNSなどで非同期化し、システム間を独立させる |
| ✅ スケーラビリティ | Lambdaなどイベントドリブンなサービスを利用 |
| ✅ 負荷変動対応 | オートスケール or サーバーレス構成 |
| ✅ シンプルな構成 | マネージドサービスを組み合わせて最小運用で高可用性を達成 |
他にもSAPの問題があれば、引き続き同じ形式で対応できますのでお気軽にどうぞ！
以下は、問題5の内容と解説を指定の形式でまとめたものです。
✅ 問題文（問題5）
ある企業は AWS クラウドで複数のワークロードを実行しています。同社には、ソフトウェア開発のための別の部門があります。同社は、AWS Organizations と SAML によるフェデレーションを使用して、開発者に AWS アカウント内のリソースを管理する権限を与えています。開発部門はそれぞれ、本番ワークロードを共通の本番アカウントにデプロイします。
最近、本番アカウントで、開発部門のメンバーが、別の開発部門に属する EC2 インスタンスを終了させるというインシデントが発生しました。ソリューションアーキテクトは、今後同様のインシデントが発生することを防ぐソリューションを作成する必要があります。また、開発者がワークロードに使用されるインスタンスを管理できるようにする必要があります。
これらの要件を満たす戦略を選択してください。
🔘 選択肢
A.
開発部門ごとに AWS Organizations で個別の OU を作成します。作成した OU を会社の AWS アカウントに割り当てます。開発部門名に一致する DevelopmentUnit リソースタグに対して、Deny アクションと StringNotEquals 条件を持つ別の SCP を作成します。SCP を対応する OU に割り当てます。
B.
SAML フェデレーション中に、DevelopmentUnit の属性を AWS Security Token Service (AWS STS) のセッションタグとして渡します。開発者が想定する IAM ロールの IAM ポリシーを更新し、DevelopmentUnit リソースタグと aws:PrincipalTag/DevelopmentUnit に対して Deny アクションと StringNotEquals 条件を設定します。
C.
SAML フェデレーション中に、DevelopmentUnit の属性を AWS Security Token Service (AWS STS) セッションタグとして渡します。DevelopmentUnit リソースタグと aws:PrincipalTag/DevelopmentUnit の Allow アクションと StringEquals 条件を含む SCP を作成します。SCP をルート OU に割り当てます。
D.
開発部門ごとに個別の IAM ポリシーを作成します。すべての IAM ポリシーに、DevelopmentUnit リソースタグと開発部門名に対する Allow アクションと StringEquals 条件を追加します。SAML フェデレーション中に、AWS Security Token Service (AWS STS) を使用して IAM ポリシーを割り当て、開発部門名を想定される IAM ロールに一致させます。
📌 問題文の要件の概要
- 本番アカウントで部門間の誤操作（インスタンス終了）を防止したい
- ただし、自分の部門が管理するインスタンスについては操作可能でなければならない
- SAMLフェデレーションおよびSTSセッションタグを使って制御することが前提
✅ 正解の選択肢と解説
正解：B
セッションタグ（STS）とリソースタグの比較によるDenyポリシーが最も効果的な方法です。
- 開発者の SAML フェデレーション時に、
DevelopmentUnitというタグを セッションタグとして付与 - EC2 インスタンス側には
DevelopmentUnitタグが設定されている - IAM ポリシーで「
aws:PrincipalTag/DevelopmentUnit≠ リソースのDevelopmentUnitならDeny」と設定 - これにより、自部門以外のインスタンスに対してアクションできなくなる
✅ メリット:
- SAMLフェデレーションを活用した動的・柔軟な制御
- ポリシーだけで部門ごとの分離と誤操作防止を実現
- 適切なDenyベースの制御により安全性が高い
❌ 不正解の選択肢と理由
A. SCP を OU に使う方法
- SCP はアカウント全体のアクセス制限には使えるが、タグベースの細かいリソース制御には不適切
- EC2 インスタンス単位の操作制限には向かない
C. SCP に Allow を使って制御する案
- SCP は Allow での細かい制御ができない（SCPはあくまで最大権限の制限）
- タグベース制御は IAM ポリシーで行うべき
D. IAMポリシーにAllowを定義する案
- Allow 条件だけだと、Denyがなければ別部門リソースにもアクセスできてしまう
- セッションタグとリソースタグの不一致を拒否するには、明示的なDenyが必要
🎯 SAP試験で押さえておくべきポイント
| 観点 | ポイント |
|---|---|
| ✅ セッションタグ | STS/Federation 時にタグを付与し、IAM ポリシーでアクセス制御できる |
| ✅ タグベースアクセス制御 | aws:RequestTag, aws:ResourceTag, aws:PrincipalTag を理解する |
| ✅ IAM ポリシー vs SCP | リソース単位の制御は IAM ポリシー、アカウント・OU全体は SCP |
| ✅ 誤操作防止設計 | 明示的な Deny とタグ照合による防止策が現場で有効 |
他の問題も引き続き対応可能です。貼り付けてください！
以下はご要望の形式に従って整理した内容です。
■ 問題文（※原文のまま）
ソリューションアーキテクトが、ある企業の Amazon RDS DB インスタンスのスナップショット取得プロセスをレビューしています。同社は毎日自動スナップショットを取得し、スナップショットを 7 日間保存します。
ソリューションアーキテクトは、6 時間ごとにスナップショットを取得し、スナップショットを 30 日間保存するソリューションを推奨する必要があります。同社は、AWS Organizations を使用してすべての AWS アカウントを管理しています。同社は、RDS スナップショットの健全性を統合的に把握する必要があります。
運用上のオーバーヘッドを最小限に抑えてこれらの要件を満たすソリューションを選択してください。
■ 選択肢（※正誤が分からないように順序を保持）
- A
AWS Backup のクロスアカウント管理機能を有効にします。頻度と保持要件を指定するバックアッププランを作成します。DB インスタンスにタグを追加します。タグを使用してバックアッププランを適用します。AWS Backup を使用してバックアップのステータスを監視します。 - B
Amazon RDS のクロスアカウント管理機能を有効にします。頻度と保持要件を指定するスナップショットグローバルポリシーを作成します。管理アカウントの RDS コンソールを使用して、バックアップのステータスを監視します。 - C
AWS CloudFormation のクロスアカウント管理機能を有効にします。管理アカウントから、頻度と保持要件を指定した AWS Backup からのバックアッププランを含む CloudFormation StackSets をデプロイします。管理アカウントで AWS Lambda 関数を作成して、バックアップのステータスを監視します。各アカウントで Amazon EventBridge ルールを作成し、スケジュールに従って Lambda 関数を実行します。 - D
各アカウントで AWS Backup を構成します。頻度と保持要件を指定する Amazon Data Lifecycle Manager ライフサイクルポリシーを作成します。DB インスタンスをターゲットリソースとして指定します。各メンバーアカウントで Amazon Data Lifecycle Manager コンソールを使用して、バックアップのステータスを監視します。
■ 問題文の要件の概要
- RDS スナップショットの取得を6時間ごとに実施したい
- 保持期間は30日
- AWS Organizations 管理下で全アカウントを一元管理
- スナップショットの健全性（バックアップ状況）を統合的に確認したい
- 運用上のオーバーヘッドを最小化したい
■ 正解の選択肢と解説
正解：A
解説：
AWS Backup は、クロスアカウントバックアップ管理機能を提供しており、AWS Organizations 配下の複数アカウントに共通のバックアップポリシーを一元的に適用可能です。バックアップ頻度（6時間ごと）や保持期間（30日）の指定、リソースのタグに基づく対象選定、さらには AWS Backup ダッシュボードで全アカウントのバックアップステータス監視が可能なため、要件をすべて満たします。
■ 不正解の選択肢の理由
- B（RDS のクロスアカウント管理機能）
RDS にクロスアカウント管理機能は存在せず、バックアップポリシーを Organizations 全体に適用することも不可能。 - C（CloudFormation と Lambda の併用）
バックアップ制御は CloudFormation で自動化できるものの、Lambda・EventBridge を各アカウントで管理する必要があり、オーバーヘッドが大きい。AWS Backup を直接使用すればシンプルに済む。 - D（Data Lifecycle Manager）
Data Lifecycle Manager は EC2/EBS 向けであり、RDS スナップショットのスケジュール管理対象ではない。使用するサービスが不適切。
■ SAP試験で押さえておくべきポイント
- AWS Backup は RDS や EBS、EFS、DynamoDB などのバックアップ管理を 一元的に行うフルマネージドサービス。
- Organizations 統合管理が可能で、クロスアカウントバックアップ、ポリシー管理、監視が可能。
- バックアップ頻度・保持期間の制御、リソースのタグによる対象指定ができる。
- Data Lifecycle Manager は EBS ボリューム専用。RDS バックアップには使用しない。
- CloudFormation や Lambda を使うと自動化は可能だが、設計の複雑さと保守性の観点から非推奨。
必要であれば図解や関連ドキュメントの要約も可能です。次の問題もご希望であれば続けてください。
以下にご要望の形式でまとめます。
■ 問題文（そのまま）
ある企業は AWS クラウドで複数のワークロードを実行しています。同社には、ソフトウェア開発のための別の部門があります。同社は、AWS Organizations と SAML によるフェデレーションを使用して、開発者に AWS アカウント内のリソースを管理する権限を与えています。開発部門はそれぞれ、本番ワークロードを共通の本番アカウントにデプロイします。
最近、本番アカウントで、開発部門のメンバーが、別の開発部門に属する EC2 インスタンスを終了させるというインシデントが発生しました。ソリューションアーキテクトは、今後同様のインシデントが発生することを防ぐソリューションを作成する必要があります。また、開発者がワークロードに使用されるインスタンスを管理できるようにする必要があります。
これらの要件を満たす戦略を選択してください。
■ 選択肢（順不同・マークなし）
A.
開発部門ごとに AWS Organizations で個別の OU を作成します。作成した OU を会社の AWS アカウントに割り当てます。開発部門名に一致する DevelopmentUnit リソースタグに対して、Deny アクションと StringNotEquals 条件を持つ別の SCP を作成します。SCP を対応する OU に割り当てます。
B.
SAML フェデレーション中に、DevelopmentUnit の属性を AWS Security Token Service (AWS STS) のセッションタグとして渡します。開発者が想定する IAM ロールの IAM ポリシーを更新し、DevelopmentUnit リソースタグと aws:PrincipalTag/DevelopmentUnit に対して Deny アクションと StringNotEquals 条件を設定します。
C.
SAML フェデレーション中に、DevelopmentUnit の属性を AWS Security Token Service (AWS STS) セッションタグとして渡します。DevelopmentUnit リソースタグと aws:PrincipalTag/DevelopmentUnit の Allow アクションと StringEquals 条件を含む SCP を作成します。SCP をルート OU に割り当てます。
D.
開発部門ごとに個別の IAM ポリシーを作成します。すべての IAM ポリシーに、DevelopmentUnit リソースタグと開発部門名に対する Allow アクションと StringEquals 条件を追加します。SAML フェデレーション中に、AWS Security Token Service (AWS STS) を使用して IAM ポリシーを割り当て、開発部門名を想定される IAM ロールに一致させます。
■ 問題文の要件の概要
- 複数の開発部門が共通の本番アカウントにデプロイしている
- 他部門のインスタンス操作（削除）という誤操作を防ぎたい
- 開発者が自分の部門のインスタンスは引き続き管理できる必要がある
- AWS Organizations と SAML フェデレーションを活用している
■ 正解の選択肢と解説
正解：B
解説：
SAML フェデレーション時に DevelopmentUnit の属性をセッションタグとして AWS STS に渡し、それを aws:PrincipalTag/DevelopmentUnit として IAM ポリシーの条件に利用します。
IAM ポリシーに Deny アクションと StringNotEquals 条件を使うことで、自分の部署のタグ以外がついたインスタンスにはアクセスできなくなります。これにより、他部門のリソースを誤って操作するリスクを防ぎつつ、自分のリソースは管理できるという要件を満たします。
■ 不正解の選択肢の理由
- A: SCP はアカウントレベルの制御に使うもので、リソース単位の細かい制御には向きません。タグベースのアクセス制御には IAM ポリシーが適しています。
- C: SCP による
Allowは通常意味がありません。SCP は「できることの上限を定める」ためのもので、リソースベースの制御には IAM ポリシーを使うべきです。また、SCP はタグベースの細かい制御には不向きです。 - D: IAM ポリシー単独での
Allowでは、明示的なDenyがない限り他部門のリソースにもアクセス可能になります。セッションタグを使ってDenyを明示するのが正しいアプローチです。
■ SAP試験で押さえておくべきポイント
- セッションタグ（Session Tags）：SAML フェデレーションや STS 経由で属性情報を IAM ポリシー条件に利用できる。
aws:PrincipalTag/タグ名で参照。 - タグベースのアクセス制御（ABAC）：リソースとユーザーの両方にタグを付与し、IAM ポリシーでマッチング条件を設定してアクセスを制御できる。
- 明示的 Deny は強力：複数部門が共通アカウントを利用するケースでは、
StringNotEqualsで明示的に拒否することで誤操作を防止。 - SCP の用途：OU 単位で「できることの上限」を定めるもので、リソースレベルの制御には適さない。
続けて別の問題があれば、同様の形式で対応いたします。
