WEB問題集
AZ700-PVT#9
Service Endpoint Policies の目的として最も適切なものはどれですか?
解説
【正解: A】の理由
Service Endpoint Policies は Service Endpoint 経由で「どの Storage Account にアクセス許可するか」を細粒度制御するセキュリティ機能です。これにより、VNet 内からの データ流出 (例: 不正な外部 Storage への書き込み) を防ぐ Zero Trust 設計が実現します。
【他選択肢が違う理由】
- B: Service Endpoint の有効化はサブネット設定で行います。
- C: Private Endpoint との直接的な関係はありません。
- D: TLS 強制は Storage Account 側の設定 (Minimum TLS version) で行います。
【参考】
AZ700-PVT#10
各 PaaS サービスに対応する Microsoft 推奨 Private DNS Zone 名を選んでください。
| ステートメント | 選択 |
|---|---|
Storage Blob Storage Blob 用の Private Endpoint には privatelink.blob.core.windows.net Zone を関連付けるのが Microsoft 推奨です。これにより、Public エンドポイントの blobname.blob.core.windows.net が PE プライベート IP に解決される設計が実現します。 | |
Azure SQL Database Azure SQL Database の Private Endpoint には privatelink.database.windows.net Zone が推奨されます。そのため、myserver.database.windows.net が VNet 内で PE プライベート IP に解決されるようになります。 | |
Azure Cosmos DB (Core SQL API) Cosmos DB Core SQL API の Private Endpoint には privatelink.documents.azure.com Zone を関連付けます。MongoDB / Cassandra 等の他 API はそれぞれ専用 Zone (例: privatelink.mongo.cosmos.azure.com) を使用します。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| Storage Blob | privatelink.blob.core.windows.net |
| Azure SQL Database | privatelink.database.windows.net |
| Azure Cosmos DB | privatelink.documents.azure.com |
【各判定の詳細】
- 「Storage Blob」→ privatelink.blob.core.windows.net: Storage Blob 用の Private Endpoint には privatelink.blob.core.windows.net Zone を関連付けるのが Microsoft 推奨です。これにより、Public エンドポイントの blobname.blob.core.windows.net が PE プライベート IP に解決される設計が実現します。
- 「Azure SQL Database」→ privatelink.database.windows.net: Azure SQL Database の Private Endpoint には privatelink.database.windows.net Zone が推奨されます。そのため、myserver.database.windows.net が VNet 内で PE プライベート IP に解決されるようになります。
- 「Azure Cosmos DB」→ privatelink.documents.azure.com: Cosmos DB Core SQL API の Private Endpoint には privatelink.documents.azure.com Zone を関連付けます。MongoDB / Cassandra 等の他 API はそれぞれ専用 Zone (例: privatelink.mongo.cosmos.azure.com) を使用します。
【参考】
AZ700-PVT#11
Storage Account に Private Endpoint を構築した後、Zero Trust 設計として Public Network Access を Disabled にする手順を正しい順序に並べてください。
- PE 経由の VNet 内アクセスを動作確認
- PE 経由で接続できる関連サービス (App Service / Function 等) をすべて棚卸し
- Storage Account の Public Network Access を Disabled に切替
- 診断ログで PE 経由トラフィックを継続監視
解説
【正しい順序】
- ステップ 1: PE 動作確認
- ステップ 2: 関連サービス棚卸し
- ステップ 3: Public Disable
- ステップ 4: 継続監視
【各ステップの理由】
- ステップ 1 PE 動作確認: まず PE 経由で VNet 内 VM から Storage に正常に接続できることを確認します。
- ステップ 2 関連サービス棚卸し: PE 経由でアクセスする App Service / Function App / Logic App などをすべて把握します。
- ステップ 3 Public Disable: Storage Account 設定で Public Network Access を Disabled に切り替えます。これにより、PE 経由のみのアクセスとなります。
- ステップ 4 継続監視: 診断ログで PE 経由トラフィックの正常性と Public エラー (アクセス失敗の試行) を監視します。
【誤った順序の問題点】
- PE 確認なしで Public Disable: PE が正常動作していないと Storage への全アクセスが切断され、運用障害となります。
- 棚卸しなし: PE 経由でない関連サービスがあると、Public Disable 後に接続不能となり業務影響が出ます。
【参考】
AZ700-PVT#12
Private Endpoint の動作について、各記述が正しいか判定してください。
| ステートメント | はい | いいえ |
|---|---|---|
Private Endpoint を作成しても、Storage Account の Public Network Access は自動的に Disabled にはならない Private Endpoint と Public Network Access Disable は別々の操作で、PE を作成しても Storage Public エンドポイントは自動的には閉じられません。そのため、Zero Trust 設計では PE 作成後に明示的に Public Network Access を Disabled に切り替える必要があります。 | ||
Private Endpoint は VPN/ExpressRoute 経由でオンプレからもプライベート IP でアクセスできる Private Endpoint は VNet 内のプライベート IP を持つため、VPN または ExpressRoute 経由でオンプレからも到達可能となります。これにより、Hybrid 環境でも Public Internet を経由しない Storage / SQL アクセスが実現します。 | ||
Private DNS Zone Group は Private Endpoint と関係なく、独立して動作する Private DNS Zone Group は Private Endpoint と Private DNS Zone を結びつけて A レコードを自動管理する機能です。そのため、独立して動作するのではなく PE と密接に連携する関係にあります。 |
解説
【正解一覧】
| ステートメント | 正解 |
|---|---|
| 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 と Public Network Access Disable は別々の操作で、PE を作成しても Storage Public エンドポイントは自動的には閉じられません。そのため、Zero Trust 設計では PE 作成後に明示的に Public Network Access を Disabled に切り替える必要があります。
- 「Private Endpoint は VPN/ExpressRoute 経由でオンプレからもプラ…」→ はい: Private Endpoint は VNet 内のプライベート IP を持つため、VPN または ExpressRoute 経由でオンプレからも到達可能となります。これにより、Hybrid 環境でも Public Internet を経由しない Storage / SQL アクセスが実現します。
- 「Private DNS Zone Group は Private Endpoint と関係なく、…」→ いいえ: Private DNS Zone Group は Private Endpoint と Private DNS Zone を結びつけて A レコードを自動管理する機能です。そのため、独立して動作するのではなく PE と密接に連携する関係にあります。
【参考】
AZ700-PVT#13
Cross-region Private Endpoint について、正しい記述はどれですか?
解説
【正解: A】の理由
Azure Private Endpoint は Cross-region 構成に対応しており、対象 PaaS リソース (例: Storage in East US) とは異なる region (例: Japan East) の VNet に PE を作成可能です。これにより、グローバル分散企業で region をまたいだ閉域アクセス設計が実現します。
【他選択肢が違う理由】
- B: 同一 region 制約はなく、Cross-region 構成可能です。
- C: 廃止予定ではなく、現役機能です。
- D: Global region 専用ではなく、各 region で利用可能です。
【参考】
AZ700-PVT#14
各要素を、Private Endpoint アーキテクチャでの役割にマッチさせてください。
項目（ドラッグしてください）
- PE のプライベート IP 取得元
- privatelink.blob.core.windows.net のホスト名解決を提供
- PE と Zone の紐付けで A レコード自動登録
- PaaS に向けた VNet 内 NIC
PE NIC (Private IP)
Private DNS Zone
Private DNS Zone Group
PE 用サブネット
解説
【正しいマッチング完全版】
※ サブネットが IP を提供、Zone が名前解決、Zone Group が自動連携、NIC が PaaS への窓口、という階層構造を覚えると PE 設計が明確になります。
- PE のプライベート IP 取得元 → PE 用サブネット
- privatelink.blob.core.windows.net のホスト名解決を提供 → Private DNS Zone
- PE と Zone の紐付けで A レコード自動登録 → Private DNS Zone Group
- PaaS に向けた VNet 内 NIC → PE NIC (Private IP)
【正解マッチング】
| 機能 | 対応 |
|---|---|
| PE のプライベート IP 取得元 | PE 用サブネット |
| privatelink.blob.core.windows.net のホスト… | Private DNS Zone |
| PE と Zone の紐付けで A レコード自動登録 | Private DNS Zone Group |
| PaaS に向けた VNet 内 NIC | PE NIC (Private IP) |
【参考】
AZ700-PVT#15
Private Endpoint の NIC に NSG を関連付けて Inbound 制御したい場合、有効化が必要な機能はどれですか?
解説
【正解: A】の理由
PE NIC に対する NSG 制御を有効化するには、PE サブネットの PrivateEndpointNetworkPolicies プロパティを Enabled に設定します。これにより、NSG 経由で PE NIC のインバウンド通信を細粒度制御できるようになります。
【他選択肢が違う理由】
- B: NSG は VNet スコープで、Subscription レベル直接適用は標準機能ではありません (AVNM 経由は別概念)。
- C: PE 自体への直接 NSG 関連付けはサブネット経由のため、サブネット側設定変更が必要です。
- D: NSG 制御は可能ですが、デフォルト設定 (Disabled) を変更する必要があります。
【参考】
AZ700-PVT#16
オンプレ クライアントから Azure Storage の Private Endpoint へ DNS 解決を経由してアクセスできるようにする Hybrid DNS 構成手順を、正しい順序に並べてください。
- Storage Account に PE を作成 (Hub VNet サブネット)
- Private DNS Zone (privatelink.blob.core.windows.net) を Hub VNet にリンク
- DNS Private Resolver の Inbound endpoint を Hub VNet にデプロイ
- オンプレ DNS で blob.core.windows.net 系列を Resolver Inbound IP へ条件付き転送
解説
【正しい順序】
- ステップ 1: PE 作成
- ステップ 2: Private DNS Zone リンク
- ステップ 3: Resolver Inbound デプロイ
- ステップ 4: オンプレ DNS 条件付き転送
【各ステップの理由】
- ステップ 1 PE 作成: Storage Account 用の PE を Hub VNet のサブネットに配置します。
- ステップ 2 Private DNS Zone リンク: PE 用の Private DNS Zone を Hub VNet にリンクし、A レコードを自動登録します。
- ステップ 3 Resolver Inbound デプロイ: DNS Private Resolver の Inbound endpoint を Hub VNet に配置します。これがオンプレからの DNS クエリ受信ポイントとなります。
- ステップ 4 オンプレ DNS 条件付き転送: オンプレ DNS で blob.core.windows.net 系列を Resolver Inbound IP に条件付き転送します。これで Hybrid DNS 解決が完成します。
【誤った順序の問題点】
- Resolver なしで条件付き転送先を指定: 転送先 (Resolver Inbound IP) が存在せず、オンプレからの DNS クエリが失敗します。
- Private DNS Zone リンクなしで Resolver 配置: PE の A レコードが Zone にないため、Resolver 経由で解決できません。
【参考】
AZ700-PVT#17
Azure Private Endpoint の課金モデルとして正しい記述はどれですか?
解説
【正解: A】の理由
Azure Private Endpoint は PE 1 つあたりの時間課金 (約 $0.01/時間) と、PE 経由のデータ転送量 (Inbound / Outbound) で課金されます。そのため、PE を多数作成する大規模環境では数 + データ転送料金を試算しておくことが重要となります。
【他選択肢が違う理由】
- B: 無料ではなく時間 + データ転送課金です。
- C: Storage Account とは独立した課金体系です。
- D: 本番でも月額固定ではなく時間 + 従量です。
【参考】
AZ700-PVT#18
Private Endpoint の NSG 制御について、各記述が正しいか判定してください。
| ステートメント | 選択 |
|---|---|
PE サブネットの PrivateEndpointNetworkPolicies を Enabled にすると、NSG で PE NIC のインバウンド制御が可能になる PrivateEndpointNetworkPolicies を Enabled にすることで、NSG ルールが PE NIC に適用され、ソース IP やプロトコル / ポートでのインバウンド制御が可能となります。これにより、PE への接続を細粒度に制限する Zero Trust 設計が実現します。 | |
Private Endpoint は VNet 内のリソースであるため、UDR で経路制御することもできる PE は VNet 内のプライベート IP リソースのため、UDR で経路を制御できます。そのため、PE への通信を中央 Firewall 経由でルーティングする設計も可能となります。 | |
Private Endpoint は NSG / UDR の制御を受けない (バイパス) PE は VNet 内リソースとして NSG / UDR の制御を受ける対象です。そのため、サブネット設定で NetworkPolicies を Enabled にすると NSG ルールが適用され、UDR で経路制御も機能します。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| PE サブネットの PrivateEndpointNetworkPolicies を Enabled にすると、NS… | はい |
| Private Endpoint は VNet 内のリソースであるため、UDR で経路制御することもできる | はい |
| Private Endpoint は NSG / UDR の制御を受けない | いいえ |
【各判定の詳細】
- 「PE サブネットの PrivateEndpointNetworkPolicies を Enabl…」→ はい: PrivateEndpointNetworkPolicies を Enabled にすることで、NSG ルールが PE NIC に適用され、ソース IP やプロトコル / ポートでのインバウンド制御が可能となります。これにより、PE への接続を細粒度に制限する Zero Trust 設計が実現します。
- 「Private Endpoint は VNet 内のリソースであるため、UDR で経路制御するこ…」→ はい: PE は VNet 内のプライベート IP リソースのため、UDR で経路を制御できます。そのため、PE への通信を中央 Firewall 経由でルーティングする設計も可能となります。
- 「Private Endpoint は NSG / UDR の制御を受けない」→ いいえ: PE は VNet 内リソースとして NSG / UDR の制御を受ける対象です。そのため、サブネット設定で NetworkPolicies を Enabled にすると NSG ルールが適用され、UDR で経路制御も機能します。