AZ-700 in 2026: Learn Azure Networking by Following the Traffic

AZ-700 becomes much easier to study when Azure networking is treated as a traffic-path problem instead of a catalog of products. A packet has to leave a source, resolve a destination, follow a route, cross the right security boundary, reach the right frontend or private endpoint, and return successfully. Every major exam domain changes one part of that journey.

Microsoft’s current blueprint, effective July 27, 2026, covers core network infrastructure, connectivity services, application delivery, private access to Azure services, and network security. The AZ-700 exam tests whether you can choose and combine those controls under requirements involving reachability, resiliency, latency, scale, security, and troubleshooting. Within the broader set of Microsoft certifications, its working vocabulary is more specialized than a general Azure administrator’s: candidates need to reason about IP addressing, name resolution, routing, VPNs, ExpressRoute, Virtual WAN, load balancing, private connectivity, firewalls, web application protection, and diagnostics as parts of one network.

Build the path from addressing, DNS, and routing

Every Azure network design begins with address space. Subnets are not just containers for resources; they become boundaries for route tables, network security groups, gateways, private endpoints, delegated platform services, Azure Bastion, Application Gateway, and other services with specific placement requirements. Poor address planning can turn a simple peering or hybrid-connectivity requirement into a redesign because overlapping ranges cannot be wished away later.

A useful foundation is to understand VNets, subnets, routing, peering, and gateways as one connected system. VNet peering creates reachability, but it does not make every route or gateway transit relationship automatic. User-defined routes can override expected paths. Forced tunneling can send traffic through inspection. Azure Route Server can exchange routes with network virtual appliances. NAT Gateway changes outbound translation without becoming an inbound access mechanism.

Name resolution belongs in that same mental model. The current AZ-700 objectives include public and private DNS zones, VNet DNS configuration, private-zone links, and Azure DNS Private Resolver. If an application resolves a public address when the design expects a private endpoint, the routing table may be perfectly correct and the application can still use the wrong path. Understanding DNS and NAT behavior makes those failures easier to diagnose because you stop treating resolution and translation as unrelated background services.

When practicing, draw the path before touching the portal. Write the source IP, destination name, expected DNS answer, effective route, next hop, security controls, and return path. Then compare the drawing with Azure’s effective routes and diagnostic tools. This habit exposes mistakes faster than repeatedly changing settings until a connection starts working.

Hybrid connectivity is a routing decision before it is a tunnel decision

Site-to-site VPN, point-to-site VPN, ExpressRoute, and Virtual WAN all connect environments, but they solve different operating problems. A site-to-site VPN can provide encrypted connectivity over the internet. Point-to-site VPN serves individual clients and introduces authentication choices such as certificates, RADIUS, or Microsoft Entra ID. ExpressRoute provides private connectivity through a provider model and adds its own peering, SKU, resiliency, and route-advertisement decisions. Virtual WAN centralizes large-scale branch, VPN, ExpressRoute, and virtual-hub connectivity.

The exam becomes more predictable when you ask what the route should do during both normal operation and failure. Which prefixes are advertised? Which path is preferred? Is there a redundant gateway? Does BGP learn the intended routes? Is traffic expected to stay on a private connection, fail over to VPN, or pass through a security appliance? ExpressRoute features such as Global Reach, FastPath, Direct, private peering, Microsoft peering, and Bidirectional Forwarding Detection matter because they change the answer to those questions.

Hybrid scenarios are also where weak fundamentals show up. A tunnel can be established while the application remains unreachable because the wrong prefix was advertised, DNS points somewhere else, or asymmetric routing sends the return traffic through another device. Do not stop troubleshooting when a gateway reports “connected.” Verify the end-to-end path.

Application delivery is about choosing where traffic should be steered

Azure has several services that can distribute or steer traffic, and AZ-700 expects candidates to distinguish them by layer, scope, and requirement. Azure Load Balancer works at Layer 4 for TCP and UDP. Application Gateway provides regional Layer 7 routing for web traffic and can integrate with Web Application Firewall. Azure Front Door provides a global entry point for HTTP/S traffic, acceleration, routing, caching, and origin protection. Traffic Manager makes DNS-based routing decisions. Gateway Load Balancer inserts network virtual appliances into traffic flows.

Instead of memorizing a comparison table, start with the application. Is the traffic HTTP/S or arbitrary TCP/UDP? Is the decision regional or global? Must routing inspect a path or hostname? Is TLS terminated at the service? Is caching useful? Does the design need a private origin? Does an NVA need to inspect flows? The broader mechanics of load balancers, DNS, and edge delivery make the Azure-specific choices much easier to reason through.

The current objectives also require practical Application Gateway and Front Door details: backend pools or origins, health probes, listeners, routing rules, HTTP settings, TLS, rewrite rules, caching, traffic acceleration, URL redirection, and Private Link to a Front Door origin. The exam may describe the symptom from a user’s perspective. Your job is to decide which layer owns the problem.

Private access and security have to agree with the route

Private Endpoints and Private Link are easy to describe and surprisingly easy to misconfigure. A private endpoint places a private IP in a VNet for access to a supported service, but the client still needs to resolve the service name to that private address. That is why private DNS is part of the design rather than an optional finishing step.

Service endpoints solve a different problem. They extend the identity of a VNet subnet to a supported Azure service while the service still uses its public endpoint. Private endpoints give the consumer a private IP path. The exam can ask which model fits a security or connectivity requirement, so the distinction should be understood from the packet’s point of view rather than memorized as “private endpoint is more private.”

For hybrid environments, add another question: how will on-premises clients resolve the private name? The answer may involve Azure DNS Private Resolver, forwarding rules, private DNS zones, or existing DNS infrastructure. A design is incomplete if the private endpoint exists but the client still receives a public DNS answer.

AZ-700 covers network security groups, application security groups, Azure Firewall, Firewall Manager, secure Virtual WAN hubs, Web Application Firewall, DDoS protection, Azure Bastion, and network-security recommendations from Defender for Cloud. Those controls operate at different points in the architecture, so stacking them without a purpose can make troubleshooting harder without improving the threat model.

Network security groups are the basic traffic-filtering boundary for subnets and interfaces. Application security groups can make rules easier to express around logical workloads. Azure Firewall adds centralized network and application filtering, NAT, policy management, and threat-intelligence capabilities. WAF protects HTTP/S applications from web-layer attacks when associated with Application Gateway or Front Door.

Study security as a set of intentional boundaries. Which flows should exist? Which should be denied? Where should inspection happen? Is remote administration supposed to use Azure Bastion rather than public management ports? Should internet-bound spoke traffic be forced through a central firewall? If an NSG, firewall policy, route table, and WAF all exist, know which one can actually block the described flow.

Monitoring is how you prove the design matches the diagram

The current blueprint includes Azure Network Watcher, Azure Monitor for Networks, DDoS monitoring, virtual network flow logs, IP-flow verification, and Defender for Cloud network recommendations. These are not secondary “operations” topics. They are how a network engineer validates the real state of a software-defined network.

When a connection fails, collect evidence in a fixed order. Confirm DNS resolution. Check effective routes and the expected next hop. Verify NSG and firewall decisions. Confirm the target service is healthy and listening. Review flow or diagnostic data. If the problem is hybrid, check learned and advertised routes on both sides. This method turns troubleshooting from a service-name guessing game into a path analysis.

Monitoring also matters before a failure. Flow logs and network metrics can reveal unexpected paths, packet drops, growing throughput, or dependencies that were not obvious in the original design. Network architecture is not finished when resources deploy successfully; it has to remain observable as routes, applications, and security policies change.

Practice by changing one requirement at a time

A strong AZ-700 lab does not need to recreate an entire enterprise. Start with two VNets, subnets, a few test workloads, and working name resolution. Add peering and prove the route. Insert a user-defined route. Add a NAT Gateway and inspect outbound behavior. Create a private endpoint and deliberately break its DNS. Put a load balancer in front of a workload. Add an NSG rule that blocks the path and use diagnostics to find it.

Then expand the scenario. Connect an on-premises simulation with VPN. Introduce a second region. Compare a regional Application Gateway with a global Front Door design. Route traffic through Azure Firewall. Build a WAF policy. Test what changes when the origin becomes private. Once the traffic-path model is clear, combine these tasks into AZ-700 core networking scenarios that force several controls to interact instead of testing one service at a time.

Use the exam domains as a completeness check after you can reason through these scenarios, not as five isolated study buckets. The current blueprint gives the largest single share to core networking infrastructure, but a real question can cross DNS, routing, private access, application delivery, and security in one design. That overlap is precisely what makes hands-on troubleshooting valuable.

Readiness for AZ-700 is visible when you can narrate a connection from source to destination and explain every decision that affects it. You should be able to say how the name resolves, which route wins, what gateway or delivery service sees the flow, where security is enforced, how private access changes the path, and which telemetry proves the result. Once that becomes natural, the Azure product names stop feeling like separate facts and start behaving like parts of one network.