模擬問題集一覧

AZ-700 模擬問題集(練習問題)

Azure Network Engineer 合格に向けた本番形式の模擬問題集。すべての問題に詳しい解説と、ドメイン別の弱点分析つき。

2 練習テスト 160 問 合格ライン 70% 各 120 分

この模擬問題集で身につくこと

  • 本番と同じ形式・難易度の問題で実力を確認
  • 制限時間つきの試験モードで時間配分を体得
  • 演習モードで1問ずつ解説を読みながら学習
  • すべての問題に正解の根拠つきの詳しい解説
  • ドメイン別スコアで弱点分野をひと目で把握
  • 完了後も何度でも復習して本番前に仕上げ

練習テストの内容

2 テスト · 全 160 問
1
模擬問題集1先頭 15 問 無料
80 問 120 分 合格 70%
2
模擬問題集2 プラン限定
80 問 120 分 合格 70%

説明

AZ-700(Azure Network Engineer)の合格に向けた、本番形式の模擬問題集です。全 160 問を2 回の練習テストに分割し、 試験モード/演習モードで受験できます。各問題には正解の根拠と誤答の理由を記した詳しい解説が付き、受験後はドメイン別のスコアで弱点を把握できます。 各試験は先頭の問題から無料でお試しいただけます。

月額 ¥980 で全 160 問+全解説が受け放題

模試プラン(¥980/月)なら、ロックされた練習テストと詳しい解説、ドメイン別の弱点分析がすべて使い放題。本番に向けて実力を仕上げましょう。

AZ-700 の操作は、実機のハンズオンラボで身につける

問題集で覚えた知識を、本物の Azure・AWS 環境で手を動かして確かめられます。 Pro プランなら AZ-700 対応のハンズオンラボ 5 本と、この問題集の全 160 問がすべて使えます。 ラボは会員登録だけで 1 本無料で試せます。

AZ-700 の対応ラボを見る(5 本)ラボを 1 本無料で試す

AZ-700 の出題範囲(カバーしている分野)

全 160 問を、本番の試験ガイドに沿った次の分野から出題しています。 受験後はドメイン別の正答率が表示され、弱点が特定できます。 難易度・学習時間・合格までの進め方はAZ-700 の学習ガイドにまとめています。

AZ-700 の無料練習問題(15 問・解説つき)

会員登録なしで、全 160 問のうち 15 問を正解と解説つきでご覧いただけます。 問題をクリックすると選択肢と解説が開きます。

問題 1接続を作成する前に行うべきことは何ですか?ハイブリッド ネットワークの設計・実装・管理
問題
あなたは Vnet1 という名前の Azure 仮想ネットワークと、オンプレミス ネットワークを所有しています。オンプレミス ネットワークにはポリシー ベース VPN デバイスがあります。 Vnet1 には、SKU が VpnGw1 でルート ベースとして構成された GW1 という名前の仮想ネットワーク ゲートウェイがデプロイされています。 GW1 に対するサイト間 (S2S) VPN 接続が次のように構成されています。 [GW1 の接続設定] | 設定 | 値 | | Use Azure Private IP Address | Disabled | | BGP | Disabled | | IPsec / IKE policy | Default | | Use policy based traffic selector | Enable | | DPD timeout in seconds | 45 | | Connection Mode | Default | | IKE Protocol | IKEv2 | オンプレミス ネットワークがルート ベースの GW1 に接続できるようにする必要があります。 接続を作成する前に行うべきことは何ですか?

選択肢と解説

  • 1
    Connection Mode を ResponderOnly に設定する。
  • 2
    BGP を Enabled に設定する。
  • 3
    Use Azure Private IP Address を Enabled に設定する。
  • ✓
    IPsec / IKE policy を Custom に設定する。

解説

正解: IPsec / IKE policy を Custom に設定する。
ルート ベース VPN ゲートウェイからポリシー ベース VPN デバイスへ接続するには、カスタム IPsec/IKE ポリシーと組み合わせてポリシー ベース トラフィック セレクター (UsePolicyBasedTrafficSelectors) を有効にする必要があります。
解説: ポリシー ベース VPN デバイスは、両端のプレフィックスの組み合わせ (具体的なトラフィック セレクター) を用いて IPsec トンネルの暗号化対象を定義します。一方、ルート ベース VPN ゲートウェイは既定でワイルドカード (0.0.0.0/0) のトラフィック セレクターを使用するため、そのままではポリシー ベース デバイスとの IKE フェーズ 2 ネゴシエーションが成立しません。Azure のルート ベース VPN ゲートウェイでポリシー ベース デバイスと相互運用するには、接続オブジェクトで「Use policy based traffic selector = Enable」とするだけでなく、カスタム IPsec/IKE ポリシー (IKE および IPsec の暗号化/整合性アルゴリズム、DH/PFS グループ、SA ライフタイムを完全指定) を割り当てる必要があります。提示の構成では Use policy based traffic selector が Enable になっているものの、IPsec / IKE policy が Default のままであるため、接続を作成する前に Custom へ変更しカスタム ポリシーを定義する必要があります。
各選択肢の検討:
  • Connection Mode を ResponderOnly に設定する。: Connection Mode は IKE ネゴシエーションのイニシエーター/レスポンダーを制御する設定であり、ポリシー ベース デバイスとの相互運用要件とは関係ありません。
  • BGP を Enabled に設定する。: BGP は動的ルーティング用であり、ポリシー ベース VPN は静的セレクターのみを扱うため BGP は使用できません。むしろ有効化は要件と矛盾します。
  • Use Azure Private IP Address を Enabled に設定する。: これは ExpressRoute プライベート ピアリング経由でゲートウェイのプライベート IP を VPN エンドポイントとして使う機能で、ポリシー ベース デバイスとのトラフィック セレクター不整合の解消には寄与しません。
  • IPsec / IKE policy を Custom に設定する。: カスタム ポリシーを指定することで、ポリシー ベース トラフィック セレクターを伴う接続を作成でき、ポリシー ベース デバイスとの相互運用が成立します。
参考: Microsoft Learn
オンプレミスのポリシー ベースの複数の VPN デバイスに VPN ゲートウェイを接続する
この問題のページを開く →
問題 2ハイブリッド ネットワークの設計・実装・管理ハイブリッド ネットワークの設計・実装・管理
問題
あなたは 3 つのオンプレミス ネットワークを所有しています。 Azure サブスクリプションには Basic SKU の Azure Virtual WAN があります。この Virtual WAN には 1 つの仮想ハブと、スループットが 1 Gbps に制限された仮想ネットワーク ゲートウェイが 1 つ含まれています。 オンプレミス ネットワークは、サイト間 (S2S) VPN 接続を使用してこの Virtual WAN に接続しています。 管理オーバーヘッドを最小限に抑えつつ、Virtual WAN のスループットを 3 Gbps に増やす必要があります。 何を行うべきですか?

選択肢と解説

  • ✓
    Virtual WAN を Standard SKU にアップグレードする。
  • 2
    Azure サブスクリプションに追加の VPN ゲートウェイを追加する。
  • 3
    追加の仮想ハブを作成する。
  • 4
    ゲートウェイ スケール ユニット数を増やす。

解説

正解: Virtual WAN を Standard SKU にアップグレードする。
Basic Virtual WAN ではゲートウェイ スケール ユニットを変更できず最大 1 Gbps に制限されるため、より高いスループットを得るには Standard SKU へのアップグレードが必須です。
解説: Basic Virtual WAN は単一の仮想ハブと S2S VPN のみをサポートし、VPN ゲートウェイのスループットも実質 1 スケール ユニット (500 Mbps × 2 = 1 Gbps 相当) に固定されています。スループットを 3 Gbps に引き上げるためには、まず Virtual WAN を Standard SKU にアップグレードして、ゲートウェイ スケール ユニットの増加 (1 スケール ユニット = 500 Mbps、6 スケール ユニットで 3 Gbps) を可能にする必要があります。アップグレードは Basic → Standard の片方向で、ポータルから 1 操作で完了するため最も少ない管理オーバーヘッドで要件を満たせます。
各選択肢の検討:
  • Virtual WAN を Standard SKU にアップグレードする。: Basic の機能制限 (1 Gbps 上限、スケール ユニット変更不可、ExpressRoute や仮想ハブ間メッシュ不可) を解除し、スループットを引き上げるための前提条件であり、最小の管理操作で実現できます。
  • Azure サブスクリプションに追加の VPN ゲートウェイを追加する。: 追加の VPN ゲートウェイ自体は Virtual WAN 内のゲートウェイ スループットを引き上げる手段ではなく、構成も複雑化します。
  • 追加の仮想ハブを作成する。: Basic では 1 つの仮想ハブのみが許可されるため、そもそも作成できません。また仮想ハブ追加はスループット拡張の本筋ではありません。
  • ゲートウェイ スケール ユニット数を増やす。: Basic SKU ではゲートウェイ スケール ユニットの変更がサポートされておらず、先に Standard へアップグレードしなければこの操作自体が行えません。
参考: Microsoft Learn
Azure Virtual WAN に関する FAQ
Azure Virtual WAN とは
この問題のページを開く →
問題 3ソリューションに含めるべき 2 つのアクションはどれですか。コア ネットワーク インフラの設計・実装
問題
ケース スタディ これはケース スタディです。ケース スタディは個別に時間制限されません。試験全体の時間内で各ケースを完了できますが、他にもケース スタディやセクションが含まれる可能性があるため時間管理に注意してください。 概要 Litware, Inc. は金融会社で、ボストンにメイン データセンターを置き、米国内に 20 の支社を持ちます。ユーザーは Android、iOS、Windows 10 デバイスを使用しています。 既存環境 - ハイブリッド環境 オンプレミス ネットワークには litwareinc.com という Active Directory フォレストがあり、Azure AD Connect により litwareinc.com という Azure AD テナントと同期しています。すべての支社は Vnet1 という仮想ネットワークにサイト間 VPN で接続しています。 Azure 環境 Litware は litwareinc.com Azure AD テナントにリンクされた Sub1 というサブスクリプションを所有しています。Sub1 は East US リージョンに以下のリソースを保持しています。 [リソース一覧] Vnet1 (仮想ネットワーク、192.168.0.0/20) GatewaySubnet (192.168.15.128/29、Vnet1 に配置) VPNGW1 (Vnet1 にデプロイされた VPN ゲートウェイ) Vnet2 (仮想ネットワーク、192.168.16.0/20) SubnetA (Vnet2 内、192.168.16.0/24) Vnet3 (仮想ネットワーク、192.168.32.0/20) cloud.litwareinc.com (Private DNS ゾーン、未リンク) VMScaleSet1 (SubnetA にデプロイされた 4 VM のスケール セット) VMScaleSet2 (SubnetA にデプロイされた 2 VM のスケール セット) storage1 / storage2 (ストレージ アカウント、パブリック エンドポイント遮断済み) Vnet1 と Vnet2 は双方向ピアリングされています。Vnet1 と Vnet3 も双方向ピアリングされています。現時点で Vnet2 と Vnet3 は直接通信できません。 要件 (抜粋) ビジネス要件: 他の要件を満たす限りコスト最小化を最優先する。 仮想ネットワーキング要件: - Vnet2 および Vnet3 の既定ルート (0.0.0.0/0) を ExpressRoute 回線経由でボストン データセンターに向ける - cloud.litwareinc.com のレコードをオンプレミスから解決できるようにする - Azure VM の DNS 名を自動的に cloud.litwareinc.com に登録する - プラットフォーム管理サービスに割り当てるサブネット サイズを最小化する - VMScaleSet1 から VMScaleSet2 への通信は TCP 443 のみ許可する ハイブリッド ネットワーキング要件: - リモート ユーザーは Azure AD 認証で P2S VPN により Vnet1 へ接続する - ボストン データセンターと全仮想ネットワーク間のレイテンシ最小化 - ボストン データセンターは ExpressRoute FastPath で Azure に接続する - Vnet2 と Vnet3 間のトラフィックは Vnet1 を経由してルーティングする PaaS ネットワーキング要件: - storage1 はパブリック エンドポイントを公開せず、全オンプレミスからアクセス可能であること - storage2 はパブリック エンドポイントを公開せず、Vnet2 と Vnet3 からアクセス可能であること 仮想ネットワーキング要件およびビジネス要件を満たす形で、Vnet2 と Vnet3 を接続する必要があります。ソリューションに含めるべき 2 つのアクションはどれですか。各正解は解の一部です。 注: 各正答に 1 ポイントが与えられます。

選択肢と解説

  • 1
    Vnet1 からのピアリングで、リモート仮想ネットワークから転送されたトラフィックを許可する (Allow traffic forwarded from remote virtual network) を選択する。
  • ✓
    Vnet2 および Vnet3 からのピアリングで、リモート仮想ネットワークから転送されたトラフィックを許可する (Allow traffic forwarded from remote virtual network) を選択する。
  • 3
    Vnet1 からのピアリングで、リモート仮想ネットワークのゲートウェイまたは Route Server を使用する (Use the remote virtual network's gateway or Route Server) を選択する。
  • 4
    Vnet1 からのピアリングで、リモート仮想ネットワークへのトラフィックを許可する (Allow traffic to remote virtual network) を選択する。
  • ✓
    Vnet2 および Vnet3 からのピアリングで、リモート仮想ネットワークのゲートウェイまたは Route Server を使用する (Use the remote virtual network's gateway or Route Server) を選択する。

解説

正解: B (Vnet2/Vnet3 側で Allow traffic forwarded from remote virtual network を有効化) と E (Vnet2/Vnet3 側で Use the remote virtual network's gateway or Route Server を有効化)。
Vnet1 をハブとするハブ アンド スポーク構成で、スポーク (Vnet2, Vnet3) を相互に通信させ、かつ Vnet1 上の VPN/ExpressRoute ゲートウェイを共有させるための定石です。
解説: 要件では Vnet2 と Vnet3 を Vnet1 経由でルーティングし、既定ルートを Vnet1 のゲートウェイ (ExpressRoute) に流す必要があります。仮想ネットワーク ピアリングは推移しないため、スポーク同士を Vnet1 経由で通信させるには、ハブ側 (Vnet1) のピアリングで「Allow forwarded traffic」を、スポーク側 (Vnet2/Vnet3) のピアリングで「Allow traffic forwarded from remote virtual network」を有効にして、ハブ経由の転送トラフィックを許可します。さらにスポークから Vnet1 のゲートウェイを利用させるため、スポーク側で「Use the remote virtual network's gateway or Route Server」を有効化し、ハブ側では「Use this virtual network's gateway」を有効にします。この問題が問うているスポーク側設定は B と E です (ハブ側設定は別途必要)。これにより Vnet2 ⇔ Vnet1 (NVA や UDR) ⇔ Vnet3 の通信および ExpressRoute 既定ルートの伝播が成立します。
各選択肢の検討:
  • A: ハブ側でリモートから転送されたトラフィックを許可する設定。ハブ側で必要ではあるが、本問が要求するのはスポーク側の構成のため B と組み合わせる必要がある。本問では正答の組合せに該当しない。
  • B: スポーク側で「リモートから転送されたトラフィックを許可」を有効化する設定で、ハブ経由の通過トラフィックを受け入れるために必須。
  • C: ハブ側で「リモート仮想ネットワークのゲートウェイまたは Route Server を使用する」を選ぶ設定。Vnet1 自身がゲートウェイを持つため、ハブで設定すべきは Use this virtual network's gateway であり、不適切。
  • D: Allow traffic to remote virtual network は既定で有効になっており、追加で設定しても要件には寄与しない。
  • E: スポーク側で「リモート仮想ネットワークのゲートウェイまたは Route Server を使用する」を有効化する設定。Vnet1 の VPN/ExpressRoute ゲートウェイをスポークから利用するために必須で、要件「Vnet2/3 の既定ルートを ExpressRoute 経由でボストンへ」を満たすうえで不可欠。
参考: Microsoft Learn
仮想ネットワーク ピアリングの概要
仮想ネットワーク ピアリングの VPN ゲートウェイ トランジットを構成する
この問題のページを開く →
問題 4ネットワークのセキュリティ保護と監視ネットワークのセキュリティ保護と監視
問題
あなたは次のリソースを含む Azure サブスクリプションを所有しています。 [リソース一覧] | 名前 | 種類 | 説明 | | DDoSplan1 | Azure DDoS Protection plan | VNet1 で有効化済み | | VNet1 | 仮想ネットワーク | VM1 という仮想マシンを含む | | IP1 | パブリック IP アドレス | VM1 に関連付け済み | IP1 を標的とするシミュレーションを実行して DDoSplan1 をテストしました。 DDoS Protection の軽減レポートを確認する必要があります。 何を使うべきですか?

選択肢と解説

  • 1
    Azure ポータルの DDoS Protection プラン
  • ✓
    Log Analytics
  • 3
    Microsoft Defender for Cloud
  • 4
    Azure Monitor Network Insights

解説

正解: Log Analytics
DDoS Protection の軽減レポート (mitigation report) は、DDoS 保護対象のパブリック IP の診断ログを Log Analytics ワークスペースに送信し、そこに用意されるブックやクエリで参照します。
解説: Azure DDoS Protection では、保護対象のパブリック IP に対して攻撃通知 (DDoSMitigationStarted/Stopped) や軽減レポート (DDoSMitigationReports)、フロー ログ (DDoSMitigationFlowLogs) を診断ログとして出力できます。これらを Log Analytics ワークスペースに送信すると、Microsoft が提供する DDoS ブックや Kusto クエリで攻撃の詳細、ドロップ パケット数、推定ピーク帯域、攻撃ベクター内訳などを含む軽減レポートを確認できます。Azure ポータルの DDoS プラン画面ではプランの基本情報やメトリックは確認できますが、詳細な軽減レポートは Log Analytics 経由で参照する設計です。
各選択肢の検討:
  • Azure ポータルの DDoS Protection プラン: メトリックや有効化状態の確認は可能だが、シミュレーション結果の詳細な軽減レポートを直接表示する機能は備えていない。
  • Log Analytics: DDoS のリソース ログ (DDoSMitigationReports など) を集約して詳細な軽減レポートを参照する正式な手段。
  • Microsoft Defender for Cloud: セキュリティ態勢管理や推奨事項を提供するが、DDoS の軽減レポートそのものは扱わない。
  • Azure Monitor Network Insights: ネットワーク リソースのトポロジやメトリックの可視化が中心で、DDoS の軽減レポート文書を取得する仕組みではない。
参考: Microsoft Learn
DDoS Protection をシミュレーションでテストする
Azure DDoS Protection の診断ログを構成する
この問題のページを開く →
問題 5最初に何をすべきですか?ネットワークのセキュリティ保護と監視
問題
あなたはシアトルのオンプレミス データセンターを所有しています。 Azure サブスクリプションには West US 2 リージョンに Azure Network Watcher リソースが 1 つあります。 オンプレミス データセンターと West US 2 リージョン間、およびオンプレミス データセンターと East US 2 リージョン間のネットワーク遅延を文書化する必要があります。管理オーバーヘッドを最小化しなければなりません。 最初に何をすべきですか?

選択肢と解説

  • 1
    Get-AzNetworkWatcherConnectionMonitor コマンドレットを実行する。
  • 2
    Get-AzNetworkWatcherReachabilityProvidersList コマンドレットを実行する。
  • 3
    East US 2 リージョンに Network Watcher リソースを作成する。
  • ✓
    West US 2 リージョンに Connection Monitor リソースを作成する。

解説

正解: West US 2 リージョンに Connection Monitor リソースを作成する。
Connection Monitor はオンプレミスと Azure リージョン間のレイテンシ・パケット損失を継続的に測定する標準機能で、エージェント (Network Watcher 拡張機能/Azure Monitor エージェント) と組み合わせ既存の West US 2 の Network Watcher 配下に作成すれば最小の手間で要件を満たせます。
解説: Network Watcher の Connection Monitor では、Azure VM・スケール セットや Arc 対応オンプレミス ホストをソースおよびターゲットとしてプローブを送信し、RTT (ラウンドトリップ時間) やパケット損失を Azure Monitor メトリック/Log Analytics に出力できます。テスト グループには複数のソース・宛先・テスト構成を含められ、1 つの接続モニターでシアトルから West US 2、East US 2 双方への計測を同時にカバーできます。すでに West US 2 に Network Watcher が存在するため、その配下に Connection Monitor を作成し、Arc 対応オンプレミス ホストや各リージョンの VM をエンドポイントとして構成すれば、追加リージョンに Network Watcher を作成する必要はなく管理オーバーヘッドを最小化できます。
各選択肢の検討:
  • Get-AzNetworkWatcherConnectionMonitor: 既存の接続モニター情報を取得する読み取り専用コマンドで、まだ Connection Monitor を作成していない段階では役に立たない。
  • Get-AzNetworkWatcherReachabilityProvidersList: ISP 別の到達性レポート用コマンドであり、リージョン間レイテンシの継続的測定には不向き。
  • East US 2 リージョンに Network Watcher リソースを作成する: Network Watcher は通常サブスクリプションごとに自動作成されており、新規作成は不要かつ管理オーバーヘッドの増加につながる。Connection Monitor は単一の Network Watcher から複数リージョン宛にプローブできる。
  • West US 2 リージョンに Connection Monitor リソースを作成する: 既存の Network Watcher を活用し、オンプレミスから両 Azure リージョンへのレイテンシを 1 リソースで継続的に取得できる最小構成。
参考: Microsoft Learn
接続モニターの概要
Azure portal を使用した接続モニターの作成
この問題のページを開く →
問題 6- 仮想ネットワークに接続されたリソースは fabrikam.com の DNS 名を解決できる - Server1 は…Azure サービスへのプライベート アクセスの設計・実装
問題
あなたは fabrikam.com というプライマリ DNS ゾーンをホストする Server1 というオンプレミス DNS サーバーを所有しています。 Azure サブスクリプションには次のリソースがあります。 [リソース一覧] | 名前 | 種類 | 説明 | | VNet1 | 仮想ネットワーク | US West リージョン | | VNet2 | 仮想ネットワーク | US West リージョン | | VNet3 | 仮想ネットワーク | West Europe リージョン | | VNet4 | 仮想ネットワーク | West Europe リージョン | | contoso.com | Azure Private DNS ゾーン | West Europe にあり、VNet1、VNet2、VNet3、VNet4 にリンク済み | オンプレミス ネットワークのユーザーは S2S VPN ですべての仮想ネットワークのリソースにアクセスします。 次の要件を満たす Azure DNS Private Resolver ソリューションをデプロイする必要があります。 - 仮想ネットワークに接続されたリソースは fabrikam.com の DNS 名を解決できる - Server1 は contoso.com のリソースの DNS 名を解決できる - コストと管理オーバーヘッドを最小化する デプロイすべきリゾルバーの最小数はいくつですか?

選択肢と解説

  • 1
    1
  • ✓
    2
  • 3
    3
  • 4
    4

解説

正解: 2
Azure DNS Private Resolver は 1 つのリージョン (および 1 つの仮想ネットワーク) にしか配置できないため、US West と West Europe それぞれに 1 つずつ、合計 2 つのリゾルバーが必要です。
解説: Azure DNS Private Resolver は単一の仮想ネットワーク内にプロビジョニングするリージョナル リソースであり、同一リージョン内の複数の仮想ネットワークは DNS 転送ルールセットのリンクにより 1 つのリゾルバーで共有できます。一方、リゾルバーは別リージョンの仮想ネットワークにルールセットをリンクできないため、リージョンごとに 1 つのリゾルバーが必要です。本問では仮想ネットワークが US West (VNet1, VNet2) と West Europe (VNet3, VNet4) の 2 リージョンに分散しており、各リージョンに 1 つのリゾルバー (受信エンドポイント + 送信エンドポイント + ルールセット) を配置することで、すべての VNet から fabrikam.com への送信転送 (出力エンドポイント + ルールセット → Server1) と、オンプレミスから contoso.com への受信解決 (受信エンドポイント) を最小コストで実現できます。
各選択肢の検討:
  • 1: 単一のリゾルバーでは別リージョンの仮想ネットワークをカバーできず、West Europe または US West のいずれかが解決できなくなる。
  • 2: 各リージョンに 1 つずつ配置することで、すべての VNet を最小コストでカバーでき、要件を満たす最適解。
  • 3: 3 つ以上配置しても要件は満たせるがコストと管理が増加し、最小コストの要件に反する。
  • 4: 仮想ネットワーク毎に 1 つ配置する必要はなく、同一リージョン内ではルールセット リンクで共有できるため過剰。
参考: Microsoft Learn
Azure DNS Private Resolver の概要
Azure DNS Private Resolver エンドポイントとルールセット
この問題のページを開く →
問題 7- VM1 は自分のパブリック IP アドレスでインターネットにアクセスする - VM2 は自分のパブリック IP アド…コア ネットワーク インフラの設計・実装
問題
あなたは次のリソースを含む Azure サブスクリプションを所有しています。 [リソース一覧] | 名前 | 種類 | 説明 | | Vnet1 | 仮想ネットワーク | なし | | Subnet1 | 仮想サブネット | Vnet1 にホスト | | GatewaySubnet | 仮想サブネット | Vnet1 にホスト | | VM1 | 仮想マシン | Subnet1 に接続、Basic SKU のパブリック IP を所有 | | VM2 | 仮想マシン | Subnet2 に接続、Standard SKU のパブリック IP を所有 | あなたは Gateway1 という名前の Azure Virtual Network NAT ゲートウェイをデプロイする予定です。ソリューションは次の要件を満たす必要があります。 - VM1 は自分のパブリック IP アドレスでインターネットにアクセスする - VM2 は自分のパブリック IP アドレスでインターネットにアクセスする - 管理オーバーヘッドを最小化する Vnet1 に Gateway1 をデプロイできるようにするために必要なサブネットの最小数はいくつですか?

選択肢と解説

  • 1
    2
  • 2
    3
  • ✓
    4
  • 4
    5

解説

正解: 4
VM1 用サブネット (NAT ゲートウェイ不要)、VM2 用サブネット (NAT ゲートウェイ不要)、GatewaySubnet、NAT ゲートウェイを関連付ける専用サブネットの計 4 つが最小構成です。
解説: NAT ゲートウェイはサブネット単位で関連付け、関連付けたサブネット上の全リソースの送信フローを NAT ゲートウェイ経由に切り替えます。サブネット内の VM が引き続き自分のインスタンス レベル パブリック IP でインターネットにアクセスできる必要があるため、VM1 のサブネットと VM2 のサブネットには NAT ゲートウェイを関連付けてはいけません。さらに GatewaySubnet は VPN ゲートウェイ専用で NAT ゲートウェイは関連付けられないため、新たに NAT ゲートウェイ専用のサブネットを 1 つ作成し、(必要に応じてダミー リソースを置く形で) Gateway1 をそこに関連付ける構成が必要です。結果として Subnet1 (VM1)、Subnet2 (VM2)、GatewaySubnet、NAT ゲートウェイ用サブネットの計 4 サブネットが最少となります。
各選択肢の検討:
  • 2: VM1/VM2 用のサブネットだけでは GatewaySubnet と NAT ゲートウェイ用の専用サブネットが不足し、デプロイ要件を満たせない。
  • 3: GatewaySubnet を含めても、NAT ゲートウェイをアタッチする独立したサブネットが別途必要で、VM1/VM2 のパブリック IP 利用要件を維持できない。
  • 4: VM1 用、VM2 用、GatewaySubnet、NAT ゲートウェイ用の 4 サブネットで全要件を満たす最小構成。
  • 5: 4 サブネットで要件を満たせるため、5 サブネットは過剰となり管理オーバーヘッドの最小化に反する。
参考: Microsoft Learn
Azure NAT Gateway とは
チュートリアル: NAT ゲートウェイを作成する
この問題のページを開く →
問題 8AF1 をデプロイできる仮想ネットワークはどれですか?ネットワークのセキュリティ保護と監視
問題
あなたは次の仮想ネットワークを含む Azure サブスクリプションを所有しています。 [仮想ネットワーク一覧] | 名前 | リソース グループ | ロケーション | | Vnet1 | RG1 | West US | | Vnet2 | RG1 | Central US | | Vnet3 | RG2 | Central US | | Vnet4 | RG2 | West US | | Vnet5 | RG3 | East US | あなたは West US リージョンの RG1 に AF1 という Azure Firewall をデプロイする予定です。 AF1 をデプロイできる仮想ネットワークはどれですか?

選択肢と解説

  • 1
    Vnet1 と Vnet4 のみ
  • 2
    Vnet1、Vnet2、Vnet3、Vnet4 のすべて
  • ✓
    Vnet1 のみ
  • 4
    Vnet1 と Vnet2 のみ
  • 5
    Vnet1、Vnet2、Vnet4 のみ

解説

正解: Vnet1 のみ
Azure Firewall は同一リージョン・同一リソース グループの仮想ネットワークにのみデプロイできるため、West US の RG1 に作成する AF1 は RG1 かつ West US にある Vnet1 のみが対象になります。
解説: Azure Firewall リソースは、ファイアウォール本体と AzureFirewallSubnet を持つ仮想ネットワークが同じリージョンに存在し、かつ同じリソース グループに属している必要があります。AF1 は West US リージョン・RG1 にデプロイされるため、West US 以外にある仮想ネットワーク (Vnet2, Vnet3, Vnet5) と、RG1 以外にある仮想ネットワーク (Vnet3, Vnet4, Vnet5) は対象外です。両方の条件を満たすのは Vnet1 (West US / RG1) だけです。Vnet4 は West US にあるものの RG2 のため不可となります。なお、リソース グループの制約は仮想ネットワーク ゲートウェイなどでも同様で、ピアリングや UDR を用いれば他リソース グループ・他リージョンの VNet からファイアウォール経由でトラフィックを通すことは可能ですが、ファイアウォール リソース自体の配置先としては Vnet1 のみが許容されます。
各選択肢の検討:
  • Vnet1 と Vnet4 のみ: Vnet4 は West US でリージョンは一致するが、リソース グループが RG2 のため AF1 を直接デプロイできない。
  • Vnet1、Vnet2、Vnet3、Vnet4 のすべて: Vnet2/Vnet3 は Central US リージョンであり、リージョン要件を満たさない。
  • Vnet1 のみ: リージョン (West US) とリソース グループ (RG1) の両条件を満たす唯一の VNet で、本問の正解。
  • Vnet1 と Vnet2 のみ: Vnet2 は RG1 だが Central US リージョンのため、West US の AF1 をデプロイできない。
  • Vnet1、Vnet2、Vnet4 のみ: 上記同様、リージョンまたはリソース グループの要件を満たさない VNet が含まれており不適切。
参考: Microsoft Learn
Azure Firewall とは
Azure Firewall の FAQ
この問題のページを開く →
問題 9[回答エリア (リソース グループごとに次の中から 1 つを選択)] RG1: Contributor / Networ…ネットワークのセキュリティ保護と監視
問題
あなたは次のリソースとユーザー User1 を含む Azure サブスクリプションを所有しています。 [リソース一覧] | 名前 | 説明 | | Policy1 | Azure Firewall ポリシー | | RG1 | 複数のリソースを含むリソース グループ | | RG2 | 複数のリソースを含むリソース グループ | | FW1 | RG1 にある Azure Firewall インスタンスで、RG2 および RG3 のリソースを保護する | Policy1 は RG2 に配置されています。 Azure Firewall Manager を使用して User1 が Policy1 を FW1 に関連付けられるようにする必要があります。最小特権の原則に従う必要があります。 各リソース グループにおいて User1 に割り当てるロールはどれですか? 解答するには、解答エリアで適切なオプションを選択してください。 注: 各正答に 1 ポイントが与えられます。 [回答エリア (リソース グループごとに次の中から 1 つを選択)] RG1: Contributor / Network Contributor / Owner / Reader RG2: Contributor / Network Contributor / Owner / Reader 次の選択肢の中から正しい組み合わせを 1 つ選んでください。

選択肢と解説

  • ✓
    RG1: Network Contributor、RG2: Network Contributor
  • 2
    RG1: Network Contributor、RG2: Reader
  • 3
    RG1: Reader、RG2: Network Contributor
  • 4
    RG1: Contributor、RG2: Reader
  • 5
    RG1: Owner、RG2: Network Contributor

解説

正解: RG1: Network Contributor、RG2: Network Contributor
Azure Firewall Manager でファイアウォールにポリシーを関連付けるには、ファイアウォール側 (FW1 → RG1) と適用するポリシー側 (Policy1 → RG2) の双方で書き込み権限が必要で、最小特権を満たすのは Network Contributor です。
解説: Azure Firewall とそのファイアウォール ポリシーは Microsoft.Network プロバイダーのリソースであり、ポリシーの関連付けには Microsoft.Network/azureFirewalls/write と Microsoft.Network/firewallPolicies/join/action (および read) のアクションが必要です。これらのアクションは組み込みロール Network Contributor に含まれており、ストレージや RBAC 権限を含む Contributor/Owner より権限スコープが狭く最小特権の原則に合致します。FW1 が配置された RG1 ではファイアウォールへの書き込み、Policy1 が配置された RG2 ではポリシーの読み取りおよび結合操作が必要となるため、両方のリソース グループに Network Contributor を割り当てるのが最小構成です。Reader はオブジェクトの読み取りしか許可せず、ポリシーの関連付け書き込みができないため不適切です。
各選択肢の検討:
  • RG1: Network Contributor、RG2: Network Contributor: ファイアウォール側のポリシー関連付け書き込みと、ポリシー側の join 権限の両方を満たし、最小特権の原則を遵守する正しい組合せ。
  • RG1: Network Contributor、RG2: Reader: RG2 が Reader のみではポリシーの join/関連付け操作が許可されず、Firewall Manager からの関連付けに失敗する。
  • RG1: Reader、RG2: Network Contributor: RG1 で FW1 への書き込み権限がないため、ポリシーをファイアウォールに割り当てる操作自体が拒否される。
  • RG1: Contributor、RG2: Reader: Contributor は最小特権を超えるうえ、RG2 が Reader のままでは関連付け不可。
  • RG1: Owner、RG2: Network Contributor: Owner は権限が広すぎ最小特権に反するため不適切。
参考: Microsoft Learn
Azure Firewall Manager の概要
Network Contributor ロール
この問題のページを開く →
問題 10次のうち、正しい順序の選択肢を選んでください。ネットワークのセキュリティ保護と監視
問題
ドラッグ アンド ドロップ あなたのオンプレミス ネットワークには contoso.com という Active Directory Domain Services ドメインがあり、内部証明機関 (CA) が配置されています。 Azure サブスクリプションに AppGwy1 という Azure Application Gateway をデプロイし、次の操作を実施しました。 - HTTP リスナーを構成した - リスナーにルーティング規則を関連付けた AppGwy1 で、contoso.com に属するドメイン参加コンピューターからのリクエストに対して相互認証 (mTLS) を実行できるよう構成する必要があります。 次のうち、どの 4 つのアクションをどの順序で実行すべきですか? 解答するには、適切なアクションをアクション一覧から解答エリアに移動し、正しい順番に並べてください。 [アクション一覧] A. AppGwy1 でフロントエンド IP 構成を作成する。 B. AppGwy1 で SSL プロファイルを作成する。 C. AppGwy1 で HTTP リスナーを追加し、リスナーを SSL プロファイルに関連付ける。 D. AppGwy1 でルーティング規則を作成する。 E. オンプレミスのコンピューターから AppGwy1 に証明書をアップロードする。 次のうち、正しい順序の選択肢を選んでください。

選択肢と解説

  • ✓
    E → B → C → D
  • 2
    A → B → C → D
  • 3
    E → A → C → B
  • 4
    B → E → C → D
  • 5
    A → E → C → B

解説

正解: E → B → C → D
クライアント CA 証明書を Application Gateway にアップロードし、その証明書を含む SSL プロファイルを作成し、リスナーに割り当ててからルーティング規則を作成するのが mTLS (相互認証) の正規の構成手順です。
解説: Application Gateway で相互認証を構成するには、まずクライアント証明書の検証に用いる「信頼されたクライアント CA 証明書チェーン」を Application Gateway にアップロードします (E)。次に、その CA 証明書を含む SSL プロファイル (クライアント認証構成) を作成し (B)、HTTPS リスナーを追加してこの SSL プロファイルを関連付けます (C)。最後に、リスナーで受信したトラフィックをバックエンド プールに送るためのルーティング規則を作成します (D)。フロントエンド IP 構成はゲートウェイ作成時にすでに存在するため新規作成は不要で、HTTP リスナーは mTLS では使用しません (HTTPS が必須)。したがって順序は E → B → C → D となります。
各選択肢の検討:
  • E → B → C → D: 証明書アップロード → SSL プロファイル作成 → リスナー関連付け → ルーティング規則作成、という公式手順に沿った正しい順序。
  • A → B → C → D: フロントエンド IP は既に存在するため新規作成は不要で、証明書アップロード手順 (E) が抜けているため mTLS を構成できない。
  • E → A → C → B: フロントエンド IP の新規作成は不要、SSL プロファイル作成前にリスナーを関連付けることはできないため順序が誤り。
  • B → E → C → D: SSL プロファイル作成時にクライアント CA 証明書が必要なので、証明書を先にアップロードしておく必要があり、順序が逆。
  • A → E → C → B: SSL プロファイル作成より先にリスナー関連付けはできず、フロントエンド IP の新規作成も不要。
参考: Microsoft Learn
Application Gateway の相互認証の概要
ポータルで相互認証を構成する
この問題のページを開く →
問題 11[記述] 1. Subnet2 には ASP1 にデプロイされた App Service アプリのみが含まれる 2. a…Azure サービスへのプライベート アクセスの設計・実装
問題
ホットスポット あなたは as12 という Azure App Service アプリを所有しています。as12 は次のように構成されています。 [App Service: as12] - リソース グループ: RG1 - 状態: Running - 場所: North Europe - App Service プラン: ASP1 (P1v2:1) - URL: https://as12.azurewebsites.net [VNet 統合 (as12)] - VNet 名: Vnet1 - 場所: North Europe - VNet アドレス空間: 10.100.0.0 ~ 10.100.255.255 - サブネット名: Subnet2 - サブネット アドレス空間: 10.100.2.0 ~ 10.100.2.255 [as12 のプライベート エンドポイント接続] - 結果なし (プライベート エンドポイントは構成されていない) 以下の各記述について、正しい場合は はい、そうでない場合は いいえ を選んでください。 注: 各正答に 1 ポイントが与えられます。 [記述] 1. Subnet2 には ASP1 にデプロイされた App Service アプリのみが含まれる 2. as12 はネットワーク通信に Subnet2 の IP アドレスを使用する 3. Vnet1 のコンピューターが as12 に接続するときはプライベート IP アドレスに接続する 次の選択肢の中から、上記 3 つの記述に対する正しい組み合わせを 1 つ選んでください (順番は 1, 2, 3)。

選択肢と解説

  • ✓
    はい / はい / いいえ
  • 2
    はい / はい / はい
  • 3
    いいえ / はい / いいえ
  • 4
    はい / いいえ / いいえ
  • 5
    いいえ / はい / はい

解説

正解: 1. はい / 2. はい / 3. いいえ
VNet 統合用のサブネットは App Service に委任 (Microsoft.Web/serverFarms) され他リソースは入れられず、送信通信はサブネット内のプライベート IP を使用しますが、受信トラフィックはプライベート エンドポイントが構成されていないため公開エンドポイントを介してしか到達できません。
解説: App Service の VNet 統合では、対象のサブネットは Microsoft.Web/serverFarms に委任され、その App Service プラン (ASP1) に属するアプリの送信トラフィック用としてのみ使用できます。同じサブネットには他のサービスや VM を配置できず、Multi-Plan Subnet Join (MPSJ) を利用しない限り別の App Service プランも参加できません。as12 は Subnet2 内の IP アドレスを 1 つ割り当てられ、それを送信通信のソースとして使用します (WEBSITE_PRIVATE_IP で公開)。一方で VNet 統合はあくまで「送信」用機能であり、受信プライベート アクセスは提供しません。プライベート エンドポイント接続が空である本問の構成では、Vnet1 内の VM が as12 に接続する際も DNS は引き続きパブリック (azurewebsites.net) を解決し、パブリック エンドポイント経由で接続されます。よって 1=はい、2=はい、3=いいえ となります。
各選択肢の検討:
  • はい / はい / いいえ: 委任サブネットの制約、VNet 統合の送信元 IP、プライベート エンドポイント未構成時の挙動という 3 点すべてに合致する正答。
  • はい / はい / はい: プライベート エンドポイントが存在しないため Vnet1 から as12 への接続はパブリック IP 経由となり、3 番目を「はい」とするのは誤り。
  • いいえ / はい / いいえ: VNet 統合用サブネットには ASP1 のアプリのみ配置可能なため、1 番目の「いいえ」が誤り。
  • はい / いいえ / いいえ: VNet 統合により as12 の送信トラフィックは Subnet2 の IP を使用するため、2 番目の「いいえ」が誤り。
  • いいえ / はい / はい: 1 番目と 3 番目の評価がともに誤り。
参考: Microsoft Learn
Azure App Service の VNet 統合
App Service のプライベート エンドポイント
この問題のページを開く →
問題 12仮想ネットワーク数とサブネット数の組み合わせとして正しいものはどれですか?コア ネットワーク インフラの設計・実装
問題
ホットスポット あなたは次の種類のリソースを単一の Azure リージョンに含む Azure ソリューションを計画しています。 - 仮想マシン - Azure App Service - 仮想ネットワーク ゲートウェイ - Azure SQL Managed Instance App Service と SQL Managed Instance は仮想ネットワーク内にリソースを作成するために委任 (delegated) されます。 このソリューションに必要な仮想ネットワーク数とサブネット数を特定する必要があります。仮想ネットワーク間のデータ転送コストは最小化しなければなりません。 仮想ネットワーク数とサブネット数の組み合わせとして正しいものはどれですか? 注: 各正答に 1 ポイントが与えられます。

選択肢と解説

  • ✓
    仮想ネットワーク: 1、サブネット: 4
  • 2
    仮想ネットワーク: 1、サブネット: 3
  • 3
    仮想ネットワーク: 2、サブネット: 4
  • 4
    仮想ネットワーク: 4、サブネット: 4
  • 5
    仮想ネットワーク: 1、サブネット: 2

解説

正解: 仮想ネットワーク 1、サブネット 4
VNet 間のデータ転送コストを発生させないためにすべてのリソースを 1 つの VNet に集約し、VM 用・App Service 委任用・SQL Managed Instance 委任用・GatewaySubnet の 4 サブネットに分離する構成が最適です。
解説: 同じ仮想ネットワーク内の通信はリージョン内・同一 VNet として課金が発生せず、ピアリングを跨ぐとイングレス/エグレスに課金されるため、コスト最小化の観点では 1 つの VNet にまとめるのが正解です。一方、サブネットは用途ごとに分離する必要があります。仮想ネットワーク ゲートウェイは「GatewaySubnet」という名前の専用サブネットが必須です。App Service の VNet 統合は Microsoft.Web/serverFarms へ委任した専用サブネットを要求します。SQL Managed Instance は Microsoft.Sql/managedInstances へ委任した専用サブネットが必須で、他リソースとの共有はできません。仮想マシンも上記委任サブネットには配置できないため独自サブネットが必要です。よって 1 VNet + 4 サブネット (VM、App Service 委任、SQL MI 委任、GatewaySubnet) が最小構成となります。
各選択肢の検討:
  • 仮想ネットワーク: 1、サブネット: 4: 委任要件と GatewaySubnet 要件を満たしつつ単一 VNet で完結し、データ転送コストを最小化する最適解。
  • 仮想ネットワーク: 1、サブネット: 3: App Service 委任、SQL MI 委任、GatewaySubnet、VM 用のうちいずれかを共有できないため不足する。
  • 仮想ネットワーク: 2、サブネット: 4: VNet を 2 つに分けると VNet ピアリング経由のトラフィック課金が発生し、コスト要件に反する。
  • 仮想ネットワーク: 4、サブネット: 4: リソースごとに VNet を分けるとピアリング料金とイングレス/エグレス料金が増大し、要件を満たさない。
  • 仮想ネットワーク: 1、サブネット: 2: 委任要件と GatewaySubnet 要件を満たせず、SQL MI や App Service VNet 統合のデプロイができない。
参考: Microsoft Learn
サブネット委任の概要
SQL Managed Instance ネットワーク アーキテクチャ
App Service VNet 統合
この問題のページを開く →
問題 13最初に何を構成すべきですか?Azure サービスへのプライベート アクセスの設計・実装
問題
あなたは次のリソースを含む Azure サブスクリプションを所有しています。 [リソース一覧] | 名前 | 説明 | | VNet1 | Subnet1 という名前のサブネットを 1 つ含む仮想ネットワーク | | Endpoint1 | Subnet1 に接続され、App1 という Azure App Service Web アプリにリンクされたプライベート エンドポイント | | storage1 | Endpoint1 経由でのみアクセスできるストレージ アカウント | | NSG1 | Subnet1 にリンクされたネットワーク セキュリティ グループ | NSG1 を使って storage1 へのアクセスを制御する必要があります。 最初に何を構成すべきですか?

選択肢と解説

  • 1
    Azure Private Link サービス
  • 2
    アプリケーション セキュリティ グループ
  • ✓
    プライベート エンドポイント ネットワーク ポリシー
  • 4
    サービス エンドポイント

解説

正解: プライベート エンドポイント ネットワーク ポリシー
既定ではプライベート エンドポイントを含むサブネットには NSG のフィルタリングが適用されないため、まず該当サブネットでプライベート エンドポイント ネットワーク ポリシーを有効化する必要があります。
解説: プライベート エンドポイントを介したトラフィックは、サブネットに関連付けられた NSG では既定でフィルタリングされません。これを変更するには、対象のサブネットで「Private endpoint network policies (privateEndpointNetworkPolicies)」を有効化する必要があります。有効化後は、NSG ルールの送信先 (Destination) としてプライベート エンドポイントの IP アドレスやサブネット範囲を指定して受信トラフィックを許可/拒否できるようになり、storage1 へのアクセス制御を NSG で行えるようになります。サービス エンドポイントは別のプライベート アクセス方式 (パブリック IP 経由) であり、プライベート エンドポイント環境では不要で、Azure Private Link サービスはサービス公開側 (プロバイダー側) の概念のため利用シーンが異なります。アプリケーション セキュリティ グループ自体は NSG ルール対象の整理に役立つものの、ネットワーク ポリシーの有効化が前提です。
各選択肢の検討:
  • Azure Private Link サービス: 自社サービスをプライベート公開する側で使用するもので、消費側でストレージへの NSG 制御を有効化する手段ではない。
  • アプリケーション セキュリティ グループ: NSG ルールのグルーピング機能であり、プライベート エンドポイントへの NSG 適用を有効化する前提条件は別途必要。
  • プライベート エンドポイント ネットワーク ポリシー: 有効化することで NSG/UDR をプライベート エンドポイントに適用できるようになる正規の方法であり、本問の正解。
  • サービス エンドポイント: VNet サービス エンドポイントは別方式のアクセス手段で、プライベート エンドポイント経由トラフィックの NSG 適用には関係しない。
参考: Microsoft Learn
プライベート エンドポイント ネットワーク ポリシーを管理する
Azure プライベート エンドポイントの概要
この問題のページを開く →
問題 14[回答エリア] HubVNet について: a) ユーザー定義ルート (UDR) を構成する b) Azure Rout…ハイブリッド ネットワークの設計・実装・管理
問題
ホットスポット ケース スタディ (Proseware, Inc.) Proseware, Inc. はニューヨーク本社とサンフランシスコ支社を持つ金融サービス企業です。オンプレミスには corp.proseware.com の AD DS フォレストがあり、proseware.com の Microsoft Entra テナントと同期しています。Azure サブスクリプションは proseware.com にリンクされ、内部 CA が存在します。 [ネットワーク インフラ] | 名前 | 種類 | 場所 | 説明 | | NYCNet | オンプレミス ネットワーク | ニューヨーク | アドレス空間 192.168.0.0/22 | | SFONet | オンプレミス ネットワーク | サンフランシスコ | アドレス空間 192.168.100.0/22 | | NYCDNS1 | サーバー | ニューヨーク | Windows Server 2019 で IP は 192.168.0.100 | NYCNet は ExpressRoute 回線で Azure に接続、SFONet は S2S VPN で Azure に接続します。 [Azure リソース] | 名前 | 種類 | 場所 | 説明 | | HubVNet | 仮想ネットワーク | East US | 10.0.0.0/20、SpokeVNet とピアリング | | SpokeVNet | 仮想ネットワーク | East US | 10.0.16.0/20、HubVNet とピアリング | | VPNGW1 | 仮想ネットワーク ゲートウェイ | HubVNet | Generation2、VpnGw3 SKU、Active-Passive、既定 ASN、SFONet 接続 | | SUBNET-PE | サブネット | HubVNet | プライベート エンドポイント用 | | SUBNET-JUMPHOSTS | サブネット | HubVNet | ジャンプホスト用 | | SUBNET-APPGW1 | サブネット | SpokeVNet | APPGW1 という Application Gateway を含む | Application Gateway APPGW1 (WAF v2、SpokeVNet)、NSG/WAF ポリシーが構成され、Azure Front Door Standard プロファイル FD1 が APPGW1 を origin に持ちます。HubVNet は ERGW1 を介して NYCNet と ExpressRoute 接続しています。 [計画中の変更 (抜粋)] - HubVNet に PRDNS1 (Private DNS Resolver) をデプロイし、SpokeVNet にリンク - DNS フォワーディング ルールセット DNSRS1 を作成し PRDNS1 に関連付け - Azure Virtual Network Manager をデプロイし、オンプレミスから SUBNET-JUMPHOSTS への TCP/3389 を許可、Internet → SpokeVNet の TCP/80 をブロックなどのルールを実装 - Virtual Network Manager のルールを NSG より優先 - HubVNet に NVA1/NVA2 をデプロイ - HubVNet に Gateway Load Balancer LBGW1 をデプロイし、LBS1 からの TCP 443/1433/1434 を NVA1/NVA2 で検査 - App2 への全トラフィックを FD1 経由 [接続性要件 (抜粋)] - Azure Virtual Network Manager デプロイの複雑さを最小化 - NYCNet と SFONet 間のトラフィックを ExpressRoute と S2S VPN 経由でルーティング - Windows 11 リモート ユーザーが proseware.com 資格情報で HubVNet に P2S VPN 接続 [セキュリティ要件 (抜粋)] - 可能な限り内部 CA を使用 - APPGW1 経由の通信はエンドツーエンド暗号化 - ユーザーから Azure ホスト アプリへの通信はエンドツーエンド暗号化 - app2.proseware.com への受信は FD1 経由 - NYCNet からはプライベート エンドポイントを使う Azure サービスにアクセス不可 - HubVNet/SpokeVNet の VM はプライベート エンドポイントを使う Azure サービスにアクセス可 [一般要件 (抜粋)] - プラットフォーム管理リソース用 IP 空間最小化 - SpokeVNet から azure.proseware.com と corp.proseware.com を PRDNS1 で名前解決 - 可能な限り管理オーバーヘッド最小化 NYCNet と SFONet 間の接続性を、接続性要件に従って構成する必要があります。 何を行うべきですか? 解答するには、解答エリアで適切なオプションを選んでください。 注: 各正答に 1 ポイントが与えられます。 [回答エリア] HubVNet について: a) ユーザー定義ルート (UDR) を構成する b) Azure Route Server をデプロイする c) Azure Virtual Network Manager 接続構成を実装する VPNGW1 について: a) ASN 番号を変更する b) Active-Active モードを構成する c) SKU をリサイズする 次のうち、正しい組み合わせを 1 つ選んでください。

選択肢と解説

  • ✓
    HubVNet: Azure Route Server をデプロイする、VPNGW1: Active-Active モードを構成する
  • 2
    HubVNet: ユーザー定義ルート (UDR) を構成する、VPNGW1: SKU をリサイズする
  • 3
    HubVNet: Azure Route Server をデプロイする、VPNGW1: ASN 番号を変更する
  • 4
    HubVNet: Azure Virtual Network Manager 接続構成を実装する、VPNGW1: Active-Active モードを構成する
  • 5
    HubVNet: ユーザー定義ルート (UDR) を構成する、VPNGW1: ASN 番号を変更する

解説

正解: HubVNet に Azure Route Server をデプロイし、VPNGW1 を Active-Active モードに構成する。
ExpressRoute と VPN ゲートウェイ間で経路情報を交換しトランジット ルーティングを成立させるには Route Server が必要で、VPN ゲートウェイ側は Route Server と BGP 連携できる Active-Active 構成が前提となります。
解説: 既定では同一 HubVNet 上に ExpressRoute ゲートウェイと VPN ゲートウェイを並べても、ExpressRoute と VPN 間で経路情報は再配布されません。NYCNet (ExpressRoute) と SFONet (S2S VPN) 間のトランジット ルーティングを実現するには、HubVNet に Azure Route Server をデプロイし、ExpressRoute ゲートウェイと VPN ゲートウェイの双方で「Branch-to-branch」(ExpressRoute と VPN ゲートウェイ間でのルート交換) を有効にして、両ゲートウェイのプレフィックスを相互に学習させる必要があります。Route Server と BGP セッションを確立する VPN ゲートウェイはアクティブ/アクティブで動作している必要があり、提示の VPNGW1 はアクティブ/パッシブのため Active-Active へ変更します (VpnGw3 のままで対応可能)。UDR の追加や ASN 変更だけではダイナミック ルーティングを介した相互接続要件 (管理オーバーヘッド最小化) を満たせません。
各選択肢の検討:
  • HubVNet: Azure Route Server、VPNGW1: Active-Active: ER と VPN の経路交換を BGP で自動化し、最小の管理コストで NYCNet ⇔ SFONet 接続を実現する正しい組合せ。
  • HubVNet: UDR、VPNGW1: SKU リサイズ: 静的ルート運用と SKU 変更は ExpressRoute と VPN の動的ルート再配布要件を満たさない。
  • HubVNet: Azure Route Server、VPNGW1: ASN 変更: ASN を変えても Active-Passive のままでは Route Server と BGP セッションを張れず、トランジットが成立しない。
  • HubVNet: Azure Virtual Network Manager 接続構成、VPNGW1: Active-Active: Virtual Network Manager は VNet 間接続のための機能であり、ExpressRoute と VPN の橋渡しは行えない。
  • HubVNet: UDR、VPNGW1: ASN 変更: ASN 変更も UDR も BGP に基づく ER ⇔ VPN 経路交換を実現できない。
参考: Microsoft Learn
Route Server による ExpressRoute と VPN の相互接続
アクティブ/アクティブ VPN ゲートウェイを構成する
この問題のページを開く →
問題 15最初に何を行うべきですか?コア ネットワーク インフラの設計・実装
問題
あなたは VM1 という仮想マシン、NIC1 というネットワーク インターフェイス、IP1 という Basic SKU のパブリック IP アドレスを含む Azure サブスクリプションを所有しています。NIC1 は VM1 に接続され、IP1 は NIC1 に関連付けられています。 IP1 を Standard SKU にアップグレードする必要があります。 最初に何を行うべきですか?

選択肢と解説

  • 1
    VM1 用に新しい NIC を作成する。
  • ✓
    IP1 を NIC1 から関連付け解除する。
  • 3
    NIC1 を VM1 から切り離す。
  • 4
    VM1 を停止する。

解説

正解: IP1 を NIC1 から関連付け解除する。
Basic SKU のパブリック IP は、どのリソースにもアタッチされていない状態でなければ Standard SKU にアップグレードできないため、最初に NIC1 との関連付けを解除する必要があります。
解説: Azure ポータル、CLI、PowerShell のいずれでパブリック IP の SKU を Basic → Standard へアップグレードする場合でも、対象の Public IP が NIC、ロード バランサー、その他リソースに関連付けられていないことが前提条件です。関連付けがある状態ではアップグレード操作が拒否されます。さらにアップグレード対象は静的割り当ての Basic Public IP である必要があるため、必要なら割り当て方法も静的に変更します。VM 自体の停止や NIC の付け外しは必須ではなく、Public IP を NIC1 から外すだけで条件を満たせます。
各選択肢の検討:
  • VM1 用に新しい NIC を作成する: 新しい NIC を作成しても元の IP1 が NIC1 に紐付いたままなのでアップグレード不可。
  • IP1 を NIC1 から関連付け解除する: アップグレードに必要な「リソース未割り当て」状態を作る唯一の操作で正解。
  • NIC1 を VM1 から切り離す: NIC を VM から外しても IP1 と NIC1 の関連付けは残るためアップグレードできない。
  • VM1 を停止する: VM 停止だけでは Public IP が NIC1 に紐付いた状態は変わらず、アップグレード条件を満たさない。
参考: Microsoft Learn
パブリック IP アドレスをアップグレードする
VM にアタッチされたパブリック IP のアップグレード
この問題のページを開く →

AZ-700 対策のハンズオンラボ

実際の Azure・AWS 環境を払い出して手を動かせます。問題演習と組み合わせると理解が定着します。

NSG と ASG で多層ネットワーク制御を構成する
intermediate・約 55 分
VNet ピアリングで 2 つの仮想ネットワークを接続する
beginner・約 50 分
ルートテーブル(UDR)でサブネットの経路を制御する
intermediate・約 50 分
Azure DNS ゾーンでレコードを管理する
beginner・約 45 分
Traffic Manager で DNS ベースの負荷分散を構成する
intermediate・約 50 分

AZ-700 模擬問題集についてよくある質問

AZ-700 の練習問題は無料で試せますか?

はい。AZ-700 は先頭 15 問を会員登録なしで、正解と全選択肢の解説つきでご覧いただけます。16 問目以降は模試プラン(月額 ¥980)または Pro プラン(月額 ¥4,980)でご利用ください。

問題は何問ありますか?

AZ-700 は本番形式の練習テスト 2 回・全 160 問を収録しています。全問に解説が付いています。

解説は付いていますか?

全ての問題に、正解の理由と各選択肢がなぜ誤りなのかの解説を付けています。ドメイン(出題分野)別の正答率も受験後に確認できます。

AZ-700 のハンズオン学習もできますか?

はい。AZ-700 に対応するハンズオンラボを 5 件ご用意しています。実際の Azure・AWS 環境を払い出して手を動かしながら学習できます。