Microsoft AZ-700: Practical Network Engineering Exercises

Microsoft AZ-700 is a design-and-implementation exam, so practical preparation should force you to make network decisions under constraints rather than memorize service definitions. The current July 27, 2026 blueprint covers core network infrastructure, connectivity services, application delivery, private access, and network security. Monitoring and troubleshooting are embedded throughout those responsibilities.

The exercises below use that structure as a working map. Each one begins with a requirement, then asks you to implement, validate, and deliberately break part of the design. That last step matters because strong AZ-700 readiness includes understanding why connectivity works and why it fails.

Exercise 1: design address space before creating resources

Create a fictional organization with several application tiers, shared services, a firewall subnet, gateway requirements, and future growth. Design VNet and subnet address spaces before deploying anything. Include enough unused space to accommodate expansion without forcing overlapping ranges later.

Then introduce a new requirement such as a merger network or a second region. Determine whether your original plan still works. This exercise exposes whether you treat IP addressing as a formality or as an architectural constraint. Add public IP, NAT Gateway, subnet delegation, and service-specific subnet requirements only after the base addressing model is coherent.

Exercise 2: build and troubleshoot name resolution

Create a scenario that uses public DNS, private DNS zones, VNet links, and a private endpoint. Then add an on-premises client that must resolve the private name correctly. Explain which resolver answers each query and where a misconfiguration would appear.

Make private connectivity fail on purpose. Break the private DNS link, remove a record, or send queries to the wrong resolver, then trace the symptom through AZ-700 private connectivity and DNS. Readiness means following a name from client to answer, not merely knowing that Azure Private DNS exists.

Exercise 3: compare peering, VPN, ExpressRoute, and Virtual WAN

Design connectivity for a company with two Azure regions, a headquarters, several branch offices, and a requirement for resilient private connectivity. Decide where VNet peering is sufficient, where VPN is appropriate, and when ExpressRoute or Virtual WAN is justified. Defend the choice using scale, routing, resiliency, cost, and operational complexity.

Then build a smaller topology in a lab and inspect route propagation. Hub-spoke and Virtual WAN design make routing ownership visible when central connectivity is introduced. Add one bad route or gateway setting and diagnose the failure from effective routes rather than guesswork.

Exercise 4: choose the correct application delivery service

Take three workloads: a regional TCP application, a global HTTP application, and a web application that needs layer-7 routing and web application firewall controls. Decide whether Azure Load Balancer, Traffic Manager, Application Gateway, Front Door, or a combination best satisfies each requirement.

Do not choose based on brand familiarity. Compare protocol layer, regional versus global scope, TLS behavior, health probes, routing method, caching, WAF requirements, and origin security. After implementation, fail one backend and confirm how health monitoring changes traffic. This turns application delivery from a memorization topic into an observable system.

Exercise 5: implement private access and prove the DNS path

Create an Azure service that supports private endpoints. Deploy the private endpoint, configure access, and integrate private DNS. Test from a permitted VNet and from a client that should not have private reachability. Then compare that design with a service endpoint so you can explain the difference in addressing and access model.

The private-access domain is only a portion of the exam, but it creates high-value cross-domain scenarios because routing, DNS, security, and hybrid connectivity often meet here. A candidate who can build a private endpoint but cannot explain why an on-premises client resolves the public address is not yet ready.

For the final rehearsal, rebuild one topology on paper without touching Azure. Label the source, destination, DNS dependency, routing decision, security enforcement point, and health signal for every major flow. Then compare the paper design with your lab. Any difference is a useful study gap because it means the implementation contains behavior you cannot yet explain from first principles.

Exercise 6: secure a network without breaking required flows

Build a network security design with NSGs, application security groups, Azure Firewall, and WAF where appropriate. Start from traffic requirements and least privilege, then implement rules. Use flow logs, IP flow verification, and effective security rules to prove that the policy behaves as intended.

Next, deliberately create an overlapping or overly broad rule. Diagnose which rule wins and why. If Azure Firewall is part of the architecture, test route ownership as well as policy logic. Security questions often become difficult because the technically valid control is placed at the wrong layer or the route bypasses it.

Finally, rotate the same architecture through three perspectives: network engineer, security engineer, and application owner. The network engineer cares about reachability and route control, the security engineer cares about inspection and least privilege, and the application owner cares about availability and latency. AZ-700 scenarios often become difficult because several answers solve one perspective while violating another. Practicing the tradeoff makes the correct design requirement-driven.

Exercise 7: monitor before there is an incident

Configure a small monitoring baseline using Network Watcher and Azure Monitor for Networks. Decide which signals would tell you that latency, packet loss, route changes, gateway health, or security posture is degrading. Do not wait for a simulated outage before deciding what evidence you need.

Then generate a failure—bad DNS, wrong route, NSG block, unhealthy backend, or gateway issue—and follow a fixed troubleshooting sequence. Start with scope, then name resolution, routing, security, service health, and application-specific behavior. Repeating that sequence builds the diagnostic discipline AZ-700 scenarios reward.

Exercise 8: run one end-to-end architecture review

Combine the earlier exercises into one design: address space, DNS, hybrid connectivity, application delivery, private endpoints, firewalling, and monitoring. Draw the traffic path for an external user, an on-premises user, and an internal Azure workload. Mark every routing and security boundary.

Finally, change one requirement—regional failure, new compliance boundary, or a need for private-only origin access—and update the design with the fewest justified changes. If you can explain the impact without rebuilding everything, your architecture is coherent. Keep Microsoft AZ-700 as the primary exam target and use current Microsoft documentation whenever a service behavior or SKU detail matters.

Exercise 9: model routing ownership during a failure

Build a topology with a hub, spoke, user-defined routes, and a security appliance or Azure Firewall. Draw the intended path for traffic before you deploy it. Then inspect effective routes from the workload and compare them with your expectation. Add a route that unintentionally bypasses the inspection point or creates asymmetric behavior and diagnose the result.

This exercise is important because many Azure networking failures are not caused by an unavailable service; they are caused by a different component owning the route than the designer assumed. Practice asking which route wins, which next hop receives the packet, whether return traffic follows a compatible path, and whether gateway propagation changes the result. When you can answer those questions from evidence, complex hub-spoke and hybrid scenarios become much easier to reason about.

Exercise 10: perform a requirement-to-service design review

Take a final scenario with branch connectivity, private PaaS access, global web delivery, firewall inspection, DNS integration, and resilience requirements. Before naming Azure services, write the requirements in categories: address and routing, hybrid connection, application delivery, private access, security, and monitoring. Only then select components.

Review the design by challenging every service choice. Why Virtual WAN instead of a smaller hub-spoke design? Why Front Door instead of Traffic Manager? Why a private endpoint instead of a service endpoint? Why Azure Firewall at this point in the path? What will detect failure? If you cannot answer, the component may be cargo-cult architecture. AZ-700 readiness means turning requirements into a defensible network and then proving the packet path, not collecting as many Azure networking services as possible.

Final review: validate the network design against current objectives

For each lab, keep a short packet-capture-style worksheet even when you do not literally capture packets. Record source, destination, resolved name, source and destination IP, expected next hop, security boundary, and the Azure service that should answer. When the design fails, compare the worksheet with the observed path. This forces precise reasoning and exposes hidden assumptions such as “private endpoint means private DNS is automatic” or “peering means all transit works.”

Repeat the end-to-end review with a different failure domain each time. In one run, break routing; in another, break DNS; in another, break a security rule or backend-health condition. Keep the user-visible symptom similar where possible. This teaches you to resist premature conclusions and to ask for the evidence that distinguishes layers. A network engineer who can create a design but cannot isolate faults will still struggle with scenario-heavy AZ-700 questions.

Save only the diagrams and decision notes that help you reason. Large screenshot collections create the illusion of preparation while making review slower. A small topology diagram, the expected packet path, and a list of constraints are usually more valuable than ten portal screenshots. Your final practice material should help you reconstruct why the design works even if the Azure interface changes.