Azure Private Link vs Service Endpoints: What AZ-305 Expects

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: allow a subnet in an Azure virtual network to reach supported Azure services over the Azure backbone and restrict the service firewall to that virtual network. Service endpoints are easier and do not require Private DNS changes, but they do not give the service a private IP in your VNet.

This sits inside AZ-305's highest-weighted domain: Microsoft lists Design infrastructure solutions at 30-35% and the current study guide includes network connectivity, network performance, network security, and routing decisions (AZ-305 exam page, AZ-305 study guide).

Decision Shortcut

• Use Private Link/private endpoints when the scenario says private IP, no public endpoint path, access from on-premises, cross-region PaaS access, 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 scope, but not as the whole article. Private endpoints require correct DNS resolution for the normal service FQDN to land on the private IP. The deeper hub-spoke Private DNS design belongs in a separate Private DNS article.

One Small Architecture Lens

The exam trap is the scope of protection. A service endpoint identifies a virtual network subnet to a supported Azure service and lets the service firewall allow that subnet. A private endpoint creates a private IP path to a specific resource instance. Those are different architecture answers, even when both keep Azure-to-Azure traffic on the Microsoft backbone.

Decision Cards

Private Link and Private Endpoints

Reach for 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 a VNet. Microsoft says Private Link traffic is sent privately over the Microsoft backbone and does not traverse the internet (Private Link FAQ).

Why it fits AZ-305: private endpoints support granular segmentation. The official comparison says private endpoints apply to an individual instance, can be reached from on-premises without public endpoints, can let the service disable public IP access, and require DNS changes (service isolation comparison).

Watch out for: 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; you still configure the storage firewall or public network access controls (Storage private endpoints).

Service Endpoints

Reach for service endpoints when the requirement is simpler VNet-scoped access from Azure subnets to supported services. 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).

Why it fits AZ-305: service endpoints are straightforward, have less management overhead, and do not require DNS changes. Microsoft also lists generally available support for services such as Azure Storage, Azure SQL Database, Azure Cosmos DB, Key Vault, Service Bus, Event Hubs, App Service, and Azure Container Registry on the service endpoints page (service endpoints overview).

Watch out for: service endpoints are not private endpoints with fewer clicks. The official comparison says service endpoints apply at the entire-service scope, remain publicly routable IP addresses, do not provide built-in data-exfiltration protection, and do not provide private access from on-premises (service isolation comparison).

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 and wants to keep this article's decision limited to private service access, not the whole network topology.

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; that 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 warns that private endpoint DNS settings are important and says 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 simpler Azure VNet subnet access and public endpoint disablement/on-premises private access is not required.

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. Label the miss as scope: subnet-to-service is not the same as 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. Label the miss as public endpoint control: private connectivity and service firewall/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. But AZ-305 private access questions usually start with the service boundary: service endpoint or private endpoint. Label the miss as order of reasoning: choose the access pattern first, then make DNS support it.

You turn it into hybrid networking

If the question asks how the datacenter reaches Azure, review VPN Gateway, ExpressRoute, Virtual WAN, and hub-spoke design in the AZ-305 hybrid network connectivity guide. 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.

How To Drill This In CramHQ

When you miss an AZ-305 private access question, write one short diagnosis:

• Source boundary miss: I confused Azure subnet access with on-premises access.
• Target boundary miss: I protected a whole service when the prompt required one resource instance.
• Public endpoint miss: I created a private path but left the public path uncontrolled.
• DNS miss: I chose the right private endpoint but did not make the FQDN resolve privately.
• Layering miss: I confused WAN connectivity with private PaaS access.

CramHQ can turn those misses into a focused learning loop: diagnostic insight to identify the decision boundary, remediation that isolates the weak point, targeted practice with nearby AZ-305 networking scenarios, and readiness planning across the Infrastructure domain. When you are ready to test whether this pattern is still costing you points, take the AZ-305 assessment. CramHQ is independent exam-preparation software, not a Microsoft product and not a pass guarantee.

Quick Recap

Use service endpoints for simple Azure VNet subnet-to-service access when supported services and subnet firewall rules satisfy the requirement. Use Private Link and private endpoints when the design needs a private IP to a specific resource, on-premises private access, public endpoint disablement, or stronger exfiltration protection. Keep DNS in the answer for private endpoints, but do not let DNS hide the main AZ-305 decision: whether the requirement is service-scope subnet access or resource-scope private access.