For AZ-305 private access questions, choose Private Link with a private endpoint when the design needs a private IP for a specific Azure PaaS resource, on-premises access over VPN or ExpressRoute, public endpoint disablement, or stronger data-exfiltration protection. Choose service endpoints when the requirement is simpler. A subnet in your virtual network reaches a supported Azure service over the Azure backbone, and the service firewall allows that subnet. Service endpoints are easier to set up and do not require DNS changes, but they do not give the service a private IP in your VNet.
This decision sits in AZ-305's highest-weighted domain. Microsoft lists Design infrastructure solutions at 30-35% on the AZ-305 exam page, with the other domains at 25-30%, 20-25%, and 15-20% (English version updated April 17, 2026). The AZ-305 study guide includes objectives on network connectivity, network performance, network security, and routing decisions.
The cues that pick each option
- Use Private Link with private endpoints when the scenario says private IP, no public endpoint path, access from on-premises, resource-level segmentation, or reduced data-exfiltration risk. Microsoft describes a private endpoint as a network interface with a private IP address in your virtual network that connects to a service powered by Azure Private Link (private endpoint overview).
- Use service endpoints when the scenario says a subnet in Azure should reach supported Azure services over the Azure backbone with simple service firewall rules. Microsoft describes service endpoints as a way to secure Azure service resources to virtual networks while DNS still resolves to public service addresses (service endpoints overview).
- Do not treat either one as a WAN service. VPN Gateway, ExpressRoute, hub-spoke, and Virtual WAN decide how networks connect. Private Link and service endpoints decide how clients reach Azure service resources.
- Keep DNS in the answer. Private endpoints require correct DNS resolution so the normal service FQDN lands on the private endpoint IP.
The two access paths and their scopes
When to pick each option
Private Link and private endpoints
Pick Private Link when the target is a specific Azure PaaS resource such as Storage, SQL, Key Vault, Cosmos DB, or App Service, and the design wants access through a private address in your VNet. In the official comparison, private endpoints apply to an individual instance, support private access from on-premises, let the service disable its public IP address, and require DNS changes (service isolation comparison). The FAQ describes the same scope as network access to specific resources behind the service, providing granular segmentation (Private Link FAQ).
Private Link traffic is sent privately over the Microsoft backbone and does not traverse the internet (Private Link FAQ). Creating a private endpoint does not automatically block every public path for every service. For Azure Storage, Microsoft explicitly notes that creating a private link does not automatically block public endpoint connections, so you still configure the storage firewall or public network access controls (Storage private endpoints).
Service endpoints
Service endpoints fit the simpler requirement, where an Azure subnet needs to reach supported services and the service firewall allows that subnet. You enable the endpoint on the subnet, then configure virtual network rules or ACLs on the service side. Microsoft documents that both steps are required before access is limited to the allowed virtual network and subnet (Private Link FAQ).
The official comparison puts service endpoints at the entire-service scope, with no built-in data-exfiltration protection and no private access from on-premises (service isolation comparison). The address they use remains publicly routable (Private Link FAQ).
Service endpoints are simple to set up with less management overhead. The service endpoints page lists generally available support for Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Key Vault, Azure Service Bus, Azure Event Hubs, Azure App Service, and Azure Container Registry, and notes that DNS entries remain as-is and keep resolving to the public IP addresses of the Azure service (service endpoints overview).
Where the rule bends
Staying on the Microsoft backbone. Both options keep Azure-to-Azure traffic on the Microsoft backbone, and the official comparison marks Azure-to-Azure backbone traffic Yes for both service endpoints and private endpoints. If the stem says traffic must stay on the backbone, that constraint does not pick the option. (service isolation comparison)
The service is in another region. For service endpoints, the virtual network must be in the same region as the service for Azure SQL Database. For the other supported services the overview lists, the VNet can be in any region (service endpoints overview). For private endpoints, the endpoint sits in the same region and subscription as your VNet, while the private-link resource it connects to can be in a different region (private endpoint overview). Region distance alone is not a private endpoint requirement.
Storage is several resources, not one. If you go private for Storage, a separate private endpoint is needed for each storage service you access, such as blobs, files, queues, tables, or static websites (Storage private endpoints). One private endpoint for the account is not the full answer.
Worked AZ-305 scenario
A company has a payment application in a spoke VNet. The app uses Azure SQL Database and a Storage account. The security team requires database and storage traffic to avoid public endpoint access. A few legacy jobs in the datacenter must also read from the same Storage account over ExpressRoute. Developers should not be able to copy data from the protected Storage account to a different public Storage account. The platform team already has hub-spoke connectivity.
First pass: this is not a load-balancing or routing problem. The app is not asking for Front Door, Application Gateway, or Traffic Manager. It is also not asking you to choose VPN Gateway versus ExpressRoute; the hub-spoke transport already exists. The decision is how clients reach Azure SQL and Storage.
Second pass: service endpoints are not enough. They can help an Azure subnet reach supported services and let the target service firewall allow that subnet, but the scenario requires access from on-premises and stronger resource-level isolation. Microsoft says service endpoints cannot be used for traffic from on-premises services to Azure services, and the comparison table lists on-premises private access as a private endpoint capability, not a service endpoint capability (service endpoints overview, service isolation comparison).
Third pass: use private endpoints for the Azure SQL server and the needed Storage subresources. Storage is a good AZ-305 trap because different storage services can need separate private endpoints. Microsoft says you need a separate private endpoint for each Storage resource you need to access, such as blobs, files, queues, tables, or static websites (Storage private endpoints).
Fourth pass: add the minimal DNS requirement. Clients should keep using normal service connection strings and FQDNs, but those names must resolve to private endpoint IPs from the VNets and hybrid clients that use the private path. Microsoft says DNS settings must be configured so the FQDN resolves to the private endpoint IP, and existing public-endpoint DNS must be overridden to connect through the private endpoint (private endpoint overview, private endpoint DNS).
Exam-ready answer: create private endpoints for Azure SQL and the required Storage subresources, configure the service firewalls or public network access settings so public endpoint access is denied where the service supports it, and configure Private DNS resolution for Azure and on-premises clients. Do not answer with service endpoints unless the requirement is limited to Azure VNet subnet access and the scenario does not require public endpoint disablement or on-premises private access.
Common wrong turns
You choose service endpoints because the source is in a VNet
That may be enough for a simple Azure-only subnet allowlist. It is not enough when the prompt says on-premises private access, disable public endpoint access, or resource-instance-level segmentation. You got the scope wrong. Subnet-to-service access is not the same as a private IP to a specific resource.
You choose Private Link but forget public access controls
A private endpoint creates the private path. It does not always remove every public path by itself. The mistake is stopping at the private path. Private connectivity and the service firewall or public network settings are separate checks.
You make the whole answer about Private DNS
DNS matters because the existing FQDN must resolve to the private endpoint IP for private clients. The decision to make is the scope of the access path. A service endpoint covers the entire service, and a private endpoint covers one resource instance.
You turn it into hybrid networking
If the question asks how the datacenter reaches Azure, the answer is in VPN Gateway, ExpressRoute, Virtual WAN, and hub-spoke design. If the question assumes that connectivity already exists and asks how to reach Storage, SQL, or Key Vault privately, stay on Private Link versus service endpoints.
Diagnose a missed question, then take the free assessment
When you miss an AZ-305 private access question, write one short diagnosis of what you got wrong.
- I confused Azure subnet access with on-premises access.
- I protected a whole service when the prompt required one resource instance.
- I created a private path but left the public path uncontrolled.
- I chose the right private endpoint but did not make the FQDN resolve privately.
- I confused WAN connectivity with private PaaS access.
Take the free AZ-305 assessment when you want to check whether this decision still costs you points. It returns a Readiness Report with your top gaps. The full AZ-305 path costs US$34.99 for 12 months of access, and the first repair task is free. The core of the path is the Pass Plan, the ranked list of targeted repair tasks for the misses you diagnose above and the ones your practice uncovers after the assessment. CramHQ re-ranks that list as it grows, and the task that comes first is always the repair for the gap that would cost you the most points on AZ-305. The practice tests and the timed final simulation check your readiness.