WEB問題集
AZ700-CORE#1
Public IP Prefix (Azure マネージドの連続 Public IP 範囲) を作成する主な利点はどれですか?
解説
【正解: B】の理由
Public IP Prefix は、連続した Public IP アドレス範囲 (例: /28 = 16 個) をまとめて確保するリソースです。利点は外部システムのファイアウォール許可リスト (allowlist) や DNS A レコード管理を単一の CIDR で行えることです。個別 Public IP を多数作成すると、それぞれの IP を Allowlist に追加・削除する運用が必要になります。
【他選択肢が違う理由】
- A. 料金無料: Public IP Prefix にも通常の Public IP 料金がかかります。
- C. 無制限: サブスクリプション上限あり、Prefix のサイズは /28〜/31 から選択します。
- D. プライベート IP も: Public IP Prefix は Public IP のみが対象です。
【参考】
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 内に配置
解説
【正しい順序】
- ステップ 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 接続方法】
| 方法 | 用途 |
|---|---|
| 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 から アクセス不可
AZ700-CORE#3
Azure VNet に関する次の構成項目を、Azure の制約に照らして正しい値を選んでください。
| ステートメント | 選択 |
|---|---|
VNet のアドレス空間に RFC 1918 以外 (例: 100.64.0.0/10 や Public IP) を指定できる 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 のアドレス空間に 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 設計が可能となります。
【参考】
AZ700-CORE#4
Application Gateway v2 の Listener タイプ「Multi-site」の用途はどれですか?
解説
【正解: 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 ベース分岐が目的。
【参考】
【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」のような多段ルーティング実現します。
AZ700-CORE#5
Subnet Delegation について、適切な用途を 2 つ選んでください。
2 つ選択してください
解説
【正解: 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 環境で検証
- 変更管理プロセスに従い、段階的な展開を実施
- 監視 + アラートを有効化し、運用品質を継続的に評価