AZ-700 focuses on designing and implementing Azure network infrastructure that works under real constraints: hybrid connectivity, multiple address spaces, private access, application delivery, security and monitoring. Microsoft's July 27, 2026 blueprint identifies core networking, connectivity services, application delivery, private service access and network security as major domains. Candidates should think in terms of end-to-end paths and failure domains. A network engineer cannot diagnose a blocked application by listing every Azure networking product. They must establish where traffic is supposed to go, which controls determine that path, and how the resulting behavior is observed.

Address planning is a decision with long consequences

Virtual network and subnet design affect routing, peering, hybrid connectivity and later expansion. Address spaces that overlap with on-premises networks can complicate connectivity even when each isolated deployment initially works. Subnet sizing should account for platform-reserved addresses, growth, private endpoints and service-specific delegation requirements. Public and private IPs, prefixes, NAT and gateway subnets each have distinct functions. A good design reserves appropriate room for operations without allocating huge ranges simply because the initial environment seems small.

Suppose a company connects two acquired businesses to Azure. Each has reused the same private IP range, and several workloads already depend on those addresses. Peering or ExpressRoute cannot fix overlapping routing by declaration. Engineers must plan translation, readdressing or segmentation with clear ownership and migration steps. Designing the Azure network foundation is meaningful because it explains why topology and address governance should be settled before deploying hundreds of applications. IP planning is not paperwork; it protects future connectivity choices.

DNS is often the missing part of private connectivity

A service can be reachable by IP but fail by name, or resolve publicly when the design expects a private endpoint. DNS zones, forwarding, private DNS integration and hybrid resolver behavior are therefore core operational topics. Understand which service names applications use and where those names are resolved. Changing a network security group cannot repair a resolver returning the wrong address. Likewise, a healthy private endpoint connection does not mean every client sees the private record from its DNS context.

An application deployed in a spoke VNet might resolve a storage endpoint differently from a workstation connected through a corporate VPN. Trace each resolver chain before changing routes or firewall settings. Test the requested protocol to the resolved destination rather than relying on name lookup alone. Understanding private endpoints, DNS and service access connects these layers and helps separate name-resolution failures from blocked private routes. AZ-700 expects the candidate to reason about both network path and naming behavior, because many serious hybrid outages arise when those two views disagree.

Choose hybrid connectivity for the right failure model

Site-to-site VPN, ExpressRoute, Virtual WAN and network gateways provide different tradeoffs in connectivity, operational control, cost and resiliency. A VPN over the public internet has different availability characteristics from private connectivity services. ExpressRoute's private circuit does not automatically make every application highly available. Route advertisement, gateway capacity, redundancy, policy and DNS still matter. A hybrid design should include how traffic changes during failure and how engineers detect when the preferred path stops carrying traffic.

For an enterprise connecting headquarters, branches and cloud regions, sketch the normal and failover paths. Identify which routes are learned, which are preferred and where asymmetric paths might appear. A firewall may observe only one direction of a session if routing is misaligned, causing sporadic failures that look like application defects. Connecting Azure across boundaries helps frame the choices. In the exam, avoid assuming one connectivity product is universally superior; the correct recommendation depends on constraints and a tested path under degraded conditions.

Application delivery needs layer-aware decisions

Azure Load Balancer, Application Gateway, Front Door and Traffic Manager handle different routing and traffic-management needs. Layer 4 and layer 7 decisions differ in the information available for directing a request. Global entry points, regional reverse proxies, health probes, TLS termination and web application firewall requirements influence the choice. A design should also explain how a backend is judged healthy and what happens to existing client sessions during failover. A green probe on one endpoint may not establish the health of the whole business transaction.

Imagine an international ecommerce platform with regional APIs. Global routing must consider latency, regional failure and data locality, while the regional application gateway manages path-based routing and backend service health. A probe checking only the homepage could route users to a region where checkout is broken. Design health checks to reflect critical application dependencies. Routing application traffic reliably highlights these choices, and AZ-305 provides the broader architecture context for selecting a delivery topology aligned with business objectives.

Private access must include identity and authorization

Private Link and private endpoints help reach supported Azure services through private addressing, while service endpoints and other network access mechanisms follow different models. An endpoint protects a connectivity path; it does not decide whether a user may read confidential data. Network engineers should coordinate with resource owners on authentication, data-plane permissions and outbound dependencies. Removing public access too early can break automation, monitoring or external integrations that were not documented in a topology diagram.

Consider a data pipeline using Azure SQL and storage. Restricting both services to private endpoints may improve control but only if workers, build agents and recovery systems can resolve and reach the new addresses. Test each execution context separately. A permission failure may occur after connectivity succeeds; distinguish it from a timeout or DNS error. Private architecture should be explicit about the identities allowed to operate the service and the network paths those identities use. The right goal is constrained access with known dependencies, not a configuration screen showing public access disabled.

Security controls occupy different layers

Network security groups, Azure Firewall, web application firewalls, DDoS protections and application-layer authorization should not be treated as substitute products. An NSG rule can filter traffic but cannot determine whether an HTTP request exploits a web vulnerability. A WAF can inspect web requests but does not remove the need for restrictive backend access. The network design should combine controls based on threat scenarios without adding multiple redundant filters that nobody can operate or debug.

A public service may require DDoS protections at ingress, WAF rules for web attacks, private backend access and egress restrictions for sensitive workloads. Document which team owns each rule set and how changes are reviewed. When a legitimate request is blocked, log evidence should identify whether DNS, routing, NSG, firewall or WAF policy caused the failure. Network security and visibility links protection with troubleshooting. Secure networking is strongest when the allowed path is predictable and a denied path produces understandable evidence.

Troubleshoot from the packet path outward

Azure Network Watcher and related diagnostic services can help inspect effective routes, packet captures, connection testing and traffic behavior. But tools are only useful if the engineer forms a plausible hypothesis. Start with scope: which clients, protocols, times and destinations fail? Verify DNS, source address, route selection, effective security rules, gateway state and service authorization in a deliberate sequence. Distinguish an inability to establish TCP from an HTTP error returned by a reachable backend.

For an intermittent connection between a VM and a storage service, correlate route and firewall changes with the failure window, then examine whether clients use different resolvers or outbound addresses. Performance symptoms may require latency and packet-loss investigation rather than a binary allow-or-deny check. Make a single controlled change and test the exact failed transaction. A network engineer's responsibility is to restore correct behavior with a traceable cause, not to issue several firewall exceptions and stop asking questions when the next test happens to pass.

Another useful scenario is asymmetric traffic after a hybrid routing change. One direction of a connection takes a private circuit, while return traffic follows a VPN path that crosses a stateful firewall without the original session context. Both routing tables may appear individually plausible, yet the transaction fails intermittently or only for some clients. Diagnose the path from both sides and compare route preference, advertised prefixes and security inspection points. A packet capture on a single host is helpful but not always sufficient. The conclusion must account for both forward and return behavior and for the effects of future failover. This kind of reasoning separates network engineering from checking whether two subnets appear in the same virtual network diagram.

Prove the design with failure drills

Create a small hub-and-spoke environment with private DNS, a private service endpoint and a load-balanced application. Measure connectivity in steady state, then introduce one fault at a time: incorrect name resolution, overlapping routes, an unexpected NSG rule or an unhealthy backend. Record the effective route and the observed application outcome. Repeat with a hybrid connection and document how route preference and redundancy should work. This creates a causal model of Azure networking rather than a memory of portal workflows.

The AZ-104 administrator needs to deploy and manage many of these controls; AZ-700 examines their network-specific design interactions. Study the official current objectives and keep a table of which service solves each defined path problem. The most defensible answer is a topology with explicit ingress, egress, name resolution, security and failure behavior. If those cannot be explained, the network is not yet designed, however polished its architecture diagram looks.