AZ-305 DNS questions are rarely about memorizing one service name. They are usually about deciding which authority answers the name, which network can reach that authority, and whether DNS is only selecting an endpoint or the design also needs inline traffic handling.
For Azure architecture scenarios, start with the visibility boundary:
| Design need | Better fit | Why it fits |
|---|---|---|
| Host records for an internet-facing domain | Azure Public DNS | The records are authoritative for public name resolution. |
| Resolve private records from selected Azure virtual networks | Azure Private DNS | Private DNS records are not resolved from the public internet and depend on VNet links. |
| Let on-premises clients resolve Azure private zones | Azure DNS Private Resolver inbound endpoint plus conditional forwarding | The on-premises DNS path needs a target inside Azure that can resolve the linked private zones. |
| Let Azure workloads resolve on-premises namespaces | Azure DNS Private Resolver outbound endpoint plus forwarding ruleset | The Azure-side resolver path sends matching namespaces to configured DNS servers. |
| Select among public regional endpoints at DNS lookup time | Azure Traffic Manager | Traffic Manager is DNS-based endpoint selection; it is not an inline proxy after resolution. |
The common exam trap is assuming private connectivity automatically fixes name resolution. A private endpoint can exist and the network path can be valid, but clients still fail the design if the service FQDN does not resolve to the private endpoint private IP from every client network that needs private access.
Worked Scenario
Contoso runs a public web application in two Azure regions. The application also uses a private data service through Private Link. Developers in a spoke VNet, operations servers in a hub VNet, and on-premises administrators over ExpressRoute all need to reach the private service by its normal service FQDN.
A good AZ-305 answer separates the public and private decisions:
- Use Azure Public DNS for the public application domain.
- Use Traffic Manager only if DNS-level regional endpoint selection is enough for the public app. If the scenario asks for request inspection, TLS termination, WAF policy, or reverse-proxy behavior, Traffic Manager alone is the wrong tool.
- Use Azure Private DNS for the private endpoint name so the service FQDN resolves to the private endpoint private IP.
- Link the private zone to the VNets that use Azure-provided DNS, or centralize resolution with Azure DNS Private Resolver when many VNets and on-premises networks need the same answer.
- For on-premises administrators, configure on-premises conditional forwarding to a Private Resolver inbound endpoint.
- For Azure workloads that must resolve on-premises domains, use a Private Resolver outbound endpoint and a forwarding ruleset.
That is the exam decision model: public authority for public names, private authority for private names, resolver endpoints for hybrid query direction, and a separate decision for DNS-based routing versus inline traffic handling.
Resolution Path Diagram
Read the arrows as query paths, not packet forwarding paths. Traffic Manager returns a DNS answer and the client connects to the chosen endpoint directly. Private Resolver endpoints move DNS questions between Azure and private networks; they do not replace the need to link zones, create forwarding rules, or configure client networks to use the intended resolver path.
Decision Rules
Use these rules to keep the answer disciplined:
- If the name must be resolvable from the public internet, start with Azure Public DNS or another public authoritative DNS service.
- If the record should only resolve from Azure VNets, start with Azure Private DNS and verify the right VNet links.
- If custom DNS is configured on a VNet, do not assume linked private zones are queried automatically; design conditional forwarding or a resolver path.
- If the DNS query starts on-premises and needs an Azure private zone answer, point conditional forwarding to a Private Resolver inbound endpoint.
- If the DNS query starts in Azure and needs an on-premises namespace answer, use an outbound endpoint and forwarding ruleset.
- If the answer needs request inspection or proxy behavior after DNS resolution, DNS-based routing alone is not sufficient.
Quick Exam Check
When an answer option sounds like it fixes networking but never fixes DNS, slow down. Private Link, peering, ExpressRoute, and hub-spoke routing can provide connectivity, but the exam will still expect the correct name-resolution path.
For AZ-305 practice, test yourself on whether you can identify the authority, client location, resolver path, and whether DNS-based selection is enough.
Quick Recap
If the interactive checks do not load, keep the exam sequence simple: identify who must resolve the name, decide whether the authority is public or private, check whether Azure-provided DNS or custom DNS controls the lookup path, then add Private Resolver inbound or outbound endpoints only for the hybrid query direction that actually exists. For public multi-region selection, remember that Traffic Manager returns DNS answers; it does not inspect, terminate, or proxy application requests after resolution.
Take the targeted AZ-305 assessment to find the network design decisions you should review next: https://cramhq.com/quiz/assessment/AZ-305