A storage client may resolve a public address despite having an approved private endpoint, while a load-balancer frontend can be reachable even when health probes mark every backend unhealthy. The first problem concerns DNS resolution; the second concerns health and reachability. Microsoft AZ-104 networking tasks require separating those boundaries before changing traffic rules.
Public and private DNS zones serve different audiences
Azure DNS can host public DNS records for an internet-visible domain, while Azure Private DNS zones provide name resolution inside linked virtual networks. Both use DNS naming concepts, but publishing a record in a private zone does not automatically make it visible to arbitrary internet clients. Administrators should document which resolver a client uses and what answer it expects.
A public CNAME may point a custom application domain to a supported service hostname, whereas a private zone may map a service name to a private IP address. The service must still be configured to accept the intended hostname, and a certificate must match that host where TLS is used. A DNS record alone does not grant application authentication or bypass network restrictions.
Name resolution should be tested from the affected vantage point. The administrator’s laptop, an Azure VM, a peered VNet and an on-premises server may resolve the same name differently because their DNS paths and zone links differ. A successful local lookup is not proof that a remote client follows the same network.
Private endpoints change the path through DNS
A private endpoint gives a supported Azure service a private address in a VNet. Applications generally continue using the service’s normal hostname, while DNS steers the connection toward the private path. Hardcoding a special private-link hostname into every application is usually the wrong response. A robust design aligns private DNS zone records and network links with the original service name.
Check the interaction between NSGs and private endpoints and private DNS-zone links before modifying access rules. A valid endpoint connection cannot help a client that still resolves the public service address.
Private DNS zone links determine which virtual networks can resolve zone records through Azure-provided DNS. When name resolution must cross on-premises boundaries or a more complex network topology, a private resolver or a carefully managed forwarding design may be needed. The exact chain should be documented rather than assumed from peering connectivity alone.
The service endpoint, identity and DNS path must all be correct. In private-endpoint security, a storage client can have valid RBAC and a correct subnet route yet fail because the name resolves publicly. Do not respond by disabling the storage firewall: compare the expected private address with the actual resolution and fix the relevant DNS or network link.
Understand what Azure Load Balancer actually balances
Azure Load Balancer operates at the transport layer to distribute inbound TCP or UDP traffic to eligible backend instances according to rules and health. A public load balancer exposes a public frontend address; an internal load balancer has a private frontend for traffic within suitable networks. It does not, by itself, rewrite application URLs or interpret HTTP paths the way an application-layer gateway can.
Frontend IP configuration, backend pools, load-balancing rules and health probes must work together. A frontend can exist while every backend fails its probe, yielding a service that appears provisioned but cannot handle requests. Build the network drawing with destination ports, probe source and effective security rules before testing a client connection.
SKU language requires a current-status check. Basic Load Balancer was retired on September 30, 2025; new design discussions should focus on supported Standard capabilities rather than presenting Basic and Standard as two current procurement choices. Gateway Load Balancer addresses a different network-virtual-appliance scenario and is not an automatic upgrade for a normal app backend.
A health probe defines who can receive traffic
A backend that fails its configured health probe may be removed from normal load-balanced traffic even while the VM itself is running. A probe should test a signal relevant to the application’s readiness, not merely an operating-system process that can survive while every important dependency is unavailable. Misaligned health checks are a frequent source of unnecessary outages or traffic directed to unhealthy instances.
Investigate backend health before changing NSG rules. Confirm the probe port and protocol, backend service listener and any route or security policy that may block health signals. In a VM scale set, confirm instance registration and application startup timing as well. An autoscaled instance is not useful merely because Azure has allocated it.
Plan VM availability and scale sets alongside a verified load-balancer health probe; additional instances cannot compensate for an invalid traffic path. Adding several virtual machines behind a broken probe yields more resources, not higher availability. Establish one working backend and a valid probe before scaling the fleet.
DNS failures and route failures look alike from a browser
A browser timing out after a DNS lookup suggests a different fault from a hostname that cannot be resolved at all. Test DNS resolution first, then the target address and transport path, then the expected service listener and authentication. DNS diagnostics should reveal which resolver answered and whether the result is a public or private target.
VNets and user-defined routes establish where packets travel after a hostname resolves. Compare the actual address, effective route and permitted traffic before concluding that name resolution or the load balancer is the cause.
Azure Network Watcher and connection monitoring can help confirm routes, next hop, NSG reachability and observed connectivity. If a path is blocked, use the effective route and security rules of the actual source and destination interfaces. The tool discussion in Azure Monitor and Network Watcher complements DNS inspection with evidence about the network segment that actually failed.
A working DNS lookup does not establish that the intended application is secure or healthy. The IP may be correct while an NSG blocks the port, the load balancer has no healthy backends or the application denies a caller. Keep layer-specific observations instead of describing all these outcomes as an unreachable name.
Make application releases account for name changes
A custom hostname move can involve DNS records, certificate bindings, backend changes and client caches. Plan a transitional period where both old and new routes can serve expected traffic if the platform supports it. A last-minute record change without testing the new endpoint can strand clients whose resolvers are using different cached answers.
App Service deployment slots can help promote a tested build while retaining a stable public hostname, but an application release is still affected by DNS and TLS configuration. Similarly, a private DNS zone change can alter access to storage or databases used by several services. Treat infrastructure name changes as production releases with ownership and rollback, not as innocuous record edits.
For a load-balancing change, verify backend health, the right frontend IP and post-change telemetry. If an application-layer requirement demands host/path routing, application firewall inspection or TLS termination, determine whether a different Azure service is needed rather than forcing a transport-layer load balancer to handle a feature it does not provide.
Build an evidence-first troubleshooting exercise
A useful lab starts with two VMs in separate subnets behind a Standard internal load balancer. Configure a meaningful health probe and verify traffic reaches healthy instances. Then deliberately block the probe and observe how backend health changes. This isolates the effect of probe configuration from application availability and from basic VNet routing.
Next, configure a private DNS zone and test name resolution from a linked VNet and an unlinked client. Add a correctly approved network relationship, then compare the expected and observed answers. This shows why a peering path and a DNS zone link answer different questions. Record the role of resolver configuration before changing firewall rules.
The AZ-104 objective is not to remember a menu click for every DNS record or load-balancing rule. It is to identify where the request failed and select the control that actually owns that failure. Naming, routing, security, load-balancer health and application readiness are distinct operational dimensions that work only when designed together.
Differentiate transport and application-layer balancing
When an application needs traffic distributed by TCP or UDP port and backend health, Azure Load Balancer is a natural candidate. A requirement to route /api to one service and /checkout to another based on HTTP paths is different: it requires an application-aware component such as an appropriately configured Application Gateway or another supported layer-seven service. Choosing a transport load balancer for an HTTP path-routing requirement will not be fixed by changing NSG rules.
Global DNS-based traffic steering answers a different question from distributing TCP or UDP connections across backends in a virtual network. Document where a client chooses the destination, where transport connections terminate, and where application requests are interpreted. That distinction prevents a team from selecting a Layer 4 load balancer when its requirement is application-layer path routing.