AZ-700 Study Guide: The Azure Networking Rules, Limits & Exam Traps That Matter

These are my study notes from preparing for and passing the Microsoft Azure Network Engineer Associate (AZ-700) exam in October 2026. I reorganized them by exam domain and kept what I actually needed: the numbers, the rules, and the traps.

AZ-700 is less about clicking through the portal and more about knowing which service fits which problem, and which limit or default will break your design. The details that decide questions are things like subnet names, rule evaluation order, and which SKU supports which feature. The sections below are built around exactly those details.

1. Core Networking Infrastructure (25–30%)

This domain covers the building blocks: VNets and subnets, name resolution, routing, and outbound connectivity. Everything else in the exam sits on top of these rules.

Virtual Networks & Subnets

• Subnets can range from /29 (smallest) to /2 (largest). Use private RFC 1918 ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
• A VNet can span multiple availability zones, but not multiple regions. Use peering to connect VNets across regions.
• Azure reserves 5 IP addresses in every subnet: the network address, the default gateway (.1), two for Azure DNS (.2, .3), and the broadcast address. A /29 has 8 addresses, so only 3 are usable.
• Subnet delegation gives a specific PaaS service (for example Microsoft.Web/serverFarms) exclusive permission to create service-specific resources inside the subnet. A delegated subnet can only be used by that service.
• IPv6: VNets support dual-stack (IPv4 + IPv6) address spaces. IPv6 subnets must be exactly /64.

VNet Peering

Peering connects two VNets so resources can talk over private IPs as if they were in the same network.

• Regional peering: same region. Global peering: different regions.
• Peering is non-transitive. If A is peered with B and B with C, A cannot reach C. Use a hub firewall/NVA with UDRs, Virtual WAN, or Azure Virtual Network Manager for transit.
• Peered VNets must not have overlapping address spaces.
• Peering must be created in both directions. Status: Initiated (one side only), Connected (both sides), Disconnected (one side was deleted).
• Per-link settings: Allow forwarded traffic (needed for NVA/firewall transit), Allow gateway transit (hub shares its VPN/ExpressRoute gateway), and Use remote gateways (spoke uses the hub's gateway).
• The common topology is hub-and-spoke: shared services (firewall, gateway, DNS) in the hub, workloads in spokes.

DNS & Name Resolution

Public DNS: Azure DNS hosts public zones on Microsoft's global name servers. Alias records point at an Azure resource (public IP, Traffic Manager, Front Door) and update automatically.

Private DNS: Private DNS zones resolve names inside VNets. A VNet resolves names through either Azure-provided DNS (168.63.129.16, the default, which resolves VM names and linked private zones) or custom DNS servers configured on the VNet (needed for on-premises names unless you use the Private Resolver).

• Private DNS zones are global resources. Link them to a VNet with a registration link (VM records are auto-created) or a resolution link (resolve only).
• A VNet can have auto-registration enabled for only one private DNS zone, but can be linked to other zones as resolution links.
• One zone can be linked to many VNets.

Azure DNS Private Resolver

A fully managed DNS service that resolves and forwards queries between Azure VNets, private DNS zones, on-premises networks, and external DNS servers, without VM-based DNS servers (BIND, Windows DNS).

• Inbound endpoint: a private IP that other networks (on-premises, or other VNets using it as DNS server) can query to resolve Azure private DNS zone records.
• Outbound endpoint + DNS forwarding ruleset: forwards queries for specific domains to a chosen DNS server (on-premises, external, or another VNet). Link the ruleset to every VNet that should use the rules.
• Each endpoint needs its own dedicated subnet (min /28), delegated to Microsoft.Network/dnsResolvers.
• It is not only for hybrid DNS. It also resolves between VNets in Azure, for example private endpoint zones across hub-and-spoke.

Routing: Route Tables, UDRs & Route Server

Azure creates system routes automatically for VNet, on-premises (via VPN/ExpressRoute), and internet traffic. A User Defined Route (UDR) in a route table overrides the system route for a prefix. This is the standard way to force traffic through a firewall or NVA with next hop type Virtual appliance.

• Route selection: longest prefix match wins; on a tie the order is UDR > BGP > system route.
• Next hop types: Virtual network gateway, Virtual network, Internet, Virtual appliance (the NVA needs IP forwarding enabled), None (drops traffic).
• Route tables are associated only with subnets, and a subnet can have only one route table. Use Disable BGP route propagation to stop gateway-learned routes from being applied.
• Verify with Effective routes on a NIC or Network Watcher Next hop.

Azure Route Server lets NVAs exchange routes with the Azure VNet router over BGP instead of you maintaining UDRs by hand. Routes learned from the NVA propagate to every subnet in the VNet.

• Lives in its own subnet named RouteServerSubnet (min /27) and needs a Standard public IP.
• Route Server uses ASN 65515, so the NVA must use a different ASN.

Public IPs & NAT Gateway

• Standard SKU (use this): always static, zone-redundant option, and closed to inbound traffic by default until an NSG allows it. Required for NAT Gateway, Standard Load Balancer, Azure Firewall and Bastion.
• Basic SKU: being retired; open by default.
• A public IP prefix reserves a contiguous block of public IPs (useful for allow-listing).
• A custom IP address prefix (BYOIP) lets you bring your own range (min /24 IPv4, /48 IPv6). You must own it through a regional internet registry and prove it with a ROA plus a signed message. The process is provision (Azure validates ownership), then commission (Azure advertises the range). You then carve public IP prefixes and IPs out of it.

NAT Gateway is a managed outbound-only connectivity service that gives a subnet a consistent public IP and scales for high SNAT volume.

• Attached to a subnet (Standard SKU only). Uses up to 16 public IPs/prefixes; each IP provides 64,512 SNAT ports.
• No route changes needed, and no inbound connections (except replies to outbound flows).
• Azure's default outbound access (the implicit outbound IP) is being retired. An explicit method will be required.

Outbound Connectivity Priority

Which method a VM uses to reach the internet, highest priority first:

1. NAT Gateway on the subnet: overrides everything below.
2. Public IP on the VM's NIC (instance-level public IP).
3. Load Balancer outbound rules (Standard public Load Balancer, also used when the VM is in its backend pool).
4. Default outbound access: implicit IP, last resort, being retired.

When the order changes or is bypassed:

• A UDR (for example 0.0.0.0/0 to Azure Firewall/NVA) changes the route first. Traffic then leaves through the firewall's public IP (or a NAT Gateway on the firewall subnet).
• Without any of these methods, a private subnet (default outbound access disabled) has no internet access.
• Basic public IPs and Load Balancers can't be combined with a NAT Gateway (Standard only).

2. Connectivity Services (20–25%)

Everything about connecting on-premises sites, branch offices, and remote users to Azure: VPN, ExpressRoute, and Virtual WAN.

Virtual Network Gateway & VPN Types

A virtual network gateway provides the secure connection between a VNet and other networks. Gateway type is Vpn or ExpressRoute. A VNet can have one of each, and both use the same GatewaySubnet (/27 recommended, minimum /29).

• RouteBased (default, recommended): IKEv2, BGP, multiple tunnels, P2S and VNet-to-VNet. Fits complex topologies.
• PolicyBased: IKEv1, static traffic selectors, one tunnel; Basic SKU only; no P2S.
• Active-active mode gives two gateway instances with two public IPs for redundancy; AZ SKUs are zone-redundant.
• The default Azure BGP ASN is 65515.

Point-to-Site VPN

Lets individual devices connect to a VNet over the internet. It is configured on the RouteBased Virtual Network Gateway with a client address pool that must not overlap your VNets.

Authentication methods: Azure certificate, Microsoft Entra ID (OpenVPN only), or RADIUS (for example when AD is on-premises).

Site-to-Site VPN

• Uses the GatewaySubnet and a local network gateway, which defines the on-premises network and its public IP on the Azure side.
• Configured on the Virtual Network Gateway under Connections. Tunnels use IPsec/IKE with a pre-shared key; custom IPsec/IKE policies and BGP are optional.
• VNet-to-VNet connections work the same way between two VPN gateways (VNet peering is usually simpler and cheaper).

ASNs reserved by Azure: public 8074, 8075, 12076; private 65515, 65517–65520. Reserved by IANA: 23456, 64496–64511, 65535–65551, and 4294967295. Both 16-bit and 32-bit ASNs are supported.

VPN Gateway SKUs

Basic is legacy: no BGP, no zone redundancy, P2S via SSTP only.

Azure ExpressRoute

A private, dedicated connection between on-premises and Azure that does not traverse the public internet.

• Traffic is not encrypted by default. Add MACsec (ExpressRoute Direct) or an IPsec VPN over ExpressRoute if you need encryption.
• Every circuit has a primary and secondary connection (two BGP sessions) for redundancy.
• Bidirectional Forwarding Detection (BFD) runs on top of the BGP sessions and detects a failed link in well under a second, versus up to minutes with BGP timers alone (hold time 180s), so traffic fails over faster. It is supported on Private and Microsoft peering; Microsoft's edge routers have it enabled, so you enable it on your own (CE) routers.
• ExpressRoute and S2S VPN can coexist, with the VPN as a backup path.

ExpressRoute Gateway SKUs

Circuit SKUs & Peering Types

• Local: connectivity to a specific Azure region, for localized workloads.
• Standard: all Azure regions within the same geopolitical boundary (a New York circuit reaches all US regions, but not Europe).
• Premium: global connectivity over the Microsoft core network, higher route limits (4,000 to 10,000 routes), and Microsoft 365 connectivity.
• Billing is Metered (per GB of outbound data) or Unlimited.

• Azure Private Peering: on-premises to VNets over private IPs. The most common type.
• Microsoft Peering: Microsoft 365, Dynamics 365, and Azure PaaS public endpoints over public IPs. Microsoft 365 access requires the Premium add-on.
• Azure Public Peering: deprecated. Use Microsoft Peering or private endpoints.
• Each peering uses a pair of /30 subnets (primary and secondary link).

FastPath, Global Reach & ExpressRoute Direct

• FastPath sends traffic directly to VMs in the VNet and bypasses the ExpressRoute gateway in the data path. It requires the Ultra Performance, ErGw3Az or ErGwScale gateway, and it is tied to the virtual network gateway connection, not the circuit.
• Global Reach links two of your ExpressRoute circuits so on-premises sites can reach each other over the Microsoft backbone. It needs a /29 private range, is enabled on the circuit, and needs the Premium add-on when the circuits are in different geopolitical regions.
• ExpressRoute Direct connects you directly to Microsoft's network over dual 10 or 100 Gbps ports, bypassing a provider. You create circuits on top of it yourself. It supports MACsec.

Azure Virtual WAN

A unified architecture for connecting branches, remote users, and Azure resources through Microsoft-managed hubs.

Basic can be upgraded to Standard, but not downgraded.

• Hub address space: /23 recommended (minimum /24). The hub is a Microsoft-managed VNet; you can't deploy your own resources in it.
• Gateways in the hub scale by scale units (S2S/P2S VPN: 500 Mbps per unit, ExpressRoute: 2 Gbps per unit).
• Routing intent forces internet-bound and/or private traffic through a security NVA (for example Azure Firewall) in the hub.
• Hub routing: each VNet connection is associated with one route table (default or custom) and propagates its routes to one or more route tables. Use static routes for NVA-based spokes.
• A hub with Azure Firewall is a secured virtual hub, managed through Azure Firewall Manager.

3. Application Delivery Services (15–20%)

Four services distribute traffic in Azure, and the exam is mostly about picking the right one. Scope (global vs regional) and layer (L4 vs L7 vs DNS) decide it.

Azure Load Balancer

A Layer 4 (TCP/UDP) load balancer for VMs and services inside a VNet.

• Public Load Balancer has a public frontend IP; Internal Load Balancer has a private one.
• Health probes: TCP, HTTP or HTTPS (HTTPS on Standard only). A failed instance stops receiving new connections.
• Distribution mode: default is a 5-tuple hash. Session persistence (source IP affinity, 2- or 3-tuple) keeps a client on the same backend.
• HA ports: one rule that balances all ports and protocols on an internal Standard LB, typical for NVAs.
• Floating IP (Direct Server Return): needed for scenarios such as SQL Always On listeners.
• Inbound NAT rules: port forwarding from a frontend port to one specific backend VM (for example RDP to a single VM).
• Outbound rules: control SNAT for the backend pool (source IPs, port ranges, protocols).

Global (Cross-Region) Load Balancer

A Layer 4 global load balancer that sits in front of regional Standard Load Balancers. It uses a single static anycast IP and routes to the closest healthy region based on geo-proximity. Unlike Traffic Manager, it does not rely on DNS.

• Needs a global-tier Standard public IP as frontend and regional Standard Load Balancers as backends.
• Preserves the client source IP and fails over automatically if a region becomes unhealthy.

Azure Application Gateway

A Layer 7 load balancer that routes on the content of the HTTP/HTTPS request (URL path, host header, query string). Use the v2 SKU (Standard_v2 / WAF_v2): autoscaling, zone redundancy, static VIP. v1 is retired. It needs its own dedicated subnet (/24 recommended for v2).

1. Frontend IP: public, private, or both.
2. Listeners: a basic listener captures all requests on an IP/port; a multi-site listener inspects the Host header so you can host several domains on one IP.
3. Routing rules: bind a listener to a backend pool. Basic routing sends everything to one pool; path-based routing sends /images/* and /video/* to different pools.
4. Backend pools: VMs, VM Scale Sets, App Services, or external IPs/FQDNs.
5. HTTP settings: how the gateway talks to the backend (port, protocol, cookie-based affinity, connection draining).
6. Health probes: unhealthy servers are removed from rotation and re-added once they recover. The default probe checks / on the backend port; use a custom probe for a specific path, host or status codes.

Redirection rules make a routing rule send an HTTP redirect instead of forwarding to a pool:

• Types: Permanent (301), Temporary (307), Found (302), See other (303).
• Target: another listener (typical for HTTP to HTTPS, configured once for all paths) or an external site.
• Optionally include the query string and the path.

• TLS termination: the gateway decrypts (certificate on the listener) and talks plain HTTP to the backend. This offloads CPU and lets the WAF inspect the traffic.
• End-to-end TLS: the gateway decrypts, inspects/routes, then re-encrypts to the backend. The backend certificate or its trusted root must be configured.
• Rewrite rules modify headers and URLs.

Azure Traffic Manager

A DNS-based global traffic load balancer. Clients connect directly to the endpoint, Traffic Manager never sees the traffic, so it works for any protocol.

• Nested profiles: a profile can be an endpoint of another profile to combine methods (for example Geographic at the top, Performance in each region).
• Endpoint types: Azure, External, Nested.
• Health probes: HTTP, HTTPS or TCP. Unhealthy endpoints are removed from DNS answers.
• TTL controls how long clients cache the answer, which affects failover speed.

Azure Front Door

A global Layer 7 entry point on Microsoft's edge network, combining load balancing, TLS offload, caching, acceleration, and a global WAF.

• Endpoint, Route, Origin group, Origin: a route maps a domain/path pattern to an origin group; the origin group holds the backends plus health probe and load-balancing settings.
• Origin selection: lowest latency (default), priority or weighted, with optional session affinity.
• Custom domains with Front Door-managed or your own TLS certificates; TLS terminates at the edge.
• Rule sets: URL redirect/rewrite, header modification, route overrides.
• WAF: global policy (managed rules, bot protection, rate limiting) attached to the endpoint.
• Tiers: Standard (content delivery, acceleration, WAF custom rules) and Premium (adds Private Link origins to reach private backends, plus managed WAF rule sets and bot protection).

Choosing the Right Service

App Service Networking

App Service (Web Apps, Functions) is PaaS with a public endpoint by default. Know which feature covers which direction:

4. Private Access to Azure Services (10–15%)

Three features keep PaaS traffic off the public internet, and the exam constantly asks you to choose between them.

Service Endpoints

A service endpoint extends your subnet's identity to supported PaaS services (Storage, SQL, Key Vault, and others) over the Azure backbone. The service's firewall can then allow only your subnet, but the service keeps its public IP.

• Enabled per subnet, per service (for example Microsoft.Storage). Free.
• Not usable from on-premises. Use a private endpoint for that.
• Service endpoint policy restricts which specific resources (for example certain storage accounts) a subnet can reach through the endpoint. Supported for Azure Storage.

Private Endpoints

A private endpoint is a network interface in your VNet with a private IP that connects you to a service powered by Private Link. It effectively brings the service into your VNet.

Network policies: by default, NSGs and UDRs are not applied to traffic going to a private endpoint. Enable the subnet setting PrivateEndpointNetworkPolicies (Disabled, Enabled, NetworkSecurityGroupEnabled, RouteTableEnabled) on the subnet that hosts the endpoints to filter with an NSG or route with a UDR (for example a /32 route through Azure Firewall).

Private Link Service

Private Link and Private Endpoint are two halves of one system: Private Link is the service provider side (the socket), the private endpoint is the consumer side (the plug). Microsoft runs the Private Link side for its own PaaS services. To publish your own app:

• Put it behind a Standard Load Balancer.
• Create the Private Link service with a NAT IP (the source IP the provider sees instead of the consumer's IP) and set visibility/auto-approval by subscription.
• Consumers create a private endpoint that points to it.

Service Endpoint vs Private Endpoint vs Private Link Service

5. Network Security Services (15–20%)

From filtering at the NIC up to global WAF and DDoS protection. Rule order and evaluation details are what get tested.

NSGs, ASGs & Service Tags

• Priority: each rule has a priority from 100 to 4096. Lower numbers are evaluated first and the first match wins.
• Default rules (priority 65000–65500) can't be deleted, only overridden: AllowVnetInBound, AllowAzureLoadBalancerInBound, DenyAllInBound, and their outbound equivalents.
• NSGs are stateful: if a rule allows inbound traffic, the return traffic is allowed automatically (and vice versa).
• An NSG can be attached to a subnet and/or a NIC. Both are evaluated: inbound hits the subnet NSG first, then the NIC NSG; outbound is the reverse.
• Service tags are Microsoft-managed labels for groups of IP prefixes (VirtualNetwork, Internet, AzureLoadBalancer), so rules don't need individual IPs.
• Application security groups (ASGs) group VMs/NICs by application role so rules reference the group instead of IPs. All NICs in an ASG must be in the same VNet.

Azure Bastion

Managed RDP/SSH to VMs through the portal without public IPs on the VMs. It needs a subnet named AzureBastionSubnet of at least /26 and a Standard public IP.

• SKUs: Developer (free, shared, one VM at a time), Basic, Standard (native client, IP-based connection, file transfer, scaling), Premium (session recording, private-only deployment).
• An NSG on AzureBastionSubnet is optional. If you use one, inbound must allow 443 from Internet (users), 443 from GatewayManager (control plane), 443 from AzureLoadBalancer (health probes), and 8080/5701 between Bastion hosts.
• Outbound must allow 3389 and 22 to the target VMs (VirtualNetwork), 443 to AzureCloud, 80 to Internet, and 8080/5701 between hosts. Note that 3389/22 are outbound from Bastion to the VMs, not inbound.

Azure Firewall

A managed, stateful Layer 3–7 firewall for inbound, outbound and spoke-to-spoke traffic, typically in a hub VNet. It needs a subnet named AzureFirewallSubnet (/26 or larger); the Basic SKU also needs AzureFirewallManagementSubnet (/26). To send spoke traffic through it, add a UDR (0.0.0.0/0 with next hop the firewall's private IP).

• Basic: lower cost, up to 250 Mbps, for small and medium businesses.
• Standard: L3–L7 filtering, threat intelligence, FQDN/service tags, DNS proxy (up to 30 Gbps).
• Premium: adds TLS inspection, IDPS, URL filtering and web categories (up to 100 Gbps).

• Network rules: allow/deny by IP, port, protocol, service tag, or FQDN. Works for any protocol.
• Application rules: outbound HTTP/HTTPS/MSSQL by FQDN, FQDN tag, and (Premium) URL or web category.
• DNAT rules: translate an inbound public IP:port to a private IP:port to publish internal services.
• FQDN tags are Microsoft-managed groups of domain names for a well-known service (for example WindowsUpdate, Microsoft365, AzureKubernetesService). They work only in application rules. A service tag is a list of IP prefixes (NSGs and network rules); an FQDN tag is a list of domains.
• Azure Firewall Manager governs multiple firewalls centrally. A reusable firewall policy can be shared (base policy plus per-region child policies), and it works with secured virtual hubs in Virtual WAN.

Web Application Firewall (WAF)

Protects web apps from SQL injection, XSS and other OWASP Top 10 attacks. It is deployed on Application Gateway (regional, WAF_v2 SKU) or Front Door (global).

• Modes: detection (log only) or prevention (block).
• Managed rule sets: Microsoft-maintained (OWASP CRS / Default Rule Set, plus Bot Protection). Use exclusions to avoid false positives.
• Custom rules: your own match conditions with allow/block/log, evaluated before managed rules in priority order.
• Rate limiting throttles requests per client.
• Microsoft Threat Intelligence Collection uses Microsoft's threat intelligence to detect and mitigate known malicious IPs, domains and URLs.

On Application Gateway the policy hierarchy, from highest to lowest priority, is URI path-level (overrides everything for that exact path), then per-site / listener-level, then global-level (the default fallback for the whole gateway).

Azure DDoS Protection

• Infrastructure protection: free and automatic for all public IPs; protects the Azure platform itself.
• Network Protection: paid, enabled per VNet (covers all public IPs in it). Adds adaptive tuning, attack metrics/alerts/logs, cost protection, DDoS Rapid Response support, and WAF discounts.
• IP Protection: paid, enabled per public IP; same mitigation without cost protection, rapid response and WAF discounts.
• Covers L3/L4 attacks. Use a WAF for L7 attacks.

A DDoS protection plan is the resource that enables Network Protection (IP Protection needs no plan). Create it once and associate VNets with it. One plan can cover multiple VNets across subscriptions in the same Microsoft Entra tenant, so one plan per tenant is usually enough. It protects the public IPs of resources in those VNets (VMs, Load Balancer, Application Gateway, Azure Firewall, Bastion), but not PaaS services outside your VNet such as App Service.

Azure Virtual Network Manager (AVNM)

Applies connectivity and security configuration across many VNets at once, instead of per VNet.

• Network groups: logical groups of VNets, static or dynamic via Azure Policy conditions.
• Connectivity configuration: builds mesh or hub-and-spoke topologies without manual peerings.
• Security admin rules: organization-wide rules evaluated before NSG rules. They can allow, deny, or always-allow, so central teams can enforce a baseline that individual NSGs can't override.

6. Network Monitoring with Network Watcher

Network Watcher is a regional service with diagnostic tools for Azure network resources. It is enabled automatically in a region when you create a VNet there.

Connection Monitor & On-Premises Sources

Connection Monitor sources can be Azure VMs/scale sets (with the Azure Monitor Agent or the Network Watcher extension) and on-premises machines. For on-premises, the Azure Connected Machine agent registers servers as Azure Arc-enabled servers, so they appear as Azure resources and can be used (together with the Azure Monitor Agent) to measure connectivity and latency from on-premises. The agent connects outbound over HTTPS (443); for private-only setups use an Azure Arc Private Link Scope with private endpoints.

Flow Logs

Flow logs record IP traffic metadata into a storage account, optionally analyzed with Traffic Analytics (Log Analytics).

• VNet flow logs (recommended): enabled at VNet, subnet or NIC level, cover all workloads, and include traffic evaluated by NSGs and AVNM admin rules.
• NSG flow logs: per NSG only; being retired in favor of VNet flow logs.

One record per flow, with this tuple format:

[Timestamp],[Src IP],[Dst IP],[Src Port],[Dst Port],[Protocol],[Direction],[Flow State],[Encryption],[Packets Src->Dst],[Bytes Src->Dst],[Packets Dst->Src],[Bytes Dst->Src]
1768384980984,10.1.1.4,10.0.1.4,42394,80,6,I,E,NX,5,679,4,1329

The example is a TCP flow (protocol 6), Inbound, flow End (B = begin, C = continuing, D = denied), NX = not encrypted.

Troubleshooting Commands

# Which routes actually apply to this NIC? (UDR vs BGP vs system)
az network nic show-effective-route-table \
  --resource-group rg-net --name nic-web01 --output table

# Which NSG rules actually apply to this NIC?
az network nic list-effective-nsg \
  --resource-group rg-net --name nic-web01

# Where does traffic from this VM go next?
az network watcher show-next-hop \
  --resource-group rg-net --vm vm-web01 \
  --source-ip 10.0.1.4 --dest-ip 10.0.2.4

# Apply NSGs and UDRs to private endpoint traffic in this subnet
az network vnet subnet update \
  --resource-group rg-net --vnet-name vnet-hub --name snet-pe \
  --private-endpoint-network-policies Enabled

7. Special Subnets Cheat Sheet

Subnet names and sizes are easy exam points. Memorize this table.

AZ-700 rewards people who understand how the pieces interact: DNS plus private endpoints, UDRs plus firewalls, gateways plus peering. If you can explain why a packet takes a specific path in each of those combinations, you are ready.

Good luck with your AZ-700 preparation!