Implement and manage virtual networking
Azure DNS and Load Balancing
CoreSeparate name resolution from traffic distribution and troubleshoot internal or public load balancers with probe evidence.
Aligned to the current AZ-104 study guide, verified August 21, 2026.
Why this matters
Clients must first resolve a usable address and then reach a healthy load-balancer frontend, rule, and backend path; DNS and traffic distribution solve consecutive but different problems.
Must Know
- Azure DNS hosts public DNS zones for internet names and private DNS zones for linked virtual networks.
- A Load Balancer frontend is public or internal, while backend pools identify instances that can receive Layer 4 traffic.
- A load-balancing rule maps frontend IP and port to backend port and protocol and works with a health probe.
- Health probes determine which backend instances are eligible for new flows; probe reachability and application response both matter.
- Use supported current Load Balancer configurations; Basic Load Balancer is retired and should not be selected for a new deployment.
Compare and Distinguish
- Azure DNS vs Load Balancer: return an address for a name vs distribute TCP or UDP flows reaching a frontend.
- Azure Load Balancer vs Application Gateway: Layer 4 TCP/UDP distribution vs Layer 7 HTTP/S routing by URL path or host, with TLS termination and optional WAF.
- Public vs internal Load Balancer: internet-reachable public frontend vs private frontend address inside a VNet.
- Frontend IP vs backend pool vs health probe: client destination vs eligible target set vs target-health test.
- DNS failure vs load-balancing failure: client cannot obtain the right frontend address vs traffic reaches a frontend whose rule, probe, or backend path fails.
Scenario examples
- Scenario: An internal line-of-business service must use a private frontend. Think: Configure an internal Load Balancer with a subnet frontend address and private DNS record if a name is required.
- Scenario: The hostname returns no address. Think: Correct the DNS zone, delegation or VNet link, and record before changing load-balancer rules.
- Scenario: The frontend responds but one backend never receives new connections. Think: Inspect pool membership, probe status and response, NSG, and listener.
Exam traps
- Creating a DNS record does not distribute traffic or assess backend health.
- A VM in the backend pool is not eligible when its health probe fails.
- An internal load balancer does not become internet-facing because a public DNS name points to its private address.
Key takeaways
- Resolve the name first, then validate frontend, rule, probe, backend membership, filtering, and listener.
- Choose public or internal load balancing from who must reach the frontend, not from where backends reside.
How it works
- A resolver finds the applicable public or private zone and returns a record; the client then opens a flow to that address.
- Load Balancer hashes eligible flows across healthy backend endpoints according to the rule and probe state.
Objects and administrative surfaces
- DNS zone — record sets, name servers, VNet links for private zones, and resolution scope.
- Load Balancer — SKU, public or private frontend, backend pool, health probe, rule, inbound NAT rule, and outbound configuration.
- Backend NIC or instance — pool membership, NSG, guest listener, and probe response.
When to use it
- Use Azure DNS to host authoritative public zones or Azure-integrated private zones.
- Use Azure Load Balancer for regional Layer 4 distribution to public or private backends.
Security and governance implications
- Restrict DNS record changes and avoid publishing private service addresses in public zones.
- Expose only required frontend ports and ensure probe sources and service traffic are permitted as documented.
How to reason about this
- Query DNS from the affected client, verify the returned frontend, then inspect rule protocol and ports, probe state, backend membership, NSG, route, and process listener.
- When only some instances fail, compare their probe response and network configuration with a healthy backend.
More detail
- Create public or private DNS zones and records, delegate public zones, and link private zones to the VNets that need resolution.
- Configure current Load Balancer frontends, pools, probes, and rules and interpret health evidence.
Ready for the quiz?
- Which resource answers a hostname query?
- What makes a backend eligible for new load-balanced flows?
- When is an internal frontend required instead of a public one?
Related objectives
- D4.3.S1 — Configure Azure DNS
- D4.3.S2 — Configure an internal or public load balancer
- D4.3.S3 — Troubleshoot load balancing