Hands-on practice is particularly valuable for AZ-700 because the exam is role-based and expects implementation plus troubleshooting. A cost-controlled sandbox can cover addressing, peering, DNS, VPN, private endpoints, NSGs, application delivery and monitoring. The current AZ-700 blueprint should define the lab boundary so you practice the technologies the exam actually measures.
Lab one: build two VNets and a deliberate address plan
Create two disposable VNets with non-overlapping address spaces and subnets reserved for workloads or network services. Document the design before deployment.
Then create a conflicting address plan on paper to explain why peering or hybrid expansion would fail.
Lab two: peer VNets and inspect effective routes
Configure VNet peering, verify connectivity and inspect routes. Change one peering option or UDR to create a safe failure.
Use a VNet-peering workflow to prove the path before modifying security rules.
Lab three: implement private DNS and name resolution
Create a private DNS zone, link it to a VNet and test name resolution from an authorized test VM. If possible, model DNS Private Resolver for hybrid resolution.
Break a record or link and observe how DNS failure differs from routing failure.
Lab four: practice Network Watcher troubleshooting
Use Network Watcher connection troubleshooting, IP flow verification or other supported diagnostics on a benign lab connection. Record source, destination, expected path and result.
A Network Watcher lab is valuable because it turns abstract connectivity into evidence.
Lab five: build site-to-site or point-to-site VPN safely
Use Microsoft training labs or a controlled Azure environment to create a VPN gateway where cost permits. Record gateway SKU, tunnel type, authentication, local network definition and routing.
If full deployment is too expensive, use an architecture/configuration tabletop and focus on dependency order.
Lab six: compare load-balancing services
Configure a simple Azure Load Balancer with health probe/backends, then compare with Application Gateway and Traffic Manager/Front Door through labs or documentation.
An Azure Load Balancer exercise should show why Layer 4 health and distribution differ from Layer 7 routing or DNS/edge-based services.
Lab seven: create a private endpoint
Create a supported storage or other test service plus private endpoint, verify the private IP and inspect private DNS behavior. Compare access before and after the endpoint/DNS setup.
Then write how service endpoints differ without changing the service to a private-IP endpoint model.
Lab eight: build NSG policy and inspect flow evidence
Create an NSG, attach it to a subnet or NIC and add a narrow test rule. Verify expected traffic and inspect flow/diagnostic evidence where available.
A network-security-group lab should preserve remote-management access so you do not lock yourself out of the test VM.
Lab nine: model Azure Firewall and WAF separately
Use training labs or architecture diagrams to configure/compare Azure Firewall rules and WAF policy on Application Gateway or Front Door. Generate only benign test traffic.
The key is observing which control blocks network/application traffic and which log proves it.
Lab ten: run a blind connectivity incident
Have another person or a saved template introduce one harmless fault: bad UDR, NSG deny, DNS record error, unhealthy backend or missing private-DNS link. Start from the symptom and collect evidence before changing anything.
Add an IP-addressing design lab before deployment. Calculate several non-overlapping CIDR ranges, reserve growth and identify subnet requirements for gateway, firewall, Application Gateway and private endpoints. Then document why each subnet exists. Networking labs are more valuable when the address plan has an explicit rationale.
Add a public IP prefix/NAT Gateway tabletop or deployment if cost allows. Attach NAT Gateway to a test subnet and observe outbound source address behavior. Compare with assigning a public IP directly to a VM and with Load Balancer outbound rules.
Add a UDR/service-chaining lab. Route one test subnet through an authorized NVA or Azure Firewall and inspect the effective route/next hop. Then remove or alter the route and confirm the observed path changes. Keep a known-good route table for recovery.
Add a forced-tunneling scenario where default traffic goes through on-premises or a security appliance. Document which route wins and what happens to service connectivity. This is best practiced in a disposable environment because incorrect default routes can disconnect management access.
Add an Azure Virtual Network Manager review if your lab subscription supports it. Group VNets and inspect connectivity configuration conceptually. If deployment is unavailable, create a diagram showing how a central manager can impose connectivity intent across several VNets.
Add a Route Server tabletop with BGP. Draw Azure Route Server, two NVAs and learned routes. Explain which prefixes are advertised and what happens if one NVA withdraws a route. The exercise is enough to understand dynamic-routing purpose without building expensive appliances.
Add a high-availability site-to-site VPN design. Use two on-premises peers and active-active Azure gateway conceptually or in a vendor lab. Simulate one path failure and verify route/tunnel status. High availability should be validated with traffic, not only tunnel indicators.
Add a point-to-site lab using a supported authentication method in an authorized tenant. Test one successful client, then break the certificate/RADIUS/Entra dependency deliberately. Capture client-side and gateway evidence so authentication and routing failures remain distinct.
Add an ExpressRoute architecture lab on paper. Draw provider edge, circuit, private peering, gateway and VNet, then add Microsoft peering or Global Reach as separate optional functions. Include BGP route advertisement and BFD so troubleshooting has clear evidence points.
Add a Virtual WAN design with two branches, two VNets and one virtual hub. Route traffic through the hub and add a third-party NVA conceptually. Compare this with a manually managed hub-spoke design and write when the managed transit model becomes valuable.
Add a Traffic Manager lab using two simple endpoints if available. Observe DNS-based endpoint selection and health. Compare the client path with Azure Load Balancer so you can explain why Traffic Manager is not inline packet forwarding.
Add an Application Gateway lab with two backends. Configure listener, backend pool, health probe and routing rule. Break the health path and use backend-health diagnostics. Then restore it without changing unrelated network controls.
Add a Front Door tabletop or low-cost lab. Define two origins, TLS, routing and caching behavior; then show how a private origin can be protected through Private Link. Note which parts occur at the global edge versus in the origin region.
Add a service-endpoint lab or diagram next to the private-endpoint lab. Observe that the service still uses a public endpoint model while access can be restricted to selected virtual networks/subnets. Write the DNS and routing differences side by side.
Add an NSG plus Bastion remote-administration design. Allow management through Bastion without opening broad public RDP/SSH access from the internet. Use IP flow verification or effective rules to prove why the path is allowed.
Add Azure Firewall rules in a lab only if budget permits; otherwise use Microsoft training labs. Configure a narrow network/application rule and one benign DNAT scenario. Inspect logs so you can identify the rule collection and translation responsible for a session.
Add WAF detection-mode practice. Generate harmless requests that match a test or managed rule if the lab supports it, review logs and then discuss prevention mode. The objective is learning evidence and policy behavior without attacking real sites.
Add DDoS and Defender for Cloud review. Inspect where DDoS protection and network-security recommendations surface. These controls are part of the current blueprint even though they may not require a large configuration lab.
Add one blind incident where a private endpoint works from one VNet but not on-premises. Check name resolution, hybrid route, NSG/firewall, endpoint approval and service configuration in that order. This integrates Private Link, DNS, connectivity and security.
Finish with cost cleanup. VPN gateways, firewalls, Application Gateway, Front Door or other networking services can incur charges even when idle. Delete disposable resources after labs and keep architecture diagrams/screenshots rather than leaving expensive environments running purely for study.
Add a DNS Private Resolver tabletop if building the service is expensive. Draw on-premises DNS, Azure VNets, private zones, resolver endpoints and forwarding rules. Trace one query in each direction and identify where a bad link or rule would break resolution.
Add an effective-route comparison before and after peering/gateway transit. Capture the route table from a test NIC, enable the connectivity option, and compare learned routes. This makes Azure’s system routes and propagated routes much easier to interpret under exam pressure.
Add a NAT Gateway observation by sending outbound traffic from two private test instances and confirming the shared public egress identity. Then explain why inbound unsolicited connections still do not magically arrive at those instances. Outbound SNAT and inbound publishing are separate behaviors.
Add a gateway-transit scenario. Use a hub VNet with a VPN gateway and a peered spoke that needs on-premises access. Configure or diagram gateway transit/remote gateway settings and inspect the routing implications. This is a common cross-domain design pattern.
Add a Virtual Network Manager centralized-connectivity exercise if licensing/permissions allow. Put several VNets into a group and define hub-spoke or mesh intent. If you cannot deploy it, compare the intended outcome with manually creating each peering so you understand the operational benefit.
Add a Network Watcher packet-capture or topology observation only on your own lab resources. Compare packet capture with connection troubleshooting and effective routes: one shows packets, another tests reachability, and another explains routing state. Choose the least invasive evidence source that answers the question.
Add one Azure Monitor for Networks dashboard review. Identify which resources or health signals it summarizes and compare it with raw Network Watcher tools. Central dashboards help prioritize where to investigate; detailed diagnostics explain the individual path.
Add one private-link hybrid case where on-premises DNS initially resolves the public service name. Fix the DNS path and then confirm private routing. Save before/after outputs because this demonstrates a realistic dependency better than a perfect first deployment.
Add one Gateway Load Balancer architecture diagram with a third-party NVA. Trace traffic through the appliance chain without changing application frontend design. This service can be harder to remember because it solves appliance insertion rather than ordinary application load distribution.
Add one secure-hub Virtual WAN diagram using Firewall Manager. Show spokes/branches entering the hub, firewall enforcement and route propagation. Compare this with an NVA in a self-managed hub VNet so you understand what Azure manages for you.
The AZ-700 lab mindset should always end with cleanup, known-good state and a short troubleshooting note. Professional network engineering depends on repeatable evidence, not lucky configuration changes.