AZ-700 study should follow network dependency order. Start with addressing, DNS and VNet routing; then hybrid connectivity; add application delivery and private access; finish with security and observability; then mix the domains in troubleshooting cases. This sequence matches the current AZ-700 role better than jumping between unrelated Azure services.
Phase one: master IP planning and subnet requirements
Create several VNet address plans, including subnets for gateways, Application Gateway, Azure Firewall, Bastion and private endpoints. Practice avoiding overlap and leaving room for growth.
Add public IP prefixes and BYOIP concepts only after ordinary addressing feels natural.
Phase two: build DNS and basic VNet connectivity
Configure or model public/private DNS zones, private-zone links and DNS Private Resolver. Then implement VNet peering and inspect effective routes.
A VNet peering exercise should include one routing or DNS problem so you learn evidence, not only successful creation.
Phase three: study UDRs, service chaining and outbound design
Create route tables, forced-tunneling scenarios and an NVA/firewall path. Add Azure Route Server and NAT Gateway concepts where they solve dynamic routing or scalable outbound needs.
Use route tables and next-hop reasoning before changing firewalls when connectivity fails.
Phase four: build VPN and ExpressRoute knowledge
Start with site-to-site VPN, gateway SKUs, IPsec/IKE and redundancy. Add point-to-site tunnel/authentication choices and then ExpressRoute connectivity models, peering, gateways, BFD, encryption and troubleshooting.
Compare internet-based encrypted connectivity with private provider connectivity by requirement.
Phase five: add Virtual WAN for scale
Model hubs, gateways, routing, SKU/scale units and third-party NVA integration. Explain when Virtual WAN simplifies many branches/VNets compared with individually managed gateway topologies.
Do not study it only as another VPN product; understand the hub-and-routing architecture.
Phase six: separate the application-delivery services
Build a table for Load Balancer, Gateway Load Balancer, Traffic Manager, Application Gateway and Front Door: layer, regional/global scope, protocol, health model and use case.
Azure Load Balancer and Traffic Manager are useful anchors because they demonstrate Layer 4 versus DNS-based routing clearly.
Phase seven: learn Private Link, endpoints and DNS together
Create a private endpoint in a lab if possible and observe DNS. Compare with service endpoints and service-endpoint policies.
The study objective should be explaining which service exposure model remains public and which introduces a private IP path.
Phase eight: build network-security controls
Practice NSGs/ASGs, flow logs, IP-flow verification, Bastion and Virtual Network Manager security. Then configure or model Azure Firewall, Firewall Manager and WAF.
A network-security-group exercise should include rule priority and both inbound/outbound reasoning.
Phase nine: make monitoring the default troubleshooting habit
Use Network Watcher, Azure Monitor for Networks, Defender for Cloud recommendations and service diagnostics. Capture known-good routes, DNS results, VPN status and health probes before creating failures.
A Network Watcher workflow can help structure first evidence for reachability or routing incidents.
Finish with multi-domain incidents
Practice cases such as private endpoint resolving publicly, application gateway backend unhealthy, VPN up but route missing, ExpressRoute route advertisement wrong, NSG blocking Bastion, or Front Door origin inaccessible through Private Link.
Keep one reference Azure topology throughout the study sequence: two spoke VNets, a transit/hub VNet, on-premises network, DNS, VPN/ExpressRoute, one web application, a PaaS service with private endpoint and centralized security. Reusing one topology makes cross-domain dependencies visible.
During IP planning, assign address space for future growth and service-specific subnets before deployment. Add GatewaySubnet, firewall, Bastion, Application Gateway and private-endpoint needs. Then deliberately create one overlap and explain which future peering or hybrid connection it would block.
Add public IP prefix and NAT Gateway late in the addressing phase. Compare direct public IPs, load-balancer frontends and centralized subnet outbound SNAT. This prevents all public-address concepts from blending together.
During DNS study, create one public DNS zone and one private zone or use a detailed lab. Link the private zone to the correct VNet, then break the link or record. Observe that IP routing can remain perfect while application access fails by name.
During routing study, capture effective routes before and after adding a UDR. Add a forced-tunnel example and a service-chaining path through an NVA or firewall. Then use next-hop diagnostics rather than guessing which route Azure selected.
Add Route Server as an advanced routing lab or tabletop. Create BGP route-exchange diagrams with two NVAs and compare dynamic propagation with maintaining many UDRs. Focus on where learned routes enter the Azure route decision.
Add Virtual Network Manager after ordinary peering. Build a small network group and connectivity design conceptually. Centralized management makes more sense once you understand the resource-level connections it is automating.
During site-to-site VPN study, document the full chain: gateway SKU, local network gateway, public peer, IKE/IPsec settings, protected networks and routes. Introduce one mismatch and identify the status/log evidence that narrows the failure.
During point-to-site study, compare certificate, RADIUS and Entra authentication plus available tunnel types. Add client-profile distribution and one authentication failure. The focus is user/client dependencies rather than site-routing scale.
During ExpressRoute study, draw physical/provider connectivity, circuit, peering, gateway and VNet. Add BGP route advertisements and then optional features such as Global Reach or FastPath. This prevents the service from becoming a list of premium features with no architecture.
During Virtual WAN study, attach several branch VPNs or VNets to a virtual hub diagram. Add hub routing and one NVA. Compare operational complexity with manually building a large hub-and-spoke estate.
During application delivery, use one web application and implement or model each service around it. Load Balancer handles transport-level distribution, Application Gateway handles regional HTTP/S, Front Door provides global edge routing, Traffic Manager makes DNS decisions and Gateway Load Balancer inserts appliances.
During Application Gateway practice, create an unhealthy backend by changing a probe path or port in a lab. Use backend-health evidence before changing DNS or NSGs. This trains symptom-to-layer reasoning.
During Front Door study, configure or model origins, routing and TLS, then protect an origin through Private Link conceptually. Add caching only where the application content supports it. Global delivery should be tied to user/location requirements.
During private access, build a private endpoint to a supported PaaS service and inspect DNS. Then compare with service endpoints in the same scenario. The goal is to explain the different service exposure models, not just complete two portal wizards.
During NSG study, inspect effective security rules rather than only one NSG definition. Add subnet and NIC rules, ASGs and flow diagnostics. Rule priority and stateful behavior are easier to understand after you test a permitted and denied session.
During Azure Firewall study, configure or model network, application and DNAT behavior and place the firewall in the transit path. Compare centralized policy with distributed NSGs. Add Firewall Manager only after ordinary firewall policy is clear.
During WAF study, use Application Gateway or Front Door in detection mode with harmless test traffic. Observe rule matches and false positives, then discuss when prevention is appropriate. Web-layer security should be tuned before relying on automatic blocking.
Use monitoring continuously rather than at the end. Save effective routes, DNS results, VPN status, health probes, flow evidence and topology diagrams for known-good state. Troubleshooting becomes much faster when you can compare a failure with baseline evidence.
In the final week, practice “which layer changed?” scenarios. A DNS change, route change, NSG rule, gateway advertisement, probe failure and private-endpoint record can all produce “cannot connect,” but each requires different first evidence. Layer classification is the central AZ-700 exam skill.
Add one IP-prefix/BYOIP session after basic addressing. Explain when predictable public ranges matter for allowlists, migrations or outbound identity, and compare Azure-assigned prefixes with bringing owned address space. Keep the focus on design requirement rather than enrollment paperwork.
Add one DNS Private Resolver design where on-premises clients need to resolve Azure private endpoints and Azure workloads need selected on-premises names. Draw inbound/outbound endpoint concepts and forwarding rules at a high level. Hybrid DNS is a frequent source of “network is up, app is down.”
Add one NAT Gateway exercise or architecture comparison. Decide whether the workload needs scalable deterministic outbound SNAT, direct public IPs or firewall-mediated egress. Then note that NAT Gateway is not an inbound publishing service.
Add one Bastion scenario during security study. Compare opening RDP/SSH to the internet with using Bastion plus private VM addressing. This is a good example of reducing public attack surface while preserving administrative reach.
Add one Firewall Manager/Virtual WAN security design. Place Azure Firewall in a secured virtual hub and apply centralized policy. Compare with a standalone firewall VNet so the role of managed hub security becomes clear.
Add one WAF false-positive exercise in detection mode. Review which managed rule matched, identify whether the request is benign, and decide whether to tune/exclude or move to prevention. This teaches why Layer 7 security needs observation before aggressive enforcement.
Add one health-probe troubleshooting drill for both Load Balancer and Application Gateway. Change a probe path or port and identify the difference between endpoint reachability and application-health evaluation. Many “load balancer” incidents are really probe or backend configuration problems.
Add one Front Door origin-security review. Compare public origins with Private Link origin access, TLS termination versus end-to-end TLS, and cacheable versus dynamic content. This helps separate global edge behavior from ordinary regional application-gateway design.
Add one Defender for Cloud network-review session near the end. Inspect or study Secure Score, attack paths and Cloud Security Explorer results and map each recommendation to the underlying Azure networking control that would remediate it. This connects security analysis with implementation.
Before the exam, rebuild the five domain weights and one troubleshooting example for each. Core networking and connectivity together account for roughly half the blueprint, but application delivery, private access and security are substantial enough that a pure routing specialist will still have major gaps.
The AZ-700 study approach should end with design and troubleshooting fluency. The current role expects engineers to identify the responsible layer quickly and choose the Azure service that best satisfies the networking requirement.