Technical Lab: Plan private endpoints
Questions
Question 1 — Multiple Choice
An architecture team needs to expose an Azure SQL Database service exclusively to workloads running on a specific VNet, without traffic transiting through the public internet. The additional requirement is that the IP address assigned to the access point should be predictable and belong to the VNet's own address space.
Which resource natively meets this requirement?
A) Service endpoint configured on the VNet subnet, with access policy restricted to the service
B) Private endpoint with a NIC provisioned on the target subnet, linked to the resource via Private Link
C) VNet peering with Azure SQL's managed network, enabling direct routing between networks
D) Application Gateway with backend pool pointing to the Azure SQL private FQDN
Question 2 — Technical Scenario
A team configured a private endpoint for a storage account in a VNet. After configuration, the VM within the same VNet can access the storage successfully. However, a second VM located in a peered VNet tries to access the same storage via the private FQDN and receives a timeout.
The administrator verifies that:
- Peering is active and general traffic between VNets works normally
- The NSG on the private endpoint subnet doesn't block traffic
- The remote VM uses Azure's default DNS server
nslookup mystorageaccount.blob.core.windows.net
Server: 168.63.129.16
Address: 168.63.129.16
Non-authoritative answer:
Name: mystorageaccount.blob.core.windows.net
Address: 52.XXX.XXX.XXX <-- Public IP
What is the root cause of the problem?
A) Peering doesn't propagate private endpoint routes between VNets by default, requiring "Use Remote Gateways" to be enabled
B) The private DNS zone linked to the private endpoint is not associated with the remote VNet, causing resolution via public DNS
C) The peered VNet's NSG is blocking port 443 toward the endpoint's private IP
D) The private endpoint needs to be recreated with the "Allow access from all networks" option enabled on the storage account
Question 3 — True or False
A private endpoint provisioned in a subnet with Network Policies enabled (such as NSG and UDR) will have these policies applied to traffic entering and leaving the endpoint's NIC, allowing the administrator to control flow through NSG rules directly on the private endpoint subnet.
True or False?
Question 4 — Technical Scenario
An organization is designing connectivity for a hub-and-spoke environment. The spokes host workloads that need to consume PaaS services via private endpoints. The architect proposes centralizing all private endpoints in the hub and using private DNS resolved from a custom DNS server also in the hub.
During testing, VMs in the spokes can reach the endpoint's private IP directly (via route), but name resolution fails for PaaS service FQDNs.
The custom DNS server in the hub forwards queries to 168.63.129.16 (Azure DNS).
; Spoke VM query
nslookup mykeyvault.vault.azure.net
Server: 10.0.0.10 <-- Custom DNS in hub
Address: 10.0.0.10
** server can't find mykeyvault.vault.azure.net: NXDOMAIN
Which adjustment resolves the resolution problem?
A) Manually create an A record in the Azure Key Vault public DNS zone pointing to the private endpoint IP
B) Link the private DNS zone to the hub VNet where the custom DNS server is hosted, so Azure DNS resolves correctly when receiving the forward
C) Replace the custom DNS server with native Azure DNS in all spokes, eliminating the need for forwarding
D) Enable "DNS Proxy" in Azure Firewall on the spokes to intercept queries before they reach the hub
Question 5 — Multiple Choice
When planning private endpoints for a service that exposes multiple sub-resources (such as a storage account with blob, file, queue and table), which statement correctly describes the expected provisioning and DNS behavior?
A) A single private endpoint can be created for all sub-resources simultaneously, and a single private DNS zone resolves all FQDNs
B) Each sub-resource requires a separate private endpoint and a distinct private DNS zone per sub-resource
C) A single private endpoint covers all sub-resources, but each sub-resource requires its own private DNS zone for correct resolution
D) Sub-resources share the same private IP assigned to the private endpoint, differing only by the TCP port used
Answer Key and Explanations
Answer Key — Question 1
Answer: B
A private endpoint provisions a NIC with a private IP belonging to the VNet's address space and links this IP to a specific PaaS resource via Azure Private Link. Traffic never leaves to the public internet; it remains entirely within Microsoft's backbone and the customer's VNet. The IP is predictable because it's allocated from the subnet like any other NIC.
The main conceptual error in the distractors is confusing service endpoint with private endpoint. Service endpoints (A) don't assign a VNet IP to the service; they only extend the VNet's identity to the public service access route, and the service IP remains public. VNet peering (C) connects networks but doesn't resolve routing to Microsoft-managed PaaS services. Application Gateway (D) is a layer 7 load balancer and doesn't create private access to PaaS services.
Answer Key — Question 2
Answer: B
The nslookup output shows that the remote VM is resolving the FQDN to the storage account's public IP. This indicates private DNS resolution failure, not a routing or NSG issue, since general traffic between VNets works.
Correct operation depends on the private DNS zone (privatelink.blob.core.windows.net) being associated (linked) to the VNet of the VM making the query. When custom DNS or native Azure DNS receives the query, it only returns the endpoint's private IP if the requesting VNet is linked to the private zone. The remote VNet wasn't linked, so the query escaped to public resolution.
The conceptual error in the distractors is focusing on routing (A) and NSG (C), when the diagnosis already shows the problem is name resolution. Option D reverses the logic: "allow access from all networks" refers to the storage account firewall on the data plane, not DNS or the private endpoint.
Answer Key — Question 3
Answer: False
By default, Network Policies are disabled for private endpoints. This means NSGs and UDRs applied to the subnet have no effect on traffic entering and leaving the private endpoint NIC, unless the administrator explicitly enables the PrivateEndpointNetworkPolicies property on the subnet.
This behavior is counterintuitive because NSGs applied to subnets normally affect all resources. The original private endpoint design disabled this behavior to simplify deployment. Starting with newer versions of the Azure API, it's possible to enable PrivateEndpointNetworkPolicies to regain control via NSG and UDR. Therefore, assuming policies are automatically applied represents a security planning error with real consequences.
Answer Key — Question 4
Answer: B
The problem is in the DNS resolution chain. The custom server in the hub forwards to 168.63.129.16 (Azure DNS), which can only resolve using private DNS zones if the VNet where it's queried is linked to the corresponding private zone.
Since Azure DNS is queried from the context of the hub VNet (where the custom DNS server resides), the private zone needs to be linked to the hub. Without this association, Azure DNS doesn't find the private record and responds with NXDOMAIN or the public IP.
Option A creates a fragile manual workaround unrelated to the forwarding problem. Option C eliminates the centralized architecture, which is a hub-and-spoke design requirement. Option D (DNS Proxy in Firewall) may be a valid complementary architectural solution, but doesn't resolve the root problem identified: the private zone simply isn't linked to the VNet serving as the Azure DNS query point.
Answer Key — Question 5
Answer: B
For services with multiple sub-resources, such as a storage account, each sub-resource (blob, file, queue, table) is treated as a distinct target sub-resource when creating the private endpoint. This means each sub-resource requires its own private endpoint, with its own private IP, and its own private DNS zone (privatelink.blob.core.windows.net, privatelink.file.core.windows.net, etc.).
The conceptual error in option A is imagining that a single endpoint covers all sub-resources. The error in option C is correct regarding DNS but wrong in claiming a single endpoint covers all sub-resources. The error in option D is confusing the private endpoint model with the service endpoint or proxy model, where port differentiation would make sense. In private endpoints, each sub-resource has a dedicated private IP and its own FQDN mapped via private DNS zone.