The AZ-700 exam asks how to securely access Azure PaaS services over a private network, without exposing traffic to the public internet. Several mechanisms exist, and the exam frequently tests when to choose one over another. This post covers Private Endpoint, Service Endpoint, and Private Link Service — their differences, DNS integration, and common pitfalls.
Private Endpoint: Installing a Dedicated Mailbox Inside Your Building
Imagine a company setting up a private mailbox inside an apartment complex. Instead of using the public postal box at the street, mail is delivered directly to the mailbox inside the building. Private Endpoint works exactly this way.
When you create a Private Endpoint for an Azure PaaS service — such as Storage Account, Azure SQL Database, or Key Vault — the service receives a NIC (Network Interface Card) inside your VNet subnet, along with a private IP address. From that point, traffic to the service never touches the public internet. You can completely disable the public endpoint on the service side, and on-premises clients can route to this private IP through a VPN or ExpressRoute connection.
Private DNS Zone: The Address Book That Resolves Private IPs
In a large library, knowing the book title is not enough — you also need the shelf number. A librarian who maps titles to shelf locations does exactly what Private DNS Zone does: it maps a service FQDN to a private IP address.
When you create a Private Endpoint, the service FQDN (for example, mystorageaccount.blob.core.windows.net) is redirected to privatelink.blob.core.windows.net. Linking a Private DNS Zone (privatelink.{service}.azure.com) to your VNet ensures that VMs inside the VNet automatically resolve this FQDN to the private IP.
For on-premises environments, you must configure a Conditional Forwarder on your DNS server to forward privatelink domain queries to the Azure DNS resolver. Without this step, on-premises VMs will fail to find the private IP.
Service Endpoint: Showing a VIP Pass at the Entrance
Think of a VIP membership card at a large shopping center. You skip the general queue and enter faster, but you are not moving into the building — you are still arriving from outside. Service Endpoint works the same way.
Enabling a Service Endpoint on a subnet routes traffic from that subnet to the Azure service via the Microsoft backbone network. The service retains its public IP address, but the traffic never leaves Microsoft's network to reach the open internet. The service-side firewall must explicitly allow the VNet ID for the path to open.
An important constraint is that on-premises clients cannot use this path directly. Also, the service's public endpoint remains accessible to other VNets or external callers.
Private Link Service: Exposing Your Own Service Privately
A logistics company wants to share its warehouse system with a partner without putting it on the internet. They need a dedicated private channel. Private Link Service fills this role.
Private Link Service is used when you — not Microsoft — want to expose your own service to other customers' VNets without making it public. You place the service behind a Standard Load Balancer, create a Private Link Service resource, and consumers in other VNets can reach it through a Private Endpoint.
Every connection request goes through an approval workflow. The consumer sends a connection request, and the service owner either approves or rejects it. Traffic only flows after approval is granted.
Private Endpoint vs. Service Endpoint: Choosing Between the Two
Booking a reserved table at a restaurant (Private Endpoint) is different from flashing a loyalty card for faster entry through the public door (Service Endpoint).
| Criteria | Private Endpoint | Service Endpoint | | :-- | :-- | :-- | | Access IP | Private IP (VNet NIC) | Public IP retained | | Disable public endpoint | Yes | No | | On-premises routing | Yes (VPN/ExpressRoute) | No | | Cost | Hourly + data charges | Free | | DNS integration | Private DNS Zone required | Not required |
If strict security or on-premises access is required, choose Private Endpoint. For simple backbone routing within the same region from a VNet, Service Endpoint is sufficient and free.
!Private Endpoint versus Service Endpoint
Blocking the Public Endpoint and On-Premises Access Scenarios
Sealing company documents so no one outside can read them, while simultaneously creating a private corridor for office staff — that combination is what Private Endpoint handles together.
When you disable the public endpoint on a Storage Account and create a Private Endpoint, VNet clients access it via the private IP and the internet route is completely blocked. On-premises offices connected through ExpressRoute can also reach the Storage Account using that same private IP.
Service Endpoint, by contrast, cannot block the public endpoint and does not support on-premises routing. If your compliance requirement explicitly states that internet traffic must be blocked at the source, Service Endpoint alone does not satisfy it.
Common Pitfalls: Missing DNS and Unapproved Connections
A car navigation system that has not been updated will not show new roads. Similarly, a Private Endpoint without proper DNS configuration will still send traffic to the public IP.
The most common mistake is creating a Private Endpoint but forgetting to link the Private DNS Zone to the VNet. The VM queries the service FQDN, receives the public IP, and fails to connect if the public endpoint is also disabled. On-premises environments have the same symptom when the Conditional Forwarder is not configured.
The second pitfall is Private Link Service approval — a consumer's Private Endpoint stays 'Pending' until the service owner approves the connection. The third is combining Service Endpoints with NSG rules: enabling a Service Endpoint alone does not open the path unless the NSG also allows the corresponding service tag.
Exam Key Takeaways
"Access Azure PaaS with a private IP inside the VNet" -- Private Endpoint "Completely disable the public endpoint on a storage account" -- Private Endpoint + disable public access "On-premises access to Azure Storage over a private network" -- Private Endpoint + VPN or ExpressRoute "Backbone routing from VNet, public IP retained" -- Service Endpoint "Expose my own service to another customer's VNet privately" -- Private Link Service "Connection request stuck in Pending, approval needed" -- Private Link Service approval workflow "FQDN returns public IP even with Private Endpoint existing" -- Private DNS Zone not linked to VNet "On-premises clients cannot resolve the privatelink domain" -- Conditional Forwarder not configured "Service Endpoint enabled but traffic still blocked" -- NSG service tag must also be allowed "Compliance requirement: block all internet traffic at the source" -- Service Endpoint insufficient; use Private Endpoint
Private Endpoint = private IP, blocks public access, supports on-premises; Service Endpoint = backbone routing, public IP retained, free