AZ-700: Designing Resilient Azure Networks

AZ-700 evaluates the decisions involved in designing, implementing, monitoring, and securing networking in Microsoft Azure. Its July 27, 2026 skills outline spans core networking, hybrid connectivity, application delivery, private access to Azure services, and security. The role is more demanding than memorizing which portal menu creates a virtual network: a network engineer must understand the effect of addressing, routing, name resolution, traffic inspection, and service availability on an application's actual behavior. The Azure Network Engineer Associate certification remains an active path as of October 2026. Its strongest preparation combines architecture diagrams with connectivity tests, change recovery, and evidence-based troubleshooting rather than treating Azure services as isolated features.

Plan virtual networks before assigning addresses

Address design has a long operational life. When a company connects multiple subscriptions, remote offices, and perhaps another cloud, overlapping prefixes can prevent clean route exchange or require inconvenient translation. A virtual network therefore needs an address plan sized for plausible growth, with space for platform-reserved addresses and separate tiers or workloads. Subnets are more than organizational labels: they establish attachment points for resources, network security groups, route tables, and delegated services. Network peering connects virtual networks but does not automatically establish transitive connectivity between every peered network. Engineers should record which networks need direct connections, which use a hub, and which must remain isolated for policy reasons.

A design review should trace a packet rather than count subnets. Suppose a private web application reaches a database in another spoke network. The engineer needs to know how DNS returns the address, whether the peering flags permit traffic, which route is most specific, and whether a security rule blocks the flow. Virtual network peering design becomes especially relevant when organizations assume peering supplies firewalling or routing that it does not. A diagram showing internet ingress, spoke-to-spoke communication, on-premises prefixes, and inspection points is more useful than a flat list of Azure resource names.

Make route selection and transit explicit

Azure system routes handle many ordinary cases, but custom user-defined routes change the next hop for selected destinations. A route to a virtual appliance is effective only when the appliance can forward traffic and the return path supports the same flow. Asymmetric routing can make a stateful firewall reject responses even when outbound requests appear to depart correctly. Route tables, peering options, virtual network gateway propagation, and effective-route inspection must be considered together. A default route sending everything through inspection may achieve centralized policy but can also break platform service access if required exceptions are missing. The candidate should know how to diagnose the path rather than defaulting to more permissive rules.

Hub-and-spoke layouts concentrate common services and connectivity, but their appeal should not hide cost or fault-domain considerations. A single inspection hub can simplify management while becoming an important availability dependency. A multi-region design needs a deliberate decision about whether application traffic fails over with state, whether routing converges as expected, and how shared security policy is deployed to each region. Hub-and-spoke networking is a natural architectural complement to AZ-700 because topology design determines what a network engineer must operate. Operational tests should include hub unavailability, route withdrawal, and restoration—not only normal-day pings.

Connect branches and data centers without assuming equivalence

A site-to-site VPN encrypts traffic over public infrastructure and can provide a practical hybrid connection, while ExpressRoute offers private connectivity through a provider ecosystem. They differ in commercial arrangements, service characteristics, routing behavior, and deployment prerequisites. Neither should be described as a universal guarantee of low latency or unlimited bandwidth. BGP plays a role in learning and advertising prefixes in many hybrid configurations; engineers must understand how prefix filters, path preferences, and failover arrangements affect traffic. A branch migration should not advertise a large summary that unintentionally attracts routes for networks the branch cannot reach.

Consider a company moving one application's database to Azure while retaining an on-premises identity system. The migration team should identify dependencies on domain controllers, DNS forwarders, certificate services, and outbound third-party connections. It then needs to confirm that a route exists both to the cloud and back, that necessary ports are allowed, and that application timeouts accommodate network latency. Hybrid connectivity to Azure helps explain why this is an architecture decision, not merely a gateway wizard. During a staged rollout, monitoring should reveal whether the application unexpectedly falls back to a slow or expensive path.

Solve name resolution alongside private access

Private endpoints expose supported services through addresses in a private virtual network. The endpoint is useful only when workloads resolve the service name correctly and the service's access policies permit the intended clients. Split-horizon DNS, private DNS zones, resolvers, on-premises forwarding, and overlapping naming conventions can create failures that resemble security denials. A well-designed private endpoint deployment documents the public and private answers expected from each network location. DNS records should be checked from the actual consuming subnet, not just from an administrator's laptop on a different resolver path.

Service endpoints and private endpoints solve different problems. A service endpoint can extend virtual network identity to a supported public service endpoint, whereas Private Link provides a private address path to a specific supported service. Decisions should account for cost, operational overhead, region support, access controls, and how clients reach the service. The engineer should also distinguish public network access settings from name resolution: an application resolving the correct private address does not by itself prove that direct public access has been disabled. Security-focused readers can extend this topic through private endpoints and private DNS.

Select application delivery services by protocol and behavior

Load balancing starts with a clear understanding of the traffic. Azure Load Balancer operates at transport-layer scenarios, while Application Gateway supports web-aware routing, TLS termination, health probing, and web application firewall integration. Azure Front Door addresses globally distributed application entry and acceleration patterns, with its own security and routing capabilities. Selecting a service from the word “load balancer” alone can produce an unsuitable design. A database protocol may need transport-level distribution, while an HTTP application may require host-based routes, path rewriting, session behavior, or inspection. Health probes must report meaningful application readiness rather than the mere ability to open a TCP port.

Availability decisions are also shaped by zones and regions. A backend pool spread across availability zones may endure a zone failure, but application state, database dependencies, and traffic-manager behavior must also survive. Sticky sessions can conceal application state-management problems until a backend disappears. A good engineer tests what happens when an instance becomes unhealthy, when a certificate expires, and when one region stops accepting traffic. Azure Load Balancer and Application Gateway provide practical context for readers evaluating these roles without equating all delivery services.

Apply segmentation and network security coherently

Network security groups apply rules at defined scopes, Azure Firewall can centralize inspection, and web application firewalls protect against selected HTTP-layer threats. These controls solve related but distinct problems. A permissive subnet rule may negate careful application-layer design; an overbroad deny rule may interrupt platform health checks; a web application firewall cannot prevent every abusive authenticated request. AZ-700 asks engineers to understand placement, effective-rule processing, next-hop selection, and how packet evidence confirms expected behavior. It is unsafe to infer that a request is denied simply because a particular portal screen displays a blocking rule when another path bypasses that scope.

Private exposure often shifts risk rather than removes it. A compromised workload inside the virtual network may still reach neighbors unless lateral movement is restricted. Engineers should segment by trust level, adopt least privilege for service access, and evaluate the path through network virtual appliances. Central inspection must be tested for symmetrical return traffic. Security changes should have a rollback plan that does not rely on the failing path itself; retaining a safe administrative recovery channel is an operational control, not a convenience. Where appropriate, Azure Policy can help prevent resources from being created without required network safeguards.

Troubleshoot from symptoms to the correct layer

A reliable diagnostic sequence begins with the exact source and destination, the service name used, the observed error, and a timestamp. DNS lookup answers whether the correct address was chosen; effective routes show the next hop; network watcher capabilities and connection tests can help distinguish route and security failures; application logs reveal whether traffic reached the workload. Metrics and flow evidence should be interpreted with health probes and connection reuse in mind. A public-facing endpoint that appears healthy from one geography may still fail for clients whose path encounters a regional edge, an expired certificate, or a stale DNS record.

For final preparation, build a small hub-and-spoke lab with an inspected egress path, one private service endpoint, a hybrid connectivity design on paper, and a web workload behind application-aware routing. Deliberately introduce a DNS error, an invalid route, and an overrestrictive network security group, then explain how the observed symptoms differ. Record expected and actual flows before changing rules. The practical skill AZ-700 rewards is not rapid clicking but the ability to choose, prove, and maintain a network path whose resilience and security remain intelligible to the next engineer.

An additional useful diagnostic is to compare intended packet symmetry against actual connection state at every middlebox. A client may establish a TCP session through one firewall instance while replies return through another that has not observed the initial handshake. The apparent symptom is intermittent application failure, especially after failover or route changes. Examining effective routes on both endpoints, health of next-hop appliances, and whether NAT is applied at the expected point often isolates the cause more quickly than adding new network security group exceptions. A design that explicitly documents stateful inspection, failover routing, and the required return path is easier to secure and troubleshoot than one relying on implicit platform behavior.