Uncategorized

#53

 

はい！問題1 を整理しました。

■問題文

ソリューションアーキテクトは、手動で作成された既存の開発環境の AWS 環境から AWS CloudFormation テンプレートを作成しています。CloudFormation テンプレートは必要に応じて破棄し、再作成することができます。環境には Amazon EC2 インスタンスが含まれています。EC2 インスタンスには、EC2 インスタンスが親アカウントのロールを引き受けるために使用するインスタンスプロファイルがあります。

ソリューションアーキテクトは、CloudFormation テンプレートでロールを再作成し、同じロール名を使用します。CloudFormation テンプレートが子アカウントで起動されると、EC2 インスタンスは権限が不十分なため、親アカウントのロールを引き受けることができなくなります。

この問題を解決するための最適な方法を選択してください。

■選択肢

A. 親アカウントで、EC2 インスタンスが引き受ける必要のあるロールの信頼ポリシーを編集します。sts:AssumeRole アクションを許可する既存のステートメントのターゲットロールの ARN が正しいことを確認します。信頼ポリシーを保存します。

B. 親アカウントで、EC2 インスタンスが引き受ける必要のあるロールの信頼ポリシーを編集します。子アカウントのルートプリンシパルに sts:AssumeRole アクションを許可するステートメントを追加します。信頼ポリシーを保存します。

C. CloudFormation スタックを再度更新します。CAPABILITY_NAMED_IAM 機能のみを指定します。

D. CloudFormation スタックを再度更新します。CAPABILITY_IAM 機能と CAPABILITY_NAMED_IAM 機能を指定します。

■問題文の要件の概要

  • 状況：子アカウントに CloudFormation でロールを再作成したため、ARN が変わり、親アカウントの信頼ポリシーが古い ARN を参照 → AssumeRole が失敗。
  • 要件：親アカウントの IAM ロール信頼ポリシーを修正し、最新のロール ARN を許可する必要がある。
  • 考慮点：root プリンシパルを許可するのはセキュリティリスク。CloudFormation の CAPABILITY フラグでは解決しない。

■正解の選択肢と解説

✅ A. 親アカウントの信頼ポリシーを修正し、ARN を最新化

  • 親アカウントの IAM ロール信頼ポリシーで、子アカウントの EC2 インスタンスプロファイルが AssumeRole できるようにする必要がある。
  • ロール名が同じでも ARN（内部 ID）が異なるため、信頼ポリシーを最新の ARN に更新し直すことで解決できる。
  • これが唯一の正しい修正方法。

■不正解の選択肢の理由

❌ B. 子アカウントのルートプリンシパルを許可

  • 最小権限の原則に反する。
  • 子アカウント内のすべてのユーザー/ロールが AssumeRole 可能になってしまう。

❌ C. CAPABILITY_NAMED_IAM のみ指定

  • CloudFormation 内で IAM リソースを作成できるようにするフラグ。
  • 親アカウントの信頼ポリシーには影響しない。

❌ D. CAPABILITY_IAM と CAPABILITY_NAMED_IAM を指定

  • IAM リソース作成を承認するフラグであり、問題の「親アカウント信頼ポリシー更新」には無関係。

■SAP試験で押さえておくべきポイント

  • IAM ロールの信頼ポリシー：AssumeRole を許可するプリンシパルを正確に定義する必要がある。
  • クロスアカウントアクセス：ロール名ではなく ARN（ID） で制御されるため、再作成時は ARN 更新が必須。
  • セキュリティベストプラクティス：root プリンシパルを許可するのは避ける（過剰権限）。
  • CloudFormation CAPABILITY フラグ：IAM リソース作成/更新の承認に必要だが、クロスアカウントの信頼関係は手動で修正する必要がある。

👉 この問題の本質は
「CloudFormation による IAM ロール再作成で ARN が変わる → 親アカウントの信頼ポリシーを最新の ARN に更新する必要がある」 です。

次は 問題2 を整理していきますか？

はい！問題2 を整理しました。

■問題文

監査中に、セキュリティチームが開発チームのコードに IAM ユーザーのシークレットアクセスキーを配置し、それを AWS CodeCommit リポジトリにコミットしていることを発見しました。セキュリティチームは、このセキュリティの脆弱性のインスタンスを自動的に見つけて修正したいと考えています。

認証情報が自動的に適切に保護されることを保証するソリューションを選択してください。

■選択肢

A. AWS Systems Manager Run Command を使用してスクリプトを毎晩実行し、開発インスタンス上の認証情報を検索します。見つかった場合は、AWS Secrets Manager を使用して認証情報をローテーションします。

B. スケジュールされた AWS Lambda 関数を使用して、CodeCommit からアプリケーションコードをダウンロードしてスキャンします。認証情報が見つかった場合は、新しい認証情報を生成して AWS KMS に保存します。

C. CodeCommit リポジトリで認証情報をスキャンするように Amazon Macie を設定します。認証情報が見つかった場合は、AWS Lambda 関数をトリガーして認証情報を無効にし、ユーザーに通知します。

D. CodeCommit のトリガーを設定して、AWS Lambda 関数を呼び出し、新しいコードの投稿をスキャンして認証情報を探します。認証情報が見つかった場合は、AWS IAM で認証情報を無効にして、ユーザーに通知します。

■問題文の要件の概要

  • 課題：開発者がシークレットアクセスキーを誤ってコードに含め、CodeCommit に push。
  • 要件：即時に脆弱性を検知し、自動的に IAM キーを無効化してリスクを最小化。
  • ポイント：リアルタイム性（push 直後に検知）と、自動修復（キー無効化 + 通知）。

■正解の選択肢と解説

✅ D. CodeCommit トリガー + Lambda で即時スキャン & IAM キー無効化

  • CodeCommit には リポジトリトリガー機能があり、push イベントを起点に Lambda を起動可能。
  • Lambda でコードをスキャンし、認証情報が含まれていれば 該当 IAM キーを Inactive に変更し、開発者へ通知。
  • 即時性 + 自動修復を満たす唯一の方法。

■不正解の選択肢の理由

❌ A. Systems Manager Run Command で毎晩スキャン

  • EC2 インスタンス上のファイルは対象にできても、CodeCommit リポジトリのコードは検出できない。
  • 毎晩実行ではリアルタイム性も不足。

❌ B. スケジュール Lambda で CodeCommit を定期スキャン

  • push からスキャンまでの間に漏えいリスク。
  • 新しいキーを KMS に保存しても、既存キーを無効化しないため根本的対処にならない。

❌ C. Macie で CodeCommit をスキャン

  • Macie は Amazon S3 データソースのみ対応。
  • CodeCommit を直接スキャンできないため前提不成立。

■SAP試験で押さえておくべきポイント

  • Secrets をコードに含めないのが大前提 → AWS Secrets Manager, SSM Parameter Store を利用。
  • CodeCommit トリガーを活用し、push イベントで Lambda を起動可能。
  • IAM アクセスキー管理：漏えいしたら即無効化、必要ならローテーション。
  • 誤答に多いパターン
    • Macie が CodeCommit をスキャンできると誤解
    • 定期スキャンで対応可能と思いがちだが、リアルタイム性が必須

👉 この問題の本質は
「イベント駆動（push トリガー）で即時にシークレットを検知し、自動で IAM キーを無効化する」 です。

次は 問題3 を整理していきますか？

はい！問題3 を整理しました。

■問題文

ある会社が AWS 上で Software-as-a-Service (SaaS) アプリケーションをホストしています。このアプリケーションは、AWS Lambda 関数と Amazon RDS 上の MySQL マルチ AZ データベースで構成されています。市場でイベントがあると、アプリケーションの負担は大幅に増加します。ピーク時にはデータベース接続が大量に発生するため、ユーザーの応答時間が低下しています。データベースのスケーラビリティと可用性を強化する必要があります。これらの条件を満たすソリューションを選択してください。

■選択肢

A. リソース使用率がしきい値に達したときに Lambda 関数をトリガーして Amazon RDS for MySQL リードレプリカを追加する Amazon CloudWatch アラームアクションを作成します。

B. データベースを Amazon Aurora に移行し、リードレプリカを追加します。Lambda ハンドラー関数の外部にデータベース接続プールを追加します。

C. データベースを Amazon Aurora に移行し、リードレプリカを追加します。Amazon Route 53 加重レコードを使用します。

D. データベースを Amazon Aurora に移行し、Aurora レプリカを追加します。データベース接続プールを管理するように Amazon RDS Proxy を設定します。

■問題文の要件の概要

  • 状況：Lambda + RDS MySQL で構築した SaaS。
  • 課題：イベント発生時にアクセス急増 → 接続数過多でレスポンス低下。
  • 要件：
    • 水平スケーラビリティ（大量リード処理に対応）
    • 高可用性（フェイルオーバーに耐える）
    • Lambda の短命接続を効率的に処理

■正解の選択肢と解説

✅ D. Aurora + Aurora レプリカ + RDS Proxy

  • Amazon Aurora：MySQL 互換で RDS MySQL より高性能（5倍のスループット）、かつ 15 台までレプリカ追加可能 → 読み込み分散でスケーラビリティ強化。
  • Aurora レプリカ：数ミリ秒レベルのレイテンシで同期、フェイルオーバーも高速。
  • RDS Proxy：Lambda が発生させる大量の短命コネクションを効率的に集約し、接続プールを管理。DB 接続数の爆発を防ぎ、リソース効率を最適化。

👉 この組み合わせにより 高スループット + 高可用性 + 接続効率 を同時に実現できる。

■不正解の選択肢の理由

❌ A. CloudWatch アラームでレプリカを追加

  • RDS リードレプリカ作成は数分～数十分かかり、即応できない。
  • 書き込みはプライマリ集中でボトルネック残存。
  • Lambda の接続爆発も解決できない。

❌ B. Aurora + 接続プール（Lambda ハンドラー外）

  • Lambda の並列実行モデルではコンテナごとに接続プールが作成され、集約効果がない。
  • RDS Proxy を使わないと接続数削減にならず本質的な解決にならない。

❌ C. Aurora + Route 53 加重レコード

  • Route 53 の重み付けは DNS レベルで Aurora レプリカの状態を考慮できない。
  • Aurora は専用エンドポイント（reader/writer）を使うべきで、DNS での分散は適切ではない。

■SAP試験で押さえておくべきポイント

  • Lambda + RDS の課題：短命コネクションの大量発生 → 接続上限に達しやすい。
  • RDS Proxy の役割：接続プールを介して Lambda と DB の間を効率化、フェイルオーバー時も自動的に再接続。
  • Aurora の優位性：
    • 高性能（5倍のスループット）
    • Aurora レプリカで水平スケール
    • 高速フェイルオーバー（10秒未満）
  • 誤答で狙われるポイント：
    • 「RDS レプリカを増やせば良い」と思いがちだが、作成遅延や書き込み集中が解決しない。
    • 「Lambda 内の接続プールで改善できる」と考えるが、実際には効果が限定的。

👉 この問題の本質は
「Aurora でスケーラビリティを確保し、RDS Proxy で Lambda 接続爆発を防ぐ」 です。

次は 問題4 を同じ形式でまとめましょうか？

はい！問題4 を整理しました。

■問題文

ある会社が、AWS CloudFormation スタックにデプロイされた AWS Lambda に基づいてアプリケーションを構築しました。ウェブアプリケーションの最後の本番リリースで問題が発生し、数分間の停止が発生しました。ソリューションアーキテクトは、カナリアリリースをサポートするためにデプロイプロセスを調整しなければなりません。これらの要件を満たすソリューションはどれですか？

■選択肢

A. Lambda 関数の新しくデプロイされたバージョンごとにエイリアスを作成します。AWS CLI update-alias コマンドに routing-config パラメーターを指定して負荷を分散します。

B. アプリケーションを新しい CloudFormation スタックにデプロイします。Amazon Route 53 加重ルーティングポリシーを使用して、負荷を分散します。

C. 新しくデプロイされた Lambda 関数ごとにバージョンを作成します。AWS CLI update-function-configuration コマンドに routing-config パラメーターを指定して負荷を分散します。

D. AWS CodeDeploy を設定し、デプロイ設定で CodeDeployDefault.OneAtATime を使用して負荷を分散します。

■問題文の要件の概要

  • 状況：Lambda アプリを CloudFormation で管理している。
  • 課題：前回のリリースで不具合があり、停止が発生。
  • 要件：カナリアリリースを実現し、段階的にトラフィックを移行できるようにしたい。
  • 重要ポイント：Lambda でカナリアデプロイをするには「エイリアスの routing-config」か「Lambda 対応の CodeDeploy 設定」を使う。

■正解の選択肢と解説

✅ A. Lambda エイリアス + routing-config

  • Lambda の エイリアス はバージョンに紐付けられ、routing-config を使うことでトラフィックを 例えば 90%:10% のように分割可能。
  • 数%だけ新バージョンへ流し、問題がなければ徐々に比率を上げる → Canary リリースを実現。
  • 問題があればすぐに 0% に戻して 即座にロールバック 可能。
  • CloudFormation でバージョン・エイリアス管理を IaC 化できる。

👉 Canary リリースの要件を最も的確に満たす。

■不正解の選択肢の理由

❌ B. CloudFormation + Route 53 加重ルーティング

  • DNS レベルの重み付けであり、Lambda の バージョン間トラフィック制御は不可。
  • そもそも同一 Lambda 関数の新旧バージョンを Route 53 で分散できない。

❌ C. update-function-configuration に routing-config

  • routing-config は エイリアス用 API のみ がサポート。
  • update-function-configuration では使用できず、エラーとなる。
  • 手法自体が誤り。

❌ D. CodeDeploy + CodeDeployDefault.OneAtATime

  • この設定は EC2 / On-Premise 用ローリング更新。
  • Lambda Canary で使うべきは Canary10Percent30Minutes や Linear10PercentEvery10Minutes などの Lambda 専用設定。
  • 設定の選択が不適切。

■SAP試験で押さえておくべきポイント

  • Lambda のデプロイ戦略
    • Canary リリース：トラフィックを段階的に移行。
    • Linear リリース：一定割合を定期的に移行。
  • エイリアスの routing-config がキー。
  • CodeDeploy を使う場合は、Lambda 専用の Canary / Linear 設定を使う必要がある。
  • 誤答の典型：
    • Route 53 で負荷分散すればよいと考える → DNS レベルでは Lambda バージョンを制御できない。
    • 関数設定で routing-config を指定できると誤解する。

👉 この問題の本質は、
「Lambda の Canary デプロイはエイリアスの routing-config（または Lambda 対応 CodeDeploy 設定）で実現する」 という理解です。

次は 問題5 もこの形式でまとめましょうか？

はい！問題5 を整理しました。

■問題文

ウェザーサービスは、eu-west-1 リージョンの AWS 上でホストされているウェブアプリケーションから高解像度の天気図を提供しています。天気図は頻繁に更新され、静的な HTML コンテンツとともに Amazon S3 に保存されます。ウェブアプリケーションの前面には Amazon CloudFront があります。同社は最近、us-east-1 リージョンのユーザーにサービスを提供するように拡大しました。これらの新しいユーザーは、それぞれの天気図の表示が遅い場合があると報告しています。

us-east-1 のパフォーマンスの問題を解決する手順の組み合わせを選択してください。 (2 つ選択)

■選択肢

A. AWS Global Accelerator のエンドポイントを eu-west-1 の S3 バケットに設定します。us-east-1 の TCP ポート 80 と 443 に対してエンドポイントグループを構成します。

B. us-east-1 に新しい S3 バケットを作成します。eu-west-1 の S3 バケットから同期するように S3 クロスリージョンレプリケーションを設定します。

C. Lambda@Edge を使用して、北米からのリクエストが us-east-1 の S3 Transfer Acceleration エンドポイントを使用するように変更します。

D. Lambda@Edge を使用して、北米からのリクエストが us-east-1 の S3 バケットを使用するように変更します。

E. CloudFront ディストリビューションのオリジンとして us-east-1 の AWS Global Accelerator エンドポイントを設定します。Lambda@Edge を使用して、新しいオリジンを使用するように北米からのリクエストを変更します。

■問題文の要件の概要

  • 状況：eu-west-1 にある S3 バケットから高解像度天気図を配信。CloudFront 経由。
  • 課題：us-east-1 のユーザーが遅延を感じている。
  • 要件：us-east-1 のユーザーに対してレイテンシーを改善する仕組み。
  • ポイント：
    • データを ユーザーに近いリージョンへ複製。
    • CloudFront で オリジンを地理的に切り替え。

■正解の選択肢と解説

✅ B. S3 クロスリージョンレプリケーション

  • eu-west-1 の S3 バケットのデータを us-east-1 バケットへ自動的にレプリケート。
  • us-east-1 のユーザーは近いバケットからデータを取得できるため、レイテンシーが大幅に改善。
  • 更新頻度が高いオブジェクトでも AWS が自動同期してくれるため整合性維持。

✅ D. Lambda@Edge でリクエストを us-east-1 S3 バケットへルーティング

  • CloudFront + Lambda@Edge を使い、リクエストの GeoIP 情報を見て北米ユーザーは us-east-1 バケットへ誘導。
  • 動的オリジン選択により、ユーザーが近いリージョンのオリジンからコンテンツを取得できる。
  • これにより CloudFront キャッシュ効率を維持しつつレスポンス改善が可能。

■不正解の選択肢の理由

❌ A. Global Accelerator を eu-west-1 に設定

  • Global Accelerator は入口を最適化するが、最終的には eu-west-1 バケットへルーティングされる。
  • データの物理距離は変わらず、北米ユーザーのレイテンシーは解消されない。

❌ C. Transfer Acceleration を us-east-1 に指定

  • Transfer Acceleration は S3 バケットへのアップロード/長距離転送最適化用。
  • バケットは eu-west-1 のまま → ダウンロード遅延は解消されない。

❌ E. CloudFront のオリジンに Global Accelerator

  • CloudFront オリジンに Global Accelerator を直接指定することは非サポート。
  • また、オリジンが eu-west-1 のままなので根本解決にならない。

■SAP試験で押さえておくべきポイント

  • S3 + CloudFront + 多リージョン対応では：
    • ユーザーの近くに S3 バケットを用意し、クロスリージョンレプリケーションで同期。
    • CloudFront + Lambda@Edge で 地理的に最適なオリジンを選択。
  • 誤答パターン：
    • 「Global Accelerator」を使えば速くなると勘違い → 既に CloudFront があるので意味が薄い。
    • 「Transfer Acceleration」で高速化できると誤認 → これはアップロード向け。
  • 試験では「ユーザーに近いリージョンへデータを複製することが本質的な解決策」を問う問題がよく出る。

👉 この問題の本質は
「ユーザーの近くにデータを配置（S3 CRR）、CloudFront+Lambda@Edge でオリジンを最適ルーティング」
という設計を理解しているかどうかです。

次は 問題6 も同じ形式でまとめますか？

はい！問題6 を整理しました。

■問題文

会社が複数の AWS アカウントを使用しています。DNS レコードは、アカウントA の Amazon Route 53 のプライベートホストゾーンに保存されおり、同社のアプリケーションとデータベースはアカウントB で実行されています。ソリューションアーキテクトは、新しい VPC に 2 層アプリケーションをデプロイします。設定を簡素化するために、Amazon RDS エンドポイント用の db.example.com CNAME レコードセットを Amazon Route 53 のプライベートホストゾーンに作成しました。デプロイ中に、アプリケーションを起動できませんでした。トラブルシューティングの結果、db.example.com が Amazon EC2 インスタンス上で解決できないことが判明しました。ソリューションアーキテクトは、レコードセットが Route 53 で正しく作成されていることを確認しました。この問題を解決するために、ソリューションアーキテクトが取るべき手順の組み合わせを選択してください。(2 つ選択）

■選択肢

A. データベースを新しい VPC の別の EC2 インスタンスにデプロイします。プライベートホストゾーンにインスタンスのプライベート IP のレコードセットを作成します。

B. SSH を使用して、アプリケーション層の EC2 インスタンスに接続します。/etc/resolve.conf ファイルに RDS エンドポイント の IP アドレスを追加します。

C. アカウントA のプライベートホストゾーンをアカウントB の新しい VPC に関連付けるための認証を作成します。

D. アカウントB に example.com ドメイン用のプライベートホストゾーンを作成します。AWS アカウント間で Route 53 レプリケーションを設定します。

E. アカウントB の新しい VPC をアカウントA のホストゾーンに関連付けます。アカウントA の関連付け認証を削除します。

■問題文の要件の概要

  • 状況：Route 53 のプライベートホストゾーンはアカウントAに存在。
  • 課題：アプリケーションとDBはアカウントBで動作中。新しいVPCから db.example.com を解決できない。
  • 要件：プライベートホストゾーンを 別アカウントのVPCから利用できるようにする。

■正解の選択肢と解説

✅ C. アカウントAで関連付け認証を作成

  • 別アカウントのVPCをプライベートホストゾーンに関連付けるには、ゾーン所有者が create-vpc-association-authorization を実行する必要がある。
  • これにより、アカウントBで associate-vpc-with-hosted-zone を実行できるようになる。

✅ E. アカウントBのVPCをアカウントAのホストゾーンに関連付け、認証を削除

  • 認証を作成したら、アカウントBからVPC関連付けを実行。
  • 関連付け完了後は認証を削除してよい（不要かつセキュリティリスク低減）。
  • これにより、アカウントBのVPC内インスタンスも db.example.com を正しく解決可能になる。

■不正解の選択肢の理由

❌ A. EC2 にDBを移してIPを登録

  • 問題の本質は「DNS解決不可」であり、リソースの移設では解決できない。
  • さらに固定IP登録はRDSフェイルオーバーに対応できない。

❌ B. /etc/resolv.conf を編集

  • VPC内DNS解決はVPCのDNSリゾルバーを経由すべき。
  • ローカル設定では動的解決やRDSフェイルオーバーに対応できず、根本解決にならない。

❌ D. アカウントBに別ゾーンを作りレプリケーション

  • Route 53 にはプライベートホストゾーンの「レプリケーション」機能は存在しない。
  • 同名ゾーンを別アカウントに作ると競合や不整合が発生する。

■SAP試験で押さえておくべきポイント

  • Route 53 プライベートホストゾーンの共有方法
    • 異なるアカウントのVPCと関連付けることが可能。
    • 手順：
      1. ホストゾーン所有アカウントが CreateVPCAssociationAuthorization を実行。
      2. 他アカウントのVPCで AssociateVPCWithHostedZone を実行。
      3. 完了後に認証を削除。
  • 誤答パターン：
    • 新しいゾーンを作ればよいと誤解 → 不整合リスク。
    • ローカルの resolv.conf 修正 → VPC DNS解決の仕組みを無視している。
    • リソース再配置で回避しようとする → DNS解決の根本原因を解決できない。

👉 この問題の本質は、
「Route 53 プライベートホストゾーンは、VPC関連付けがなければ別アカウントから解決できない」
という理解です。

次は 問題7 も整理しますか？

はい！問題7 を整理しました。

■問題文

ソリューションアーキテクトは、AWS 環境へのユーザーのアクセスを認証するために、自社のオンプレミス ID プロバイダー (IdP) と SAML 2.0 フェデレーション ID ソリューションを導入しました。ソリューションアーキテクトがフェデレーション ID ウェブポータルを介して認証をテストすると、AWS 環境へのアクセスが許可されます。しかし、テストユーザーがフェデレーション ID ウェブポータルを介して認証を試みると、AWS 環境へのアクセスができません。ID フェデレーションが適切に構成されていることを確認するために、チェックする必要がある項目を選択してください。 (3 つ選択)

■選択肢

A. IAM ユーザーのアクセス許可ポリシーで、そのユーザーに SAML フェデレーションの使用が許可されています。

B. フェデレーションユーザーまたはフェデレーショングループの信頼ポリシー用に作成された IAM ロールが、SAML プロバイダーをプリンシパルとして設定します。

C. テストユーザーが、会社の IdP の AWSFederatedUsers グループに含まれていません。

D. ウェブポータルは、SAML プロバイダーの ARN、IAM ロールの ARN、IdP からの SAML アサーションを使用して AWS STS AssumeRoleWithSAML API を呼び出します。

E. 会社の IdP は、会社のユーザーやグループを適切な権限を持つ IAM ロールに適切にマッピングする SAML アサーションを定義します。

F. オンプレミスの IdP の DNS ホスト名は、AWS 環境の VPC から到達可能です。

■問題文の要件の概要

  • 背景：オンプレ IdP と AWS を SAML 2.0 フェデレーションで連携。
  • 現象：管理者のテストは成功するが、一般ユーザーの認証は失敗。
  • 要件：IdP → AWS のフェデレーション認証フローの正しい構成を確認する必要がある。

■正解の選択肢と解説

✅ B. IAM ロールの信頼ポリシーで SAML プロバイダーをプリンシパルに設定

  • IAM ロールは trust policy でどの IdP/SAML プロバイダーを受け入れるかを定義。
  • 設定されていないと STS が AssumeRoleWithSAML を拒否する。

✅ D. ウェブポータルが AssumeRoleWithSAML API を正しく呼び出す

  • フェデレーション認証では RoleArn / PrincipalArn / SAMLAssertion の3要素が必須。
  • 誤っていると一時的認証情報が取得できずアクセス不可になる。

✅ E. IdP が正しく SAML アサーションでユーザーとIAMロールをマッピング

  • SAMLアサーションには https://aws.amazon.com/SAML/Attributes/Role 属性を含め、
    • IAM RoleArn
    • SAML プロバイダー ARN
      の組み合わせでマッピングする必要がある。

■不正解の選択肢の理由

❌ A. IAMユーザーポリシーでSAMLを許可

  • フェデレーションではIAMユーザーは登場しない。STSがIAMロールの信頼ポリシーを検証するため不要。

❌ C. AWSFederatedUsers グループに含まれていない

  • AWSは社内グループ名を認識しない。必要なのはアサーションに適切なロール情報が含まれていること。

❌ F. IdPのDNSがVPCから到達可能である

  • フェデレーションはユーザーのブラウザがIdPにアクセスし、AWS STSにアサーションを渡す仕組み。AWS VPCからIdPへの接続は不要。

■SAP試験で押さえておくべきポイント

  • SAMLフェデレーションの3つの必須要素
    1. IAMロールの信頼ポリシーにSAMLプロバイダーをプリンシパルとして定義
    2. SAMLアサーションに RoleArn, PrincipalArn の組み合わせを含める
    3. クライアント/ポータルが AssumeRoleWithSAML を正しく呼び出す
  • 誤解しやすい点
    • IAMユーザーポリシーは不要（IAMロールとSTSがメイン）
    • 社内グループ名はAWS側で認識されない（あくまでSAMLアサーションが鍵）
    • フェデレーションはブラウザ経由 → VPCからIdPへ直接接続は不要

👉 この問題の本質は、
「SAMLフェデレーションは IAMロールのtrust policy ・ SAMLアサーション ・ STS呼び出しの3点で成否が決まる」
という理解です。

次は 問題8 も整理しますか？

RELATED POST