AZ-700 Core 142 問再構成完了 (8 フィードバック対応)

📋 AZ-700 Core 142 問再構成完了 (8 フィードバック対応)

multi 選択肢 3 個ルール、hsdd 3 行ルール、drag_match 10 問新規、hotspot 単一 5 問新規、yesno シリーズ 9 series (27 posts)、画像/コード問題追加。VARONTO 様にブラウザでの品質確認をお願いします。

🟡 single_choice (4 択 1 答) (60 問)

AZ700-CORE#244 (pid=29802)

AZ700-CORE#35

次の ExpressRoute トポロジ図を見て、構成として正しい記述はどれですか?

オンプレ 拠点 (本社)
└─ ER Provider (NTT/Equinix)
└─ ER Circuit-1 (East Asia)
└─ Private Peering (Customer ASN 65500)

Azure (East Asia リージョン)
└─ Hub VNet (10.0.0.0/16)
└─ ExpressRoute Gateway (ErGw2)
└─ Connection ↔ ER Circuit-1
└─ Spoke VNets (Peering 経由で ER Gateway 利用)

A. 本構成は ExpressRoute Standard で動作。Spoke VNet は VNet ピアリング (Use remote gateways) で Hub の ER Gateway を利用してオンプレに到達する B. Spoke VNet は Hub と関係なく直接 ER Circuit に接続する C. BGP は不要、すべて静的ルートで構成する D. ExpressRoute Premium が必須

ディスカッション 0

AZ700-CORE#243 (pid=29801)

AZ700-CORE#33

次の Hub-Spoke ネットワーク構成図を見て、Spoke A の VM (10.1.1.5) からインターネットへの通信経路として正しいものはどれですか? Spoke A サブネットには UDR で 0.0.0.0/0 → 10.0.1.4 (Azure Firewall プライベート IP) が設定されています。

Hub VNet (10.0.0.0/16)
├─ AzureFirewallSubnet (10.0.1.0/26)
│  └─ Azure Firewall: 10.0.1.4 + Public IP
└─ Peering ↔ Spoke A

Spoke A VNet (10.1.0.0/16)
└─ subnet-app (10.1.1.0/24)
└─ VM: 10.1.1.5 (UDR: 0.0.0.0/0 → 10.0.1.4)

A. VM → Spoke A デフォルトゲートウェイ → Hub Firewall プライベート IP (10.0.1.4) → Firewall Public IP → Internet B. VM → Spoke A デフォルトゲートウェイ → Internet 直接 (UDR は無視) C. VM → Hub Public IP → Internet D. VM → VPN Gateway → Internet

ディスカッション 0

AZ700-CORE#242 (pid=29800)

AZ700-CORE#31

次の Bicep テンプレートで Application Gateway WAF_v2 SKU の空欄に入る値として正しいものはどれですか?

resource appgw "Microsoft.Network/applicationGateways@2024-05-01" = {
  name: "appgw1"
  location: location
  properties: {
    sku: {
      name: "[空欄]"
      tier: "WAF_v2"
      capacity: 2
    }
    ...
  }
}

A. WAF_v2 B. Standard_v2 C. WAF D. Standard

ディスカッション 0

解説

【正解: A】の理由

Application Gateway v2 の SKU は name と tier が同じ値を取ります。WAF 機能付きの v2 は name = "WAF_v2" + tier = "WAF_v2"。Standard 機能 (WAF なし) の v2 は "Standard_v2"。

【SKU 値の一覧】

SKU 名	機能	用途
Standard_v2	L7 LB のみ	WAF 不要、シンプル LB
WAF_v2	L7 LB + WAF	Web 攻撃保護必須
Standard (v1)	L7 LB のみ (廃止予定)	レガシー
WAF (v1)	L7 LB + WAF (廃止予定)	レガシー

【他選択肢が違う理由】

B. Standard_v2: WAF なし、tier "WAF_v2" との不整合。
C/D. WAF/Standard (v1): v1 は廃止予定、新規構築は v2 必須。

【参考】

App Gateway v2

【ベストプラクティス】

Microsoft 公式ドキュメントに記載された推奨手順を遵守
本番環境では事前に Test/Dev 環境で検証
変更管理プロセスに従い、段階的な展開を実施
監視 + アラートを有効化し、運用品質を継続的に評価

【関連リソース】

AZ700-CORE#241 (pid=29799)

AZ700-CORE#29

次の Azure CLI コマンドの空欄に入る値として正しいものはどれですか?

# VNet ピアリングを作成 (Hub → Spoke 方向)
az network vnet peering create \
  --resource-group RG-Hub \
  --name Hub-to-Spoke \
  --vnet-name Hub-VNet \
  --remote-vnet Spoke-VNet \
  --allow-vnet-access true \
  --allow-forwarded-traffic true \
  --allow-gateway-transit [空欄] \
  --use-remote-gateways false

Hub 側に VPN Gateway があり、Spoke がこれを利用する設計です。

A. true B. false C. auto D. inherit

ディスカッション 0

解説

【正解: A】の理由

Hub 側に VPN Gateway があり Spoke が利用する場合、Hub 側で allow-gateway-transit = true (Gateway を貸す)、Spoke 側で use-remote-gateways = true (Gateway を借りる) という対の設定が必要です。

【Gateway Transit 設定マトリクス】

側	allow-gateway-transit	use-remote-gateways
Hub (Gateway 保有)	true	false
Spoke (Gateway 利用)	false	true

【他選択肢が違う理由】

B. false: Gateway を貸さない設定、本要件と不整合。
C. auto / D. inherit: Azure CLI ではこれらの値は受け付けません。bool 値 (true/false) のみ。

【参考】

VNet ピアリング / az network vnet peering

【ベストプラクティス】

Microsoft 公式ドキュメントに記載された推奨手順を遵守
本番環境では事前に Test/Dev 環境で検証
変更管理プロセスに従い、段階的な展開を実施
監視 + アラートを有効化し、運用品質を継続的に評価

【関連リソース】

AZ700-CORE#240 (pid=29798)

AZ700-CORE#27

次の PowerShell スクリプトの空欄に入る Cmdlet として正しいものはどれですか?

# VNet にサブネットを追加する
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG1" -Name "VNet1"
[空欄] -Name "subnet-web" -AddressPrefix "10.0.1.0/24" -VirtualNetwork $vnet
$vnet | Set-AzVirtualNetwork

A. Add-AzVirtualNetworkSubnetConfig B. New-AzVirtualNetworkSubnet C. Set-AzSubnetConfig D. Create-AzSubnet

ディスカッション 0

解説

【正解: A】の理由

Azure PowerShell でサブネットを VNet に追加する標準 Cmdlet は Add-AzVirtualNetworkSubnetConfig。Get で取得した VNet オブジェクトに対し Add でサブネット構成を追加、最後に Set-AzVirtualNetwork で変更を Azure に永続化するパターンです。

【他選択肢が違う理由】

B. New-AzVirtualNetworkSubnet: そのような Cmdlet は存在しません。
C. Set-AzSubnetConfig: そのような Cmdlet は存在しません。Set は VNet 全体の永続化用。
D. Create-AzSubnet: Azure PowerShell の動詞は New/Set/Add/Remove で、Create は使いません。

【Azure PowerShell パターン】

用途	Cmdlet
取得	Get-Az*
追加	Add-Az*Config
変更	Set-Az*Config
永続化	Set-Az* (top-level)
削除	Remove-Az*Config

【参考】

Add-AzVirtualNetworkSubnetConfig

【ベストプラクティス】

Microsoft 公式ドキュメントに記載された推奨手順を遵守
本番環境では事前に Test/Dev 環境で検証
変更管理プロセスに従い、段階的な展開を実施
監視 + アラートを有効化し、運用品質を継続的に評価

【関連リソース】

AZ700-CORE#141 (pid=29758)

AZ700-CORE#14

Azure Network Watcher Agent for Linux/Windows をインストールする目的はどれですか?

A. Connection Monitor の Source として、Packet Capture の対象として動作可能にする B. NSG ルールを動的に追加する C. Public IP の自動取得 D. BGP セッション維持

ディスカッション 0

解説

【正解: A】の理由

Network Watcher Agent (VM Extension または手動インストール) は、その VM を Connection Monitor の Source として登録、または Packet Capture の対象として動作可能にします。Agent なしの VM では Connection Monitor の Source 機能や Packet Capture が動作しません。

【Agent インストール方法】

環境	方法
Azure VM	VM Extension で自動インストール (Azure Portal/CLI/PS)
オンプレ VM	手動インストール (Linux: apt/yum、Windows: MSI)
VMSS	VM Scale Set Extension で全インスタンス自動適用

【Agent が有効化する機能】

Connection Monitor の Source として動作
Packet Capture (PCAP 取得)
VM 内部ネットワークメトリクス収集 (Workspace ベース)
Hybrid 監視 (オンプレ Agent → Azure Workspace)

【他選択肢が違う理由】

B. NSG 動的追加: NSG は Azure 側機能、Agent と無関係。
C. Public IP 自動取得: Public IP は別リソース。
D. BGP セッション: Gateway リソースの機能、Agent と無関係。

【参考】

Network Watcher Agent

【Network Watcher Agent 機能】

機能	Agent 必要
IP Flow Verify	不要 (Azure VM のみ)
Connection Monitor (Source)	必要
Packet Capture	必要
Effective Routes/Security Rules	不要
Hybrid 監視 (オンプレ Source)	必要

【Agent インストール方法】

Azure VM: Portal/CLI/PowerShell から VM Extension
VM Scale Set: VMSS Extension
オンプレ Linux: apt/yum パッケージ
オンプレ Windows: MSI インストーラ

Network Watcher Agent

AZ700-CORE#140 (pid=29757)

AZ700-CORE#12

DDoS Network Protection の「Mitigation Report」に含まれる情報はどれですか?

A. 攻撃タイプ (SYN flood 等)、ピーク帯域、緩和開始時刻、緩和方法、影響リソースの詳細 B. 攻撃者の身元 (氏名、住所) C. コスト試算のみ D. NSG ルール提案

ディスカッション 0

解説

【正解: A】の理由

DDoS Mitigation Report は攻撃後に PDF として生成され、攻撃の詳細記録を含みます: (1) 攻撃タイプ (Volumetric、Protocol、Application 別)、(2) ピーク帯域 (Gbps、PPS)、(3) 攻撃継続時間、(4) Mitigation 開始/終了時刻、(5) Mitigation 方法 (SYN cookie、Rate limiting 等)、(6) 影響リソース (Public IP)。これは SOC のインシデントレポート + コンプライアンス監査の重要な資料となります。

【Mitigation Report の用途】

SOC インシデント記録
コンプライアンス監査 (PCI DSS、ISO 27001 等)
経営層への報告
保険会社への請求材料
事後攻撃パターン分析

【Mitigation Report 取得方法】

Azure Portal → DDoS Protection Plan → Mitigation Reports
攻撃イベント (Mitigation Triggered) を選択
PDF Report をダウンロード (攻撃後数時間で生成)

【他選択肢が違う理由】

B. 攻撃者の身元: DDoS Protection は技術的緩和、攻撃者特定はサイバー犯罪調査の領域。
C. コスト試算: Cost Management 領域。
D. NSG 提案: Defender for Cloud の領域。

【参考】

DDoS Protection 管理

【DDoS Telemetry メトリクス一覧】

メトリック	用途
Under DDoS attack or not	攻撃検知 Bool
Inbound packets / bytes	攻撃時の Inbound 計測
TCP/UDP/Other packets DDoS	プロトコル別緩和
Packets dropped DDoS	緩和済パケット

【SOC 対応プロセス】

アラート受信 (Under DDoS attack = true)
Mitigation Report ダウンロード
影響範囲確認 (どの Public IP)
カスタマー対応 (必要時 DRR 連絡)
事後分析 + 設定見直し

DDoS Telemetry

AZ700-CORE#139 (pid=29756)

AZ700-CORE#8

Azure DNS の Alias レコード (Alias Record Set) の利点はどれですか?

A. Azure リソース (Public IP、Front Door、Traffic Manager) の IP 変更を自動追従、CNAME と異なり Zone Apex (ルートドメイン) でも利用可能 B. CNAME と完全に同じ C. TTL を 0 にできる D. NS レコードの代替

ディスカッション 0

解説

【正解: A】の理由

Azure DNS Alias レコードは Azure リソースを直接参照する特殊なレコード。Public IP、Front Door、Traffic Manager、CDN 等の Azure リソースが IP 変更されても DNS レコードが自動追従。CNAME と異なり Zone Apex (例: contoso.com) でも利用可能 (CNAME は RFC で Zone Apex 禁止)。

【Alias vs CNAME】

項目	Alias	CNAME
Zone Apex	○	× (RFC 違反)
Azure リソース自動追従	○	×
外部ドメイン参照	×	○
レコードタイプ	A/AAAA/CNAME 互換	CNAME

【典型ユースケース】

contoso.com の Zone Apex を Front Door に向ける (CNAME 不可なので Alias)
Public IP リソースを参照する DNS A レコード (IP 変更時に自動追従)
Traffic Manager Profile を Zone Apex から参照

【参考】

Azure DNS Alias

【Alias レコードの自動追従】

Azure リソース	Alias 対応
Public IP Address	○
Front Door	○
Traffic Manager Profile	○
CDN Endpoint	○
Storage Static Website	○ (Endpoint 経由)

【Alias vs A レコードの違い】

A レコード: IP 直接記述、変更時に手動更新
Alias レコード: Azure リソース参照、変更時に自動追従
Apex 利用 (例: contoso.com の Front Door 参照) は Alias のみ可

Azure DNS Alias

AZ700-CORE#138 (pid=29755)

AZ700-CORE#6

Azure Storage Account の「Network Routing Preference」設定で「Microsoft Network Routing」を選ぶ意味はどれですか?

A. クライアントから Storage への通信を Microsoft バックボーン経由でルーティング (低レイテンシ + データ流出防止) B. Storage 内部のレプリケーションを変更 C. NSG を上書き D. コスト削減

ディスカッション 0

解説

【正解: A】の理由

Storage Account の Network Routing Preference (Microsoft Network Routing vs Internet Routing) は、クライアント → Storage 通信の経路を制御します。「Microsoft Network Routing」を選ぶと、Microsoft バックボーン経由で通信し、低レイテンシ + Microsoft 内部ネットワークでの通信保護を実現します。Internet Routing は通常のインターネット経路 (ISP 経由) で、コストは安いが経路セキュリティは劣ります。

【Routing Preference 比較】

項目	Microsoft Routing	Internet Routing
経路	Microsoft バックボーン	インターネット (ISP)
レイテンシ	低 (最適化)	変動
セキュリティ	Microsoft 内部	ISP 経由 (公開)
コスト	標準	低
SLA	○	限定的

【参考】

Routing Preference

【Storage Routing オプション影響】

項目	Microsoft Routing	Internet Routing
レイテンシ	低	変動 (ISP 依存)
セキュリティ	Microsoft 内部	ISP 経由
コスト	標準	低
SLA	○	限定的

【ユースケース別推奨】

本番 + 機密データ → Microsoft Routing 必須
テスト + コスト重視 → Internet Routing 可
地理的に分散したクライアント → Microsoft Routing で安定レイテンシ

Routing Preference

AZ700-CORE#137 (pid=29754)

AZ700-CORE#4

Application Gateway v2 の Listener タイプ「Multi-site」の用途はどれですか?

A. 1 つの AppGW で複数のドメイン (例: contoso.com + fabrikam.com) をホスト B. AppGW を複数地理的にデプロイ C. バックエンドプールを複数にする D. 1 つのドメインで TLS 証明書を複数持つ

ディスカッション 0

解説

【正解: A】の理由

Multi-site Listener は、1 つの AppGW で複数のドメイン (Host ヘッダ別) をホスティングする機能です。例: contoso.com と fabrikam.com を 1 つの AppGW で受信し、Host ヘッダに応じて異なるバックエンドプールに振り分け可能です。SaaS マルチテナントアーキテクチャに最適。

【Listener タイプ】

タイプ	用途
Basic	1 つの Frontend IP + Port で 1 つのバックエンド
Multi-site	1 つの IP + Port、Host ヘッダで複数バックエンド分岐

【典型構成例】

Listener (Multi-site):
  contoso.com (TLS Cert 1) → Backend Pool A
  fabrikam.com (TLS Cert 2) → Backend Pool B
  api.contoso.com (TLS Cert 1 wildcard) → Backend Pool C

【他選択肢が違う理由】

B. 複数地理的: AppGW はリージョン内サービス、複数地理は別途。
C. バックエンド複数: Multi-site は Listener レベル機能、バックエンドは Routing Rule で関連付け。
D. 複数 TLS 証明書: Multi-site では各 Listener で別 TLS Cert 設定可能だが、これが目的ではなく Host ベース分岐が目的。

【参考】

Multi-site hosting

【AppGW Listener 構成例】

Listener 1 (Multi-site):
  Frontend: Public IP, Port 443, HTTPS
  Host: contoso.com
  Cert: contoso.com Cert
  → Backend Pool Contoso

【Multi-site の制約】

Listener あたり 1 ホスト
1 Listener で複数ホスト = SNI ベース、各ホスト用 Cert 必要
Wildcard 証明書 (例: *.contoso.com) で 1 Cert 多ホスト可
Frontend IP は共有可能

【URL Path-based Routing と組み合わせ】

Multi-site + URL Path で「contoso.com/api → API Pool、contoso.com/web → Web Pool」のような多段ルーティング実現します。

Multi-site

AZ700-CORE#136 (pid=29753)

AZ700-CORE#113

Azure VPN Gateway で IKE フェーズ 2 失敗の典型的原因はどれですか?

A. 暗号スイート (SA Proposal) がオンプレ側と一致していない B. Public IP が変わった C. Gateway Subnet サイズが小さい D. ASN が小さい

ディスカッション 0

解説

【正解: A】の理由

IKE フェーズ 2 (IPsec SA 確立) の失敗は、Azure 側とオンプレ機器側で暗号スイート (SA Proposal) が一致していない場合に発生します。フェーズ 1 (認証) は成功するがフェーズ 2 で失敗するため、PSK は正しくても通信が確立しないというパターン。

【IKE フェーズ 1 vs 2 失敗の典型原因】

フェーズ	典型的失敗原因
フェーズ 1 (IKE SA)	PSK 不一致、IKE バージョン不一致 (IKEv1 vs IKEv2)
フェーズ 2 (IPsec SA)	暗号スイート (AES-256 等)、PFS Group、ライフタイム不一致

【トラブルシュート手順】

VPN Diagnostic で IKE/IPsec ステータス確認
SA 確立失敗の場合、Custom IPsec Policy を Azure 側で設定 (Default 値がオンプレ機器と非互換)
オンプレ機器ベンダーの推奨設定を参照
両側で同一の Encryption + Integrity + DH Group + PFS + Lifetime を設定

【他選択肢が違う理由】

B. Public IP 変更: Local Network Gateway の更新が必要だが、フェーズ 2 特定の問題ではない。
C. Subnet サイズ: Gateway デプロイには影響、フェーズ 2 失敗には直接関連しない。
D. ASN: BGP の問題、フェーズ 2 (IPsec) には直接関連しない。

【参考】

VPN デバイス

【VPN IPsec/IKE パラメータ詳細】

パラメータ	典型値
IKEv2 Encryption	AES256
IKEv2 Integrity	SHA384
DH Group	DHGroup24 / ECP384
IPsec Encryption	AES256
IPsec Integrity	SHA256
PFS Group	PFS24
SA Lifetime	3600 sec / 102400000 KB

【ベンダー別推奨】

Cisco ASA、Palo Alto、Juniper SRX、Fortinet 等の主要 VPN 機器ベンダーごとに Microsoft 推奨設定が公開されています。

VPN 暗号化

AZ700-CORE#135 (pid=29752)

AZ700-CORE#112

AKS で Network Policy を実装する場合、Azure CNI Overlay モードでサポートされる Policy Engine はどれですか?

A. Cilium (eBPF ベース、高性能) または Calico B. iptables ベースのみ C. NetworkPolicy は AKS 非対応 D. AppArmor + SELinux のみ

ディスカッション 0

解説

【正解: A】の理由

AKS の Network Plugin が Azure CNI Overlay モードの場合、Network Policy Engine として Cilium (eBPF ベース、高性能 + 監視機能) または Calico (iptables ベース、業界標準) を選択可能です。Cilium は L7 (HTTP) ポリシーや高度な可観測性機能を提供し、最新の推奨選択です。

【AKS Network Policy 比較】

Engine	ベース	L3/L4	L7 (HTTP)	可観測性
Calico	iptables	○	×	基本
Azure NPM	iptables/IPVS	○	×	基本
Cilium	eBPF	○	○	高度 (Hubble)

【他選択肢が違う理由】

B. iptables のみ: CNI Overlay は Cilium も対応です。
C. 非対応: NetworkPolicy は AKS 標準機能です。
D. AppArmor: これはコンテナのプロセスサンドボックス、ネットワーク制御ではない。

【参考】

AKS Network Policy

【Network Policy 比較】

Engine	L3/4	L7	パフォーマンス	監視
Calico	○	×	中	基本
Azure NPM	○	×	中	基本
Cilium	○	○	高 (eBPF)	Hubble UI

【Cilium の利点】

eBPF ベースで iptables より高速
L7 (HTTP メソッド、URL) ポリシー
Service Mesh 統合 (Istio 互換)
Hubble で可観測性強化

AKS Network Policy

AZ700-CORE#134 (pid=29751)

AZ700-CORE#109

Azure Container Instances (ACI) を VNet 内にデプロイする際の構成として正しいのはどれですか?

A. サブネットを Microsoft.ContainerInstance/containerGroups に Delegation、Public IP なしのプライベート ACI B. ACI は VNet 統合非対応 C. Private Endpoint でアクセス D. AKS にデプロイする

ディスカッション 0

AZ700-CORE#133 (pid=29750)

AZ700-CORE#108

Azure Container Apps の VNet 統合に関する正しい記述はどれですか?

A. Container Apps Environment を VNet 内にデプロイし、Internal Mode (Private IP) または External Mode (Public IP) を選択 B. Container Apps は VNet 統合非対応、Public IP のみ C. AKS と同じ Network Plugin (CNI/Kubenet) を選択する D. Service Endpoint のみ対応

ディスカッション 0

解説

【正解: A】の理由

Azure Container Apps Environment を VNet 内にデプロイすることで、内部 PaaS とのプライベート通信が可能になります。「Internal Mode」は外部から非公開 (Internal LB)、「External Mode」は Public IP を持ちます。Internal で構築 + Front Door や Application Gateway 経由で公開するパターンが Zero Trust 推奨。

【Container Apps 統合】

専用サブネット (/23 以上推奨) 必要、Delegation 不要 (Container Apps 用)
Internal Mode: Public IP なし、VNet 内/VPN 経由のみアクセス
External Mode: Public IP あり、インターネット公開
Custom DNS、Private DNS Zone との統合可能

【他選択肢が違う理由】

B. 非対応: Container Apps は VNet 統合対応です。
C. AKS と同じ Plugin: Container Apps はマネージドサービス、Plugin 選択不要 (内部 Kubernetes は隠蔽)。
D. SE のみ: Container Apps は VNet 内デプロイ可能、SE は補完的。

【参考】

Container Apps Networking

【Container Apps Environment Networking】

項目	Internal	External
Public IP	なし	あり
外部アクセス	VNet 内のみ	インターネット
用途	内部 API、Zero Trust	Public Web API

【サブネット要件】

Consumption Plan: /23 サブネット推奨
Dedicated Plan: /27 でも可
Delegation: Microsoft.App/environments (Consumption) または不要 (Dedicated)

Container Apps Networking

AZ700-CORE#132 (pid=29749)

AZ700-CORE#87

Custom IP Prefix (BYOIP) リソースの状態遷移として正しい順序はどれですか?

A. Provisioning → Provisioned → Commissioning → Commissioned B. Commissioned → Provisioned → Active C. Created → Active → Deactivated D. Draft → Published → Archived

ディスカッション 0

解説

【正解: A】の理由

Custom IP Prefix リソースは 4 段階の状態遷移を持ちます: (1) Provisioning = リソース作成 + 検証中、(2) Provisioned = 検証完了、まだアドバタイズ前、(3) Commissioning = アドバタイズ開始処理中、(4) Commissioned = Azure バックボーンからインターネットへ BGP アドバタイズ中。

【各状態の意味と所要時間】

状態	動作	所要
Provisioning	署名検証 + ROA 検証	数日
Provisioned	検証完了、利用準備可	-
Commissioning	BGP アドバタイズ準備	30 分〜数時間
Commissioned	インターネットから到達可能	-

【他選択肢が違う理由】

B, C, D: Azure Custom IP Prefix の状態名としては正しくない。

【参考】

Custom IP Prefix

【BYOIP の典型用途】

SaaS Allowlist 維持 (顧客サービス側で IP 変更不要)
SEO + SSL 証明書の継続性
規制要件 (特定 IP 範囲の保持)
マルチクラウド統一 IP プール

【BYOIP 申請プロセス】

段階	所要
RIR 所有権登録	既存
ROA 登録 (IRR)	1-2 日
署名付き認証メッセージ	即時
Microsoft 検証	3-7 日
Commission	30 分-数時間

Custom IP Prefix

AZ700-CORE#131 (pid=29748)

AZ700-CORE#66

Azure VPN Gateway / ExpressRoute Gateway の Azure 側 BGP ASN はどれですか?

A. 65515 (VPN Gateway)、12076 (ExpressRoute) B. 1234 (両方) C. AS65000 (両方) D. カスタマー指定 (任意)

ディスカッション 0

解説

【正解: A】の理由

Azure 側 BGP ASN は固定値で、VPN Gateway は 65515、ExpressRoute Microsoft 側は 12076 です。VPN Gateway の ASN は変更可能ですが、ExpressRoute の Microsoft 側 ASN は固定です。Customer 側 ASN はオンプレ機器側で設定し、Local Network Gateway / ER Private Peering で Azure に登録します。

【ASN 設計のポイント】

側	ASN	備考
Azure VPN Gateway	65515 (既定)	変更可能 (1-4,294,967,295)
Azure ExpressRoute MS 側	12076	固定
オンプレ Customer 側	任意	Private ASN (64512-65534) 推奨

【ASN 衝突回避】

Customer 側 ASN は Azure 側と異なる必要 (eBGP の前提)
複数 VPN Gateway を持つ場合、各 Gateway で異なる ASN 設定可
同じ ASN を複数 Local Network Gateway で使うとループリスク

【他選択肢が違う理由】

B, C: 固定値が正しくない。
D. カスタマー指定: VPN Gateway 側は変更可能だが既定は 65515、ER MS 側は固定です。

【参考】

VPN BGP

【BGP ASN 設計指針】

側	推奨 ASN 範囲
Customer (オンプレ) Private	64512-65534 (RFC 6996 Private)
Customer 4-byte Private	4200000000-4294967294
Public ASN	RIR (ARIN/RIPE 等) 取得

【ASN 衝突回避ルール】

Azure 側 ASN (65515 / 12076) と異なる ASN を使う
異なる VPN/ER 接続で同じ Customer ASN を使うとループリスク (BGP path-prepending で対処)
Azure VPN Gateway の ASN は変更可、ER MS 側は固定

VPN BGP

AZ700-CORE#130 (pid=29747)

AZ700-CORE#44

Azure VNet で IPv4 と IPv6 のデュアルスタックを使う場合、必要な構成はどれですか?

A. VNet 作成時に IPv4 + IPv6 アドレス空間を両方指定、各サブネットも IPv4 + IPv6 デュアル指定 B. IPv6 は VNet では非対応 C. IPv6 のみ専用 VNet を別途作成必要 D. VPN Gateway を介してのみ IPv6 利用可

ディスカッション 0

解説

【正解: A】の理由

Azure VNet は IPv4 + IPv6 のデュアルスタックをサポートしており、VNet 作成時に両アドレス空間を指定、各サブネットも IPv4 (例: 10.0.1.0/24) + IPv6 (例: fd00::/64) の両方を割り当てることで VM が両アドレスを取得します。NIC、NSG、UDR、Public IP、Load Balancer も IPv6 対応。

【IPv6 構成例】

VNet:
  IPv4: 10.0.0.0/16
  IPv6: fd00::/48

サブネット:
  IPv4: 10.0.1.0/24
  IPv6: fd00:0:0:1::/64

【IPv6 のメリット】

IPv4 アドレス枯渇問題の解決 (大規模 IoT、Pod スケール)
規制 (政府機関 IPv6 義務化、日本でも進行中) への対応
NAT 不要のエンドツーエンド通信

【他選択肢が違う理由】

B. 非対応: Azure は IPv6 完全対応、ULA + GUA 両方サポート。
C. 専用 VNet: 同一 VNet 内デュアルスタックが標準です。
D. VPN Gateway のみ: VPN Gateway は IPv6 アドバタイズ対応だが必須ではない。

【参考】

VNet IPv6

【IPv6 デュアルスタック対応サービス】

サービス	IPv6 対応
VNet + Subnet	○ (デュアルスタック)
VM (NIC)	○
Public IP	○ (Standard SKU)
Load Balancer	○ (Standard SKU)
NSG	○ (IPv6 ルール対応)
Application Gateway	○ (v2)
VPN Gateway	限定対応

【IPv6 移行段階】

IPv4 オンリー → デュアルスタック (IPv4 + IPv6) → IPv6 オンリー (将来)。多くの組織はデュアルスタックフェーズに長期滞在。

VNet IPv6

AZ700-CORE#94 (pid=29711)

AZ700-CORE#105

Azure Monitor for Networks の Functional Dependency View で確認できる情報はどれですか?

A. ネットワークリソース間の依存関係 (VNet→ピアリング→Spoke、AppGW→VNet→Subnet→VM 等) B. Public IP のコスト分析 C. BGP ピアリング状態 D. TLS 証明書の有効期限

ディスカッション 0

解説

【正解: A】の理由

Functional Dependency View は、Azure ネットワークリソース間の依存関係を視覚的に表示する機能です。VNet → ピアリング先 VNet、AppGW → バックエンド VM → サブネット → NSG、VPN Gateway → Local Network Gateway 等の依存グラフを自動構築し、トラブルシュート時に「どのリソースが影響を受けるか」を瞬時に把握できます。

【Functional Dependency View で表示される依存関係】

親リソース	子/依存リソース
VNet	サブネット、ピアリング、NSG、UDR、Gateway
Application Gateway	バックエンドプール、Listener、Rule、Health Probe、TLS Cert
Load Balancer	バックエンドプール、Frontend IP、Outbound Rule
VPN Gateway	Local Network Gateway、Connection、Tunnel、BGP Peer
ExpressRoute Gateway	Circuit、Peering、Connection
Front Door	Origin、Route、WAF Policy、Endpoint

【典型ユースケース】

インシデント時: 「VNet 障害でどの AppGW/VM/SQL DB が影響を受けるか」即把握
変更管理: 「サブネット削除で影響する PE/VM をリスト化」
容量計画: 「Hub VNet のピアリング接続数を確認」
監査: 「NSG が全サブネットに関連付けられているか網羅確認」

【Functional Dependency View の特徴】

自動生成 (Azure Resource Graph ベース)
クリック可能なリンク (関連リソースへ即移動)
関係種類別表示 (Containing、Reference、Dependency)
Network Insights の他機能 (Health、Topology) との統合

【他選択肢が違う理由】

B. Public IP コスト: Cost Management の領域、Functional Dependency View はリソース依存関係に特化。
C. BGP 状態: VPN Gateway / ExpressRoute の各リソースメトリクスで確認します。
D. TLS 証明書期限: Key Vault / AppGW の証明書管理機能で確認します。

【参考】

Network Insights

AZ700-CORE#92 (pid=29709)

AZ700-CORE#104

Network Insights (Azure Monitor for Networks) の「Diagnostic Toolkit」機能の利点はどれですか?

A. Network Watcher の各診断ツール (Connection Monitor、IP Flow Verify、Topology 等) を Network Insights ダッシュボードから直接呼び出せる B. すべてのネットワークエラーを自動修復 C. BGP ルートを編集できる D. コスト分析機能

ディスカッション 0

解説

【正解: A】の理由

Network Insights の Diagnostic Toolkit は、Azure Portal の Network Watcher の各診断ツール (Connection Monitor、IP Flow Verify、Next Hop、Effective Routes、Effective Security Rules、Connection Troubleshoot、Packet Capture、VPN Diagnostic 等) を Network Insights のダッシュボードから直接呼び出せる統合 UI を提供します。トラブルシュート時のコンテキスト切替を最小化し、効率的な調査が可能です。

【Diagnostic Toolkit からアクセス可能なツール】

ツール	用途
Connection Monitor	継続的接続性監視
IP Flow Verify	NSG 判定
Next Hop	UDR / システムルート確認
Effective Routes	VM の実効ルートテーブル
Effective Security Rules	VM の実効 NSG ルール
Connection Troubleshoot	エンドツーエンド経路分析
Packet Capture	パケットキャプチャ
VPN Diagnostic	VPN Gateway 診断
NSG Diagnostics	NSG ルール衝突分析

【Network Insights のその他主要機能】

Functional Dependency View: リソース間の依存関係可視化
Health Dashboard: 全ネットワークリソースの健全性監視
Topology View: VNet ピアリング、サブネット、ルーティング可視化
Connectivity: Connection Monitor 結果集約
Traffic: NSG Flow Logs / Traffic Analytics 結果集約

【典型ユースケース】

ネットワークエンジニアのオンボーディング (全体把握)
インシデント時の影響範囲特定 (依存関係から影響リソース推定)
キャパシティプランニング (帯域・接続数のトレンド)
定期的なネットワーク健全性レビュー

【他選択肢が違う理由】

B. 自動修復: Diagnostic Toolkit は診断ツールへの統合 UI、自動修復機能はなし。
C. BGP 編集: BGP は VPN/ExpressRoute Gateway 設定で管理、Diagnostic Toolkit の対象外。
D. コスト分析: Cost Management の領域、Network Insights には別途。

【参考】

Network Insights

AZ700-CORE#88 (pid=29703)

AZ700-CORE#100

Azure DDoS Network Protection と Azure DDoS IP Protection の主な違いはどれですか?

A. Network Protection は VNet 単位 (月額固定費)、IP Protection は Public IP 単位 (IP ごと従量制) B. 機能差はない、命名のみ違う C. Network Protection は廃止予定 D. IP Protection はインバウンドのみ、Network Protection はアウトバウンド

ディスカッション 0

解説

【正解: A】の理由

DDoS Network Protection は VNet 単位で月額固定費 (約 USD 2,944/月、100 Public IP まで含む) で、大規模環境向き。DDoS IP Protection は個別の Public IP 単位で従量課金 (約 USD 199/IP/月)、小規模環境や特定 Public IP のみ保護したい場合に適切です。

【DDoS Protection 詳細比較】

項目	Network Protection	IP Protection
適用単位	VNet	Public IP
料金体系	月額固定 + IP 追加料金	IP 単位 (従量制)
料金例	$2,944/月 (100 IP 含む)	$199/IP/月
DDoS Rapid Response (DRR)	○	×
コスト保護	○ (DDoS 攻撃時の追加料金保護)	×
WAF 統合 (Front Door/AppGW)	○	○
Defender for Cloud 統合	○	○
用途	大規模 (10+ Public IP)	小規模 (1〜数個の重要 IP)

【DDoS Basic (既定、無料)】

すべての Azure リソースで自動有効化、追加料金なし
Microsoft グローバルネットワークレベルの保護 (大規模攻撃の吸収)
VNet ごとのアダプティブチューニングなし
カスタムアラートなし
緊急対応支援なし

【DDoS 攻撃の典型タイプ】

攻撃タイプ	Basic で吸収可	Standard 必要
Volumetric (帯域消費)	○ (大規模なら Microsoft が自動緩和)	○ (細かい制御)
Protocol attack (SYN flood 等)	×	○
Application layer (L7)	×	○ (WAF 連携)

【選択指針】

10+ Public IP + 重要本番環境 → Network Protection
1〜数個の重要 Public IP のみ → IP Protection
テスト/開発環境 → DDoS Basic (既定で十分)
Web アプリケーション攻撃も対象 → DDoS Standard + WAF 必須

【他選択肢が違う理由】

B. 機能差なし: 大きく異なる料金体系 + DRR/コスト保護の有無。
C. Network Protection 廃止: 廃止予定なし、最新の推奨製品。
D. インバウンド/アウトバウンド分離: 両方ともインバウンド DDoS 保護。アウトバウンド DDoS 保護は別概念。

【参考】

DDoS Protection 概要 / 攻撃タイプ

AZ700-CORE#86 (pid=29701)

AZ700-CORE#98

AVNM の Connectivity 構成で「Mesh」トポロジを選んだ時の動作はどれですか?

A. Network Group 内のすべての VNet 間に双方向ピアリングを自動構築 (N×N) B. 1 つの Hub に対し全 VNet がピアリング C. 静的ルートのみ集中管理 D. Public IP の集中管理

ディスカッション 0

解説

【正解: A】の理由

AVNM の Mesh トポロジは、Network Group 内のすべての VNet 間に双方向ピアリングを自動構築します。N 個の VNet があれば N×(N-1)/2 ペアのピアリングが自動生成され、すべての VNet が他の VNet と直接通信可能になります。手動での管理が破綻する規模 (10+ VNet) で自動化メリットが大きい。

【Connectivity トポロジ 3 種類】

トポロジ	説明	適用シナリオ
Mesh	全 VNet 間に双方向ピアリング	すべて相互接続が必要、各 VNet が独立アプリ
Hub-Spoke	1 Hub + N Spoke、Hub のみと Spoke ピア	中央 Firewall/監視、Spoke は分離
Hub-Spoke with Direct Connectivity	Hub-Spoke + Spoke 間直接ピア	Hub は監視のみ、Spoke 間は高速通信

【Mesh の利点と欠点】

項目	評価
低レイテンシ	○ (各 VNet 間で直接通信、Hub 経由なし)
運用シンプル	○ (AVNM が自動管理、手動不要)
セキュリティ	△ (各 VNet 間で通信可能、中央 Firewall 経由しない)
スケール	○ (AVNM Network Group の動的追加で自動 Mesh 拡張)
コスト	△ (ピアリング数増加、データ転送料)

【Mesh の典型ユースケース】

マイクロサービスアーキテクチャで多数のサービス VNet が相互通信
研究/開発環境で各 VNet が独立、Hub の Firewall 検査不要
同一信頼境界内 (例: 同一ビジネスユニット) の VNet 群
低レイテンシ要件の VNet 間通信

【Hub-Spoke vs Mesh の選択】

中央セキュリティ検査必要 → Hub-Spoke
低レイテンシ + 単純構成 → Mesh
両方の良さ → Hub-Spoke with Direct Connectivity

【他選択肢が違う理由】

B. 1 Hub + 全 VNet ピアリング: これは Hub-Spoke トポロジ、Mesh ではない。
C. 静的ルートのみ: AVNM Connectivity 構成は VNet ピアリング自動化、静的ルートではない。
D. Public IP 管理: Public IP は別リソース、AVNM の機能ではない。

【参考】

AVNM Connectivity

AZ700-CORE#84 (pid=29699)

AZ700-CORE#96

Azure VNet 設計のベストプラクティスのうち、最も重要な原則はどれですか?

A. アドレス空間を初期段階で十分に大きく確保 (将来拡張余裕)、専用サブネット (Gateway、Bastion、Firewall) を計画に含める B. アドレス空間は最小限 (/24) で十分 C. サブネットは VM ごとに 1 つ作成 D. すべての VM に Public IP を付与

ディスカッション 0

解説

【正解: A】の理由

Azure VNet 設計の最重要原則は「初期段階で十分なアドレス空間を確保 + 専用サブネットを計画に含める」です。VNet 作成後のアドレス空間 + サブネット境界変更は既存リソースに影響するため困難で、将来の機能追加 (Gateway、Bastion、Firewall、AppGW、Container 統合等) を見越したアドレス計画が運用効率を大きく左右します。

【VNet 設計の主要原則】

原則	詳細
アドレス計画	RFC 1918 (10.0.0.0/8) で /16 以上、オンプレと重複しない範囲を選択
専用サブネット予約	Gateway (/27)、Bastion (/26)、Firewall (/26)、AppGW (/24) の専用枠を事前確保
階層的サブネット分割	Web/App/DB の層別 + 環境別 (Prod/Dev)
NSG/ASG 設計	最小権限、Defense in Depth、ASG ベースルール
Hub-Spoke パターン	10+ VNet で集中管理、AVNM で自動化
監視 + ログ	NSG Flow Logs V2、Traffic Analytics、Defender for Cloud

【典型的なアドレス計画例】

Hub VNet: 10.0.0.0/16 (65,536 IP)
  AzureFirewallSubnet:    10.0.1.0/26
  AzureBastionSubnet:     10.0.2.0/26
  GatewaySubnet:          10.0.3.0/27
  Shared Services:        10.0.10.0/24
  Resolver Inbound:       10.0.20.0/28
  Resolver Outbound:      10.0.20.16/28

Spoke 1 (Prod): 10.1.0.0/16
  Web tier:               10.1.1.0/24
  App tier:               10.1.2.0/24
  DB tier:                10.1.3.0/24
  Private Endpoint:       10.1.10.0/24

Spoke 2 (Dev): 10.2.0.0/16 ...

【避けるべき設計】

アドレス空間 /28 のような最小限指定 (後から拡張不可)
サブネット内に 1 VM のみ (NSG 関連付けが分散、管理破綻)
専用サブネット (Gateway/Bastion/Firewall) を計画外配置 (アドレス枯渇)
オンプレと重複するアドレス空間 (ピアリング/VPN で衝突)
Public IP の VM 直接付与 (Bastion 利用が標準)

【他選択肢が違う理由】

B. 最小限 /24: VNet 全体が 256 IP しかなく、Bastion (/26 = 64 IP) や Firewall (/26 = 64 IP) を追加すると半分以上消費、拡張余地なし。
C. VM ごとにサブネット: サブネット数 6,000 上限、運用コスト膨大、不要な粒度分割。
D. すべて Public IP: セキュリティポスチャ最悪 (各 VM が直接インターネット曝露)。Bastion + Private 構成が標準です。

【参考】

VNet 計画と設計 / ネットワークベストプラクティス

AZ700-CORE#83 (pid=29698)

AZ700-CORE#94

Multi-region Hub-Spoke 構成 (East US と West Europe にそれぞれ Hub-Spoke) で、2 つの Hub を相互接続する標準的な手法はどれですか?

A. Global VNet Peering で 2 Hub を直接接続 (Microsoft バックボーン経由) B. Internet 経由 VPN で 2 Hub を接続 C. Hub VNet を物理的に統合 D. ExpressRoute Direct で接続

ディスカッション 0

解説

【正解: A】の理由

Multi-region Hub-Spoke で 2 つの Hub VNet を結ぶ標準手法は Global VNet Peering です。Microsoft バックボーン経由で低レイテンシ + 高帯域、暗号化なし (バックボーン内信頼) で接続。Spoke→Spoke のリージョン跨ぎ通信は「Spoke A → Hub 1 → Hub 2 (Global Peering) → Spoke B」のように Hub 経由でルーティングします。

【Multi-region Hub-Spoke のトラフィックフロー】

Spoke A (East US)
  ↓ UDR で Firewall 1 経由
Hub 1 (East US) Firewall
  ↓ Global VNet Peering
Hub 2 (West Europe)
  ↓ Hub 2 Firewall (オプション)
Spoke B (West Europe)

【接続手法比較】

手法	レイテンシ	帯域	暗号化	コスト
Global VNet Peering	低 (Backbone)	高	なし (Backbone 信頼)	データ転送料
VPN over Internet	高	VPN GW SKU 依存	IPsec	VPN GW + 転送料
ExpressRoute (Premium で複数リージョン)	低 (専用)	10/100 Gbps	MACsec (ER Direct)	高 (回線 + ER 料金)
Virtual WAN	低 (Backbone)	高	なし (Backbone 信頼)	Virtual WAN コスト

【Global Peering の制約】

暗号化されない (Microsoft バックボーンの物理セキュリティに依存)
Multicast/Broadcast 非対応
UDP Bidirectional Streaming は一部制限
VNet Gateway を介した Transit は対応 (Hub の Gateway を Spoke が利用)
2 リージョン以上の Mesh は管理複雑、Virtual WAN を検討

【代替: Azure Virtual WAN】

3 リージョン以上または 10+ ブランチで複雑化する場合、Virtual WAN が推奨
Hub 間接続が自動 (Mesh Backbone)
VPN/ExpressRoute/P2S を統合管理

【他選択肢が違う理由】

B. Internet 経由 VPN: レイテンシ高 + Public Internet 通過 + 帯域制限です。Global Peering より劣る。
C. VNet 統合: Azure では異リージョン VNet を 1 つに統合する機能なし。
D. ExpressRoute Direct: オンプレ↔Azure 用、VNet↔VNet には不適。

【参考】

VNet ピアリング / Hub-Spoke リファレンス

AZ700-CORE#81 (pid=29696)

AZ700-CORE#92

Service Chaining (サービスチェイニング) とは何ですか?

A. VNet ピアリング + UDR を組み合わせて、トラフィックを意図した NVA/Firewall 経由でルーティングする手法 B. 複数の Azure サービスを連携させる Azure Logic Apps の機能 C. Storage Account を複数連携する機能 D. AKS のサービス間通信の機能

ディスカッション 0

解説

【正解: A】の理由

Service Chaining は Azure VNet の機能で、VNet ピアリング + UDR (User-Defined Route) を組み合わせて、特定の経路 (例: Hub の NVA、Azure Firewall、サードパーティ Firewall) を経由するようトラフィックを誘導するアーキテクチャパターンです。例えば Spoke→Spoke の通信を Hub の Firewall 経由で強制することで、セキュリティ検査を集中化できます。

【Service Chaining の典型パターン】

パターン	用途	実装
Spoke→Hub→Spoke	Spoke 間通信を Hub Firewall 経由で検査	UDR で Spoke の他 Spoke 範囲 → Hub Firewall
Spoke→Internet via Hub	すべてのアウトバウンドを Hub Firewall 経由	UDR で 0.0.0.0/0 → Hub Firewall
Multi-tier NVA chain	複数の NVA (WAF + Firewall + IDS) を順次通過	各層で UDR を設定

【設計上のポイント】

VNet ピアリングは非推移的 (Spoke A↔Hub、Hub↔Spoke B でも A↔B 直接不可)、これを UDR で迂回する
Hub の NVA (Firewall) で「Allow forwarded traffic」がピアリング設定で true 必須
NVA が VM の場合、NIC で「IP 転送を有効化」が必要
非対称ルーティング (Asymmetric Routing) を避けるため、戻りトラフィックの経路も計画
UDR がない場合、VNet Peering 設定のみでは Spoke 間直接通信になる (NVA を経由しない)

【設定例: Spoke A → Spoke B を Hub Firewall 経由】

Spoke A の UDR:
  Address prefix: 10.2.0.0/16 (Spoke B 範囲)
  Next hop type: Virtual appliance
  Next hop address: 10.0.1.4 (Hub Firewall プライベート IP)

Spoke B の UDR:
  Address prefix: 10.1.0.0/16 (Spoke A 範囲)
  Next hop type: Virtual appliance
  Next hop address: 10.0.1.4 (Hub Firewall)

【他選択肢が違う理由】

B. Logic Apps の機能: Service Chaining はネットワーク概念で、Logic Apps とは無関係。
C. Storage Account 連携: 無関係。
D. AKS サービス間通信: AKS は内部に独自の Service Mesh (Istio、Linkerd) を持つが、Service Chaining とは別概念。

【参考】

Service Chaining / Hub-Spoke リファレンス

AZ700-CORE#78 (pid=29693)

AZ700-CORE#90

AKS (Azure Kubernetes Service) のネットワークモデル「Azure CNI」と「Kubenet」を比較した時、Azure CNI の特徴はどれですか?

A. 各 Pod が VNet の IP を直接取得 (NAT なし)、VNet 内リソースへの直接通信可能 B. Pod は NAT 経由のみ、VNet の IP は使わない C. CNI は旧式で Kubenet が推奨 D. CNI は Windows ノード非対応

ディスカッション 0

解説

【正解: A】の理由

Azure CNI (Container Network Interface) では各 Pod が VNet サブネットの IP を直接取得し、VNet 内の VM、Private Endpoint、Service Bus 等に NAT なしで直接通信できます。Kubenet は Pod が VNet 外のオーバーレイネットワーク IP を使い、ノード経由で NAT する仕組みのため、VNet 内 PaaS との直接通信は不可です。

【ネットワークモデル比較】

項目	Kubenet	Azure CNI	Azure CNI Overlay
Pod IP	オーバーレイ範囲	VNet サブネット IP	オーバーレイ範囲
VNet 内リソース直接通信	× (NAT 経由)	○	△ (条件付き)
必要 IP 数	少ない	多い (Pod × Node 数)	少ない
サブネットサイズ	/24 で十分	大規模 /22 等	/24 で十分
Network Policy	Calico のみ	Calico / Azure / Cilium	Calico / Cilium
パフォーマンス	NAT オーバーヘッド	最高	最高 (オーバーヘッド最小)
用途	小規模、シンプル	大規模、PaaS 統合	大規模、IP 節約

【Azure CNI の IP 計画】

Pod IP がサブネットから消費されるため、サブネットサイズを Pod 数で見積もる
ノードあたり Max Pods (既定 30) × Node 数 + Node 自身の IP + バッファ
例: 100 Node + 30 Pods/Node = 3,000 + 100 + 余裕 = /20 (4096 IP)
サブネットサイズ過小だと Pod 起動失敗

【Azure CNI Overlay (最新推奨)】

2023 年 GA の新モード、CNI の利点 (Network Policy 等) + Kubenet の IP 効率を両立
Pod はオーバーレイ範囲 (任意 CIDR、例: 192.168.0.0/16) の IP
Node は VNet サブネット IP
大規模クラスタ (10,000 Pod 以上) で推奨

【他選択肢が違う理由】

B. NAT 経由のみ: これは Kubenet の動作で、CNI ではない。
C. CNI 旧式: 逆、CNI が現代的な標準です。Kubenet は廃止予定。
D. Windows 非対応: CNI は Windows ノードもサポート (Kubenet が一部 Windows 非対応)。

【参考】

AKS ネットワーク概念

AZ700-CORE#75 (pid=29690)

AZ700-CORE#89

Azure App Service (Premium Plan) を VNet 統合する 2 種類の方式 (Regional VNet Integration と Gateway-required VNet Integration) について、Regional VNet Integration の特徴はどれですか?

A. 同一リージョンの VNet にのみ統合可、専用サブネット (Delegation Microsoft.Web/serverFarms) 必要 B. 異なるリージョンの VNet にも統合可、VPN Gateway 不要 C. VPN Gateway 経由で他リージョンの VNet にも統合可 D. Public IP 専用、VNet 統合不要

ディスカッション 0

解説

【正解: A】の理由

Regional VNet Integration (RVI) は App Service Premium V2/V3、Functions Premium、Logic Apps Standard で利用可能な VNet 統合方式で、同一リージョンの VNet にのみ統合可能です。専用サブネットを Microsoft.Web/serverFarms に Delegation する必要があり、Gateway 不要で低レイテンシ + 低コストで実現します。

【VNet 統合の 2 方式比較】

項目	Regional VNet Integration	Gateway-required VNet Integration
対象リージョン	同一リージョンのみ	同一/異リージョン両方
Gateway	不要	VNet Gateway 必要
専用サブネット	必須 (Delegation)	不要
レイテンシ	低 (直接接続)	高 (Gateway 経由)
帯域	App Service Plan に依存	VPN Gateway SKU に依存
料金	App Service Plan のみ	+ Gateway 料金
App Service Plan	Premium V2/V3、Standard 等	Standard、Premium 等 (Basic 不可)

【Regional VNet Integration の動作】

App Service Plan の各インスタンスが専用サブネットの IP を取得 (NIC 仮想化)
VNet 内のリソース (Storage Private Endpoint、VM、SQL DB Private Endpoint) にプライベートアクセス可能
アウトバウンドのみ (App Service が VNet 内リソースを呼ぶ)、インバウンドは Application Gateway や Private Endpoint で別途構成
Service Endpoint と組み合わせ可能

【専用サブネット計画】

サブネット名: 任意 (例: app-service-integration)
サイズ: /26 以上推奨 (App Service Plan のスケールアウト余裕)
Delegation: Microsoft.Web/serverFarms
他のリソースは配置不可

【他選択肢が違う理由】

B. 異リージョン Gateway 不要: Regional VNet Integration は同一リージョンのみ。異リージョンには Gateway 経由か Private Endpoint。
C. VPN Gateway 経由: これは Gateway-required VNet Integration の動作で、Regional VNet Integration ではない。
D. Public IP 専用: VNet 統合は不要ではなく必須要件ありの機能です。

【参考】

App Service VNet Integration

AZ700-CORE#73 (pid=29688)

AZ700-CORE#85

Private Endpoint を作成する際の Private DNS Zone Group の役割はどれですか?

A. Private Endpoint のプライベート IP に対応する A レコードを自動登録 + ライフサイクル管理 B. Public DNS にレコードを登録 C. NSG ルールを自動設定 D. コストを最適化

ディスカッション 0

解説

【正解: A】の理由

Private DNS Zone Group は、Private Endpoint (PE) と Private DNS Zone (例: privatelink.blob.core.windows.net) を結びつけるリソースで、PE のプライベート IP に対応する A レコードを自動登録 + 自動更新 + 削除時の自動クリーンアップを行います。手動メンテナンスを排除し、PE のライフサイクル全体を通じて DNS 整合性を保ちます。

【Private DNS Zone Group の構成】

項目	例
名前	storage-pe-dns
関連 Private DNS Zone	privatelink.blob.core.windows.net
登録される A レコード	mystorage.privatelink.blob.core.windows.net → 10.0.5.4
解決される FQDN	mystorage.blob.core.windows.net (CNAME 経由)

【DNS 解決の仕組み】

VM が mystorage.blob.core.windows.net をクエリ
Public DNS が mystorage.privatelink.blob.core.windows.net へ CNAME 返却
VNet 内の Private DNS Zone を参照 (リンクされている場合)
Private DNS Zone Group で登録した A レコードから 10.0.5.4 (PE プライベート IP) を返却
VM は 10.0.5.4 にアクセス (PE 経由で Storage へ)

【Zone Group なしの場合 (非推奨)】

PE 作成後、手動で Private DNS Zone に A レコード追加
PE 削除時、A レコードを手動削除しないと不整合発生
PE プライベート IP 変更時、手動更新必要
運用工数増大 + ヒューマンエラーのリスク

【複数 Zone Group 対応】

PE 作成時に複数の Private DNS Zone Group を関連付け可能
例: privatelink.blob + privatelink.dfs + privatelink.file (Storage の各サブリソース)
Multi-region 環境では Zone 集約が運用効率向上に貢献

【他選択肢が違う理由】

B. Public DNS にレコード登録: Public DNS とは無関係 (Public DNS の CNAME は Microsoft 管理)。Zone Group は Private DNS Zone のみ操作。
C. NSG ルール自動設定: NSG とは無関係。
D. コスト最適化: Zone Group 自体には料金不要、Private DNS Zone と PE の通常料金。

【参考】

Private Endpoint DNS 統合

AZ700-CORE#70 (pid=29685)

AZ700-CORE#82

Azure Bastion の SKU を比較した時、Standard SKU でのみ利用可能な機能はどれですか?

A. SSH/RDP 経由の VM 接続 B. 最大 50 同時セッションへのスケーリング、ホストスケールユニット 2-50 構成 C. ブラウザベースのアクセス (Azure Portal) D. AzureBastionSubnet の利用

ディスカッション 0

解説

【正解: B】の理由

Azure Bastion Standard SKU は Basic SKU と比べて、ホストスケールユニット (2〜50) を手動指定可能で、同時セッション数を大幅に拡張できます。さらに Native Client (Azure CLI / Azure PowerShell からの SSH 直接接続)、IP ベース接続、共有可能リンク、Kerberos 認証等の高度な機能を提供します。

【Bastion SKU 機能比較】

機能	Basic	Standard	Premium
SSH/RDP via Portal	○	○	○
ホストスケーリング	固定 2 unit	2-50 unit 手動指定	2-50 unit
Native Client (Azure CLI/PS)	×	○	○
IP ベース接続	×	○	○
共有可能リンク	×	○	○
Kerberos 認証	×	○	○
カスタム RDP/SSH ポート	×	○	○
セッション録画	×	×	○
Private-only Bastion	×	×	○

【他選択肢が違う理由】

A. SSH/RDP 接続: すべての SKU でサポートされる基本機能です。
C. ブラウザベース: すべての SKU の基本機能です。Azure Portal から接続。
D. AzureBastionSubnet: すべての SKU で必須のサブネット要件 (/26)。

【SKU 選択指針】

少数 VM、シンプル接続のみ → Basic
多数 VM、Native Client、共有リンク必要 → Standard
セッション録画、Private-only、Zero Trust 環境 → Premium (2024 GA)

【参考】

Azure Bastion 構成 / Bastion SKU

AZ700-CORE#66 (pid=29681)

AZ700-CORE#79

Service Endpoint を有効化したサブネットから Azure Storage Account へ通信する場合、Storage 側で必要な設定はどれですか?

A. Storage Firewall の「Selected networks」で当該 VNet/サブネットを許可リストに追加 B. Storage Account に Private Endpoint を作成 C. Storage Account を Public IP 専用にする D. 特別な設定不要、Service Endpoint だけで完結

ディスカッション 0

解説

【正解: A】の理由

Service Endpoint (SE) はサブネット側で「このサブネットからの通信は Azure バックボーン経由で Storage に直送する」最適化機能ですが、Storage 側でも「どの VNet/サブネットからの通信を許可するか」を Firewall ルールで明示する必要があります。Storage Account → Networking → Firewalls and virtual networks → Selected networks で対象サブネットを追加します。

【Service Endpoint vs Private Endpoint 比較】

項目	Service Endpoint	Private Endpoint
Storage のアクセス IP	Public IP (バックボーン経由)	Private IP (VNet 内)
オンプレからの利用	不可	VPN/ER 経由で可能
料金	無料	有償 (PE 単位)
SE Policy	細粒度 Storage Account 制御可	不要
Storage 側設定	Firewall 許可リスト	Private Endpoint 受け入れ

【Service Endpoint 通信フロー】

サブネットで Microsoft.Storage Service Endpoint を有効化
VM が Storage Account の Public DNS に対しクエリ
Public IP に解決
送信時に Service Endpoint で Azure バックボーン経由にルーティング
Storage Firewall で VNet ID + サブネット ID をチェック
許可リストにあれば通信成立

【他選択肢が違う理由】

B. Private Endpoint 作成: Private Endpoint は別アーキテクチャ。SE と併用も可能ですが、本要件には不要です。
C. Public IP 専用: Storage の SKU や設定としては正確ではなく、Public Network Access 設定とは別。
D. 設定不要: Storage 側 Firewall で許可しないと、SE 経由のトラフィックも拒否されます。

【参考】

Service Endpoint 概要 / Storage ネットワークセキュリティ

AZ700-CORE#65 (pid=29680)

AZ700-CORE#77

あなたは Web 層 VM 5 台に対し、すべて同じ NSG ルール (HTTP/HTTPS 許可、SSH 拒否) を適用する設計を考えています。NSG と ASG (Application Security Group) の使い分けとして最適なアプローチはどれですか?

A. NSG ルールに各 VM の IP を個別記載 (5 つのソース IP ルール) B. ASG 「web-tier」を作成し、5 VM の NIC に関連付け、NSG ルールで ASG を指定 C. 各 VM に個別 NSG を関連付ける D. NSG を使わず Public IP のみで制御

ディスカッション 0

解説

【正解: B】の理由

Application Security Group (ASG) は、複数の VM NIC を論理的にグループ化し、IP アドレスではなく ASG 名で NSG ルールを定義可能にします。VM の追加・削除や IP 変更があっても NSG ルールは変更不要で、運用効率が大幅に向上します。Web 層 5 台のような同一役割の VM グループに最適です。

【ASG の利点】

項目	IP ベース NSG	ASG ベース NSG
VM 追加時の運用	IP 追記必要	NIC を ASG に追加するだけ
IP 変更時	NSG ルール更新	変更不要
ルール可読性	IP 羅列で見づらい	役割名で明確
スケールアウト	手動メンテ必要	VMSS 自動追従

【ASG 設計パターン】

「web-tier」「app-tier」「db-tier」のような層ベース命名
「prod」「dev」「test」のような環境ベース
NSG ルールで Source/Destination の両方に ASG 指定可能
1 NIC は複数の ASG に所属可能 (役割の組み合わせを表現)

【ASG の制約】

同一 VNet 内のリソースのみ ASG 所属可能
ASG を NSG ルールで利用するには、NSG が ASG メンバーのいるサブネットに関連付けられている必要
サブスクリプション間 ASG 共有不可

【他選択肢が違う理由】

A. 各 VM 個別 IP 記載: 運用負担が大きく、VM 追加/IP 変更時に NSG メンテナンスが必要。スケールしない。
C. VM 個別 NSG: NSG ルール重複の温床、管理工数増大。サブネット NSG + ASG 戦略が標準です。
D. Public IP のみ: NSG なしでは細かい L4 制御不可、セキュリティポスチャ低下。

【参考】

Application Security Groups / NSG 概要

AZ700-CORE#64 (pid=29679)

AZ700-CORE#75

Azure Network Watcher の Packet Capture を使うべきシナリオはどれですか?

A. VM 間で特定の通信パターンを再現させ、L7 まで含めた完全なパケット内容を解析する必要がある B. NSG ルールが正しく動作しているか即座に確認したい C. VNet 間のレイテンシを継続監視したい D. DNS 解決の状況を確認したい

ディスカッション 0

解説

【正解: A】の理由

Packet Capture は Wireshark で読める標準的な PCAP ファイル形式でパケットを記録します。L2-L7 すべてのプロトコル情報 (TCP フラグ、HTTP ヘッダ、TLS handshake 詳細、SQL クエリ内容等) を確認可能なため、複雑な通信問題の最終手段として活用します。アプリケーション層を含む詳細解析が必要な場面で唯一の選択肢になります。

【Packet Capture の使い分け】

用途	推奨ツール	理由
NSG ルール判定	IP Flow Verify	即時 + ルール名特定
継続的接続性監視	Connection Monitor	長期トレンド + SLO
VPN トンネル状態	VPN Diagnostic	VPN 専用診断
パケットレベル詳細分析	Packet Capture	L7 まで完全可視化
NSG 通過フローの記録	NSG Flow Logs	すべての許可/拒否を記録

【Packet Capture の前提条件】

VM に Network Watcher Agent (Linux/Windows VM Extension) がインストール済み
キャプチャサイズ上限 (1 GB) と時間上限 (5 時間)
Storage Account または VM ローカルディスクに保存
5-tuple フィルター可能 (送信元 IP、宛先 IP、ポート、プロトコル)
パケット長制限指定可能 (例: ヘッダ部分 64 バイトのみキャプチャ)

【典型ユースケース】

TLS handshake 失敗の原因分析 (Cipher Suite 不一致など)
HTTP 通信での特定ヘッダの確認
SQL DB へのコネクションパターン解析
マルウェア通信の詳細フォレンジック
パフォーマンス問題の根本原因特定 (TCP Window Size 等)

【Packet Capture の制約】

VM 単位 (PaaS リソースには直接適用不可)
キャプチャ中の VM CPU/ディスク負荷
暗号化通信 (TLS) は復号できない (Pre-master Secret 取得が別途必要)
大量トラフィック時はパケットロス発生の可能性

【他選択肢が違う理由】

B. NSG ルール: IP Flow Verify が即時判定可能です。Packet Capture は過剰。
C. 継続レイテンシ: Connection Monitor が SLO 監視に最適。Packet Capture は瞬間的キャプチャ。
D. DNS: DNS Diagnostic / nslookup / dig のような専用ツールが効率的です。

【参考】

Packet Capture

AZ700-CORE#63 (pid=29678)

AZ700-CORE#73

あなたは VPN Gateway 経由のオンプレ通信が突然停止しました。Azure Network Watcher のどの機能で最初に診断すべきですか?

A. VPN Diagnostic (VPN Gateway のログ + メトリクス分析) B. IP Flow Verify C. Topology D. Packet Capture

ディスカッション 0

解説

【正解: A】の理由

VPN Diagnostic (Network Watcher → VPN Troubleshoot) は VPN Gateway 専用の診断機能で、Gateway のメトリクス (Tunnel Connectivity、IKE/IPsec ステータス、BGP ピアリング状態、トンネル帯域)、診断ログを統合的に分析します。「VPN 経由オンプレ通信停止」シナリオではまずこれで Tunnel Status を確認します。トラブルシュートの起点として最適です。

【VPN Diagnostic で確認できる項目】

項目	意味
IPsec SA (Security Association) の確立状況	暗号化セッションが確立されているか
IKE フェーズ 1/2 の交渉結果	認証 + 暗号化アルゴリズム交渉成功
BGP ピアリング状態 (BGP 構成の場合)	動的ルート交換セッション
Tunnel up/down のタイムライン	切断イベントの記録
Throughput メトリクス	帯域使用状況
Inbound/Outbound パケット数	双方向通信量

【VPN トラブルシュートの典型フロー】

VPN Diagnostic で Tunnel Status 確認 (Up/Down)
Down の場合、IKE フェーズ確認 (フェーズ 1 失敗 = 認証問題、フェーズ 2 = 暗号スイート不一致)
BGP 利用の場合、BGP ピアリング状態確認
オンプレ側機器のログを確認 (Azure 側だけでは判断不能の場合あり)
必要に応じてオンプレベンダーへエスカレーション

【VPN 切断の主要原因】

Pre-Shared Key (PSK) 不一致
IKE/IPsec パラメータ不一致 (暗号スイート、ライフタイム)
オンプレ機器の再起動・設定変更
BGP ASN 不一致
Local Network Gateway の Public IP 変更
NAT デバイス挿入

【他選択肢が違う理由】

B. IP Flow Verify: NSG 起因の判定用、VPN トンネル自体の状態確認には不適。NSG は VPN 関連ではない。
C. Topology: 可視化用、診断ツールではない。トラブルシュートの起点には不向き。
D. Packet Capture: パケットレベル詳細分析、まずは VPN Diagnostic で全体状況を把握すべき。Packet Capture は VPN Diagnostic で原因が絞れない深堀り時に使用します。

【参考】

VPN Troubleshoot / VPN Gateway 診断

AZ700-CORE#62 (pid=29677)

AZ700-CORE#71

Azure Monitor for Networks (現 Network Insights) の主な役割はどれですか?

A. Azure ネットワークリソース全体のメトリクス + 健全性 + トポロジを統合ダッシュボード化 B. NSG ルールの作成支援 C. BGP ピアリング設定 D. Public IP のコスト分析

ディスカッション 0

解説

【正解: A】の理由

Network Insights (Azure Monitor for Networks の現名称) は、Azure 上のネットワークリソース (VNet、Subnet、NSG、Application Gateway、Load Balancer、VPN Gateway、ExpressRoute、Front Door、Private Link 等) のメトリクス、健全性、トポロジを単一のダッシュボードに統合し、ネットワークエンジニアが全体把握しやすくする機能です。複数の Network Watcher ツールと Azure Monitor メトリクスを横断的に表示します。

【主要機能】

機能	用途
Functional Dependency View	リソース間の依存関係可視化
Health Dashboard	全ネットワークリソースの健全性監視
Topology View	VNet ピアリング、サブネット、ルーティング可視化
Connectivity	Connection Monitor 結果集約
Traffic	NSG Flow Logs / Traffic Analytics 結果集約
Diagnostic Toolkit	Network Watcher ツールへのワンクリックアクセス

【Network Insights vs Azure Monitor 一般機能】

視点	Network Insights	Azure Monitor 一般
スコープ	ネットワークリソース特化	全 Azure リソース
事前定義ダッシュボード	あり (ネットワーク向け)	なし (カスタム必要)
トポロジ可視化	あり	なし
Network Watcher 統合	あり	限定的

【典型ユースケース】

新規ネットワークエンジニアのオンボーディング (全体把握)
インシデント時の影響範囲特定 (依存関係から影響リソース推定)
キャパシティプランニング (帯域・接続数のトレンド)
定期的なネットワーク健全性レビュー

【他選択肢が違う理由】

B. NSG ルール作成支援: NSG 設定支援は別機能 (Azure Policy、AVNM)、Network Insights はあくまでも監視 + 可視化。
C. BGP 設定: VPN Gateway / ExpressRoute の設定とは無関係。Route Server / Gateway リソース管理で行います。
D. Public IP コスト: Cost Management の領域。Network Insights はリソース健全性監視に特化。

【参考】

Network Insights 概要

AZ700-CORE#58 (pid=29671)

AZ700-CORE#69

Traffic Analytics の主要機能はどれですか?

A. NSG Flow Logs を Log Analytics に集約し、トラフィックパターンを可視化 + 異常検知 B. NSG ルールを自動生成 C. VPN トンネルの暗号化強度を分析 D. Public IP の使用率測定

ディスカッション 0

解説

【正解: A】の理由

Traffic Analytics は NSG Flow Logs を Log Analytics ワークスペースに集約し、ダッシュボード化することで「どの VM 間にどれだけのトラフィック」「異常なトラフィックパターン」「マルウェア通信の疑い」などを可視化します。Azure 環境のネットワークアクティビティを把握するための主要分析ツールで、SOC (Security Operations Center) や NetOps での日常監視に活用されます。

【主要メトリクス】

メトリクス	用途
送信元/宛先別トラフィック量	Top Talkers 特定
許可/拒否フロートレンド	NSG ポリシー効果分析
Top Talkers (VM/サブネット)	過剰通信 VM の特定
マルウェア通信疑い (Threat Intelligence)	セキュリティインシデント早期発見
異常ポート通信	不正侵入の兆候検知
VNet トポロジー	ネットワーク全体構造の可視化
地理的トラフィック分布	意図しない国からのアクセス検出

【Traffic Analytics 有効化前提】

NSG Flow Logs V2 が有効化されている
Log Analytics ワークスペースが存在する
NSG Flow Logs の宛先として Log Analytics が指定されている
Traffic Analytics の処理間隔: 10 分 (既定) または 60 分

【典型的なクエリ例 (KQL)】

// Top 10 アウトバウンド送信元 VM
AzureNetworkAnalytics_CL
| where SubType_s == "FlowLog"
| where FlowDirection_s == "O"
| summarize TotalBytes = sum(OutboundBytes_d) by VM1_s
| top 10 by TotalBytes desc

【他選択肢が違う理由】

B. NSG 自動生成: Traffic Analytics は分析・可視化のみで、ルール生成はしません。Microsoft Sentinel との統合で「異常検知 → SOAR ワークフロー」が可能ですが、自動生成は別機能です。
C. VPN 暗号化分析: 無関係。VPN Gateway の暗号化スイートは VPN Gateway のメトリクスで確認します。
D. Public IP 使用率: Azure Monitor の Public IP メトリクス領域。

【参考】

Traffic Analytics / Traffic Analytics スキーマ

AZ700-CORE#56 (pid=29669)

AZ700-CORE#67

あなたは Azure VM 間の通信が突然失敗するようになりました。NSG ルールが原因かどうかをまず確認する Network Watcher の機能はどれですか?

A. IP Flow Verify B. Connection Monitor C. Topology D. VPN Diagnostic

ディスカッション 0

解説

【正解: A】の理由

IP Flow Verify は、指定した 5-tuple (送信元 IP/Port、宛先 IP/Port、プロトコル) が NSG ルールで「許可」または「拒否」されるかを瞬時に判定するツールです。VM 単位で動作し、許可された/拒否された具体的なルール名を返すため、NSG 起因の通信失敗を即座に切り分けできます。トラブルシュートの最初の一手として最適です。

【NSG 関連診断ツール比較】

ツール	用途	実行時間
IP Flow Verify	特定 5-tuple の NSG 判定 (許可/拒否 + ルール名)	即時 (数秒)
NSG Diagnostics	NSG セット内のルール衝突 + 重複検出	数秒
NSG Flow Logs	すべての NSG 通過パケットの記録 (Storage に保存)	継続的
Effective Security Rules	VM/NIC に適用される実効ルール一覧	即時

【IP Flow Verify の使い方】

Azure Portal → Network Watcher → IP Flow Verify
対象 VM、NIC を選択
Direction: Inbound / Outbound
5-tuple 指定: Local IP、Local Port、Remote IP、Remote Port、Protocol (TCP/UDP)
結果: Access Allowed / Denied + マッチした NSG ルール名

【典型シナリオ】

VM がアウトバウンドで特定 URL に到達できない → Outbound + Remote IP:443 で判定
VM が SSH (22) を受け付けない → Inbound + Local Port 22 で判定
VM Scale Set の特定インスタンスのみ通信失敗 → そのインスタンス NIC で判定

【他選択肢が違う理由】

B. Connection Monitor: 継続的な接続性監視、NSG ルール判定には不向き。原因が NSG か他要因かを切り分ける用途には不適。
C. Topology: VNet トポロジ可視化、NSG 判定機能なし。
D. VPN Diagnostic: VPN Gateway のトラブルシュート用で VM 間通信には不適。

【トラブルシュートの 5 段階】

IP Flow Verify で NSG 起因を確認
NSG 否定なら Effective Routes で UDR/ピアリング確認
ルート OK なら Connection Troubleshoot で経路全体確認
更に詳細が必要なら Packet Capture で L7 まで確認
VPN/ER 起因なら VPN Diagnostic で詳細分析

【参考】

IP Flow Verify / Effective Security Rules

AZ700-CORE#55 (pid=29668)

AZ700-CORE#64

Azure Network Watcher の Connection Monitor は何を計測する機能ですか?

A. 2 つのエンドポイント間のレイテンシ、パケット損失、トポロジ変化を継続的に監視 B. 特定の TCP ポートが開いているかをワンショットテスト C. NSG のルールヒットカウント D. BGP セッションの状態

ディスカッション 0

解説

【正解: A】の理由

Connection Monitor は Network Watcher の機能の 1 つで、Source (VM/サブネット/Workspace) と Destination (Azure リソース、外部 URL、IP) 間の継続的な接続性テストを行います。レイテンシ、パケット損失、トポロジ変化、TCP/HTTP 応答時間を定期計測し、Log Analytics に蓄積されます。SRE/NetOps の SLO 監視に最適です。

【Network Watcher 主要機能の使い分け】

機能	用途	実行モード
Connection Monitor	継続的なエンドツーエンド接続性監視	常時実行
Connection Troubleshoot	ワンショット接続テスト + ホップ分析	都度実行
IP Flow Verify	特定の 5-tuple が NSG で許可/拒否されるか	都度実行
Next Hop	UDR/システムルートで Next Hop を確認	都度実行
NSG Diagnostics	NSG ルールの効果分析	都度実行
Packet Capture	パケットキャプチャ (PCAP)	期間実行
VPN Diagnostic	VPN Gateway の診断	都度実行

【Connection Monitor の機能詳細】

Source: VM (Agent) / Azure Resource (LB、AppGW、ER Circuit 等) / Workspace
Destination: Azure リソース、Public Endpoint (URL/IP)、オンプレ Endpoint
プロトコル: TCP、ICMP、HTTP/HTTPS
頻度: 30 秒〜30 分 (設定可能)
メトリクス: Round Trip Time、Loss %、Health Threshold (Pass/Fail)
アラート: メトリクスが閾値超えで Azure Monitor アラート発火可能

【典型ユースケース】

クロスリージョン VNet ピアリングの常時 RTT 監視
オンプレと Azure 間の ExpressRoute 接続性 SLO 計測
App Service への外部ユーザー到達性監視
Microservice 間の継続的接続性検証

【他選択肢が違う理由】

B. ワンショットテスト: Connection Troubleshoot の機能です。Connection Monitor は継続監視します。
C. NSG ルールヒット: NSG Flow Logs / Traffic Analytics の領域。
D. BGP セッション: VPN Gateway / ExpressRoute の診断 (BGP Status) の領域。

【参考】

Connection Monitor / Network Watcher 概要

AZ700-CORE#53 (pid=29666)

AZ700-CORE#61

NAT Gateway を 1 つの可用性ゾーン (例: Zone 1) に配置した場合、ゾーン障害が発生したらどうなりますか?

A. 関連付けられたサブネット内のすべてのアウトバウンド通信が停止する B. 自動的に他ゾーンへフェイルオーバーする C. 帯域が半減するが通信は継続する D. NAT Gateway は影響を受けない

ディスカッション 0

解説

【正解: A】の理由

NAT Gateway はゾーン依存リソースで、デプロイ時に特定のゾーン (Zone 1/2/3) に配置するか「No zone」(リージョン内ランダム) を選択します。特定ゾーンに配置した場合、そのゾーン障害時には NAT Gateway も停止し、関連サブネットのアウトバウンドが影響を受けます。フェイルオーバー機能は組み込まれておらず、ゾーン冗長を実現するには複数の NAT Gateway を異なるゾーンに配置する必要があります。

【NAT Gateway ゾーン配置オプション】

オプション	動作	用途	SLA
Zone 1/2/3 (特定ゾーン)	そのゾーンに配置、ゾーン障害時影響あり	Zonal VM と同じゾーンに配置	99.9%
No zone	リージョン内ランダム配置	Zonal でない用途	99.9%

【ゾーン冗長戦略】

ゾーン跨ぎの VM Scale Set の場合、各ゾーンに別の NAT Gateway を配置 (合計 3 つの NAT Gateway)
各サブネットを個別の NAT Gateway に関連付け (同じゾーンの VM とサブネットを揃える)
1 つの NAT Gateway を複数ゾーンには配置不可 (これが Standard LB との大きな違い)
Zonal Resilient な構成では Public IP もゾーン冗長 (Standard) を使用

【NAT Gateway の他制約】

1 つの NAT Gateway を複数サブネットに関連付け可能 (同一可用性ゾーン内)
1 つのサブネットに関連付けられる NAT Gateway は 1 つだけ
NAT Gateway と Standard LB Outbound Rule は同一サブネットで併用不可 (どちらか一方)
NAT Gateway は Basic SKU リソースとは併用不可 (Standard SKU のみ)

【他選択肢が違う理由】

B. 自動フェイルオーバー: NAT Gateway はそのような機能を持たない。フェイルオーバーを実現するには複数 NAT Gateway を冗長配置する必要があります。
C. 帯域半減: 該当ゾーン内では完全停止、帯域半減ではなく完全停止です。
D. 影響なし: ゾーン障害は確実に影響します。特定ゾーン配置の特性上、フェイルオーバーなしで停止します。

【参考】

NAT Gateway 可用性ゾーン / NAT Gateway 設計

AZ700-CORE#51 (pid=29664)

AZ700-CORE#59

UDR (User-Defined Route) の Next hop type のうち、Azure Firewall を経由させるときに指定すべき値はどれですか?

A. Virtual appliance B. Virtual network gateway C. Internet D. None (Drop)

ディスカッション 0

解説

【正解: A】の理由

Azure Firewall を経由させる UDR では Next hop type に Virtual appliance を指定し、Next hop address に Azure Firewall のプライベート IP (例: 10.0.1.4) を設定します。NVA (サードパーティ Firewall、SD-WAN 等) も同じ Virtual appliance タイプで処理します。

【UDR Next hop type 完全一覧】

Next hop type	用途	Next hop address	典型シナリオ
Virtual appliance	Azure Firewall / NVA	必要 (IP 指定)	Firewall 強制経路
Virtual network gateway	VPN / ExpressRoute Gateway	不要	オンプレ向け
VNet local	VNet 内部経路	不要	VNet 内部
Internet	インターネット直行	不要	Public Internet
VirtualNetworkServiceEndpoint	Service Endpoint 経由	不要	Storage 等への内部最適化
None (Drop)	パケット破棄	不要	意図的な遮断

【UDR 設定の典型例 (Hub-Spoke + Firewall)】

名前: rt-spoke-to-firewall
Address prefix: 0.0.0.0/0
Next hop type: Virtual appliance
Next hop address: 10.0.1.4 (Azure Firewall プライベート IP)
適用サブネット: Spoke の全サブネット

【設計上のポイント】

Virtual appliance の Next hop IP は必ず VNet 内のプライベート IP (Public IP 指定は不可)
Azure Firewall の場合、Firewall のプライベート IP を確認 (Firewall リソース > 概要)
NVA (VM ベース Firewall) の場合、その VM の NIC で「IP 転送を有効化」する必要あり
UDR はサブネット単位で適用、複数サブネットに同じ UDR を関連付け可能

【他選択肢が違う理由】

B. Virtual network gateway: VPN/ExpressRoute Gateway 用、Firewall は別。Gateway 経由でオンプレへ流すときに使用します。
C. Internet: Firewall を経由せず直接インターネットへ。Firewall 強制経路を実現できません。
D. None: パケット破棄、通信不可です。Firewall を経由しないどころか通信そのものを止めます。

【参考】

UDR Next hop type / Azure Firewall + UDR

AZ700-CORE#50 (pid=29663)

AZ700-CORE#58

VPN Gateway を Hub VNet に配置し、Spoke VNet 内の VM がオンプレへ通信できるよう設定したい。VNet ピアリング設定として正しいフラグの組み合わせはどれですか?

A. Hub 側: Allow gateway transit = true、Spoke 側: Use remote gateways = true B. 両方とも Use remote gateways = true C. 両方とも Allow gateway transit = true D. 特別な設定不要

ディスカッション 0

解説

【正解: A】の理由

Gateway Transit は「Hub にゲートウェイがある側 = Allow gateway transit を true」「Spoke がそれを利用する側 = Use remote gateways を true」という対の設定です。これにより Spoke VM が Hub の VPN Gateway 経由でオンプレに到達できるようになります。Spoke 側に独自の VPN Gateway を持たせる必要がなくなり、Gateway リソースのコスト削減と管理集中化が実現します。

【ピアリング Gateway Transit 設定マトリクス】

側	Allow gateway transit	Use remote gateways	説明
Hub (Gateway 保有)	true	false	Gateway を Spoke に貸す
Spoke (Gateway 利用)	false	true	Hub の Gateway を借りる

【Gateway Transit の追加要件】

Hub に VPN Gateway または ExpressRoute Gateway が既にデプロイ済み
VPN Gateway 経由のオンプレルートが BGP または手動で広告されている
Spoke のサブネットに UDR で適切な経路 (オンプレアドレス → VirtualNetworkGateway) が設定されている (BGP の場合自動)
双方の VNet 接続が「Connected」状態

【他選択肢が違う理由】

B. 両方 Use remote gateways: Hub には自身の Gateway があり「リモート」を使う必要なし。両方が「相手の Gateway を使う」と設定するのは矛盾。
C. 両方 Allow gateway transit: Spoke 側に Gateway がないため transit を許可する意味なし。論理的に成立しません。
D. 特別な設定不要: 明示的に対の設定が必要で、デフォルトでは Spoke→オンプレ通信は不可です。Allow virtual network access のみではオンプレ到達できません。

【関連設計上のポイント】

1 つの Spoke が 2 つ以上の Hub に Use remote gateways = true で接続することは制限あり (1 つの Hub からのみ Gateway を借りる)
ExpressRoute と VPN Gateway を Hub に共存させる場合、各 Gateway の優先度設定が必要
BGP を利用すると Gateway 経由の動的ルート広告が Spoke にも自動伝達

【参考】

VNet ピアリング Gateway Transit / VPN Gateway Transit

AZ700-CORE#46 (pid=29659)

AZ700-CORE#54

Azure Private DNS Zone に「VNet リンク」を作成するとき、Auto-registration を有効化できる VNet の数は?

A. 1 つだけ (1 ゾーンにつき 1 VNet) B. 最大 5 個 C. リンクできる VNet すべて D. 制限なし

ディスカッション 0

解説

【正解: A】の理由

Azure Private DNS Zone への VNet リンクで Auto-registration を有効化できるのは 1 ゾーンにつき 1 VNet のみです。Auto-registration は VNet 内の VM の A レコードをゾーンに自動登録する機能で、複数 VNet で有効化すると重複レコードや競合が発生するため設計上 1 VNet のみに制限されています。

【VNet リンクの 2 種類】

リンク種類	動作	制限	用途
Auto-registration あり	VM の A レコード自動登録	1 ゾーンに 1 VNet のみ	VM の内部 FQDN 自動管理
Auto-registration なし (解決のみ)	ゾーン参照のみ可能	制限なし (1000 VNet 上限)	Private Endpoint 解決、他 VNet からの参照

【典型的な構成: Hub-Spoke + Private DNS Zone】

Hub VNet: privatelink.* Private DNS Zone を集中配置
Hub VNet: 内部用 corp.local Zone に Auto-registration リンク (Hub の VM の A レコード自動登録)
Spoke VNet 1〜N: 同じ Private DNS Zone に Auto-registration なしリンク (解決のみ)
これで Spoke の VM も Private DNS Zone を解決可能

【Auto-registration の制限事項】

VM の NIC のプライマリ IP のみ対象 (セカンダリ IP は対象外)
Private Endpoint は対象外 (PE は Private DNS Zone Group で管理)
Azure App Service VNet 統合インスタンスは対象外
A レコードのみ (CNAME、AAAA は手動)

【他選択肢が違う理由】

B, C, D: すべて 1 VNet 制限を超えるため不正解です。複数 VNet で Auto-registration を有効化したい場合は、それぞれ別の Private DNS Zone を作成する必要があります (例: vnet1.local、vnet2.local)。

【参考】

Private DNS Auto-registration / Private DNS 概要

AZ700-CORE#45 (pid=29658)

AZ700-CORE#52

あなたは VNet 内で社内ドメイン corp.contoso.com の名前解決をオンプレ DNS サーバーに転送したいと考えています。VNet 内の VM が Azure 提供 DNS を使い続けつつ、特定ドメインのみオンプレ DNS を使う方法はどれですか?

A. 各 VM の OS で hosts ファイルに静的登録 B. Azure DNS Private Resolver の Outbound Endpoint + Forwarding Ruleset でドメイン別転送 C. VNet のカスタム DNS をオンプレ DNS に変更 D. すべての VM に Public DNS を設定

ディスカッション 0

解説

【正解: B】の理由

Azure DNS Private Resolver の Outbound Endpoint + DNS Forwarding Ruleset を組み合わせると、特定の DNS 名前空間 (例: corp.contoso.com) を指定の宛先 (オンプレ DNS サーバー IP) へ条件付き転送できます。VM は引き続き Azure 提供 DNS を使用し、Resolver が自動的にドメインを判別して転送します。

【DNS Private Resolver の構成コンポーネント】

コンポーネント	方向	用途	専用サブネット
Inbound Endpoint	オンプレ → Azure	オンプレからの DNS クエリ受信	必要 (/28)
Outbound Endpoint	Azure → オンプレ	条件付き転送のソース	必要 (/28、Inbound と別)
Forwarding Ruleset	-	ドメイン別宛先 IP の定義	Ruleset として独立
VNet Link	-	Ruleset を VNet に関連付け	-

【DNS Private Resolver のメリット】

マネージドサービス (VM 不要、可用性 99.99% SLA)
条件付き転送が複数ドメインに対して柔軟に設定可能
Inbound + Outbound 両方向の Hybrid DNS を実現
カスタム DNS サーバー (VM ベース) と異なり、自動スケール + 障害対応

【他選択肢が違う理由】

A. hosts ファイル: VM 単位で運用負担が大きく、変更追従が困難。スケールアウトには適しません。
C. カスタム DNS を変更: 全 VNet が完全にオンプレ DNS 依存になり、Azure サービスの解決 (privatelink.*、azurewebsites.net 等) が不安定化する可能性があります。
D. Public DNS: 内部ドメインは Public DNS では解決できません。corp.contoso.com のような社内ドメインは公開されていません。

【Resolver と従来手法の比較】

手法	可用性	運用負担	条件付き転送
VM ベース DNS フォワーダ (BIND/Windows)	自社運用	高	○
Azure DNS Private Resolver	99.99% SLA	低	○

【参考】

Azure DNS Forwarding Ruleset / DNS Private Resolver 概要

AZ700-CORE#43 (pid=29656)

AZ700-CORE#50

VNet ピアリング設定の "Allow forwarded traffic" を有効化すべきシナリオはどれですか?

A. Hub-Spoke で NVA/Firewall 経由のトラフィックを Spoke が受信する必要がある B. VNet 間で直接通信のみ行いトラフィック転送はしない C. Public Internet からのトラフィックを許可したい D. VPN Gateway 経由のトラフィックのみ許可したい

ディスカッション 0

解説

【正解: A】の理由

"Allow forwarded traffic" は、ピアリング先 VNet から「送信元 IP が当該 VNet 内部ではないトラフィック」を受け入れる設定です。Hub-Spoke + NVA 構成では Spoke→Hub の NVA→他 Spoke のように転送経路を通るため、転送元 NVA が異なる VNet にあると Spoke 受信側でこのフラグを true にする必要があります。

【ピアリング設定フラグの動作完全表】

フラグ	動作	典型用途	既定値
Allow virtual network access	ピア間の VM 通信を許可	常に true	true
Allow forwarded traffic	NVA 経由の転送パケットを受信	Hub-Spoke + NVA で必須	false
Allow gateway transit	この VNet の Gateway を相手に貸す	Hub 側で true	false
Use remote gateways	相手の Gateway を借りる	Spoke 側で true	false

【Hub-Spoke 構成での設定パターン】

方向	Allow forwarded	Allow gateway transit	Use remote gateways
Hub → Spoke	true	true	false
Spoke → Hub	true	false	true

【他選択肢が違う理由】

B. 直接通信のみ: "Allow virtual network access" だけで足り、"Allow forwarded traffic" は不要です。
C. Public Internet 許可: VNet ピアリング設定とは無関係 (NSG/UDR で制御)。Public Internet 通信は VNet の Internet 既定ルートで処理されます。
D. VPN Gateway 経由のみ: これは "Use remote gateways" + "Allow gateway transit" の組み合わせです。

【参考】

VNet ピアリング概要 / Hub-Spoke リファレンス

AZ700-CORE#42 (pid=29655)

AZ700-CORE#48

VNet ピアリングで両 VNet 間のアドレス空間に同一サブネット (例: 両方とも 10.0.0.0/24) が含まれる場合、何が起きますか?

A. ピアリング作成自体が失敗する B. ピアリングは成功するが通信時にエラー C. 重複部分のみ通信不可、それ以外は問題なし D. Azure が自動的にアドレスを変更する

ディスカッション 0

解説

【正解: A】の理由

Azure VNet ピアリングは作成時にアドレス空間の重複をチェックし、重複が検出された場合はピアリング作成が失敗します。これは TCP/IP のルーティング原則上、同一アドレス範囲が複数 VNet に存在するとパケットの宛先が決定できないためです。Azure はこれを事前に検証することで、誤った設定が本番運用に影響することを防いでいます。

【重複時の対処方法】

方法	説明	適用シナリオ
VNet アドレス変更	片方の VNet のアドレス空間を変更 (リソースなしならサブネット削除→再作成)	計画初期、リソース移行可能
VPN Gateway NAT	VPN Gateway の NAT 機能でアドレス変換	合併・買収 (M&A) で重複が避けられない
AVNM IPAM	Azure Virtual Network Manager の IP Address Manager で組織全体の重複防止	大規模組織の予防策
セカンダリ範囲追加	重複 VNet に別の非重複範囲を追加し、リソースを移行	既存運用中の VNet

【ピアリング作成時の検証項目】

アドレス空間の重複なし (CIDR 単位)
双方が同じ Microsoft Entra テナント (異なる場合は特別な権限設定が必要)
両 VNet が Standard SKU リージョン (Government Cloud 等の制約あり)
サブスクリプション間ピアリングは Network Contributor ロール必要

【他選択肢が違う理由】

B. ピアリング成功するがエラー: Azure は作成時に検証するため、ピアリング自体が成立しません。設定段階でエラーが返ります。
C. 重複部分のみ通信不可: そのような部分許可動作はありません。ピアリング自体が成立しないため通信は完全に確立されません。
D. 自動アドレス変更: Azure は顧客の VNet 設定を勝手に変更しません。顧客側で明示的に変更する必要があります。

【参考】

VNet ピアリング制約 / VPN Gateway NAT

AZ700-CORE#39 (pid=29652)

AZ700-CORE#43

Azure SQL Managed Instance を VNet にデプロイする際、サブネットに対して必要な設定はどれですか?

A. サブネットを Microsoft.Sql/managedInstances に Delegation する B. サブネットに Private Endpoint を関連付ける C. NSG を完全に無効化する D. 特別な設定は不要

ディスカッション 0

解説

【正解: A】の理由

SQL Managed Instance は専用のサブネットを必要とし、そのサブネットに対して Microsoft.Sql/managedInstances Delegation を設定する必要があります。これにより Azure が当該サブネットを SQL MI 専用として管理し、適切な内部リソース (Routing、DNS、ストレージ、管理プレーントラフィック) を自動構成します。

【主要 Delegation サービス一覧】

サービス	Delegation 名	サブネット要件
SQL Managed Instance	Microsoft.Sql/managedInstances	専用 /27 推奨
App Service VNet 統合	Microsoft.Web/serverFarms	専用 /28 以上
Container Instances	Microsoft.ContainerInstance/containerGroups	専用 /29 以上
PostgreSQL Flexible Server	Microsoft.DBforPostgreSQL/flexibleServers	専用 /28 以上
MySQL Flexible Server	Microsoft.DBforMySQL/flexibleServers	専用 /28 以上
Spring Apps	Microsoft.AppPlatform/Spring	専用 /28 以上

【SQL MI Delegation の動作】

サブネットは SQL MI 専用 (他のリソースを配置不可)
Azure が自動で内部 Load Balancer、Backup Storage アクセス用ルートを構成
Network Intent Policy が自動付与される
サブネット削除時に Delegation 解除が必要

【他選択肢が違う理由】

B. Private Endpoint: SQL MI は VNet 統合型のため Private Endpoint ではなく Delegation を使用します (Azure SQL DB は逆に PE 使用)。
C. NSG 無効化: NSG は必要、ただし SQL MI 用の管理トラフィック (Microsoft 管理プレーン) を許可するルールが自動付与されます。完全無効化は推奨されません。
D. 設定不要: Delegation 設定なしでは SQL MI デプロイは「サブネットが委任されていない」エラーで失敗します。

【参考】

サブネット委任 / SQL MI 接続アーキテクチャ

AZ700-CORE#37 (pid=29650)

AZ700-CORE#41

Azure サブネットを作成済み VM がある状態で、サブネットプレフィックスを縮小 (例: /24 → /25) しようとしたところエラーになりました。原因として最も適切なものはどれですか?

A. Azure VNet ではサブネットの縮小は既存リソースがある場合許可されない B. /24 から /25 への縮小は Azure では一切不可能 C. サブネット内のすべての VM を停止すれば縮小可能 D. NSG をデタッチしないとサイズ変更不可

ディスカッション 0

解説

【正解: A】の理由

2024 年以降の Azure では、リソースが存在するサブネットの拡張は条件付きで可能になりましたが、縮小は既存リソースの IP が縮小後の範囲外になる可能性があるため許可されていません。VM・NIC・Private Endpoint 等が存在しない状態にしてから縮小操作を行う必要があります。

【サブネットサイズ変更の制約マトリクス】

操作	VM/NIC あり	VM/NIC なし	備考
拡張 (/24 → /23)	条件付き可	可	新範囲が既存と互換
縮小 (/24 → /25)	不可	可	IP 範囲外の検証
アドレス開始位置変更	不可	可	全 IP リセット
名前変更	不可	不可	削除して再作成必要

【他選択肢が違う理由】

B. 一切不可能: リソースを削除すれば縮小可能です。
C. VM 停止のみ: 停止しても NIC は残るため、NIC の IP が縮小範囲外の場合は不可能です。NIC を削除する必要があります。
D. NSG デタッチ: NSG とサブネットサイズ変更は無関係です。

【ベストプラクティス: アドレス計画の見直し時】

変更前にサブネット内のすべてのリソース (VM、NIC、PE、Bastion 等) をリスト化
新サブネットを別範囲で作成
リソースを段階的に移行 (NIC の再作成、VM の再デプロイ)
旧サブネットを削除
必要に応じて新サブネットを旧範囲にリネーム

【参考】

サブネット管理 / VNet FAQ

AZ700-CORE#36 (pid=29649)

AZ700-CORE#38

あなたは Azure VPN Gateway を Active-Active モードでデプロイする予定です。BGP も併用し、将来的に ExpressRoute Gateway も同一 VNet に共存させる可能性があります。GatewaySubnet として推奨される最小プレフィックスサイズはどれですか?

A. /29 (8 アドレス) B. /28 (16 アドレス) C. /27 (32 アドレス) D. /24 (256 アドレス)

ディスカッション 0

解説

【正解: C】の理由

Microsoft 公式は GatewaySubnet に /27 以上を推奨しています。Active-Active 構成では 2 インスタンスの Gateway がそれぞれ IP を必要とし、BGP ピアリング用 IP、Azure 内部用予約 IP、将来の Gateway SKU アップグレード予備、ExpressRoute Gateway 共存時の追加 IP を考慮すると /27 (32 アドレス) が安全です。

【サイズ要件詳細比較】

サイズ	利用可能 IP	Active-Standby	Active-Active	+ ER 共存
/29	3	○ (最低限)	△ (BGP 共存厳しい)	×
/28	11	○	○	△
/27	27	○	○	○ (推奨)
/24	251	○	○	○ (浪費)

【他選択肢が違う理由】

A. /29: Active-Active + BGP では IP 数が不足する可能性あり。最小 Active-Standby なら動作するが推奨外。
B. /28: Active-Active で機能しますが、将来の SKU 変更や ExpressRoute Gateway 共存で予備が枯渇しやすい。
D. /24: 機能上問題ないが大幅なアドレス浪費 (VNet 全体のアドレス計画から見ても過大)。

【設計時の注意点】

GatewaySubnet 名は固定 (変更不可)
NSG を GatewaySubnet に関連付けると問題が起きるケースあり (Microsoft 推奨は NSG 関連付けなし)
UDR を関連付けた場合、Azure 内部管理トラフィックを誤って遮断しないよう注意
Azure VPN Gateway は 30 分以上のデプロイ時間が必要

【参考】

GatewaySubnet サイズ要件 / VPN Gateway 概要

AZ700-CORE#35 (pid=29648)

AZ700-CORE#37

あなたは新規 Azure VNet を設計しており、アドレス空間として 10.0.0.0/8 を使いたいと考えています。次のうち、Azure VNet のアドレス空間として有効な範囲はどれですか?

A. 10.0.0.0/8 (RFC 1918) B. 172.16.0.0/12 (RFC 1918) C. 192.168.0.0/16 (RFC 1918) D. すべて有効、加えて Public IP 範囲も指定可能

ディスカッション 0

解説

【正解: D】の理由

Azure VNet のアドレス空間は RFC 1918 (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16) が一般的ですが、Public IP 範囲や 100.64.0.0/10 (Carrier-grade NAT、SP NAT 範囲) なども指定可能です。重要なのは「他の Azure VNet とのピアリング先と重複しないこと」「オンプレネットワークとの重複を避けること」「Azure 予約範囲 (マルチキャスト、ブロードキャスト等) を含まないこと」です。

【他選択肢が違う理由】

A, B, C 単独: いずれも有効ですが、RFC 1918 以外も指定可能なので「すべて + Public 範囲」が最も正確な答えです。

【Azure で許可されない予約範囲】

範囲	用途	使用可否
224.0.0.0/4	マルチキャスト	不可
255.255.255.255/32	ブロードキャスト	不可
127.0.0.0/8	ループバック	不可
169.254.0.0/16	リンクローカル	不可
168.63.129.16/32	Azure 内部 DNS	不可

【VNet アドレス計画ベストプラクティス】

Hub-Spoke 全体で /16 を確保し、Hub /20 + 各 Spoke /20 のように階層分割
将来の Bastion (/26)、Firewall (/26)、AppGW (/24)、Gateway (/27) 用の専用範囲を予約
オンプレと完全に分離した範囲 (例: 10.10.0.0/16) を選択し重複を避ける
IPv4 + IPv6 デュアルスタックをサポート、IPv6 は /48 以上推奨

【参考】

VNet で使えるアドレス範囲 (FAQ) / VNet 計画と設計

AZ700-CORE#23 (pid=29646)

AZ700-CORE#25

あなたは Spoke VNet の全アウトバウンドを Hub VNet の Azure Firewall 経由にしたい。最も適切な手段はどれですか?

A. Spoke の各 VM に Public IP を割り当てる B. Spoke サブネットの UDR で 0.0.0.0/0 → Next Hop: Azure Firewall プライベート IP を設定 C. Spoke の VNet Peering を削除する D. Spoke を Hub にマージする

ディスカッション 0

解説

【正解: B】の理由

UDR (User-Defined Route) で 0.0.0.0/0 のデフォルトルートを Next Hop: Virtual appliance (Azure Firewall のプライベート IP) に向けることで、すべてのアウトバウンドトラフィックを Hub の Firewall に強制 (Forced Tunneling) できます。

【UDR 設定例】

項目	値
Address prefix	0.0.0.0/0
Next hop type	Virtual appliance
Next hop address	Azure Firewall プライベート IP (例: 10.0.1.4)

【他選択肢が違う理由】

A. 各 VM に Public IP: VM が直接インターネットに出るため Firewall を経由せず、要件不一致 + セキュリティ低下。
C. ピアリング削除: 削除すると Hub と通信できなくなり、Firewall も経由できません。
D. マージ: VNet マージは Azure では非対応です。

【参考】

Azure Firewall + Forced Tunneling

AZ700-CORE#21 (pid=29644)

AZ700-CORE#22

Azure Route Server について、正しい記述はどれですか?

A. Network Virtual Appliance (NVA) と Azure の Software-Defined Network 間で BGP ルートを交換する B. 静的ルート (UDR) のみを管理する集中サービス C. DNS ルーティング専用 D. Public DNS の権威サーバー

ディスカッション 0

AZ700-CORE#19 (pid=29642)

AZ700-CORE#19

異なる Azure リージョン (East US と West Europe) の 2 つの VNet を、Microsoft バックボーン経由で約 200 ms のレイテンシ目標でフラット接続したい。最も適切な技術はどれですか?

A. Site-to-Site VPN B. Regional VNet Peering C. Global VNet Peering D. ExpressRoute Direct

ディスカッション 0

AZ700-CORE#18 (pid=29641)

AZ700-CORE#18

Azure DNS Public Zone と Private Zone について、正しい記述はどれですか?

A. Public Zone のレコードはインターネット経由で誰でも解決可、Private Zone はリンクされた VNet 内のみ解決可 B. 両方とも VNet リンクが必要 C. Public Zone は IPv4 のみ、Private Zone は IPv6 専用 D. Private Zone は Azure サブスクリプション間で共有不可

ディスカッション 0

解説

【正解: A】の理由

Azure DNS の Public Zone はインターネット側に向けた権威 DNS サービスで、Web 公開ドメイン (例: contoso.com) のホスティングに使われます。Private Zone は VNet 内部からのみ解決可能で、内部用ドメイン (例: corp.local) や Private Endpoint 連携に使われます。

【比較表】

項目	Public Zone	Private Zone
解決スコープ	インターネット全体	リンクされた VNet 内のみ
VNet リンク	不要	必要
用途	Web 公開ドメイン	内部用 / Private Endpoint
レコードタイプ	A/AAAA/CNAME/MX/TXT/NS 等	同上 (制約あり)

【他選択肢が違う理由】

B. 両方 VNet リンク必要: Public Zone には VNet リンクは不要です。
C. IPv4/IPv6 専用区分: 両方とも IPv4/IPv6 両対応です。
D. サブスクリプション間共有不可: VNet ピアリングまたは共有で複数サブスクリプションから利用可能です。

【参考】

Azure DNS 概要

AZ700-CORE#16 (pid=29639)

AZ700-CORE#15

Azure Private DNS Zone に VNet を「自動登録 (auto-registration)」付きでリンクすると、何が起きますか?

A. リンク先 VNet 内の VM の A レコードがゾーンに自動登録される B. リンク先 VNet 内の全リソースの Public IP がゾーンに登録される C. Private Endpoint のレコードのみが登録される D. 登録は行われず、リンクのみ確立される

ディスカッション 0

AZ700-CORE#14 (pid=29637)

AZ700-CORE#10

Azure VNet 内の VM がデフォルトで使用する DNS 解決サービスはどれですか?

A. Azure 提供 DNS (168.63.129.16) B. パブリックリゾルバ (8.8.8.8) C. オンプレ DNS サーバー D. Microsoft Entra ID DNS

ディスカッション 0

解説

【正解: A】の理由

Azure VNet 内の VM は既定で Azure が提供する仮想 DNS リゾルバ (Azure-provided DNS) を使用し、その IP は 168.63.129.16 です。この IP は Azure のすべての VNet で共通で、内部用の予約アドレスです。VNet 内の名前解決 (azurewebsites.net 等の Azure サービス) やインターネット名前解決を担当します。

【DNS カスタマイズオプション】

レベル	設定方法
VNet レベル	VNet > DNS サーバー > カスタム
NIC レベル	NIC > DNS サーバー (VNet をオーバーライド)
VM OS レベル	OS 設定 (DHCP オーバーライド)

【参考】

IP アドレス 168.63.129.16 とは / VNet の名前解決

AZ700-CORE#13 (pid=29636)

AZ700-CORE#23

あなたは複数 VNet 間でアドレス空間の重複を避ける必要があります。Azure Virtual Network Manager の機能のうち、組織全体のアドレス計画を集中管理できる機能はどれですか?

A. Network Group B. IP Address Manager (IPAM) C. Mesh Connectivity D. Hub and Spoke Topology

ディスカッション 0

解説

【正解: B】の理由

Azure Virtual Network Manager (AVNM) の IPAM 機能は、組織全体の VNet アドレス空間を集中管理し、重複を予防する機能を提供します。プール定義、サブプール、自動割り当てを含みます。

【AVNM 主要機能】

機能	用途
Network Group	VNet を動的にグループ化
Connectivity 構成	Mesh / Hub-Spoke の集中管理
Security Admin Rules	NSG より優先される強制ルール
IPAM	アドレス計画の集中管理

【他選択肢が違う理由】

A. Network Group: VNet のグルーピングで、アドレス計画ではありません。
C. Mesh Connectivity: VNet 間 Mesh 接続で、アドレス計画ではありません。
D. Hub and Spoke: トポロジパターンの一種で、アドレス計画ではありません。

【参考】

AVNM IP Address Management

AZ700-CORE#11 (pid=29634)

AZ700-CORE#1

Public IP Prefix (Azure マネージドの連続 Public IP 範囲) を作成する主な利点はどれですか?

A. Public IP の通信料金が無料になる B. 連続したアドレス範囲をまとめて確保でき、ファイアウォール許可リスト管理がシンプルになる C. Public IP の数が無制限になる D. プライベート IP もまとめて確保できる

ディスカッション 0

AZ700-CORE#9 (pid=29632)

AZ700-CORE#102

あなたは Azure Bastion を VNet にデプロイします。Bastion 用サブネットの正しい命名とサイズ要件はどれですか?

A. 任意の名前のサブネット、/28 以上 B. AzureBastionSubnet という名前固定、/26 以上 C. BastionSubnet という名前固定、/27 以上 D. GatewaySubnet を共有可能、/29 以上

ディスカッション 0

AZ700-CORE#7 (pid=29630)

AZ700-CORE#81

Standard SKU の Public IP アドレスについて、正しい説明はどれですか?

A. 割り当ては動的のみで、リソース停止で IP が変わる B. 割り当ては静的のみで、明示的に削除されるまで保持される C. ゾーン冗長または特定ゾーンへの関連付けが可能 D. NSG ルールなしで全インバウンドが許可される

ディスカッション 0

解説

【正解: C】の理由

Standard SKU の Public IP は割り当てが「Static のみ」、ゾーン冗長 (3 ゾーン) または特定ゾーン (zone 1/2/3) への関連付けが可能、デフォルトで全インバウンドが拒否、という特徴を持ちます。Basic SKU はゾーン非対応で、デフォルトで全インバウンドが許可されます。

【Standard と Basic の比較】

項目	Standard	Basic (廃止予定)
割り当て	Static のみ	Dynamic / Static
ゾーン	○ (冗長 or 特定)	×
既定セキュリティ	全拒否	全許可
SLA	99.99%	なし

【他選択肢が違う理由】

A. 動的のみ: Basic SKU の特徴で、Standard は Static のみです。
B. 静的のみは正解だが説明不足: 「割り当ては静的のみ」は正しいが C のゾーン特性が Standard の最大の特徴です。
D. 全インバウンド許可: Standard はデフォルト拒否です。

【参考】

Public IP アドレス / Basic Public IP 廃止と移行

AZ700-CORE#5 (pid=29628)

AZ700-CORE#56

VNet 内の各サブネットでは Azure が予約しているアドレスが存在します。/24 (256 アドレス) のサブネットで実際に VM/PaaS に割り当て可能なアドレス数はいくつですか?

A. 256 B. 254 C. 251 D. 250

ディスカッション 0

解説

【正解: C】の理由

Azure はサブネットごとに先頭の 5 アドレスを予約しています。/24 = 256 アドレスから 5 を引いて 251 アドレスが利用可能です。

【Azure 予約アドレス 5 個】

オフセット	用途
x.x.x.0	ネットワークアドレス
x.x.x.1	Azure 既定ゲートウェイ
x.x.x.2	Azure DNS 用 (VNet 内)
x.x.x.3	Azure 将来用
x.x.x.255	ブロードキャスト相当 (予約)

【他選択肢が違う理由】

A. 256: 予約を考慮していません。
B. 254: 従来の IP サブネット計算 (network + broadcast の 2 個減算) で、Azure 固有の予約 5 個を加味していません。
D. 250: 4 個減算で計算違いです。

【参考】

Virtual Network FAQ - 予約アドレス

AZ700-CORE#4 (pid=29627)

AZ700-CORE#46

あなたは新規 VNet 10.10.0.0/16 を作成し、その中に Azure VPN Gateway をデプロイする予定です。Microsoft が推奨する GatewaySubnet の最小プレフィックスサイズはどれですか?

A. /24 (256 アドレス) B. /27 (32 アドレス) C. /28 (16 アドレス) D. /30 (4 アドレス)

ディスカッション 0

AZ-700-CORE#2 (pid=29620)

AZ-700-CORE#2

あなたの 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 宛のパケットは、どの経路が選択されますか?

A. (1) System default (Internet) B. (2) BGP via ExpressRoute C. (3) UDR via Azure Firewall D. (4) VNet Peering (VirtualNetwork)

ディスカッション 0

解説

【正解: 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 に向ける

【参考】

UDR とルーティング

🟠 multi_choice (複数選択、選択肢 3 個) (10 問)

AZ700-CORE#144 (pid=29761)

AZ700-CORE#39

Azure Front Door Premium の Standard SKU に対する追加機能を 2 つ選んでください。

2 つ選択してください

A. Private Link 経由でオリジン (Web App、Internal LB) にプライベート接続 B. Microsoft マネージド WAF Rule Set (Microsoft DRS + Bot Manager) C. グローバル CDN D. カスタムドメインサポート E. TLS Termination

ディスカッション 0

解説

【正解: A, B】の理由

Front Door Premium が Standard に追加する主要機能: (A) Private Link 経由オリジン接続 (Zero Trust、オリジンの Public 公開不要)、(B) Microsoft マネージド WAF (DRS + Bot Manager + API Security)。これらは Premium 専用です。

【Front Door SKU 比較】

機能	Standard	Premium
グローバル CDN	○	○
カスタムドメイン	○	○
TLS Termination	○	○
Private Link オリジン	×	○
Microsoft DRS	×	○
Bot Manager	×	○
API Security	×	○

【誤りの根拠】

C, D, E: すべて両 SKU で利用可能、Premium 専用ではない。

【参考】

Front Door Standard/Premium

【Front Door Premium 価値】

機能	影響
Private Link オリジン	Zero Trust (オリジン Public 公開不要)
Microsoft DRS WAF	OWASP + Microsoft 独自シグネチャ
Bot Manager	Bot トラフィック分類 + ブロック
API Security	OWASP API Top 10 対応

【コスト比較例】

Standard: $35/月 + データ転送
Premium: $330/月 + データ転送
多くの本番 Web アプリは Premium が必須 (Private Link + WAF 両方)

Front Door SKU

AZ700-CORE#143 (pid=29760)

AZ700-CORE#26

AKS で Azure CNI (Pod が VNet IP) を選択する主な利点を 2 つ選んでください。

2 つ選択してください

A. Pod が VNet 内 PaaS リソース (Private Endpoint、Service Bus) に NAT なしで直接通信可能 B. Azure NPM (Network Policy Manager) で L3-L4 ネットワークポリシーを実装可能 C. VNet サブネットを最小サイズ /29 で構築可能 D. NAT パフォーマンスが向上する E. Pod がインターネット直接公開される

ディスカッション 0

解説

【正解: A, B】の理由

Azure CNI の主要利点は (A) Pod が VNet サブネット IP を直接取得し、VNet 内 PaaS と NAT なしで通信可能 (例: Private Endpoint への直接アクセス)、(B) Azure NPM/Calico/Cilium で Network Policy (L3-L4) 実装可能です。

【誤りの根拠】

C. /29 最小: CNI は大規模サブネット (/22 以上) 必要。/29 では Pod 数不足。
D. NAT パフォーマンス向上: CNI は NAT を排除、NAT が発生しないため NAT パフォーマンスは関係なし (NAT そのものがない)。
E. インターネット公開: Pod は内部 IP、インターネット公開には別途 LB/Ingress が必要。

【CNI vs Kubenet 比較】

項目	Kubenet	Azure CNI
VNet 内 PaaS と直接通信	× (NAT 経由)	○
必要 IP	少ない	多い (Pod × Node)
Network Policy	Calico のみ	Calico / Azure / Cilium
パフォーマンス	NAT オーバーヘッド	最高

【参考】

AKS Network

【Azure CNI vs Kubenet 詳細比較】

項目	Kubenet	Azure CNI
Pod IP 範囲	オーバーレイ (10.244.0.0/16 等)	VNet サブネット
必要 IP	少 (Node 数のみ)	多 (Pod × Node)
VNet 内通信	NAT 経由	直接
UDR/NSG 影響	Node のみ	Pod 単位
Windows ノード	限定	○
将来性	廃止予定	推奨

【Azure CNI Overlay (最新)】

2023 GA、Pod がオーバーレイ範囲 (任意 CIDR) + Node が VNet IP の Hybrid。IP 節約 + CNI 機能を両立。

AKS Network

AZ700-CORE#142 (pid=29759)

AZ700-CORE#16

Azure Network Insights (Azure Monitor for Networks) で利用できる機能を 2 つ選んでください。

2 つ選択してください

A. ネットワークリソース間の依存関係可視化 (Functional Dependency View) B. Diagnostic Toolkit (Network Watcher 各ツールへの統合 UI) C. NSG ルール自動生成 D. Public IP の購入 E. BGP ルートの動的編集

ディスカッション 0

解説

【正解: A, B】の理由

Network Insights は Azure 上のネットワークリソースの統合監視 + 可視化ダッシュボード。主要機能として (A) Functional Dependency View でリソース間依存を可視化、(B) Diagnostic Toolkit で Network Watcher の各ツール (IP Flow Verify、Connection Monitor、Packet Capture 等) にダッシュボードから直接アクセス可能です。

【Network Insights 主要機能】

機能	用途
Functional Dependency View	リソース依存関係可視化
Health Dashboard	全ネットワークリソースの健全性
Topology View	VNet ピアリング + サブネット可視化
Diagnostic Toolkit	Network Watcher 統合 UI
Connectivity	Connection Monitor 結果集約
Traffic	NSG Flow Logs / Traffic Analytics 集約

【誤りの根拠】

C. NSG 自動生成: Network Insights は監視機能、ルール生成はしない。
D. Public IP 購入: リソース管理機能ではない。
E. BGP 編集: Gateway リソース管理の領域。

【参考】

Network Insights

【Network Insights が統合する情報源】

情報源	用途
Azure Resource Graph	リソースインベントリ + 依存関係
Azure Monitor Metrics	パフォーマンス + 健全性
Network Watcher	診断ツール統合
NSG Flow Logs / Traffic Analytics	トラフィック可視化
Connection Monitor	接続性監視

【典型 Workbook】

VNet Topology Workbook
VPN Gateway Health Workbook
ExpressRoute Workbook
WAF Workbook

Network Insights

AZ700-CORE#79 (pid=29694)

AZ700-CORE#106

AKS クラスタで Pod から Azure Storage への通信を「VNet 内プライベート」に保ちたい。組み合わせとして適切なものを 2 つ選んでください。

2 つ選択してください

A. AKS を Azure CNI (Pod が VNet IP) + Storage に Private Endpoint 作成 B. AKS を Kubenet (NAT 経由) + Storage を Public IP のみ C. AKS のサブネットに Storage Service Endpoint 有効化 + Storage Firewall で VNet 許可 D. Pod に Public IP を直接付与 E. AKS Cluster を Public、Storage を Public でアクセス

ディスカッション 0

解説

【正解: A, C】の理由

AKS Pod → Azure Storage のプライベート通信には 2 つの主要パターンがあります: (A) Azure CNI + Private Endpoint で完全プライベート IP 経路、(C) Service Endpoint + Storage Firewall でバックボーン経由の VNet 限定アクセス。どちらも Public Internet 経由を排除し、セキュリティ要件を満たします。

【パターン比較】

項目	A: CNI + PE	C: SE + Firewall
Pod IP	VNet IP	VNet IP (Azure CNI) または Node NAT (Kubenet)
Storage IP	Private IP (10.x)	Public IP (Microsoft IP)
DNS	Private DNS Zone	Public DNS
オンプレからのアクセス	可 (VPN/ER)	不可
料金	PE 単位 (有償)	SE 無料
細粒度制御	PE = Storage Account 単位	SE Policy で Storage 単位

【AKS + Storage プライベートアクセスのベストプラクティス】

AKS Cluster を Azure CNI で構築 (Pod が VNet IP)
AKS サブネットを別途専用に配置 (NSG 制御しやすく)
Storage Account に Private Endpoint を AKS サブネットに作成
Storage Account の Public Network Access を Disabled
Private DNS Zone (privatelink.blob.core.windows.net) を VNet にリンク
Pod から Storage への通信を NetworkPolicy で制御 (Calico/Azure NP)

【誤りの根拠】

B. Kubenet + Public IP: NAT 経由 + Public IP は最もセキュリティ脆弱な構成します。「VNet 内プライベート」の要件不一致。
D. Pod Public IP: Pod に Public IP を付与する標準的な方法は存在せず (Cluster の Public IP とは別の話)、要件不一致。
E. すべて Public: セキュリティ要件と完全に逆の構成します。

【参考】

AKS Private Cluster / Private Endpoint

AZ700-CORE#68 (pid=29683)

AZ700-CORE#95

Service Endpoint がサポートする Azure サービスを 2 つ選んでください。

2 つ選択してください

A. Azure Storage (Blob/File/Queue/Table) B. Azure SQL Database C. Azure Functions (Consumption Plan) D. Azure Bastion E. Azure DNS Public Zone

ディスカッション 0

解説

【正解: A, B】の理由

Service Endpoint は Azure Storage、Azure SQL Database、Azure Cosmos DB、Key Vault、Service Bus、Event Hubs 等の主要 PaaS サービスに対応しています。サブネット側で SE を有効化し、サービス側で VNet ID 許可リストに追加することで Azure バックボーン経由の最適化通信が実現します。

【Service Endpoint 対応サービス一覧】

サービス	SE タグ名
Azure Storage	Microsoft.Storage
Azure SQL Database / Synapse	Microsoft.Sql
Azure Cosmos DB	Microsoft.AzureCosmosDB
Key Vault	Microsoft.KeyVault
Service Bus	Microsoft.ServiceBus
Event Hubs	Microsoft.EventHub
App Service	Microsoft.Web
Cognitive Services	Microsoft.CognitiveServices
Container Registry	Microsoft.ContainerRegistry

【誤りの根拠】

C. Azure Functions (Consumption): Functions Consumption Plan は SE 非対応 (Premium/Dedicated Plan なら VNet 統合可)。
D. Azure Bastion: Bastion はサブネット (AzureBastionSubnet) 上のサービスで、SE 対象外。VNet 内専用のため SE 不要。
E. Azure DNS Public Zone: Public DNS はインターネット公開サービスで、SE の概念対象外。

【Service Endpoint と Private Endpoint の選択指針】

要件	推奨
VNet 内のみアクセス制限したい	SE で十分
オンプレからもプライベートアクセスしたい	PE 必須
サービスの IP を VNet 内 IP にしたい	PE 必須
細粒度 (特定 Storage Account のみ等)	SE Policy + SE、または PE
低コスト	SE (PE は有償)

【参考】

Service Endpoint 概要

AZ700-CORE#54 (pid=29667)

AZ700-CORE#83

Azure Virtual Network Manager (AVNM) で Hub-Spoke トポロジを管理する際の利点を 2 つ選んでください。

2 つ選択してください

A. Network Group の動的メンバーシップ (タグベースで自動 VNet 追加) B. Connectivity 構成で N×N の手動ピアリング作成を自動化 C. NSG ルールを完全に置き換える D. VPN Gateway を自動デプロイする E. Public IP の管理機能

ディスカッション 0

解説

【正解: A, B】の理由

AVNM の Hub-Spoke 管理の主要利点は (1) Network Group の動的メンバーシップ (Azure Policy 風のタグ評価で VNet を自動所属) と (2) Connectivity 構成で 1 回設定するだけで N 個の Spoke ピアリングを自動構築できる点です。大規模な VNet 環境 (50+ VNet) では手動でのピアリング管理は破綻するため、AVNM が標準解になります。

【AVNM の主要機能】

機能	用途	典型シナリオ
Network Group	VNet の動的グループ化	「dev タグ持つ VNet を自動所属」
Connectivity 構成	Hub-Spoke / Mesh の集中管理	「Hub に対し全 Spoke を自動ピアリング」
Security Admin Rules	NSG より優先のテナントレベルルール	「Port 3389 を組織全体で遮断」
IPAM	アドレス空間集中管理	「重複しない CIDR 自動払い出し」

【AVNM の Connectivity 構成パターン】

Hub-Spoke: 1 つの Hub に対し N 個の Spoke を自動ピアリング
Mesh: すべての VNet 間で双方向ピアリング
Hub-Spoke with Direct Connectivity: Hub-Spoke + Spoke 間直接接続オプション
Cross-region: 複数リージョン間の Global ピアリング統合

【誤りの根拠】

C. NSG を置き換え: NSG は併用し、Security Admin Rules は NSG 上書きですが置き換えではありません。階層的に Security Admin → NSG → ASG の順で評価されます。
D. VPN Gateway 自動デプロイ: AVNM は VPN Gateway の自動デプロイは行いません。Gateway は ARM テンプレート / Bicep / Terraform 等別途デプロイ。
E. Public IP 管理: Public IP は別リソース、AVNM の機能ではありません。Public IP Prefix は別途管理します。

【AVNM 適用規模目安】

VNet 数	推奨ツール
1〜10	手動ピアリング (簡素)
10〜50	ARM テンプレート / Bicep
50+	AVNM (集中管理が必須)

【参考】

AVNM 概要 / AVNM Connectivity

AZ700-CORE#48 (pid=29661)

AZ700-CORE#72

VNet のカスタム DNS サーバー設定 (Azure 提供 DNS の代わりに独自 DNS を指定) を使うべきシナリオを 2 つ選んでください。

2 つ選択してください

A. オンプレの Active Directory (AD) 統合された VM の名前解決が必要 B. すべての DNS クエリを社内 DNS サーバー経由で監査ログ取得したい C. azurewebsites.net などの Azure サービスのみ解決したい D. Public DNS のみ使いたい E. 特定ドメインだけオンプレに転送したい (他は Azure 既定)

ディスカッション 0

解説

【正解: A, B】の理由

カスタム DNS の主な用途は (1) オンプレ AD ドメイン参加 VM の名前解決 (DC 上の DNS を参照)、(2) 全 DNS クエリの集中監査・ロギングが必要なケースです。これらでは VNet レベルで「すべてのクエリ」を社内 DNS にルーティングします。

【カスタム DNS の設定階層】

レベル	設定箇所	影響範囲
VNet レベル	VNet > DNS サーバー > カスタム	VNet 全体のすべての NIC
NIC レベル	NIC > DNS サーバー	その NIC のみ (VNet 設定を上書き)
VM OS レベル	OS DHCP 設定	その VM のみ (NIC/VNet を上書き)

【カスタム DNS vs Private Resolver 比較】

要件	カスタム DNS	Private Resolver + Ruleset
すべてのクエリを社内 DNS	○ (推奨)	△ (可能だが過剰)
特定ドメインのみ転送	×	○ (推奨)
双方向 (オンプレ↔Azure) 解決	△ (オンプレ側設定必要)	○
マネージド (障害対応自動)	×	○
運用コスト	高 (VM 運用)	低 (PaaS)

【誤りの根拠】

C. Azure サービスのみ: Azure 提供 DNS (168.63.129.16) が既定で対応します。カスタム DNS を設定する必要はありません。
D. Public DNS のみ: Public DNS では Azure 内部リソース (Private Endpoint、Azure サービスの内部 IP) が解決できません。
E. 特定ドメインだけ転送: このケースは Azure DNS Private Resolver + Forwarding Ruleset を使うべきで、VNet 全体のカスタム DNS は過剰です。

【参考】

VNet 名前解決 / DNS Private Resolver

AZ700-CORE#40 (pid=29653)

AZ700-CORE#62

Custom IP Prefix (BYOIP) を Azure に持ち込む際の前提条件として正しいものを 2 つ選んでください。

2 つ選択してください

A. IRR (Internet Routing Registry) で ROA (Route Origin Authorization) を登録する B. プレフィックスの所有権を証明する署名付き認証メッセージを Azure に提出する C. Microsoft が無料で IP を割り当てる D. プレフィックスは IPv6 のみ対応 E. Provider Edge (PE) ルーター設定は Microsoft が代行する

ディスカッション 0

解説

【正解: A, B】の理由

BYOIP の前提条件は (1) ROA を IRR に登録して所有権を公的に証明、(2) 署名付き認証メッセージ (X.509 証明書ベース) を Azure に提出、の 2 点が中核です。これにより Microsoft は「あなたが本当にこのプレフィックスの所有者である」ことを検証してから Azure バックボーンからのアドバタイズを許可します。

【BYOIP の全前提条件】

所有プレフィックスサイズ: /24 以上 (IPv4)、/64 以上 (IPv6)
RIR (ARIN/RIPE/APNIC 等) での所有権登録済み
IRR で ROA 登録 (Route Origin Authorization)
署名付き認証メッセージ提出 (X.509 証明書)
Microsoft の内部検証完了 (数日〜1 週間)
Azure Public IP Prefix としてのリソース登録

【BYOIP プロセスの全体フロー】

順序	作業	所要
1	ROA を IRR に登録	1〜2 日
2	署名付き認証メッセージ作成 + Azure 提出	即時
3	Custom IP Prefix リソース作成 (Provisioning 状態)	即時
4	Microsoft 検証 (Provisioning → Provisioned)	数日〜1 週間
5	Commissioned 状態に切替 + アドバタイズ開始	即時
6	個別 Public IP として払い出し利用	即時

【誤りの根拠】

C. 無料割り当て: BYOIP は「持ち込み」、Microsoft が IP を割り当てるのではなく顧客所有 IP を Azure で使用します。料金は Public IP 利用料がかかります。
D. IPv6 のみ: IPv4 と IPv6 両方対応です。
E. PE 設定代行: BYOIP は Azure 内のアドバタイズに関する仕組みで、顧客側 PE ルーター設定はあれば顧客側で実施します。Microsoft は代行しません。

【BYOIP のユースケース】

顧客所有の固定 Public IP プールを Azure で利用
SaaS Allowlist 維持 (顧客サービスから見て IP が変わらない)
SEO/SSL 証明書の維持 (IP に紐づく)

【参考】

Custom IP Address Prefix (BYOIP) / BYOIP ポータル操作

AZ700-CORE#24 (pid=29647)

AZ700-CORE#49

VNet ピアリング (Regional) の制限について、正しい記述を 2 つ選んでください。

2 つ選択してください

A. ピアリングは推移しない (A↔B、B↔C ピアでも A↔C は直接通信不可) B. ピアリングは推移する (A↔B、B↔C で A↔C 通信可) C. 1 つの VNet は最大 500 ピアリングを持てる (Azure 既定上限) D. ピアリング先 VNet のアドレス空間が重複していてもピアリング可能 E. ピアリング先 VNet のアドレス空間は重複してはいけない

ディスカッション 0

AZ700-CORE#10 (pid=29633)

AZ700-CORE#5

Subnet Delegation について、適切な用途を 2 つ選んでください。

2 つ選択してください

A. Azure SQL Managed Instance のサブネット占有 B. Azure Container Instances の VNet 統合 (Microsoft.ContainerInstance/containerGroups) C. Azure Storage Account 用の専用ネットワーク D. VM の NIC 割り当て E. Public IP の予約

ディスカッション 0

解説

【正解: A, B】の理由

Subnet Delegation は、特定の Azure PaaS サービスにサブネットを「占有的に使わせる」設定です。SQL Managed Instance や Container Instances (ACI)、App Service (VNet 統合)、Database for PostgreSQL Flexible Server 等が代表例です。

【代表的な Delegation サービス】

サービス	Delegation 名
SQL Managed Instance	Microsoft.Sql/managedInstances
Container Instances	Microsoft.ContainerInstance/containerGroups
App Service 統合	Microsoft.Web/serverFarms
PostgreSQL Flexible	Microsoft.DBforPostgreSQL/flexibleServers

【誤りの根拠】

C. Storage Account: Storage は Private Endpoint や Service Endpoint で接続するもので、Delegation サービスではありません。
D. VM NIC: VM NIC は通常のサブネット内アドレスを使用し Delegation は不要です。
E. Public IP: Public IP はサブネットではなくリソース単位で予約します。

【参考】

サブネット委任の概要

【ベストプラクティス】

Microsoft 公式ドキュメントに記載された推奨手順を遵守
本番環境では事前に Test/Dev 環境で検証
変更管理プロセスに従い、段階的な展開を実施
監視 + アラートを有効化し、運用品質を継続的に評価

【関連リソース】

🔵 hotspot_dropdown (3 行以下) (15 問)

AZ700-CORE#93 (pid=29710)

AZ700-CORE#110

Defender for Cloud の Attack Path analysis 機能について、各特性を判定してください。

ステートメント	選択
Internet から Public IP 経由で VM に到達できる経路を可視化
攻撃経路を自動的に遮断する機能
各経路の脆弱性スコア (CVSS) + ビジネス影響度を組み合わせて優先度判定

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
Internet から Public IP 経由で VM に到達できる経路を可視化	はい
攻撃経路を自動的に遮断する機能	いいえ
各経路の脆弱性スコア	はい

【各判定の詳細】

「Internet から Public IP 経由で VM に到達できる経路を可視化」→ はい: Internet から Public IP 経由で VM に到達できる経路は、Attack Path analysis で攻撃者視点として可視化されます。これにより、NSG / Firewall を通じた外部到達性のリスクを定量的に把握できます。
「攻撃経路を自動的に遮断する機能」→ いいえ: Attack Path analysis は分析と推奨事項の提示に特化した機能で、攻撃経路を自動的に遮断する機能は備えていません。そのため、緩和は手動 (NSG ルール追加、Public IP 削除等) で実施する運用が前提となります。
「各経路の脆弱性スコア」→ はい: 各攻撃経路には CVSS (技術的脆弱性スコア) とビジネス影響度 (Sensitive Data や Privileged Identity 等の重要度) が組み合わせて評価されます。これにより、優先度の高い経路から対応するリスクベース運用が可能となります。

【参考】

Attack Paths

AZ700-CORE#90 (pid=29707)

AZ700-CORE#101

Network Watcher Connection Monitor の設定要素について、各項目を判定してください。

ステートメント	選択
Source は Azure VM (Network Watcher Agent 必須) または Azure Workspace を選択可
Destination は Azure リソース、外部 URL、IP アドレス、いずれも指定可
プロトコルは TCP、ICMP、HTTP/HTTPS から選択

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
Source は Azure VM	はい
Destination は Azure リソース、外部 URL、IP アドレス、いずれも指定可	はい
プロトコルは TCP、ICMP、HTTP/HTTPS から選択	はい

【各判定の詳細】

「Source は Azure VM」→ はい: Connection Monitor の Source は Azure VM (Network Watcher Agent 必須) または Azure Workspace (エージェントベース) のどちらも選択可能です。そのため、IaaS / SaaS 両方のシナリオで監視ソースを柔軟に配置できます。
「Destination は Azure リソース、外部 URL、IP アドレス、いずれも指定可」→ はい: Destination は Azure リソース (VM / PaaS)、外部 URL、IP アドレスのいずれも指定可能です。これにより、Azure 内通信の監視に加えてオンプレや外部 SaaS への Hybrid 到達性監視も同一ツールで実現できます。
「プロトコルは TCP、ICMP、HTTP/HTTPS から選択」→ はい: プロトコルは TCP、ICMP、HTTP、HTTPS の 4 種類から選択可能です。そのため、Web アプリケーションの監視には HTTP / HTTPS、ネットワーク疎通テストには TCP / ICMP のように用途に応じた使い分けができます。

【参考】

Connection Monitor

AZ700-CORE#85 (pid=29700)

AZ700-CORE#91

Azure Virtual Network Manager (AVNM) の Security Admin Rules について、各特性を判定してください。

ステートメント	選択
Security Admin Rules は NSG より高い優先度で評価される
Security Admin Rules はテナントレベルで設定し、VNet グループ単位で適用
Security Admin Rules は Always Allow / Always Deny / Allow / Deny の 4 アクションを持つ

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
Security Admin Rules は NSG より高い優先度で評価される	はい
Security Admin Rules はテナントレベルで設定し、VNet グループ単位で適用	はい
Security Admin Rules は Always Allow / Always Deny / Allow …	はい

【各判定の詳細】

「Security Admin Rules は NSG より高い優先度で評価される」→ はい: AVNM の Security Admin Rules は NSG より上位で評価され、テナントレベルで強制適用されます。そのため、NSG で個別に許可されているルールを Security Admin Rules で Deny に上書きすることが可能となります。
「Security Admin Rules はテナントレベルで設定し、VNet グループ単位で適用」→ はい: Security Admin Rules はテナントレベルで設定し、Network Group という VNet 集合に対して一括適用される設計です。これにより、組織全体のセキュリティコンプライアンスを集中管理でき、個別 NSG の手動運用負荷が軽減されます。
「Security Admin Rules は Always Allow / Always Den…」→ はい: Security Admin Rules は Always Allow / Always Deny / Allow / Deny の 4 アクションを持ち、Always 系は NSG で上書き不可、それ以外は NSG での再評価対象という階層構造です。このため、強制ポリシーと推奨ポリシーを使い分ける柔軟な設計が可能となります。

【参考】

AVNM Security Admin Rules

AZ700-CORE#80 (pid=29695)

AZ700-CORE#86

AKS のネットワークモデル選択について、各要件に適したモードを選んでください。

ステートメント	選択
10,000 Pod 規模の大規模クラスタ、VNet IP を節約したい
Pod から Azure SQL DB Private Endpoint に NAT なし直接通信
小規模 (50 Pod 以下) シンプル構成、移行マイグレーション中

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
10,000 Pod 規模の大規模クラスタ、VNet IP を節約したい	Azure CNI Overlay
Pod から Azure SQL DB Private Endpoint に NAT なし直接通信	Azure CNI
小規模	Kubenet

【各判定の詳細】

「10,000 Pod 規模の大規模クラスタ、VNet IP を節約したい」→ Azure CNI Overlay: Azure CNI Overlay は Pod がオーバーレイ範囲 (VNet 外の private CIDR) を使用し、Node のみが VNet IP を消費する設計です。そのため、10,000 Pod 規模の大規模クラスタでも VNet IP プールを使い果たすリスクがなく、Pod 数増加に対応しやすいモデルとなります。
「Pod から Azure SQL DB Private Endpoint に NAT なし直接通信」→ Azure CNI: Azure CNI は Pod が VNet IP を直接持つため、VNet 内の Private Endpoint や PaaS サービスとの NAT なし通信が可能です。これにより、Pod から Azure SQL DB Private Endpoint への直接アクセスで遅延やトラブルシューティングが容易となります。
「小規模」→ Kubenet: Kubenet は IP アドレスを節約しつつシンプルな構成を実現できる旧モデルで、50 Pod 以下の小規模クラスタや移行中の暫定環境に適合します。ただし将来廃止予定のため、新規構築では Azure CNI または CNI Overlay の採用が推奨されます。

【参考】

AKS ネットワーク概念 / Azure CNI Overlay

AZ700-CORE#61 (pid=29676)

AZ700-CORE#78

Microsoft Defender for Cloud のセキュリティ機能の中で、ネットワーク観点で関連するものを判定してください。各機能について「Network 関連あり」または「Network 関連薄い」を選んでください。

ステートメント	選択
Attack Paths (攻撃経路の可視化)
Secure Score (構成ベースのセキュリティ評価)
Cloud Security Posture Management (CSPM)

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
Attack Paths	Network 関連あり
Secure Score	Network 関連あり
Cloud Security Posture Management	Network 関連あり

【各判定の詳細】

「Attack Paths」→ Network 関連あり: Attack Paths は Public IP / NSG / ピアリング / Firewall などのネットワーク到達可能性を考慮して、攻撃者視点での外部到達経路を可視化する機能です。そのため、Network 構成のセキュリティ評価に直接関わる機能と位置付けられます。
「Secure Score」→ Network 関連あり: Secure Score は構成ベースの総合セキュリティ評価で、NSG / Public IP 露出 / Just-in-Time / DDoS Protection 等のネットワークコントロールが重要評価要素となります。このため、ネットワーク推奨事項を解決することで Score が直接的に上昇します。
「Cloud Security Posture Management」→ Network 関連あり: Cloud Security Posture Management (CSPM) は Azure 全体の構成評価機能で、ネットワーク構成 (NSG ルール、Public IP 露出、暗号化など) も評価対象に含まれます。そのため、Network 関連のリスク管理にも貢献するソリューションとなります。

【参考】

Defender for Cloud Network 推奨事項 / Attack Paths

AZ700-CORE#57 (pid=29670)

AZ700-CORE#60

NSG Flow Logs のバージョン (Version 1 と Version 2) の機能差について、各機能をどちらがサポートするか選んでください。

ステートメント	選択
許可/拒否されたフローの記録
フロー状態 (Begin/Continue/End) の記録
送受信バイト数 + パケット数の記録

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
許可/拒否されたフローの記録	両方
フロー状態	Version 2
送受信バイト数 + パケット数の記録	Version 2

【各判定の詳細】

「許可/拒否されたフローの記録」→ 両方: 許可および拒否されたフローの 5-tuple ベース記録は、Version 1 と Version 2 の両方で対応する基本機能です。そのため、シンプルな許可 / 拒否ログ要件であれば Version 1 でも要件を満たせます。
「フロー状態」→ Version 2: フロー状態 (Begin / Continue / End) の記録は Version 2 で導入された機能で、長時間継続するフローの開始・継続中・終了を時系列で分析可能になります。これにより、Version 1 では把握できなかった「いつまで通信していたか」が判断できます。
「送受信バイト数 + パケット数の記録」→ Version 2: 送受信バイト数とパケット数の記録は Version 2 で導入された機能で、トラフィック量分析やコスト分析に必要なデータを提供します。これにより、特定セグメント間の帯域消費やボトルネック特定が可能となります。

【参考】

NSG Flow Logs / Virtual Network Flow Logs

AZ700-CORE#52 (pid=29665)

AZ700-CORE#53

Azure Route Server を使うシナリオで、正しい設定値を選んでください。NVA との BGP ピアリングを行います。

ステートメント	選択
Route Server の Branch-to-Branch を有効化 (NVA 経由で異なる ER 回線/VPN 間の Transit を可能に)
Route Server を VPN Gateway と同一サブネットに配置
NVA との BGP ピアリングで BGP ASN を指定 (Route Server 側は固定 ASN 65515)

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
Route Server の Branch-to-Branch を有効化	はい
Route Server を VPN Gateway と同一サブネットに配置	いいえ
NVA との BGP ピアリングで BGP ASN を指定	はい

【各判定の詳細】

「Route Server の Branch-to-Branch を有効化」→ はい: Route Server の Branch-to-Branch 設定を有効化すると、複数の ExpressRoute 回線または VPN 接続間で NVA 経由のルート交換が可能となります。そのため、異なる拠点間で NVA を Transit ハブとして使う設計では必須となる設定です。
「Route Server を VPN Gateway と同一サブネットに配置」→ いいえ: Route Server は専用サブネット RouteServerSubnet (/27 推奨) が必要で、GatewaySubnet と同居させることはできません。そのため、Hub VNet には RouteServerSubnet と GatewaySubnet を別々に作成して配置する必要があります。
「NVA との BGP ピアリングで BGP ASN を指定」→ はい: Route Server 側の ASN は 65515 で固定されており、NVA とのピアリング時には NVA 側の任意 ASN を指定して BGP セッションを確立します。このため、NVA ベンダーの推奨 ASN (例: 64512〜65534 の private 範囲) を選び、ピアリング設定で明示します。

【参考】

Azure Route Server / ER + VPN Transit

AZ700-CORE#47 (pid=29660)

AZ700-CORE#45

各 DNS シナリオで使うべき Azure DNS 機能を選んでください。

ステートメント	選択
contoso.com (公開 Web) の権威 DNS をホスティング
privatelink.blob.core.windows.net の Private Endpoint レコードホスティング
オンプレ DNS から Azure VNet 内の privatelink.* ゾーン解決

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
contoso.com	Public DNS Zone
privatelink.blob.core.windows.net の Private Endpoint レコード …	Private DNS Zone
オンプレ DNS から Azure VNet 内の privatelink.* ゾーン解決	DNS Private Reso…

【各判定の詳細】

「contoso.com」→ Public DNS Zone: Public DNS Zone はインターネット側公開ドメインの権威 DNS をホスティングする機能で、Web サーバーの A レコード、メールの MX、SPF / DKIM 等を一元管理します。そのため、contoso.com 等の対外公開ドメインを Azure 上で管理する用途に最適です。
「privatelink.blob.core.windows.net の Private Endp…」→ Private DNS Zone: Private DNS Zone は VNet 内部からのみ解決可能な内部用ゾーンで、Private Endpoint と組み合わせて Private Endpoint Group が A レコードを自動登録します。これにより、Private Endpoint へのプライベート IP 解決を VNet 内で自動的に提供できます。
「オンプレ DNS から Azure VNet 内の privatelink.* ゾーン解決」→ DNS Private Reso…: DNS Private Resolver の Inbound endpoint はオンプレからの DNS クエリを受信するエントリポイントとして機能します。そのため、オンプレ DNS で privatelink.* ドメインを Resolver Inbound IP に条件付き転送することで、オンプレから Azure 内 Private Endpoint の名前解決が可能となります。

【参考】

Azure DNS 概要 / DNS Private Resolver

AZ700-CORE#44 (pid=29657)

AZ700-CORE#36

Azure VNet のルーティング優先度に関する各ルートタイプについて、優先度 (1 = 最高、4 = 最低) を選んでください。プレフィックス長は同一とします。

ステートメント	選択
UDR (ユーザー定義ルート)
BGP (ExpressRoute / VPN 経由の動的ルート)
VNet Peering (システム自動)

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
UDR	1 (最高)
BGP	2
VNet Peering	3

【各判定の詳細】

「UDR」→ 1 (最高): User Defined Route (UDR) は最も高い優先度を持ち、BGP やシステム既定の経路を上書きできます。そのため、Forced Tunneling や中央 Firewall への強制経路を構成する場合に UDR で 0.0.0.0/0 を NVA に向ける設計が採用されます。
「BGP」→ 2: BGP は UDR より低いものの、VNet Peering やシステム既定ルートよりは高い優先度で評価されます。これにより、VPN / ExpressRoute 経由でオンプレから広告された経路が VNet 内でデフォルトの経路として採用されます。
「VNet Peering」→ 3: VNet Peering で自動追加されるシステム経路は BGP より低く、システム既定 (Internet 経由) より高い優先度を持ちます。そのため、ピアリングが確立している限り Spoke は VNet ピア宛トラフィックを直接送信する経路が選ばれます。

【参考】

Azure ルート選択 / ルートテーブル管理

AZ700-CORE#38 (pid=29651)

AZ700-CORE#30

Public IP の SKU と機能の対応について、Standard / Basic / どちらでもの中から選んでください。Basic は 2025-09-30 で廃止予定です。

ステートメント	選択
ゾーン冗長 (Zone-redundant) または特定ゾーン (1/2/3) 関連付け
既定で全インバウンドトラフィック許可
割り当て方式 Static のみ (Dynamic 不可)

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
ゾーン冗長	Standard
既定で全インバウンドトラフィック許可	Basic
割り当て方式 Static のみ	Standard

【各判定の詳細】

「ゾーン冗長」→ Standard: Standard SKU は 3 ゾーン冗長または特定 1 ゾーンへの関連付けが可能で、99.99% SLA が提供されます。一方、Basic SKU はゾーン非対応かつ SLA なしのため、本番環境のゾーン耐性要件では Standard 一択となります。
「既定で全インバウンドトラフィック許可」→ Basic: Basic SKU は既定で全インバウンドトラフィックが許可される旧仕様です。一方、Standard SKU は既定で全拒否となり、明示的な NSG 許可が必要となるセキュアな既定動作に切り替わっています。
「割り当て方式 Static のみ」→ Standard: Standard SKU は割り当て方式が Static (静的) のみとなります。一方、Basic SKU は Static と Dynamic の両方に対応しますが、Dynamic では VM 停止のタイミングで IP が変わる可能性があるため本番運用では Static が推奨されます。

【参考】

Public IP アドレス / Basic Public IP 廃止と移行

AZ700-CORE#20 (pid=29643)

AZ700-CORE#21

Hub-Spoke ピアリング設定の 4 つのフラグについて、Hub 側で設定する値を選んでください。Hub に VPN Gateway があり、Spoke がそれを利用 (Gateway Transit) する設計です。

ステートメント	選択
Allow virtual network access (Hub → Spoke の通信を許可)
Allow forwarded traffic (NVA 経由の転送トラフィックを受け入れる)
Allow gateway transit (この VNet のゲートウェイを相手側に使わせる)

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
Allow virtual network access	はい
Allow forwarded traffic	はい
Allow gateway transit	はい

【各判定の詳細】

「Allow virtual network access」→ はい: Allow virtual network access は VNet 間の基本通信を許可するフラグで、ピアリング作成時は通常両方向で有効化します。そのため、Hub-Spoke ピアリングでも Hub→Spoke / Spoke→Hub どちらもこのフラグを有効にしておく必要があります。
「Allow forwarded traffic」→ はい: Hub に配置した NVA / Azure Firewall を経由するトラフィックは送信元 IP が書き換えられた状態で Spoke に到達するため、Allow forwarded traffic が必須となります。このため、Firewall 集中検査構成では Hub / Spoke 両方でこのフラグを有効化します。
「Allow gateway transit」→ はい: Hub にゲートウェイ (VPN / ExpressRoute) を配置して Spoke から共有利用させる構成では、Hub 側の Allow gateway transit を有効化し、Spoke 側の Use remote gateways を有効化する組み合わせが必須となります。これにより、Spoke は独自 Gateway を持たずに Hub Gateway 経由でオンプレ接続できます。

【参考】

VNet ピアリング Gateway Transit

AZ700-CORE#15 (pid=29638)

AZ700-CORE#13

Azure DNS Private Resolver の主要コンポーネントについて、それぞれの目的を選んでください。

ステートメント	選択
Inbound endpoint
Outbound endpoint + Forwarding Ruleset
公式 Microsoft Learn ガイドの推奨手順に従う

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
Inbound endpoint	オンプレ→Azure受信
Outbound endpoint + Forwarding Ruleset	Azure→オンプレ転送
公式 Microsoft Learn ガイドの推奨手順に従う	オンプレ→Azure受信

【各判定の詳細】

「Inbound endpoint」→ オンプレ→Azure受信: Inbound endpoint は VNet 内に IP アドレスを持ち、オンプレ側 DNS フォワーダーからのクエリを受信するエントリポイントとして機能します。そのため、オンプレからの Azure 上 Private Zone 解決の入り口として利用されます。
「Outbound endpoint + Forwarding Ruleset」→ Azure→オンプレ転送: Outbound endpoint と Forwarding Ruleset を組み合わせると、Azure 側から特定ドメイン (例: corp.contoso.com) のクエリをオンプレ DNS へ転送できます。これにより、Hybrid 環境で Azure ワークロードからオンプレドメインの名前解決が実現します。
「公式 Microsoft Learn ガイドの推奨手順に従う」→ オンプレ→Azure受信: Azure DNS Private Resolver の最新仕様や運用推奨事項は、Microsoft Learn の公式ドキュメントに常時最新版が提供されています。そのため、本番設計の前に必ず Microsoft Learn を参照して最新の上限値・利用可能 region・ベストプラクティスを確認することが推奨されます。

【参考】

Azure DNS Private Resolver 概要

AZ700-CORE#12 (pid=29635)

AZ700-CORE#3

Azure VNet に関する次の構成項目を、Azure の制約に照らして正しい値を選んでください。

ステートメント	選択
VNet のアドレス空間に RFC 1918 以外 (例: 100.64.0.0/10 や Public IP) を指定できる
デプロイ済 VM があるサブネットの CIDR は変更不可
1 つの VNet 内で複数の重複しないアドレス空間を持てる

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
VNet のアドレス空間に RFC 1918 以外	はい
デプロイ済 VM があるサブネットの CIDR は変更不可	いいえ
1 つの VNet 内で複数の重複しないアドレス空間を持てる	はい

【各判定の詳細】

「VNet のアドレス空間に RFC 1918 以外」→ はい: VNet のアドレス空間には RFC 1918 以外 (例: 100.64.0.0/10 や Public IP) も指定できます。そのため、複数 VNet 間の CIDR 重複を避ける目的や NAT44 用途で Public IP 範囲を VNet に割り当てるケースで活用されます。
「デプロイ済 VM があるサブネットの CIDR は変更不可」→ いいえ: 2024 年以降のアップデートにより、特定条件下 (拡張のみ、リソース在中サブネット) で CIDR 変更が可能となりました。そのため、デプロイ済 VM があっても影響なしにサブネットを拡張できるシナリオが増えています。
「1 つの VNet 内で複数の重複しないアドレス空間を持てる」→ はい: 1 つの VNet 内には複数の重複しないアドレス空間を追加できます。これにより、10.0.0.0/16 と 172.16.0.0/16 を同じ VNet にまとめて運用するような柔軟な CIDR 設計が可能となります。

【参考】

VNet 概要 / VNet IPv6 概要

AZ700-CORE#6 (pid=29629)

AZ700-CORE#68

各 Azure サービスをデプロイするとき、専用サブネット (専用名または特定の条件) が必要なものを分類してください。各サービスについて「専用サブネット必要」または「専用サブネット不要 (任意のサブネット可)」を選んでください。

ステートメント	選択
Azure VPN Gateway / ExpressRoute Gateway
Azure Bastion
Azure Firewall

ディスカッション 0

解説

【正解マッチング】

判定対象	正解
Azure VPN Gateway / ExpressRoute Gateway	専用サブネット必要
Azure Bastion	専用サブネット必要
Azure Firewall	専用サブネット必要

【各判定の詳細】

「Azure VPN Gateway / ExpressRoute Gateway」→ 専用サブネット必要: Azure VPN Gateway および ExpressRoute Gateway は GatewaySubnet という名前固定のサブネットを必要とします。そのため、Hub VNet に GatewaySubnet (推奨 /27 以上) を事前に作成しておかないと Gateway デプロイ自体ができません。
「Azure Bastion」→ 専用サブネット必要: Azure Bastion は AzureBastionSubnet という名前固定 (最小 /26) のサブネットを必須要件とします。このため、Bastion ホストを Hub VNet にデプロイする際は AzureBastionSubnet を別途作成する必要があります。
「Azure Firewall」→ 専用サブネット必要: Azure Firewall は AzureFirewallSubnet という名前固定 (/26 推奨) のサブネットが必須となります。そのため、Hub-Spoke で中央 Firewall を配置する設計では Hub VNet に AzureFirewallSubnet を確保しておく必要があります。

【参考】

VNet 計画と設計

AZ-700-CORE#1 (pid=29613)

AZ-700-CORE#1

異なるサブスクリプション同士の 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 からの通信を許可するか)
② --allow-forwarded-traffic (NVA/Firewall 等で転送されたトラフィックを受け入れるか)
③ --allow-gateway-transit (Hub の VPN/ER Gateway を Spoke で利用させるか) — Hub 側の設定

ディスカッション 0

🟢 drag_order (順序並び替え) (15 問)

AZ700-CORE#112 (pid=29729)

AZ700-CORE#20

DDoS Network Protection の動作検証として攻撃シミュレーションを実施する手順を順序付けてください。

BreakingPoint Cloud (BPC) アカウントを準備 (Microsoft 公認パートナー)
シミュレーション対象の Public IP (テスト VM、Bastion 等の本番影響なし) を選定
攻撃前の通常時メトリクス (帯域、PPS、SYN 数) を 30 分計測しベースライン化
BPC で疑似 SYN Flood + UDP Reflection 攻撃を 5 分間実行 (実際の DDoS パターン)

ディスカッション 0

解説

【正しい順序】

ステップ 1: BPC 準備
ステップ 2: 対象 Public IP 選定
ステップ 3: ベースライン計測
ステップ 4: 攻撃実行

【各ステップの理由】

ステップ 1: BPC: Microsoft 公認の DDoS テストツール、Azure 環境への合法的シミュレーション。
ステップ 2: 対象: 本番影響なし、テスト用に隔離された Public IP を選定 (本番 VM への攻撃は事故リスク)。
ステップ 3: ベースライン: 「平常時」のメトリックを記録、後の比較材料。
ステップ 4: 攻撃: SYN Flood + UDP Reflection の現実的なシナリオ。サイズ 5-50 Gbps 帯。

【参考】

DDoS シミュレーション

【BreakingPoint Cloud (BPC) シナリオ】

シナリオ	攻撃タイプ
Volumetric	UDP Flood、ICMP Flood、SYN Flood
Protocol	SYN-ACK Flood、TCP Reset
Application	HTTP Flood (L7)
Reflection/Amplification	DNS、NTP、Memcached

【シミュレーションベストプラクティス】

本番影響なしのテスト用 Public IP で実施
Microsoft に事前通知 (Customer Reservation Form)
ピーク帯域 1-5 Gbps 程度で検証 (本物攻撃は 100+ Gbps)
結果を SOC ランブックに反映

DDoS シミュレーション

AZ700-CORE#111 (pid=29728)

AZ700-CORE#11

既存 Public Storage Account を Private Endpoint 化 (Zero Trust 移行) する手順を順序付けてください。ダウンタイムを最小化。

既存 Storage の利用クライアント (VM、PaaS、外部 SaaS) を監査、IP 範囲特定
Storage Firewall で「Selected networks」を有効化、既存 IP/VNet を許可リストに追加 (中断回避)
privatelink.blob.core.windows.net Private DNS Zone を作成、対象 VNet にリンク
Storage Account に Private Endpoint を作成、Private DNS Zone Group で自動 A レコード登録

ディスカッション 0

解説

【正しい順序】

ステップ 1: 既存クライアント監査
ステップ 2: Storage Firewall で許可リスト (継続性確保)
ステップ 3: Private DNS Zone
ステップ 4: PE 作成 + DNS Zone Group

【各ステップの理由】

ステップ 1: 監査: 誰がアクセスしているか把握、移行漏れ防止。
ステップ 2: Firewall: 移行作業中も既存通信を継続させるための保険措置。
ステップ 3: DNS Zone: PE 作成前に Private DNS Zone 準備、後の自動 A レコード登録の受け皿。
ステップ 4: PE: Private IP を VNet 内に確保、Zone Group で A レコード自動登録します。

【参考】

Storage ネットワーク

【Storage Account Zero Trust 構成】

Public Network Access = Disabled
Private Endpoint でプライベート IP
Storage Firewall で VNet/IP 範囲限定 (バックアップ用 IaC)
Storage SAS Token 制限 (HTTPS のみ、IP 制限、期限)
Microsoft Entra ID + RBAC でアクセス制御
Defender for Storage で異常検知

【段階移行タイムライン】

段階	期間
監査 + 計画	1 週間
PE + Private DNS	即時
クライアント DNS 切替	1-2 週間 (段階)
Public Disable	切替完了後

Storage ネットワーク

AZ700-CORE#110 (pid=29727)

AZ700-CORE#2

AKS Private Cluster をネットワーク観点で構築する手順を順序付けてください。

専用 VNet を作成、ノード用サブネット (Azure CNI で /22 等)、PE 用サブネット
Private DNS Zone (privatelink.region.azmk8s.io) を作成、対象 VNet にリンク
AKS Private Cluster を作成、API server を Private Endpoint 経由に、Network Plugin = Azure CNI
Azure Bastion 経由でアクセス可能な Jump Box VM を VNet 内に配置

ディスカッション 0

解説

【正しい順序】

ステップ 1: VNet + サブネット
ステップ 2: Private DNS Zone
ステップ 3: AKS Private Cluster デプロイ
ステップ 4: Jump Box VM

【各ステップの理由】

ステップ 1: VNet: Azure CNI なら大規模サブネット (/22 = 1024 IP) 推奨。Pod ごとに IP 消費。
ステップ 2: DNS: Private Cluster の API server FQDN (例: aks-xxx.privatelink.eastus.azmk8s.io) を Private DNS で解決します。
ステップ 3: AKS デプロイ: Private Cluster 有効化、API server を Public 公開せず PE 経由のみ。Network Plugin で CNI / CNI Overlay を選択します。
ステップ 4: Jump Box: Private API server は VNet 内/ピアリング先からのみアクセス可能です。Bastion + Jump Box が標準アクセス手段。

【参考】

AKS Private Cluster

【AKS Private Cluster 接続方法】

方法	用途
VNet 内 Jump Box VM	標準、Bastion 経由
VPN/ER 経由オンプレから kubectl	オンプレ管理者向け
Cloud Shell (VNet 統合)	Premium SKU
AKS Run Command	API 経由でクラスタ操作

【Private Cluster の制約】

API server FQDN は Private DNS で解決
az aks command invoke で Run Command 実行可
Public IP 持つ Build Agent からアクセス不可

AKS Private Cluster

AZ700-CORE#91 (pid=29708)

AZ700-CORE#111

Spoke VM から外部 Web API への通信が突然失敗するようになりました。Network Watcher を使った標準的なトラブルシュート手順を順序付けてください。

IP Flow Verify で NSG が当該通信を拒否していないか即座に確認
NSG OK なら Effective Routes で経路 (UDR/ピアリング/BGP) を確認
Connection Troubleshoot でエンドツーエンド経路を実行 (ホップごとのレイテンシ + 到達性)
必要に応じて Packet Capture でパケットレベル詳細分析 (TCP フラグ、HTTP 応答等)

ディスカッション 0

解説

【正しい順序】

ステップ 1: IP Flow Verify (NSG 判定)
ステップ 2: Effective Routes (UDR 判定)
ステップ 3: Connection Troubleshoot (経路全体)
ステップ 4: Packet Capture (詳細)

【各ステップの理由】

ステップ 1: IP Flow Verify: 最も多い原因 = NSG ルールの設定ミス。IP Flow Verify で即座に判定でき、許可/拒否を確認すれば原因切り分けの最速手段。実行時間数秒、コストゼロ。
ステップ 2: Effective Routes: NSG OK の場合、次に疑うのは経路 (UDR が誤って 0.0.0.0/0 を None に向けていないか、ピアリング切断、Firewall NextHop 不在等)。Azure Portal の VM の NIC で確認可能です。
ステップ 3: Connection Troubleshoot: 経路 OK でも到達失敗の場合、エンドツーエンドのホップ別レイテンシ + 到達性を分析。Firewall ルール、外部 DNS、宛先サービス側障害も切り分け。
ステップ 4: Packet Capture: L3-L4 OK でも L7 で失敗 (TLS handshake 失敗、HTTP エラー応答等) の場合、Wireshark で読める PCAP を取得してプロトコルレベルで分析。VM に Network Watcher Agent が必要。

【段階的アプローチの理由】

ステップ	実行時間	コスト	得られる情報
IP Flow Verify	数秒	無料	NSG 判定 + ルール名
Effective Routes	数秒	無料	経路情報
Connection Troubleshoot	数分	無料	エンドツーエンド経路
Packet Capture	長時間	VM 負荷 + ストレージ	L2-L7 詳細
Connection Monitor	継続	Log Analytics 課金	長期トレンド + アラート

【誤った順序の問題点】

❌ いきなり Packet Capture: 負荷 + ストレージコスト大、原因が NSG なら過剰調査。
❌ Connection Monitor だけで終わる: 原因特定なしの監視は再発防止にならない。
❌ Routes を見ずに Troubleshoot: UDR が誤って 0.0.0.0/0 → None (Drop) になっていれば、Troubleshoot の結果も「到達不可」しか得られない。

【参考】

Network Watcher 概要

AZ700-CORE#87 (pid=29702)

AZ700-CORE#103

新規 AVNM (Azure Virtual Network Manager) で大規模 Hub-Spoke 環境 (50 Spoke VNet) を集中管理する手順を順序付けてください。

AVNM リソースを作成 (Scope: 適用対象サブスクリプション、Features: Connectivity + Security Admin)
Network Group を作成 (Spoke 用)、動的メンバーシップで Azure Policy 風に「タグ env=prod の VNet を自動所属」と定義
Connectivity 構成を作成 (Topology: Hub and Spoke、Hub VNet を指定、Network Group を Spoke として割り当て)
Security Admin 構成を作成 (Always Deny RDP/SSH from Internet、Always Deny SQL 1433 from Public 等)

ディスカッション 0

解説

【正しい順序】

ステップ 1: AVNM リソース作成
ステップ 2: Network Group 作成 + 動的メンバーシップ
ステップ 3: Connectivity 構成
ステップ 4: Security Admin 構成

【各ステップの理由】

ステップ 1: AVNM 作成: すべての構成の親リソース。Scope (適用対象サブスクリプション) と Features (Connectivity + Security Admin) を最初に確定。
ステップ 2: Network Group: VNet をグループ化、動的メンバーシップでタグ評価により自動所属。50 VNet を一つひとつ手動追加せず、Azure Policy 風の動的評価で「タグ env=prod の VNet を自動 Spoke 所属」を実現します。
ステップ 3: Connectivity 構成: Hub VNet を指定し、Network Group を Spoke として割り当て。AVNM が各 Spoke→Hub のピアリングを自動生成。
ステップ 4: Security Admin 構成: Always Deny ルール (RDP/SSH Internet 公開禁止) や Always Allow (組織標準許可) を定義。Network Group に対して一括適用します。

【AVNM のメリット (規模別)】

VNet 数	手動管理	AVNM 利用
1〜10	運用可能	過剰投資の可能性
10〜50	運用負担増加	推奨 (大きな効率化)
50+	破綻リスク	必須

【動的メンバーシップ式の例】

// Network Group 動的メンバーシップ式 (Azure Resource Graph)
Resources
| where type =~ "microsoft.network/virtualnetworks"
| where tags.env == "prod"
| where tags.region == "eastus"

【誤った順序の問題点】

❌ Connectivity 構成を Network Group なしで作成: 適用対象が定義されておらず、構成が機能しない。
❌ Deploy を構成完了前に実行: 未完成の構成が VNet に適用され、想定外の影響。
❌ 検証をスキップ: 誤った構成が本番環境に影響し続けるリスク。

【参考】

AVNM 概要 / Network Groups

AZ700-CORE#82 (pid=29697)

AZ700-CORE#93

Hub-Spoke + Azure Firewall を新規構築し、すべての Spoke のアウトバウンドを Firewall 強制経由する設計を構築する手順を順序付けてください。

IP アドレス計画 (Hub: 10.0.0.0/16、Spoke 1: 10.1.0.0/16、Spoke 2: 10.2.0.0/16)、Firewall サブネット要件確認
Hub VNet + 各 Spoke VNet を作成、相互ピアリング (Allow forwarded traffic 双方向 true)
Hub VNet に AzureFirewallSubnet (/26) を作成
Azure Firewall (Standard SKU、Public IP 付き) を Hub にデプロイ

ディスカッション 0

解説

【正しい順序】

ステップ 1: IP 計画 + 専用サブネット要件確認
ステップ 2: VNet + ピアリング設定
ステップ 3: AzureFirewallSubnet 作成
ステップ 4: Firewall デプロイ

【各ステップの理由】

ステップ 1: IP 計画: 後から修正困難な要素 (アドレス空間、サブネット境界) を最初に確定。Firewall 専用サブネット (/26)、Bastion (/26)、Gateway (/27) 等の予約スペースを計画段階で盛り込みます。
ステップ 2: VNet + ピアリング: Hub と Spoke の VNet を作成、ピアリング設定で双方向「Allow forwarded traffic」を true (Hub の Firewall 経由通信に必須)。
ステップ 3: AzureFirewallSubnet 作成: 名前固定 + /26 必須、Firewall デプロイ前に存在が必要。
ステップ 4: Firewall デプロイ: Standard SKU + Static Public IP で Firewall ホストをデプロイ。プライベート IP がここで決定される (例: 10.0.1.4)。

【UDR vs Firewall ルールの順序の理由】

順序	理由
UDR 先 + ルール後	UDR で Firewall に強制経路、Firewall が「許可リストないと全拒否」の既定動作で安全に検証可能
ルール先 + UDR 後	UDR 未設定の間は Firewall を経由せず、ルールが有効でも実際の通信に影響しないため意味なし

【誤った順序の問題点】

❌ Firewall デプロイ前に UDR 設定: Firewall のプライベート IP が未確定のため、Next Hop アドレスを指定できない。
❌ ピアリング後設定: ピアリングなしでは Spoke から Hub の Firewall に到達できないため、UDR が機能しない。
❌ AzureFirewallSubnet なしで Firewall デプロイ: 「AzureFirewallSubnet が見つからない」エラーで Firewall デプロイ失敗です。

【参考】

Azure Firewall デプロイ / Hub-Spoke リファレンス

AZ700-CORE#77 (pid=29692)

AZ700-CORE#80

VM Scale Set (Flexible Orchestration) をゾーン跨ぎで構築するネットワーク設計の標準手順を順序付けてください。

VNet + 各ゾーン用サブネット (3 ゾーン: zone1-subnet、zone2-subnet、zone3-subnet) を作成
Standard Load Balancer (Zone-redundant) を作成、Public IP も Zone-redundant Standard SKU
NAT Gateway を各ゾーンに 1 つずつ配置 (合計 3 つ)、各サブネットに関連付け
NSG を作成し、各サブネットに関連付け (Inbound 80/443、Outbound 制限)

ディスカッション 0

解説

【正しい順序】

ステップ 1: VNet + ゾーン別サブネット作成
ステップ 2: Zone-redundant LB + Public IP
ステップ 3: 各ゾーンに NAT Gateway 配置
ステップ 4: NSG 作成 + 関連付け

【各ステップの理由】

ステップ 1: ゾーン別サブネット: VM のゾーン配置に合わせてサブネットを分けることで、ゾーン単位での障害分離が明確化。設計の保守性が向上。
ステップ 2: Zone-redundant LB: Standard LB は Zone-redundant 設定で 3 ゾーン全体にトラフィック分散します。Public IP も Zone-redundant Standard SKU が必須です。
ステップ 3: NAT Gateway 配置: NAT Gateway はゾーン依存リソース。各ゾーンに 1 つずつ配置 (合計 3 つ) しないと、1 ゾーン障害時に該当ゾーンの VM アウトバウンドが停止。
ステップ 4: NSG 関連付け: VM デプロイ前に NSG を関連付けることで、デプロイ時点から最小権限を適用 (Defense in Depth)。

【Zone-redundant 構成のコスト + 利点】

項目	Zonal (1 ゾーン)	Zone-redundant (3 ゾーン)
SLA	99.9%	99.99%
NAT Gateway	1 つ	3 つ
Public IP	1 つ	1 つ (Zone-redundant)
コスト	低	高 (NAT Gateway × 3)

【誤った順序の問題点】

❌ NAT Gateway を 1 つだけ配置: そのゾーン障害時に全アウトバウンドが停止 (SPOF: Single Point of Failure)。Zone fault tolerance が達成できない。
❌ VMSS を先にデプロイ: LB/NAT/NSG なしでデプロイすると、デプロイ直後から無防備な状態 + アウトバウンド経路未確立。

【参考】

VMSS Orchestration / 可用性ゾーン

AZ700-CORE#72 (pid=29687)

AZ700-CORE#70

VNet 内に Azure Bastion をデプロイし、Spoke VNet 内の VM にも Bastion 経由で接続できるようにする手順を順序付けてください。Hub-Spoke 構成です。

Hub VNet 内に AzureBastionSubnet (/26) を作成
Standard SKU Public IP を作成 (Static、Bastion 用)
Bastion ホスト (Standard SKU 推奨) をデプロイし、Public IP と関連付け
Hub と Spoke の VNet ピアリングを設定 (Allow forwarded traffic = true)

ディスカッション 0

解説

【正しい順序】

ステップ 1: AzureBastionSubnet 作成 (/26)
ステップ 2: Standard Public IP 作成
ステップ 3: Bastion ホストデプロイ
ステップ 4: VNet ピアリング設定 (Forwarded Traffic 許可)

【各ステップの理由】

ステップ 1: 専用サブネット作成: 名前固定 AzureBastionSubnet が必須、/26 サイズが要件。Bastion デプロイ前に必須です。
ステップ 2: Public IP 作成: Bastion ホストは Standard SKU Public IP を必要 (Public-mode の場合)。Premium SKU では Private-only mode も選択可能ですが、Standard で Public IP を持つのが一般的。
ステップ 3: Bastion デプロイ: Bastion 本体をデプロイし Public IP を関連付け。SKU は Standard (Native Client、ピア接続必要なら) を選択します。
ステップ 4: ピアリング設定: Hub-Spoke ピアリング設定で双方向通信 + Forwarded Traffic を許可します。これにより Bastion (Hub) から Spoke の VM プライベート IP へ到達可能に。

【Cross-VNet Bastion の前提条件】

Hub VNet と Spoke VNet の双方向ピアリング
「Allow forwarded traffic」が両方向で true
Bastion SKU が Basic 以上 (Premium も対応)
Spoke の AzureBastionSubnet は不要 (Hub の Bastion を共有)

【誤った順序の問題点】

❌ Bastion デプロイ前にサブネット作成なし: AzureBastionSubnet が存在しない場合、Bastion デプロイ自体が失敗です。
❌ ピアリング前に接続テスト: Hub-Spoke ピアリングがないと Spoke VM に到達できないため、テスト失敗です。
❌ Basic Public IP 使用: Bastion は Standard SKU Public IP のみ対応 (Basic は廃止予定)。

【典型コスト構成 (Standard SKU)】

Bastion ホスト: ~$140/月 (Scale Unit 2)
Public IP (Standard): ~$3.5/月
1 つの Bastion で複数 VNet の VM 接続を共有可能 → コスト効率高い

【参考】

Bastion VNet ピアリング / Bastion デプロイチュートリアル

AZ700-CORE#67 (pid=29682)

AZ700-CORE#65

新規 Hub-Spoke 環境で、Web/App/DB 3 層構成の NSG をベストプラクティスに沿って設計する手順を順序付けてください。

各層 (Web/App/DB) の通信要件を特定し、許可すべき送受信ポートを文書化
ASG「web-tier」「app-tier」「db-tier」を作成し、各層の VM NIC に関連付け
各サブネット用の NSG を作成 (web-nsg、app-nsg、db-nsg)
NSG ルールを ASG ベースで定義 (例: app-nsg では Source=web-tier、Dest=app-tier、Port=8080 のみ許可)

ディスカッション 0

解説

【正しい順序】

ステップ 1: 通信要件の特定 + 文書化
ステップ 2: ASG 作成 + VM NIC 関連付け
ステップ 3: NSG 作成 (層別)
ステップ 4: ASG ベースルール定義

【各ステップの理由】

ステップ 1: 要件特定: 「最小権限」(Least Privilege) の原則に基づき、必要最小限の通信ポート + 方向を最初に確定します。例: Web→App は 8080、App→DB は 1433、外部→Web は 80/443、それ以外はすべて拒否します。文書化により後の運用変更時の判断材料となります。
ステップ 2: ASG 関連付け: VM の役割を ASG として表現することで、後の NSG ルールが IP に依存しません。スケールアウト時も自動追従。
ステップ 3: NSG 作成: NSG はサブネット単位で関連付けるのが推奨 (VM 単位 NSG はルール管理が散在する原因)。層別サブネット + 層別 NSG で関心の分離します。
ステップ 4: ASG ベースルール: Source/Destination に ASG を指定することで、ルールが意図的に読みやすくなり、将来の保守性向上。「app-nsg の Inbound: Source=web-tier ASG、Dest=app-tier ASG、Port=8080、Allow」のようなルール。

【最小権限の典型 NSG ルール例】

NSG	方向	Source	Dest	Port	Action
web-nsg	Inbound	Internet	web-tier ASG	80/443	Allow
app-nsg	Inbound	web-tier ASG	app-tier ASG	8080	Allow
db-nsg	Inbound	app-tier ASG	db-tier ASG	1433	Allow

【誤った順序の問題点】

❌ NSG ルールを ASG なしで作成: 後から ASG を導入する場合、ルール全書き換えが必要になる。
❌ 検証を最後に行わない: 本番運用後に通信問題が発覚すると、サービス停止やインシデント対応が必要に。
❌ 要件特定をスキップ: 過度に許可的なルールが設定され、セキュリティポスチャが低下。

【参考】

NSG 動作原理 / Hub-Spoke リファレンス

AZ700-CORE#60 (pid=29675)

AZ700-CORE#57

新規 VNet に対して DDoS Network Protection を設定する手順を順序付けてください。要件は本番運用前にシミュレーション検証まで完了させることです。

DDoS Network Protection Plan リソースを作成 (1 サブスクリプションあたり 1 つ推奨、コスト効率)
対象 VNet に Plan を関連付け (VNet の Properties → DDoS Protection を有効化)
アラートルールを Azure Monitor で設定 (Under attack、Mitigation triggered 等)
通常時のベースライントラフィック量を Plan が学習する期間 (約 1 週間)

ディスカッション 0

解説

【正しい順序】

ステップ 1: DDoS Plan 作成
ステップ 2: VNet に Plan 関連付け
ステップ 3: Azure Monitor アラート設定
ステップ 4: ベースライン学習 (約 1 週間)

【各ステップの理由】

ステップ 1: Plan 作成: DDoS Network Protection Plan は月額固定費 (約 USD 2,944/月) で 1 サブスクリプション 1 Plan が推奨です。複数 VNet をこの 1 つの Plan に関連付けることでコスト効率化を実現します。サブスクリプション間 Plan 共有も可能です。
ステップ 2: VNet 関連付け: VNet 単位で Plan を関連付けることで、その VNet 内の Public IP が DDoS Protection の対象となります。VNet → Properties → DDoS Protection で有効化します。
ステップ 3: アラート設定: Under DDoS attack、Mitigation triggered、DDoS attack mitigated などのメトリクスをアラート化し、運用通知 (Email、SMS、Webhook、Teams) を確保。SOC への即時通知が攻撃対応の鍵です。
ステップ 4: ベースライン学習: Plan は約 1 週間でその VNet の通常時トラフィックを学習し、機械学習ベースで「平常時逸脱」を判定するベースラインを作成します。学習期間中は検知精度が低いため、シミュレーション前にこの期間を待ちます。

【DDoS Protection Standard の機能】

機能	説明
常時監視	VNet の Public IP すべての常時トラフィック分析
アダプティブチューニング	ベースラインに基づいた緩和閾値の動的調整
攻撃メトリクス + アラート	Azure Monitor 統合
緊急対応サポート (DRR)	Microsoft DDoS Rapid Response チーム支援
コスト保護	DDoS によるトラフィック増加分のコスト補填

【誤った順序の問題点】

❌ シミュレーションを最初に実行: Plan 未関連付け状態では緩和が動作せず、本物の DDoS と同じ被害を VM が受ける可能性あり。サービス停止につながる重大な誤り。
❌ アラート設定を最後に: ベースライン学習中に攻撃を受けた場合、通知がなく対応遅延の原因に。学習期間中も監視は必要。
❌ Plan なしで VNet 関連付け: 関連付け対象の Plan が存在しないため、関連付け操作自体が失敗します。

【参考】

DDoS Protection 管理 / DDoS シミュレーション

AZ700-CORE#49 (pid=29662)

AZ700-CORE#47

双方向 DNS 解決 (オンプレ↔Azure) を Azure DNS Private Resolver で構築する手順を順序付けてください。

Azure DNS Private Resolver リソースを Hub VNet に作成
Inbound Endpoint をデプロイ (専用サブネット /28 必要、IP 自動割り当て)
Outbound Endpoint をデプロイ (別の専用サブネット /28 必要)
Forwarding Ruleset を作成し、Outbound Endpoint にリンク

ディスカッション 0

解説

【正しい順序】

ステップ 1: Resolver リソース作成
ステップ 2: Inbound Endpoint デプロイ
ステップ 3: Outbound Endpoint デプロイ
ステップ 4: Forwarding Ruleset 作成 + Outbound 関連付け

【各ステップの理由】

ステップ 1: Resolver 作成: すべての Endpoint や Ruleset の親リソースとなる Resolver を最初に作成します。Hub VNet に配置することで集中管理を実現します。
ステップ 2: Inbound Endpoint: オンプレからのクエリ受信ポイント。専用サブネット (/28、最小 16 IP) が必須で、ここに割り当てられた IP がオンプレ条件付き転送の宛先となります。サブネットには他のリソースを配置不可です。
ステップ 3: Outbound Endpoint: Azure 側から条件付き転送するときの送信元。Inbound とは別のサブネット必須です。これも /28 専用サブネット。
ステップ 4: Forwarding Ruleset: 転送ルールのコンテナを作成し、Outbound に関連付け。Ruleset は複数のルールを含む親リソース。

【専用サブネット計画例】

サブネット名	CIDR	用途
resolver-inbound-subnet	10.0.10.0/28	Inbound Endpoint 専用
resolver-outbound-subnet	10.0.10.16/28	Outbound Endpoint 専用

【誤った順序の問題点】

❌ Ruleset を Outbound 前に作成: Ruleset は Outbound に関連付ける必要があるため、Outbound 未デプロイの状態では関連付けできません。作成自体は可能だが意味をなしません。
❌ オンプレ転送を最初に設定: Resolver Inbound IP が確定する前にオンプレ側で転送設定すると、宛先 IP が不明で無効な設定になります。
❌ Inbound と Outbound を同じサブネットに配置: 仕様上、それぞれ別の専用サブネット必須です。

【参考】

DNS Private Resolver 概要 / ハイブリッド DNS チュートリアル

AZ700-CORE#41 (pid=29654)

AZ700-CORE#42

新規 VNet を作成し、3 層 (Web/App/DB) アーキテクチャを構築する標準的な手順を順序付けてください。要件は Defense in Depth (多層防御) + 専用サブネット計画です。

アドレス空間と各サブネット (Web/App/DB/Gateway/Bastion/Firewall) の CIDR を設計
VNet を作成 (10.0.0.0/16 等、リージョン指定)
各サブネットを作成 (Web=10.0.1.0/24、App=10.0.2.0/24、DB=10.0.3.0/24 等)
NSG を作成し、各サブネットに関連付け (Web→App、App→DB の最小許可)

ディスカッション 0

解説

【正しい順序】

ステップ 1: アドレス空間 + サブネット CIDR 設計
ステップ 2: VNet 作成
ステップ 3: サブネット作成
ステップ 4: NSG 作成 + 関連付け

【各ステップの理由】

ステップ 1: 設計: 後から修正が困難な要素 (アドレス空間、サブネット境界) を先に決めます。Gateway / Bastion / Firewall 用の専用サブネット (それぞれ名前固定 + 最小サイズ要件) も計画段階で盛り込みます。設計ミスは後から修正困難なため最重要ステップです。
ステップ 2: VNet 作成: VNet がなければサブネット作成不可です。リージョン選定もこの時点で確定します。リージョン間ピアリングは Global Peering を使うので、メインリージョンを慎重に選びます。
ステップ 3: サブネット作成: サブネット間の最小通信を考慮した CIDR で分割します。専用サブネット (GatewaySubnet、AzureBastionSubnet、AzureFirewallSubnet) は名前固定で先に作成します。
ステップ 4: NSG 配置: リソースが入る前に NSG を関連付けることで、デプロイ時点から最小権限を適用できます (Defense in Depth)。VM スケールアウト時も NSG が自動適用されるため、リソースを後から追加する運用に強い構造です。

【誤った順序の問題点】

❌ リソースを先にデプロイして NSG 後付け: NSG なしの期間にデプロイされたリソースが意図せず公開状態になり、攻撃面が広がります。特に Public IP を持つ VM では、デプロイ直後から Brute Force 攻撃の標的になります。
❌ 設計せずに VNet/サブネットを作成: 後からアドレス空間 (Bastion 用 /26、Firewall 用 /26 等) を確保できず、再設計が必要になります。サブネットの境界変更は既存リソースがあると不可能なため、再設計コストが大きい。
❌ サブネット → VNet の順: サブネットは VNet の子リソースのため、VNet 不在では作成不可です。

【参考】

VNet 計画と設計 / NSG 概要

AZ700-CORE#22 (pid=29645)

AZ700-CORE#34

Azure NAT Gateway を Spoke サブネットに関連付けて、アウトバウンド SNAT スケールを実現する手順を正しい順序に並べてください。

NAT Gateway リソースを作成する
NAT Gateway に Public IP (Standard SKU) または Public IP Prefix を関連付け
対象 Spoke サブネットに NAT Gateway を関連付け
VM からアウトバウンド通信を実行し Effective Routes で Next Hop が NAT Gateway であることを確認

ディスカッション 0

AZ700-CORE#17 (pid=29640)

AZ700-CORE#24

Hub-Spoke 環境で、オンプレクライアントから Azure 上の Storage Account への Private Endpoint アクセスを実現する DNS 設計手順を正しい順序に並べてください。

Storage Account に Private Endpoint を作成し、Spoke VNet 内のサブネットに配置
privatelink.blob.core.windows.net の Private DNS Zone を Hub VNet にリンク
Private Endpoint 作成時に Private DNS Zone Group で A レコード自動登録
Azure DNS Private Resolver の Inbound endpoint を Hub VNet にデプロイ

ディスカッション 0

AZ700-CORE#8 (pid=29631)

AZ700-CORE#88

Custom Public IP Prefix (BYOIP) を Azure に持ち込み、その範囲から個別の Public IP を払い出すまでの手順を正しい順序に並べてください。

ROA (Route Origin Authorization) を IRR に登録し、Azure に署名付き認証メッセージを提出
Custom IP Prefix リソースを Azure サブスクリプションに登録 (Provisioning 状態へ移行)
Microsoft 側の検証完了を待ち、Provisioning → Provisioned 状態へ
Custom IP Prefix を Commissioned 状態に切り替え、インターネットピアからアドバタイズ開始

ディスカッション 0

🟣 drag_match (項目→カテゴリマッチ) ✨ 新規 (10 問)

AZ700-CORE#209 (pid=29774)

AZ700-CORE#97

各 Network Watcher ツールを、最適な使用シナリオにマッチさせてください。

項目（ドラッグしてください）

Connection Monitor
IP Flow Verify
Next Hop
Packet Capture

継続的なエンドツーエンド接続性監視 (SLO)

NSG が特定通信を許可/拒否しているか即時判定

UDR/システムルートで Next Hop を確認

L2-L7 までのパケット内容詳細解析

ディスカッション 0

解説

【正しいマッチング完全版】

Connection Monitor → 継続的なエンドツーエンド接続性監視 (SLO)
IP Flow Verify → NSG が特定通信を許可/拒否しているか即時判定
Next Hop → UDR/システムルートで Next Hop を確認
Packet Capture → L2-L7 までのパケット内容詳細解析

【正解マッチング】

ツール	用途	実行モード
Connection Monitor	継続的なエンドツーエンド接続性監視 (SLO)
IP Flow Verify	NSG が特定通信を許可/拒否しているか即時判定
Next Hop	UDR/システムルートで Next Hop を確認
Packet Capture	L2-L7 までのパケット内容詳細解析

【トラブルシュート標準フロー】

IP Flow Verify で NSG 判定
Next Hop / Effective Routes で経路確認
Connection Troubleshoot でエンドツーエンド経路
必要に応じて Packet Capture
VPN 起因なら VPN Diagnostic

【参考】

Network Watcher

【ベストプラクティス】

Microsoft 公式ドキュメントに記載された推奨手順を遵守
本番環境では事前に Test/Dev 環境で検証
変更管理プロセスに従い、段階的な展開を実施
監視 + アラートを有効化し、運用品質を継続的に評価

【関連リソース】

AZ700-CORE#208 (pid=29773)

AZ700-CORE#84

各 AKS Network Plugin を、その主要特性にマッチさせてください。

項目（ドラッグしてください）

Pod がオーバーレイ範囲 (10.244.0.0/16 等)、Node 経由で NAT、VNet 内 PaaS と直接通信不可
Pod が VNet サブネット IP を直接取得、VNet 内 PaaS (Private Endpoint 等) と NAT なし直接通信
Pod がオーバーレイ範囲 + Node が VNet IP、CNI の利点 + IP 節約を両立、大規模クラスタ向け

Kubenet (廃止予定)

Azure CNI

Azure CNI Overlay (推奨)

ディスカッション 0

解説

【正しいマッチング完全版】

Pod がオーバーレイ範囲 (10.244.0.0/16 等)、Node 経由で NAT、VNet 内 PaaS と直接通信不可 → Kubenet (廃止予定)
Pod が VNet サブネット IP を直接取得、VNet 内 PaaS (Private Endpoint 等) と NAT なし直接通信 → Azure CNI
Pod がオーバーレイ範囲 + Node が VNet IP、CNI の利点 + IP 節約を両立、大規模クラスタ向け → Azure CNI Overlay (推奨)

【正解マッチング詳細】

Plugin	Pod IP	VNet 内 PaaS 通信	IP 効率	用途
Pod がオーバーレイ範囲	Kubenet (廃止予定)
Pod が VNet サブネット IP を直接取得、VNet 内 PaaS	Azure CNI
Pod がオーバーレイ範囲 + Node が VNet IP、CNI の利点…	Azure CNI Overlay (推奨)

【選択指針】

新規 + 大規模 → Azure CNI Overlay + Cilium
PaaS Direct 通信必須 → Azure CNI
移行マイグレーション中 (廃止予定) → Kubenet

【参考】

AKS Network

【ベストプラクティス】

Microsoft 公式ドキュメントに記載された推奨手順を遵守
本番環境では事前に Test/Dev 環境で検証
変更管理プロセスに従い、段階的な展開を実施
監視 + アラートを有効化し、運用品質を継続的に評価

【関連リソース】

AZ700-CORE#207 (pid=29772)

AZ700-CORE#74

各 Storage 接続シナリオを、Service Endpoint / Private Endpoint / Public のいずれかにマッチさせてください。

項目（ドラッグしてください）

オンプレから VPN/ER 経由でプライベート IP アクセス
VNet 内 VM から低コストで Azure 最適化通信
Storage Account の Public ネットワークアクセスを Enabled (制限なし)
特定の Storage Account のみアクセス許可 (細粒度制御)

Service Endpoint

Private Endpoint

Public (制限なし)

ディスカッション 0

解説

【正しいマッチング完全版】
※「Public ネットワークアクセス Enabled」は Public (制限なし) カテゴリにマッチします。

オンプレから VPN/ER 経由でプライベート IP アクセス → Private Endpoint
VNet 内 VM から低コストで Azure 最適化通信 → Service Endpoint
Storage Account の Public ネットワークアクセスを Enabled (制限なし) → Public (制限なし)
特定の Storage Account のみアクセス許可 (細粒度制御) → Service Endpoint

【正解マッチング】

シナリオ	推奨	理由
オンプレから VPN/ER 経由でプライベート IP アクセス	Private Endpoint
VNet 内 VM から低コストで Azure 最適化通信	Service Endpoint
Storage Account の Public ネットワークアクセスを …	Public (制限なし)
特定の Storage Account のみアクセス許可	Service Endpoint

【選択フロー】

オンプレからプライベート? → PE
Public Disable 必要? → PE
VNet 内のみ + 低コスト? → SE
細粒度制御? → SE Policy

【参考】

Private Link

【ベストプラクティス】

Microsoft 公式ドキュメントに記載された推奨手順を遵守
本番環境では事前に Test/Dev 環境で検証
変更管理プロセスに従い、段階的な展開を実施
監視 + アラートを有効化し、運用品質を継続的に評価

【関連リソース】

AZ700-CORE#206 (pid=29771)

AZ700-CORE#63

各 Routing ソースを、Azure VNet での優先度にマッチさせてください (1=最高、4=最低、プレフィックス長同一時)。

項目（ドラッグしてください）

UDR (User-Defined Route)
BGP (ExpressRoute / VPN 動的ルート)
VNet Peering (システム自動)
System Default (Internet / VirtualNetwork)

1 (最高)

4 (最低)

ディスカッション 0

解説

【正しいマッチング完全版】

UDR (User-Defined Route) → 1 (最高)
BGP (ExpressRoute / VPN 動的ルート) → 2
VNet Peering (システム自動) → 3
System Default (Internet / VirtualNetwork) → 4 (最低)

【ルート選択順序】

最長プレフィックスマッチ (Longest Prefix Match)
同一プレフィックスならソース優先度: UDR > BGP > Peering > System

【優先度マトリクス】

ソース	優先度	用途
UDR	1 (最高)
BGP	2
VNet Peering	3
System Default	4 (最低)

【設計上のポイント】

UDR が BGP より優先 → BGP 経路を UDR で上書き可能
Hub-Spoke で Firewall を強制 → UDR 0.0.0.0/0 → Firewall プライベート IP
Effective Routes で確認

【参考】

UDR

【ベストプラクティス】

Microsoft 公式ドキュメントに記載された推奨手順を遵守
本番環境では事前に Test/Dev 環境で検証
変更管理プロセスに従い、段階的な展開を実施
監視 + アラートを有効化し、運用品質を継続的に評価

【関連リソース】

AZ700-CORE#205 (pid=29770)

AZ700-CORE#51

各 Azure DNS シナリオを、適切な機能にマッチさせてください。

項目（ドラッグしてください）

contoso.com (公開 Web) の権威 DNS をホスティング
privatelink.blob.core.windows.net の PE A レコードホスティング
オンプレ DNS から Azure VNet 内の Private Zone を解決
Azure 側から corp.contoso.com をオンプレ DNS に転送

Public DNS Zone

Private DNS Zone

DNS Private Resolver Inbound

DNS Private Resolver Outbound + Ruleset

ディスカッション 0

解説

【正しいマッチング完全版】

contoso.com (公開 Web) の権威 DNS をホスティング → Public DNS Zone
privatelink.blob.core.windows.net の PE A レコードホスティング → Private DNS Zone
オンプレ DNS から Azure VNet 内の Private Zone を解決 → DNS Private Resolver Inbound
Azure 側から corp.contoso.com をオンプレ DNS に転送 → DNS Private Resolver Outbound + Ruleset

【正解マッチング】

シナリオ	機能
contoso.com	Public DNS Zone
privatelink.blob.core.windows.net の PE…	Private DNS Zone
オンプレ DNS から Azure VNet 内の Private Zone…	DNS Private Resolver Inbound
Azure 側から corp.contoso.com をオンプレ DNS に転送	DNS Private Resolver Outbound + Ruleset

【参考】

Azure DNS / DNS Private Resolver

AZ700-CORE#204 (pid=29769)

AZ700-CORE#40

各 Azure Bastion 機能を、Basic / Standard / Premium のいずれかにマッチさせてください。

項目（ドラッグしてください）

Native Client サポート (Azure CLI/PowerShell からの SSH)
共有可能リンク (セッション URL の他者共有)
ブラウザベース基本 RDP/SSH 接続 (機能制限あり、Native Client や共有リンク不可)
セッション録画 (動画保存)

Basic

Standard

Premium

ディスカッション 0

解説

【正しいマッチング完全版】
※ Basic SKU はブラウザからの基本 RDP/SSH のみ。Native Client / Kerberos / 共有リンクは Standard 以上、セッション録画は Premium。

Native Client サポート (Azure CLI/PowerShell からの SSH) → Standard
共有可能リンク (セッション URL の他者共有) → Standard
ブラウザベース基本 RDP/SSH 接続 (機能制限あり、Native Client や共有リンク不可) → Basic
セッション録画 (動画保存) → Premium

【正解マッチング】

機能	最低 SKU
Native Client サポート	Standard
共有可能リンク	Standard
ブラウザベース基本 RDP/SSH 接続	Basic
セッション録画	Premium

【選択指針】

少数 VM、基本接続のみ → Basic
多数 VM + Native Client → Standard
セッション録画 (コンプライアンス) + Zero Trust → Premium

【参考】

Bastion 構成

【ベストプラクティス】

Microsoft 公式ドキュメントに記載された推奨手順を遵守
本番環境では事前に Test/Dev 環境で検証
変更管理プロセスに従い、段階的な展開を実施
監視 + アラートを有効化し、運用品質を継続的に評価

【関連リソース】

AZ700-CORE#203 (pid=29768)

AZ700-CORE#28

各 ExpressRoute 機能を、Standard / Premium / Direct のいずれかのレベルにマッチさせてください。

項目（ドラッグしてください）

Global Reach (異拠点 ER 間 Backbone 接続)
Geo-political region 全体への VNet 接続
同一 Geo-political Region 内 VNet 接続のみ (グローバル接続不可)
最大 100 Gbps ポート

Standard

Premium add-on

ExpressRoute Direct

ディスカッション 0

解説

【正しいマッチング完全版】
※ Standard は同一 Geo Region 内のみ。Premium add-on で Global Reach / Geo-political 全域 / Route 上限増加。Direct で 100 Gbps。

Global Reach (異拠点 ER 間 Backbone 接続) → Premium add-on
Geo-political region 全体への VNet 接続 → Premium add-on
同一 Geo-political Region 内 VNet 接続のみ (グローバル接続不可) → Standard
最大 100 Gbps ポート → ExpressRoute Direct

【正解マッチング】

機能	対応レベル
Global Reach	Premium add-on
Geo-political region 全体への VNet 接続	Premium add-on
同一 Geo-political Region 内 VNet 接続のみ	Standard
最大 100 Gbps ポート	ExpressRoute Direct

【料金体系】

Standard: 帯域別月額
Premium add-on: Standard に追加料金
Direct: Standard より高い基本料金 + 大規模帯域
データ転送: Metered (従量) または Unlimited (固定) 選択可

【参考】

ExpressRoute FAQ

【ベストプラクティス】

Microsoft 公式ドキュメントに記載された推奨手順を遵守
本番環境では事前に Test/Dev 環境で検証
変更管理プロセスに従い、段階的な展開を実施
監視 + アラートを有効化し、運用品質を継続的に評価

【関連リソース】

AZ700-CORE#202 (pid=29767)

AZ700-CORE#17

各 VPN 機能を、Route-based / Policy-based のどちらに対応するかマッチさせてください。

項目（ドラッグしてください）

IKEv2 プロトコルサポート
BGP 動的ルーティング
P2S (Point-to-Site) との共存
IKEv1 プロトコルサポート (旧式 IPsec)

Route-based のみ

Policy-based のみ

ディスカッション 0

解説

【正しいマッチング完全版】
※ Route-based は IKEv2 + BGP + P2S 共存。Policy-based は IKEv1 のみで旧式 IPsec 互換性のため残存。

IKEv2 プロトコルサポート → Route-based のみ
BGP 動的ルーティング → Route-based のみ
P2S (Point-to-Site) との共存 → Route-based のみ
IKEv1 プロトコルサポート (旧式 IPsec) → Policy-based のみ

【正解マッチング】

機能	対応
IKEv2 プロトコルサポート	Route-based のみ
BGP 動的ルーティング	Route-based のみ
P2S	Route-based のみ
IKEv1 プロトコルサポート	Policy-based のみ

【選択指針】

新規構築 = Route-based (IKEv2 + BGP) が標準
Policy-based は IKEv1 のみ対応のレガシー機器との互換性のため残存
Custom IPsec Policy で暗号スイートを調整可能

【参考】

VPN デバイス

【ベストプラクティス】

Microsoft 公式ドキュメントに記載された推奨手順を遵守
本番環境では事前に Test/Dev 環境で検証
変更管理プロセスに従い、段階的な展開を実施
監視 + アラートを有効化し、運用品質を継続的に評価

【関連リソース】

AZ700-CORE#201 (pid=29766)

AZ700-CORE#7

各 Azure PaaS サービスを、VNet 統合の主要方式にマッチさせてください。

項目（ドラッグしてください）

App Service Premium V3 (Outbound を VNet 内 PaaS に送信)
Azure SQL Managed Instance (専用サブネットに直接デプロイ)
Azure Storage Blob (オンプレからプライベート IP でアクセス)
Azure SQL Database (Public Disable + プライベート IP のみ)

Regional VNet Integration

Subnet Delegation (SQL MI)

Private Endpoint (Storage)

Private Endpoint (SQL DB)

ディスカッション 0

解説

【正しいマッチング完全版】

App Service Premium V3 (Outbound を VNet 内 PaaS に送信) → Regional VNet Integration
Azure SQL Managed Instance (専用サブネットに直接デプロイ) → Subnet Delegation (SQL MI)
Azure Storage Blob (オンプレからプライベート IP でアクセス) → Private Endpoint (Storage)
Azure SQL Database (Public Disable + プライベート IP のみ) → Private Endpoint (SQL DB)

【正解マッチング】

サービス	VNet 統合方式	選択理由
App Service Premium V3	Regional VNet Integration
Azure SQL Managed Instance	Subnet Delegation (SQL MI)
Azure Storage Blob	Private Endpoint (Storage)
Azure SQL Database	Private Endpoint (SQL DB)

【選択フロー】

サービスインスタンスを VNet 内に配置? → Subnet Delegation
サービスにプライベート IP でアクセス? → Private Endpoint
サービスから VNet 内リソースにアクセス? → Regional VNet Integration
VNet 内のみアクセス + Public DNS 維持? → Service Endpoint

【参考】

VNet 統合パターン

AZ700-CORE#200 (pid=29765)

AZ700-CORE#107

各 Azure ネットワークサービスを、その主な機能 (主機能の説明) にマッチさせてください。

項目（ドラッグしてください）

L3-L4 (IP/Port) ベースの 5-tuple フィルタリング、サブネット/NIC 単位
ステートフル L3-L7、FQDN フィルタリング、IDPS (Premium)
OWASP Top 10、Bot Manager 等の L7 HTTP/HTTPS 攻撃保護
L4 (TCP/UDP) 高速振り分け、Zone-redundant、Outbound Rules

Network Security Group (NSG)

Azure Firewall

Web Application Firewall

Standard Load Balancer

ディスカッション 0

解説

【正しいマッチング完全版】

L3-L4 (IP/Port) ベースの 5-tuple フィルタリング、サブネット/NIC 単位 → Network Security Group (NSG)
ステートフル L3-L7、FQDN フィルタリング、IDPS (Premium) → Azure Firewall
OWASP Top 10、Bot Manager 等の L7 HTTP/HTTPS 攻撃保護 → Web Application Firewall
L4 (TCP/UDP) 高速振り分け、Zone-redundant、Outbound Rules → Standard Load Balancer

【正解マッチング】

サービス	主機能	主用途
L3-L4	Network Security Group (NSG)
ステートフル L3-L7、FQDN フィルタリング、IDPS	Azure Firewall
OWASP Top 10、Bot Manager 等の L7 HTTP/HT…	Web Application Firewall
L4	Standard Load Balancer

【多層防御配置例】

境界 (グローバル): Front Door + WAF
境界 (リージョン): Application Gateway + WAF
VNet 内部: Azure Firewall
サブネット: NSG + ASG

【参考】

Network Security アーキテクチャ / LB 選択ガイド

🔴 hotspot 単一 (Yes/No on 3 statements) ✨ 新規 (5 問)

AZ700-CORE#224 (pid=29779)

AZ700-CORE#99

Azure DNS Public / Private Zone に関する次の各記述について、正しい場合は「はい」、誤っている場合は「いいえ」を選択してください。

注: 正解 1 つにつき 1 点が与えられます。

ステートメント	はい	いいえ
Private DNS Zone の Auto-registration は 1 ゾーンにつき 1 VNet のみ有効化できる
Alias レコードは CNAME と完全に同じで、Zone Apex (ルートドメイン) には設定できない
Public DNS Zone は VNet リンクを必要とせず、インターネット全体から名前解決可能

ディスカッション 0

解説

【正解一覧】

ステートメント	正解
Private DNS Zone の Auto-registration は 1 ゾーンにつき 1 VNet のみ有…	はい
Alias レコードは CNAME と完全に同じで、Zone Apex	いいえ
Public DNS Zone は VNet リンクを必要とせず、インターネット全体から名前解決可能	はい

【各判定の詳細】

「Private DNS Zone の Auto-registration は 1 ゾーンにつき …」→ はい: Private DNS Zone の Auto-registration は 1 ゾーンにつき 1 VNet のみ有効化できます。そのため、複数 VNet でホスト名重複が起きる可能性を回避し、レコード競合を防ぐ設計となっています。
「Alias レコードは CNAME と完全に同じで、Zone Apex」→ いいえ: Alias レコードは CNAME と異なり Zone Apex (ルートドメイン) に設定可能で、Azure リソースの IP 変更を自動追従します。これにより、CDN や App Service 等のリソースを Zone Apex で公開する用途で重宝されます。
「Public DNS Zone は VNet リンクを必要とせず、インターネット全体から名前解決可能」→ はい: Public DNS Zone は権威 DNS としてインターネット側に応答するため、VNet リンクは不要です。これにより、Microsoft の DNS インフラ経由で世界中からドメイン名が解決可能となります。

【参考】

Azure DNS

AZ700-CORE#223 (pid=29778)

AZ700-CORE#76

Azure Private Endpoint (PE) の動作に関する次の各記述について、正しい場合は「はい」、誤っている場合は「いいえ」を選択してください。

注: 正解 1 つにつき 1 点が与えられます。

ステートメント	はい	いいえ
Private Endpoint を作成しても、Storage Account の Public Network Access は自動的に Disabled にはならない
Private Endpoint は VPN/ExpressRoute 経由でオンプレからもプライベート IP でアクセスできる
Private DNS Zone Group は Private Endpoint と関係なく、独立して動作する

ディスカッション 0

解説

【正解一覧】

ステートメント	正解
Private Endpoint を作成しても、Storage Account の Public Network A…	はい
Private Endpoint は VPN/ExpressRoute 経由でオンプレからもプライベート IP でア…	はい
Private DNS Zone Group は Private Endpoint と関係なく、独立して動作する	いいえ

【各判定の詳細】

「Private Endpoint を作成しても、Storage Account の Public…」→ はい: Private Endpoint を作成しても、Storage Account の Public Network Access は自動では Disabled になりません。そのため、Zero Trust 設計では PE 作成と同時に Public Access を明示的に Disabled へ切り替える運用が必要です。
「Private Endpoint は VPN/ExpressRoute 経由でオンプレからもプラ…」→ はい: Private Endpoint は VNet 内のプライベート IP を持つため、VPN または ExpressRoute 経由でオンプレからも到達可能となります。これにより、Hybrid 環境でも Public Internet を介さず Azure サービスに接続できます。
「Private DNS Zone Group は Private Endpoint と関係なく、…」→ いいえ: Private DNS Zone Group は Private Endpoint と Private DNS Zone を結びつけて A レコードを自動管理する機能です。そのため、独立して動作するのではなく PE と密接に連携して動作する関係にあります。

【参考】

Private Endpoint

AZ700-CORE#222 (pid=29777)

AZ700-CORE#55

Azure DDoS Protection に関する次の各記述について、正しい場合は「はい」、誤っている場合は「いいえ」を選択してください。

注: 正解 1 つにつき 1 点が与えられます。

ステートメント	はい	いいえ
DDoS Basic はすべての Azure リソースで自動的に有効、追加料金なしで Microsoft グローバルネットワークレベルの保護を提供
DDoS Network Protection は VNet 単位で機械学習ベースのベースライン学習を行い、約 1 週間で平常時パターンを学習する
DDoS Network Protection は攻撃が発生しても DDoS Rapid Response (DRR) チームのサポートは含まれない

ディスカッション 0

解説

【正解一覧】

ステートメント	正解
DDoS Basic はすべての Azure リソースで自動的に有効、追加料金なしで Microsoft グローバ…	はい
DDoS Network Protection は VNet 単位で機械学習ベースのベースライン学習を行い、約 1 …	はい
DDoS Network Protection は攻撃が発生しても DDoS Rapid Response	いいえ

【各判定の詳細】

「DDoS Basic はすべての Azure リソースで自動的に有効、追加料金なしで Micr…」→ はい: DDoS Basic はすべての Azure リソースで自動的に有効化される無料サービスで、追加料金は発生しません。これにより、大規模な Volumetric 攻撃が Microsoft グローバルネットワークレベルで自動緩和されます。
「DDoS Network Protection は VNet 単位で機械学習ベースのベースライン…」→ はい: DDoS Network Protection は VNet 単位で機械学習ベースのアダプティブチューニングを行い、約 1 週間で平常時のトラフィックパターンを学習します。そのため、攻撃発生時にベースラインからの逸脱を高精度で検出できます。
「DDoS Network Protection は攻撃が発生しても DDoS Rapid Res…」→ いいえ: DDoS Network Protection には DDoS Rapid Response (DRR) チームのサポートが標準で含まれます。そのため、攻撃発生中に Microsoft の専門家が直接、調査と緩和支援を提供してくれます。

【参考】

DDoS Protection

AZ700-CORE#221 (pid=29776)

AZ700-CORE#32

NSG (Network Security Group) と ASG (Application Security Group) の動作に関する次の各記述について、正しい場合は「はい」、誤っている場合は「いいえ」を選択してください。

注: 正解 1 つにつき 1 点が与えられます。

ステートメント	はい	いいえ
NSG ルールは Priority の値が低い番号 (例: 100) から評価され、最初にマッチしたルールで決定される
1 つの NIC は最大 1 つの ASG にのみ所属できる
AVNM の Security Admin Rules は NSG より優先され、Always Deny で NSG の許可を上書きできる

ディスカッション 0

解説

【正解一覧】

ステートメント	正解
NSG ルールは Priority の値が低い番号	はい
1 つの NIC は最大 1 つの ASG にのみ所属できる	いいえ
AVNM の Security Admin Rules は NSG より優先され、Always Deny で NSG…	はい

【各判定の詳細】

「NSG ルールは Priority の値が低い番号」→ はい: NSG ルールは Priority の値が低い番号 (100〜4096) から順に評価され、最初にマッチしたルールでアクセス可否が決定されます。そのため、特定 IP のみ許可するルールは拒否ルールより低い番号で配置する必要があります。
「1 つの NIC は最大 1 つの ASG にのみ所属できる」→ いいえ: 1 つの NIC は複数の ASG に所属できるため、「Web 層 + 監視対象」のような役割の組み合わせを表現できます。これにより、NSG ルールで Source / Destination に ASG を指定する設計の柔軟性が大きく高まります。
「AVNM の Security Admin Rules は NSG より優先され、Always …」→ はい: AVNM の Security Admin Rules はテナント / Subscription レベルで強制され、NSG より高い優先度で評価されます。そのため、Always Deny に設定したルールは Subscription 内のすべての NSG 許可を上書きできます。

【参考】

NSG 概要

AZ700-CORE#220 (pid=29775)

AZ700-CORE#9

Azure VNet ピアリング (Regional + Global) に関する次の各記述について、正しい場合は「はい」、誤っている場合は「いいえ」を選択してください。

注: 正解 1 つにつき 1 点が与えられます。

ステートメント	はい	いいえ
VNet ピアリングは推移的で、A↔B と B↔C のピアリングがあれば A↔C は直接通信できる
Allow gateway transit を Hub 側で true、Use remote gateways を Spoke 側で true にすることで、Spoke が Hub の Gateway を利用できる
ピアリング先 VNet のアドレス空間が重複しているとピアリング作成は成功するが通信時にエラーになる

ディスカッション 0

解説

【正解一覧】

ステートメント	正解
VNet ピアリングは推移的で、A↔B と B↔C のピアリングがあれば A↔C は直接通信できる	いいえ
Allow gateway transit を Hub 側で true、Use remote gateways を …	はい
ピアリング先 VNet のアドレス空間が重複しているとピアリング作成は成功するが通信時にエラーになる	いいえ

【各判定の詳細】

「VNet ピアリングは推移的で、A↔B と B↔C のピアリングがあれば A↔C は直接通信できる」→ いいえ: VNet ピアリングは非推移的なため、A↔B と B↔C のピアリングがあっても A↔C は直接通信できません。そのため、Hub-Spoke で Spoke 間通信を実現するには Hub に NVA と UDR を配置するか、Virtual Network Manager を採用します。
「Allow gateway transit を Hub 側で true、Use remote g…」→ はい: Hub 側で Allow gateway transit を有効化し、Spoke 側で Use remote gateways を有効化すると、Spoke が Hub の VPN / ExpressRoute Gateway を共有利用できます。このため、Gateway を保有するのは Hub のみで済み、コストと運用負荷を大幅に削減できます。
「ピアリング先 VNet のアドレス空間が重複しているとピアリング作成は成功するが通信時にエラーになる」→ いいえ: ピアリング作成時に対向 VNet のアドレス空間が重複している場合、ピアリング作成自体が失敗します。そのため、通信時のエラーではなく作成時の検証段階で問題が検出される仕組みとなっています。

【参考】

VNet ピアリング

⭐ yesno シリーズ (9 series × 3 posts) (27 問)

AZ700-CORE#235-3 (pid=29797)

AZ700-CORE#119-3

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

あなたは既存の 10 Spoke 環境 (手動ピアリング管理) を Azure Virtual Network Manager (AVNM) に移行する必要があります。本番運用中のためダウンタイムゼロが要件です。

解決策

最初から動的メンバーシップ (タグベース) で AVNM を設定し、すべての Spoke を一括で動的所属させる。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

AVNM Network Group の動的メンバーシップは、初期段階から全 Spoke に適用すると設定ミスで意図しない VNet が所属し、想定外のピアリングや Security Admin Rules が広域適用されるリスクがあります。そのため、最初は Static で 1〜2 Spoke を追加して動作確認した後、動的メンバーシップへ移行するのが安全な順序となります。

【もし「はい」を選んだ場合】

「はい」と判定するといきなり動的化が正解となりますが、初期検証なしの動的化はリスクが高すぎます。そのため、Static で動作確認してから動的化への移行が推奨されます。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

Network Groups

AZ700-CORE#235-2 (pid=29796)

AZ700-CORE#119-2

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

解決策

既存の手動ピアリングをすべて削除してから AVNM をデプロイし、Connectivity 構成で再構築する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

既存ピアリングを先に削除してから AVNM で再構築する方式は、削除と新規構築の間に数分から数時間のダウンタイムが発生し、問題発生時のロールバックも困難となります。そのため、本番環境では並行運用 + 段階的切替が必須で、AVNM は既存ピアリングと共存可能な設計になっています。

【もし「はい」を選んだ場合】

「はい」と判定すると削除 → 再構築アプローチが正解となりますが、これはダウンタイムとロールバック困難という二重リスクを伴います。そのため、並行運用アプローチが正しい選択肢となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

AVNM Deployment

AZ700-CORE#235-1 (pid=29795)

AZ700-CORE#119-1

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

解決策

既存 10 Spoke の手動ピアリングを段階的に AVNM 移行: Step 1 AVNM 作成、Step 2 Network Group を Static で 1-2 Spoke 追加 + 検証、Step 3 残り Spoke を Static 追加、Step 4 動作確認後に旧手動ピアリング削除、Step 5 動的メンバーシップに移行。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: はい】の理由

並行運用 → 段階的検証 → 旧構成削除 → 動的化という標準移行パターンは、ダウンタイムゼロとロールバック可能性を両立する Microsoft 推奨アプローチです。そのため、50 以上の VNet 規模で本番に AVNM を導入する際は、必ずこの段階的方式を採用することが推奨されます。

【もし「いいえ」を選んだ場合】

「いいえ」と判定するとこの手順は不要になりますが、並行運用と段階的検証はリスク回避の基本パターンです。そのため、本番移行ではこの手順を厳守することが正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

AVNM Deployment

AZ700-CORE#234-3 (pid=29794)

AZ700-CORE#118-3

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

あなたは本番 Azure 環境 (10+ Public IP、Web 公開アプリ含む) に DDoS Protection を導入する必要があります。攻撃検知 + 緩和 + SOC 通知 + 監査ログ保持の要件があります。

解決策

DDoS Network Protection を有効化したら、シミュレーションなしで即時本番運用を開始する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

BreakingPoint Cloud (Microsoft 公認の DDoS シミュレーションパートナー) で 5〜50 Gbps の疑似攻撃を実施し、検知・Mitigation 起動・SOC 通知・Mitigation Report 生成の各動作を本番運用前に検証することは強く推奨されます。そのため、シミュレーションなしの本番運用は実機検証なしの構成と等しく、本物の攻撃発生時に意図せず障害となるリスクを抱えることになります。

【もし「はい」を選んだ場合】

「はい」と判定するとシミュレーション不要となりますが、本番運用前の検証は SOC 対応ランブック確認にも不可欠です。そのため、シミュレーション実施が正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

DDoS シミュレーション

AZ700-CORE#234-2 (pid=29793)

AZ700-CORE#118-2

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

解決策

DDoS Basic で十分なので、追加の DDoS Network Protection や IP Protection の有効化は不要。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

DDoS Basic は無料で自動有効化されますが、機能は Microsoft グローバルレベルの大規模 Volumetric 攻撃緩和のみで、カスタムベースライン学習・Mitigation Report・DRR (Rapid Response) サポートはありません。そのため、本番ワークロードの保護には DDoS Network Protection (Standard) の採用が必須となります。

【もし「はい」を選んだ場合】

「はい」と判定すると Basic で十分となりますが、Basic では DRR サポートやレポート機能が欠如しており、本番運用要件を満たせません。そのため、Standard へのアップグレードが正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

DDoS SKU 比較

AZ700-CORE#234-1 (pid=29792)

AZ700-CORE#118-1

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

解決策

DDoS Network Protection Plan を 1 つ作成し、本番 VNet に関連付け、Azure Monitor アラートを設定、1 週間のベースライン学習を待ってから BreakingPoint Cloud でシミュレーション検証する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: はい】の理由

DDoS Network Protection Plan の作成、Standard Public IP を持つ VNet への関連付け、Azure Monitor アラート、診断ログの Log Analytics 送信、約 1 週間のベースライン学習、BreakingPoint Cloud によるシミュレーション検証という流れは Microsoft 公式の標準導入手順となります。そのため、本番運用前にこのチェックリスト全項目を完了することが推奨されます。

【もし「いいえ」を選んだ場合】

「いいえ」と判定するとこの手順は不要となりますが、ベースライン学習とシミュレーション検証は本番品質を担保する必須プロセスです。そのため、Microsoft 推奨フローを完全実施することが正解です。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

DDoS Protection 管理

AZ700-CORE#233-3 (pid=29791)

AZ700-CORE#117-3

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

あなたは新規 AKS Cluster を構築し、Pod 間の通信を Defense in Depth に基づいて細粒度制御する Network Policy を実装する必要があります。クラスタ規模は約 100 ノード、5,000 Pod を想定しています。

解決策

AKS Cluster を Azure CNI モード + Calico Network Policy で構築、追加の eBPF/L7 機能なしでシンプルに運用する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: はい】の理由

Azure CNI は Pod が VNet IP を直接持つことで PaaS Private Endpoint との NAT なし通信を可能にし、Calico は iptables ベースで L3-L4 ポリシーを提供します。そのため、L7 までは不要な中規模クラスタで運用シンプルさを優先する場合は、CNI Overlay + Cilium と並ぶ妥当な選択肢となります。

【もし「いいえ」を選んだ場合】

「いいえ」と判定するとこの構成が不適切になりますが、Azure CNI + Calico は中小規模 AKS でシンプル運用を重視する標準パターンの 1 つです。そのため、要件次第で十分採用可能な構成となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	はい

【参考】

AKS Network Policy

AZ700-CORE#233-2 (pid=29790)

AZ700-CORE#117-2

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

解決策

AKS Cluster を Kubenet モードで構築、Network Policy は実装せず NSG のみでサブネット単位の制御する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

Kubenet は将来廃止予定で新規構築は非推奨となっており、Network Policy なしでは Pod 間通信を細粒度で制御できません。そのため、Defense in Depth が成立せず、本番環境では Azure CNI 系統と Cilium / Calico などのポリシーエンジンの組み合わせが必須となります。

【もし「はい」を選んだ場合】

「はい」と判定すると Kubenet + Policy なしで十分になりますが、廃止予定 + 細粒度制御不能の組み合わせは本番運用に不適切です。そのため、Azure CNI 系統への移行が正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	はい

【参考】

AKS ネットワーク概念

AZ700-CORE#233-1 (pid=29789)

AZ700-CORE#117-1

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

解決策

AKS Cluster を Azure CNI Overlay モード + Cilium (eBPF ベース) Network Policy Engine で構築し、Hubble UI で可観測性を確保する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: はい】の理由

Azure CNI Overlay は Pod IP をオーバーレイ範囲に配置することで VNet IP を節約しつつ Node のみ VNet IP を消費する Hybrid モデルで、Cilium は eBPF ベースで iptables より高速かつ L7 ポリシーと Hubble 可観測性を備えます。そのため、2024 年以降の AKS で大規模かつ高度な制御が必要な環境ではこの組み合わせが推奨されます。

【もし「いいえ」を選んだ場合】

「いいえ」と判定するとこの構成は不適切となりますが、Azure CNI Overlay と Cilium はそれぞれ IP 効率と高度ポリシーで AKS の主流選択肢です。そのため、本構成が正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	はい

【参考】

AKS Network Policy

AZ700-CORE#232-3 (pid=29788)

AZ700-CORE#116-3

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

あなたは大規模 Hub-Spoke 環境 (Hub + 50 Spoke VNet + オンプレハイブリッド) で、Azure Storage Account への Private Endpoint アクセスを構築します。オンプレクライアントと VNet 内クライアントの両方が、既存の Public URL (例: contosostor.blob.core.windows.net) でアクセスできる必要があります。

解決策

オンプレ DNS に privatelink.blob.core.windows.net の A レコードを手動で追加し、PE プライベート IP を静的指定する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

オンプレ DNS で hosts ファイルや静的レコードを手動メンテナンスする方式は、PE の追加・変更・削除のたびに更新が必要でスケールしません。そのため、Azure DNS Private Resolver + Forwarding Ruleset による条件付き転送で、Hybrid DNS 解決を自動化するのが正解となります。

【もし「はい」を選んだ場合】

「はい」と判定すると手動 DNS 運用で十分となりますが、PE プライベート IP の変動や Zone 数増加で運用が破綻します。そのため、Private Resolver を使った自動解決が正しい選択となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

DNS Private Resolver

AZ700-CORE#232-2 (pid=29787)

AZ700-CORE#116-2

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

解決策

各 Spoke VNet に個別の Private DNS Zone を作成し、各 VNet で独自に PE のレコードを管理する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

各 Spoke に個別の Private DNS Zone を作成すると、50 Spoke で 50 Zone を管理することになり、レコード同期エラーやコンフリクトが発生しやすくなります。そのため、Hub に Zone を 1 つ集中配置して全 Spoke からリンク参照させる設計が標準アプローチとなります。

【もし「はい」を選んだ場合】

「はい」と判定すると Spoke 個別 Zone が推奨されることになりますが、運用コストとレコード一貫性の観点から非推奨です。そのため、Hub 集中型の Zone 配置が正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

PE DNS パターン

AZ700-CORE#232-1 (pid=29786)

AZ700-CORE#116-1

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

解決策

Hub VNet に Private DNS Zone (privatelink.blob.core.windows.net) を 1 つ作成し、すべての Spoke VNet にリンク。Storage Account に PE 作成、Private DNS Zone Group で自動 A レコード登録。Azure DNS Private Resolver Inbound Endpoint をデプロイし、オンプレ DNS から条件付き転送する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: はい】の理由

Hub 集中型 Private DNS Zone と Private Endpoint + Zone Group の自動 A レコード登録、DNS Private Resolver による Hybrid 解決を組み合わせる構成は、Microsoft 公式の大規模 Hub-Spoke DNS ベストプラクティスです。これにより、運用効率と命名解決の一貫性が両立し、50 以上の Spoke でも単一の Zone リソースで管理できます。

【もし「いいえ」を選んだ場合】

「いいえ」と判定するとこの構成では要件を満たさないと読み取れますが、Hub 集中 + 自動 + Hybrid の 3 要素が揃っており、Microsoft が推奨する標準パターンに合致します。そのため、本構成が正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

Private Endpoint DNS 統合

AZ700-CORE#231-3 (pid=29785)

AZ700-CORE#115-3

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

あなたは本番 Azure 環境のオンプレ↔Azure VPN 接続を高可用 (SLA 99.95%) 構成にする必要があります。ゾーン障害、Gateway インスタンス障害、オンプレ機器障害のいずれにも耐性が必要です。

解決策

VPN Gateway は単一構成のままで、オンプレ機器を 3 台にして冗長化する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

オンプレ側のみ冗長化しても、Azure 側 Gateway が SPOF (Single Point of Failure) のままとなり、Gateway インスタンス障害やゾーン障害で接続が完全停止します。そのため、Azure 側も VpnGw[1-3]AZ + Active-Active + Public IP 2 つで対称的に冗長化する必要があります。

【もし「はい」を選んだ場合】

「はい」と判定するとオンプレ側冗長化だけで十分となりますが、Azure 側 Gateway の単一障害点が残ります。そのため、両側で冗長性を確保する設計が正解です。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

VPN GW 高可用性

AZ700-CORE#231-2 (pid=29784)

AZ700-CORE#115-2

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

解決策

VPN Gateway を VpnGw1 (Active-Standby、ゾーン非対応) で構成、Standard Public IP 1 つ、BGP 無効、オンプレ機器 1 台で単一トンネル構成にする。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

VpnGw1 (AZ なし) はゾーン非対応、Active-Standby はフェイルオーバ中の一時切断、BGP 無効では静的経路のみ、オンプレ 1 機器ではオンプレ障害で全停止と、本構成は冗長要素を全て欠いています。そのため、本番運用では VpnGw1 AZ 以上 + Active-Active + BGP + オンプレ 2 機器の組み合わせが必須となります。

【もし「はい」を選んだ場合】

「はい」と判定すると本構成で十分と読み取れますが、ゾーン障害・Gateway 障害・オンプレ機器障害のいずれにも耐えられない構成です。そのため、本番環境ではより冗長な構成へ移行する必要があります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

VPN Gateway SKU

AZ700-CORE#231-1 (pid=29783)

AZ700-CORE#115-1

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

解決策

VPN Gateway を VpnGw2AZ SKU (Zone-redundant) で Active-Active 構成、Standard SKU の Zone-redundant Public IP を 2 つ準備、BGP を有効化、オンプレ機器も 2 台で全 Mesh トンネル構成にする。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: はい】の理由

VpnGw2AZ SKU で Active-Active + BGP を有効化し、オンプレ側 2 機器との Full Mesh 4 トンネル構成にすると、Azure Zone 障害・Gateway インスタンス障害・オンプレ機器障害のいずれにも耐性を持つ完全冗長構成となります。これにより、BGP による自動切替と ECMP による帯域実質倍増が同時に実現します。

【もし「いいえ」を選んだ場合】

「いいえ」と判定するとこの構成では冗長性が不足と読み取れますが、Zone 耐性 + Active-Active + BGP + オンプレ Mesh はすべての主要冗長要素を備えています。そのため、本構成は SLA 99.95% を超える耐障害性を実現する Microsoft 推奨パターンとなります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

VPN Gateway 高可用性

AZ700-CORE#230-3 (pid=29782)

AZ700-CORE#114-3

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

あなたは Hub-Spoke 環境を運用しており、Spoke A の VM から Spoke B の VM への通信を実現する必要があります。Hub VNet には Azure Firewall がデプロイされています。VNet ピアリングは Spoke A↔Hub、Spoke B↔Hub で構成済みです。

解決策

Hub VNet にもう 1 つの VPN Gateway を追加して、それを介して Spoke 間通信させる。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

VPN Gateway はオンプレ↔Azure の S2S / P2S 接続用リソースで、Azure 内の Spoke 間通信を Transit させる用途には設計されていません。そのため、Spoke 間通信は Azure Firewall + UDR、または AVNM の Mesh トポロジで実現するのが適切となります。

【もし「はい」を選んだ場合】

「はい」と判定すると VPN Gateway を Spoke 間 Transit に使うことになり、無駄なレイテンシとコスト増加を招きます。そのため、Spoke 間通信は Azure Firewall + UDR で構成するのが正しい選択肢となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

Azure Firewall FAQ

AZ700-CORE#230-2 (pid=29781)

AZ700-CORE#114-2

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

解決策

Spoke A と Spoke B の VNet 間に直接 VNet ピアリングを追加する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

Spoke 間ピアリングを直接張ること自体は技術的に可能ですが、Hub-Spoke 設計の本来の目的である中央セキュリティ検査が損なわれ、N×(N-1)/2 のペア管理は 50 以上の Spoke 規模で破綻します。そのため、原則は Hub Firewall 経由とし、例外的に低レイテンシ要件がある場合のみ AVNM の Hub-Spoke with Direct Connectivity を検討します。

【もし「はい」を選んだ場合】

「はい」と判定すると Spoke 間直接ピアリングを推奨することになりますが、運用負荷とセキュリティ検査の観点から本番では避けるべき設計です。そのため、Spoke 間通信は Hub の Firewall を経由させるのが原則となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

AVNM Connectivity

AZ700-CORE#230-1 (pid=29780)

AZ700-CORE#114-1

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

解決策

Spoke A のサブネットに UDR を設定し、Spoke B のアドレス範囲への Next Hop を Hub の Azure Firewall のプライベート IP に向ける。Hub のピアリング設定で Allow forwarded traffic を true にする。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: はい】の理由

VNet ピアリングは非推移的なため、Spoke A↔Spoke B の直接通信は標準ピアリングだけでは成立しません。そのため、Hub に配置した Azure Firewall や NVA を経由するように UDR を構成し、ピアリング側で Allow forwarded traffic を有効化する Hub-Spoke + NVA パターンが標準解となります。

【もし「いいえ」を選んだ場合】

「いいえ」と判定すると Hub Firewall 経由の Spoke 間通信が不要と読み取れますが、Hub-Spoke 設計では中央 Firewall による検査が前提となります。そのため、UDR + Allow forwarded traffic で Hub 経由のルーティングを成立させる方式が正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

Hub-Spoke + NVA パターン

AZ700-CORE#89-3 (pid=29706)

AZ700-CORE#121-3

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

(設問 1 と同じシナリオ)

解決策

Azure ARM テンプレートで 50 VNet 構成を Infrastructure as Code (IaC) として定義し、Git リポジトリで版管理、CI/CD パイプライン (Azure DevOps Pipeline) で自動デプロイする。NSG ルールも IaC で管理。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

IaC (ARM / Bicep / Terraform) は構成の版管理に優れますが、新規 VNet 追加時に IaC 更新とパイプライン実行が必要なため、AVNM Network Group の動的メンバーシップによる「真の自動所属」とは異なります。そのため、運用効率の観点では AVNM が IaC の上位互換となる場面が多くあります。

【もし「はい」を選んだ場合】

「はい」と判定すると IaC で十分となりますが、健全性監視や動的所属の要件は IaC では完全に満たせません。そのため、AVNM 採用が正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

AVNM 概要

AZ700-CORE#89-2 (pid=29705)

AZ700-CORE#121-2

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

(設問 1 と同じシナリオ)

解決策

各 VNet に手動でピアリングを設定し、NSG を VNet ごとに個別管理、Azure Policy で組織標準ルールを強制、Azure Monitor のカスタムダッシュボードで健全性を可視化する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

手動ピアリング管理は 50 VNet 規模で N×(N-1)/2 = 1,225 ペアの手動運用となり、ヒューマンエラーのリスクが極めて高くなります。Azure Policy は構成監査には有効ですが、リアルタイムなセキュリティルール強制には限界があります。そのため、AVNM による自動管理と Security Admin Rules による強制が正解となります。

【もし「はい」を選んだ場合】

「はい」と判定すると手動 + Policy 構成が正解となりますが、運用工数とリアルタイム強制の観点で AVNM に劣ります。そのため、AVNM 採用が正しい選択肢です。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

AVNM Security Admin

AZ700-CORE#89-1 (pid=29704)

AZ700-CORE#121-1

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

あなたは 50 VNet (Hub-Spoke 構成) の大規模 Azure 環境を運用しています。要件は (1) 全 VNet のネットワーク構成変更を中央集権的に管理、(2) コンプライアンス監査用に組織標準のセキュリティルール (RDP/SSH 公開禁止) を強制、(3) 新規 VNet が追加されたら自動的に Hub にピアリング、(4) ネットワーク健全性を一元監視。手動で 50 VNet を個別管理することは現実的でないため、自動化アプローチが必要です。

解決策

Azure Virtual Network Manager (AVNM) を導入し、Network Group の動的メンバーシップで VNet を自動所属、Connectivity 構成で Hub-Spoke 自動ピアリング、Security Admin Rules で組織標準ルール強制、Network Insights で健全性監視を実現する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: はい】の理由

AVNM (Network Group + Connectivity + Security Admin Rules) と Network Insights (Azure Monitor for Networks) の組み合わせにより、中央集権管理・セキュリティルール強制・新 VNet 自動ピアリング・健全性監視の 4 要件をすべてカバーできます。そのため、本構成は 50 以上の VNet 規模で運用工数を最小化する Microsoft 推奨パターンとなります。

【もし「いいえ」を選んだ場合】

「いいえ」と判定するとこの構成では要件を満たさないことになりますが、AVNM + Network Insights は中央管理シナリオの標準ソリューションです。そのため、本構成が正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

AVNM 概要

AZ700-CORE#59-3 (pid=29674)

AZ700-CORE#120-3

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

(設問 1 と同じシナリオ)

解決策

Microsoft Defender for Cloud の Network Security 推奨事項を有効化することで、すべてのネットワークフロー監視と異常検知、ログ保持が自動で行われる。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

Defender for Cloud は NSG 構成推奨や Secure Score の評価、Attack Path 分析を提供しますが、すべてのネットワークフローを記録する機能は持たないため、補完的なセキュリティポスチャ管理ツールという位置付けです。そのため、フロー監査要件には NSG Flow Logs + Traffic Analytics の併用が必要となります。

【もし「はい」を選んだ場合】

「はい」と判定すると Defender for Cloud だけで監査要件を満たすことになりますが、フロー記録は対象外です。そのため、NSG Flow Logs と組み合わせて運用するのが正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

Defender for Cloud

AZ700-CORE#59-2 (pid=29673)

AZ700-CORE#120-2

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

(設問 1 と同じシナリオ)

解決策

各 VM に IIS ログを書き込ませ、Azure VM Backup でログをバックアップして保持する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: いいえ】の理由

IIS ログは Web リクエストのアプリケーション層 (HTTP ステータス) を記録するもので、L3 / L4 のネットワークフローやプロトコルレベルの許可・拒否情報は捕捉できません。そのため、ネットワーク監視には NSG Flow Logs + Traffic Analytics の構成が必須となり、IIS ログでは要件を満たせません。

【もし「はい」を選んだ場合】

「はい」と判定すると IIS ログでネットワーク監視が可能となりますが、IIS は Web リクエスト記録に限定された機能です。そのため、ネットワークレベルでは NSG Flow Logs の採用が正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

Traffic Analytics

AZ700-CORE#59-1 (pid=29672)

AZ700-CORE#120-1

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

あなたは Hub-Spoke 構成の Azure 環境でネットワーク監視を構築しています。要件は (1) すべての Spoke サブネットのフロー監視、(2) 異常な通信パターンの自動検知、(3) 6 ヶ月間のログ保持、(4) コンプライアンス監査用のログ完全性保証です。Network Watcher と関連サービスを使って実現します。

解決策

各 Spoke のサブネットに紐づく NSG に対して NSG Flow Logs V2 を有効化し、ログを Storage Account (Cool/Archive 階層) に保存。Traffic Analytics を有効化して Log Analytics Workspace に集約する。Storage Account には Immutability Policy を設定する。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【正解: はい】の理由

NSG Flow Logs V2 で 5-tuple とフロー状態を記録し、Traffic Analytics で Threat Intelligence と異常検知を行い、Storage Account の Immutability Policy + 階層化ストレージ (Hot / Cool / Archive) で 6 ヶ月以上の保持と改ざん防止を実現します。そのため、本構成はネットワークフロー監視のすべての要件を満たします。

【もし「いいえ」を選んだ場合】

「いいえ」と判定するとこの構成では不十分になりますが、V2 + Traffic Analytics + Immutability の組み合わせはネットワーク監査の標準パターンです。そのため、本構成が正解となります。

【シリーズ全体の正解一覧】

問	ステートメント	正解
問1	この解決策は要件を満たしますか?	はい
問2	この解決策は要件を満たしますか?	いいえ
問3	この解決策は要件を満たしますか?	いいえ

【参考】

NSG Flow Logs

AZ-700-CORE#3-3 (pid=29623)

AZ-700-CORE#3-3

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

(設問 1 と同じシナリオ)

解決策

Hub VNet の Azure Firewall (Standard tier) を経由してすべての外部 SaaS への HTTPS 通信を強制トンネリングする。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

AZ-700-CORE#3-2 (pid=29622)

AZ-700-CORE#3-2

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

(設問 1 と同じシナリオ)

解決策

Spoke の VM に Public IP を直接付与し、System Default Outbound にトラフィックを流す。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【判定: いいえ】の理由

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	○	低	◎

【参考】

Default Outbound Access の廃止

AZ-700-CORE#3-1 (pid=29621)

AZ-700-CORE#3-1

注: この問題は、同じ前提を持つ一連の問題の一部です。それぞれの問題には異なる解決策が提示されます。

前提

あなたは Hub-Spoke 構成の Azure 環境で、Spoke の VM から多数の外部 SaaS API への大量並列 HTTPS 通信を行います。Source NAT (SNAT) ポート枯渇 (SNAT exhaustion) を回避し、安定したアウトバウンド接続を確保したい設計です。

解決策

Spoke のサブネットに NAT Gateway を関連付け、専用の Public IP プレフィックス (/28) を割り当てる。

この解決策は要件を満たしますか?

A.はい B.いいえ

ディスカッション 0

解説

【判定: はい】の理由

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 は別)	◎

【参考】

Azure NAT Gateway 概要

AZ-700 Core 142 問 再構成完了 (8 フィードバック対応)

🟡 single_choice (4 択 1 答) (60 問)

解説

【正解: A】の理由

【トラフィック フロー】

【他選択肢が違う理由】

【参考】

解説

【正解: A】の理由

【経路詳細】

【他選択肢が違う理由】

【参考】

解説

【正解: A】の理由

【SKU 値の一覧】

【他選択肢が違う理由】

【参考】

【ベスト プラクティス】

【関連リソース】

解説

【正解: A】の理由

【Gateway Transit 設定マトリクス】

【他選択肢が違う理由】

【参考】

【ベスト プラクティス】

【関連リソース】

解説

【正解: A】の理由

【他選択肢が違う理由】

【Azure PowerShell パターン】

【参考】

【ベスト プラクティス】

【関連リソース】

解説

【正解: A】の理由

【Agent インストール方法】

【Agent が有効化する機能】

【他選択肢が違う理由】

【参考】

【Network Watcher Agent 機能】

【Agent インストール方法】

解説

【正解: A】の理由

【Mitigation Report の用途】

【Mitigation Report 取得方法】

【他選択肢が違う理由】

【参考】

【DDoS Telemetry メトリクス一覧】

【SOC 対応プロセス】

解説

【正解: A】の理由

【Alias vs CNAME】

【典型ユース ケース】

【参考】

【Alias レコードの自動追従】

【Alias vs A レコードの違い】

解説

【正解: A】の理由

【Routing Preference 比較】

【参考】

【Storage Routing オプション影響】

【ユース ケース別推奨】

解説

【正解: A】の理由

【Listener タイプ】

【典型構成例】

【他選択肢が違う理由】

【参考】

【AppGW Listener 構成例】

【Multi-site の制約】

【URL Path-based Routing と組み合わせ】

解説

【正解: A】の理由

【IKE フェーズ 1 vs 2 失敗の典型原因】

【トラブル シュート手順】

【他選択肢が違う理由】

【参考】

【VPN IPsec/IKE パラメータ詳細】

【ベンダー別推奨】

解説

AZ-700 Core 142 問再構成完了 (8 フィードバック対応)

【トラフィックフロー】

【ベストプラクティス】

【ベストプラクティス】

【ベストプラクティス】

【典型ユースケース】

【ユースケース別推奨】

【トラブルシュート手順】

【IPv6 デュアルスタック対応サービス】

【典型ユースケース】

【典型ユースケース】

【Mesh の典型ユースケース】