Azure認定資格 WEB問題集&徹底解説
AZ-104:Microsoft Azure Administrator
問題文と選択肢
その後 vnet-devtest 側でサブネットを追加しようとした際に、アドレス空間が不足していることが判明しました。
追加するアドレス範囲は vnet-factory のアドレス空間とは重複しません。
要件: vnet-factory と vnet-devtest の間の既存の通信を止めずに vnet-devtest のアドレス空間を拡張し、vnet-factory の仮想マシンから新しいアドレス範囲に作成するサブネットへも通信できるようにする必要がある。
実施すべき手順はどれですか。
- vnet-devtest のアドレス空間にアドレス範囲を追加し、その後 peer-fd を同期 (Sync) する
- peer-fd を削除し、vnet-devtest のアドレス空間にアドレス範囲を追加してから、ピアリングを作り直す
- vnet-devtest のアドレス空間にアドレス範囲を追加する(新しい範囲はピアリング先へ自動で反映されるため、peer-fd への操作は不要)
- 新しいアドレス空間で vnet-devtest を作成し直し、リソースを移行したうえで peer-fd を新しい仮想ネットワークに向けて再作成する
A. vnet-devtest のアドレス空間にアドレス範囲を追加し、その後 peer-fd を同期 (Sync) する
現在の Azure では、ピアリング済みの仮想ネットワークでも、アドレス空間のページでピアリングを残したままアドレス範囲を追加でき、この更新でダウンタイムによる中断は発生しません。vnet-factory との既存の通信は止まりません。
追加後は、vnet-devtest の[ピアリング]で peer-fd を選び[同期]を実行します。同期によってリモート側(vnet-factory)が新しいアドレス範囲を認識し、vnet-factory の仮想マシンから新しいサブネットへ通信できるようになります。追加する範囲が vnet-factory と重複しないという前提条件も満たしており、この選択肢が正解です。
B. peer-fd を削除し、vnet-devtest のアドレス空間にアドレス範囲を追加してから、ピアリングを作り直す
かつては、ピアリング済みの仮想ネットワークのアドレス空間を変更するには先にピアリングを削除する必要がありました。この選択肢はその旧来の手順です。
現在は削除は不要で、削除してから作り直すまでの間は vnet-factory と vnet-devtest の通信が途切れます。「既存の通信を止めずに」という要件に反するため誤りです。
C. vnet-devtest のアドレス空間にアドレス範囲を追加する(新しい範囲はピアリング先へ自動で反映されるため、peer-fd への操作は不要)
アドレス範囲の追加がピアリングを維持したまま行える点は正しいものの、「ピアリング先へ自動で反映される」は誤りです。公式ドキュメントは、プレフィックスの変更・範囲の追加・範囲の削除のいずれも同期が必要な操作とし、更新後はリモートのピアリングごとに同期するよう求めています。
同期しなければ vnet-factory 側は新しい範囲を認識しないままで、既存の通信は続いても新しいサブネットへの通信という要件を満たせません。
D. 新しいアドレス空間で vnet-devtest を作成し直し、リソースを移行したうえで peer-fd を新しい仮想ネットワークに向けて再作成する
仮想ネットワークを作り直してリソースを移行すれば、最終的に広いアドレス空間は手に入ります。
しかし、移行と peer-fd の再作成の間は通信が止まり、作業量も大きくなります。アドレス範囲はピアリングを維持したまま追加できるため、作り直す必要がそもそもありません。要件に反し、過剰な手順です。
アドレス空間を変えたら「同期」。ピアリングは消さない。追加 → Sync で相手に新しい範囲を知らせる。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| vnet-factory と vnet-devtest の既存の通信を止めずに拡張する | ピアリングの削除や仮想ネットワークの作り直しは通信断を伴う →選択肢(B・D)を消す |
| ピアリング済みの仮想ネットワークのアドレス空間を拡張する | 現在はピアリングを維持したままアドレス範囲を追加できる(ダウンタイムなし) →選択肢(A・C)は候補 |
| vnet-factory の仮想マシンから新しい範囲のサブネットへも通信する | 追加・変更・削除の後はピアリングの同期でリモート側に新しい範囲を反映する必要がある →選択肢(C)を消す |
| 追加する範囲は vnet-factory のアドレス空間と重複しない | 範囲追加の前提条件(他のアドレス空間と重複しない)を満たしている →選択肢(A)が正解 |
ひっかけポイント
- 「アドレス空間を変えるには、まずピアリングを削除する」は旧来の手順です。古い教材や記憶のまま B を選ばないようにします。現在はピアリングを残したまま更新できます
- C は「追加するだけで済む」という手軽さが罠です。アドレス範囲の追加は同期が必要な操作として明記されており、同期を省くとリモート側は新しい範囲を知りません
- 要件の後半「vnet-factory の仮想マシンから新しいサブネットへも」が、同期の要否を問う一文です。前半の「通信を止めずに」だけでは A と C を区別できません
- 同期はリモートのピアリングごとに行います。ハブ&スポークのように複数の仮想ネットワークとピアリングしている場合は、それぞれのピアリングで同期が必要です
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「追加したい範囲がvnet-factory のアドレス空間と重複している」 | 他のアドレス空間と重複する範囲は追加できない。重複しない範囲を選び直すのが先。 |
| 「既存のアドレス範囲を削除したい」 | 範囲内のサブネットとリソースを先に空にしてから削除し、そのあと同期する。 |
| 「既存の範囲のプレフィックスを変更したい(例 10.1.0.0/16 → 10.1.0.0/18)」 | これも同期が必要な操作。変更 → 同期の順で、ピアリングは削除しない。 |
| 「アドレス空間の変更を何回かに分けて行う」 | まとめて最後に同期するより、変更のたびに同期することが推奨されている。 |
リファレンス
この問題を解くために必要な知識を扱う公式ドキュメントです。| 知識項目 | 公式ドキュメント |
|---|---|
| ピアリング済み仮想ネットワークのアドレス範囲の追加・変更・削除と同期 (Sync) の手順 | ピアリングされた仮想ネットワークのアドレス空間を更新する - Azure portal |
その後 vnet-devtest 側でサブネットを追加しようとした際に、アドレス空間が不足していることが判明しました。
追加するアドレス範囲は vnet-factory のアドレス空間とは重複しません。
要件: vnet-factory と vnet-devtest の間の既存の通信を止めずに vnet-devtest のアドレス空間を拡張し、vnet-factory の仮想マシンから新しいアドレス範囲に作成するサブネットへも通信できるようにする必要がある。
実施すべき手順はどれですか。
- vnet-devtest のアドレス空間にアドレス範囲を追加し、その後 peer-fd を同期 (Sync) する
- peer-fd を削除し、vnet-devtest のアドレス空間にアドレス範囲を追加してから、ピアリングを作り直す
- vnet-devtest のアドレス空間にアドレス範囲を追加する(新しい範囲はピアリング先へ自動で反映されるため、peer-fd への操作は不要)
- 新しいアドレス空間で vnet-devtest を作成し直し、リソースを移行したうえで peer-fd を新しい仮想ネットワークに向けて再作成する
次の問題前の問題
会員機能
お役立ち情報
姉妹サイト
AWS
- CLF:クラウドプラクティショナー
- SAA:ソリューションアーキテクト-アソシエイト
- AIF:AIプラクティショナー
- SOA:CloudOpsエンジニア-アソシエイト
- DVA:デベロッパー-アソシエイト
- DEA:データエンジニア-アソシエイト
- MLA:機械学習エンジニア-アソシエイト
- SAP:ソリューションアーキテクト-プロフェッショナル
- DOP:DevOpsエンジニア-プロフェッショナル
- AIP:生成AIデベロッパー-プロフェッショナル
- SCS:セキュリティ-専門知識
Microsoft Azure
- AZ-900:Microsoft Azure Fundamentals
- AZ-104:Microsoft Azure Administrator
- AI-901:Microsoft Azure AI Fundamentals
- DP-900:Microsoft Azure Data Fundamentals