AWS SOAレベル無料練習問題①

第1問: グローバルに配置されたWebアプリを最速応答のリージョンへ誘導する方法

あるスポーツニュース提供企業は、単純なWebアプリをAmazon EC2インスタンス上で稼働させ、それらをElastic Load Balancerでまとめています。現在はeu-west-2リージョンのみで運用し、DNSにはAmazon Route 53のシンプルなレコードを使用しています。しかし世界各地の利用者に対して、最速の応答時間を実現するため、us-east-1とap-south-1リージョンにも同一アプリを展開する方針となりました。SysOps管理者はどのように設定すべきでしょうか？

正解: 2. 新しいリージョンにアプリケーションのコピーをデプロイし、それぞれに別のElastic Load Balancerを用意してからLatencyルーティングポリシーに変更する

最速の応答時間を提供するには、各リージョンに同一アプリを配置し、それぞれに専用のElastic Load Balancerを用意しておく必要があります。次にRoute 53のレコードに対してLatencyルーティングポリシーを使うことで、DNSクエリに対してユーザーからのレイテンシが最も低いリージョンへ誘導されます。

他の選択肢

GeoLocationルーティングはユーザーの地理位置に基づいて誘導しますが、必ずしも最速応答とは限りません。
Multivalueルーティングは複数の健康なリソースを返すだけで、ユーザーが最適なリージョンに誘導される保証はありません。
シンプルルーティングを継続すると、特定の1つのエンドポイントに偏り、複数リージョンを活かした最速応答のメリットを得られません。

第2問: CLIでのMFAを強制するには

ある医療系企業は、すべてのIAMユーザーに対して多要素認証(MFA)を使用したAPI呼び出しを義務づけています。しかし、ユーザーがCLIでAWSサービスにアクセスしても、MFAの入力を要求されずにコマンドを実行できる状況です。運用ポリシーとして「MFAなしのAPI呼び出しは拒否」するルールをIAMポリシーに設定しましたが、依然としてMFAが実施されないままCLIを利用可能です。CLI経由のAPI呼び出しに実際にMFA認証を適用するには、SysOps管理者はどのような追加手順を取る必要がありますか？

正解: 1. MFAのトークンを用いてget-sessiontokenコマンドを実行し、得られた一時的な資格情報でAPI呼び出しを行うようユーザーに指示する

AWS CLIでMFAを強制するには、IAMユーザーが通常のアクセスキーではなくMFA認証を伴う一時的なセッショントークンを使用してAPIコールを行う必要があります。具体的には、get-sessiontokenコマンドにMFAデバイスのシリアル番号やトークンコードを指定すると、一時的なセキュリティ資格情報が取得できます。その資格情報をAWS CLI設定に反映することで、MFA必須のポリシーが適用され、API呼び出しを実行可能になります。

他の選択肢

IAMロールにMFAを有効化する方法は、スイッチロール時にMFAを使うケースに有効ですが、ユーザーがCLI経由で日常的にMFAを要するAPIコールを行うにはget-sessiontokenが一般的です。
CLIを禁止してコンソールでMFAを強制するのは、本来の要件であるCLI利用を妨げるため不適切です。
マネジメントコンソールへのログイン状況とCLIの資格情報は独立しているため、コンソールログイン中であってもCLIでMFAが強制されるわけではありません。

第3問: IO集中型アプリケーションのEBSボリュームパフォーマンス向上策

ある画像処理企業は、高いI/Oを要求するアプリケーションをAmazon EC2の汎用インスタンスタイプに移行しました。インスタンスには単一の汎用SSD EBSボリュームをアタッチしており、ユーザーが集中的な読み書きを行うとパフォーマンスが著しく低下、あるいは処理が失敗する現象が報告されています。CloudWatchメトリクスを調べたところ、問題が発生している時間帯にVolumeQueueLengthが一貫して高い値を示していました。SysOps管理者は、この課題を解決してアプリケーションの性能を正常に回復させたいと考えています。どのアクションが最適でしょうか？

正解: 1. ボリューム設定を変更し、より高いIOPS性能をもつプロビジョンドIOPS SSDに切り替える

EBS gp2やgp3などの汎用SSDボリュームでは、I/Oが集中した場合にスループットやIOPSが不足し、VolumeQueueLengthが高止まりして性能劣化を引き起こすことがあります。プロビジョンドIOPS SSD(io1またはio2)に変更することで、必要なIOPSを確保でき、アプリケーションのI/O要求を満たす性能を安定的に提供できます。

他の選択肢

インスタンスタイプをネットワーク最適化型に変更しても、ディスクI/O帯域幅の問題は根本的に解決しません。
自動I/O最適化設定のオンオフはEBSボリュームのIOPS不足解消とは関係が薄く、本質的な対策ではありません。
CloudWatchアラートを設定し手動対処する方法は根本的なIO性能向上にならず、運用負担が増すだけです。

第4問: オンプレミスDNSを使用するVPC内アプリケーションの名前解決失敗

ある製造業の企業は、オンプレミスネットワークとAWS上のVPCをSite-to-Site VPNで接続しています。新たにVPCへ移行したアプリケーションが、オンプレミスにある内部DNSサーバーを利用してドメイン解決しようとしていますが、名前解決が失敗して顧客データにアクセスできません。アプリケーションがオンプレミスの内部ドメイン名を正常に解決できるようにするには、SysOps管理者はどうすればよいでしょうか？

正解: 4. Route 53 Resolverアウトバウンドエンドポイントを作成し、オンプレミスDNSサーバーへDNSクエリを転送するように構成する

オンプレミスDNSを使用するには、AWS内のVPCがDNSリクエストをVPNを通じてオンプレミスサーバーに転送できる仕組みが必要です。Route 53 Resolverアウトバウンドエンドポイントを設定し、ドメイン名に基づいてオンプレミスDNSへクエリをフォワードすることで、VPC内リソースからオンプレミスの内部ドメインを解決可能になります。

他の選択肢

EC2インスタンスをDNSフォワーダーとして起動する場合、手動設定や運用コストが増加し、フォールトトレランスが低下する可能性があります。
AWS Direct Connectを追加で構築するのは大規模かつ高コストの方法であり、単にDNSフォワードを行うだけならSite-to-Site VPNで十分です。
オンプレミスドメインをパブリックホストゾーンに登録すると、インターネットから内部ドメインが参照可能になってしまい、セキュリティリスクが高まります。

第5問: 他のAWSアカウントに共有されたService Catalogポートフォリオで可能な操作

ある医療ソリューション企業のSysOps管理者は、AWS Service Catalogでポートフォリオを作成し、組織内の別のAWSアカウントと共有しました。共有先のアカウントは別部門が管理しており、そこでも同じ製品を利用したいと考えています。共有されたポートフォリオについて、受け取ったアカウントの管理者が実行できるアクションとして正しいのはどれでしょうか？

正解: 3. 共有されたポートフォリオから製品をローカルポートフォリオに追加し、ユーザーがデプロイできるようにする

AWS Service Catalogで共有されたポートフォリオは、受信側アカウントの管理者がその製品を利用できるようにインポートし、ローカルポートフォリオに登録することができます。ただし、共有元が所有するポートフォリオや製品を直接修正する権限は受信側アカウントにはありません。代わりにローカルポートフォリオへ製品を追加し、その範囲内でアクセス制御やユーザーデプロイ設定を管理するのが一般的な運用です。

他の選択肢

共有ポートフォリオに新製品を追加する行為は、元のアカウントが所有するため権限がありません。
起動ロールの変更などは共有元で行う設定で、受信側が直接置き換えることはできません。
製品のテンプレート自体を編集する権限は共有先アカウントには付与されないため、テンプレート変更はできません。

第6問: AWS Systems Manager Patch ManagerでのEC2パッチ適用に必要な追加設定

ある金融サービス企業のSysOps管理者は、AWS Systems Manager Patch Managerを利用してEC2インスタンスへパッチを自動配布しています。パッチ対象のインスタンスはタグで識別し、パッチベースラインとメンテナンスウィンドウも設定済みです。SysOps管理者は、パッチ適用時にSystems ManagerがEC2インスタンスへアクセスできるようにするため、追加の対応が必要だと認識しています。要件を満たすために行うべき追加アクションはどれでしょうか？

正解: 4. IAMインスタンスプロファイルをEC2インスタンスにアタッチし、Systems Managerへのアクセス権限を付与する

AWS Systems Manager Patch ManagerでEC2インスタンスを制御・管理するには、EC2インスタンスにSysOps管理者またはシステムが許可したIAMロールをアタッチする必要があります。具体的にはAmazonSSMManagedInstanceCoreなどのポリシーを含むインスタンスプロファイルロールを設定し、それをEC2インスタンスに付与することで、Systems Managerが対象インスタンスへアクセスし、パッチ適用などの操作を実行できます。

他の選択肢

セキュリティグループのインバウンドルールを追加するだけでは、Systems Managerへのアクセス権限を付与することにはなりません。
アクティベーションを行う方法は、オンプレミスサーバーや外部リソースをSystems Managerで管理する際に使用する手順であり、通常のEC2インスタンスでは不要です。
タグを使用しないように設定を変更すると、パッチ対象を識別できなくなり、運用が煩雑になるため推奨されません。

第7問: ニュースサイトをDDoS攻撃から守るためのWAFレート制限設定

あるメディア企業は、アジア圏に多いユーザー向けにAmazon S3（ap-southeast-1リージョン）にホストしたニュースサイトをAmazon CloudFrontディストリビューションの背後で公開しています。最近、DDoS攻撃対策が必要となり、同時にレート制限（レートベースルール）を柔軟に設定できるようにしたいと考えています。SysOps管理者は、会社側がレートベースルールを常に制御できる仕組みを維持しつつ、DDoS攻撃からサイトを保護するには、どのようなソリューションを導入すべきでしょうか？

正解: 3. グローバルスコープのAWS WAF WebACLを作成し、デフォルトアクションをAllowにしてレートベースルールでDDoS攻撃をブロックし、CloudFrontディストリビューションにWebACLを関連付ける

CloudFrontへの攻撃を防ぐには、AWS WAFをグローバルスコープで利用し、デフォルトアクションをAllowに設定したうえでレートベースルールでDDoS関連の大量リクエストをブロックする方法が有効です。こうすることで通常のアクセスは許可される一方、異常に高いアクセス数を検知するとレートベースルールが動作して攻撃を阻止します。さらにWebACLをCloudFrontディストリビューションに関連付けることで、エッジロケーションでのDDoS対策が可能になります。

他の選択肢

リージョンスコープのWAF WebACLはS3バケットに関連付けできますが、CloudFront経由のリクエストには適用されません。DDoS防御をエッジで行うにはグローバルスコープでCloudFrontに関連付ける必要があります。
AWS Shield AdvancedはDDoS保護を強化しますが、レートベースルールの柔軟な制御を行うためにはWAFのWebACLが必要です。
CloudFrontを無視してS3バケットに直接WAFをアタッチすると、EdgeでのDDoS緩和が行われないため、CloudFrontでの最適な防御ができません。

第8問: 全ビルドアップロードの送信元IPを単一化する方法

あるゲーム開発企業では、Amazon EC2上で動作するビルドサーバー群（ビルドフリート）を使ってビルドアーティファクトを外部サービスにアップロードしています。新たに外部サービス側で「すべてのアップロードが単一のIPアドレスから行われる」ことを要件とするIPホワイトリストが設けられたため、複数のEC2インスタンスがそれぞれ異なるパブリックIPを使ってアップロードしている現状では対応できません。SysOps管理者がこの要件を満たすには、どのように構成を変更すべきでしょうか？

正解: 1. 全EC2インスタンスのアウトバウンドトラフィックをNATゲートウェイ経由にし、NATゲートウェイのIPアドレスを外部サービスへ登録する

NATゲートウェイを利用すれば、プライベートサブネット内のEC2インスタンス全てが単一のNATゲートウェイのパブリックIPアドレスを使ってインターネットへアクセスできます。したがって外部サービスから見ればすべてのアップロードが同一IPから行われることになり、要求されたIP許可リストにNATゲートウェイのIPアドレスを登録するだけで要件を満たせます。

他の選択肢

AZのIPアドレスに依存させる方法は存在せず、AZには特定のパブリックIPが割り当たらないため実現できません。
インターネットゲートウェイはVPC全体で使用されるリソースですが、複数のEC2インスタンスが個別パブリックIPを持つ可能性があり、単一IPに固定できません。
ピアリング先VPCを用意しても、パブリックIPが単一化されるわけではありません。NATゲートウェイ等の仕組みが必要になります。

第9問: Windows EC2インスタンスで拡張したEBSボリューム容量がファイルシステムに反映されない

ある映像制作会社は、Amazon EC2上でWindows Serverを稼働させています。ストレージ不足が発生しそうになったため、SysOps管理者はEC2コンソールからEBSボリュームサイズを拡張しました。しかし、Windowsのファイルシステム上では新しいストレージ容量が認識されていないため、容量不足が続いています。どのようにすればこの問題を解決できるでしょうか？

正解: 4. Windowsのディスク管理ツールなどを使用してファイルシステムを拡張し、新しいボリューム容量を使えるようにする

EC2コンソール上でEBSボリュームのサイズを拡張しても、Windowsではオペレーティングシステム側でファイルシステムの拡張操作が必要です。Windowsのディスク管理ツールやdiskpartコマンドなどを使用してファイルシステムを拡張すると、追加されたストレージ容量を認識して利用できるようになります。

他の選択肢

別ボリュームを作成して再アタッチする方法は、追加のスナップショット作成やデータコピーが必要になり、手間が増えます。
EC2インスタンスの再起動ではファイルシステムが自動で拡張されないため、問題は解決しません。
EBSボリュームをデタッチして再アタッチしても、ファイルシステムを拡張する必要があることに変わりはありません。

第10問: VPC宛て通信のみをAWS Client VPN経由でルーティングする方法

ある医療ソフトウェア企業は、社内ユーザーがAWS上のリソースに安全にアクセスするため、AWS Client VPNを導入しました。コンプライアンス上の理由で、インターネットへの一般的なトラフィックは企業ネットワークを経由させ、VPC内のリソースへのアクセスのみVPNトンネルを通過させたいと考えています。SysOps管理者がClient VPNをどのように設定すれば、この要件を満たすことができるでしょうか？

正解: 3. Client VPNエンドポイントで分割トンネルを有効にし、VPC宛て通信だけをVPN経由にする

分割トンネルを有効にすると、クライアントはVPC内IPアドレス宛ての通信のみをVPN経由とし、その他のインターネットアクセスはローカルネットワークを使うようにルーティングされます。これによりコンプライアンス要件の「VPC向け通信のみがVPNトンネルを経由する」という条件を満たしつつ、不要なトラフィックをVPNに流さずに済むため、帯域などのリソースを節約できます。

他の選択肢

プライベートサブネット関連付けとNATゲートウェイ：全トラフィックをVPN経由にする設定とは逆の動きになり、要件を満たせません。
DNSサーバー設定の指定：DNSの名前解決を制御するだけではインターネット宛て通信をローカルに留めることはできません。
プライベート証明書の利用：これはVPNの証明書管理手法に関する設定であり、トラフィックルーティングの設定とは無関係です。