Azure Private DNS for Private Link: AZ-305 Resolution Paths

For AZ-305, the DNS answer for Private Link is usually this: keep the application's normal Azure service FQDN, make that name resolve to the private endpoint IP for the clients that should use the private path, and design the private DNS zone links or resolver forwarding so every hub, spoke, and on-premises client follows the same resolution chain. Microsoft says private endpoint DNS must override the existing public-endpoint DNS so the FQDN resolves to the private endpoint IP, and Private DNS zones can be linked to VNets for that purpose (private endpoint DNS, Private DNS zone overview).

This matters inside AZ-305 because Microsoft lists Design infrastructure solutions at 30-35%, and the current study guide includes design network solutions such as connectivity, network performance, network security, load balancing, and routing (AZ-305 exam page, AZ-305 study guide). Private endpoint questions often look like networking questions, but the deciding clue is frequently name resolution.

Decision Shortcut

• Single VNet, Azure-provided DNS: create the recommended private DNS zone for the service, add or auto-create the A record, and link the zone to the VNet that contains the client. Microsoft says private DNS records resolve only from linked virtual networks (Private DNS zone overview, virtual network links).
• Hub-spoke with Azure-provided DNS in spokes: link the same private DNS zone to every hub or spoke VNet that contains clients needing private endpoint resolution. Microsoft warns that hub-spoke private endpoint scenarios should use one private DNS zone and link it to all client VNets that need resolution (Private Endpoint DNS integration scenarios).
• Hub-spoke with centralized custom DNS: link the zone to the VNet where the resolver or DNS forwarder can query Azure DNS, then forward client queries through that resolver path. Microsoft documents centralized and distributed Azure DNS Private Resolver patterns with inbound endpoints, outbound endpoints, and rulesets (Private resolver architecture).
• On-premises clients: do not point on-premises DNS directly at Azure-provided DNS. Use an Azure DNS Private Resolver inbound endpoint or an Azure DNS forwarder reachable over VPN or ExpressRoute. Microsoft says on-premises DNS should conditionally forward private endpoint queries to a resolver or forwarder in Azure (Private Endpoint DNS integration scenarios).
• Do not re-decide Private Link versus service endpoints here: this article assumes Private Link is already the correct service-access pattern. The remaining design question is whether names resolve to the private endpoint IP from every required network.

Resolution Path Diagram

Read the diagram from left to right. The application still connects to the normal service name, such as server.database.windows.net. Public DNS can return a CNAME into a privatelink namespace, but the client only gets the private IP when its DNS path can reach the matching private DNS zone record. Microsoft describes that CNAME behavior and says connection URLs for existing applications do not change (private endpoint DNS).

The Three Decisions AZ-305 Is Really Testing

1. Which private DNS zone owns the record?

Use the Microsoft-recommended private DNS zone for the service, such as privatelink.database.windows.net for Azure SQL Database or privatelink.blob.core.windows.net for Storage blob endpoints. Microsoft publishes the private DNS zone values because the zone name is not cosmetic; it is how the private endpoint FQDN maps to the private IP (private endpoint DNS zone values).

Avoid creating separate zones with the same name in multiple spokes. Microsoft says a single private DNS zone is required for the peered VNet and hub-spoke scenarios, because multiple same-name zones force manual record merging and can create resolution failures (Private Endpoint DNS integration scenarios).

2. Which VNets need a link, and which only need forwarding?

If a VNet uses Azure-provided DNS, a private DNS zone link is the simplest answer. A VNet link makes the zone visible to clients in that VNet, and a link without autoregistration is enough when the zone is only resolving private endpoint records (virtual network links).

If the VNet uses custom DNS, the link alone is not enough for the client. Microsoft says custom DNS settings override the default name-resolution order, so clients do not automatically query linked private DNS zones. Your custom DNS path must forward the relevant queries into Azure DNS through Azure DNS Private Resolver or another forwarder in a VNet linked to the zone (Private DNS zone overview).

3. Where does the private endpoint live?

Private endpoint placement is related, but it is not the same as DNS visibility. The Azure Architecture Center recommends centralized private endpoint placement when on-premises systems or multiple applications need access, and spoke placement when only one application needs the resource. For name resolution, it still says to integrate the endpoint with a centralized private DNS zone and link that zone to all VNets that need to resolve the private endpoint DNS name (Private Link in hub-spoke).

That is the exam trap: a private endpoint in a spoke does not magically make every other spoke resolve it. A linked zone or resolver path must exist for each client network.

Worked AZ-305 Scenario

A company runs a claims application in a spoke VNet. The app uses Azure SQL Database through a private endpoint. The hub VNet contains shared DNS and connectivity to the datacenter over ExpressRoute. Two other spokes host batch jobs that also need the database. The security team says the app should keep using the normal SQL connection string, and datacenter jobs must resolve the same name to the private endpoint IP.

First pass: this is not a service endpoint comparison. Private Link is already required because the clients include on-premises workloads and the target is a specific database endpoint. Microsoft describes Private Link as private access to Azure PaaS services over a private endpoint, and Microsoft marks Private Link and private endpoints as generally available (Private Link overview).

Second pass: choose the DNS authority. Use the recommended SQL private DNS zone and the A record that maps the private endpoint name to the private IP. If a private DNS zone group is used, Microsoft says it associates the private endpoint with the zone and helps manage the records when the endpoint changes (Private Endpoint DNS integration scenarios).

Third pass: make every client network reach that authority. The workload spoke, batch spokes, and hub need either direct links to the same private DNS zone or a centralized resolver design that forwards their queries to a linked hub. On-premises DNS should conditionally forward the public service zone, such as database.windows.net, to an Azure DNS Private Resolver inbound endpoint or DNS forwarder in Azure. Microsoft explicitly calls out forwarding to the recommended public DNS zone rather than the privatelink zone in hybrid examples (Private Endpoint DNS integration scenarios).

Exam-ready answer: keep the SQL FQDN in the application, use one SQL private DNS zone for the private endpoint record, link the zone to client VNets that use Azure-provided DNS, and use DNS Private Resolver or an Azure DNS forwarder for custom DNS and on-premises clients.

Common Wrong Turns

You link only the private endpoint VNet

That works only for clients whose DNS path can query that linked zone. If another spoke uses Azure-provided DNS and is not linked to the zone, peering alone does not make the private DNS zone visible. Link the zone to that spoke or route its DNS queries through a resolver path that can see the zone.

You forward only the privatelink zone from on-premises

The client usually asks for the public service name first, not the privatelink name. Microsoft hybrid examples say the conditional forwarder should target the recommended public DNS zone, such as database.windows.net, because the CNAME chain then lands in the private zone and returns the private IP (Private Endpoint DNS integration scenarios).

You treat DNS as access control

DNS makes the private path discoverable. It does not replace service firewall settings, public network access controls, identity, or authorization. Private Link helps bring a resource into a private address path, but the resource still needs normal access controls and any public endpoint restrictions required by the scenario.

You create one zone per team

That feels decentralized, but it is dangerous when the zone names overlap. Microsoft calls for a single private DNS zone in the hub-spoke patterns, and the CAF scale guidance describes central private DNS zones in the connectivity subscription for Private Link services (Private Link and DNS integration at scale).

How to Study This in CramHQ

When you miss an AZ-305 Private Link DNS question, label the miss with one of four causes:

• Zone miss: you chose the wrong privatelink zone or forgot that some services need more than one zone.
• Link miss: the private DNS zone exists, but the client VNet cannot query it.
• Forwarding miss: custom or on-premises DNS never forwards the original public service zone into Azure.
• Layering miss: you solved DNS but ignored private endpoint placement, public endpoint controls, or identity.

CramHQ can turn that diagnosis into a tighter study loop: identify the specific networking boundary you missed, review a focused lesson, practice nearby AZ-305 scenarios, and check readiness without rereading every hybrid connectivity article. CramHQ is independent exam-preparation software, not a Microsoft product and not a pass guarantee. When you are ready to test this pattern, take the AZ-305 assessment.

Quick Recap

For Private Link on AZ-305, the most reliable mental model is: normal FQDN in the app, private endpoint IP in the answer, and a DNS path that lets every required client resolve that private IP. Link private DNS zones directly when clients use Azure-provided DNS. Use Azure DNS Private Resolver or an Azure DNS forwarder when clients use custom DNS or live on-premises. Keep Private Link versus service endpoints out of the answer unless the prompt is actually asking for the service-access pattern instead of the name-resolution path.