📋 AZ-700 拡張プロジェクト Phase 1 サンプル (VARONTO 様レビュー用)
CloudCamp の AZ-700 拡張プロジェクト Phase 1 のサンプル 10 問 + yesno シリーズ 3 問です。ブラウザでの実際のレンダリング状態をご確認ください。
形式: hsdd (空欄ドロップダウン) 3 / drag_order 2 / single_choice 3 / multi_choice 1 / yesno シリーズ 3
🔵 hotspot_dropdown (コード/構成 空欄補完) 3 問
AZ-700-SEC#1 (pid=29612)
VM の RDP (3389) を会社のオフィス サブネット 203.0.113.0/24 からのみ許可する NSG インバウンド ルールを PowerShell で作成しています。各空欄に最適な選択肢を選んでください。
$nsg = ____①____ -ResourceGroupName "RG1" -Name "NSG1" $nsg | ____②____ `` -Name "Allow-RDP-Office" `` -Description "RDP from office" `` -Access Allow `` -Protocol Tcp `` -Direction Inbound `` -Priority 100 `` -SourceAddressPrefix "203.0.113.0/24" `` -SourcePortRange * `` -DestinationAddressPrefix * `` -DestinationPortRange 3389 $nsg | ____④____
| ステートメント | 選択 |
|---|---|
① NSG を取得する Cmdlet 既存 NSG の取得は Get-AzNetworkSecurityGroup。 New- は新規作成用。 | |
② NSG にルールを追加する Cmdlet Add-AzNetworkSecurityRuleConfig は既存 NSG 構成にインメモリでルール追加。 Set- は変更用、ルール作成では Add-。 | |
④ 変更を Azure へ適用する Cmdlet (永続化) Add-AzNetworkSecurityRuleConfig はローカル変更のみ。Azure へ永続化するには Set-AzNetworkSecurityGroup でパイプラインを完結させる必要があります。 |
解説
【正解: Get → Add → Set】の理由
Azure PowerShell における NSG ルール追加の標準パターンは Get → Add → Set です。Add-AzNetworkSecurityRuleConfig はオブジェクト変更のみで、最後の Set-AzNetworkSecurityGroup がないと Azure 側に反映されません。これは Az モジュール全般の典型的な落とし穴です。
【参考】
AZ-700-CORE#1 (pid=29613)
異なるサブスクリプション同士の VNet 間で 双方向のピアリングを Azure CLI で構成します。Hub VNet と Spoke VNet を接続し、Hub 側からは Spoke の通信を許可し、双方の Gateway 経由のトランジットを有効化します。各空欄を完成させてください。
# Hub → Spoke 方向 az network vnet peering create `` --resource-group RG-Hub `` --name Hub-to-Spoke `` --vnet-name Hub-VNet `` --remote-vnet "/subscriptions/<sub_id>/resourceGroups/RG-Spoke/providers/Microsoft.Network/virtualNetworks/Spoke-VNet" `` --allow-vnet-access ____① `` --allow-forwarded-traffic ____② `` --allow-gateway-transit ____③ `` --use-remote-gateways false
| ステートメント | 選択 |
|---|---|
① --allow-vnet-access (Hub 側: Spoke からの通信を許可するか) ピアリングの基本機能。これを true にしないと VM 間通信が成立しない。 | |
② --allow-forwarded-traffic (NVA/Firewall 等で転送されたトラフィックを受け入れるか) Hub-Spoke 構成では Hub の Firewall/NVA 経由で Spoke 同士が通信するため true が必要。 | |
③ --allow-gateway-transit (Hub の VPN/ER Gateway を Spoke で利用させるか) — Hub 側の設定 Hub にゲートウェイがある場合、Hub 側で true にすることで Spoke がトランジット可能。 |
解説
【正解: true / true / true】の理由
Hub-Spoke ピアリングは「Hub → Spoke」と「Spoke → Hub」の双方向 2 本で構成し、Gateway Transit は「ゲートウェイを持つ側=Hub」が allow-gateway-transit=true、「使う側=Spoke」が use-remote-gateways=true という対の設定が必須です。
【参考】
AZ-700-APP#1 (pid=29614)
Application Gateway v2 を Bicep で定義しています。Web App (App Service) をバックエンドとし、TLS 終端 + HTTP/2 を有効化したい。各空欄を完成させてください。
resource appGw 'Microsoft.Network/applicationGateways@2024-05-01' = {
name: 'appgw1'
location: location
properties: {
sku: { name: '____①____', tier: '____①____', capacity: 2 }
enableHttp2: ____②____
sslPolicy: { policyType: 'Predefined', policyName: '____③____' }
backendAddressPools: [{ name: 'webBackend', properties: { backendAddresses: [
{ fqdn: 'mywebapp.azurewebsites.net' }
] } }]
}
}| ステートメント | 選択 |
|---|---|
① Application Gateway v2 の SKU 名称 (WAF 不要、TLS + L7 ルーティングのみ) WAF 機能が不要なら Standard_v2。WAF 必要なら WAF_v2。Standard は v1 で非推奨。 | |
② enableHttp2 (HTTP/2 を有効にする値) HTTP/2 を有効にする論理値。クライアント → AppGW 区間のみ対応 (バックエンド側は HTTP/1.1)。 | |
③ TLS Predefined Policy (2026 時点で TLS 1.2/1.3 を強制する最新版) 2026 年時点の最新は AppGwSslPolicy20220101 (TLS 1.2 + 1.3 強制)。20150501 は古く非推奨。 |
解説
【正解: Standard_v2 / true / AppGwSslPolicy20220101】の理由
Application Gateway v2 + App Service バックエンドの標準構成です。HTTP/2 はクライアント側のみ対応、TLS は Predefined Policy 20220101 が 2026 年時点の推奨で TLS 1.2/1.3 を強制します。App Service へのルーティングは IP ではなく FQDN を使う必要があります (App Service の IP は流動)。
【参考】
🟢 drag_order (設定手順 並び替え) 2 問
AZ-700-CONN#1 (pid=29615)
Azure 上に Site-to-Site VPN (Route-based, IKEv2) を構築します。次の作業を正しい順序に並び替えてください (オンプレ機器側の作業は除く)。
- 対象 VNet に GatewaySubnet (/27 推奨) を作成する
- Virtual Network Gateway (VpnGw1 等 SKU) をデプロイする (約 30 分かかる)
- オンプレ機器の Public IP + アドレス空間を持つ Local Network Gateway を作成する
- VNet Gateway と Local Gateway を結ぶ Connection リソース (IPsec/IKE 共有キー) を作成する
- Azure 側で Effective Routes を確認し、オンプレ機器側の設定と Public IP 一致を確認する
解説
【正しい順序】
- ステップ 1: 対象 VNet に GatewaySubnet (/27 推奨) を作成する
- ステップ 2: Virtual Network Gateway (VpnGw1 等 SKU) をデプロイする (約 30 分かかる)
- ステップ 3: オンプレ機器の Public IP + アドレス空間を持つ Local Network Gateway を作成する
- ステップ 4: VNet Gateway と Local Gateway を結ぶ Connection リソース (IPsec/IKE 共有キー) を作成する
- ステップ 5: Azure 側で Effective Routes を確認し、オンプレ機器側の設定と Public IP 一致を確認する
【各ステップの理由】
- ステップ 1 が最初の理由 (GatewaySubnet)
- GatewaySubnet は名前が固定 (変更不可) で、Virtual Network Gateway のデプロイに必須のサブネットです。Gateway は通常のサブネットには配置できず、必ず GatewaySubnet という名前のサブネットを必要とします。/27 以上 (16+ アドレス) が推奨されます (将来の Gateway スケールアップ時に余裕を持たせるため)。
- ステップ 2 の理由 (Gateway デプロイ = 約 30 分)
- Virtual Network Gateway のデプロイには約 30 分かかります。後続作業 (Local Gateway / Connection) はこのデプロイ完了を必要としないため、並行して進めると効率的です (時系列としては手順 2 → 3 → 4 で記述します)。
- ステップ 3 の理由 (Local Network Gateway)
- Local Network Gateway はオンプレ機器側の Public IP とアドレス空間を Azure に登録するメタデータ リソースです。実際の VPN トンネルではなく「相手側の定義」です。Gateway デプロイ完了を待つ必要はなく、並行作業可能です。
- ステップ 4 の理由 (Connection で結ぶ)
- Virtual Network Gateway (Azure 側) と Local Network Gateway (オンプレ側の定義) を Connection リソースで結びます。ここで IPsec/IKE 共有キー (PSK) を設定します。PSK はオンプレ機器側と完全に一致させる必要があり、不一致だと SA (Security Association) 確立がフェーズ 1 で失敗します。両 Gateway が存在しないと Connection リソースを作成できません。
- ステップ 5 の理由 (検証)
- Effective Routes (有効なルート) を確認することで、VPN Gateway 経由でオンプレ アドレス空間へのルートが BGP/Static で広告されているか検証できます。トンネル確立後の動作確認は最後のステップとして必須です。
【誤った順序の問題点】
- ❌ Virtual Network Gateway → GatewaySubnet の順
- Gateway のデプロイには GatewaySubnet という名前のサブネットを必要とします。先にこのサブネットを作成していないと Gateway デプロイがエラーになります。
- ❌ Connection → Local Network Gateway の順
- Connection リソースは「VNet Gateway」と「Local Gateway」を結ぶリソースのため、両者が存在しなければ作成できません。Local Gateway を先に作成する必要があります。
- ❌ Gateway デプロイ完了を待ってから Local Gateway 作成
- 順序としては正しいですが、Gateway デプロイは 30 分かかるため、並行作業することで全体時間を短縮できます (Local Gateway は Gateway デプロイ完了を必要としない)。
【VPN Gateway SKU の選び方 (参考)】
| SKU | S2S 接続数 | 帯域 | 用途 |
|---|---|---|---|
| VpnGw1 | 30 | 650 Mbps | 小〜中規模 |
| VpnGw2 | 30 | 1 Gbps | 中規模 |
| VpnGw3 | 30 | 1.25 Gbps | 大規模 |
| VpnGw4/5 | 30 | 5/10 Gbps | 大規模高速 |
【参考】
Site-to-Site VPN 接続を作成する / Virtual Network Gateway の概要 / なぜ GatewaySubnet が必要か
AZ-700-SEC#2 (pid=29616)
Hub-Spoke + Azure Firewall を新規構築します。Spoke から Hub の Azure Firewall を経由してインターネットへ 強制トンネリングさせる構成です。次の作業を正しい順序に並び替えてください。
- Hub VNet (10.0.0.0/16) と Spoke VNet (10.1.0.0/16) を作成し、相互ピアリングを設定する
- Hub VNet に AzureFirewallSubnet (/26) を作成する
- Hub VNet に Azure Firewall をデプロイし、Public IP を関連付ける
- Spoke のサブネットに UDR (User-Defined Route) を作成し、 0.0.0.0/0 → Next Hop: AzureFirewall のプライベート IP を設定する
- Azure Firewall 上にネットワーク/アプリケーション ルール (許可 outbound 等) を設定する
解説
【正しい順序】
- ステップ 1: Hub VNet (10.0.0.0/16) と Spoke VNet (10.1.0.0/16) を作成し、相互ピアリングを設定する
- ステップ 2: Hub VNet に AzureFirewallSubnet (/26) を作成する
- ステップ 3: Hub VNet に Azure Firewall をデプロイし、Public IP を関連付ける
- ステップ 4: Spoke のサブネットに UDR を作成し、0.0.0.0/0 → Next Hop: AzureFirewall のプライベート IP を設定する
- ステップ 5: Azure Firewall 上にネットワーク/アプリケーション ルール (許可 outbound 等) を設定する
【各ステップの理由】
- ステップ 1 が最初の理由
- すべての後続リソース (Firewall、UDR、ピアリング) が VNet の存在を前提とするため、まず VNet を作成します。ピアリングも先に設定することで、後の UDR の Next Hop アドレス検証時に既に Spoke から Hub への到達性が確立されている状態となります。
- ステップ 2 の理由 (Firewall の前)
- AzureFirewallSubnet は名前が固定 (変更不可) で、サイズは /26 以上が必要です。Firewall デプロイ時にこのサブネットが存在しないとデプロイが失敗するため、Firewall より先に作成する必要があります。
- ステップ 3 の理由 (Firewall デプロイ)
- UDR の Next Hop には Firewall のプライベート IPを指定する必要があるため、Firewall がデプロイされて IP が割り当てられていなければ UDR を正しく設定できません。デプロイには数分かかります。
- ステップ 4 の理由 (UDR でルーティング強制)
- Spoke サブネットからのアウトバウンドを 0.0.0.0/0 で Firewall に強制する UDR を設定します。Firewall ルールを先に作っても UDR がないとトラフィックが Firewall を通らないため、UDR はルール定義より先に設定するのが推奨です (検証時に意図しない deny を回避できます)。
- ステップ 5 の理由 (ルール定義は最後)
- UDR が正しく Firewall を経由するように設定された後、最後にネットワーク/アプリケーション ルールで具体的な許可・拒否を定義します。最初は最小許可ルールから始めて、段階的に拡張する運用が安全です。
【UDR 設定例】
| 項目 | 値 |
|---|---|
| 名前 | RT-Spoke-to-Firewall |
| Address prefix | 0.0.0.0/0 |
| Next hop type | Virtual appliance |
| Next hop address | Azure Firewall のプライベート IP (例: 10.0.1.4) |
【誤った順序の問題点】
- ❌ Firewall → AzureFirewallSubnet の順
- Firewall のデプロイは AzureFirewallSubnet という名前のサブネットを必要とします。先にこのサブネットを作成していないと Firewall のデプロイがエラーになります。
- ❌ ルール定義 → UDR の順
- UDR がない状態で Firewall ルールだけ作っても、Spoke からのトラフィックは Firewall を経由しません (デフォルトのシステム ルートでインターネット直通)。検証時に「ルールは作ったのに動作しない」混乱を招きます。
- ❌ Firewall デプロイ → ピアリングの順
- Firewall は単独でも動きますが、ピアリングがないと Spoke から Hub の Firewall プライベート IP に到達できないため、UDR が機能しません。本要件はピアリングが前提です。
【参考】
Azure Firewall のデプロイ チュートリアル / Hub-Spoke リファレンス アーキテクチャ / なぜ AzureFirewallSubnet は /26 が必要か
🟡 single_choice (4 択 1 答) 3 問
AZ-700-APP#2 (pid=29617)
あなたは 複数リージョン (East US と West Europe) にデプロイされた VM Scale Set をフロントエンドにし、地理的に近いユーザーへ最寄りのリージョンへトラフィックを振り分けたい。レイテンシ最適化 + HTTP/HTTPS 不問のグローバル L4 ロード バランサーが必要です。最も適切な選択はどれですか?
解説
【正解: B】の理由
「グローバル + L4 + 最寄り振り分け」を満たすのは Cross-region Load Balancer (Global tier) です。Standard LB のリージョン版を上位で束ねることで、Anycast IP 1 つでグローバル受付しつつ、TCP/UDP を含む L4 で振り分けできます。
【選択肢比較】
| 選択肢 | レイヤー | スコープ | 本要件 |
|---|---|---|---|
| A. Regional LB のみ | L4 | リージョン内 | × 単一エンドポイントなし |
| B. Cross-region LB | L4 | グローバル | ○ 最適 |
| C. Application Gateway | L7 | リージョン内 | × リージョン内のみ |
| D. Front Door | L7 (HTTP/S 限定) | グローバル | △ HTTP/HTTPS のみ |
【参考】
AZ-700-CONN#2 (pid=29618)
あなたは大手データセンター事業者と直接コロケーション接続を結んでおり、その施設には Microsoft のエッジ ルーターが設置されています。最低遅延 + 帯域 100 Gbps の選択肢が欲しい。最も適切な ExpressRoute モデルはどれですか?
解説
【正解: B】の理由
コロケーション内に Microsoft エッジ ルーターがあり、帯域 100 Gbps が欲しい場合、ExpressRoute Direct (100 Gbps Port) が唯一の選択肢です。プロバイダー経由 (A/C) では 10 Gbps が上限のことが多く、また中間プロバイダーを挟むため遅延も増えます。
【ExpressRoute モデル比較】
| モデル | 最大帯域 | 用途 |
|---|---|---|
| Cloud Exchange Co-location (A) | 10 Gbps | プロバイダー L2/L3 経由 |
| Point-to-Point Ethernet (C) | 10 Gbps | 専用線 |
| Any-to-Any (IPVPN) | 10 Gbps | MPLS など |
| ExpressRoute Direct (B) | 10/100 Gbps | 大規模 + 高帯域 |
【参考】
AZ-700-PVT#1 (pid=29625)
Storage Account に Private Endpoint を作成し、Hub-Spoke 環境のすべてのオンプレ クライアントとすべての Spoke VNet からプライベート IP 経由でアクセスさせたい。クライアントは既存の URL (例: contosostor.blob.core.windows.net) をそのまま使う必要があります。最も適切な DNS 構成はどれですか?
解説
【正解: B】の理由
大規模環境のベスト プラクティスは 「Hub に 1 つの Private DNS Zone + すべての Spoke にリンク + オンプレは Private Resolver 経由」 です。Private DNS Zone は privatelink.[サービス名] という固定名で、各 Azure サービスに対応するゾーンを 1 サブスクリプションあたり 1 つ作るのが推奨です。
【DNS 解決フロー】
クライアント (オンプレ) → contosostor.blob.core.windows.net オンプレ DNS フォワーダ → 条件付き転送 Azure DNS Private Resolver (Hub VNet) → 解決 privatelink.blob.core.windows.net Private Zone → 10.0.5.4 (Private Endpoint IP) クライアントは 10.0.5.4 にアクセス (プライベート経路)
【他選択肢が違う理由】
- A. Spoke 毎に DNS Zone
- 運用が破綻、管理コスト膨大。Hub 集約が標準です。
- C. ホスト ファイル
- スケールせず、IP 変更時にすべて手作業が必要です。
- D. パブリック DNS で書き換え
- パブリック リゾルバはインターネット全体に公開されるため、内部用途には不適切です。
【参考】
🟠 multi_choice (複数選択) 1 問
AZ-700-SEC#3 (pid=29619)
解説
【正解: B, C】の理由
Azure Firewall Premium tier でしか実装できない機能は TLS Inspection と IDPS です。これらは深いインスペクション (DPI) を必要とするため、Premium tier 専用に提供されます。
【Standard vs Premium 機能マトリクス】
| 機能 | Standard | Premium |
|---|---|---|
| アプリケーション ルール (FQDN フィルタリング) | ○ | ○ |
| ネットワーク ルール (TCP/UDP/ICMP) | ○ | ○ |
| NAT ルール | ○ | ○ |
| Threat Intelligence (既知の悪意ある IP / ドメインのブロック) | ○ | ○ |
| TLS Inspection (TLS 復号 + コンテンツ検査) | × | ○ |
| IDPS (侵入検知/防止) | × | ○ |
| URL Filtering (フル URL パス制御) | × | ○ |
| Web Categories (カテゴリ ベースのブロック) | × | ○ |
【他選択肢が違う理由】
- A. アプリケーション ルールでの FQDN フィルタリング
- Standard tier でも実装できます。アプリケーション ルールは Standard tier の中核機能です。
- D. ネットワーク ルールでの TCP/UDP プロトコル制御
- Standard tier でも実装できます。ネットワーク ルールは Standard tier の中核機能です。
- E. アプリケーション ルールでの HTTP/HTTPS L7 制御
- Standard tier でも実装できます (SNI 検査 + Host ヘッダー判定)。Premium が追加するのは TLS 復号後のコンテンツ検査です。
【参考】
🔴 single_choice 追加 (ルーティング優先度)
AZ-700-CORE#2 (pid=29620)
あなたの VNet には次の経路が同時に存在します:
- (1) システム既定ルート: 0.0.0.0/0 → Internet
- (2) BGP 経由 (ExpressRoute) で広告された: 10.50.0.0/16 → ExpressRoute
- (3) ユーザー定義ルート (UDR): 10.50.0.0/16 → Azure Firewall (Virtual appliance)
- (4) VNet ピアリング: 10.50.0.0/16 → VirtualNetwork
VM から 10.50.0.5 宛のパケットは、どの経路が選択されますか?
解説
【正解: C】の理由
Azure のルーティング優先度は 「最長プレフィックス マッチ → ソース優先度」の順で決定されます。今回は全て 10.50.0.0/16 なのでプレフィックス長は同じ → ソース優先度で決定。
【ルーティング優先度 (高い順)】
| 順位 | ソース |
|---|---|
| 1 | UDR (User-Defined Route) |
| 2 | BGP (ExpressRoute / VPN) |
| 3 | VNet Peering (System route) |
| 4 | System default (Internet / VirtualNetwork) |
【ポイント】
- UDR は最強。手動で指定したルートが常に優先される
- BGP は UDR より弱いが Peering よりは強い
- Hub-Spoke で Firewall を強制トンネリングしたい場合、必ず UDR で 0.0.0.0/0 を Firewall に向ける
【参考】
🟣 yesno シリーズ 3 問 (Hub-Spoke SNAT 設計)
AZ-700-CORE#3-1 (pid=29621)
あなたは Hub-Spoke 構成の Azure 環境で、Spoke の VM から多数の外部 SaaS API への大量並列 HTTPS 通信を行います。Source NAT (SNAT) ポート枯渇 (SNAT exhaustion) を回避し、安定したアウトバウンド接続を確保したい設計です。
Spoke のサブネットに NAT Gateway を関連付け、専用の Public IP プレフィックス (/28) を割り当てる。
解説
【判定: はい】の理由
NAT Gateway は 専用のアウトバウンド SNAT を提供し、Public IP 1 つあたり 64,000 SNAT ポートを利用できます (/28 プレフィックスなら 16 IP × 64K = 約 100 万ポート)。Spoke VM の Default Outbound や VM 上の Public IP の共有プール枯渇問題を完全に回避できます。
【SNAT ポート比較】
| 方式 | SNAT ポート/IP | 安定性 |
|---|---|---|
| VM への Default Outbound (deprecated) | 限定的、共有 | × |
| Standard LB Outbound rule | 1024〜64K | ○ |
| NAT Gateway | 64,512/IP (Idle 4 分以上の TCP は別) | ◎ |
【参考】
AZ-700-CORE#3-2 (pid=29622)
(設問 1 と同じシナリオ)
Spoke の VM に Public IP を直接付与し、System Default Outbound にトラフィックを流す。
解説
【判定: いいえ】の理由
VM に Public IP を直接付与する方法は SNAT 枯渇には対処できるが、(1) セキュリティ ベスト プラクティス違反 (各 VM が外部から到達可能になる)、(2) Public IP コスト増加、(3) 2025-09 以降、Default Outbound Access は段階的に廃止予定、の 3 つの問題があります。本要件には不適切です。
【代替案】
| 選択肢 | セキュリティ | コスト | 推奨度 |
|---|---|---|---|
| VM Public IP 直付け | × | 高 | × |
| Standard LB Outbound rule | ○ | 中 | △ |
| NAT Gateway | ○ | 低 | ◎ |
【参考】
AZ-700-CORE#3-3 (pid=29623)
(設問 1 と同じシナリオ)
Hub VNet の Azure Firewall (Standard tier) を経由してすべての外部 SaaS への HTTPS 通信を強制トンネリングする。
解説
【判定: いいえ】の理由
Azure Firewall も SNAT を行いますが、SNAT ポートは Firewall インスタンスあたり 2,496 ポート/IP と比較的少なく、大量並列接続 (数千同時) の用途では枯渇しやすいです。Azure Firewall はセキュリティ検査用途で利用すべきで、純粋な SNAT スケール目的では NAT Gateway が適切です。
【併用パターン】
本要件をセキュリティ + スケールの両立で解決する場合は、「NAT Gateway + Azure Firewall サブネットには別 NAT Gateway」のようにサブネット単位で NAT Gateway を関連付けるのが最善です。Azure Firewall のサブネットに NAT Gateway を関連付けることで、Firewall 経由のアウトバウンドも SNAT スケール可能となります。