Microsoft AZ-700: Designing and Implementing Azure Networking

Microsoft AZ-700, Designing and Implementing Microsoft Azure Networking Solutions, is the current exam for Azure network engineering. Microsoft updated the English skills outline on July 27, 2026. The exam centers on core network infrastructure, hybrid connectivity, application delivery, private access to Azure services, network security, monitoring, and troubleshooting.

Within the broader Microsoft certification portfolio, AZ-700 sits between general Azure administration and solution architecture. Administrators need networking to operate resources; architects need networking to shape system boundaries; AZ-700 expects deeper ownership of routing, connectivity, traffic delivery, and fault isolation.

That makes hands-on topology work essential. A candidate should be able to start with an application flow—user to front end, front end to service, service to database, on-premises network to Azure—and explain address space, name resolution, route selection, security enforcement, load distribution, private access, and telemetry at every hop.

Address planning is an architectural decision that becomes expensive to undo

Virtual networks and subnets are easy to create, but poor address planning can block peering, hybrid connectivity, growth, and acquisitions. Candidates should understand CIDR, subnet sizing, reserved addresses, address overlap, IP allocation, peering constraints, and the relationship between network boundaries and workload ownership. The goal is to design a scheme that supports both current workloads and predictable expansion.

The AZ-700 core networking infrastructure material is useful for building a hierarchy of regions, hubs, spokes, shared services, and application networks. Start with a fixed private address range and allocate space for three regions plus future growth. Then add a requirement for on-premises connectivity and identify where overlap would break the design.

Name resolution should be tested as part of every connectivity path

Many “network” incidents are actually DNS incidents. Azure DNS, private DNS zones, custom DNS servers, forwarding, hybrid name resolution, and private endpoints can make resolution paths more complex than IP routing alone. Candidates should know which resolver receives a query, which zone is authoritative, and how names are resolved across peered or hybrid networks.

The Azure DNS architecture topic becomes practical when a private service resolves correctly inside one virtual network but not from an on-premises client. Trace the query before changing firewall rules. A good troubleshooting habit separates “name did not resolve” from “name resolved to an unreachable address” and from “the endpoint rejected the connection.”

Hybrid connectivity requires routing knowledge as much as tunnel configuration

Site-to-site VPN, point-to-site VPN, ExpressRoute, and Virtual WAN can connect organizations to Azure, but the real design problem includes route propagation, BGP, redundancy, encryption, bandwidth, failover, and how traffic enters shared inspection or application networks. A tunnel being up does not prove that the correct prefixes are exchanged or that return traffic follows a valid path.

Review VPN design tradeoffs and then build two scenarios: a branch that needs resilient site-to-site access and an administrator who needs remote point-to-site access. Add overlapping address space to one scenario and explain why the problem cannot be solved by simply creating another connection object.

Routing determines where inspection, egress, and return traffic actually occur

System routes, user-defined routes, BGP-learned routes, route priorities, next hops, NAT, and asymmetric paths are common sources of confusion. Candidates should be able to predict a packet’s route from a route table and recognize when a firewall or network virtual appliance changes the expected return path.

Use a hub-and-spoke lab with a firewall in the hub. Force spoke-to-internet traffic through the firewall, then force spoke-to-spoke traffic through it. Break one route intentionally and use effective routes and connection troubleshooting to identify the fault. This is more useful than memorizing route types because the exam often frames routing through a symptom.

Application delivery services should be selected from traffic requirements

Azure Load Balancer, Application Gateway, Front Door, Traffic Manager, and related services operate at different layers and scopes. The load balancing, DNS, and CDN traffic path perspective helps separate global name-based distribution, HTTP-aware proxying, web application firewall capability, regional layer-4 balancing, and content acceleration.

For each service, define whether the application needs TLS termination, path-based routing, private front ends, global failover, client IP preservation, web attack protection, or cross-region acceleration. Then design one public web application and one internal line-of-business service. A product name should emerge from requirements rather than being chosen first.

Private access changes both security posture and DNS behavior

Private Link and private endpoints allow platform services to be reached through private IP addresses, reducing public exposure. Service endpoints solve a different problem and should not be treated as interchangeable. Private-access designs also require careful DNS planning so clients resolve service names to the intended private addresses from every relevant network.

Build a storage or database service with a private endpoint and disable public network access. Test resolution and connectivity from a workload VNet, a peered VNet, and an on-premises network. If one path fails, determine whether the issue is routing, DNS, firewall policy, endpoint approval, or service configuration. That diagnostic separation is central to real Azure networking.

Network security controls should be layered without creating an unreadable rule system

NSGs, Azure Firewall, Web Application Firewall, DDoS Protection, private access, routing, and platform service controls can overlap. The Azure network security group model is a good starting point for subnet and interface filtering, but candidates should know when centralized stateful inspection, application-layer protection, or managed DDoS controls are required.

Create a rule matrix from business flows rather than from ports alone. For each flow, identify source identity or network, destination, protocol, inspection requirement, and logging requirement. Then remove every rule that does not correspond to an intentional flow. This reduces the common operational problem of security policy accumulating exceptions until nobody can explain what is safe to delete.

Monitoring should answer whether the problem is resolution, routing, security, or application health

Network Watcher, connection monitoring, flow data, Azure Monitor, resource health, diagnostics, effective routes, and effective security rules help narrow incidents. A disciplined workflow starts with the symptom and tests each layer. Randomly editing NSGs or routes often hides the original problem and creates new ones.

Practice three failures: DNS returns the wrong address, a route sends traffic to the wrong next hop, and an NSG blocks a required flow. Use evidence to distinguish them. Record the command or portal view that proves each conclusion. Over time, this builds a repeatable troubleshooting method that is more valuable than remembering where a particular diagnostic blade sits.

AZ-700 depth complements AZ-104 administration and AZ-305 architecture

The AZ-104 administrator skill set includes routine virtual networking, while AZ-305 asks architects to choose network patterns within larger solutions. AZ-700 goes deeper into implementing and operating those patterns. Candidates moving from administration should add design and troubleshooting depth; candidates coming from architecture should make sure they can configure and validate what they draw.

A strong capstone is a two-region application connected to an on-premises network. Use a hub-and-spoke or Virtual WAN design, private service access, controlled egress, application delivery, DNS, and monitoring. Then simulate a gateway failure, a bad route, and a private-DNS mistake. If you can trace the expected path before troubleshooting the broken one, you are practicing the network reasoning AZ-700 is built to measure.

ExpressRoute and VPN resiliency should be studied as end-to-end path design rather than as a pair of connection products. Model two on-premises sites, redundant gateways, and a requirement that a single circuit or gateway failure must not isolate production. Decide where BGP learns prefixes, how routes change during failure, and whether inspection remains symmetric after failover. Then compare the operational evidence available when a tunnel is technically established but an application prefix is missing. Connectivity status and usable routing are related, but they are not the same thing.

Egress design is another area where simple labs expose hidden assumptions. Public IPs on individual resources, NAT Gateway, Azure Firewall, and other egress patterns affect source address stability, scale, inspection, and cost. Create a workload that must call an external partner that allow-lists source addresses. Now add autoscaling. A design that depends on unpredictable instance addresses will fail even though outbound internet access works. Stable egress becomes a business requirement, not merely a networking preference.

Private endpoints deserve a second DNS-focused exercise because the data plane can become unreachable even when the endpoint itself is healthy. Start with a platform service that normally resolves to a public address. Add a private endpoint and private DNS zone, then test clients in the local VNet, a peered VNet, and on-premises. If the on-premises resolver still returns the public address, the fix may be conditional forwarding or a resolver design rather than another route. This is the kind of cross-layer failure that distinguishes memorized service knowledge from network engineering.

Finally, build a change-review checklist for production networking. Include address overlap, effective routes, DNS impact, security rules, gateway capacity, application probes, rollback, and expected monitoring signals. Apply it to a proposed subnet or route change. Network incidents often arise from small changes with large blast radius, so the ability to predict downstream effects is part of operating the architecture, not an administrative extra.

IPv4 remains dominant in many Azure labs, but network engineers should also be comfortable recognizing dual-stack and IPv6 requirements where they appear. More broadly, avoid designing from assumptions that are invisible in the diagram: expected client address families, maximum flows, gateway throughput, DNS resolver reachability, and application probe behavior should all be stated. A topology is only as useful as the constraints it communicates. During final review, redraw one design from memory and annotate every traffic path with source, destination, name-resolution method, route decision, security control, and health signal.

When reviewing answers, prefer the design that satisfies the stated traffic, security, resiliency, and operational requirements with the fewest unsupported assumptions. Azure networking questions often offer several technically possible services. The deciding factor is usually a constraint such as layer, scope, private access, global reach, protocol, inspection, or failover behavior.