Microsoft AZ-700: Private Connectivity and DNS

Private connectivity in Azure is rarely only a networking problem. A private endpoint can have the correct private IP address and still fail because DNS resolves the public endpoint, an on-premises resolver cannot reach the private zone path, a UDR sends traffic through the wrong appliance, or a firewall blocks the return flow. AZ-700 treats private access and name resolution as connected design responsibilities, so troubleshooting should follow both the packet path and the DNS path.

The current July 27, 2026 AZ-700 outline includes private endpoints, Private Link services, service endpoints, private DNS zones, VNet links, Azure DNS Private Resolver, and on-premises integration. Microsoft AZ-700 tests how those components work together in network designs, while the Microsoft Azure certifications show where the networking role sits among adjacent Azure responsibilities.

Private Endpoint changes the service path, not just the IP address

An Azure private endpoint places a network interface with a private IP in a VNet for access to a supported service through Azure Private Link. Clients should reach that private address rather than the service’s public endpoint. The design decision includes which subnet hosts the endpoint, who can reach it, which service resource it maps to, and how DNS makes clients choose it.

Because the endpoint is an object in the consumer VNet, address planning, network security, routing, and operational ownership matter. A team that creates private endpoints without a naming and subnet strategy can quickly accumulate opaque interfaces that are difficult to troubleshoot. Treat them as first-class network dependencies with owners and lifecycle records.

DNS is the steering mechanism for most private-endpoint clients

Applications normally connect by hostname, so successful private access depends on the name resolving to the endpoint’s private address. Azure private DNS zones are commonly linked to VNets so cloud clients receive the correct answer. If the zone is missing, linked to the wrong VNet, or populated incorrectly, traffic may continue toward the public endpoint even though a private endpoint exists.

Private Link architecture covers the broader pattern. In AZ-700 scenarios, trace which resolver answers, which zone contains the record, which VNets are linked, and whether the returned address is reachable from the requesting network.

Azure DNS Private Resolver connects cloud and on-premises name resolution

Hybrid environments often need on-premises clients to resolve Azure private-zone records and Azure workloads to resolve on-premises names. Azure DNS Private Resolver provides inbound and outbound endpoints plus rulesets to bridge these paths without deploying custom DNS forwarder VMs for every scenario.

Design still matters. Inbound and outbound endpoints require appropriate subnets, rulesets must be linked correctly, forwarding targets must be reachable, and on-premises DNS must send the relevant zones to the resolver. A DNS query can fail even while VPN or ExpressRoute connectivity is healthy because forwarding policy is wrong. Test name resolution independently from general network reachability.

Private DNS zones should reflect service ownership and namespace boundaries

Centralizing every private zone in one subscription can simplify governance, but it also creates dependency and delegation questions. Application teams may need records while a platform networking team owns links and resolver policy. Decentralizing without standards can create duplicate zones and inconsistent answers. The right model depends on the operating organization.

Use naming standards, controlled zone creation, documented VNet links, and change processes that prevent teams from creating competing private zones for the same namespace. When troubleshooting, list all zones with the relevant suffix and verify which one the client can actually query. Duplicate or shadowed namespaces can be more confusing than missing records.

Service endpoints solve a different problem

Service endpoints extend a VNet identity to supported Azure services while the service still uses its public endpoint. They can be appropriate when private IP exposure is not required and the service firewall can restrict access to selected VNets. Private endpoints instead expose a private address into the VNet and are generally the stronger isolation model for private service access.

AZ-700 candidates should compare the traffic and DNS implications rather than memorize that one feature is always “more secure.” Consider service support, on-premises access, network topology, policy requirements, cost, operational complexity, and whether public network access must be disabled.

Routing and security appliances can break an otherwise correct design

A private endpoint resolves to an IP in a VNet, but the client still needs a valid route to that address. Hub-and-spoke designs, UDRs, NVAs, Azure Firewall, Virtual WAN, and on-premises routes can change the path. If inspection is required, the chosen path must be supported and symmetric enough for the service flow.

Azure networking design patterns show how routing, failure domains, and recovery behavior interact. For a specific private-access failure, compare the effective route at the client, peering or hub propagation, NVA/firewall policy, and the endpoint subnet. A correct DNS answer only proves where the client tried to go.

On-premises access needs both route advertisement and DNS delegation

Hybrid clients typically reach private endpoints through VPN or ExpressRoute, but the tunnel is only one dependency. The on-premises network must learn routes to the relevant VNet address space, and its DNS infrastructure must resolve the Azure private hostname to the private address. If either half is missing, users may report the same symptom: “the private endpoint does not work.”

Document the end-to-end path: client subnet, on-premises resolver, forwarding rule, Azure resolver or DNS path, private record, WAN connection, Azure route, firewall inspection, and endpoint. This makes changes safer because each team knows which layer it owns.

Public fallback can hide private-access failures

If public network access remains enabled, a client with incorrect DNS may still reach the service over the public endpoint. That can make testing look successful while violating the intended architecture. Conversely, disabling public access before private DNS and hybrid routing are complete can create a widespread outage.

Migration should therefore be staged. Validate private resolution from each important network, confirm the packet path, test application authentication, monitor logs, and only then tighten public exposure according to policy. Record expected failure behavior so teams know whether a public-path success is actually a defect.

Troubleshoot with paired DNS and packet tests

A reliable sequence is: resolve the hostname; identify the answering resolver; confirm the expected private IP; test reachability or connection to that IP; inspect effective routes and security controls; verify endpoint and service approval state; then check application authentication. If name resolution is wrong, fix DNS before changing routes. If the name is right but packets do not arrive, move to routing and firewall evidence.

Private endpoint and DNS troubleshooting exposes the operational failure modes behind those design choices. AZ-700 adds the design perspective: make the DNS architecture, ownership model, routing path, and fallback behavior explicit before deployment so the same class of fault does not recur.

Large Azure estates should avoid reinventing private connectivity for every application. Platform teams can standardize endpoint subnets, private-zone ownership, resolver rules, hub connectivity, monitoring, approval workflows, and patterns for disabling public access. Application teams then consume a known service rather than building ad hoc networking.

This is the architectural outcome AZ-700 is trying to develop: not merely the ability to create a private endpoint, but the judgment to connect private IP delivery, DNS resolution, hybrid connectivity, routing, and security into one supportable system. A design is complete when clients resolve the right name, take the intended path, meet access policy, and can be diagnosed with clear evidence when something changes.

Private-access monitoring should be designed before the first outage. Useful signals include private endpoint provisioning state, DNS query failures, resolver health, effective routes, firewall logs, connection metrics, and service-side diagnostics. Synthetic tests from representative VNets and on-premises networks can detect broken resolution or routing even when no user has opened a ticket. Monitoring should distinguish public and private endpoints so a public fallback cannot mask a broken private path.

Cross-subscription and cross-tenant ownership can also complicate troubleshooting. The application team may own the PaaS resource, a network platform team may own the VNet and resolver, a security team may own the firewall, and a central DNS team may own on-premises forwarding. The design should identify who approves endpoint connections, who creates records and links, who owns route/firewall changes, and who can see logs across those boundaries. Without that map, incidents stall while teams prove which layer is not theirs.

Migration and deletion deserve equal care. Removing a private endpoint can leave stale DNS records or application configuration; recreating one may assign a different private IP. Infrastructure-as-code and lifecycle processes should therefore manage endpoint, DNS, and policy objects together where practical. A private-connectivity design is supportable when creation, validation, change, and retirement all preserve the relationship between hostname, private address, route, and access policy.

Document the expected DNS suffix, resolver hop, private IP, route, and security boundary for each important service. That small dependency record often shortens outages because the responder can compare intended and observed paths instead of rediscovering the architecture under pressure.

Platform standards should include a tested rollback path for endpoint, DNS, and routing changes so private-access failures can be reversed without reopening public exposure unnecessarily.

Azure DNS Private Resolver troubleshooting should follow the query path end to end. Identify the client’s configured DNS server, the zone it is asking about, any conditional-forwarding rule, the inbound or outbound resolver endpoint involved, the linked virtual network, and the route or firewall path between on-premises and Azure. Confirm that the private DNS zone is linked to the VNet where resolution is expected and that a public record is not masking the intended private answer. Test resolution from each relevant network segment because a query that works inside one VNet can still fail across peering, VPN, ExpressRoute, or a custom DNS chain. Name resolution and private IP reachability must both succeed.