Microsoft AZ-700 Azure Network Engineer Practical Preparation: Scenarios, Exercises, and Skills to Rehearse

 

AZ-700 practical preparation should make Azure network behavior predictable. Reading the service documentation is necessary, but it does not fully prepare you for questions that combine address design, routing, DNS, gateways, private access, application delivery, and security. The most valuable labs are small enough to understand end to end and deliberate enough to expose dependencies. You should know not only how to create a resource but also what traffic path you expect, what evidence proves the path is correct, and what failure you would create to test your understanding.

The current AZ-700 blueprint covers core networking infrastructure, connectivity services, application delivery, private access, and network security. The exercises below are arranged around those skill families, but they intentionally cross domain boundaries. That is how real networks behave. A private endpoint is partly a private-access feature, partly a DNS problem, partly a routing problem, and partly a security decision. A hub-and-spoke design is topology, routing, segmentation, hybrid connectivity, and operations at the same time.

If you want to establish a baseline first, the AZ-700 readiness matrix can identify which exercises deserve most of your time. The goal here is to turn those weaknesses into repeatable skills.

Build every lab around a prediction, an observation, and an explanation

A portal walkthrough can create false confidence because the interface guides you toward valid settings. Add three requirements to every exercise. Before deploying, predict the traffic path or outcome. After deploying, collect evidence. Then explain any difference between prediction and observation.

For routing, the evidence may be effective routes, next-hop behavior, or a connection test. For DNS, it is the resolved name and address from the client that matters. For security controls, inspect effective rules and flow evidence rather than assuming an NSG is active because it exists. For application delivery, examine health status and backend selection. For hybrid connectivity, understand learned routes and connection state.

Keep a short lab journal with four fields: intended design, expected packet or request path, observed evidence, and failure lesson. This makes hands-on work useful for exam reasoning rather than a collection of screenshots.

Exercise 1: design an address plan before creating any VNet

Create a fictional company with three Azure regions, one on-premises network, and expected growth. Give yourself a private address space large enough for several VNets but intentionally constrain it so careless allocation will create future overlap. Divide the space into regional blocks, hub subnets, workload subnets, gateway subnets, and room for future services.

The exercise is not about finding one perfect CIDR plan. It is about being able to explain the plan. Why are the regional blocks non-overlapping? Which subnets are intentionally isolated? Where will private endpoints live? Which address ranges must be advertised to on-premises? What happens if an acquired network later overlaps one of your Azure ranges?

Then implement a simplified version in Azure. Peer two VNets and confirm that non-overlapping addressing is a prerequisite for the expected model. Add one subnet intended for an application tier and another for management or shared services. The exam skill is the reasoning that precedes resource creation.

Exercise 2: build a simple hub-and-spoke network and trace traffic

Deploy one hub VNet and two spokes. Peer the hub to each spoke and start without transitive assumptions. Test direct spoke-to-hub communication and then reason about spoke-to-spoke behavior. Introduce a network virtual appliance or simulated routing point only if your lab budget and environment allow; the essential objective is to understand that peering does not magically create every transit path you may want.

Add a user-defined route in a spoke and predict which next hop will be selected. Inspect effective routes. If you add an NVA, enable the required forwarding behavior and observe what happens when return traffic does not follow the expected path. This is a useful way to experience asymmetric routing rather than only reading about it.

Finally, draw the final topology from memory and label which component owns transit, filtering, and route propagation. The ability to explain the diagram is more valuable than the deployment itself.

Exercise 3: practice route precedence with a controlled failure

Create a workload subnet with a normal Azure system route. Add a UDR that directs a specific destination toward a different next hop. Before applying it, write down the expected effective route. After applying it, inspect the actual route table on a network interface.

Now introduce a mistake: use an incorrect prefix, disable propagation in a place where learned routes were required, or send traffic toward a next hop that cannot forward. Observe the failure and determine which evidence identifies the problem fastest. The point is to learn a diagnostic order rather than to memorize precedence rules in isolation.

Extend the scenario conceptually to hybrid networking. Imagine the same subnet also learns routes by BGP from a VPN or ExpressRoute connection. Which route should win for a given prefix? What change could accidentally divert traffic? A candidate who can reason through these interactions is much more prepared than one who has only configured a route table once.

Exercise 4: configure NAT Gateway and observe outbound behavior

Deploy two simple workloads in a subnet and associate a NAT Gateway with a public IP or prefix. Confirm that outbound internet connections use the expected source address. Compare this with a workload that has a direct public IP or another outbound method.

The key learning is ownership of outbound connectivity. NAT Gateway provides subnet-level outbound translation and predictable egress addresses without creating unsolicited inbound access. Think about scenarios where a partner allow-lists outbound source IPs or where workloads make large numbers of outbound connections.

Then remove or alter the NAT design and observe how behavior changes. You do not need to simulate massive SNAT exhaustion, but you should understand why source ports matter and why an architecture with many outbound connections requires deliberate egress design.

Exercise 5: create public and private DNS zones and trace queries

Host a simple public DNS record and compare it with a record in an Azure Private DNS zone linked to a VNet. Query from a client inside the linked VNet and from a location without that private-zone visibility. Record which answer is returned and why.

Next, create a second VNet and control whether it is linked to the private zone. This makes the scope of private DNS concrete. If your environment permits, deploy Azure DNS Private Resolver or at least diagram how inbound and outbound endpoints plus rulesets support hybrid resolution.

Your success criterion is not “the name resolved.” It is that you can describe the path of the query: client resolver settings, Azure-provided DNS or custom DNS, forwarding behavior, private zone, and response. DNS questions become easier when you think about the query path rather than about zone names.

Exercise 6: create a private endpoint and make DNS the center of the lab

Choose a supported Azure PaaS service such as Storage and create a private endpoint. Link the appropriate private DNS zone and verify that the service’s normal FQDN resolves to the private IP from the intended VNet. Confirm connectivity, then deliberately break the DNS link or query from a network that lacks the proper resolution path.

Observe the difference between network reachability and name resolution. The private endpoint can be healthy while the client still tries to reach the public endpoint because DNS is wrong. This is one of the most important operational lessons in the AZ-700 scope.

Extend the design on paper to on-premises clients. Where would the DNS query go? How would Azure DNS Private Resolver or a custom DNS solution participate? What conditional forwarding is required? What happens if the public endpoint is disabled but on-premises DNS still returns the public address?

Exercise 7: compare a private endpoint with a service endpoint

Use the same platform-service scenario and reason through two designs. In the private-endpoint design, the service is represented by a private IP in your VNet. In the service-endpoint design, the service remains on its public endpoint architecture, while access can be restricted to selected virtual-network subnets for supported services.

Build one if practical and diagram the other. Record the differences in IP behavior, DNS, on-premises access, service configuration, and use of service endpoint policies where relevant. The purpose is to eliminate the common misconception that the two features are interchangeable.

Create three requirement cards: “must use a private IP,” “must allow selected subnets while retaining public service architecture,” and “must support private access from on-premises through hybrid connectivity.” Choose the stronger fit for each and explain why.

Exercise 8: build a site-to-site VPN in a sandbox or simulate the design rigorously

If you have two environments capable of acting as separate networks, configure a site-to-site VPN with appropriate gateways. If cost or lab limitations make that impractical, use a detailed design exercise with real Azure gateway settings and route expectations.

Understand the objects involved: virtual network gateway, local network gateway, tunnel configuration, shared key or other authentication mechanism, BGP if used, and the routes that become available. Draw both ends and label which address prefixes each side advertises.

Then introduce a mismatch conceptually: wrong shared key, wrong address prefix, incompatible tunnel parameters, or missing route. Decide which symptoms you would expect. Troubleshooting knowledge is stronger when you can predict failure from configuration state.

Exercise 9: compare site-to-site and point-to-site VPN requirements

Create two scenarios. In one, a branch office network requires persistent encrypted connectivity to Azure. In the other, individual remote engineers need client connectivity to Azure resources. Write down why S2S fits the first and P2S fits the second.

For P2S, review supported authentication approaches and client considerations. Think about scale, user identity, certificate or identity-based authentication, and operational management. For S2S, focus on network-to-network connectivity, gateway redundancy, BGP options, and on-premises device compatibility.

The practical skill is selection. If a question says “remote users from unmanaged locations,” that is a different requirement from “connect the branch subnet.” Your lab notes should reinforce the distinction.

Exercise 10: design ExpressRoute from a business requirement, not a product description

You may not be able to provision an ExpressRoute circuit for a study lab, but you can still practice the architecture accurately. Create a scenario requiring private, provider-based connectivity between an enterprise network and Azure. Draw the circuit, provider edge, Azure connection, gateway or relevant connectivity components, and private peering route exchange.

Add requirements one by one. The company wants direct connectivity between two on-premises sites through Microsoft’s network: consider the purpose of Global Reach. The company wants traffic to bypass the virtual network gateway data path where supported to improve performance: understand FastPath conceptually. The company needs additional encryption requirements: review the available options and where encryption is applied. The organization also wants a resilient backup path: design VPN as a secondary option and reason about routing preference.

Do not memorize “ExpressRoute equals private.” Practice explaining what it connects, how routes are exchanged, and what it does not automatically provide.

Exercise 11: model Azure Virtual WAN as a managed transit platform

Create a paper or diagramming lab for an organization with ten branches, several Azure regions, ExpressRoute, site-to-site VPN, and remote users. Compare a self-managed hub-and-spoke architecture with Virtual WAN virtual hubs.

Identify what Virtual WAN centralizes: managed hub infrastructure, VPN and ExpressRoute integration, routing, and supported security or third-party NVA patterns. Then identify what still requires design: regional hub placement, routing intent, connectivity between hubs, branch association, security inspection, and failure behavior.

Your exercise should answer “what operating problem does Virtual WAN reduce?” rather than “what features does it have?” That mindset aligns well with scenario questions.

Exercise 12: configure a Standard Load Balancer and learn health probes

Deploy two simple backend instances serving a basic TCP or HTTP endpoint. Place them behind a Standard Load Balancer. Configure a health probe and verify that both backends receive traffic while healthy.

Now stop the service on one backend without deleting the VM. Observe how the health probe changes backend availability. Deliberately configure the probe to the wrong port or path and watch a healthy application become “unhealthy” from the load balancer’s perspective.

This lab teaches a critical lesson: application delivery depends on health-detection design. A backend can be running but unavailable to the load balancer because the probe does not reflect application health correctly.

Exercise 13: build Application Gateway request flow step by step

If budget permits, deploy Application Gateway with two backend pools or at least two logical paths. Configure listeners, routing rules, health probes, and backend settings. Use path-based routing so `/api` and `/web` reach different destinations.

Observe the request chain: client to frontend, listener, routing rule, backend pool, health status, and response. Add TLS if practical and note where certificates are used. If you enable WAF, keep the security function distinct from routing: WAF inspects application-layer traffic, while listeners and rules determine where it goes.

Create one controlled error, such as an invalid backend host setting or failed health probe. Troubleshoot from the gateway’s health view and backend logs rather than guessing.

Exercise 14: compare Application Gateway, Front Door, Traffic Manager, and Load Balancer

Create four requirement cards. Card one: regional HTTP application with path-based routing and WAF. Card two: global HTTP application requiring edge acceleration and multi-region origins. Card three: DNS-based global distribution between endpoints. Card four: internal TCP service requiring Layer 4 distribution.

Map the strongest primary service to each requirement and then explain what would make a different service relevant. Front Door and Application Gateway can appear together in a layered design; Traffic Manager makes DNS decisions rather than proxying HTTP; Load Balancer operates at Layer 4. This comparison lab is more valuable than memorizing feature tables because it rehearses selection.

If you have time, add Gateway Load Balancer as a fifth card for transparent insertion of supported virtual network appliances into traffic paths.

Exercise 15: design Front Door with healthy and unhealthy origins

For a global web application, create two regional origins if your lab budget allows. Configure Front Door routing and health checks. Observe normal distribution, then make one origin unavailable and confirm how health affects request routing.

Add a caching or rule-engine scenario and identify whether the change belongs at the edge or in the origin application. Think about TLS termination, custom domains, and private origin access where supported.

The objective is to understand Front Door as a global application-delivery layer, not simply as “a faster load balancer.” Trace the request from the user to the edge to the selected origin.

Exercise 16: build NSG rules and inspect the effective result

Create a subnet and workload with an NSG. Start with a simple allow requirement, such as permitting HTTPS from a defined source while denying unnecessary inbound traffic. Add a second NSG at the NIC or subnet level and inspect the effective security rules.

Change priorities deliberately and test the impact. Use Application Security Groups if you have multiple workloads and want to express rules based on application role rather than fixed IP addresses. The main lesson is that configured rules and effective rules are not always the same mental object when several scopes interact.

For troubleshooting, begin with the effective rule result before rewriting policy. This reinforces the habit of observing the system rather than guessing.

Exercise 17: distinguish NSG, Azure Firewall, WAF, and DDoS use cases

Create a four-layer security design for a public web application. Use NSGs for subnet or NIC traffic policy. Place a network firewall where centralized Layer 3/4 and relevant higher-level inspection is required. Use WAF at the web application edge. Consider DDoS protection for volumetric attack resilience. Add Defender for Cloud posture findings as a governance and exposure signal rather than as a packet-filtering control.

Now remove each layer in turn and state what risk reappears. Removing WAF does not necessarily open every port, but it reduces application-layer protection. Removing the firewall does not remove all NSG rules, but centralized policy and inspection may be lost. Removing identity controls is not compensated for by a firewall.

This exercise builds control-layer discipline, which is useful throughout AZ-700.

Exercise 18: troubleshoot a complete “client cannot connect” scenario

Build or simulate a failure where a client cannot reach an Azure service. Use a fixed diagnostic order: resolve the name, confirm source and destination addresses, inspect the expected route, inspect effective security rules, confirm the destination service is listening or healthy, and verify any platform-specific access configuration.

Do not change anything until you have evidence. If DNS returns the wrong address, solve that first. If the route points to an unintended appliance, investigate routing. If the route is correct but an NSG denies the flow, fix the rule. If all network checks succeed but the application is unhealthy, move up the stack.

Repeat with a second failure where two problems exist at once. Real troubleshooting often involves layered faults, and AZ-700 scenario reasoning improves when you learn not to stop at the first fix.

Exercise 19: practice Network Watcher and Azure Monitor for Networks with questions in mind

Explore the tools available for topology, connection troubleshooting, effective routes, effective security rules, and network monitoring. Do not click through features randomly. Ask questions: Which path is traffic taking? Which security rule applies? Is a connection possible? Which resources participate in the topology? What changed when the failure began?

Document which tool or evidence answers each question. The exam can present a troubleshooting goal and expect you to choose the right diagnostic approach. Familiarity with the purpose of the tools is more useful than remembering the exact blade name in the portal.

Exercise 20: add security and failure requirements to every design

Once you can make a design work, make it fail safely. If you create a public application, ask how DDoS, WAF, and backend segmentation affect risk. If you create hybrid connectivity, ask what happens when the primary link fails. If you create private access, disable public access and verify that intended clients still work. If you create a route through an appliance, ask how appliance failure affects availability.

This final habit turns configuration practice into architecture practice. AZ-700 is not just about reaching a destination; it is about reaching it through a design that meets security, availability, manageability, and performance requirements.

Exercise 21: use Azure Virtual Network Manager to think about policy at scale

When a lab grows beyond two or three VNets, manual peering and security configuration can hide an important AZ-700 skill: operating network intent consistently across many virtual networks. Review Azure Virtual Network Manager and, where your subscription permits, create a small network group with two or more VNets. Explore how connectivity configurations can express a topology and how security admin concepts differ from ordinary per-NSG rule management.

The practical question is not “which button creates a group?” It is how centralized network management changes the operating model. If the organization regularly creates new spokes, can the network team apply a repeatable connectivity pattern without hand-building every peer? If a policy must be enforced broadly, which centralized capability is appropriate and what exceptions or rollout controls are required?

Design a failure test as well. Place a VNet outside the intended group and predict how connectivity differs. Change group membership and confirm the expected effect. Centralized management is useful only when you understand scope and propagation.

Exercise 22: investigate exposure rather than treating every recommendation equally

Open Defender for Cloud or another available posture view for your lab environment and inspect network-related recommendations. Do not treat the list as a checklist to clear blindly. Pick one exposed resource and ask what an attacker could do if that exposure were abused. Does the resource have a managed identity? Can it reach a sensitive backend? Is a management port open? Is the security group broader than necessary?

Draw an attack path from the initial exposure to a valuable asset. Then identify multiple ways to break the path: reduce public reachability, narrow an NSG rule, patch the workload, reduce identity privilege, segment the backend, or add monitoring. This exercise connects network engineering to security prioritization and reinforces why the strongest remediation may not be the recommendation with the largest visual score impact.

If DDoS protection is available in your environment, review its placement and monitoring without attempting unsafe traffic generation. The study objective is to understand what problem DDoS protection solves, how it differs from WAF or firewalling, and which internet-facing resources may benefit from the service.

Exercise 23: finish with a capstone design and an evidence pack

Create one final scenario that uses at least four domains. A company has two Azure regions, an on-premises datacenter, a global web application, a private database service, and a requirement that internet-bound workload traffic leave through known public IP addresses. Design regional address spaces, hub/spoke connectivity, hybrid connectivity, application delivery, private access, outbound NAT, DNS, and network security.

Before deploying anything, create the expected traffic paths for five flows: public user to web application, web tier to private database, administrator to management interface, on-premises client to private service, and workload to the internet. Label the DNS answer, route, security control, and delivery component involved in each flow. Even if you cannot afford to deploy the full architecture, build a smaller representative version and validate the most important dependencies.

Your evidence pack should contain route outputs, DNS query results, health status, effective security rules, and a short explanation of failure behavior. Then deliberately alter one dependency—remove a private DNS link, change a UDR, break a health probe, or tighten an NSG—and diagnose the impact. The capstone is complete only when you can explain both the healthy and broken states without relying on the original instructions.

Structure a weekly practice cycle around mixed scenarios

A productive week alternates focused labs with mixed scenarios. Spend early sessions on one weak concept such as DNS, routing, ExpressRoute design, Application Gateway, or private endpoints. Later in the week, combine two or three domains. For example, build a private application behind Application Gateway, connect it to a private PaaS service, and require on-premises access. Now you have application delivery, private access, DNS, routing, and hybrid connectivity in one scenario.

Use a readiness log to decide what to repeat. If you can deploy a service but cannot predict the traffic path, the skill is not finished. If you can predict the path but cannot identify the evidence needed to troubleshoot it, add monitoring. If you can do both but keep choosing the wrong service in practice questions, add comparison exercises.

The companion AZ-700 preparation mistakes guide can help if your lab activity is high but your scenario performance remains inconsistent.

Use practice questions only after building a mental model

Hands-on preparation and AZ-700 practice questions reinforce each other when used in the right order. A lab gives you a model of how the service behaves. Practice questions test whether you can select that behavior under new constraints. When you miss a question, decide whether the problem is missing knowledge, weak comparison, or poor reading.

For every missed item, create a tiny follow-up exercise. If you confused Private Link and service endpoints, redraw both traffic models. If you missed an Application Gateway health-probe question, deliberately break a probe. If you misread route precedence, reproduce the route table. This closes the loop between theory and evidence.

Final perspective: rehearse the behavior of the network, not just the configuration steps

The most valuable AZ-700 lab is one you can explain after the portal is closed. You should know why the address plan works, why a route wins, why a name resolves to a particular address, why a gateway or delivery service is the right fit, which security control applies, and what evidence proves the design is healthy.

Build small environments, predict outcomes, create controlled failures, and troubleshoot them methodically. That process gives you the practical intuition to handle exam scenarios that do not look exactly like your lab. The technology may be presented in a different order, but packets still follow routes, names still depend on DNS, health probes still influence backend selection, and access still depends on the interaction between connectivity and security. If you can reason about those behaviors, your preparation is operating at the level AZ-700 expects.