Q1 — 単一選択企業は移行期間中、既存業務トラフィックと大量データレプリケーションを同じ10 GbpsのAWS Direct Connectで流します。
業務トラフィックはピーク時7 Gbps、移行処理は期限を満たすため4 Gbpsを要求します。
最も適切なMigration Network Architectureはどれですか。
A. 10 Gbpsは個々の通信量より大きいため、両方を同時に無制限で実行する
B. 業務ピークと移行通信を合算し、時間分離・移行ウェーブ調整・容量追加などで必要な余裕を確保する
C. AWS Direct Connectは業務通信を必ず自動優先するため、移行用Bandwidthの設計は不要である
D. Amazon Route 53のDNS設定を変更し、AWS Direct Connect回線自体のBandwidthを増加させる
答えと解説
答え：B
Migrationに必要なBandwidthは通常業務で利用するBandwidthに追加して考えます。合計が利用可能容量を超える場合は、実行時間や移行ウェーブの調整、回線容量の追加などを検討します。
Q2 — 単一選択移行元からAWSへの大量レプリケーションにはプライベート接続が必要です。
一方、少量の管理通信はパブリックAWSエンドポイントへのHTTPSが許可されています。
最も適切な設計はどれですか。
A. 大量レプリケーションは要件を満たすプライベート経路、許可された管理通信はInternetを利用する
B. 1つでもプライベート接続を使う場合、管理通信を含むすべての通信を必ず同じ経路へ固定する
C. パブリックAWSエンドポイントへのHTTPSにも必ず専用のAWS Direct Connect接続を新設する
D. 管理通信でInternetを利用する場合、大量レプリケーションも同じInternet経路へ変更する
答えと解説
答え：A
通信目的によってプライベート接続要件は異なります。大量レプリケーションと管理通信を、それぞれの要件を満たす経路へ分けることができます。
Q3 — 単一選択大量のデータレプリケーションはAWS Direct Connectで実行しています。
同時に、小規模な別Migration Waveとしてプライベート接続が必要な通信を追加したいと考えています。AWS Direct Connectの空きBandwidthは少ない一方、Site-to-Site VPN側には必要なRouteと十分な容量があります。
最も適切な設計はどれですか。
A. 移行トラフィックは必ず1本の接続へ統一し、小規模な通信もAWS Direct Connectへ追加する
B. 小規模な別Migration WaveをSite-to-Site VPNへ分け、AWS Direct Connectへの追加負荷を避ける
C. Site-to-Site VPNはMigrationには利用できないため、小規模な通信もInternetへ公開する
D. Amazon Route 53の加重ルーティングを使い、AWS Direct ConnectのBandwidthをSite-to-Site VPNへ移動する
答えと解説
答え：B
移行トラフィックをすべて同じ接続へ固定する必要はありません。Site-to-Site VPNが必要なプライベート接続・Route・容量を満たすなら、小規模な移行トラフィックを別経路へ分けることができます。
Q4 — 単一選択Amazon Route 53で管理する本番アプリケーションのDNSレコードはTTLが24時間である。今夜AWS移行先へ切り替えるため、切り替え開始時にTTLを60秒へ変更すれば全利用者がすぐ新しい宛先を見ると担当者が考えている。最も適切なカットオーバー設計はどれですか。
A. 切り替え開始時だけTTLを60秒へ変更すれば、既に24時間でキャッシュされた回答もRoute 53が即座に削除する
B. 切り替えより十分前にRoute 53レコードのTTLを短縮し、以前の長いTTLでキャッシュされた回答が失効する時間を確保してから宛先を更新する
C. Route 53のレコードを変更するとリゾルバーはTTLを無視するため、事前のTTL調整は不要である
D. TTLを短くするとRoute 53ではレコードの宛先を変更できなくなるため、24時間のまま切り替える
答えと解説
答え：B
Route 53でTTLを短縮しても、それ以前の長いTTLで既にキャッシュされたDNS回答は直ちには消えません。カットオーバー前にTTLを短縮して旧キャッシュが失効する時間を確保し、その後に移行先へレコードを更新します。
Q5 — 単一選択本番カットオーバーではAWS Direct Connect 1系統だけを利用します。ルート、DNS、ID、帯域は検証済みですが、この回線が停止するとAWS側への通信だけでなく、ロールバック時に必要な旧環境への通信も維持できません。
カットオーバー前に追加すべき対応として最も適切なのはどれですか。
A. DNS TTLをさらに短くし、ネットワーク障害時も名前解決だけで切り替えられるようにする
B. 独立した冗長経路を用意してフェイルオーバーを検証し、旧環境への経路も維持する
C. AWS Direct Connectの帯域を増やし、単一回線のまま通信量だけを処理できるようにする
D. 管理通信だけInternetへ変更し、業務通信の単一経路はそのまま維持する
答えと解説
答え：B
容量が十分でも単一経路では障害時にカットオーバー後の通信とロールバック経路を同時に失う可能性があります。独立した冗長経路を準備し、実際にフェイルオーバーできることを事前確認します。