The current AZ-700 blueprint can be mapped as a packet path plus a management path. IP addressing, DNS and routing establish connectivity. VPN, ExpressRoute and Virtual WAN connect locations. Load Balancer, Application Gateway, Traffic Manager and Front Door deliver applications. Private Link and service endpoints control private service access. NSGs, Firewall and WAF enforce security. Network Watcher and Azure Monitor provide evidence across the entire architecture.
The current AZ-700 weights are 25–30% core networking, 20–25% connectivity services, 15–20% application delivery, 10–15% private access and 15–20% network security.
Address space is the foundation of every network decision
VNet and subnet planning determine whether gateways, firewalls, Bastion, Application Gateway, private endpoints and platform-integrated services have room to operate. Overlapping ranges create peering or hybrid-connectivity problems later.
The map should therefore begin with segmentation, address growth and service-specific subnet requirements before adding routes.
DNS is a parallel dependency to routing
Public DNS, private DNS zones and DNS Private Resolver determine whether clients can translate names into the addresses the network path expects. Private endpoints especially depend on correct DNS integration.
A packet cannot reach the intended private service if the client keeps resolving a public endpoint even though the VNet path is healthy.
Routing connects VNets, appliances and outbound paths
VNet peering, UDRs, forced tunneling, gateway transit, Route Server, NAT Gateway and Virtual Network Manager all influence how traffic moves. Service chaining can route traffic through an NVA or firewall, while NAT Gateway handles scalable outbound source translation for supported subnet scenarios.
A peering map becomes much clearer when routes and gateway transit are drawn alongside it.
Hybrid connectivity branches by requirement
Site-to-site VPN uses IPsec over public connectivity, point-to-site supports individual clients, ExpressRoute provides private connectivity through providers/direct models and Virtual WAN centralizes large-scale branch/VPN/ExpressRoute routing around virtual hubs.
The correct service depends on bandwidth, latency, privacy, topology, redundancy and operational scale.
Application delivery sits above connectivity
Azure Load Balancer works at Layer 4, Traffic Manager uses DNS-based traffic routing, Application Gateway provides regional Layer 7 web traffic management and Azure Front Door provides global edge/application delivery. Gateway Load Balancer integrates network virtual appliances into traffic flows.
The map should classify each service by layer, scope and protocol rather than comparing marketing names.
Private service access has two distinct models
Private Endpoint/Private Link places supported service access on private IPs in the consumer VNet, while service endpoints extend VNet identity to selected Azure services through the service’s public endpoint. DNS design is a central dependency for Private Link.
On-premises clients can also reach private endpoints when hybrid routing and name resolution are correctly integrated.
NSGs enforce distributed network policy
NSGs filter traffic at subnet or NIC scope using rules, priorities and service/address criteria. Application Security Groups can group workloads logically, and flow logs plus IP flow verification help explain decisions.
An NSG model belongs close to workload subnets rather than as a centralized perimeter firewall.
Azure Firewall centralizes broader network security
Azure Firewall adds centralized network/application rules, DNAT/SNAT behavior and managed security capabilities, while Firewall Manager can govern policies at scale and secure Virtual WAN hubs.
A DNAT example helps show why centralized firewall policy is distinct from distributed NSG rules.
WAF protects HTTP applications at Layer 7
WAF policies on Application Gateway or Front Door inspect web requests against managed/custom rules and can run in detection or prevention mode. WAF should be placed with application delivery rather than general network filtering.
This separation helps explain why an NSG can allow TCP/443 while WAF still blocks a malicious HTTP request.
Monitoring closes the networking feedback loop
Network Watcher, Azure Monitor for Networks, flow logs, health probes, Defender for Cloud recommendations and service-specific diagnostics tell engineers whether intended design matches observed behavior.
The map should add public IP prefixes and NAT Gateway to the outbound-address branch. Public IP prefixes create predictable public-address pools, while NAT Gateway provides scalable outbound SNAT from private subnets. These are different from public IPs assigned directly to VMs or load-balancer frontends.
Subnet delegation should connect PaaS integration with IP planning. When a service requires delegated or dedicated subnets, the network engineer must reserve address space before deployment. This is why service architecture decisions can have network consequences long before packets flow.
Virtual Network Manager should sit above many VNets as a control layer. Connectivity configurations can create hub-and-spoke or mesh relationships at scale, while security-admin rules can establish centrally managed intent. The underlying resources remain VNets, routes and NSGs, so centralized management does not remove core networking knowledge.
Route Server belongs beside NVAs and BGP. It can exchange routes dynamically with supported network virtual appliances, reducing the need for static UDR maintenance. Candidates should understand when dynamic propagation simplifies a transit design and when manual UDRs are still appropriate.
Forced tunneling should be drawn as a route-policy choice. Internet-bound traffic can be directed through on-premises or security appliances rather than exiting directly from Azure. This affects route tables, gateways, inspection and sometimes PaaS/service connectivity.
Site-to-site VPN should branch into route-based and policy-based concepts, gateway SKU and high-availability choices. A tunnel can be cryptographically established while traffic still fails because routes, local-network definitions or security policies are wrong.
Point-to-site should branch into tunnel type and authentication. Certificate, RADIUS and Entra-based authentication create different client and identity dependencies. The map should keep client access separate from permanent site-to-site connectivity.
ExpressRoute should be mapped with connectivity provider/direct choices, private/Microsoft peering, gateways, route advertisements, Global Reach, FastPath, BFD and encryption. This branch is complex because physical/private connectivity still depends on BGP route exchange and Azure gateway design.
Virtual WAN should sit above many branches and VNets as a managed transit architecture. A virtual hub can host VPN or ExpressRoute gateways, route between connections and integrate with third-party NVAs. Scale units matter because managed gateways still need capacity planning.
Load Balancer should connect directly to backend health and transport-level distribution. A health probe determines whether an instance receives traffic; rules map frontend IP/port to backend pools. Outbound rules or NAT can affect source connectivity separately from inbound distribution.
Traffic Manager should sit at DNS resolution rather than packet forwarding. It chooses an endpoint by DNS policy/health and the client then connects directly. This explains why it differs fundamentally from Load Balancer or Application Gateway, which sit in the data path.
Gateway Load Balancer should be drawn between traffic and an NVA. It allows transparent insertion of supported virtual appliances without making application teams redesign every route manually. Its value is service chaining and scalable appliance integration.
Application Gateway should show listener → rule → backend pool → HTTP settings → health probe. TLS can terminate at the gateway or continue end to end depending on design. WAF can attach here when the application requires web-layer protection.
Front Door should show client → edge → routing rule → origin with optional caching, acceleration and WAF. Private Link can protect the origin path, so a public global edge does not require the origin itself to accept unrestricted public access.
Private Link should connect with DNS and hybrid routing. On-premises clients can reach private endpoints when VPN/ExpressRoute routes and name resolution are correct. This makes private access a cross-domain design, not a standalone checkbox.
Service endpoints should be mapped as subnet identity to supported Azure services while the service retains a public endpoint. Service-endpoint policies can restrict which service resources are allowed. This model is simpler than Private Link in some cases but offers a different exposure model.
NSG flow evidence should connect enforcement to monitoring. Virtual network flow logs and IP flow verification can help explain why a flow is allowed or denied. Engineers should validate effective policy rather than stare at one NSG in isolation.
Azure Firewall should sit on centralized transit paths, while NSGs remain distributed around subnets and NICs. Both can affect the same packet. Troubleshooting should follow the route and evaluate each enforcement point in sequence.
WAF detection versus prevention mode should be visible on the application-security branch. Detection logs matches without blocking; prevention can block based on rules. A candidate should know when to deploy/tune in detection before moving to enforcement.
Defender for Cloud network recommendations should sit in the feedback layer, not the packet path. Secure Score, attack paths and Cloud Security Explorer help engineers identify exposure or risky network relationships, but remediation still occurs through Azure networking/security controls.
Application Security Groups should be drawn beside NSGs because they let rules refer to logical application tiers rather than individual addresses. This reduces rule maintenance as workloads scale or change IPs, while the NSG still provides the actual distributed enforcement point.
Azure Bastion belongs on the secure-administration branch. It provides browser-based RDP/SSH access to supported VMs without requiring each VM to expose a public management port. Bastion does not replace NSGs or identity controls; it changes the remote-management path.
DDoS protection should sit on the availability/security boundary. It addresses volumetric and protocol attacks against public endpoints, while WAF addresses web-application request patterns and Azure Firewall/NSGs enforce different network policies. Similar “security” labels hide different attack layers.
Cloud Security Explorer and attack-path analysis should be shown as security-context discovery. They help identify relationships or paths that could expose resources, but the engineer still remediates through network design, identity, policy or workload changes. They are analytical aids rather than inline packet filters.
Health probes should appear throughout application delivery because backend selection depends on them. Load Balancer and Application Gateway can both exclude unhealthy backends, but their probes operate at different layers/capabilities. A wrong probe can create an outage even when the application is reachable manually.
Route advertisement should connect ExpressRoute and Virtual WAN to on-premises routing. Prefixes learned or announced through BGP influence reachability; one missing or overly broad advertisement can create asymmetric paths or blackholes. Hybrid design is as much about routing policy as physical connectivity.
The map should end with one diagnostic question per layer: Does the name resolve correctly? Is there an effective route? Is hybrid connectivity established? Is the backend healthy? Does the security policy allow it? Is the private-access model correct? Which monitor/log proves the answer? That sequence is an exam-ready troubleshooting framework.
The complete map is address/DNS → route/connectivity → application/private access → security → monitoring/troubleshooting. That end-to-end model is more useful for the current Azure networking role than memorizing one service at a time.