This chapter covers Azure Private Link, a critical network security feature that enables private connectivity to Azure PaaS services and your own services from your virtual network. For the AZ-500 exam, Private Link is a high-yield topic under objective 3.3 (Implement network security), appearing in approximately 10-15% of questions. Understanding its architecture, endpoint types, DNS configuration, and security implications is essential for passing the exam. This chapter provides a deep dive into the mechanism, configuration, and exam-focused details you need.
Jump to a section
Think of Azure Private Link as a private, dedicated tunnel that connects two buildings (your virtual network and a PaaS service) without going through the public street. Normally, if you want to access a store in a mall (like Azure SQL Database), you have to walk on public sidewalks (the internet), and your path is visible to everyone. With Private Link, you build a private tunnel from your building's basement directly into the store's back room. The store assigns a special private entrance (a private endpoint) that only your building can use. The tunnel is not a physical cable but a virtual connection that uses the mall's internal service network (Azure backbone). When you send a request, it enters the tunnel at your building's private endpoint, travels through the mall's internal corridors (Microsoft network), and exits directly into the store. The store never sees the public street; it only sees the private entrance. This means no traffic ever traverses the public internet, reducing exposure to attacks. The private endpoint gets a private IP from your VNet, making the service appear as if it's inside your network. The tunnel is managed by Azure, so you don't need to configure VPNs or ExpressRoute. The key is that the service (e.g., SQL Database) must be configured to accept traffic from the private endpoint, and you must disable public access to ensure no one else can use the public entrance.
What is Azure Private Link and Why It Exists
Azure Private Link allows you to access Azure PaaS services (like Azure SQL Database, Storage, Key Vault, etc.) and your own services hosted on Azure (via Private Link Service) over a private endpoint in your virtual network. The primary driver is security: before Private Link, accessing PaaS services required traffic to traverse the public internet, even if you used service endpoints (which still route through the Azure backbone but use public IPs). Private Link eliminates public internet exposure entirely by making the service appear as a resource inside your VNet with a private IP.
How It Works Internally
When you create a private endpoint, Azure deploys a network interface (NIC) in the subnet of your VNet. This NIC gets a private IP from the subnet. The private endpoint is connected to the PaaS service via a connection request. The service owner (e.g., Azure SQL) must approve the connection. Once approved, traffic from your VNet to the service is routed through the private endpoint. Here's the packet-level flow:
A VM in your VNet sends a DNS query for the SQL server name (e.g., myserver.database.windows.net).
With Private Link, the DNS resolution returns the private IP of the private endpoint (e.g., 10.0.1.5) instead of the public IP. This is achieved by using a private DNS zone linked to your VNet.
The VM sends traffic to 10.0.1.5. The private endpoint captures this traffic and tunnels it over the Azure backbone to the PaaS service.
The PaaS service sees the traffic as coming from the private endpoint's private IP, not the VM's IP. This is because the private endpoint performs source NAT (SNAT) to its own private IP.
The response flows back through the same tunnel.
Key Components, Values, and Defaults
Private Endpoint: A network interface with a private IP from your VNet. You can create one for each PaaS resource you want to connect privately.
Private Link Service: A service you create on top of a Standard Load Balancer to expose your own service to consumers via private endpoints. The consumer creates a private endpoint in their VNet and connects to your Private Link Service.
Private DNS Zone: Required for DNS resolution to return the private IP. For Azure services, you use zones like privatelink.database.windows.net. You must link this zone to your VNet.
Connection Approval: The service owner must approve the private endpoint connection. There are three states: Pending, Approved, Rejected. If the service owner disables public access, only approved private endpoints can connect.
Network Policies: By default, private endpoints do not support network security groups (NSGs) or route tables on the subnet. However, you can enable privateEndpointNetworkPolicies on the subnet to allow NSG and UDR support (though this is limited).
Data Exfiltration Protection: You can use Azure Policy to deny creation of private endpoints with certain approvals or to require specific DNS zones.
Configuration and Verification Commands
To create a private endpoint for Azure SQL Database using Azure CLI:
az network private-endpoint create \
--name myPrivateEndpoint \
--resource-group myRG \
--vnet-name myVNet \
--subnet mySubnet \
--private-connection-resource-id /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Sql/servers/myserver \
--group-id sqlServer \
--connection-name myConnectionTo approve the connection (from the service side):
az network private-endpoint-connection approve \
--id /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Sql/servers/myserver/privateEndpointConnections/{connectionId} \
--description "Approved"To verify DNS resolution:
nslookup myserver.database.windows.netShould return the private IP.
Interaction with Related Technologies
Service Endpoints vs Private Link: Service endpoints provide a direct, private connection to PaaS services using the Azure backbone, but the service still has a public IP. Private Link gives a private IP in your VNet. Private Link is more secure but has higher cost and complexity.
VPN Gateway / ExpressRoute: Private Link works independently of VPN or ExpressRoute. You can use Private Link within a VNet that is connected to on-premises via VPN/ER, allowing on-premises resources to access PaaS services privately via the private endpoint.
Azure Firewall: You can route traffic from on-premises through Azure Firewall and then to Private Link. However, be aware that Private Link does not support forced tunneling (default route 0.0.0.0/0) because the private endpoint requires direct connectivity to the Azure backbone.
Network Security Groups (NSGs): By default, NSGs are not supported on subnets with private endpoints. However, you can enable network policies to apply NSGs, but the NSG will only apply to traffic from resources in the VNet to the private endpoint, not to the private endpoint itself (the private endpoint's NIC is not in the subnet's traffic path for inbound traffic).
Security Considerations
Data Exfiltration: The primary risk is that a compromised resource in your VNet could create a private endpoint to an external service (e.g., a malicious Azure Storage account) and exfiltrate data. To prevent this, use Azure Policy to restrict private endpoint creation to approved services or require specific DNS zones.
Public Access: Always disable public access on the PaaS resource after configuring Private Link to ensure no internet traffic can reach the service. For example, set public-network-access to Disabled for Azure SQL Database.
Connection Approval: Ensure that only authorized connections are approved. Use Azure Policy or RBAC to control who can approve connections.
Exam-Specific Details
The exam expects you to know that Private Link uses the Azure backbone network, not the public internet.
You must know the difference between Private Endpoint and Private Link Service.
DNS configuration is critical: you need a private DNS zone linked to the VNet.
Private Link supports TCP traffic only (no UDP).
The private endpoint's IP address is from the VNet's subnet, not from the service's network.
For Azure Storage, you can create private endpoints for different sub-resources: blob, file, queue, table, dfs.
Private Link is available for many Azure services: SQL Database, SQL Managed Instance, Storage, Key Vault, Azure Cosmos DB, Azure App Service, Azure Kubernetes Service (AKS), Azure Container Registry, etc.
The maximum number of private endpoints per VNet is 1000.
Private Link Service requires a Standard Load Balancer (not Basic).
The consumer's private endpoint can be in a different region than the service, but the service must be in the same region as the Private Link Service (for user-defined services). For Azure PaaS, cross-region private endpoints are not supported (the service and endpoint must be in the same region).
Common Configuration Mistakes
Forgetting to disable public access after configuring Private Link.
Not configuring private DNS zones correctly, leading to continued resolution to public IP.
Using Basic Load Balancer for Private Link Service (must be Standard).
Creating private endpoint in a subnet that has service endpoints enabled for the same service (they can coexist, but you must ensure DNS resolution points to the private endpoint).
Not approving the connection on the service side (connection stays in pending state).
Conclusion
Azure Private Link is a powerful security feature that provides private connectivity to Azure services. For the AZ-500 exam, focus on understanding the architecture, DNS configuration, security controls (public access disable, connection approval, data exfiltration prevention), and the differences between Private Endpoint and Private Link Service. Practice with CLI commands and understand the interaction with other networking components.
Create Private Endpoint Resource
In the Azure portal, navigate to 'Private endpoints' and click 'Create'. Specify the resource group, name, and region. The region must be the same as the VNet you will connect to. Then, select the target sub-resource (e.g., 'sqlServer' for Azure SQL Database). At this point, the private endpoint is created as a resource, but it is not yet connected to any service. The connection is in a 'Pending' state from the consumer side.
Configure DNS for Private Endpoint
After creating the private endpoint, you must configure DNS so that the service's FQDN resolves to the private IP. Azure can automatically create a private DNS zone (e.g., `privatelink.database.windows.net`) and link it to your VNet. If you choose to use your own DNS server, you must add an A record mapping the FQDN to the private IP. Without proper DNS, traffic will still go to the public IP, defeating the purpose of Private Link.
Approve Private Endpoint Connection
The service owner (e.g., the Azure SQL Database admin) must approve the pending connection. This can be done via the Azure portal under the service's 'Private endpoint connections' blade, or via CLI/PowerShell. The connection state changes from 'Pending' to 'Approved'. If the service owner has set 'Deny public network access', only approved private endpoints can connect. If the connection is not approved, the private endpoint remains in pending state and traffic is not routed.
Verify Connectivity from VNet
From a VM in the same VNet (or peered VNet), test connectivity to the service using its FQDN. Run `nslookup` to confirm the IP is the private endpoint's IP. Then, try connecting to the service (e.g., using SQL Server Management Studio for SQL). If successful, traffic is flowing through the private endpoint. If not, check DNS resolution, NSG rules (if enabled), and that the service is configured to allow the private endpoint connection.
Disable Public Access on Service
As a security best practice, disable public network access on the PaaS service after Private Link is configured. For Azure SQL Database, set 'Public network access' to 'Disabled'. This ensures that only traffic from private endpoints can reach the service. Even if someone discovers the public IP, they cannot connect. This step is critical for the exam: always disable public access after setting up Private Link to achieve a fully private connection.
Enterprise Deployment Scenarios
Scenario 1: Financial Services Company with Strict Compliance
A bank must ensure that all data traffic to Azure SQL Database never traverses the public internet due to regulatory requirements (e.g., PCI DSS). They deploy Private Link for their production databases. Each database server gets a private endpoint in a dedicated subnet within a hub VNet. The bank uses Azure Policy to enforce that private endpoints can only be created for approved services (by resource ID) and that public access is disabled. They also set up private DNS zones with auto-registration to ensure seamless resolution. The bank's on-premises users connect via ExpressRoute to the hub VNet and then to SQL through the private endpoint. Performance is consistent because traffic stays on the Microsoft backbone. A common misconfiguration they encountered was forgetting to disable public access on the SQL server, which left a backdoor. They now use Azure Policy to automatically disable public access when a private endpoint is created.
Scenario 2: SaaS Provider Exposing Their Service via Private Link Service
A software company runs a multi-tenant application on Azure VMs behind a Standard Load Balancer. They want to offer private connectivity to their enterprise customers. They create a Private Link Service on top of the load balancer. Each customer creates a private endpoint in their own VNet and connects to the Private Link Service. The SaaS provider approves the connections and uses network policies to restrict which customer VNets can connect. They monitor connection states and use Azure Monitor to track traffic. A challenge they faced was DNS: each customer needed to resolve the SaaS service's FQDN to their private endpoint IP. The provider created a private DNS zone for each customer and linked it to their VNet. They also had to ensure that the load balancer's health probes work correctly through the private endpoint. Misconfiguration of health probes caused traffic to be dropped.
Scenario 3: Healthcare Organization with Data Exfiltration Concerns
A hospital uses Azure Storage for medical records. They are concerned about a compromised VM exfiltrating data by creating a private endpoint to an external storage account. To mitigate this, they use Azure Policy to deny creation of private endpoints unless the target resource is in an approved list (e.g., only storage accounts in their subscription). They also enable network policies on the subnet to apply NSGs that restrict outbound traffic. However, they learned that NSGs on the subnet do not filter traffic to the private endpoint itself; they only filter traffic from other resources in the subnet to the private endpoint. To fully control egress, they route all traffic through Azure Firewall and use FQDN tags to allow only approved services. They also monitor private endpoint connections using Azure Activity Logs to detect unauthorized connection attempts.
What AZ-500 Tests on Private Link
AZ-500 objective 3.3 (Implement network security) specifically tests your ability to 'implement and manage Azure Private Link' and 'configure private endpoints and private link services'. Expect 2-3 questions directly on Private Link, plus scenario-based questions that involve Private Link as a security control.
Common Wrong Answers and Why Candidates Choose Them
'Private Link uses the public internet but encrypts traffic.' This is wrong because Private Link routes traffic over the Microsoft backbone, not the public internet. Candidates confuse it with VPN or TLS. The correct answer: traffic never traverses the internet.
'You can use NSGs on the subnet to filter traffic to the private endpoint.' This is partially true: you can enable network policies to apply NSGs, but the NSG only applies to traffic from other resources in the subnet to the private endpoint, not to the private endpoint itself. Many candidates think NSGs fully protect the endpoint. The exam likes to test this nuance.
'Private Link works across regions for all services.' This is false for Azure PaaS services (e.g., SQL, Storage) — the private endpoint must be in the same region as the service. However, for Private Link Service (your own service), the consumer's private endpoint can be in a different region from the service. Candidates often confuse the two.
'You can use Basic Load Balancer for Private Link Service.' This is wrong; only Standard Load Balancer is supported. Candidates may choose Basic because it's cheaper.
Specific Numbers, Values, and Terms on the Exam
Maximum private endpoints per VNet: 1000.
Private Link supports TCP only (no UDP).
The private DNS zone for Azure SQL Database is privatelink.database.windows.net.
Connection states: Pending, Approved, Rejected.
For Azure Storage, sub-resources: blob, file, queue, table, dfs.
Private Link Service requires a Standard Load Balancer with at least one frontend IP configuration.
Edge Cases and Exceptions
Private Link does not support forced tunneling (default route 0.0.0.0/0) because the private endpoint needs direct connectivity to the Azure backbone. If you have forced tunneling, you must create a route for the private endpoint's subnet to bypass the tunnel.
Private Link does not support network policies by default; you must explicitly enable privateEndpointNetworkPolicies on the subnet.
For Azure Key Vault, you can create private endpoints for vaults, but the firewall must be configured to allow trusted Microsoft services if you need certain scenarios.
When using Private Link with Azure App Service, you must use the sites sub-resource and ensure the App Service plan is on Premium v2 or v3.
How to Eliminate Wrong Answers
If an answer says 'public internet', eliminate it.
If an answer mentions 'Basic Load Balancer', eliminate it.
If an answer says 'UDP traffic is supported', eliminate it.
If an answer says 'NSG fully controls traffic to private endpoint', it's likely wrong unless it specifies the limitation.
If an answer says 'cross-region private endpoints are supported for Azure PaaS', eliminate it.
Focus on the core mechanism: private IP, private DNS zone, approval, and no public internet. Practice with the CLI commands and understand the difference between Private Endpoint and Private Link Service.
Private Link routes traffic over the Microsoft backbone, not the public internet.
Private Endpoint gets a private IP from your VNet subnet; DNS must resolve to this IP via private DNS zone.
Connection approval is required; states: Pending, Approved, Rejected.
Always disable public access on the PaaS service after configuring Private Link.
Private Link supports TCP only (no UDP).
Private Link Service requires a Standard Load Balancer (not Basic).
Maximum 1000 private endpoints per VNet.
Private endpoint must be in the same region as the Azure PaaS service.
NSGs are not supported by default; must enable network policies and even then limited.
Use Azure Policy to prevent data exfiltration via private endpoints.
These come up on the exam all the time. Here's how to tell them apart.
Private Endpoint
Provides a private IP from your VNet for the PaaS service.
Traffic never leaves Microsoft backbone; no public internet exposure.
Requires private DNS zone for resolution.
Supports connection approval and can disable public access.
Higher cost due to per-hour and per-GB charges.
Service Endpoint
Routes traffic over Azure backbone but service still has a public IP.
Traffic uses public IP of the service; still accessible from internet if firewall allows.
DNS resolution returns public IP; no private DNS needed.
No connection approval; public access can be restricted via firewall rules.
Free of charge; included with the service.
Mistake
Private Link encrypts traffic over the internet.
Correct
Private Link does not encrypt traffic itself; it routes traffic over the Microsoft backbone, not the public internet. Encryption (e.g., TLS) is separate and should be used for data in transit.
Mistake
You can use NSGs to fully secure the private endpoint.
Correct
By default, NSGs are not supported on subnets with private endpoints. Even if you enable network policies, NSGs only filter traffic from other resources in the subnet to the private endpoint, not traffic to the endpoint from outside the subnet. The private endpoint's NIC is not in the data path for inbound traffic from the service.
Mistake
Private Link works across regions for all Azure services.
Correct
For Azure PaaS services (SQL, Storage, etc.), the private endpoint must be in the same region as the service. Only for Private Link Service (your own service) can the consumer's private endpoint be in a different region.
Mistake
You can create a private endpoint for any Azure service without the service owner's approval.
Correct
The service owner must approve the connection. If the service owner rejects or does not approve, the connection remains in 'Pending' state and no traffic flows.
Mistake
Private Link replaces the need for VPN or ExpressRoute.
Correct
Private Link provides private connectivity to PaaS services, but it does not replace VPN/ExpressRoute for connecting on-premises networks to Azure. You can use Private Link in conjunction with VPN/ER to access PaaS services privately from on-premises.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A Private Endpoint is a network interface in your VNet that connects to an Azure PaaS service or a Private Link Service. A Private Link Service is a service you create on top of a Standard Load Balancer to expose your own application to consumers via private endpoints. In short: Private Endpoint is the consumer side, Private Link Service is the provider side.
For Azure PaaS services (e.g., SQL, Storage), the private endpoint must be in the same region as the service. However, for Private Link Service (your own service), the consumer's private endpoint can be in a different region from the service. The service and the Private Link Service must be in the same region, but consumers can connect from any region.
You need to create a private DNS zone (e.g., `privatelink.database.windows.net` for SQL) and link it to your VNet. Then add an A record mapping the service's FQDN to the private endpoint's IP. Azure can automatically do this if you select 'Yes' for 'Integrate with private DNS zone' during creation. If you use custom DNS, manually add the record.
By default, NSGs are not supported on subnets with private endpoints. You can enable network policies by setting `privateEndpointNetworkPolicies` to `Enabled` on the subnet. However, even then, NSGs only apply to traffic from resources in the subnet to the private endpoint, not to traffic from the private endpoint to the service or from the service to the private endpoint. For inbound traffic to the private endpoint from the service, NSGs are not effective.
Private Endpoints incur charges based on the number of endpoints and data processed. There is an hourly fee per private endpoint and a per-GB fee for data processed through the endpoint. Costs vary by region. Service Endpoints are free. For exam, remember that Private Link has additional cost.
Use Azure Policy to restrict private endpoint creation to approved resources. For example, create a policy that denies private endpoints unless the target resource ID is in an allow list. Also, disable public access on PaaS services and monitor connection approvals. Use network policies to control outbound traffic, but note that NSGs on the subnet do not filter traffic to the private endpoint itself.
Yes, if you have a VPN gateway or ExpressRoute connecting your on-premises network to Azure, you can access private endpoints from on-premises. The private endpoint is in your VNet, so any resource connected to that VNet (including on-premises via VPN/ER) can reach it, provided DNS resolves correctly.
You've just covered Azure Private Link Service — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?