質問#21 ある e コマース企業が、AWS 上で 1 日 1 回のセールサイトを立ち上げようとしている。1 日に 1 つの商品を 24 時間販売する。同社は、ピーク時にミリ秒のレイテンシで毎時数百万のリクエストを処理できるようにしたいと考えている。最も少ない運用オーバーヘッドでこれらの要件を満たすソリューションはどれか？
A.Amazon S3 を使用して、完全なウェブサイトを異なる S3 バケットにホストする。Amazon CloudFront ディストリビューションを追加する。S3 バケットをディストリビューションのオリジンとして設定する。注文データを Amazon S3 に保存する。
B.複数のアベイラビリティゾーンにまたがる Auto Scaling グループで実行される Amazon EC2 インスタンスに、フルウェブサイトをデプロイする。アプリケーションロードバランサー(ALB)を追加して、ウェブサイトの trac を配布する。バックエンド API用に別の ALB を追加する。Amazon RDS for MySQL にデータを保存する。
C.アプリケーション全体をコンテナで実行するように移行する。Amazon Elastic Kubernetes Service（Amazon EKS）でコンテナをホストする。Kubernetes Cluster Autoscaler を使ってポッド数を増減させ、trac のバースト処理を行う。Amazon RDS for MySQL にデータを保存する。
D.Amazon S3 バケットを使ってウェブサイトの静的コンテンツをホストする。Amazon CloudFront ディストリビューションをデプロイする。S3 バケットをオリジンに設定する。バックエンド API に Amazon API Gateway と AWS Lambda 関数を使用する。Amazon DynamoDB にデータを保存する。

正解：D
理由： 24時間の短期集中で「毎時数百万リクエスト＋ミリ秒レイテンシ＋運用最小」を狙うなら、

• 静的：S3 + CloudFront（超スケール、低レイテンシ、運用ほぼ無し）

• 動的API：API Gateway + Lambda（サーバ運用不要で自動スケール）

• 注文/在庫/状態：DynamoDB（高スループット/低レイテンシでスケールが簡単）
  の組み合わせが鉄板です。

他がダメな理由：

• A：注文データをS3保存は不向き（更新/検索/整合性の要件に弱い）。

• B：EC2+ALB+RDSは運用負荷が高い。

• C：EKSは運用オーバーヘッドが増える（要件に対して過剰）。

問題#22 あるソリューションアーキテクトは、新しいデジタルメディアアプリケーションのストレージアーキテクチャを設計するために Amazon S3 を使用している。メディアレスは、アベイラビリティゾーンの損失に対して弾力的でなければならない。あるメディアは頻繁にアクセスされ、他のメディアは予測不可能なパターンでほとんどアクセスされない。ソリューション・アーキテクトは、メディア・レスの保存と検索のコストを最小限に抑えなければならない。これらの要件を満たすストレージオプションはどれか。
A.S3 スタンダード
B.S3 インテリジェントティアリング
C.S3 スタンダード-フリークエントアクセス（S3 Standard-IA）
D.S3 One Zone-Infrequent Access（S3 One Zone-IA）

正解：B（S3 Intelligent-Tiering）
理由： アクセスが「頻繁なもの」と「予測不能でほぼアクセスされないもの」が混在 → 自動で最適階層に移す Intelligent-Tiering がコスト最小化に効きます。
またS3はマルチAZで、AZ損失耐性も満たします。

他がダメな理由：

• A：常に高コスト寄り（頻繁アクセス以外が無駄）。

• C：アクセス頻度が予測不能だと最適化しづらい。

• D：One ZoneはAZ損失耐性を満たせない。

質問#23 ある企業が、Amazon S3 Standard ストレージを使用してバックアップを保存している。1 ヶ月間は頻繁にアクセスされる。しかし、1 ヶ月を過ぎるとアクセスされなくなる。しかし、1 ヶ月後にはアクセスされなくなる。これらの要件を最もコスト効率よく満たすストレージソリューションはどれか。
A.オブジェクトを自動的に移行するために、S3 Intelligent-Tiering を設定する。
B.S3 Lifecycle コンギュレーションを作成し、1 ヶ月後にオブジェクトを S3 Standard から S3 Glacier Deep Archive に移行する。
C.1 ヶ月後にオブジェクトを S3 Standard から S3 Standard-Infrequent Access (S3 Standard-IA)に移行する S3 ライフサイクル構成を作成する。
D.1 ヶ月後にオブジェクトを S3 Standard から S3 One Zone-Infrequent Access (S3 One Zone-IA)に移行するために S3 ライフサイクル構成を作成する。

正解：B
理由： 「1か月は頻繁アクセス、その後はアクセスされない」＝ライフサイクルで
S3 Standard →（1か月後）S3 Glacier Deep Archive が最安に寄せられます。

他がダメな理由：

• A：Intelligent-Tieringは“ほぼゼロアクセス”なら移るが、監視コスト等もあり、要件が明確ならライフサイクル直指定が強い。

• C：Standard-IAは“たまに取り出す”向けで、以降アクセスしないなら割高。

• D：One Zone-IAは耐久設計が落ちる（バックアップ用途で避けがち）。

質問#24 ある企業が、直近の請求書で Amazon EC2 のコストが増加していることを確認した。請求チームは、いくつかの EC2 インスタンスについて、インスタンスタイプの不要な垂直スケーリングに気づいている。ソリューションアーキテクトは、過去 2カ月の EC2 コストを比較するグラフを作成し、詳細な分析を行って垂直スケーリングの根本原因を特定する必要がある。ソリューションアーキテクトは、運用上のオーバーヘッドを最小限に抑えながら、どのように情報を作成すべきか。
A.AWS バジェットを使用して予算レポートを作成し、インスタンスタイプに基づいて EC2 コストを比較する。
B.コストエクスプローラーの詳細なレタリング機能を使用して、インスタンスタイプに基づいて EC2 コストを詳細に分析する。
C.AWS Billing and Cost Management ダッシュボードのグラフを使用して、過去 2 ヶ月間のインスタンスタイプに基づく EC2 コストを比較する。
D.AWS Cost and Usage Reports を使用してレポートを作成し、Amazon S3 バケットに送信する。Amazon S3 をソースとして Amazon QuickSight を使用して、インスタンスタイプに基づいてインタラクティブなグラフを生成する。

正解：B
理由： 過去2か月のEC2コストをインスタンスタイプで集計・比較し、深掘り分析するなら Cost Explorer が最小運用で最適です（フィルタ/グルーピングが強い）。

他がダメな理由：

• A：Budgetsは主に予算監視・アラート用途。深掘り分析向きではない。

• C：Billingダッシュボードのグラフは分析粒度が弱い。

• D：CUR→S3→QuickSightは強力だが、運用オーバーヘッドが増える。

質問#25 ある企業がアプリケーションを設計している。このアプリケーションは、Amazon API Gateway を通じて情報を受け取り、Amazon Aurora PostgreSQL データベースに情報を格納するために、AWS Lambda 関数を使用している。概念実証の段階で、同社はデータベースにロードする必要がある大量のデータを処理するために、Lambda のクォータを大幅に増やさなければならない。ソリューションアーキテクトは、スケーラビリティを向上させ、構築の手間を最小限に抑えるための新しい設計を提案しなければならない。これらの要件を満たすソリューションはどれか。
A.Lambda 関数のコードを、Amazon EC2 インスタンス上で動作する Apache Tomcat のコードにリファクタリングする。ネイティブの Java Database Connectivity（JDBC）ドライバーを使ってデータベースに接続する。
B.プラットフォームを Aurora から Amazon DynamoDProvision a DynamoDB Accelerator (DAX) cluster に変更する。DAX クライアント SDK を使用して、既存の DynamoDB API コールを DAX クラスターに向ける。
C.2 つの Lambda 関数をセットアップする。1 つの関数は情報を受け取るように構成する。もう 1 つの関数は、情報をデータベースにロードするように設定する。Amazon Simple Notication Service（Amazon SNS）を使用して、Lambda 関数を統合する。
D.2 つの Lambda 関数をセットアップする。1 つの関数は情報を受信する。もう 1 つの関数は、情報をデータベースにロードする。Amazon Simple Queue Service（Amazon SQS）キューを使用して、Lambda 関数を統合する。

正解：D
理由： 大量データでLambda同時実行（クォータ）を無理やり上げるより、
SQSで受信とDBロードを疎結合化してバッファリングし、コンシューマ側Lambdaの並列度を制御するのが、スケーラビリティと手間のバランスが良いです（リトライ/可視性タイムアウトなども強い）。

他がダメな理由：

• A：EC2/Tomcat化は運用増。

• B：Aurora→DynamoDB+DAXはDB要件が変わりすぎ（目的とズレ）。

• C：SNSはpub/subであり、キュー的な滞留・ワーカー制御にSQSほど向かない。

問題#26 ある企業は、Amazon S3 バケットに不正な構成変更がないことを確認するために、AWS クラウドのデプロイメントを見直す必要がある。この目標を達成するために、ソリューションアーキテクトは何をすべきか。
A.適切なルールで AWS Cong をオンにする。
B.適切なチェックで AWS Trusted Advisor をオンにする。
C.適切な評価テンプレートで Amazon Inspector をオンにする。
D.Amazon S3 サーバーのアクセスロギングをオンにする。Amazon EventBridge（Amazon Cloud Watch Events）を設定する。

正解：A
理由： 「S3バケットに不正な構成変更がないことを確認」＝AWS Configで設定変更を記録し、ルールで評価するのが正攻法です。

他がダメな理由：

• B：Trusted Advisorはベストプラクティス助言が中心で、構成変更監査の主役ではない。

• C：Inspectorは脆弱性評価。

• D：アクセスログは“アクセス”監査であって“設定変更”監査ではない（変更追跡はCloudTrail/Config側）。

質問#27 ある企業が新しいアプリケーションを立ち上げ、Amazon CloudWatch ダッシュボードにアプリケーションのメトリクスを表示しようとしている。会社のプロダクトマネージャーは定期的にこのダッシュボードにアクセスする必要がある。プロダクトマネージャーは AWS アカウントを持っていない。ソリューションアーキテクトは、最小特権の原則に従ってプロダクトマネージャにアクセスを提供しなければならない。これらの要件を満たすソリューションはどれか。
A.CloudWatch コンソールからダッシュボードを共有する。プロダクトマネージャーのメールアドレスを入力し、共有ステップを完了する。ダッシュボードの共有可能なリンクをプロダクトマネージャに提供する。
B.プロダクトマネージャー専用の IAM ユーザーを作成する。そのユーザーに CloudWatchReadOnlyAccess AWS マネージドポリシーをアタッチする。新しいログイン認証情報をプロダクトマネージャと共有する。正しいダッシュボードのブラウザ URL をプロダクトマネージャと共有する。
C.会社の従業員用の IAM ユーザーを作成する。ViewOnlyAccess AWS 管理ポリシーを IAM ユーザーにアタッチする。新しいログイン認証情報をプロダクトマネージャと共有する。プロダクトマネージャに、CloudWatch コンソールにナビゲートし、Dashboards セクションでダッシュボードの名前を探すように依頼する。
D.パブリックサブネットに Bastion サーバーをデプロイする。プロダクト・マネージャがダッシュボードへのアクセスを要求したら、サーバを起動し、RDP 認証情報を共有する。bastion サーバーで、ダッシュボードを表示する適切な権限を持つキャッシュされた AWS 資格情報を使用して、ダッシュボードの URL を開くようにブラウザが構成されていることを確認する。
正解 A

正解：A
理由： PMがAWSアカウントを持っていない前提なら、CloudWatchダッシュボードの共有リンクで閲覧だけさせるのが最小権限・最小手間です。

他がダメな理由：

• B/C：IAMユーザー発行＝AWSアカウント前提の運用が増える。最小権限にも反しやすい。

• D：踏み台で見るのは論外級に面倒＆リスク増。

質問#28 ある企業がアプリケーションを AWS に移行している。アプリケーションは異なるアカウントにデプロイされている。同社は AWS Organizations を使用してアカウントを一元管理している。会社のセキュリティチームは、会社のすべてのアカウントにわたるシングルサインオン（SSO）ソリューションを必要としている。オンプレミスで自己管理している Microsoft Active Directory のユーザーとグループの管理を継続する必要がある。これらの要件を満たすソリューションはどれか。
A.AWS SSO コンソールから AWS シングルサインオン（AWS SSO）を有効にする。AWS Directory Service for Microsoft Active Directory を使用して、会社の自己管理 Microsoft Active Directory と AWS SSO を接続するために、一方通行のフォレスト信頼または一方通行のドメイン信頼を作成する。
B.AWS SSO コンソールから AWS シングルサインオン（AWS SSO）を有効にする。AWS Directory Service for Microsoft Active Directory を使用して、自社で管理する Microsoft Active Directory と AWS SSO を接続するための双方向フォレストトラストを作成する。
C.AWS Directory Service を使用する。自社で管理する Microsoft Active Directory と双方向の信頼関係を作成する。
D.構内に ID プロバイダー（IdP）を導入する。AWS SSO コンソールから AWS シングルサインオン（AWS SSO）を有効にする。

正解：A
理由： 全アカウント横断SSOは AWS SSO（= IAM Identity Center） が素直。
さらに「オンプレ自己管理Microsoft ADのユーザー/グループ管理を継続」するなら、AWS Directory Service for Microsoft AD +（一方向）信頼で連携して既存ADを活かす構成が定番です。

他がダメな理由：

• B：双方向トラストは要件的に過剰になりがち。

• C：Directory Serviceだけでは“全アカウント横断SSO”要件を満たしにくい。

• D：オンプレIdP導入は可能性はあるが、設計/運用が増えやすい（最短回答としてはAが自然）。

質問#29 ある企業が、UDP 接続を使用する VoIP（Voice over Internet Protocol）サービスを提供している。このサービスは、Auto Scaling グループで実行される Amazon EC2 インスタンスで構成されている。同社は複数の AWS リージョンにデプロイしている。最もレイテンシーの低いリージョンにユーザーをルーティングする必要がある。また、リージョン間の自動フェイルオーバーも必要だ。これらの要件を満たすソリューションはどれか。
A.ネットワークロードバランサー（NLB）と関連するターゲットグループをデプロイする。ターゲットグループを Auto Scaling
グループに関連付ける。NLB を各リージョンの AWS Global Accelerator エンドポイントとして使用する。
B.アプリケーションロードバランサー（ALB）と関連するターゲットグループをデプロイする。ターゲットグループを Auto Scaling グループに関連付ける。ALB を各リージョンの AWS Global Accelerator エンドポイントとして使用する。
C.ネットワークロードバランサー（NLB）と関連するターゲットグループをデプロイする。ターゲットグループを Auto Scaling グループに関連付ける。各 NLB のエイリアスを指す Amazon Route 53 のレイテンシーレコードを作成する。レイテンシーレコードをオリジンとして使用する Amazon CloudFront ディストリビューションを作成する。
D.アプリケーションロードバランサー（ALB）と関連するターゲットグループをデプロイする。ターゲットグループを Auto Scaling グループに関連付ける。各 ALB のエイリアスを指す Amazon Route 53 ウェイトレコードを作成する。重み付けレコードをオリジンとして使用する Amazon CloudFront ディストリビューションをデプロイする。

正解：A
理由： UDPのVoIPで、最寄りリージョン誘導＋リージョン障害時フェイルオーバーなら AWS Global Accelerator が適任。
そしてUDPを受けるフロントは NLB（ALBはL7でUDP不可）なので NLBをGAのエンドポイントにするAが正解です。

他がダメな理由：

• B：ALBはUDP不可。

• C/D：CloudFrontはHTTP(S)中心でUDP用途に合わない。Route53+CloudFrontの組み合わせもズレ。

質問#30 ある開発チームが、Performance Insights を有効にした汎用 Amazon RDS for MySQL DB インスタンスで、毎月リソース集中型のテストを実行している。テストは月に 1 回 48 時間行われ、データベースを使用する唯一のプロセスである。チームは、DB インスタンスの計算およびメモリ属性を減らすことなく、テストの実行コストを削減したいと考えている。これらの要件を最もコスト効率よく満たすソリューションはどれか。
A.テストが完了したら DB インスタンスを停止する。必要なときに DB インスタンスを再起動する。
B.DB インスタンスでオートスケーリングポリシーを使用し、テスト完了時に自動的にスケーリングする。
C.テスト完了時にスナップショットを作成する。DB インスタンスを終了し、必要に応じてスナップショットをリストアする。
D.テスト完了時に DB インスタンスを低容量インスタンスに変更する。必要なときに DB インスタンスを再度修正する。
正解 C

理由： 「月1回48時間だけ使う」「計算/メモリ属性は落とさない」「コスト削減」なら、
テスト後にスナップショット → DBインスタンス削除 → 必要時に復元が、非稼働期間のインスタンス料金を消せて最も効きます。

他がダメな理由：

• A：RDS停止はできるが、停止期間に制約があり“月1”の長期停止に向きにくい。

• B：RDSで“自動でスケールダウン”みたいな運用は基本できない（Aurora Serverless等なら別）。

• D：インスタンスタイプを下げるのは「属性を減らさない」に反する。