10問中 0問が回答されています
質問:
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
無料レッスン・テストを受講するにはフリーコース(無料)に登録してください。
まず、次の操作を完了する必要があります:
正解数 0/問題数10
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
【SAP-2001】あるソリューションアーキテクトは、既存の VPC 内で稼働する 3 層アプリケーションを担当しています。アプリケーションサーバーはプライベートサブネットに配置され、NAT ゲートウェイ経由でインターネット上の外部 API を呼び出しています。パブリックサブネットにはインターネットゲートウェイへのデフォルトルートが設定されています。企業は新たに社内データセンターとの専用線接続を追加し、オンプレミスの認証システムおよびファイル共有サーバーと通信できるようにする必要があります。オンプレミスのアドレス空間は複数の CIDR ブロックに分かれており、将来的に追加される可能性があります。既存のインターネット向け通信は現在と同じ経路を維持しなければなりません。これらの要件を満たす構成を選択してください。
1 つのルートテーブルに同じ宛先 0.0.0.0/0 を 2 つ登録できるでしょうか。またサブネットに関連付けられるルートテーブルはいくつまででしょうか。この制約を踏まえると、既存の NAT ゲートウェイ経由の通信を維持したままオンプレミス宛の経路を追加するには、どちらの宛先を具体的なプレフィックスとして持つべきかが見えてきます。さらに「CIDR が将来追加される可能性がある」という記述に注目し、手動更新が不要な仕組みは何かを考えてみましょう。
【SAP-2002】あるソリューションアーキテクトは、地方の農地に設置された検査装置向けのシステムを設計しています。装置には産業用ゲートウェイが接続されており、カメラ画像から作物の病害を判定します。判定モデルは Amazon SageMaker AI で学習しており、更新版を定期的に現場へ配布する必要があります。農地の通信回線は不安定で、数時間から数日にわたりインターネットに接続できない状態が発生します。切断中も装置側で画像の判定を継続し、復旧後に判定結果をクラウドへ集約する必要があります。これらの要件を満たすソリューションを選択してください。
数時間から数日にわたって回線が切れる環境で「判定を継続する」という要件は、推論処理をどこで実行するかを決定づけます。クラウドのエンドポイントを呼び出す構成では、通信断の間に何が起きるでしょうか。さらに、モデルの更新版を遠隔の農地へ定期的に配布し、復旧後に判定結果を自動でクラウドへ送る仕組みも必要です。エッジ機器上で AWS のロジックと機械学習モデルを動かすためのランタイムサービスに注目してください。
【SAP-2003】あるソリューションアーキテクトは、複数の VPC から送信されるインターネット向けトラフィックを、サードパーティ製の仮想ファイアウォールアプライアンスで検査する構成を設計しています。アプライアンスは EC2 インスタンスとして稼働し、検査対象のパケットは送信元 IP アドレスと宛先 IP アドレスを保持したまま透過的に渡される必要があります。アプライアンスの構成は変更できません。また、単一のアベイラビリティーゾーンやインスタンスの障害が発生してもトラフィック検査を継続し、自動的に復旧させる必要があります。これらの要件を満たす手順の組み合わせを選択してください。(3 つ選択)
まず「送信元 IP と宛先 IP を保持したまま透過的に渡す」という制約に注目してください。ロードバランサーやゲートウェイの中で、IP アドレスを書き換えないものはどれでしょうか。次に、検査 VPC 側にアプライアンスを並べるだけでは、他の VPC からトラフィックがそこへ到達しません。経路をどう向けるかという要素も必要です。さらに AZ 障害とインスタンス障害への自動復旧という別の観点もあります。どの組み合わせで要件の全範囲をカバーできるか整理してみましょう。
【SAP-2004】あるソリューションアーキテクトは、オンプレミスデータセンターと AWS Direct Connect で接続された VPC を運用しています。VPC は AWS が提供する DNS を使用するよう構成されており、開発チームは内部アプリケーション用のドメイン名を解決するために Amazon Route 53 のプライベートホストゾーンを新規に作成しました。しかし、VPC 内の EC2 インスタンスからそのドメイン名を照会しても応答が返りません。さらに、パブリック IP アドレスを持つインスタンスにパブリック DNS ホスト名が付与されていないことも判明しました。これらの問題を解消する構成を選択してください。
症状が二つある点に注目してください。プライベートホストゾーンの名前が解決されない問題と、パブリック IP を持つインスタンスにパブリック DNS ホスト名が付かない問題です。後者はどの VPC 属性に依存するでしょうか。既定 VPC 以外で新規作成した VPC では、この属性の初期値はどうなっているか思い出してみましょう。また、VPC 内で Route 53 Resolver が待ち受けるアドレスは CIDR の基底から数えて何番目でしょうか。
【SAP-2005】ある企業は、AWS 上の複数の VPC とオンプレミスデータセンターを AWS Direct Connect で接続したハイブリッド環境を運用しています。オンプレミスには社内ドメイン corp.example.com を管理する DNS サーバーが 2 台稼働しています。VPC 内の Amazon EC2 インスタンス上で動作するアプリケーションから、このオンプレミスの社内ドメイン名を解決する必要があります。企業は VPC 側の DNS 設定として Amazon 提供の DNS サーバーを引き続き利用したいと考えています。これらの要件を満たすソリューションを選択してください。
Route 53 Resolver のエンドポイントには 2 種類ありますが、それぞれ「どちらからどちらへ」DNS クエリが流れるための仕組みでしょうか。今回解決したいのは VPC 内の EC2 からオンプレミスのドメイン名であり、クエリの出発点がどこかを整理してみましょう。また「Amazon 提供の DNS サーバーを引き続き利用したい」という条件は、EC2 のリゾルバー設定や DHCP オプションセットを書き換える案にどう影響するかに注目してください。この条件は「社内ドメインの解決方法」の話ではなく、Amazon 提供 DNS が担っている AWS 内部の名前解決(S3・RDS などのサービスエンドポイントやプライベートホストゾーン)を今のまま機能させ続けたいという意味だと捉えると、選択肢を絞り込みやすくなります。
【SAP-2006】あるソリューションアーキテクトは、オンプレミスデータセンターと AWS を AWS Direct Connect で接続したハイブリッド環境を担当しています。オンプレミスには社内ドメインの権威 DNS サーバーが稼働しており、Amazon VPC 内の複数の Amazon EC2 インスタンスから社内ドメインのホスト名を解決する必要があります。同時に、オンプレミスのサーバーからは VPC 内のプライベートホストゾーンに登録されたレコードを解決できなければなりません。DNS サーバーの構築やパッチ適用は避けたい状況です。これらの要件を運用オーバーヘッドを最小限に抑えて満たす構成を選択してください。
DNS 解決の方向が 2 つあることに注目してください。VPC からオンプレミスへ問い合わせる経路と、オンプレミスから VPC のプライベートホストゾーンを引く経路は、それぞれ別の仕組みが必要です。
また「DNS サーバーの構築やパッチ適用は避けたい」という制約は、自前でリゾルバーを立てる案を除外する強いヒントになります。
Amazon 提供 DNS(VPC CIDR + 2)が VPC の外から到達できるかどうかも確認してみましょう。
【SAP-2007】あるソリューションアーキテクトは、AWS Organizations 配下の複数アカウントで構成された環境を担当しています。共有サービスアカウントには内部向けアプリケーションの DNS レコードを登録した Amazon Route 53 プライベートホストゾーンがあり、現在は共有サービスアカウントの VPC からのみ名前解決できます。新たに開発アカウントの VPC で稼働するワークロードから、このプライベートホストゾーン内のレコードを解決する必要があります。既存のホストゾーンとレコードはそのまま利用し、開発アカウントに複製は作成しません。この要件を満たす手順の組み合わせを選択してください。(2つ選択)
プライベートホストゾーンは「関連付けられた VPC の中からのみ」名前解決できる仕組みです。では、ゾーンを所有していないアカウントの VPC を勝手に関連付けられてしまうと問題が起きないでしょうか。所有者側が先に何かを許可し、その許可を前提に VPC 側が関連付けを実行する、という 2 段階の流れになるはずです。先に準備すべきものは何か、それが次のステップで何の前提として使われるかを追ってみましょう。
【SAP-2008】あるソリューションアーキテクトは、複数の事業部門が個別に運用する 20 個の VPC を単一リージョンで管理しています。各 VPC は共有サービス VPC 上の認証基盤とログ収集基盤に接続する必要があります。一方で、事業部門どうしの VPC は相互に通信させてはならず、部門間の通信は監査上も遮断する必要があります。今後 VPC は数十単位で追加される見込みであり、追加のたびに個別の接続設定を積み上げる構成は避けたいと考えています。これらの要件を満たす構成を選択してください。
Transit Gateway は既定で 1 つのルートテーブルを全アタッチメントで共有します。この状態でアタッチされた VPC どうしはどうなるでしょうか。部門間の通信を「監査上も遮断」するとき、パケットが届いた上で拒否するのと、そもそも経路が存在しないのでは、どちらが証明しやすいでしょうか。VPC が数十単位で増える前提も踏まえ、追加のたびに増える設定量が最小になる構成に注目してください。
【SAP-2009】あるソリューションアーキテクトは、社内向けバッチ処理システムを Amazon VPC 上で稼働させています。処理を実行する Amazon EC2 インスタンスはプライベートサブネットに配置され、外部のソフトウェアリポジトリから更新パッケージを取得する必要があります。監査部門の指摘により、システム全体を IPv6 に対応させる計画が進んでおり、EC2 インスタンスには IPv6 アドレスを割り当てて外部と通信させることが決まっています。インスタンスからインターネットへのアウトバウンド通信は許可し、インターネット側から開始される通信はすべて到達させないという条件があります。これらの要件を満たす構成を選択してください。
IPv6 アドレスはすべてグローバルに到達可能であり、プライベートアドレスをグローバルアドレスへ変換するという発想がそもそも必要でしょうか。IPv4 で使い慣れた NAT ゲートウェイが、IPv6 の ::/0 ルートのターゲットとして指定できるかを確認してみましょう。また「インターネット側から開始される通信をすべて到達させない」という条件は、セキュリティグループの設定に頼るのか、ゲートウェイの機能そのもので保証するのか、どちらが要件に忠実かに注目してください。
【SAP-2010】あるソリューションアーキテクトは、決済処理アプリケーションを AWS に移行する計画を立てています。アプリケーションは複数の VPC のプライベートサブネットで動作する Amazon EC2 インスタンス群で構成され、外部の金融機関が提供する API を呼び出します。金融機関は接続元を IP アドレスの許可リストで制限しており、企業がオンプレミスのデータセンターで長年使用してきた自社所有のパブリック IP アドレスブロックを引き続き登録し続けることを希望しています。移行後もこの IP アドレスブロックを送信元として外部 API への通信を継続する必要があります。これらの要件を満たすソリューションを選択してください。
プライベートサブネットの EC2 インスタンスがインターネットへ出るとき、相手側から見える送信元 IP アドレスはどこで決まるでしょうか。VPC の CIDR(プライベート IP アドレス帯)はインターネット上ではルーティングされないため、そのままでは送信元にはなり得ない点も踏まえて考えてみましょう。Elastic IP アドレスは、どのリソースに関連付けることができるのかを整理してみましょう。また、Elastic IP を関連付けたインスタンスでも、そのサブネットにインターネットゲートウェイへのルートがない場合に何が起こるかに注目してください。金融機関の許可リストが対象としているのは、インバウンドではなくアウトバウンドの送信元 IP である点も踏まえて考えてみましょう。
⚠️ こちらは教材の操作/UIなど全般に対するリクエストフォームではございません。
個別の問題についての改善リクエストです。
教材全般についての改善リクエストはお問い合わせフォームよりご連絡ください。
CloudTech(クラウドテック)は多くのユーザーの皆様から改善リクエストをご協力いただき運営できております。
あなたの視点での気づきは他の学習者の迷いを解決する手助けとなります。
運営側でもチェックをしておりますが限界があるため、誠に恐縮ではございますが細かい点でもご遠慮なくご指摘をお願いいたします。
※ 匿名での報告となり、内容は一般公開されません。
※ 技術的なご質問への回答を行うフォームではございませんのでご注意ください。
