Configure Azure DNS and Load Balancing for AZ-104

AZ-104 networking questions often end with one of two root causes: the name does not resolve where you think it should, or the load-balancing path is not healthy. That is why Azure DNS and load balancing appear together in the official outline.

What the exam wants you to distinguish

Azure DNS handles name resolution. Azure Load Balancer handles Layer 4 traffic distribution for internal or public scenarios. Those are different jobs. If the question is about hostnames, records, or private name resolution, think DNS first. If it is about frontend IPs, backend pools, probes, or rule behavior, think load balancing.

What Microsoft explicitly includes

The current study guide is very direct here:

• configure Azure DNS
• configure an internal or public load balancer
• troubleshoot load balancing

This page is meant to cover that full set. Private endpoint name resolution shows up heavily in 4.2 Secure Private Access, while this page focuses on the DNS and load-balancer decisions that administrators keep making in live environments.

One useful contrast

Azure Load Balancer is the main AZ-104 load-balancing service in scope. Application Gateway and Front Door are useful broader Azure services, but they solve different Layer 7 or edge-routing problems. Do not let those products distract you from the simpler load-balancer choices this exam usually cares about.

DNS choices that matter on AZ-104

Azure DNS does not send the traffic anywhere. It only tells the client which IP or endpoint to use. Many candidates mix up “the app is down” with “DNS is pointing to the wrong place,” and AZ-104 deliberately exploits that confusion.

Public versus internal load balancer

The exam does not usually want a long product tour. It wants you to choose the right frontend exposure model and then reason about probe health and backend reachability.

Common traps

• choosing a public load balancer when the requirement is internal-only access
• ignoring health probes when a backend appears down
• blaming NSGs for a failure that starts with incorrect DNS records or record targets

Lab moves worth practicing

• create a public and an internal load balancer and compare the frontends
• inspect health-probe status and rule behavior
• create or review Azure DNS records, including the private DNS records tied to private endpoints

Symptom map

Load-balancer components to recognize

If the backend is healthy in theory but receives no traffic in practice, the probe is often the first place to look.

DNS mental model for AZ-104

Public DNS answers public names. Private DNS answers private names inside the networks that are linked to the zone. Private endpoint designs often fail because the private zone exists but is not linked correctly, or because the expected record does not map the service name to the private IP. That is why DNS mistakes can look like application or firewall failures.

Request path you should be able to troubleshoot

    flowchart LR
	  C["Client"] --> D["Azure DNS lookup"]
	  D --> F["Load balancer frontend IP"]
	  F --> P["Health probe evaluation"]
	  P --> B["Healthy backend pool member"]

If the client never gets the right IP, the problem is upstream in DNS. If the client gets the IP but traffic still fails, the next checks are usually the frontend type, backend pool membership, probe, rule, and the backend’s own reachability.

CLI example: create the record, probe, and rule

This is the operational shape Azure administrators need to recognize, even if the exam phrases it in portal language:

 1# Create a public DNS zone and add an A record
 2az network dns zone create -g net-rg -n corp.example.com
 3az network dns record-set a create -g net-rg -z corp.example.com -n app --ttl 300
 4az network dns record-set a add-record -g net-rg -z corp.example.com -n app -a 20.30.40.50
 5
 6# Create a standard public load balancer with a frontend and backend pool
 7az network lb create \
 8  -g net-rg \
 9  -n app-lb \
10  --sku Standard \
11  --public-ip-address app-lb-pip \
12  --frontend-ip-name app-fe \
13  --backend-pool-name web-pool
14
15# Add a health probe and load-balancing rule
16az network lb probe create \
17  -g net-rg \
18  --lb-name app-lb \
19  -n http-probe \
20  --protocol Http \
21  --port 80 \
22  --path /
23
24az network lb rule create \
25  -g net-rg \
26  --lb-name app-lb \
27  -n web-rule \
28  --protocol Tcp \
29  --frontend-ip app-fe \
30  --frontend-port 80 \
31  --backend-pool-name web-pool \
32  --backend-port 80 \
33  --probe http-probe

What to notice:

• the DNS record maps the hostname to the frontend IP the client will target
• the load balancer still needs a healthy backend pool and a matching rule
• a correct frontend IP with a failing probe still leads to a broken application path

Load-balancer troubleshooting order

When Azure Load Balancer questions get noisy, use a fixed order:

1. Check whether the client resolved the expected hostname to the expected IP.
2. Confirm whether the scenario needed a public or internal frontend.
3. Check that the backend resource is actually in the correct backend pool.
4. Inspect the health probe protocol, port, and path.
5. Review the load-balancing rule and confirm the frontend and backend ports match the workload.
6. Only then look deeper at NSGs, guest firewalls, or the application itself.

That sequence is simple, but it prevents a common AZ-104 failure mode: debugging the backend application before proving that DNS and the load-balancer path are even pointing at it.

Quiz

Move next into Monitoring & Recovery, where these network and compute choices start surfacing in logs, alerts, and failover plans.