Q1. ある金融企業が、AWS Organizations で管理されている AWS アカウントへ銀行業務アプリケーションを移行しています。
これらのアプリケーションは、機密性の高い顧客データを Amazon EBS ボリュームに保存しており、企業はバックアップとして定期的にスナップショットを取得しています。
企業は、EBS スナップショットが公開共有されるのを防ぐための制御を、すべてのアカウントに対して運用上の負担を最小限に抑えて実装する必要があります。
これらの要件を満たすソリューションはどれですか。
A. AWS Config ルールを各 OU に対して有効化し、EBS スナップショットのアクセス許可を監視する。
B. 組織レベルで EBS スナップショットのパブリックアクセスブロックを有効化する。
C. ルートアカウントで、ユーザーによるスナップショットのアクセス許可の変更を禁止する IAM ポリシーを作成する。
D. AWS CloudTrail を使用して、スナップショットのアクセス許可の変更を追跡する。
回答
- B
-
正解は B です。
AWS Organizations には EBS スナップショットのパブリックアクセスブロック（Block Public Access）という機能があり、組織レベルで有効化すると、すべてのメンバーアカウントのスナップショットが公開共有されるのを一括で防止できます。
これは中央集約的に適用される組織全体の制御であり、アカウントごとの設定や監視ルールが不要なため、運用負担が最も小さくなります。
パブリック共有を確実に「防止」するには、事後検知ではなくブロック機能を選ぶことが重要です。
AWS Config（A）は問題発生後の検知にとどまり、IAM ポリシー（C）は変更経路が複数あり回避されうるため不十分です。
CloudTrail（D）は記録のみで共有自体は防げません。
Amazon EBS スナップショットのブロックパブリックアクセス – AWS ドキュメント
Q2. ある企業が、Amazon RDS データベースをバックエンドとする Amazon EC2 上で、機密性の高いアプリケーションを実行しています。
コンプライアンス規制により、すべての個人を特定できる情報（PII）を保存時に暗号化することが義務付けられています。
インフラストラクチャへの変更を最小限に抑えてこの要件を満たすために、ソリューションアーキテクトが推奨すべきソリューションはどれですか。
A. AWS Key Management Service（AWS KMS）キーを用いて Amazon Elastic Block Store（Amazon EBS）暗号化と Amazon RDS 暗号化を設定し、インスタンスとデータベースのボリュームを暗号化する。
B. AWS CloudHSM をデプロイして暗号化キーを生成し、そのキーを使用してデータベースのボリュームを暗号化する。
C. AWS Key Management Service（AWS KMS）キーを使用して SSL 暗号化を設定し、データベースのボリュームを暗号化する。
D. AWS Certificate Manager をデプロイして証明書を生成し、その証明書を使用してデータベースのボリュームを暗号化する。
回答
- A
-
正解は A です。
保存時の暗号化（encryption at rest）を最小限の変更で実現するには、Amazon EBS と Amazon RDS の暗号化機能を AWS KMS キーと組み合わせて有効化するのが最適です。
EBS と RDS のネイティブ暗号化は、アプリケーションのコードやアーキテクチャを変更せずに保存データを暗号化できます。
これによりインスタンスストレージとデータベースボリュームの両方の PII を保護できます。
CloudHSM（B）は専用ハードウェアの管理が必要で運用負担が増えます。
SSL（C）は転送時の暗号化であり、保存時暗号化の要件を満たしません。
ACM の証明書（D）はボリューム暗号化の用途には適しません。
Amazon EBS 暗号化 – AWS ドキュメント
Q3. ソリューションアーキテクトが、ある企業向けにマルチリージョンの災害対策（DR）戦略を設計しています。
この企業は、Application Load Balancer（ALB）の背後にある Auto Scaling グループ内の Amazon EC2 インスタンスでアプリケーションを実行しています。
企業はこのアプリケーションを、プライマリとセカンダリの AWS リージョンでホストしています。
プライマリリージョンに障害が発生した場合、アプリケーションはセカンダリリージョンからの DNS クエリに応答する必要があります。
同時にトラフィックを処理するリージョンは 1 つだけでなければなりません。
これらの要件を満たすソリューションはどれですか。
A. Amazon Route 53 Resolver でアウトバウンドエンドポイントを作成する。
クエリをネットワーク上の DNS リゾルバーへどのように転送するかを決定する転送ルールを作成する。
そのルールを各リージョンの VPC に関連付ける。
B. Amazon Route 53 でプライマリとセカンダリの DNS レコードを作成する。
ヘルスチェックとフェイルオーバールーティングポリシーを設定する。
C. Amazon Route 53 でトラフィックポリシーを作成する。
地理的位置（geolocation）ルーティングポリシーと、値のタイプとして ELB Application Load Balancer を使用する。
D. Amazon Route 53 プロファイルを作成する。
DNS リソースをプロファイルに関連付ける。
そのプロファイルを各リージョンの VPC に関連付ける。
回答
- B
-
正解は B です。
プライマリリージョン障害時のみセカンダリへ切り替え、常に 1 リージョンだけがトラフィックを処理するという要件には、Amazon Route 53 のフェイルオーバールーティングポリシーとヘルスチェックの組み合わせが最適です。
フェイルオーバールーティングは、ヘルスチェックが正常な間はプライマリのみに応答し、異常を検知するとセカンダリへ自動的に切り替えます。
これによりアクティブ・パッシブ構成が実現します。
Resolver のアウトバウンドエンドポイント（A）はオンプレミスへの DNS 転送用途です。
geolocation（C）は送信元の地域でトラフィックを振り分ける方式で、障害時フェイルオーバーには適しません。
Route 53 プロファイル（D）は VPC 間で DNS 設定を共有する機能で用途が異なります。
フェイルオーバールーティング – Amazon Route 53
Q4. ある企業が、Amazon RDS for MySQL を使用して重要なアプリケーションをデプロイしています。
このアプリケーションは高可用性を備え、自動的に復旧できなければなりません。
企業は、対話型ユーザー（トランザクションクエリ）とバッチレポート（分析クエリ）を、4 時間以内の遅延でサポートする必要があります。
分析クエリがトランザクションクエリのパフォーマンスに影響を与えてはなりません。
A. Amazon RDS for MySQL を、1 台のスタンバイインスタンスを持つマルチ AZ DB インスタンス構成で設定する。
トランザクションクエリをプライマリ DB インスタンスに向ける。
分析クエリを、別のアベイラビリティーゾーンで実行されるセカンダリ DB インスタンスに向ける。
B. Amazon RDS for MySQL を、自動バックアップを有効にしてトランザクションクエリ用のプライマリデータベースとして設定する。
自動バックアップを設定する。
毎晩、最新のスナップショットから読み取り専用のデータベースを作成して分析クエリをサポートする。
以前に作成したデータベースは削除する。
C. Amazon RDS for MySQL を、複数のアベイラビリティーゾーンにまたがる複数のリードレプリカを使用するように設定する。
トランザクションクエリをプライマリ DB インスタンスに向ける。
分析クエリを、別のアベイラビリティーゾーンにあるレプリカの 1 つに向ける。
D. Amazon RDS for MySQL を、2 台のスタンバイインスタンスを持つマルチ AZ DB クラスター構成で設定する。
トランザクションクエリをプライマリ DB インスタンスに向ける。
分析クエリをリーダーエンドポイントに向ける。
回答
- D
-
正解は D です。
高可用性と自動復旧に加え、分析クエリをトランザクション処理から隔離しつつ 4 時間以内の遅延で参照する要件には、マルチ AZ DB クラスター構成が最適です。
マルチ AZ DB クラスターは 2 台の読み取り可能なスタンバイを持ち、プライマリ障害時には自動的にフェイルオーバーします。
リーダーエンドポイントを使えば、分析クエリを読み取り可能なスタンバイへ振り向けられ、プライマリのトランザクション性能に影響を与えません。
マルチ AZ DB インスタンス（A）のスタンバイは読み取りに使用できないため、分析クエリを向けられません。
リードレプリカ（C）は読み取り分離はできますが、非同期のため単体では自動フェイルオーバーによる高可用性・自動復旧を保証できません。
スナップショットから毎晩再作成する方式（B）は運用が煩雑で遅延も大きくなります。
マルチ AZ DB クラスターの使用 – Amazon RDS
Q5. ある企業が、機密性の高い医療結果を Amazon S3 バケットに保存する必要があります。
このリポジトリでは、少数の承認されたユーザーだけが新しいファイルを追加できるようにする必要があります。
リポジトリは、それ以外のすべてのユーザーを、Write Once Read Many（WORM、一度書き込めば何度でも読み取れる）方式によって読み取り専用アクセスに制限しなければなりません。
企業は、リポジトリ内のすべてのファイルを作成日から最低 1 年間保持する必要があります。
これらの要件を、実装の手間を最小限に抑えて満たすソリューションはどれですか。
A. S3 バケットに多要素認証（MFA）削除を設定する。
削除を防ぐため、MFA のシークレットをユーザーと共有しない。
B. S3 Object Lock をコンプライアンスモードで、保持期間を 1 年に設定して使用する。
指定した承認済みユーザーにファイルアクセスを制限する IAM ポリシーを使用する。
C. IAM ロールを使用して、すべてのユーザーが S3 バケット内のオブジェクトを削除または変更できないように制限する。
その IAM ロールのみを許可する S3 バケットポリシーを使用する。
D. オブジェクトが追加されるたびに AWS Lambda 関数を呼び出すよう S3 バケットを設定する。
保存されたオブジェクトのハッシュを追跡し、変更されたオブジェクトに印を付けられるよう関数を設定する。
回答
- B
-
正解は B です。
WORM（Write Once Read Many）と最低 1 年の保持という要件には、Amazon S3 Object Lock のコンプライアンスモードが最適です。
コンプライアンスモードでは、ルートユーザーや管理者を含む誰も、保持期間中はオブジェクトを削除・上書きできません。
これにより医療記録のような規制対象データに必要な不変性が保証されます。
承認ユーザーによるアップロード制御は IAM ポリシーで実現できます。
MFA 削除（A）は誤削除防止にとどまり、WORM の上書き防止を保証しません。
IAM／バケットポリシー（C）は管理者が変更でき、不変性を担保できません。
Lambda によるハッシュ追跡（D）は変更を事後検知するだけで防止にならず、実装も複雑です。
S3 オブジェクトロックの使用 – Amazon S3
Q6. あるオンラインゲーム企業が、複数の AWS リージョンにわたって Network Load Balancer（NLB）の背後にある Amazon EC2 インスタンス上でプラットフォームをホストしています。
これらの NLB は、インターネット経由でターゲットにリクエストをルーティングできます。
企業は、グローバルな顧客基盤に対してエンドツーエンドのロード時間を短縮することで、顧客のプレイ体験を向上させたいと考えています。
これらの要件を満たすソリューションはどれですか。
A. 各リージョンで Application Load Balancer（ALB）を作成し、既存の NLB を置き換える。
既存の EC2 インスタンスを各リージョンの ALB のターゲットとして登録する。
B. 各リージョンの NLB に均等な重み付けでトラフィックをルーティングするよう Amazon Route 53 を設定する。
C. 顧客基盤の大きい他のリージョンに、追加の NLB と EC2 インスタンスを作成する。
D. AWS Global Accelerator で標準アクセラレーターを作成する。
既存の NLB をターゲットエンドポイントとして設定する。
回答
- D
-
正解は D です。
グローバルな利用者のエンドツーエンドの遅延を削減するには、AWS Global Accelerator が最適です。
Global Accelerator は最寄りの AWS エッジロケーションからトラフィックを AWS のグローバルネットワーク経由で転送し、公衆インターネットよりホップ数と遅延を削減します。
既存の NLB をエンドポイントに設定するだけでよく、構成変更も最小限です。
ALB への置き換え（A）はレイヤー 7 機能を追加しますが、遅延問題は解決しません。
Route 53 の均等重み付け（B）はトラフィックを分散するだけでネットワーク性能を最適化しません。
リージョン追加（C）は遅延を改善しうるものの、インフラ構築の手間とコストが大きくなります。
AWS Global Accelerator とは – AWS ドキュメント
Q7. ある企業が、ビジネスにとって重要なアプリケーションを AWS クラウドにデプロイする予定です。
このアプリケーションには、一貫した低レイテンシー性能を備えた耐久性の高いストレージが必要です。
これらの要件を満たすために、ソリューションアーキテクトが推奨すべきストレージの種類はどれですか。
A. インスタンスストアボリューム
B. Amazon ElastiCache（Memcached）クラスター
C. プロビジョンド IOPS SSD の Amazon Elastic Block Store（Amazon EBS）ボリューム
D. スループット最適化 HDD の Amazon Elastic Block Store（Amazon EBS）ボリューム
回答
- C
-
正解は C です。
プロビジョンド IOPS SSD（io1／io2）ボリュームは、予測可能で一貫した低レイテンシーの高性能を提供し、データベースなど I/O 集約型の重要ワークロードに最適です。
EBS ボリュームは耐久性が高く、インスタンスを停止してもデータが失われないため、ビジネスクリティカルな用途に向いています。
インスタンスストア（A）は一時的なストレージで、インスタンス停止時にデータが消えるため耐久性要件を満たしません。
ElastiCache（B）はキャッシュ用途で永続ストレージではありません。
スループット最適化 HDD（D）は大容量のシーケンシャル処理向けで、低レイテンシーのランダム I/O には適しません。
Amazon EBS ボリュームの種類 – AWS ドキュメント
Q8. ある企業が、10 万台のデバイスからのストリーミングセンサーデータを取り込み、ほぼリアルタイムでデータを変換し、分析用に Amazon S3 へロードするソリューションを必要としています。
このソリューションは、フルマネージドかつスケーラブルで、サブ秒の取り込みレイテンシーを維持する必要があります。
A. Amazon Kinesis Data Streams を使用してデータを取り込む。
Amazon Managed Service for Apache Flink を使用して、データをほぼリアルタイムで処理する。
Amazon Data Firehose ストリームを使用して、処理済みデータを Amazon S3 に送信する。
B. Amazon Simple Queue Service（Amazon SQS）の標準キューを使用してセンサーデータを収集する。
AWS Lambda 関数を呼び出して、SQS メッセージをバッチで変換・処理する。
AWS SDK を使用して変換済みデータを Amazon S3 に書き込むよう Lambda 関数を設定する。
C. Apache Kafka を実行する Amazon EC2 インスタンス群をデプロイしてデータを取り込む。
Amazon EMR クラスター上で Apache Spark を実行してデータを処理する。
処理済みデータを直接 Amazon S3 に書き込むよう Spark を設定する。
D. Amazon EventBridge を実装してすべてのセンサーデータをキャプチャする。
AWS Batch を使用して、コンテナ化された変換ジョブをスケジュールに従って実行する。
データをチャンク単位で処理するよう AWS Batch ジョブを設定する。
結果を Amazon S3 に保存する。
回答
- A
-
正解は A です。
Kinesis Data Streams はサブ秒のレイテンシーで大量ストリームを取り込み、Managed Service for Apache Flink がほぼリアルタイムで変換し、Data Firehose が S3 へ確実に配信します。
これらはすべてサーバーレスのフルマネージドサービスで、10 万台規模でも自動的にスケールします。
SQS + Lambda（B）は大量のリアルタイムストリーミングには最適化されていません。
EC2 + Kafka + EMR（C）は運用負担とコストが大きくなります。
EventBridge + AWS Batch（D）はイベント駆動・バッチ処理向けで、サブ秒のストリーミングには適しません。
Amazon Kinesis Data Streams とは – AWS ドキュメント
Q9. あるメディア企業が、動画をアップロードするための Web アプリケーションを AWS 上でホストしています。
認証済みのユーザーだけが、認証後の指定された時間枠内でアップロードできるようにする必要があります。
これらの要件を、運用上の負担を最小限に抑えて満たすソリューションはどれですか。
A. 認証済みユーザー向けに IAM の一時的セキュリティ認証情報を生成するようアプリケーションを設定する。
B. ユーザーが認証したときに事前署名付き URL（pre-signed URL）を生成する AWS Lambda 関数を作成する。
C. Amazon Cognito と統合してアプリケーション経由の S3 バケットへの直接アクセスを制御・記録する、カスタム認証サービスを開発する。
D. AWS Security Token Service（AWS STS）を使用して、認証済みユーザーに S3 バケットへ動画を直接アップロードする一時的な権限を付与する、事前定義済みの IAM ロールを引き受ける。
回答
- B
-
正解は B です。
事前署名付き URL は、有効期限を指定して S3 への一時的で認証済みのアップロードアクセスを付与でき、認証後の時間枠制限をそのまま実現できます。
Lambda で URL を生成する方式は軽量で実装が容易なため、運用負担が最も小さくなります。
IAM の一時的認証情報（A）は認証情報の管理が必要で複雑さが増します。
Cognito 連携のカスタム認証サービス（C）は不要な開発工数がかかります。
STS でロールを引き受ける方式（D）は、事前署名付き URL に比べて STS とロールの管理が加わり複雑になります。
事前署名付き URL を使用したオブジェクトのアップロード – Amazon S3
Q10. ある企業が、Amazon EC2 インスタンス群で本番アプリケーションを実行しています。
このアプリケーションは、Amazon Simple Queue Service（Amazon SQS）キューからメッセージを読み取り、並列で処理します。
メッセージ量は予測不可能で変動が非常に大きくなっています。
企業は、ダウンタイムなしでアプリケーションが継続的にメッセージを処理できるようにする必要があります。
これらの要件を最もコスト効率よく満たすソリューションはどれですか。
A. 必要な最大キャパシティを処理するために、スポットインスタンスのみを使用する。
B. 必要な最大キャパシティを処理するために、リザーブドインスタンスのみを使用する。
C. ベースラインのキャパシティを処理するためにリザーブドインスタンスを使用する。
必要に応じて追加キャパシティを提供するためにスポットインスタンスを使用する。
D. 最小キャパシティを処理するために、EC2 Auto Scaling グループでリザーブドインスタンスを使用する。
SQS キューのバックログに基づく Auto Scaling ポリシーを設定する。
回答
- C
-
正解は C です。
AWS のベストプラクティスは、安定したベースラインをリザーブドインスタンスや Savings Plans でカバーし、変動するバースト分を割安なスポットインスタンスで補うことです。
スポットインスタンスは最大 90% 割引で、中断されてもメッセージは SQS に保持されたまま別インスタンスで再処理できるため、キュー処理のようなフォールトトレラントなワークロードに適しています。
スポットのみ（A）はキャパシティ不足のリスクがあり、リザーブドのみ（B）は低負荷時にコストが無駄になります。
D はバックログに応じてスケールしますが、バーストにオンデマンドを使う想定でスポットより割高です。
ベースラインを RI で継続処理しつつスポットで安価に増強する C が最適です。
インスタンス購入オプション – Amazon EC2