The DNS answer for an Azure Private Link scenario on AZ-305 has three moves. Keep the application's normal service FQDN in the connection string. Make that name resolve to the private endpoint's IP address for the clients that use the private path. Give every client network a DNS path to the private DNS zone that holds that record. Microsoft says the existing public-endpoint DNS configuration must be overridden to connect using your private endpoint, and a private DNS zone linked to the client's VNet performs that override (private endpoint DNS, Private DNS zone overview).
A Private Link scenario reads like a networking question, and the clue that decides it is the name resolution path. The question family sits in Design infrastructure solutions, one of the four domains the exam measures, and that domain carries a 30-35% weight on the exam page (AZ-305 exam page). The study guide lists the skills measured as of April 17, 2026, and its Design network solutions tasks cover connectivity to the internet and to on-premises networks, network performance, network security, and load balancing and routing (AZ-305 study guide). Recheck both pages before you book. The exam is updated periodically, and Microsoft always updates the English version first.
Pick the DNS design from where the client sits
Which DNS design a scenario needs depends on where the clients sit and what DNS they use. The cases below pair each client situation with the mechanism that serves it.
- A single VNet whose clients use Azure-provided DNS. Create the service's recommended private DNS zone, let the private endpoint create its A record, and link the zone to the VNet that holds the clients. Records in a private DNS zone resolve only from the virtual networks that are linked to it (Private DNS zone overview).
- Hub and spokes whose clients use Azure-provided DNS. Link the same single zone to every hub and spoke VNet whose clients need the name. Microsoft says a single private DNS zone is required for the peered and hub-and-spoke configurations, and that creating multiple zones with the same name would need manual operations to merge the DNS records (DNS integration scenarios).
- Any VNet with a custom DNS server. The zone link alone does not reach those clients. A custom DNS server overrides the default name-resolution order, so the system does not automatically query the linked private zones. Forward the queries through an Azure DNS Private Resolver deployed in a VNet linked to the zone, or through another DNS forwarder in that VNet (Private DNS zone overview).
- On-premises clients. A query for the private zone must originate from the VNet linked to it, so the on-premises path runs through a forwarder in Azure. Deploy an Azure DNS Private Resolver or a DNS forwarder virtual machine in a VNet linked to the zone, and point the on-premises conditional forwarder at it. The forwarder targets the service's public zone, such as
database.windows.net, not theprivatelinkzone (DNS integration scenarios). - The service-access pattern. This article assumes Private Link is already the pattern the scenario chose for reaching the service. The question left to answer is whether the name resolves to the private endpoint IP from every required client network.
The resolution chain for a SQL endpoint
In this example, the application connects to server.database.windows.net, the service's normal name. Public DNS returns a CNAME into the privatelink namespace, and the client gets the private IP only when its DNS path reaches the A record in the linked private DNS zone. The connection URL for an existing application does not change. A spoke that uses Azure-provided DNS skips the resolver entirely, because its default DNS queries the linked zone directly (private endpoint DNS, Private DNS zone overview).
The three decisions every design must settle
Which private DNS zone owns the record
Use the private DNS zone that Microsoft publishes for the service. Azure SQL Database uses privatelink.database.windows.net, and a Storage account's blob endpoint uses privatelink.blob.core.windows.net (private endpoint DNS zone values). The CNAME chain from the public name lands in that zone, so the zone you link is the zone that answers the query.
Create one zone for the service and put it where the clients can reach it. In a hub-and-spoke topology, a common scenario creates the private DNS zone once in the hub, and the spokes register to it instead of creating zones of their own (DNS integration scenarios).
Which VNets need a link, and which need forwarding
For a VNet that uses the default DNS settings, the zone link is the whole design. The system queries the linked private DNS zones first, before it queries the Azure-provided DNS servers (Private DNS zone overview). You do not need to enable the link's autoregistration setting for the endpoint's A record. That setting manages the life cycle of records for the VNet's virtual machines, and the A record already exists in the zone.
For a VNet that uses a custom DNS server, the zone link does not reach the clients. The custom settings override the name-resolution order, and the system does not automatically query the linked private zones. The fix is a forwarder in the path. Deploy an Azure DNS Private Resolver in a VNet linked to the zone, or configure a conditional forwarder on the custom DNS server that points at a forwarder in the linked VNet (Private DNS zone overview).
Where the private endpoint lives
Placement is a separate decision from DNS visibility, and the exam tests them independently. The Architecture Center's hub-and-spoke guide says to deploy the endpoint in the hub when on-premises systems access the resource or when more than one application needs it, and in the application's spoke when only one application needs access (hub-and-spoke guide). For name resolution, the same guide says to integrate the endpoint with a centralized private DNS zone and link that zone to every VNet that must resolve the name, whether the endpoint sits in a hub or a spoke. A private endpoint deployed in one spoke does not make the other spokes resolve it. Each client network needs its own linked zone or resolver path.
The same decisions in one hub-and-spoke scenario
A company runs a claims application in a spoke VNet. The app reaches Azure SQL Database through a private endpoint, and the security team wants the connection string to keep its normal FQDN. Two other spokes host batch jobs that need the same database, and jobs in the datacenter must resolve the same name. The hub VNet holds the ExpressRoute circuit to the datacenter.
First pass. The service-access pattern is fixed by the scenario. The app already reaches the database through a private endpoint, so the question is the DNS path, not the access pattern.
Second pass. Choose the zone. Use the SQL private DNS zone, privatelink.database.windows.net, and let the private endpoint's zone group create and maintain the A record. The zone group keeps the record in step with the endpoint, and when the endpoint is deleted, the zone group's records are deleted with it. A zone group supports up to five DNS zones, and a private endpoint can have only one zone group (DNS integration scenarios).
Third pass. Give every client network a path to the zone. The three spoke VNets use Azure-provided DNS, so link the single zone to each of them. The datacenter uses on-premises DNS, so deploy an Azure DNS Private Resolver or a DNS forwarder virtual machine in the hub VNet, which is linked to the zone. The on-premises DNS server conditionally forwards database.windows.net to that forwarder over the ExpressRoute circuit. The forwarder targets the public service zone, not the privatelink zone. Microsoft states that requirement explicitly for the on-premises configurations, and it requires the same single zone for the on-premises and VNet clients (DNS integration scenarios).
Exam-ready answer. Keep the normal SQL FQDN in the application. Use one SQL private DNS zone for the endpoint's A record. Link that zone to every client VNet that uses Azure-provided DNS. Route custom-DNS and on-premises clients through a resolver or forwarder in a linked VNet that conditionally forwards the public service zone.
Four ways the DNS design fails
You link only the VNet that holds the endpoint
Linking the zone to the endpoint's VNet makes the name resolvable from that VNet. It does not help a spoke that is not linked, and peering does not change that. Resolution against a private DNS zone works only from the virtual networks that are linked to it, so either link the zone to the other spoke or route its queries through a resolver path that can see the zone (Private DNS zone overview).
You forward only the privatelink zone from on-premises
The on-premises client queries the public service name, and the CNAME chain from that name lands in the privatelink zone. The conditional forwarder must therefore target the public service zone, such as database.windows.net, not privatelink.database.windows.net. Microsoft states that requirement for the on-premises scenarios (DNS integration scenarios).
You treat DNS as access control
Making the name resolve to a private IP does not restrict who can reach the service. DNS resolution and access control are independent (private endpoint DNS). The endpoint still needs its own firewall rules, and the resource's public network access setting decides whether the public path stays open. When a resource has public network access disabled, or the service firewall denies the caller, the service rejects the connection at the front door regardless of DNS resolution.
You create one zone per team or per spoke
Separate zones with the same name drift apart. When they hold different records, clients in different VNets can resolve the same name to different IPs, and only manual merging keeps them aligned. That is why the peered and hub-and-spoke configurations require one zone (DNS integration scenarios).
Label the wrong answer by cause
When you get an AZ-305 Private Link DNS question wrong, label the wrong answer with one of four causes.
- Zone error. You picked the wrong
privatelinkzone for the service, or missed that the service resolves through more than one zone. - Link gap. The zone exists with the right record, but the client's VNet is not linked to it and its DNS path cannot query it.
- Forwarding gap. The custom or on-premises DNS never forwards the public service zone into Azure, so the CNAME chain stops at public DNS.
- Layering gap. You solved name resolution but ignored the other layer the scenario checks, such as endpoint placement, public endpoint controls, or identity.
Write one line per wrong answer naming the cause, fix that layer, and work the nearby scenarios again.
Next step
If Private Link DNS questions still cost you points, take the free AZ-305 assessment. It is free, needs no credit card, and returns a Readiness Report with your top gaps and a targeted repair preview. One of the sample gap areas on the AZ-305 path is Identity and network boundaries, the same two layers this article keeps separate (free AZ-305 assessment).
When you are ready for the full path, the Pass Plan is the ranked list of targeted repair tasks that CramHQ keeps in step with your practice. Your first set of gaps comes from the free assessment, and the practice work you do after that adds more. CramHQ marks each gap with the points it would cost on the AZ-305, and orders the plan by that number, largest first. The practice tests and the timed simulation check your readiness before the exam. The full path costs 34.99 USD for 12 months of access (AZ-305 course).