AZ-700 scenario questions become easier when you stop reading them as a list of Azure products and start reading them as a network dependency chain. The current AZ-700 blueprint expects design, implementation and troubleshooting across addressing, DNS, routing, hybrid connectivity, application delivery, private access and security. The right answer usually depends on identifying which layer the scenario is actually testing.
Start by locating the failed layer
“Cannot connect” is not a diagnosis. A client can fail because name resolution is wrong, no route exists, a VPN or ExpressRoute path is down, an NSG denies traffic, a firewall blocks it, the application gateway marks the backend unhealthy or a private endpoint resolves to the wrong address. The first decision should narrow the layer with evidence.
Use effective routes, DNS results, Network Watcher, flow logs, gateway status, health probes and service diagnostics before changing unrelated configuration.
Address overlap is a design failure, not a routing tweak
If two VNets or an on-premises network use overlapping ranges, peering or hybrid connectivity can become impossible or ambiguous. Adding more UDRs does not fix an address plan that cannot distinguish destinations.
The better answer is normally to redesign or renumber the conflicting space before the environment grows further.
DNS can break a healthy Private Link design
A private endpoint may exist with correct routing, yet clients still resolve the service to a public endpoint. In that case the scenario is about DNS integration, private zones or hybrid resolution, not NSG troubleshooting.
Private access questions often require the engineer to reason about network path and name resolution together.
VPN up does not mean application reachable
A site-to-site tunnel can negotiate successfully while traffic fails because routes, local-network definitions, security rules or return paths are wrong. Do not change IKE parameters merely because the application is unreachable.
Check whether the intended prefixes are known on both sides and whether security controls allow the flow.
ExpressRoute questions are often routing questions
Private connectivity can be physically healthy while BGP advertisements are missing or too broad. Global Reach, FastPath, BFD and peering type solve different needs and should not be selected simply because they sound “more enterprise.”
The scenario’s route, resilience and geography requirements determine the feature.
Choose application delivery by layer and scope
Layer 4 regional distribution points toward Azure Load Balancer; DNS-based global endpoint selection points toward Traffic Manager; regional HTTP/S routing points toward Application Gateway; global edge application delivery points toward Front Door.
A Load Balancer comparison helps when two choices can both distribute traffic but operate at different layers.
Private Endpoint and service endpoint are not interchangeable
A private endpoint gives the supported service a private IP presence in the consumer VNet. A service endpoint keeps the service on its public endpoint while extending subnet identity to supported Azure services.
When the requirement explicitly says private IP access or private on-premises reachability, Private Link is usually the stronger clue.
NSG, Firewall and WAF answer different security questions
An NSG is distributed network filtering, Azure Firewall provides centralized network/application rules and NAT, and WAF protects HTTP applications at Layer 7. One can allow TCP/443 while another blocks a malicious request.
Identify which protocol layer the policy needs to inspect before selecting the control.
Use monitoring evidence to eliminate distractors
If Network Watcher shows the route is correct and IP flow verification shows the NSG allows the flow, do not choose another route table or NSG rule. Move to the next dependency: firewall, load balancer, application health or DNS.
The Network Watcher mindset is valuable because evidence removes plausible but irrelevant answer choices.
Finish with a repeatable decision sequence
Read the requirement, identify the traffic source and destination, verify name resolution, inspect effective route, confirm hybrid or application-delivery health, check distributed and centralized security, and only then change configuration. That sequence works across many AZ-700 scenarios.
Scenario questions often include one or two facts that are deliberately irrelevant. A requirement may mention that the application runs on Linux, but the decision is really about private DNS. Train yourself to separate business constraints, topology facts and symptoms from incidental detail. The shortest correct path usually appears once the network layer is identified.
When the scenario describes a new design rather than a failure, begin with nonfunctional requirements: availability, latency, throughput, private connectivity, management scale, security boundary and cost. Then choose the service. Starting from a familiar product and forcing the requirement into it is a common reason two answer choices both seem plausible.
Gateway transit questions are a good example of dependency reasoning. A spoke can use a peered hub’s gateway only when the peering settings and topology support that design. If the requirement says the spoke should reach on-premises through the hub, check peering and gateway-transit concepts before adding a second gateway unnecessarily.
Forced tunneling changes where default traffic goes. If an organization requires all internet-bound traffic to pass through an on-premises appliance or centralized security service, a default route may be intentional. If Azure PaaS access then fails, the problem can be route or service connectivity rather than an application bug.
NAT Gateway scenarios usually emphasize outbound scale and stable source addresses. If private VMs need predictable internet egress without individual public IPs, NAT Gateway is a strong fit. If the requirement is to publish an internal server to inbound clients, NAT Gateway is the wrong direction of translation.
Azure Route Server appears when dynamic route exchange with network virtual appliances is the requirement. If a scenario describes many route-table updates caused by changing NVA paths, BGP-based propagation can be more suitable than maintaining large sets of static UDRs. It does not replace ordinary peering or every route table.
Virtual Network Manager scenarios often describe many VNets, centralized connectivity intent or security-admin rules. The key clue is management at scale. If the environment contains only one or two VNets and the question is simply about a single route, Virtual Network Manager may add complexity without solving the actual problem.
For point-to-site VPN, distinguish connectivity from identity. Certificate, RADIUS and Microsoft Entra authentication methods change how the user proves identity, while routes and tunnel configuration determine what the client can reach after connection. A successful login does not prove the target prefix is reachable.
For ExpressRoute, private peering and Microsoft peering are different traffic domains. Private peering connects private Azure virtual networks; Microsoft peering provides access to supported Microsoft public services. A scenario about reaching VNet private addresses should not be answered with Microsoft peering just because both use ExpressRoute.
Application Gateway scenarios frequently hinge on backend health. If a listener is reachable but returns errors because all backends are unhealthy, check probe path, host header, port, TLS and application response. Adding another frontend IP or DNS record does not repair a failing health check.
Front Door scenarios emphasize global edge routing, origin health, caching and application-layer policy. When the requirement mentions users in several geographies, global acceleration or WAF at the edge, Front Door is often stronger than a regional Application Gateway. The origin can still be protected privately depending on design.
Traffic Manager can be correct even though it never carries application packets. If the requirement is DNS-based failover or geographic endpoint selection across public endpoints, DNS resolution can be enough. If the question requires Layer 7 routing after the connection reaches a service, look elsewhere.
NSG rule questions require attention to priority and effective scope. A permissive rule with a lower precedence may never be evaluated because a higher-priority deny already matched. Likewise, subnet- and NIC-level NSGs can both apply, so reading one rule set in isolation can be misleading.
Azure Firewall questions often involve centralized policy, application rules, DNAT/SNAT or transit inspection. If the requirement is simple workload-to-workload filtering inside one subnet, an NSG may be more direct. If the requirement is centralized control across many spokes, a firewall architecture is more likely.
WAF scenarios should remain HTTP-aware. Managed rules, custom rules, bot protection or request inspection fit web applications. If the traffic is arbitrary TCP or UDP, WAF is not the enforcement layer even if the destination happens to be internet-facing.
Bastion questions are about secure administrative access to VMs without exposing RDP or SSH directly to the internet. If a scenario asks how administrators can connect while VMs remain privately addressed, Bastion may be the answer. It is not a general-purpose application proxy for end users.
DDoS questions are usually about public endpoint availability under volumetric or protocol attack. WAF can reduce some application-layer abuse, but DDoS protection addresses a different scale and attack layer. Read whether the scenario describes malicious requests or traffic-volume exhaustion.
Use elimination aggressively. If the requirement says “private IP,” remove answers that keep only a public endpoint. If it says “DNS-based global routing,” remove inline load balancers. If it says “centralized outbound SNAT,” remove WAF and peering. Strong scenario reading is often faster than recalling detailed configuration.
Scenario wording around “centralized management” versus “centralized transit” also matters. Azure Virtual Network Manager is about managing connectivity and security intent across many VNets, while Virtual WAN is a managed transit architecture for branch/VNet/VPN/ExpressRoute connectivity. They can coexist, but they solve different control problems.
When a scenario mentions a third-party NVA inserted transparently into a traffic path, Gateway Load Balancer deserves attention. That requirement is different from balancing application traffic among web servers. Recognizing appliance insertion as the goal can eliminate several familiar but incorrect load-balancing choices.
Health-probe scenarios should be read from the service outward. If backends fail health checks, first validate probe protocol, port, path, host expectations and application response. An NSG or route change may be necessary only if evidence shows the probe traffic itself cannot reach the backend.
For hybrid Private Link scenarios, the strongest answer often contains three pieces: the private endpoint, a route from on-premises to the VNet, and DNS resolution to the private address. A design missing any one of those can appear partially correct while still failing end to end.
Within the broader Microsoft certification path, AZ-700 rewards engineers who can locate the responsible networking layer quickly rather than candidates who simply recognize more Azure service names.