Azure Private Endpoint Questions Explained

Private endpoint questions appear regularly on the AZ-104 exam. The exam tests the difference between private endpoints and service endpoints, when to use each, and what configuration is required for private endpoints to work correctly.

What a Private Endpoint Is

A private endpoint creates a private IP address inside your VNet that maps to a specific Azure PaaS service (like a storage account, SQL database, or Key Vault). Traffic from your VNet to that service goes through your VNet's private IP — it never leaves the Microsoft backbone and never goes over the public internet.

Why Use a Private Endpoint

By default, Azure PaaS services have public endpoints — they are accessible over the internet (with authentication). Some security requirements prohibit any data traffic traversing the public internet. Private endpoints satisfy:

• Regulatory compliance requirements (PCI DSS, HIPAA)
• Preventing data exfiltration (a compromised VM can only reach the approved private endpoint, not arbitrary public endpoints)
• Connecting to Azure services from on-premises without routing through the internet (via ExpressRoute or VPN)

Private Endpoint vs Service Endpoint

These two are frequently confused on the exam:

Exam trap: service endpoints improve routing and can restrict access to specific VNets, but the service still has a public IP. Private endpoints give the service a private IP in your VNet. For on-premises access or the strictest network isolation, private endpoints are required.

The DNS Requirement

This is the most common exam topic about private endpoints — they require DNS configuration to work correctly.

When you create a private endpoint for a storage account, the storage account's public DNS name (e.g., mystorageaccount.blob.core.windows.net) must resolve to the private IP of the endpoint, not the public IP.

Without correct DNS, applications that try to connect to the storage account will resolve the public IP and their traffic will not go through the private endpoint.

The recommended solution: create an Azure Private DNS Zone (e.g., privatelink.blob.core.windows.net) and link it to the VNet. The private endpoint registration creates an A record in this zone mapping the storage account name to the private IP.

Exam scenario: "A private endpoint was created for a storage account, but VMs in the VNet are still connecting over the public internet. What is missing?"

The Private DNS Zone is not configured, or the VNet is not linked to it. Without DNS resolution returning the private IP, traffic defaults to the public endpoint.

Disabling the Public Endpoint

After creating a private endpoint, you can optionally disable the public endpoint on the PaaS resource. This ensures all traffic must come through the private endpoint and the resource is unreachable from the public internet entirely.

For storage accounts: Storage Account → Networking → Public network access → Disable.

When to Choose Private Endpoint on the Exam

• The question requires access from on-premises systems (via VPN or ExpressRoute) — private endpoint is the only option that works
• The question requires the resource to have a private IP in the VNet — private endpoint
• The question requires preventing any public internet traffic — disable the public endpoint after creating a private endpoint
• The question just needs to restrict access to a specific VNet and cost is a concern — service endpoint may be sufficient

Practice AZ-104 networking questions to build confidence with private endpoint scenarios.

Private Endpoint vs Service Endpoint — The Key Differences

The exam frequently offers both as answer choices and tests whether you know the specific capabilities of each:

The critical exam differentiator: on-premises access. Service endpoints only work from within the Azure VNet. A client connecting from on-premises via ExpressRoute or VPN cannot use a service endpoint to reach Azure Storage privately — the traffic still goes to the public endpoint. Private endpoints work from on-premises because the private IP is routable over VPN/ExpressRoute.

Exam pattern: "An on-premises application connected via ExpressRoute needs to access Azure Storage without traffic traversing the public internet." → Private endpoint. A service endpoint won't work for on-premises access.

Private DNS Zone — The Critical Configuration

Creating a private endpoint is only half the work. Without correct DNS configuration, clients will resolve the storage account's public DNS name to its public IP, even though the private endpoint exists.

The correct DNS flow:

1. Create a Private DNS Zone with the right name — for Blob Storage: privatelink.blob.core.windows.net
2. Link the private DNS zone to the VNet — this tells the VNet's DNS resolver to use this zone for matching queries
3. The private endpoint registration automatically creates an A record in the zone pointing to the private endpoint's NIC IP (e.g., 10.1.0.5)

When a VM in the VNet queries mystorageaccount.blob.core.windows.net:

• Azure public DNS returns a CNAME to mystorageaccount.privatelink.blob.core.windows.net
• The private DNS zone resolves this CNAME to the private endpoint IP
• Traffic goes to the private IP (inside the VNet), never to the public internet

Without the private DNS zone link, the same query resolves to the public IP. The private endpoint exists but isn't used.

Exam pattern: "A private endpoint is created for a storage account, but VMs in the VNet are still reaching the storage account via its public IP. What is missing?" → The private DNS zone is not linked to the VNet (or the A record wasn't created).

The On-Premises DNS Resolution Problem

This is an advanced scenario that appears in more difficult exam questions.

On-premises DNS servers don't know about Azure's private DNS zones — those zones only exist inside Azure DNS. When an on-premises client queries mystorageaccount.blob.core.windows.net, the on-premises DNS server resolves it through public DNS, returning the public IP.

The solution: configure a conditional forwarder on the on-premises DNS server that forwards queries for privatelink.blob.core.windows.net to the Azure DNS resolver at 168.63.129.16 (Azure's magic DNS IP, reachable over the VPN/ExpressRoute connection).

The flow becomes:

1. On-premises client queries on-premises DNS
2. On-premises DNS sees the privatelink.blob.core.windows.net suffix and forwards to 168.63.129.16
3. Azure DNS resolver checks the private DNS zone and returns the private endpoint IP
4. On-premises client connects to the private IP over the VPN tunnel

This requires the VPN or ExpressRoute to be configured and 168.63.129.16 to be reachable from on-premises (it always is, over any Azure VPN tunnel).

Exam pattern: "An on-premises server needs to resolve private endpoints in Azure. A private DNS zone is correctly configured in Azure. What must be configured on-premises?" → Conditional DNS forwarder for the privatelink zone pointing to 168.63.129.16.

Private Endpoint for Your Own Service — Azure Private Link

Private Link is the technology behind private endpoints. When you connect to a Microsoft service (Storage, Key Vault, SQL), Microsoft has already set up the Private Link service on their side. But you can also create a Private Link service to expose your own service privately to other VNets or tenants.

Architecture:

• Your service runs behind a Standard Load Balancer (Basic doesn't support Private Link)
• You create a Private Link service attached to the load balancer's frontend
• Consumers create a private endpoint that connects to your Private Link service
• Microsoft creates a cross-VNet connection that doesn't require peering or overlapping IP management

Use cases: SaaS providers exposing their service to enterprise customers privately; large enterprises exposing shared services from a central subscription to spoke subscriptions without VNet peering complexity.

Exam pattern: "A company wants to expose an internal API (running behind an Azure Load Balancer) to a partner company's Azure VNet without VNet peering." → Create a Private Link service; the partner creates a private endpoint connecting to it.

Network Policy for Private Endpoints

By default, private endpoint NICs are exempt from NSG rules and route tables on the subnet they're deployed in. An NSG on the subnet does not apply to traffic destined for the private endpoint.

To apply NSGs to private endpoint traffic, you must enable "Network policies for private endpoints" on the subnet:

az network vnet subnet update \
  --name mySubnet \
  --vnet-name myVNet \
  --resource-group myRG \
  --private-endpoint-network-policies Enabled

After enabling this, NSG rules and route tables apply to traffic hitting the private endpoint NIC, just like any other NIC in the subnet.

This setting is disabled by default because enabling it changes routing behavior and can break connectivity if NSG rules aren't updated to permit the traffic.

Exam pattern: "A security team requires that NSG rules control all traffic to private endpoints in a subnet. Private endpoints are deployed but NSG rules are not being applied. What must be configured?" → Enable network policies for private endpoints on the subnet.

Exam Scenario Pattern — 'Data Must Never Traverse Public Internet'

This phrase in an exam question almost always points to private endpoint as the answer. Here's why service endpoints are the wrong answer for this pattern:

Service endpoints optimize routing — traffic from a VNet to Azure Storage leaves the VNet at the subnet level and routes over the Azure backbone to the storage service's public endpoint. The traffic doesn't go over the public internet (it uses Microsoft's private backbone), but it does reach the storage account's public IP address. If the storage firewall is configured to allow the VNet subnet, the traffic is accepted. But the destination IP is public.

Private endpoints create a private IP within the VNet. DNS resolves to this private IP. Traffic never leaves the VNet to reach a public IP. This is the genuine "never traverse public internet" answer.

The exam's wrong answer for this pattern: "Configure a service endpoint on the VNet subnet." This is a valid security improvement but doesn't eliminate public IP routing. The right answer is private endpoint.

Practice Question Sets