Uncategorized

#55

 

了解しました！それでは 問題1 を整理します。

■問題文

企業は、すべてのアプリケーションのデプロイツールとして AWS CloudFormation を使用しています。すべてのアプリケーションのバイナリとテンプレートを、バージョニングを有効にした Amazon S3 バケット内でステージングしています。開発者は、統合開発 (IDE) をホストする Amazon EC2 インスタンスにアクセスできます。開発者は、Amazon S3 から EC2 インスタンスにアプリケーションのバイナリをダウンロードし、変更を加え、ローカルで単体テストを実行した後、S3 バケットにバイナリをアップロードします。開発者は、既存のデプロイの仕組みを改善し、AWS CodePipeline を使用して CI/CD を実装したいと考えています。

開発者には以下の要件があります。

  • ソース管理に AWS CodeCommit を使用します。
  • 単体テストとセキュリティスキャンを自動化します。
  • 単体テストが失敗したときに開発者に警告します。
  • CI/CD の一環として、アプリケーションの機能をオン/オフにし、デプロイを動的にカスタマイズします。
  • アプリケーションをデプロイする前に、主任開発者に承認を提供してもらいます。

これらの要件を満たすソリューションはどれですか？

■選択肢

A：AWS CodeBuild を使用して、テストとセキュリティスキャンを実行します。単体テストが失敗した場合に Amazon EventBridge ルールを使用して、Amazon SNS アラートを開発者に送信します。AWS Cloud Development Kit (AWS CDK) コンストラクトをソリューションの異なる機能ごとに作成し、マニフェストファイルを使用して AWS CDK アプリケーションで機能をオンまたはオフにします。パイプラインで手動の承認ステージを使用して、リード開発者がアプリケーションを承認できるようにします。

B：AWS Lambda を使用して、単体テストとセキュリティスキャンを実行します。パイプラインの後続のステージで Lambda を使用して、単体テストが失敗した場合に Amazon SNS アラートを開発者に送信します。異なるソリューション機能のための AWS Amplify プラグインを作成し、ユーザープロンプトを利用して機能をオンまたはオフにします。パイプラインで Amazon SES を使用して、リード開発者がアプリケーションを承認できるようにします。

C：Jenkins を使用して、単体テストとセキュリティスキャンを実行します。パイプラインで Amazon EventBridge ルールを使用して、単体テストが失敗した場合に Amazon SES のアラートを開発者に送信します。異なるソリューション機能とパラメーターに AWS CloudFormation のネストされたスタックを使用して、機能をオンまたはオフにします。パイプラインで AWS Lambda を使用して、リード開発者がアプリケーションを承認できるようにします。

D：AWS CodeDeploy を使用して、単体テストとセキュリティスキャンを実行します。パイプラインで Amazon CloudWatch アラームを使用して、単体テストが失敗した場合に Amazon SNS アラートを開発者に送信します。異なるソリューション機能に Docker イメージを使用し、AWS CLI を使用して機能をオンまたはオフにします。パイプラインで手動の承認ステージを使用して、リード開発者がアプリケーションを承認できるようにします。

■問題文の要件の概要

  • ソース管理 → CodeCommit
  • 単体テストとセキュリティスキャンの自動化 → CIフェーズで必要
  • 失敗時に通知 → SNS通知が必要
  • 機能のオン/オフ切り替え → CDKなどのIaCで動的制御が必要
  • デプロイ前に承認 → CodePipeline の Manual Approval が必要

■正解の選択肢と解説

✅ A：AWS CodeBuild + EventBridge + SNS + AWS CDK + Manual Approval

  • AWS CodeBuild はテストやセキュリティスキャンを自動実行可能。
  • EventBridge + SNS でテスト失敗時に開発者へアラート通知。
  • AWS CDK のコンストラクトとマニフェストで機能をオン/オフ可能（Feature Flag 的制御）。
  • CodePipeline Manual Approval ステージでリード開発者の承認を挿入。
    ➡️ CI/CD の各要件をすべて満たす構成。

■不正解の選択肢の理由

  • B（Lambda + Amplify + SES）
    • Lambda は長時間実行や依存管理に不向きでビルド/テスト用途には不適。
    • Amplify プラグインはCI/CDでの機能フラグ管理に向かない。
    • SESによるメールは CodePipeline の承認アクションと統合できない。
  • C（Jenkins + CFNネスト + Lambda承認）
    • Jenkins は自己運用が必要でマネージド統合不足。
    • CFNネストは機能のオン/オフを動的に制御する用途に不向き。
    • Lambdaで承認を代替するのは誤り（人手によるManual Approvalが必要）。
  • D（CodeDeploy + CloudWatch Alarm + CLI機能制御）
    • CodeDeployはデプロイ専用でテスト/スキャン機能を持たない。
    • CloudWatch Alarmはテスト失敗の通知には不適（閾値監視用）。
    • Docker + CLIによる機能制御はパイプラインでの動的切替には不向き。

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

  • CodeBuild = ビルド・テスト・スキャンの実行基盤
  • EventBridge + SNS = CI/CD イベント駆動型通知のベストプラクティス
  • AWS CDK での機能フラグ管理 → 動的デプロイの実現方法
  • CodePipeline Manual Approval = ヒューマンガバナンス
  • LambdaやCodeDeployは役割が異なる → 適材適所のサービス選択が重要

👉 この問題のポイントは「AWS ネイティブ CI/CD サービスを組み合わせて要件をすべて満たす」ことです。

次の問題（問題2）もこの形式でまとめましょうか？

はい！それでは 問題2 を整理します。

■問題文

ある会社は、多様な集団から大量のデータサンプルを収集する研究者を支援するために、ゲノム情報を収集する遺伝子報告装置を開発しています。この装置は、毎秒 8 KB のゲノムデータをデータプラットフォームにプッシュし、データプラットフォームは、データを処理・分析して、研究者に情報を提供する必要があります。

データプラットフォームは、以下の要件を満たす必要があります。

  • インバウンドしたゲノムデータのほぼリアルタイムの分析を提供します。
  • データが実行可能で、並列性があり、耐久性があることを保証します。
  • 処理の結果をデータウェアハウスに配信します。

これらの要件を満たすために、ソリューションアーキテクトはどの戦略を使用する必要がありますか？

■選択肢

A：Amazon Kinesis Data Firehose を使用して、インバウンドセンサーデータを収集し、Kinesis クライアントでデータを分析し、結果を Amazon RDS インスタンスに保存します。

B：Amazon Kinesis Data Streams を使用して、インバウンドセンサーデータを収集し、Kinesis クライアントでデータを分析し、Amazon EMR を使用して結果を Amazon Redshift クラスターに保存します。

C：Amazon S3 を使用して、インバウンドデバイスデータを収集し、Kinesis で Amazon SQS のデータを分析し、結果を Amazon Redshift クラスターに保存します。

D：Amazon API Gateway を使用して Amazon SQS キューにリクエストを入れ、AWS Lambda 関数でデータを分析し、Amazon EMR を使用して結果を Amazon Redshift クラスターに保存します。

■問題文の要件の概要

  • ほぼリアルタイム分析 → ストリーミング処理が必須
  • 並列性と耐久性の確保 → シャーディングや耐久保持の仕組みが必要
  • 分析結果をDWHに配信 → Amazon Redshift へロードできる仕組みが必要

■正解の選択肢と解説

✅ B：Amazon Kinesis Data Streams + Kinesis クライアント + Amazon EMR + Redshift

  • Kinesis Data Streams → ミリ秒単位の遅延でデータを収集、シャード単位で水平スケールし耐久保持（最大7日）。並列処理可能。
  • Kinesis Client Library (KCL) → 各シャードを自動ロードバランスしてリアルタイム分析可能。
  • Amazon EMR (Spark Streaming など) → データを加工・分析し、結果を Redshift にロード可能。
  • Redshift → 大量の分析結果を格納する DWH として最適。

➡️ リアルタイム性・並列性・耐久性・データウェアハウス配信のすべての要件を満たす。

■不正解の選択肢の理由

  • A（Firehose + RDS）
    • Firehose は最小 60 秒 or 1 MB バッファリング → リアルタイム性不足。
    • RDS は大量ストリームを継続的に書き込む用途に非適合。
  • C（S3 + SQS + Kinesis + Redshift）
    • S3 はオブジェクトストレージでリアルタイム処理不可。
    • SQS を挟むと遅延が発生。要件の「ほぼリアルタイム」に不適。
  • D（API Gateway + SQS + Lambda + EMR + Redshift）
    • API Gateway は高頻度ストリーム処理に向かずスループット制限あり。
    • Lambda は高頻度・長時間処理に不適（同時実行・15分制限）。

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

  • Kinesis Data Streams → リアルタイム処理・並列処理・耐久保持を満たすストリーミング基盤。
  • Kinesis Firehose → ほぼバッチ書き込み専用。リアルタイム分析には不適。
  • S3やSQS → バッファやキュー用途であり、低遅延処理には向かない。
  • Redshift → DWH として処理結果の集約先に最適。
  • リアルタイム処理系の設計問題では「Kinesis Data Streams + 分析基盤 (EMR / Lambda / Kinesis Analytics) + DWH/Storage」パターンを押さえることが重要。

👉 この問題は「リアルタイムストリーミング処理のサービス選択」がポイントです。

次の 問題3 もこの形式でまとめますか？

はい！それでは 問題3 を整理します。

■問題文

ソリューションアーキテクトが、新しいセキュリティツールを、これまで使われていなかったいくつかの AWS リージョンにデプロイする準備をしています。ソリューションアーキテクトは、AWS CloudFormation StackSets を使用してツールをデプロイします。StackSets のテンプレートには、カスタム名を持つ IAM ロールが含まれています。StackSets の作成時に、スタックインスタンスが正常に作成されません。

スタックを正常にデプロイする最適な方法を選択してください。

■選択肢

A：すべての関連アカウントで新しいリージョンを有効にします。StackSets の作成時に、CAPABILITY_NAMED_IAM 機能を指定します。

B：Service Quotas コンソールを使用して、関連するすべてのアカウントで、各新しいリージョンの CloudFormation スタックの数のクォータの増加をリクエストします。StackSets の作成時に、CAPABILITY_IAM 機能を指定します。

C：StackSets の作成時に、CAPABILITY_NAMED_IAM 機能と SELF_MANAGED アクセス許可モデルを指定します。

D：StackSets の作成時に、管理ロールの ARN と CAPABILITY_IAM 機能を指定します。

■問題文の要件の概要

  • 複数リージョンへの新規デプロイ（一部リージョンはまだ有効化されていない）
  • CloudFormation StackSets を使用
  • テンプレート内にカスタム名の IAM ロールあり
  • スタックインスタンスが失敗 → IAMロール作成権限やリージョン有効化が原因

■正解の選択肢と解説

✅ A：新しいリージョンを有効化 + CAPABILITY_NAMED_IAM を指定

  • CAPABILITY_NAMED_IAM → カスタム名を持つ IAM リソースを作成する際に必須の指定。
  • 新しいリージョン有効化 → 対象リージョンがアカウントで未有効だと StackSets デプロイに失敗。
  • この2点を組み合わせることで、エラーなくスタックインスタンスを作成可能。

➡️ StackSets で IAM ロールの作成に失敗する典型的な理由は「CAPABILITY_NAMED_IAM の不足」。加えて新しいリージョン未有効も失敗要因となるため、この選択肢が最適解。

■不正解の選択肢の理由

  • B（Service Quotas + CAPABILITY_IAM）
    • 問題はクォータ超過ではない。
    • CAPABILITY_IAM ではカスタム名 IAM ロールを作成できず失敗する。
  • C（CAPABILITY_NAMED_IAM + SELF_MANAGED）
    • SELF_MANAGED モデルでは事前に実行ロールを各アカウント/リージョンへ配布が必要。
    • 本シナリオでは追加準備がないため、権限不足で失敗。
  • D（管理ロール ARN + CAPABILITY_IAM）
    • 管理ロール ARN を指定しても、カスタム名 IAM リソースには CAPABILITY_NAMED_IAM が必須。
    • CAPABILITY_IAM のみでは不十分で失敗。

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

  • CAPABILITY_IAM → 通常の IAM リソース作成に必要。
  • CAPABILITY_NAMED_IAM → カスタム名付き IAM リソースの作成に必須。
  • StackSets
    • SERVICE_MANAGED（推奨）: AWS Organizations と統合、自動的に管理・実行ロールを作成。
    • SELF_MANAGED: 各アカウント/リージョンに管理・実行ロールを手動作成が必要。
  • リージョン有効化 → 未使用リージョンではリソース作成できないため事前に有効化する。

👉 この問題の本質は「StackSets で IAM カスタム名リソースを扱うには CAPABILITY_NAMED_IAM を必ず指定する」ことと、「対象リージョンの有効化が必須」という2点です。

次の 問題4 も同じ形式でまとめますか？

了解しました！問題4 を整理します。

■問題文

ある企業は、開発者が AWS Marketplace を通じてサードパーティ製のソフトウェアを購入できるようにしたいと考えています。同社は、全機能が有効になっている AWS Organizations のアカウント構造を使用しており、調達マネージャーが使用する各組織単位 (OU) に共有サービスアカウントを持っています。調達チームのポリシーでは、開発者は承認されたリストからのみサードパーティ製のソフトウェアを入手し、AWS Marketplace のプライベートマーケットプレイスを使用してこの要件を達成できるようにする必要があります。調達チームは、プライベートマーケットプレイスの管理を、調達マネージャーが引き受けることができる調達マネージャーロールという名前のロールに制限することを望んでいます。会社の他の IAM ユーザー、グループ、ロール、およびアカウント管理者は、プライベートマーケットプレイスの管理アクセスを拒否する必要があります。

これらの要件を満たすアーキテクチャを設計するための最も効率的な方法を選択してください。

■選択肢

A：組織内のすべての AWS アカウントに procurement-manager-role という名前の IAM ロールを作成します。このロールに PowerUserAccess 管理ポリシーを追加します。すべての AWS アカウントのすべての IAM ユーザーとロールにインラインポリシーを適用し、AWSPrivateMarketplaceAdminFullAccess 管理ポリシーのアクセス許可を拒否します。

B：組織内のすべての AWS アカウントに procurement-manager-role という名前の IAM ロールを作成します。このロールに AdministratorAccess 管理ポリシーを追加します。AWSPrivateMarketplaceAdminFullAccess 管理ポリシーを使用して権限境界を定義し、それをすべての開発者ロールにアタッチします。

C：組織内のすべての共有サービスアカウントに procurement-manager-role という名前の IAM ロールを作成します。このロールに AWSPrivateMarketplaceAdminFullAccess 管理ポリシーを追加します。組織のルートレベルの SCP を作成し、プライベートマーケットプレイスを管理する権限を、 procurement-manager-role というロールを除く全員に拒否します。別の組織ルートレベルの SCP を作成して、組織内の全員に procurement-manager-role という名前の IAM ロールを作成する権限を拒否します。

D：開発者が使用するすべての AWS アカウントに procurement-manager-role という名前の IAM ロールを作成します。このロールに AWSPrivateMarketplaceAdminFullAccess 管理ポリシーを追加します。Organizations に SCP を作成し、procurement-manager-role というロールを除く全員にプライベートマーケットプレイスの管理権限を拒否します。組織内のすべての共有サービスアカウントに SCP を適用します。

■問題文の要件の概要

  • 開発者が AWS Marketplace でソフトウェアを購入可能にする。
  • ただし、承認されたリストのみ（Private Marketplace を利用）。
  • Private Marketplace の管理は 調達マネージャーロールのみに限定。
  • 他のユーザー/ロール/管理者は管理権限を持たないよう制御。
  • AWS Organizations（SCP）を活用することが前提。

■正解の選択肢と解説

✅ C：共有サービスアカウントに procurement-manager-role を作成し、SCP で管理権限を制御する

  • 共有サービスアカウントに限定的な管理ロールを置くことで管理を一元化。
  • AWSPrivateMarketplaceAdminFullAccess を付与することで Private Marketplace の編集や承認が可能。
  • SCP を組織ルートに適用し、
    • procurement-manager-role 以外には Private Marketplace 管理 API を拒否。
    • 誰も勝手に procurement-manager-role を作成・変更できないよう制御。
  • これにより、承認済みの調達マネージャーだけが Private Marketplace を管理でき、セキュリティと運用効率の両方を満たす。

■不正解の選択肢の理由

  • A：
    • PowerUserAccess では Private Marketplace 管理 API を実行できない。
    • 各アカウントに拒否ポリシーを個別適用するのは運用負荷が高い。
  • B：
    • AdministratorAccess を広く付与してしまい、開発者が権限昇格可能。
    • 許可境界だけでは横展開を防げず SCP 不使用のため要件不達。
  • D：
    • 管理ロールを「開発者アカウント」に配置してしまい本来の要件（共有サービスアカウント集中管理）と逆転。
    • 開発者が直接 Marketplace 管理権限を持ってしまう危険あり。

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

  • Private Marketplace 管理権限は AWSPrivateMarketplaceAdminFullAccess ポリシーで付与する。
  • 管理ロールの配置先は共有サービスアカウント（セキュリティ・ガバナンスの集中管理）。
  • SCP の活用
    • 管理権限を「誰もが勝手に取得できない」よう制御する。
    • 特定ロール（例：procurement-manager-role）のみを例外的に許可する構成がベストプラクティス。
  • 権限境界や PowerUserAccess では制御不十分。ガバナンスは SCP が必須。

👉 この問題の本質は、**「Private Marketplace の管理権限を組織的に 1 つのロールへ集中させ、SCP で強制的に制御する」**という設計原則です。

次の問題（問題5）も同じ形式で整理しましょうか？

承知しました！問題5 を整理します。

■問題文

ある企業では、1 万個以上のセンサーがあり、MQTT (Message Queuing Telemetry Transport) プロトコルを使用して、オンプレミスの Apache Kafka サーバーにデータを送信しています。オンプレミスの Kafka サーバーに接続された別のプロセスがデータを変換し、その結果を Amazon S3 バケットにオブジェクトとして保存します。

最近、Kafka サーバーに障害が発生しました。これにより同社は、サーバーの復旧作業中にセンサーデータを失いました。ソリューションアーキテクトは、同様の事態を防ぐために、可用性と拡張性に優れた新しい設計を AWS 上に作成する必要があります。

運用上のオーバーヘッドが最も少なく、これらの要件を満たすソリューションを選択してください。

■選択肢

A：AWS IoT Core をデプロイし、Amazon EC2 インスタンスを起動して Kafka サーバーをホストします。AWS IoT Core は、EC2 インスタンスにデータを送信するように構成します。センサーをルーティングして、AWS IoT Core にデータを送信します。

B：オンプレミスの Kafka サーバーを Amazon Managed Streaming for Apache Kafka (Amazon MSK) に移行します。Amazon MSK ブローカーを指す Network Load Balancer (NLB) を作成します。NLB ヘルスチェックを有効にします。センサーをルーティングして、NLB にデータを送信します。

C：AWS IoT Core をデプロイし、Amazon Kinesis Data Firehose 配信ストリームに接続します。AWS Lambda 関数を使用してデータ変換を処理します。センサーをルーティングして、AWS IoT Core にデータを送信します。

D：2 つの Amazon EC2 インスタンスを起動して、2 つのアベイラビリティーゾーンにまたがるアクティブ / スタンバイ構成で Kafka サーバーをホストします。Amazon Route 53 でドメイン名を作成します。Route 53 フェイルオーバーポリシーを作成します。センサーをルーティングしてデータをドメイン名に送信します。

■問題文の要件の概要

  • 1万台以上のセンサーが MQTT プロトコルでデータ送信。
  • これまでは オンプレ Kafka → 変換プロセス → S3 だった。
  • Kafka 障害でデータを喪失 → 高可用性＆拡張性が必須。
  • 運用負荷を最小化するフルマネージド構成が求められる。

■正解の選択肢と解説

✅ C：AWS IoT Core + Kinesis Data Firehose + Lambda

  • AWS IoT Core
    • MQTT をネイティブサポート。数十万デバイス同時接続を自動スケール。
    • マルチ AZ 冗長化によりデータ喪失リスクを軽減。
  • Kinesis Data Firehose
    • IoT Core ルールから直接データ送信可能。
    • バッファと再試行機能により 確実に Amazon S3 へ保存。
  • AWS Lambda
    • Firehose のデータ変換に利用。
    • サーバーレスで自動スケーリングし、追加運用負荷なし。

👉 フルマネージド構成で、Kafka のようなクラスタ管理・スケーリング調整は不要。運用コストが最も低く、データロスを防ぐ設計。

■不正解の選択肢の理由

  • A
    • Kafka を EC2 で自己運用 → 障害対応・スケーリング・パッチ適用など運用負荷が残る。
    • IoT Core 経由でも本質的に Kafka の SPOF 問題は解決できない。
  • B
    • Amazon MSK は Kafka をマネージド提供するが MQTT をネイティブサポートしていない。
    • センサーからの MQTT を直接受信できず、ブリッジ実装が必要 → 運用負荷増。
  • D
    • EC2 2台での Kafka アクティブ/スタンバイは水平スケール不可。
    • Route 53 フェイルオーバーでは Kafka のクラスタ要件（分散ログ保持・再同期）を満たせず、データ喪失リスクが残る。

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

  • MQTT を扱う IoT データ取り込みは AWS IoT Core が最適解。
  • Amazon Kinesis Data Firehose はストリーミングデータの確実な配送に利用（S3, Redshift, OpenSearch など）。
  • Lambda を Firehose と組み合わせると ETL がサーバーレスで実現可能。
  • MSK は MQTT 非対応 → IoT データ取り込み用途では不適。
  • EC2/Kafka 自己運用は高可用性・スケーラビリティで劣るため NG。

👉 この問題の本質は、IoT デバイスの MQTT データを可用性・拡張性を確保しつつ最小運用コストで S3 に安全保存できる設計を選べるかです。

次の問題（問題6）も同じ形式でまとめましょうか？

ありがとうございます！問題6 を整理します。

■問題文

ある研究センターは AWS クラウドに移行しており、オンプレミスの 1 PB オブジェクトストレージを Amazon S3 バケットに移動しました。100 人の科学者がこのオブジェクトストレージを使用して、仕事関連のドキュメントを保存しています。各科学者はオブジェクトストレージ上に個人フォルダを持っています。すべての科学者は、単一の IAM ユーザーグループのメンバーです。

研究センターのコンプライアンス責任者は、科学者たちがお互いの研究内容にアクセスできるようになるのではないかと懸念しています。研究センターには、どの科学者がどのドキュメントにアクセスしたかをレポートする厳格な義務があります。これらのレポートを担当するチームは AWS の経験がほとんどなく、運用オーバーヘッドを最小限に抑えるすぐに使用できるソリューションを望んでいます。

これらの要件を満たす最適なアクションの組み合わせを選択してください。(2 つ選択)

■選択肢

A：ユーザーに読み取りと書き込みのアクセスを許可するアイデンティティポリシーを作成します。S3 パスの先頭に $(aws:username) を付けることを指定する条件を追加します。科学者の IAM ユーザーグループにポリシーを適用します。

B：AWS CloudTrail で証跡を構成し、S3 バケット内のすべてのオブジェクトレベルのイベントをキャプチャします。証跡の出力を別の S3 バケットに保存します。Amazon Athena を使用して、ログをクエリし、レポートを生成します。

C：S3 サーバーのアクセスログを有効にします。別の S3 バケットをログ配信のターゲットとして設定します。Amazon Athena を使用して、ログをクエリし、レポートを生成します。

D：科学者の IAM ユーザーグループのユーザーに読み取りと書き込みのアクセスを許可する S3 バケットポリシーを作成します。

E：AWS CloudTrail で証跡を構成し、S3 バケット内のすべてのオブジェクトレベルのイベントをキャプチャし、イベントを Amazon CloudWatch に書き込みます。Amazon Athena CloudWatch コネクタを使用して、ログをクエリし、レポートを生成します。

■問題文の要件の概要

  • 各科学者は 自分のフォルダにのみアクセス可能にする必要がある。
  • コンプライアンス要件で 誰がどのオブジェクトにアクセスしたかを監査・レポートしなければならない。
  • AWS に不慣れなチームでも運用できる、運用オーバーヘッドの低い仕組みが求められている。

■正解の選択肢と解説

✅ A + B

  • A (IAM アイデンティティポリシー with ${aws:username})
    • ユーザー名をプレフィックスにしたフォルダを強制。
    • 例: arn:aws:s3:::research-bucket/${aws:username}/*
    • 各ユーザーは自分のディレクトリにしかアクセスできず、他人の研究内容を参照できない。
  • B (CloudTrail + Athena)
    • CloudTrail の データイベントで S3 オブジェクトレベル操作をすべて記録。
    • ログは S3 に保存され、Athena で SQL クエリしてレポート生成可能。
    • 追加インフラ不要で、AWS 未経験のチームでも簡単に使える。

👉 この組み合わせで アクセス制御とコンプライアンス監査を同時に実現でき、かつ運用負荷が最小。

■不正解の選択肢の理由

  • C（S3 サーバーアクセスログ）
    • API イベントの一部しか記録されない。IAM ユーザーを明確に識別できないケースもあり、コンプライアンス要件を満たせない。
  • D（S3 バケットポリシー）
    • グループ全体への一括付与となり、各ユーザーごとのフォルダ制御ができない。結果的に他人のフォルダにアクセス可能になってしまう。
  • E（CloudTrail → CloudWatch → Athena コネクタ）
    • CloudWatch Logs へのルーティングやコネクタ構築が必要で設定が複雑。
    • S3 へ直接保存して Athena でクエリするシンプル構成に比べてオーバーヘッドが大きい。

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

  • ユーザー単位の S3 アクセス制御は IAM ポリシーで ${aws:username} を使うのがベストプラクティス。
  • S3 の監査ログは CloudTrail データイベントを使用。サーバーアクセスログは補助用途であり、完全な監査には不十分。
  • Athena + CloudTrail は運用負荷が小さい監査ソリューションとして頻出。
  • バケットポリシーは全体への制御に適し、ユーザーごとの制御は IAM 側で行う。
  • 試験の狙いは「アクセス制御」と「コンプライアンス監査」を両立できる最小運用構成を選べるか。

👉 この問題は 「アクセス制御」と「監査」両面をどう組み合わせるか がポイントですね。

次の 問題7 も同じ形式で整理しますか？

ありがとうございます！問題7 を整理しました。

■問題文

ある企業は、ユーザー向けのインフラストラクチャサービスのプラットフォームを構築しています。この企業には以下のような要件があります。

  • AWS インフラストラクチャの起動時にユーザーに最小限の特権アクセスを提供し、ユーザーが承認されていないサービスをプロビジョニングできないようにします。
  • インフラサービスの作成を中央アカウントで管理します。
  • AWS Organizations の複数のアカウントにインフラストラクチャサービスを配布する機能を提供します。
  • ユーザーが起動したインフラストラクチャにタグを適用する機能を提供します。

これらの要件を満たす AWS サービスを利用したアクションの組み合わせを選択してください。 (3 つ選択)

■選択肢

A：AWS CloudFormation テンプレートを使用してインフラストラクチャサービスを開発します。テンプレートを中央の Amazon S3 バケットに追加し、S3 バケットポリシーへのアクセスを必要とする IAM ロールまたはユーザーを追加します。

B：AWS CloudFormation テンプレートを使用してインフラストラクチャサービスを開発します。各テンプレートを AWS Service Catalog 製品として、中央の AWS アカウントで作成したポートフォリオにアップロードします。これらのポートフォリオを、会社用に作成した組織構造と共有します。

C：ユーザーの IAM ロールに AWSCloudFormationFullAccess と AmazonS3ReadOnlyAccess 権限を持つことを許可します。AWS アカウントのルートユーザーレベルで Organizations の SCP を追加して、AWS CloudFormation と Amazon S3 以外のすべてのサービスを拒否します。

D：ユーザーの IAM ロールに ServiceCatalogEndUserAccess アクセス許可のみを許可します。自動化スクリプトを使用して、中央ポートフォリオをローカル AWS アカウントにインポートし、TagOption をコピーし、ユーザーにアクセス割り当て、起動制約を適用します。

E：AWS Service Catalog TagOption ライブラリを使用して、会社が必要とするタグのリストを維持します。TagOption を AWS Service Catalog の製品またはポートフォリオに適用します。

F：AWS CloudFormation リソースタグのプロパティを使用して、ユーザー用に作成される CloudFormation テンプレートにタグを適用します。

■問題文の要件の概要

  • 最小権限アクセス（ユーザーは承認済みリソースのみ利用可能にする）
  • 中央集約管理（インフラは中央アカウントから提供）
  • マルチアカウント配布（Organizations 経由で共有）
  • タグ強制（起動リソースに標準タグを付与）

■正解の選択肢と解説

✅ B + D + E

  • B (Service Catalog ポートフォリオ + Organizations 共有)
    • 中央アカウントで CloudFormation テンプレートを Service Catalog 製品として登録。
    • ポートフォリオを AWS Organizations と共有することで、複数アカウントに統一配布可能。
    • 起動制約により最小特権でサービスを起動可能。
  • D (ServiceCatalogEndUserAccess ロール + 自動化スクリプト)
    • ユーザーは承認済み製品しか起動できない。
    • 自動化スクリプトで中央ポートフォリオを各アカウントへインポート。
    • 必須タグ (TagOption) や起動制約を強制できる。
  • E (TagOption ライブラリによるタグ強制)
    • 組織標準のタグセットを一元管理。
    • 製品やポートフォリオに適用すれば、リソース作成時に自動的に継承される。
    • コスト配分や運用管理に必須。

👉 この3つで 最小特権アクセス + 中央管理 + マルチアカウント配布 + タグ適用 を満たせる。

■不正解の選択肢の理由

  • A
    • CloudFormation + S3 保存だけではガバナンスや最小特権を制御できない。
    • Service Catalog のような承認済み製品管理や Organizations 共有機能がない。
  • C
    • CloudFormation 実行に必要な IAM、EC2 など他サービスが SCP でブロックされてしまい、スタックが正常にデプロイできない。
  • F
    • CloudFormation テンプレートにタグを書いてもユーザーが削除・改変可能で、タグ強制の仕組みとして不十分。

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

  • Service Catalog は承認済み CloudFormation テンプレートを 製品として配布する仕組み。
  • Organizations との統合により、マルチアカウントへ一括配布が可能。
  • EndUserAccess ロール + 起動制約 により、ユーザーは最小権限で製品を利用できる。
  • TagOption ライブラリは強制タグ付与の仕組み。タグ標準化やコスト配分に必須。
  • SCP は乱用厳禁：CloudFormation の裏で必要なサービスをブロックしてしまうリスクがある。

👉 この問題は「Service Catalog を使ってマルチアカウントに承認済みインフラを配布し、タグ強制と最小特権を同時に実現できるか」がポイントですね。

次の 問題8 も同じ形式でまとめますか？

RELATED POST