Private Endpoints and DNS Troubleshooting for Microsoft AZ-104

An Azure private endpoint can be fully provisioned and approved while an application still connects to the public endpoint or fails with NXDOMAIN. That is why private-endpoint troubleshooting should begin with name resolution rather than with random network changes. The application normally continues to use the service’s standard fully qualified domain name; DNS is what directs that name to the private endpoint’s IP from the correct network context.

The live Microsoft AZ-104 exam expects administrators to configure and troubleshoot virtual networking. For private connectivity, the useful mental model is service FQDN → private-link DNS mapping → private IP → network path → service authorization. Private Link and private endpoint architecture ties those layers together; when the path breaks, an administrator should diagnose them in that order instead of changing several controls at once.

Confirm what the client actually resolves before changing the network

Start from the failing client or from a host in the same DNS and routing context. Resolve the service FQDN with nslookup, dig, Resolve-DnsName, or an equivalent tool. Record the resulting IP and any CNAME chain. The answer should ultimately lead to the private endpoint’s private IP when private access is intended.

If the name resolves to the public service IP, the problem is usually DNS integration rather than an NSG or route blocking the private endpoint. If it returns NXDOMAIN, the private zone may be intercepting the namespace without the required record. If it resolves correctly to the private IP, move to network-path testing.

This order prevents wasted effort. An NSG change cannot make a public DNS answer become a private address, and a correct private address does not prove that TCP connectivity or service authorization is healthy.

Verify the private endpoint resource and connection state

Check that the private endpoint exists in the expected virtual network and subnet, has completed provisioning, has the expected private IP, and shows an approved connection state on the target service. A pending or rejected connection is a control-plane problem that blocks data access regardless of DNS quality.

The endpoint’s network interface contains the private IP and FQDN information used by the DNS configuration. Compare those values with what the client resolved. If the endpoint was re-created, migrated, or changed, stale DNS data can point at an address that no longer represents the current endpoint.

Also verify the correct subresource or group ID where the Azure service uses multiple private-link subresources. A technically healthy endpoint to the wrong subresource does not satisfy the application’s dependency.

Private DNS zones must use the service-specific namespace and reach the client VNet

Azure services use specific `privatelink.*` private DNS zones. The zone must contain the appropriate record for the private endpoint and must be reachable from the client’s DNS path. In a simple Azure-only design, that often means linking the private DNS zone to the virtual network from which clients query Azure DNS.

A missing VNet link is one of the most common causes of a service name continuing to resolve publicly. A missing or stale A record can produce NXDOMAIN or an incorrect private IP. Zone groups associated with the private endpoint can automate record management, but administrators still need to verify that the relationship exists and matches the intended zone.

Do not invent private DNS zone names. Use the zone documented for the Azure service because the public-to-private CNAME behavior depends on the correct namespace.

Hub-and-spoke and peered networks make DNS reachability a design problem

Peering provides network connectivity, but private DNS visibility depends on how the zones and resolvers are connected. A spoke that can route to a private endpoint still needs a DNS path capable of resolving the service name to that endpoint. Linking a zone only to the endpoint VNet does not automatically solve every hub-and-spoke name-resolution pattern.

Centralized private DNS can be effective when ownership is clear and all required VNets can use the central resolution path. The design should avoid a collection of overlapping zones managed independently by teams that do not understand one another’s records.

Cloud networking fundamentals clarify the routing and peering relationships around the private endpoint, but failures should still be diagnosed from the specific FQDN and client path rather than from a generic network diagram.

Hybrid DNS requires deliberate forwarding between on-premises and Azure

On-premises clients cannot query Azure’s internal resolver directly as though it were an ordinary public DNS service. Hybrid designs typically use Azure DNS Private Resolver or a DNS forwarder architecture so on-premises DNS servers can conditionally forward the relevant Azure private namespaces into Azure.

If an on-premises client resolves the public IP while an Azure VM resolves the private IP, compare their resolver paths. Check conditional forwarders, inbound resolver endpoints or DNS forwarder VMs, private-zone links, and whether the query suffix matches the intended rule.

A healthy VPN or ExpressRoute connection proves transport reachability, not private DNS correctness. Conversely, correct DNS does not prove the hybrid route and firewall path. Test each layer separately.

NXDOMAIN can be caused by over-broad private DNS interception

A private DNS zone can override an entire namespace. If the zone is linked to a VNet but does not contain a record for another resource that clients still need to reach publicly, those queries can return NXDOMAIN instead of falling back automatically to the public answer. Microsoft specifically cautions against private-zone designs that unintentionally override active public namespaces.

This failure can be confusing because adding the private zone appears to “break” resources unrelated to the endpoint that motivated the change. The solution is to use the recommended service-specific private-link zone and appropriate forwarding behavior rather than creating arbitrary shadow zones.

When troubleshooting, compare a failing FQDN with a known-good FQDN in the same service family and inspect which DNS zone is authoritative for each response.

Once DNS is correct, test routing, NSGs, UDRs, and the service firewall

If the FQDN resolves to the private endpoint IP, test the required TCP port from the actual client path. Network Watcher connection troubleshoot, Test-NetConnection, or service-specific diagnostics can help separate routing from application failure.

Private endpoint subnet policies and surrounding NSGs or user-defined routes can affect the path when those controls are enabled. In enterprise designs, traffic may intentionally traverse inspection appliances. Check that the forward and return paths are valid and that the security rules allow the expected source, destination, and port.

Also distinguish network access from service authorization. Reaching the endpoint does not grant data-plane permission. A storage account, database, or Key Vault can accept the network path and still deny the caller because identity or service-level permissions are wrong.

Public network access should match the intended security posture

A private endpoint does not automatically mean the public endpoint is unusable. Many Azure services allow private connectivity while public network access remains enabled unless the administrator disables or restricts it. If the security objective is private-only access, the target service’s public access configuration must reflect that requirement.

This matters in troubleshooting because a client resolving publicly may still connect successfully when public access is enabled, masking a broken private DNS design. The application appears healthy while the intended network boundary is not actually being used.

Private Link and private endpoint security adds the exposure and authorization controls around that network path. For AZ-104, focus on proving which path the client uses and whether that path matches the administrator’s design intent.

Use a fixed diagnostic order so each test eliminates a class of causes

A strong troubleshooting sequence is: resolve the FQDN, verify endpoint state and IP, verify the private DNS zone and record, verify the client’s zone link or forwarding path, test TCP connectivity, inspect routing and security controls, then test service authentication and authorization. Record the result at each step before changing configuration.

That sequence also makes rollback safer. If the first failing test is a missing VNet link, there is no reason to change an NSG. If DNS and TCP both work but the service returns authorization errors, avoid dismantling the network path.

The AZ-104 skill is not memorizing every private-link zone name. It is understanding how name resolution, private addressing, routing, and service access fit together well enough to isolate the broken layer quickly.

For troubleshooting practice, record every test from the client’s point of view: queried FQDN, resolver used, returned CNAME and IP, endpoint state, expected private IP, TCP result, and service response. That small evidence table prevents teams from discussing “DNS” or “the network” as vague causes. It also makes escalation much faster because the next engineer can see exactly which layer has already been proven healthy and which boundary is still unverified.

Caching deserves attention during DNS changes. A corrected private-zone record or forwarding rule may not immediately change the answer seen by every client if an operating system, local resolver, DNS proxy, or upstream server still holds an earlier response. Record TTL behavior and flush caches only after proving the authoritative configuration is now correct. Clearing caches before fixing the source can create the illusion of progress while the bad answer simply returns again.