以下は、SAP試験・問題1 に関する詳細な整理・解説です。
■ 問題文(文字列を編集せずに出力)
ある企業は、Amazon API Gateway、AWS Lambda、Amazon DynamoDB を使用するウェブアプリケーションがあります。最近のマーケティングキャンペーンで需要が増加しました。監視ソフトウェアは、多くのリクエストの応答時間がマーケティングキャンペーン前よりも大幅に長くなっていることを報告しています。
ソリューションアーキテクトは、API Gateway の Amazon CloudWatch Logs を有効にしたところ、リクエストの 20 % でエラーが発生していることに気付きました。CloudWatch では、Lambda 関数の Throttles メトリクスがリクエストの 1 % を表し、Errors メトリクスがリクエストの 10 % を表しています。アプリケーションログによると、エラーが発生しているのは DynamoDB への呼び出し時です。
ウェブアプリケーションの人気が高まるにつれて、現在のレスポンスタイムを改善するために、ソリューションアーキテクトが行う最適な変更方法を選択してください。
■ 選択肢(文字列を編集せずに出力、正解は伏せてあります)
A. Lambda 関数の同時実行数の制限を増やします。
B. テーブルに DynamoDB Auto Scaling を実装します。
C. API Gateway のスロットル制限を増やします。
D. より適切にパーティション分割されたプライマリインデックスを使用して DynamoDB テーブルを再作成します。
■ 問題文の要件の概要
要件 | 内容 |
---|---|
システム構成 | API Gateway → Lambda → DynamoDB |
現象 | 応答時間の悪化、CloudWatch によるエラー多発 |
CloudWatch 状況 | 20%のリクエストでエラー、Lambda Throttle 1%、Lambda Error 10% |
アプリケーションログ | エラーの主因は DynamoDB 呼び出し |
解決すべき課題 | スケーラビリティ向上・パフォーマンス改善 |
■ 正解の選択肢とその解説
✅ B. テーブルに DynamoDB Auto Scaling を実装します。
- 理由:
アプリケーションログで明確に「DynamoDB 呼び出しでエラーが発生している」と記録されています。これはリクエストの増加によって プロビジョンドキャパシティ が不足しており、スロットリングやタイムアウトが発生していると推察されます。 - DynamoDB Auto Scaling を有効にすることで、トラフィック増加時に自動的にスループットがスケーリングされ、遅延やエラーの軽減が可能です。
■ 不正解の選択肢の理由
❌ A. Lambda 関数の同時実行数の制限を増やします。
- CloudWatch によれば Lambda のスロットルは 1% にとどまり、主要因ではない。
- Lambda の制限を緩和しても、根本的に DynamoDB 側の制限がボトルネックのままなので、効果が限定的。
❌ C. API Gateway のスロットル制限を増やします。
- エラーが API Gateway ではなく バックエンド(DynamoDB)で発生しているため、これも効果なし。
- スロットル緩和によりリクエスト数が増えると、むしろ DynamoDB の負荷が増し悪化する可能性も。
❌ D. より適切にパーティション分割されたプライマリインデックスを使用して DynamoDB テーブルを再作成します。
- パーティション設計は長期的に有効だが、現時点の課題は スループット不足。
- 再構築には時間がかかり、短期的なスケーラビリティ問題の解決には不適。
■ SAP試験で押さえておくべきポイント
試験対策ポイント | 内容 |
---|---|
DynamoDB Auto Scaling | プロビジョンされた読み書き容量を動的に調整し、トラフィック変化に対応可能 |
CloudWatch メトリクスの読み取り力 | エラーやスロットル率をもとに ボトルネック特定が問われる |
Lambda・API Gateway・DynamoDB の関係性 | 問題の原因がどの層にあるかを正確に判断 |
インフラの動的スケーリングの設計力 | 需要急増に対してスケーリング戦略を持っていること |
根本原因を判断して最小限の変更で解決 | 無関係な構成変更(例:IAM、パーティション再設計など)に注意 |
次の問題も続けて送っていただければ、同様に整理してお返しします。
以下は、SAP試験・問題2 に関する詳細な整理と解説です。
■ 問題文(文字列を編集せずに出力)
エンターテインメント会社が最近新しいゲームを発売しました。リリース期間中、プレイヤーに良好なエクスペリエンスを提供するため、同社は Network Load Balancer の背後に 12 台の r6g.16xlarge (メモリ最適化) の Amazon EC2 インスタンスを静的にデプロイしました。同社の運用チームは、Amazon CloudWatch エージェントとカスタムメトリクスを使用して、メモリ使用率をモニタリング戦略に組み込みました。
発売期間の CloudWatch メトリクスを分析したところ、同社が予想していた CPU とメモリの約 4 分の 1 が消費されていることがわかりました。ゲームに対する当初の需要は落ち着き、より変動するようになりました。同社は、CPU とメモリの消費量を監視する Auto Scaling グループを使用して、インスタンスフリートを動的にスケーリングすることにしました。ソリューションアーキテクトは、最もコスト効率の高い方法で需要を満たすために、Auto Scaling グループを構成する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢(正解がどれか分からないようにそのまま出力)
A.
c6g.4xlarge (コンピューティング最適化) インスタンスをデプロイするように Auto Scaling グループを構成します。最小キャパシティを 3、希望するキャパシティを 3、最大キャパシティを 12 に設定します。
B.
m6g.4xlarge (汎用) インスタンスをデプロイするように Auto Scaling グループを構成します。最小キャパシティを 3、希望するキャパシティを 3、最大キャパシティを 12 に設定します。
C.
r6g.4xlarge (メモリ最適化) インスタンスをデプロイするように Auto Scaling グループを構成します。最小キャパシティを 3、希望するキャパシティを 3、最大キャパシティを 12 に設定します。
D.
r6g.8xlarge (メモリ最適化) インスタンスをデプロイするように Auto Scaling グループを構成します。最小キャパシティを 2、希望するキャパシティを 2、最大キャパシティを 6 に設定します。
■ 問題文の要件の概要
要件 | 内容 |
---|---|
現在の構成 | r6g.16xlarge × 12 台、静的構成、NLB 配下 |
モニタリング状況 | CPU/メモリ使用率は 25% 程度、過剰プロビジョニング状態 |
今後のニーズ | 需要の変動に応じて 動的スケーリング したい |
最重要要件 | コスト効率を重視、必要な性能は維持しつつリソースを最適化 |
■ 正解の選択肢とその解説
✅ C. r6g.4xlarge (メモリ最適化) インスタンスをデプロイするように Auto Scaling グループを構成します。
- 理由:
現在の r6g.16xlarge はオーバースペックであることが CloudWatch メトリクスから明らかです。
r6g.4xlarge は同じメモリ最適化ファミリーであり、必要なアプリケーション要件を満たしながら、大幅なコスト削減が可能です。 - Auto Scaling を使って変動に柔軟に対応できるため、コスト効率と可用性の両立ができます。
■ 不正解の選択肢の理由
❌ A. c6g.4xlarge(コンピューティング最適化)を使用
- CPU 最適化は 計算集約型アプリケーションに向いており、メモリ最適化が求められる本問には不適。
❌ B. m6g.4xlarge(汎用)を使用
- m6g はバランス型で、コスト効率も悪くはないが、メモリ最適化された r6g に比べて適性が劣る。
- 問題文に「メモリ使用率のモニタリング」とあるため、明確にメモリ重視の要件であると読み取れる。
❌ D. r6g.8xlarge を使用
- メモリ最適化タイプで方向性は正しいが、インスタンスサイズがまだ大きく、コスト効率に欠ける。
- わざわざ r6g.16xlarge から半分サイズにするよりも、さらに細かくスケーリングできる r6g.4xlarge の方が Auto Scaling にも適している。
■ SAP試験で押さえておくべきポイント
項目 | 説明 |
---|---|
インスタンスタイプ選定力 | 使用リソースに基づいて、適切なファミリー(Compute / Memory / General)を判断する |
Auto Scaling 戦略 | トラフィックの変動に応じて、動的にスケールする構成が最適解であることが多い |
リソース最適化とコスト削減 | 使用率が低ければ、オーバースペックなリソースを見直してコスト削減を検討する |
メモリ最適化インスタンスの特徴 | データセットを多く扱うワークロード、ゲームや分析系処理に適している |
次の問題があれば、続けて送ってください。引き続き、同様の形式で対応いたします。
以下は、SAP試験・問題3 に関する詳細な整理と解説です。
■ 問題文(文字列を編集せずに出力)
ある会社が、サードパーティーのウェブアプリケーションを AWS にデプロイしています。アプリケーションは Docker イメージとしてパッケージ化されています。同社は、Amazon Elastic Container Service (Amazon ECS) の AWS Fargate サービスとして Docker イメージをデプロイしました。Application Load Balancer (ALB) がアプリケーションにトラフィックを転送します。
同社は、インターネットからアプリケーションにアクセスする能力を、特定のユーザーリストにのみ与える必要があります。同社はアプリケーションを変更することはできず、アプリケーションを ID プロバイダーと統合することもできません。すべてのユーザーは、多要素認証 (MFA) によって認証される必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢(文字列を編集せずに出力)
A.
Amazon Cognito でユーザープールを作成します。アプリケーション用にプールを構成します。必要なユーザーをプールに追加します。MFA を要求するようにプールを設定します。ALB でリスナールールを構成して、Amazon Cognito でホストされる UI を介した認証を要求します。
B.
AWS Identity and Access Management (IAM) でユーザーを構成します。ユーザーに MFA の使用を要求するために、Fargate サービスにリソースポリシーをアタッチします。ALB のリスナールールを設定して、IAM を介して認証を要求します。
C.
AWS Identity and Access Management (IAM) でユーザーを構成します。AWS IAM Identity Center (AWS Single Sign-On) を有効にします。ALB のリソース保護を設定します。ユーザーに MFA の使用を要求するリソース保護ルールを作成します。
D.
AWS Amplify にユーザープールを作成します。アプリケーション用にプールを構成します。必要なユーザーをプールに追加します。MFA を要求するようにプールを設定します。ALB のリスナールールを設定して、Amplify ホスト UI を介して認証を要求します。
■ 問題文の要件の概要
要件内容 | 詳細 |
---|---|
アプリケーション構成 | ECS (Fargate)、ALB 経由でトラフィック |
制約条件 | アプリを変更不可・IdPと統合不可 |
アクセス要件 | 特定ユーザーにのみアクセス許可、MFA 必須 |
解決方法 | ALB を介した認証でアプリを変更せず制御したい |
■ 正解の選択肢とその解説
✅ A. Amazon Cognito + ALB の認証アクション
- 解説:
ALB はリスナールールで Amazon Cognito ユーザープールを使った認証 をサポートしており、アプリケーションに手を加えずにアクセス制御を実現可能です。
Cognito ではユーザーごとの MFA 強制設定も可能で、特定ユーザー + MFA 認証 + ALB 経由 の構成が要件に完全一致しています。 - 構成の概要:
- Cognitoユーザープールにユーザー登録
- MFA を必須に設定
- ALB のリスナーに Cognito 認証ルールを適用
■ 不正解の選択肢の理由
❌ B. IAMユーザー + リソースポリシー + ALB
- IAM は AWSリソースのアクセス管理に特化しており、ALB によるウェブアプリ認証のような用途には対応していません。
- リスナールールで IAM による直接的なユーザー認証は不可能です。
❌ C. IAM Identity Center (SSO) + ALB
- IAM Identity Center は AWS CLI や AWS マネジメントコンソールへのアクセス管理には有効ですが、ALB 経由の Web アプリケーションの直接的な認証手段とは連携できません。
❌ D. Amplify + ALB
- Amplify はアプリケーションのホスティングやデプロイには便利ですが、ALB と連携した認証メカニズムを提供していません。
- Amplify を通じて ALB 認証設定を行うことはできません。
■ SAP試験で押さえておくべきポイント
項目 | 内容 |
---|---|
ALB の認証機能 | ALB は OIDC または Cognito を使ったリクエストベースの認証をサポートする |
Cognito の活用 | MFA 強制、ユーザー管理、IdP 連携を UI 変更せずに可能にする |
アプリ変更不可要件 | アプリを改修できない場合、ALB+Cognito など外部制御手段を検討 |
IAM / SSO の限界 | IAM や SSO は ALB の HTTP レイヤーでのアクセス制御には不向き |
次の問題もお待ちしています。引き続き、同様の形式で解説いたします。
以下は、SAP試験・問題4 に関する詳細な整理と解説です。
■ 問題文(文字列を編集せずに出力)
ある企業は、オンプレミスのデータベース群を Amazon RDS に移行する必要があります。同社は現在、Microsoft SQL Server、MySQL、Oracle データベースを混在して使用しています。一部のデータベースには、カスタムスキーマとストアドプロシージャがあります。
移行のために企業が実行する必要がある手順の組み合わせを選択してください。(2 つ選択)
■ 選択肢(文字列を編集せずに出力)
A.
Migration Evaluator Quick Insights を使用してソースデータベースを分析し、移行が必要なストアドプロシージャを特定します。
B.
AWS Application Migration Service を使用してソースデータベースを分析し、移行が必要なストアドプロシージャを特定します。
C.
AWS Schema Conversion Tool (AWS SCT) を使用して、ソースデータベースを分析し、必要な変更を確認します。
D.
AWS Database Migration Service (AWS DMS) を使用して、ソースデータベースを Amazon RDS に移行します。
E.
AWS DataSync を使用して、ソースデータベースから Amazon RDS にデータを移行します。
■ 問題文の要件の概要
要件項目 | 内容 |
---|---|
ソースDB | Microsoft SQL Server、MySQL、Oracle(混在) |
特徴 | カスタムスキーマとストアドプロシージャあり |
移行先 | Amazon RDS |
目的 | 適切な移行ツールと手順の選定(2つ) |
■ 正解の選択肢とその解説
✅ C. AWS Schema Conversion Tool (AWS SCT)
- 理由: SCTは異種データベース間のスキーマやストアドプロシージャを分析・変換するためのツールで、スキーマの互換性分析や変換推奨、非互換なコード(例:ストアドプロシージャ)を特定可能。
- 異なるDBエンジン間(例:Oracle→MySQL)移行時の重要な前処理。
✅ D. AWS Database Migration Service (AWS DMS)
- 理由: SCTで分析・変換されたスキーマをもとに、実際のデータ移行を行うのが DMS。ダウンタイムを抑えた継続的レプリケーションも可能。
- 移行元と移行先の両方でDBが稼働可能な状態を保ったまま移行できる。
■ 不正解の選択肢の理由
❌ A. Migration Evaluator Quick Insights
- これは主に サーバーやリソースのコスト分析・移行可否のアセスメント用ツール であり、ストアドプロシージャの検出やスキーマ変換は対象外。
❌ B. AWS Application Migration Service
- これはEC2やVMなどの**サーバーごと移行(リフト&シフト)**するサービスであり、データベースのスキーマやプロシージャの分析はできない。
❌ E. AWS DataSync
- ファイル転送に特化したサービスであり、データベース移行には非対応。RDSへの直接的なDBデータの移行には使えない。
■ SAP試験で押さえておくべきポイント
トピック | 内容 |
---|---|
SCTの役割 | スキーマの互換性を分析・変換し、移行可能性を確認する。特に異種DB間の移行では必須。 |
DMSの役割 | 実際のデータ移行(レプリケーション含む)を担う。スキーマ変換後の手順。 |
移行プロセスの流れ | ① SCTでスキーマ確認 → ② SCTで変換 → ③ DMSで移行 |
DataSyncやMigration Evaluatorの用途の見極め | ファイル転送用 or 移行評価用であり、DB移行用途ではない。用途を混同しないこと。 |
次の問題も引き続きどうぞ!問題文と選択肢を貼っていただければ、同様の形式で整理・解説いたします。
以下は、SAP試験・問題5 に関する詳細な整理と解説です。
■ 問題文(文字列を編集せずに出力)
ある企業が自社のウェブサイトを AWS に移行したいと考えています。このウェブサイトはマイクロサービスを使用しており、オンプレミスの自己管理型 Kubernetes クラスターにデプロイされたコンテナ上で実行されます。Kubernetes デプロイメント内のコンテナのデプロイメントを定義するマニフェストはすべてソース管理内にあります。
ウェブサイトのデータはすべて PostgreSQL データベースに保存されています。オープンソースのコンテナイメージリポジトリは、オンプレミス環境と並行して実行されます。
ソリューションアーキテクトは、AWS 上のウェブサイトに使用するアーキテクチャを決定する必要があります。
移行に最も労力をかけずに、これらの要件を満たすソリューションを選択してください。
■ 選択肢(文字列を編集せずに出力)
A.
AWS App Runner サービスを作成します。App Runner サービスをオープンソースのコンテナイメージリポジトリに接続します。マニフェストをオンプレミスから App Runner サービスにデプロイします。Amazon RDS for PostgreSQL データベースを作成します。
B.
マネージド型ノードグループを持つ Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを作成します。アプリケーションコンテナを新しい Amazon Elastic Container Registry (Amazon ECR) リポジトリにコピーします。マニフェストをオンプレミスから EKS クラスターにデプロイします。Amazon Aurora PostgreSQL DB クラスターを作成します。
C.
Amazon EC2 キャパシティープールを持つ Amazon Elastic Container Service (Amazon ECS) クラスターを作成します。アプリケーションコンテナを新しい Amazon Elastic Container Registry (Amazon ECR) リポジトリにコピーします。各コンテナイメージを新しいタスク定義として登録します。元の Kubernetes デプロイメントと一致するように、各タスク定義の ECS サービスを設定します。Amazon Aurora PostgreSQL DB クラスターを作成します。
D.
Amazon EC2 インスタンスでクラスターをホスティングして、オンプレミスの Kubernetes クラスターを再構築します。オープンソースのコンテナイメージリポジトリを EC2 インスタンスに移行します。オンプレミスから AWS 上の新しいクラスターにマニフェストをデプロイします。新しいクラスターにオープンソースの PostgreSQL データベースをデプロイします。
■ 問題文の要件の概要
項目 | 内容 |
---|---|
アーキテクチャ | マイクロサービス、オンプレミス Kubernetes 利用中 |
コンテナ管理 | Kubernetes マニフェストで管理 |
データベース | PostgreSQL |
コンテナイメージ | オープンソースのリポジトリ |
要件 | 労力最小で移行、構成の再利用性が高いこと |
■ 正解の選択肢とその解説
✅ B. Amazon EKS + ECR + Aurora PostgreSQL
- 理由:
- EKSはKubernetesと互換性があり、既存のマニフェストをそのまま利用可能。
- Amazon ECRにイメージをコピーして使える。
- Amazon Aurora for PostgreSQLは、スケーラブルかつマネージドなDBで移行に適している。
- 最小限の変更でクラウド移行を実現できるベストプラクティス構成。
■ 不正解の選択肢とその理由
❌ A. AWS App Runner
- App RunnerはKubernetesに非対応。マニフェストを直接デプロイできない。
- コンテナアプリは動かせるが、K8sベースの構成を再構築する手間が大きい。
- 小規模アプリには便利だが、マイクロサービス構成全体の移行には向かない。
❌ C. Amazon ECS
- ECSはKubernetesと互換性がない独自オーケストレーション。
- マニフェストはECSで使えず、タスク定義などを作り直す必要がある。
- ECS移行自体はあり得るが、今回の要件「労力をかけずに」には反する。
❌ D. Amazon EC2でK8s再構築
- EC2上にKubernetesを構築するのは労力が非常に大きい。
- 自己管理のため、EKSやFargateなどのマネージドサービスの利点を活かせない。
- PostgreSQLも自己管理型で、保守負担が増加。
■ SAP試験で押さえておくべきポイント
トピック | 内容 |
---|---|
EKS vs ECS | 既存K8s環境の移行はEKS。K8s互換性なしのECSは代替構成。 |
最小限の移行労力 | 「既存のK8sマニフェストを再利用できるか」が鍵。EKSはここが強み。 |
Aurora vs RDS vs OSS DB | AuroraはPostgreSQL互換で高可用性、RDSよりスケーラブル。自己管理DBより運用コストも低い。 |
App Runnerの用途 | 簡易なWebアプリの構築に適しており、K8s移行には不向き。 |
次の問題も準備できましたら、引き続き送ってください。丁寧に解説していきます!
以下は、SAP試験・問題6 に関する詳細な整理と解説です。
■ 問題文(文字列を編集せずに出力)
ある企業が AWS に新しいアプリケーションをデプロイしています。このアプリケーションは、Amazon Elastic Kubernetes Service (Amazon EKS) クラスターと Amazon Elastic Container Registry (Amazon ECR) リポジトリで構成されています。EKS クラスターには AWS のマネージド型ノードグループがあります。
同社のセキュリティガイドラインでは、AWS のすべてのリソースを継続的にスキャンして、セキュリティの脆弱性を検出する必要があります。
運用上のオーバーヘッドが最も少なく、この要件を満たすソリューションを選択してください。
■ 選択肢(文字列を編集せずに出力)
A.
AWS Security Hub をアクティブにします。EKS ノードと ECR リポジトリをスキャンするように Security Hub を構成します。
B.
Amazon Inspector を有効にして、EKS ノードと ECR リポジトリをスキャンします。
C.
新しい Amazon EC2 インスタンスを起動し、AWS Marketplace から脆弱性スキャンツールをインストールします。EC2 インスタンスを構成して、EKS ノードをスキャンします。Amazon ECR を構成して、プッシュ時に基本スキャンを実行します。
D.
EKS ノードに Amazon CloudWatch エージェントをインストールします。継続的にスキャンするように CloudWatch エージェントを構成します。Amazon ECR を構成して、プッシュ時に基本スキャンを実行します。
■ 問題文の要件の概要
要件項目 | 内容 |
---|---|
対象リソース | EKS ノード、ECR リポジトリ |
セキュリティ要件 | 脆弱性を継続的にスキャン |
優先条件 | 運用負荷を最小限に |
■ 正解の選択肢とその解説
✅ B. Amazon Inspector を有効にして、EKS ノードと ECR リポジトリをスキャンする
- 理由:
- Amazon Inspector は、EKS ノード(EC2ベース)や ECR イメージを対象に、継続的な脆弱性スキャンを自動で実行できるマネージドサービス。
- AWSとの統合が強力で、リソース追加時にも自動検出・スキャン実行。
- 運用負荷は極めて少なく、スキャン結果も Security Hub に連携可能。
- 最も効率的かつ管理コストが低いセキュリティ対策で、問題の要件に完全一致。
■ 不正解の選択肢の理由
❌ A. AWS Security Hub をアクティブにする
- Security Hub はあくまで「結果の集約・可視化」ツール。
- 実際の脆弱性スキャンを行う機能はなく、Inspectorなどからの連携結果を表示するにすぎない。
- スキャン自体はできないため、本質的に要件を満たさない。
❌ C. Marketplace の脆弱性スキャナ + ECR基本スキャン
- 自前でEC2を立てて脆弱性スキャナをセットアップする方式は、構成が複雑で運用負荷が高い。
- ECR のプッシュ時スキャンは継続的スキャンではない(定期的な再スキャン不可)。
- この構成では完全自動化できない上にコストも高い。
❌ D. CloudWatch エージェントを活用する
- CloudWatch は監視ツールであり、脆弱性スキャン機能を持たない。
- ECR の基本スキャンだけでは、マルチノードや継続的スキャンの要件に対応できない。
- CloudWatch をスキャナとして使うのは完全に誤り。
■ SAP試験で押さえておくべきポイント
試験ポイント | 内容 |
---|---|
✅ Amazon Inspector | EKS、ECR、Lambda に対して継続的な脆弱性スキャンが可能。自動でスキャン対象を検出。 |
❌ Security Hub | セキュリティ情報の集約・ダッシュボード表示に特化。スキャンは行わない。 |
❌ EC2 + Marketplace製品 | 柔軟性はあるが、運用負荷と構築手間が大きい。自動化が難しい。 |
❌ CloudWatch | 監視ツール。脆弱性スキャン用途では使用不可。 |
次の問題もご準備いただければ、引き続き分析・解説いたします!
以下は、SAP試験・問題7 に関する詳細な整理と解説です。
■ 問題文(文字列を編集せずに出力)
ある企業が、AWS アカウント内の数千台の Amazon EC2 インスタンスにアプリケーションをデプロイしています。セキュリティ監査により、暗号化されていない Amazon Elastic Block Store (Amazon EBS) ボリュームが EC2 インスタンスにアタッチされていることが判明しました。同社のセキュリティポリシーでは、EBS ボリュームは暗号化されている必要があります。
同社は、EBS ボリュームを暗号化する自動化ソリューションを導入する必要があります。また、開発チームが暗号化されていない EBS ボリュームを作成できないようにする必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢(文字列を編集せずに出力)
A.
暗号化されていない EBS ボリュームを識別する AWS Config マネージドルールを設定します。自動修復アクションを設定します。新しい暗号化された EBS ボリュームを作成する手順を含む AWS Systems Manager オートメーションランブックを関連付けます。AWS Key Management Service (AWS KMS) のカスタマーマネージドキーを作成します。キーポリシーに、暗号化されていない EBS ボリュームの作成を拒否するステートメントを含めます。
B.
AWS Systems Manager Fleet Manager を使用して、暗号化されていない EBS ボリュームのリストを作成します。新しい暗号化された EBS ボリュームを作成する手順を含む Systems Manager オートメーションランブックを作成します。暗号化されていない EBS ボリュームの作成を拒否する SCP を作成します。
C.
AWS Systems Manager Fleet Manager を使用して、暗号化されていない EBS ボリュームのリストを作成します。新しい暗号化された EBS ボリュームを作成する手順を含む Systems Manager オートメーションランブックを作成します。新しい EBS ボリュームを常に暗号化するように、EBS 暗号化の AWS アカウント設定を変更します。
D.
暗号化されていない EBS ボリュームを識別する AWS Config マネージドルールを設定します。自動修復アクションを設定します。新しい暗号化された EBS ボリュームを作成する手順を含む AWS Systems Manager オートメーションランブックを関連付けます。新しい EBS ボリュームを常に暗号化するように、EBS 暗号化の AWS アカウント設定を変更します。
■ 問題文の要件の概要
要件 | 内容 |
---|---|
✅ 既存の未暗号化 EBS ボリュームを検出・修復したい | |
✅ 開発者が新規に未暗号化ボリュームを作れないようにしたい | |
✅ 自動化されたソリューションで実施したい |
■ 正解の選択肢と解説
✅ D. AWS Config + 自動修復 + アカウント暗号化設定の変更
- 理由:
- AWS Config のマネージドルールを使って未暗号化の EBS ボリュームを検出。
- Systems Manager オートメーションランブックで検出後に暗号化された新しいボリュームへ移行。
- EBS アカウント暗号化設定を有効にすることで、今後作成される EBS ボリュームは常に暗号化される。
- ⇒ 過去と未来両方のリスクを自動的にカバーできる構成。
■ 不正解の選択肢の理由
❌ A. KMS キーポリシーで制限
- 誤りのポイント:
- KMS のキーポリシーでは「特定のキーの利用を制限」することはできるが、EBS の未暗号化作成自体を拒否することはできない。
- 暗号化されていないボリュームの作成を防ぐには、アカウントレベルで暗号化を強制する必要がある。
❌ B. Fleet Manager + SCP
- 誤りのポイント:
- Fleet Manager はリスト化には使えるが、自動修復の機構が不足。
- SCP(Service Control Policy)で「未暗号化EBSの作成を拒否」する制御は困難かつ対象が曖昧(暗号化のパラメータまで検出できない)。
❌ C. アカウント設定のみで暗号化
- 誤りのポイント:
- 今後の作成は暗号化されるが、既存の暗号化されていないボリュームは放置される。
- 自動修復機能が欠けており、既存リスクへの対応が不十分。
■ SAP試験で押さえておくべきポイント
試験ポイント | 内容 |
---|---|
✅ AWS Config | ポリシー準拠違反の検出、自動修復アクション(SSMと連携)に活用。 |
✅ SSM オートメーション | 修復・再構成などの自動実行に活用される。 |
✅ EBS アカウント設定 | 新規作成ボリュームを強制的に暗号化できる。 |
❌ KMSポリシーでは暗号化必須制御は不可 | |
❌ SCPではリソースプロパティ(暗号化有無)の精密制御は困難 |
次の問題も準備でき次第、同様の形式で解説いたします。SAP試験の合格をしっかりサポートします!