{"id":2683,"date":"2026-10-08T18:04:35","date_gmt":"2026-10-08T18:04:35","guid":{"rendered":"https:\/\/www.exam-topics.net\/blog\/?p=2683"},"modified":"2026-10-12T20:47:25","modified_gmt":"2026-10-12T20:47:25","slug":"az-104-dns-peering-and-routing","status":"publish","type":"post","link":"https:\/\/www.exam-topics.net\/blog\/az-104-dns-peering-and-routing\/","title":{"rendered":"Microsoft AZ-104: DNS, Peering, and Routing"},"content":{"rendered":"

Many AZ-104 network questions are really path questions: how does a client discover a destination, how does Azure decide where the packet should go, and what relationship allows two virtual networks to exchange traffic? The current blueprint explicitly includes Azure DNS, virtual network peering, public IP addresses, user-defined routes, and connectivity troubleshooting. The AZ-104 exam<\/a> expects administrators to connect these ideas instead of studying DNS, peering, and routing as isolated features.<\/p>\n

A practical mental model is simple. DNS converts a name into an address. Peering creates private connectivity between virtual networks. Routing chooses the next hop for traffic. Security rules can still permit or block that traffic after the path exists. Keeping those responsibilities distinct makes both exam scenarios and real incidents easier to solve.<\/p>\n

Read DNS questions as name-resolution problems<\/h2>\n

Azure DNS can host DNS domains and record sets, while private DNS capabilities support name resolution for private resources. The important administrative skill is recognizing what must resolve, from where, and to which address. A record that is correct for a public client may be wrong for a workload that should use a private endpoint. Conversely, a private zone that is not associated with the necessary network can leave a client resolving the public address.<\/p>\n

Fundamental record behavior still matters. A, AAAA, CNAME, MX, TXT, and other records serve different purposes, and understanding DNS records<\/a> makes Azure-specific scenarios less mysterious. The exam may not ask you to recite every record type, but it can expect you to know whether a name should resolve directly to an address or through an alias.<\/p>\n

Always distinguish DNS from connectivity. Successful name resolution proves only that the client obtained an address. It does not prove that routing, NSGs, service firewalls, or the destination application will allow the connection.<\/p>\n

Understand authority, caching, and the client\u2019s point of view<\/h2>\n

A name-resolution problem often depends on which DNS server is authoritative for a zone and which resolver the client is actually using. The distinction between authoritative data and recursive lookup behavior is useful when diagnosing why one client sees a different result from another. A deeper explanation of authoritative DNS servers<\/a> can reinforce the hierarchy behind Azure-hosted zones.<\/p>\n

Caching adds another layer. A corrected record may not appear immediately to every client if a previous answer remains cached. In an exam question, the decisive clue is usually the configured zone, record, or network linkage rather than a timing edge case, but operationally the administrator should remember that stale answers can persist.<\/p>\n

For private endpoints<\/a>, DNS deserves special attention because the application should normally continue using the service\u2019s expected name while that name resolves to a private address from the appropriate network. Hard-coding private IP addresses into applications is usually a brittle workaround rather than a clean design.<\/p>\n

Treat peering as a direct relationship<\/h2>\n

Virtual network peering allows private communication between Azure VNets, but it should not be interpreted as \u201call networks can now reach all other networks.\u201d Address spaces must not overlap, and a network that peers with two others does not automatically turn those two networks into peers with each other. This non-transitive behavior is one reason hub-and-spoke designs require deliberate routing decisions.<\/p>\n

When a scenario includes a hub network with shared services, examine whether the spokes need only reach the hub or must also reach one another. If traffic should traverse a firewall or network virtual appliance in the hub, peering alone is not enough; the route design and forwarding behavior must support the intended path.<\/p>\n

Peering also interacts with gateway scenarios and with effective routes. The exam rewards administrators who look at the complete route rather than assuming that a peering object guarantees end-to-end application connectivity.<\/p>\n

Use user-defined routes for intentional next hops<\/h2>\n

Azure system routes handle common traffic paths automatically. A user-defined route becomes important when the organization needs a different next hop, such as steering traffic through a security appliance. The route prefix identifies the destination range, while the next-hop choice determines where matching traffic is sent. This is conceptually close to static routing<\/a>, but Azure evaluates the route in the context of virtual networks, peering, and platform behavior.<\/p>\n

Do not confuse a route table with a firewall. A route can direct traffic to an appliance, but the appliance or another control decides whether to permit the flow. Likewise, an NSG can allow a packet that never arrives because the route points somewhere else. When a question gives you both a security rule and a route table, check both independently.<\/p>\n

The most common design mistake is asymmetry: traffic takes one path outbound and a different path back. Stateful devices can reject that flow even though each individual route seems plausible. Think about the return path whenever a network virtual appliance is introduced.<\/p>\n

Know when routing policy is the real requirement<\/h2>\n

Some network requirements are about choosing one path over another based on organizational policy rather than simply reaching a subnet. Traditional networking distinguishes destination-based routing from more specialized policy decisions. A general explanation of policy-based routing<\/a> can help clarify that distinction, even though AZ-104 focuses specifically on the Azure routing mechanisms named in the blueprint.<\/p>\n

For the exam, stay disciplined: if the objective is to send a destination prefix through an Azure next hop, user-defined routes are central. Do not invent an advanced routing product unless the scenario requires it. If the problem is name resolution, do not answer with a route. If the problem is access control, do not answer with DNS.<\/p>\n

This separation of responsibilities is more valuable than memorizing a long list of routing terms because it tells you which Azure control can actually change the observed behavior.<\/p>\n

Troubleshoot from the symptom back to the layer<\/h2>\n

If a client cannot connect by name, test whether it can resolve the expected address. If the address is wrong, inspect DNS first. If resolution is correct but the connection fails, inspect effective routes and peering. Then inspect NSGs, private-access controls, and the destination service. Azure Network Watcher can help reveal next-hop and connectivity information when the configuration is not obvious.<\/p>\n

When only one subnet is affected, look for a subnet-specific route table, NSG, or DNS configuration. When every network fails to resolve a private service, the private DNS linkage or record is a stronger suspect. When one direction works and the reverse does not, examine asymmetric routing and stateful inspection. Exam questions often become straightforward after you map the symptom to the smallest configuration scope that could cause it.<\/p>\n

Avoid changing multiple controls at once. In production that destroys diagnostic evidence; on the exam it usually leads to selecting an overbroad answer.<\/p>\n

Build a packet-path habit for AZ-104<\/h2>\n

For every networking scenario, narrate the packet journey in order: resolve the name, identify the destination address, check whether the source network has a route, determine whether peering or another connection exists, evaluate security rules, and confirm that the service is reachable on the requested port. This makes DNS, peering, and routing one coherent troubleshooting process.<\/p>\n

Other Microsoft certifications<\/a> emphasize architecture, security, or specialist networking; AZ-104 concentrates on operating resources and diagnosing day-to-day failures. You are expected to configure and troubleshoot the controls an Azure administrator actually touches.<\/p>\n

Once you can explain why DNS is not routing, why peering is not transitive connectivity, and why a route is not a firewall rule, the networking questions stop feeling like a collection of overlapping Azure features. They become a sequence of testable decisions.<\/p>\n

Private DNS becomes critical with private service access<\/h2>\n

Private endpoints make DNS design especially important because the application should normally continue to use the service\u2019s familiar host name while resolution changes to a private address from approved networks. If clients resolve the public endpoint instead, traffic may bypass the intended private path or fail after public access is disabled. The network can be perfectly routed and still appear broken because the name points to the wrong destination.<\/p>\n

When several VNets need to use the same private service, consider where name-resolution data is hosted and which networks can query it. Peering provides reachability between networks, but it does not by itself guarantee that every VNet receives the intended private DNS answer. This is a useful example of why connectivity and name resolution must be validated separately.<\/p>\n

A strong troubleshooting test is to compare the name, resolved address, expected route, and actual destination from the affected client. If the name resolves to the expected private address but the connection fails, move to routing and security. If it resolves to an unexpected public address, fix the DNS path before changing the network controls.<\/p>\n

Check the return path before blaming DNS<\/h2>\n

A client can resolve the correct address and send traffic through the expected route while the session still fails because the destination returns traffic through a different path. This becomes especially important when virtual appliances, forced tunneling, or multiple network connections are present. Stateful firewalls expect the flow to be consistent, so asymmetric routing can look like an application or name-resolution problem even when the DNS answer is correct.<\/p>\n

For exam questions, trace both directions. Identify how the request leaves the source subnet, what next hop processes it, and how the destination is expected to reply. That habit prevents you from changing DNS records when the real issue is an incomplete route design.<\/p>\n","protected":false},"excerpt":{"rendered":"

Many AZ-104 network questions are really path questions: how does a client discover a destination, how does Azure decide where the packet should go, and what relationship allows two virtual networks to exchange traffic? The current blueprint explicitly includes Azure DNS, virtual network peering, public IP addresses, user-defined routes, and connectivity troubleshooting. The AZ-104 exam […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10,1],"tags":[],"class_list":["post-2683","post","type-post","status-publish","format-standard","hentry","category-microsoft","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2683","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/comments?post=2683"}],"version-history":[{"count":4,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2683\/revisions"}],"predecessor-version":[{"id":3932,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/posts\/2683\/revisions\/3932"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/media?parent=2683"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/categories?post=2683"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.net\/blog\/wp-json\/wp\/v2\/tags?post=2683"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}