This chapter covers Azure Private Endpoints and the critical role of DNS resolution in ensuring private connectivity to Azure PaaS services. For the AZ-500 exam, this topic appears in approximately 15-20% of questions under domain 'Network Security' (objective 3.3). Mastering private endpoints and their DNS configuration is essential because misconfigurations are a common source of security breaches and exam traps. You'll learn the internal mechanics, configuration steps, and how to troubleshoot DNS resolution for private endpoints.
Jump to a section
Imagine a large office building (your Azure virtual network) where each department has its own internal phone extension (private IP). Across town, there's a cloud service provider's data center (PaaS service like Azure Storage) that offers services to many customers. Normally, to call that provider, you must dial through the public telephone network (public internet), which is insecure and slower. A private endpoint is like installing a direct, dedicated phone line from your building's private switchboard directly to that provider's private switchboard, bypassing the public network entirely. This dedicated line uses a private circuit (Azure backbone) and each call gets a private extension (network interface with a private IP) in your building's phone directory (Azure Private DNS Zone). When you want to access the service, you dial the extension (private IP) instead of the public number. The call never touches the public telephone network. DNS resolution is like the company's internal phone book: it maps the service name (e.g., mystorageaccount.blob.core.windows.net) to the private extension (10.0.1.5) instead of the public number. If the phone book is not updated correctly, calls go to the public number instead, defeating the purpose. The private endpoint is the physical line; the private DNS zone is the phone book entry.
What is a Private Endpoint?
A private endpoint is a network interface that connects you privately and securely to a service powered by Azure Private Link. It uses a private IP address from your virtual network, effectively bringing the service into your VNet. The service can be an Azure PaaS service (e.g., Storage Account, SQL Database, Azure Cosmos DB) or a service hosted by a partner (via Private Link Service).
Private endpoints are deployed at the subnet level. You create a private endpoint resource in a resource group, specifying the target service (e.g., a storage account) and the subnet where the private endpoint's network interface (NIC) will be placed. The NIC gets a private IP from the subnet's address range. This NIC is the entry point for all traffic from your VNet to the service.
Why Private Endpoints Exist: Security and Compliance
Traditionally, accessing Azure PaaS services requires going over the public internet, even if you use a service endpoint (which still routes traffic over the Microsoft backbone but uses public IPs). Private endpoints eliminate exposure to the public internet entirely. Traffic stays within the Microsoft Azure backbone network, never traversing the internet. This is critical for compliance with regulations like HIPAA, PCI-DSS, and GDPR, which require data to remain within a controlled boundary.
How Private Endpoints Work: The Mechanism
When you create a private endpoint for a storage account, Azure provisions a private IP address for that storage account in your VNet. The storage account's public endpoint remains, but you can disable public access to force all traffic through private endpoints. The private endpoint uses a technology called Azure Private Link, which establishes a network connection between the VNet and the service over the Microsoft backbone.
Here's the step-by-step flow: 1. A VM in your VNet resolves the FQDN of the storage account (e.g., mystorageaccount.blob.core.windows.net). 2. If DNS is configured correctly, the FQDN resolves to the private IP address of the private endpoint (e.g., 10.0.1.5). 3. The VM sends traffic to 10.0.1.5:443 (HTTPS). 4. The packet arrives at the private endpoint NIC, which forwards it via Azure Private Link to the storage account's private endpoint resource. 5. The storage account sees the traffic as coming from the private IP, not a public IP. 6. The response follows the reverse path.
All traffic is encrypted with TLS, but the underlying network path is private.
Key Components and Defaults
Private Endpoint Resource: A top-level resource in Azure. It includes the target sub-resource (e.g., blob, file, table, queue for a storage account).
Network Interface (NIC): Created automatically within the private endpoint's subnet. It has a private IP and is associated with the private endpoint.
Private DNS Zone: A DNS zone that maps the FQDN of the service to the private IP. For Azure services, Microsoft provides a set of private DNS zone names (e.g., privatelink.blob.core.windows.net).
Private Link Service: The service side of Private Link. For customer-owned services, you create a Private Link Service behind a Standard Load Balancer.
Default behavior: When you create a private endpoint, Azure automatically creates a private DNS zone (if you choose 'Integrate with private DNS zone') and links it to your VNet. The zone contains an A record mapping the FQDN to the private IP. If you do not integrate, you must manually manage DNS.
DNS Resolution: The Critical Component
DNS resolution is where most misconfigurations occur. The goal is to resolve the public FQDN of the service to the private IP address when the client is within the VNet (or a connected network). This is achieved using Azure Private DNS Zones or custom DNS servers.
Azure Private DNS Zone:
For each Azure service, there is a specific private DNS zone name. For example:
- Blob storage: privatelink.blob.core.windows.net
- SQL Database: privatelink.database.windows.net
- Cosmos DB: privatelink.documents.azure.com
- These zones are not publicly resolvable. They are only resolvable from within VNets that are linked to the zone.
- When you create a private endpoint and choose to integrate with a private DNS zone, Azure creates the zone (if it doesn't exist) and adds an A record for the FQDN.
- The zone is linked to the VNet with 'auto registration' disabled (since it's not a custom domain).
DNS resolution flow with Azure Private DNS Zone:
1. Client VM queries DNS server (Azure-provided DNS at 168.63.129.16).
2. The Azure DNS server checks the VNet's linked private DNS zones.
3. If there is a matching zone (e.g., privatelink.blob.core.windows.net) and an A record for the FQDN, it returns the private IP.
4. Otherwise, it forwards the query to the public internet DNS to resolve the public IP.
Custom DNS servers: If you use custom DNS servers (e.g., on-premises AD), you must configure conditional forwarding to Azure's private DNS zones. The custom DNS server must forward queries for privatelink.blob.core.windows.net to the Azure DNS (168.63.129.16) or to an Azure DNS Private Resolver (which is a newer service).
Configuration Steps
Create a Private Endpoint (Azure Portal) 1. Navigate to the service (e.g., Storage Account) -> Networking -> Private Endpoint Connections -> + Private Endpoint. 2. Select the subscription, resource group, name, and region (must be same region as VNet). 3. Select the target sub-resource (e.g., blob). 4. Select the virtual network and subnet. 5. For DNS, choose 'Integrate with private DNS zone'. Select the zone or let Azure create one. 6. Review and create.
Verification
- Check the private endpoint's NIC: It should have a private IP from the subnet.
- Check the private DNS zone: It should have an A record for the FQDN (e.g., mystorageaccount.blob.core.windows.net -> 10.0.1.5).
- From a VM in the VNet, run nslookup mystorageaccount.blob.core.windows.net. It should return the private IP.
- Attempt to access the storage account via the FQDN (e.g., using Azure Storage Explorer). It should work.
- Disable public network access on the storage account to enforce private-only access.
Interaction with Related Technologies
Service Endpoints: Service endpoints also provide private access but do not give a private IP; they route traffic over the backbone but the destination still has a public IP. Private endpoints are more secure because they remove public exposure entirely.
Azure Firewall: You can use Azure Firewall to inspect traffic to private endpoints, but it's optional. Private endpoints bypass the firewall by default (traffic goes directly via Private Link). To force inspection, you need to use route tables or Azure Firewall with forced tunneling.
Network Security Groups (NSGs): Private endpoints do not support NSGs on the subnet where they are deployed. Traffic to the private endpoint is controlled by the service-side firewall (e.g., Storage Account firewall). However, you can apply NSGs to the subnet for other traffic.
Azure VPN Gateway / ExpressRoute: Private endpoints work seamlessly with on-premises networks connected via VPN or ExpressRoute, provided DNS resolution is configured correctly. On-premises clients need to resolve the FQDN to the private IP, which requires conditional forwarding to Azure DNS.
Performance and Scale
Each private endpoint supports up to 10,000 connections per minute. The maximum number of private endpoints per VNet is 1000 (soft limit). Each private endpoint can handle up to 10 Gbps throughput. For high-throughput scenarios, you can create multiple private endpoints for the same service (e.g., one per storage account sub-resource).
Monitoring and Logging
Azure Monitor: You can monitor private endpoint metrics like bytes in/out, packets in/out, and active connections.
NSG Flow Logs: Traffic to private endpoints is captured in NSG flow logs if an NSG is applied to the subnet (though NSGs on the private endpoint subnet only affect inbound traffic to the subnet, not to the private endpoint itself).
Diagnostic Logs: Private endpoints emit logs for connection attempts (success/failure). Enable diagnostic settings on the private endpoint resource.
Common Pitfalls
DNS not resolving to private IP: Most common issue. Ensure the private DNS zone is linked to the VNet and the A record exists. Check that the client is using the correct DNS server.
Public access still enabled: Even with a private endpoint, the service's public endpoint remains accessible by default. You must disable public network access to enforce private-only connectivity.
Cross-region private endpoints: Private endpoints must be in the same region as the VNet. The target service can be in a different region (e.g., storage account in East US, VNet in West US), but the private endpoint is created in the VNet's region.
Using FQDN with port: Some applications use the FQDN with a specific port (e.g., for SQL, port 1433). DNS resolution works the same; the private IP is returned, and traffic goes to the private endpoint.
Exam Tips
Remember the private DNS zone names for key services: privatelink.blob.core.windows.net, privatelink.database.windows.net, privatelink.documents.azure.com, privatelink.vaultcore.azure.net (for Key Vault).
Know that private endpoints use a NIC with a private IP from the subnet.
Understand that disabling public access is a separate step after creating the private endpoint.
Be aware that NSGs cannot be applied directly to the private endpoint NIC; they apply to the subnet but do not affect private endpoint traffic.
Know that private endpoints support TCP traffic only (no UDP).
The exam often tests DNS resolution: if a client cannot resolve the FQDN to the private IP, the connection will fail or go over the internet.
Provision the Private Endpoint Resource
In the Azure portal or via CLI/ARM, create a private endpoint resource. Specify the target service (e.g., storage account) and the sub-resource (e.g., blob). Choose the virtual network and subnet where the private endpoint will be placed. Azure creates a network interface (NIC) in that subnet with a private IP from the subnet's range. This NIC is the entry point for all traffic to the service from within the VNet. The private endpoint resource also establishes a connection with the target service's Private Link endpoint. The provisioning typically takes a few seconds to a minute.
Configure DNS Integration
During creation, you can choose to integrate with a private DNS zone. If selected, Azure automatically creates (or uses an existing) private DNS zone for the service (e.g., `privatelink.blob.core.windows.net`) and adds an A record mapping the FQDN (e.g., `mystorageaccount.blob.core.windows.net`) to the private IP. The zone is linked to the VNet. This step is critical for seamless DNS resolution. If you skip integration, you must manually create the private DNS zone, add the A record, and link it to the VNet. Azure DNS (168.63.129.16) is used for resolution within the VNet.
Verify DNS Resolution from a Client VM
Deploy a test VM in the same VNet (or a peered VNet). From the VM, run `nslookup <service-fqdn>` (e.g., `nslookup mystorageaccount.blob.core.windows.net`). The response should show the private IP address (e.g., 10.0.1.5) and indicate that the answer is authoritative. If it returns a public IP (e.g., 40.xxx.xxx.xxx), DNS resolution is not working correctly. Check that the private DNS zone is linked to the VNet and that the A record exists. Also ensure the VM is using Azure-provided DNS (168.63.129.16) or a custom DNS that forwards to Azure.
Disable Public Network Access on the Service
After confirming private connectivity, disable public network access on the target service. For a storage account, go to Networking -> Firewalls and virtual networks, set 'Public network access' to 'Disabled'. This ensures that only traffic from private endpoints (or trusted Azure services) can access the storage account. Without this step, the public endpoint remains accessible, defeating the security purpose. Note that disabling public access also blocks access from Azure services that do not use private endpoints, so you may need to allow specific Azure services (e.g., Azure Backup) via the 'Exceptions' blade.
Test End-to-End Connectivity
From the client VM, attempt to access the service using its FQDN. For storage, you can use Azure Storage Explorer or a simple PowerShell command: `Invoke-RestMethod -Uri https://mystorageaccount.blob.core.windows.net/`. The request should succeed. Also test from on-premises if connected via VPN/ExpressRoute. On-premises clients must have DNS configured to resolve the FQDN to the private IP. This often requires conditional forwarding on the on-premises DNS server to forward queries for `privatelink.blob.core.windows.net` to Azure DNS (168.63.129.16) or to an Azure DNS Private Resolver. Finally, verify that public access is blocked by attempting to access the service via its public endpoint from a machine outside the VNet (should fail).
Enterprise Scenario 1: Securing Azure SQL Database for a Financial Application
A financial services company hosts a critical application on Azure VMs that connects to an Azure SQL Database. Compliance requires that all database traffic remain within the Azure backbone and never traverse the internet. The company deploys a private endpoint for the SQL Database in the same VNet as the application VMs. They integrate with the private DNS zone privatelink.database.windows.net, creating an A record for the SQL server FQDN (e.g., sqlserver.database.windows.net -> 10.0.0.4). They then disable public network access on the SQL server. The application connection string uses the FQDN, and DNS resolves to the private IP. Performance is excellent, with latency under 1ms. The company uses Azure Monitor to track metrics like bytes in/out and active connections. A common issue they encountered was that after disabling public access, Azure Backup (which uses public endpoints) could no longer back up the database. They resolved this by allowing trusted Azure services in the SQL firewall exceptions.
Enterprise Scenario 2: Hybrid Access to Azure Storage from On-Premises
A retail company has an on-premises data center connected to Azure via ExpressRoute. They have an Azure Storage account used for backup data. They want on-premises backup servers to access storage privately. They create a private endpoint for blob storage in a VNet in Azure, and configure a private DNS zone privatelink.blob.core.windows.net. On-premises, they have an Active Directory DNS server. They configure a conditional forwarder: queries for privatelink.blob.core.windows.net are forwarded to Azure DNS (168.63.129.16) via the ExpressRoute. The on-premises backup servers resolve the storage account FQDN to the private IP (10.1.0.5). Traffic flows over ExpressRoute to the VNet, then via Private Link to the storage account. They notice that if the conditional forwarder is misconfigured, the backup jobs fail with timeout errors because traffic goes over the internet. They also ensure that the storage account's firewall allows traffic from the private endpoint's subnet (which is automatic). They monitor using Azure Storage logs and set up alerts for failed connections.
Enterprise Scenario 3: Multi-Tier Application with Multiple Private Endpoints
A SaaS provider hosts a multi-tier application on Azure: web tier in a public subnet, app tier in a private subnet, and a database tier using Azure Cosmos DB. They want all inter-tier communication to use private endpoints. They create private endpoints for Cosmos DB and for the app tier's internal API (using a Private Link Service). Each private endpoint is in the respective subnet. DNS integration is critical: they use a single private DNS zone for each service (e.g., privatelink.documents.azure.com) and link it to all VNets in the hub-spoke topology. They use Azure Firewall to inspect traffic between tiers, but they learn that private endpoint traffic bypasses the firewall by default. To force inspection, they use user-defined routes (UDRs) to send traffic to the firewall. They also set up diagnostic logs for each private endpoint to audit connections. A common mistake they made initially was creating private endpoints in the same region as the service, but the VNet was in a different region (not allowed). They now ensure both are in the same region.
AZ-500 Exam Focus: Private Endpoints and DNS Resolution
This topic is tested under objective '3.3 Implement network security' and specifically within 'Implement Azure Private Link and private endpoints'. Expect 2-3 questions on the exam, often scenario-based, asking you to choose the correct configuration to secure access to a PaaS service.
Common Wrong Answers and Why Candidates Choose Them: 1. 'Use a service endpoint instead of a private endpoint': Candidates often confuse service endpoints with private endpoints. Service endpoints do not provide a private IP and do not remove public exposure. The exam expects you to know that private endpoints are more secure because they use a private IP and can disable public access. 2. 'Private endpoints automatically disable public access': This is false. After creating a private endpoint, you must manually disable public network access on the service. Many candidates assume it's automatic. 3. 'DNS resolution is not needed if you use the private IP directly': While you can use the private IP, Azure services are accessed via FQDN. The exam stresses that DNS must resolve to the private IP. Using the IP directly may not work for all services (e.g., storage accounts require the FQDN for authentication). 4. 'You can apply NSGs to the private endpoint NIC': NSGs are not supported on private endpoint NICs. Candidates may think they can filter traffic at the private endpoint level, but NSGs on the subnet do not affect private endpoint traffic.
Specific Numbers and Terms on the Exam:
- Private DNS zone names: privatelink.blob.core.windows.net, privatelink.database.windows.net, privatelink.vaultcore.azure.net (for Key Vault).
- The default Azure DNS IP: 168.63.129.16.
- Private endpoints support TCP only.
- Maximum private endpoints per VNet: 1000 (soft limit).
- Private endpoint NIC gets an IP from the subnet range.
Edge Cases and Exceptions: - Cross-region: Private endpoint must be in the same region as the VNet, but the target service can be in any region. - Multiple private endpoints for the same service: You can create multiple private endpoints for the same service in different VNets. Each gets a different private IP. - Private endpoints and Azure PaaS services with multiple sub-resources: For storage accounts, you can create separate private endpoints for blob, file, table, and queue. DNS zones are specific to each sub-resource. - Private endpoints and Azure DNS Private Resolver: For hybrid DNS resolution, you may use Azure DNS Private Resolver instead of conditional forwarding. The exam may ask about this newer feature.
How to Eliminate Wrong Answers: - If a question asks for the most secure way to connect to a PaaS service, look for 'private endpoint' plus 'disable public access'. - If a question mentions DNS not resolving, check if the private DNS zone is linked to the VNet. - If a question involves on-premises connectivity, ensure DNS conditional forwarding is configured. - If a question mentions NSGs, remember that private endpoints do not support NSGs.
Exam Tip: Always read the scenario carefully. If the requirement is to 'remove exposure to the public internet', the answer must include disabling public network access on the service, not just creating a private endpoint.
Private endpoints use a NIC with a private IP from the VNet subnet.
DNS resolution must map the service FQDN to the private IP using a private DNS zone.
Private DNS zone names: `privatelink.blob.core.windows.net`, `privatelink.database.windows.net`, `privatelink.vaultcore.azure.net`.
After creating a private endpoint, disable public network access on the service to enforce private-only connectivity.
NSGs do not apply to private endpoint traffic; use service-side firewalls.
Private endpoints support TCP only.
Private endpoints must be in the same region as the VNet; target service can be in any region.
Maximum 1000 private endpoints per VNet (soft limit).
For on-premises connectivity, configure DNS conditional forwarding to Azure DNS (168.63.129.16).
Azure DNS Private Resolver can be used for hybrid DNS without conditional forwarding.
These come up on the exam all the time. Here's how to tell them apart.
Private Endpoint
Provides a private IP address in the VNet for the service.
Removes public exposure; can disable public access.
Traffic stays within Microsoft backbone, never internet.
Supports only TCP traffic.
More granular: can target specific sub-resources (e.g., blob vs. table).
Service Endpoint
Does not provide a private IP; uses public IP of the service.
Traffic goes over Microsoft backbone but still uses public endpoint.
Cannot disable public access; service remains publicly reachable.
Supports TCP and UDP traffic.
Less granular: applies to the entire service (e.g., all storage accounts in the VNet).
Mistake
Private endpoints automatically disable public access to the service.
Correct
Creating a private endpoint does not disable the service's public endpoint. You must manually disable public network access in the service's networking settings. Until then, the service remains accessible via its public IP.
Mistake
You can apply an NSG to the private endpoint's subnet to filter traffic to the private endpoint.
Correct
NSGs applied to the subnet do not affect traffic destined to the private endpoint. The private endpoint NIC bypasses NSG rules. Traffic filtering must be done at the service side (e.g., storage account firewall) or using a network virtual appliance with UDRs.
Mistake
Private endpoints work with any protocol (TCP, UDP, ICMP).
Correct
Private endpoints support only TCP traffic. UDP and ICMP are not supported. For example, DNS queries over UDP to a private endpoint will fail.
Mistake
You must use the private IP address to access the service instead of the FQDN.
Correct
Azure services require the FQDN for proper authentication and functionality. The FQDN must resolve to the private IP via DNS. Using the private IP directly may cause certificate errors or authentication failures.
Mistake
Private endpoints require a VPN or ExpressRoute to work.
Correct
Private endpoints work within Azure VNets without any VPN or ExpressRoute. They are used for intra-Azure connectivity. For on-premises access, you need VPN/ExpressRoute to connect to the VNet, but the private endpoint itself does not require it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The most common cause is DNS resolution not returning the private IP. Check that the private DNS zone is linked to the VNet and contains an A record for the FQDN. Also ensure the client VM is using the Azure DNS (168.63.129.16) or a custom DNS that forwards queries for the private DNS zone to Azure DNS. Another cause is that public network access is still enabled; you must disable it to force traffic through the private endpoint.
The private endpoint must be deployed in the same region as the virtual network. However, the target service (e.g., storage account) can be in any region. For example, you can have a VNet in West US and a storage account in East US, and create a private endpoint in West US for that storage account.
You need a site-to-site VPN or ExpressRoute to connect your on-premises network to the Azure VNet where the private endpoint is deployed. Then, configure DNS on your on-premises DNS servers to conditionally forward queries for the private DNS zone (e.g., `privatelink.blob.core.windows.net`) to Azure DNS (168.63.129.16) or to an Azure DNS Private Resolver. This ensures on-premises clients resolve the FQDN to the private IP.
Azure Private Link is the underlying service that enables private connectivity. A Private Endpoint is the resource you create in your VNet to connect to a service via Private Link. Think of Private Link as the technology, and Private Endpoint as the specific connection point.
NSGs can be applied to the subnet where the private endpoint is deployed, but they do not affect traffic destined to the private endpoint. The private endpoint NIC bypasses NSG rules. To filter traffic, use the service's firewall (e.g., storage account firewall) or deploy a network virtual appliance with user-defined routes.
If you delete the private DNS zone, DNS resolution for the service FQDN will fall back to the public IP, unless you have a custom DNS setup. Traffic will no longer go through the private endpoint. To restore, you must recreate the zone, add the A record, and link it to the VNet.
The default soft limit is 1000 private endpoints per VNet. You can request an increase by opening a support ticket.
You've just covered Private Endpoints and DNS Resolution — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?