AZ-700 Crash Course
AZ-700 Exam Crash Course
Three-part intensive covering all five AZ-700 domains — subnet math, routing, connectivity services, load balancing, private access, and network security. Includes five scenario questions and ten exam-day cheats to memorise cold.
D1 · Core Networking Infrastructure (25–30%)
Subnet math, routing precedence, DNS Private Resolver, Network Watcher, UDRs
Subnet Mathematics — Know Cold
Every Azure subnet reserves 5 addresses: x.x.x.0 → Network address x.x.x.1 → Default gateway (Azure) x.x.x.2 → Azure DNS mapping x.x.x.3 → Azure DNS mapping x.x.x.255 → Broadcast /24 = 256 total → 251 usable /27 = 32 total → 27 usable /28 = 16 total → 11 usable /29 = 8 total → 3 usable (minimum subnet size)
Special Subnet Reserved Names & Sizes
| Subnet Name | Min Size | Rule |
|---|---|---|
| GatewaySubnet | /27 (rec) | Exact name required. Only ONE per VNet |
| AzureFirewallSubnet | /26 | No NSGs. No route tables (normally) |
| AzureFirewallManagementSubnet | /26 | For forced tunnelling only |
| AzureBastionSubnet | /26 | Dedicated to Bastion only |
| RouteServerSubnet | /27 | Fully reserved for Route Server |
| DNS Resolver subnet | /28 | Delegated to Microsoft.Network/dnsResolvers |
Routing Precedence (same prefix length)
1. UDR (User-Defined Routes) — ALWAYS wins 2. BGP routes (ExpressRoute/VPN) — second 3. System routes (default) — last Longest prefix match selects candidates first: A /32 route beats /24 beats /16 — regardless of source
DNS Private Resolver — Direction Matters
- Inbound endpoint — On-premises DNS servers forward queries INTO Azure. They forward e.g. contoso.internal to the inbound endpoint IP, which then resolves via Azure Private DNS Zones.
- Outbound endpoint + Forwarding Ruleset — Azure VMs forward specific domains OUT to on-premises DNS. E.g., corp.local → 192.168.1.10. All other queries still go to Azure DNS.
Network Watcher: Right Tool for Each Problem
| Problem | Tool |
|---|---|
| Is this flow blocked by an NSG? | IP Flow Verify |
| Where does this packet get routed? | Next Hop |
| Monitor 24/7 with latency alerts | Connection Monitor |
| Capture packets on a NIC | Packet Capture |
| Analyse traffic patterns & threats | Traffic Analytics |
D2 · Connectivity Services (20–25%)
VPN Gateway, ExpressRoute, Virtual WAN, peering gateway transit
VPN Gateway — Key Facts
- Basic SKU: NO BGP, NO P2S with IKEv2/Entra, NO zone redundancy — avoid for production
- VpnGw1-3 AZ: zone-redundant, 30 S2S tunnels, 250-500 P2S connections
- VpnGw4-5 AZ: 100 S2S tunnels, 1000-10,000 P2S connections
- P2S + Entra ID auth → must use OpenVPN tunnel type
- IKE Phase 1 fails → authentication error (wrong shared key, expired cert)
- IKE Phase 2 fails → IPsec parameter mismatch (encryption/integrity/DH group)
ExpressRoute — Critical Distinctions
- Private peering: Access to Azure VNet resources via private IPs
- Microsoft peering: Access to Azure PaaS services and Microsoft 365 via public IPs
- Standard SKU: Same geopolitical region only (e.g., Europe)
- Premium SKU: All Azure regions globally + 10,000 route table limit
- Local SKU: Same metro area only, egress data transfer included free
- No encryption: Use VPN-over-ER for encryption. MACsec = Direct connections only
- FastPath: Only on ErGw3AZ (UltraPerformance). Does NOT extend to peered VNets
- Global Reach: Connects two ER circuits so two on-premises networks communicate via Microsoft backbone
Virtual WAN — What the Exam Tests
- Migration sequence: Create VWAN → Delete existing peerings → Connect spokes → Update UDRs
- Basic SKU: S2S VPN only. Standard SKU: P2S, ExpressRoute, inter-hub, Secured Virtual Hub
- Secured Virtual Hub = Virtual WAN hub + Azure Firewall
- Routing Intent: enables Azure Firewall to inspect all private or Internet traffic automatically
- VNet connection must propagate routes to defaultRouteTable for spoke-to-spoke transit
D3 · Application Delivery Networks (15–20%)
Load Balancing Quick Selection
| Scenario | Service |
|---|---|
| Regional L4, TCP/UDP, VM backends | Azure Load Balancer (Standard) |
| Regional L7, HTTP(S), WAF, URL routing | Azure Application Gateway (v2) |
| Global L7, HTTP(S), WAF, CDN, Anycast | Azure Front Door (Premium) |
| Global DNS, any protocol, non-HTTP failover | Azure Traffic Manager |
| Global L4 TCP across regional Standard LBs | Cross-Region Load Balancer |
| Transparent NVA insertion into traffic path | Gateway Load Balancer |
Application Gateway — Exam Targets
- v2 SKU only: autoscaling, zone redundancy, static VIP, header/URL rewrite, WAF v2
- WAF modes: Detection (log, no block) → Prevention (log + block)
- Custom WAF rules evaluated BEFORE managed rule sets
- NSG on backend subnet must allow App Gateway subnet + GatewayManager tag (ports 65200-65535)
- Health probe failures: NSG blocks, wrong port/path, probe timeout too short
Load Balancer — Key Points
- Standard LB: secure by default — NSG must explicitly allow traffic to backends
- Standard LB does NOT provide outbound connectivity — add NAT Gateway or explicit outbound rules
- HA Ports rule: load balances ALL TCP/UDP ports simultaneously on internal LB (for NVAs)
- NAT Gateway overrides all other outbound SNAT methods on the subnet
D4 · Private Access to Azure Services (10–15%)
Service Endpoint vs Private Endpoint — The Key Differences
- Service Endpoint: free, per-subnet, uses public IP, no on-premises access
- Private Endpoint: costs money, per-endpoint, private IP, on-premises access via VPN/ER + DNS
- Private Endpoint DNS chain: FQDN → CNAME (privatelink.service.azure.com) → A record → private IP
- Every VNet needing private resolution must have its own Private DNS Zone VNet link
- Enable privateEndpointNetworkPolicies to apply NSG rules to Private Endpoint traffic
Private Link Service — Exposing Your Own Service
- Lets you expose a service behind a Standard Internal Load Balancer to other tenants
- Consumer creates a Private Endpoint in their VNet pointing to your Private Link Service
- You control access via connection approval — no VNet peering required
D5 · Network Security (15–20%)
NSG Evaluation — The Two Rules
- Inbound: Subnet NSG → NIC NSG. Both must allow. Evaluated in priority order (lowest number first).
- Outbound: NIC NSG → Subnet NSG. Both must allow.
- Default rules at 65500: DenyAllInbound, DenyAllOutBound. At 65000: AllowVNet. At 65001: AllowLoadBalancer/AllowInternetOutbound.
Azure Firewall — Rule Processing
1. DNAT rules → Inbound NAT (publish a service) 2. Network rules → L3/L4 filtering (IP, port, protocol) 3. Application rules → L7 filtering (FQDN, URL, web category) 4. Default deny → Implicit — all non-matched traffic dropped
- Standard: Threat intelligence, FQDN application rules, URL filtering (by SNI)
- Premium: Standard + TLS inspection, IDPS signatures, full URL filtering
- AzureFirewallSubnet: No NSG. No route table (in normal scenarios).
Azure Virtual Network Manager (AVNM)
- Security Admin Rules are evaluated BEFORE NSG rules
- AlwaysAllow bypasses NSG entirely — NSG Deny cannot override it
- Regular Allow passes, then NSG evaluates — NSG Deny can still block
- Dynamic Network Groups use Azure Resource Graph queries to auto-populate VNets
Azure Bastion
- Basic SKU: browser-based RDP/SSH, no file transfer, no native client
- Standard SKU: native client support, file transfer, shareable links, peered VNet access
- Premium SKU: session recording, private-only (no public IP) deployment
DDoS Protection
- DDoS Network Protection: protects all public IPs in a VNet, flat monthly fee, includes Rapid Response team
- DDoS IP Protection: per-public-IP, ~$199/month, does not include Rapid Response
- Both protect Layer 3/4 only. Layer 7 (HTTP floods) requires WAF on App Gateway or Front Door
5 Hard Scenario Questions — Think Before Reading the Answer
Scenario 1: Spoke-A VMs can reach the firewall (10.0.1.4) and the Internet. They cannot reach Spoke-B VMs. Spoke-B VMs can reach the firewall and the Internet. What is the most likely single missing configuration?
Answer: UDRs are missing on Spoke-A's subnet routing Spoke-B's address space (10.2.0.0/16) to VirtualAppliance (10.0.1.4 — the Firewall). If firewall logs show no traffic from Spoke-A towards Spoke-B, the packet never reaches the Firewall — the UDR is missing, not the Firewall rule.
Scenario 2: VPN tunnel is Connected in the portal. On-premises host cannot reach Azure VMs. Firewall logs show traffic from on-premises allowed. Azure VMs have no return path visible in logs. What is the root cause?
Answer: GatewaySubnet is missing a UDR routing spoke VNet prefixes back through the Firewall. Return traffic from spoke VMs reaches the Firewall, but the Firewall has no route back to the VPN Gateway to send it on-premises. Fix: add a route table to GatewaySubnet with spoke VNet prefixes → Firewall private IP.
Scenario 3: All VMs in the hub VNet resolve sql01.database.windows.net to 10.0.5.4 (private). VMs in Spoke-A resolve to 52.x.x.x (public). No other changes were made. What is missing?
Answer: The Private DNS Zone (privatelink.database.windows.net) has a VNet link to the hub VNet but NOT to Spoke-A VNet. Add a VNet link to the Private DNS Zone for Spoke-A (resolution only — auto-registration not needed).
Scenario 4: Azure Firewall Standard has an Application rule allowing *.microsoft.com on port 443 (priority 300), and a Network rule allowing TCP 443 from spoke to Any (priority 200). VMs can reach non-Microsoft HTTPS sites but get blocked on *.microsoft.com. Is this expected?
Answer: YES — this is expected and is a configuration error. The Network rule at priority 200 matches ALL TCP 443 traffic (including *.microsoft.com) before the Application rule at 300 is evaluated. The Network rule allows the traffic without FQDN inspection. The Application rule is never reached. To restrict to specific FQDNs, remove the catch-all Network rule for port 443 and rely only on Application rules.
Scenario 5: An Azure Standard Load Balancer health probe (TCP 443) reports all backend VMs as Unhealthy. VMs are reachable on port 443 from other VMs in the same VNet. The backend subnet NSG allows TCP 443 from 10.0.0.0/16. What is wrong?
Answer: Azure Load Balancer health probes originate from 168.63.129.16 — which is OUTSIDE 10.0.0.0/16. The NSG rule does not match probe traffic. Fix: add an inbound NSG rule allowing the AzureLoadBalancer service tag on TCP 443, or allow 168.63.129.16/32 specifically.
10 Exam-Day Cheats — Memorise These Cold