Microsoft AZ-700 Azure Network Engineer Readiness Matrix: How to Diagnose Your Weakest Exam Domains

 

AZ-700 readiness is difficult to judge by hours studied because the current exam is broad and operational. A candidate can read about every major Azure networking service and still be unprepared to design a route, choose a connectivity pattern, troubleshoot DNS, reason about SNAT, or explain why a private endpoint is unreachable. The most useful readiness test is therefore not “Have I covered the syllabus?” but “Can I make and defend the decisions the syllabus requires?”

Microsoft’s current AZ-700 study guide groups the exam into five major skill areas: core networking infrastructure, connectivity services, application delivery services, private access to Azure services, and network security services. The largest individual area is core networking infrastructure at 25–30%, followed by connectivity at 20–25%, application delivery at 15–20%, network security at 15–20%, and private access at 10–15%. Microsoft currently lists 100 minutes for the assessment and a passing score of 700. Those numbers are useful context, but they should not drive your study plan as strongly as demonstrated skill.

This readiness matrix converts each domain into observable behaviors. Use it to find the difference between recognition, working knowledge, and exam-ready reasoning. If you need deeper practice after identifying a gap, the companion AZ-700 practical preparation guide turns many of the checks below into hands-on exercises.

Use four readiness levels instead of a simple “know / don’t know” checklist

Rate each skill at one of four levels. Level 0 means you do not recognize the concept well enough to explain it. Level 1 means you recognize the service or feature and can describe its purpose, but you need notes to choose it in a scenario. Level 2 means you can configure or explain the feature in a familiar case and can compare it with common alternatives. Level 3 means you can reason through an unfamiliar scenario, identify dependencies, predict failure modes, and explain trade-offs without relying on memorized wording.

AZ-700 readiness should be dominated by Level 2 and Level 3 skills. A Level 1 understanding of Private Link, for example, may let you define a private endpoint, but the exam can require you to reason about private DNS, on-premises name resolution, service FQDNs, and the difference between private endpoints and service endpoints. Likewise, knowing that ExpressRoute is private connectivity is only Level 1 if you cannot distinguish peering models, redundancy, Global Reach, FastPath, routing implications, and when VPN remains appropriate.

Do not average your scores too early. A 2.5 average can hide a severe gap in one domain. The goal is to find weak clusters that can cause repeated mistakes.

Domain 1 readiness: design and implement core networking infrastructure

The current core infrastructure domain is more than “know VNets and subnets.” It includes IP addressing, segmentation, VNet connectivity, DNS, routing, NAT, monitoring, and related operational design. A Level 3 candidate can move from business requirements to an address and routing model and can explain what breaks when dependencies are wrong.

Start with address planning. Can you choose non-overlapping CIDR ranges across multiple VNets while leaving room for growth? Can you explain why overlap complicates peering and hybrid connectivity? Can you identify when a subnet must be delegated and when it should be isolated? Can you distinguish address planning for workloads, gateways, private endpoints, and platform services? If you can only create a VNet through the portal, you are not yet at the design level.

Next test segmentation. Given a three-tier application, can you decide which components belong in separate subnets and why? Can you reason about how segmentation affects NSGs, routing, service endpoints, private endpoints, appliance insertion, and operational ownership? Do you know when separate VNets create useful boundaries and when they add unnecessary complexity?

For VNet connectivity, verify that you understand peering behavior, forwarding, gateway transit patterns, and the operational purpose of Azure Virtual Network Manager. You should be able to explain why peering is not simply “connect everything” and why a hub-and-spoke design still requires explicit thinking about route propagation, security inspection, and DNS.

Core infrastructure readiness: routing and forced-path scenarios

Routing is one of the best indicators of AZ-700 readiness because it combines conceptual knowledge with troubleshooting. You should understand system routes, user-defined routes, route precedence, next-hop types, forced tunneling, Route Server, and how network virtual appliances can influence traffic paths.

Test yourself with a scenario: a spoke workload must reach the internet only through a central firewall. Can you describe the route needed, the effect on return traffic, the importance of IP forwarding for an NVA, and how asymmetric routing can appear? Now add on-premises connectivity. Can you explain how learned routes interact with user-defined routes and why route propagation settings matter? If you can solve the diagram only after searching documentation, mark this area as Level 1 or 2 rather than Level 3.

Route Server deserves decision-level understanding. Know that it helps exchange routes dynamically with supported network virtual appliances using BGP, reducing the need to maintain static UDRs in some designs. But do not turn that into a reflex. Ask whether the scenario needs dynamic route exchange, what the appliance supports, and how the overall hub design is organized.

A good readiness test is to predict the effective route table before checking it in Azure. If your prediction and the observed path disagree, investigate until you can explain why.

Core infrastructure readiness: DNS and name-resolution architecture

DNS is a frequent source of real Azure networking failures because connectivity can be healthy while names resolve incorrectly. The current blueprint includes Azure DNS public and private zones, VNet DNS settings, and Azure DNS Private Resolver. You should be able to design name resolution for Azure-only, hybrid, and private-endpoint scenarios.

At Level 3, you can explain the difference between public DNS hosting and private DNS zones, how VNets link to private zones, and how Private Resolver endpoints and rulesets support hybrid name resolution. You understand that private endpoint connectivity often depends on the original service FQDN resolving to the private IP in the clients that should use the private path.

Test yourself with a hybrid scenario. An on-premises client must reach a storage account through a private endpoint in Azure. What must happen to the query for the storage service name? Where can conditional forwarding or Private Resolver fit? What happens if on-premises DNS continues to return the public address? If you can describe the query path from client to answer, including the private zone, you are moving toward exam readiness.

The companion core networking infrastructure deep dive is particularly useful if DNS, routing, or VNet topology is your weakest cluster.

Core infrastructure readiness: outbound connectivity and NAT

Azure networking questions can become confusing when candidates ignore outbound behavior. NAT Gateway, public IPs, load balancer outbound rules, application delivery services, and platform-managed egress can influence source addresses and SNAT behavior. You should be able to reason about which component owns outbound connectivity and what happens when connections scale.

A readiness prompt: workloads in a subnet need predictable outbound public IP addresses and high-scale internet egress without accepting unsolicited inbound traffic. Can you explain why NAT Gateway fits, how it associates with a subnet, and why it is different from deploying a public load-balancing frontend? Then change the scenario: the application already uses a Standard Load Balancer and requires specific outbound behavior. Can you explain the relevant outbound options without assuming every architecture needs NAT Gateway?

You do not need to memorize every platform limit to be ready, but you should understand SNAT as a resource and troubleshooting concept. When an application makes many outbound connections and starts experiencing intermittent failures, source-port exhaustion should be in your diagnostic vocabulary.

Core infrastructure readiness: monitoring and operational diagnosis

The current exam includes Network Watcher, Azure Monitor for Networks, flow logs, DDoS-related considerations, and Defender for Cloud network recommendations or attack-path context. Readiness means knowing what question each tool can answer.

Can you determine whether a route is wrong, a security rule is blocking traffic, DNS resolves incorrectly, or a gateway connection is unhealthy? Can you choose the evidence source instead of changing configuration blindly? Effective routes and effective security rules help validate actual policy on a network interface. Connection troubleshooting and related Network Watcher capabilities can help isolate reachability. Flow data supports traffic analysis. Azure Monitor for Networks helps with topology and health context.

Your Level 3 standard should be: given “A cannot reach B,” you can define a diagnostic order that minimizes random changes. Check name resolution, source/destination addressing, route path, security controls, service health, and application listening state in a deliberate sequence.

Domain 2 readiness: connectivity services

Connectivity includes site-to-site and point-to-site VPN, ExpressRoute, Virtual WAN, and related routing decisions. The exam is less about knowing that these services exist and more about matching them to latency, bandwidth, redundancy, security, operational, and topology requirements.

For VPN, know gateway roles, tunnel and authentication choices, active-active design concepts, local network gateways, BGP use, and the difference between S2S and P2S. For P2S, identify when the user population requires remote client connectivity rather than network-to-network connectivity. Understand that authentication choices and client support influence the design.

For ExpressRoute, be able to distinguish private peering from Microsoft peering at a conceptual level and understand that private peering connects to private Azure address spaces rather than becoming general internet access. Know the purpose of redundancy, circuit/provider considerations, FastPath, Global Reach, and encryption options. You should be able to compare ExpressRoute with VPN based on business requirements, not on the simplistic claim that one is always “better.”

Connectivity readiness: design for failure, not only for the happy path

A network engineer should expect circuits, gateways, devices, and regions to fail. Test whether you can design redundancy. If a company uses ExpressRoute as the primary hybrid connection, what backup model is appropriate? If two on-premises sites connect to Azure, how should the topology avoid a single hub appliance becoming the only path? If a Virtual WAN architecture uses multiple hubs, how does that affect regional reachability and routing?

Do not judge readiness solely by whether you can draw the normal traffic path. Draw the failure path. Which route wins when the preferred connection is unavailable? How quickly does convergence occur conceptually? What dependencies remain? Does the backup path preserve required security inspection? These questions expose gaps that normal diagrams hide.

A Level 3 candidate can describe both the desired path and the fallback behavior without promising unrealistic seamlessness.

Connectivity readiness: know when Virtual WAN changes the operating model

Azure Virtual WAN is not merely “a bigger hub.” It provides a managed transit architecture with virtual hubs, integrated VPN/ExpressRoute connectivity, routing, and supported security or NVA integration patterns. The decision signal is often operational scale and connectivity complexity.

Evaluate whether you can explain when a self-managed hub-and-spoke design remains reasonable and when Virtual WAN reduces operational burden across many branches, regions, or connectivity types. Understand gateway scale units, hub routing, and integration considerations at a decision level. Know that adopting Virtual WAN changes the architecture model, so migration and routing design matter.

If your only explanation is “Virtual WAN is for large companies,” you need deeper preparation. Replace size labels with requirements: many sites, global transit, integrated managed gateways, centralized routing policy, and the need to simplify connectivity operations.

Domain 3 readiness: application delivery services

This domain includes Azure Load Balancer, Traffic Manager, Gateway Load Balancer, Application Gateway, and Front Door. Candidates often confuse them because all can affect how traffic reaches applications. Readiness requires a clean selection framework based on layer, scope, protocol, geography, inspection needs, and application behavior.

Can you explain the difference between Layer 4 load balancing and Layer 7 application routing? Can you identify when global DNS-based distribution is different from global HTTP reverse-proxy delivery? Do you understand when WAF capability matters? Can you reason about internal versus public frontends? Do you understand health probes as an availability dependency rather than an optional check box?

A strong comparison exercise is to take one application and redesign it five times: internal TCP service, regional web application, global web application, multi-region active/active site, and application traffic requiring a third-party network appliance. Choose the delivery service each time and defend the decision.

Application Gateway readiness: listeners, pools, probes, TLS, and routing logic

Application Gateway questions become easier when you view the service as a Layer 7 policy engine. A request arrives at a frontend and listener, is evaluated against routing rules, and is forwarded to an appropriate backend pool using settings that influence protocol and health. TLS can terminate or be re-established depending on design. URL/path or host-based routing can direct requests to different backends.

Readiness means understanding the chain. If a backend is marked unhealthy, what should you inspect? If the certificate name does not match the backend configuration, what can fail? If the requirement is to route `/api` and `/images` to different pools, which feature family is relevant? If a WAF is required, where in the path does it operate?

The exam rarely rewards memorizing a portal sequence. It rewards understanding the request path and dependencies.

Front Door readiness: global application delivery and private origins

Azure Front Door operates at a global application-delivery layer. You should be able to explain origins, endpoints, routing, TLS, caching or acceleration concepts, rule processing, and the possibility of private connectivity to supported origins. The comparison with Application Gateway is especially important.

A Level 3 candidate can decide whether the primary need is global HTTP/S entry and acceleration, regional Layer 7 routing, or a combination. The services can complement each other in some architectures, so avoid simplistic either/or memorization. Ask where the clients are, where the application runs, where TLS and WAF controls should be applied, and whether origins need to remain private.

Practice explaining the request path from a user in one geography to an origin in another. Then identify what happens when an origin fails health checks.

Domain 4 readiness: private access to Azure services

This domain may be smaller by weighting, but it produces disproportionately important architecture decisions. You must distinguish Private Link and private endpoints from service endpoints. Both can reduce exposure compared with unrestricted public access, but they work differently.

A private endpoint places a network interface with a private IP in your VNet that represents access to a supported service. Name resolution is central because clients must resolve the service FQDN to the private address for the private path. Service endpoints, by contrast, extend VNet identity to a supported service over the Azure backbone while the service retains its public endpoint architecture. Service endpoint policies can add restrictions in relevant designs.

Readiness means you can choose based on requirements. If the goal is to expose a platform service privately inside a VNet and potentially from on-premises through private connectivity, Private Link is often the stronger pattern. If the scenario needs service-level access restricted to selected subnets but does not require a private IP endpoint, service endpoints may fit. Do not call them interchangeable.

Private access readiness: troubleshoot the whole dependency chain

A common real-world failure is “the private endpoint exists but the client cannot connect.” Your diagnostic order should include DNS, routing, NSGs or relevant controls, service-side configuration, and application behavior. If DNS returns the public address, you have not actually validated the intended path.

Run a readiness lab where you create a private endpoint, link the appropriate private DNS zone, test resolution from a linked VNet, then test from another network without the correct resolution path. Add hybrid DNS forwarding if your lab resources allow. The aim is to see how name resolution changes the network outcome.

This is a classic distinction between Level 1 and Level 3 knowledge: Level 1 knows what a private endpoint is; Level 3 can predict and diagnose its dependencies.

Domain 5 readiness: network security services

Network security includes NSGs, ASGs, flow logging, DDoS-related design, and other Azure security services relevant to network protection. Readiness requires both policy reasoning and troubleshooting.

For NSGs, know rule priority, direction, source/destination, service/port, and the interaction between subnet- and NIC-level application of rules. Understand default rules conceptually and know how to inspect effective security rules. Application Security Groups can make policy more expressive by grouping workloads logically instead of hardcoding addresses.

Do not treat NSGs as firewalls with every advanced capability. Understand when centralized firewalling, application-aware controls, or web application protection requires other services. The exam can test whether you choose the correct security control layer.

Security readiness: DDoS, WAF, firewalling, and posture are different problems

DDoS protection addresses volumetric and protocol-level attack concerns at the network edge. A WAF addresses web application attack patterns at Layer 7. A network firewall provides traffic inspection and policy at network boundaries. Defender for Cloud posture recommendations or attack paths help identify risky configurations. These capabilities can all appear in one architecture without substituting for one another.

Test yourself with scenarios that require one primary control. If the application is being targeted by HTTP request attacks, a WAF is more directly relevant than a DDoS service. If the risk is unauthorized east-west connectivity between workloads, segmentation or firewall policy is more direct. If the problem is a risky public endpoint combined with excessive identity permissions, attack-path prioritization may guide remediation but does not itself replace the control.

Your readiness should include the ability to place each service in the right layer.

Build a numeric readiness matrix without letting the numbers hide risk

Create a spreadsheet or notebook with one row per skill cluster and columns for concept explanation, design selection, configuration familiarity, troubleshooting, and scenario reasoning. Score each from 0 to 3. Add evidence: lab completed, scenario explained, mistake observed, or practice score. The evidence column prevents optimistic self-rating.

Weight the major domains roughly in line with the current blueprint, but add a “critical dependency” flag. DNS and routing may deserve extra attention even if a single subtopic has a small formal weighting because they affect many scenarios. Likewise, identity or security controls can influence designs across domains.

Use the matrix to choose study blocks. If core infrastructure averages 1.4 while application delivery averages 2.6, the next week should not be another tour of Front Door features. It should be routing, DNS, address planning, and VNet design until the lower domain rises.

Use practice questions as a diagnostic instrument

When using AZ-700 practice questions, tag every missed or guessed item to a readiness row. Was the error a route-precedence gap, DNS misunderstanding, ExpressRoute selection error, Application Gateway health-probe issue, private-endpoint DNS failure, or NSG scope mistake? After a few sessions, the frequency of tags is more informative than the raw percentage correct.

Also distinguish knowledge gaps from reading errors. If you knew the concept but missed the word “private,” “global,” “minimize administration,” or “from on-premises,” your fix is scenario reading. If you repeatedly choose service endpoints when the requirement needs a private IP, your fix is conceptual comparison. If you know the right service but cannot explain the dependencies, your fix is hands-on validation.

Practice is readiness evidence only when you learn from the pattern of errors.

A deeper connectivity check: compare VPN, ExpressRoute, and Virtual WAN from requirements

Use one comparison drill to expose shallow knowledge. Create four customer profiles: a small branch that needs encrypted site-to-site connectivity quickly; a large enterprise that needs predictable private connectivity through a provider; remote users who need secure client access; and a multinational organization with many branches, several Azure regions, and a desire to simplify transit routing. For each profile, choose the primary connectivity pattern and then list two constraints that could change your answer.

This exercise forces you away from slogans. VPN is not simply the “cheap” choice; it can be appropriate where internet-based encrypted connectivity, rapid deployment, or backup paths fit the requirement. ExpressRoute is not automatically the “enterprise” answer; it must be justified by private connectivity, provider integration, performance, compliance, or reliability needs. Virtual WAN is not merely a scale label; its value is the managed connectivity and transit operating model. Point-to-site access solves a different problem from site-to-site connectivity even though both use VPN technology.

Then add failure behavior. If ExpressRoute fails, what path remains? If a VPN gateway is active-active, what dependencies still exist? If a Virtual WAN hub has a routing problem, what traffic scope is affected? If you cannot describe the fallback path, the comparison is still only Level 1 or 2.

A deeper application-delivery check: classify by layer, geography, and inspection

Build a table in your notes with rows for Azure Load Balancer, Traffic Manager, Application Gateway, Front Door, and Gateway Load Balancer. Do not memorize marketing phrases. Fill columns for network layer, regional or global scope, protocol assumptions, health behavior, TLS or HTTP awareness, WAF relevance, private/internal use, and the kind of problem each service primarily solves.

Then test combinations rather than single products. A global web application may use Front Door for global HTTP/S entry and regional services behind it. A regional application may need Application Gateway for Layer 7 routing and WAF. A private TCP workload may use an internal Load Balancer. A design that steers traffic through a third-party virtual appliance may involve Gateway Load Balancer. Traffic Manager makes DNS-based decisions and therefore behaves differently from a reverse proxy.

Readiness is demonstrated when you can explain why a service is wrong for a scenario. If the requirement is Layer 7 path-based routing, a Layer 4 load balancer does not become correct merely because it distributes traffic. If the requirement is non-HTTP internal traffic, a global HTTP reverse proxy is not the natural first answer. Elimination quality is part of exam readiness.

Turn the matrix into a two-week remediation plan

Once the weak rows are visible, convert them into a short remediation cycle. Days one through three can focus on the weakest infrastructure fundamentals: addressing, routes, DNS, and peering. Days four and five can cover hybrid connectivity and failure design. Days six and seven can focus on application delivery with request-path diagrams and health-probe troubleshooting. The next several days can cover private access, network security, and mixed scenarios that combine multiple domains.

Every study block should have an output. A route lab should end with an effective-route explanation. A DNS lab should end with a query-path diagram. An Application Gateway lab should end with a request-flow and health-check explanation. A private-endpoint lab should end with proof of private name resolution and reachability. A security lab should end with a statement of which layer the control protects and what it does not protect.

Retest the same matrix after several days without rereading your original answers first. Improvement is real when you can reason from the scenario again, not when the old notes look familiar. If a row remains weak after repeated reading, change the learning mode: build, troubleshoot, draw, or teach the concept aloud.

Final readiness test: explain five end-to-end scenarios without notes

Before considering yourself ready, solve five end-to-end scenarios verbally or on paper. Design IP space and routing for a multi-region hub-and-spoke environment. Connect a branch network with appropriate redundancy. Deliver a global web application using the right application-delivery services. Provide private access from on-premises to a platform service with correct DNS. Diagnose a connectivity failure involving routes, NSGs, and name resolution.

For each scenario, state the requirement, proposed services, traffic path, failure modes, monitoring evidence, and at least one alternative you rejected. If you can do that accurately and without relying on a memorized diagram, you are operating near Level 3.

If one scenario exposes a major weakness, that is useful. Readiness matrices are not designed to make you feel prepared; they are designed to identify the next highest-value improvement.

Final perspective: readiness is the ability to predict network behavior

AZ-700 becomes manageable when you stop treating it as a catalog of Azure networking products and start testing whether you can predict behavior. Can you predict the route? Can you predict the resolved address? Can you predict which backend receives a request? Can you predict which security rule applies? Can you predict what happens when a connection fails or a gateway is unavailable?

Use the matrix to drive your study toward those outcomes. Raise weak domains with targeted labs and scenario work, retest them, and record evidence. A candidate who can explain why traffic follows a path—and how to prove it—has a much stronger readiness signal than a candidate who has simply read every page of the study guide.