Domain 4: Implement and Manage Virtual Networking (15-20%)
What this domain actually covers
Everything that carries a packet in Azure.
Virtual networks. VNet address space (RFC1918 + optional IPv6), subnets, subnet delegation, subnet reservations (5 IPs per subnet), VNet peering (regional and global), gateway transit, service endpoints, private endpoints.
Filtering. Network Security Groups (5-tuple stateful rules, priority order, default rules), Application Security Groups (logical grouping of NICs), Azure Firewall (application/network/NAT rules, threat intel, Premium features: TLS inspection + IDPS).
Routing. System routes, user-defined routes (UDR), route table associations, next hop types (VirtualAppliance, VirtualNetworkGateway, Internet, VNet, None).
Public connectivity. Public IP (Basic being retired, Standard is required for new; static vs dynamic), Standard Load Balancer (Layer 4, 5-tuple hashing, backend pools, health probes, session persistence, outbound rules), NAT Gateway.
Layer 7 + global. Application Gateway (v2 with WAF, host-based/path-based routing), Front Door (global L7 with WAF + caching), Traffic Manager (DNS-based global routing).
Hybrid. Site-to-site VPN (VpnGw SKUs, IKEv2/IKEv1, BGP, active-active), Point-to-site VPN (OpenVPN/IKEv2/SSTP, cert/RADIUS/Entra ID auth), VNet-to-VNet VPN, ExpressRoute (circuit + private/Microsoft peering, gateway SKUs).
DNS. Public DNS zones (Azure-hosted authoritative), Private DNS zones (VNet-linked resolution, registration links), DNS Private Resolver (for on-prem to Azure resolution).
Diagnostics. Network Watcher (IP flow verify, NSG diagnostics, effective routes, connection troubleshoot, VPN diagnostics, packet capture, connection monitor).
Questions
Q1
Default number of USABLE IP addresses in a /24 subnet in Azure?- A. 256
- B. 254
- C. 251
- D. 250
Show answer & explain every option
Correct: C
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real address count before reservations: a /24 contains 256 total addresses, not 256 assignable VM addresses.
Why this is not the answer
Traditional subnet calculation: subtracting only network/broadcast misses Azure's additional reserved addresses.
✓ Correct choice
Correct Azure calculation: 256 total addresses minus five Azure-reserved addresses leaves 251 usable.
Why this is not the answer
Numeric distractor: subtracting six addresses does not match Azure's standard five-address subnet reservation.
The reasoning
Azure reserves 5 IPs per subnet: network address, Azure default gateway, two for Azure-provided DNS, broadcast equivalent. 256 - 5 = 251 usable. Exam trap: on-prem admins expect 254 (network + broadcast only); Azure loses three more.
Q2
Two VNets are peered. VNet A has a VPN gateway to on-prem. VMs in VNet B need to reach on-prem via A's gateway. Requirements?- A. Automatic once peered
- B. On VNet B's peering: "Use remote gateways." On VNet A's peering: "Allow gateway transit."
- C. Requires a third-party NVA
- D. Not supported; peering never allows transit
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
False default: peering alone does not automatically share a VNet gateway with the remote network.
✓ Correct choice
Real gateway-transit configuration: the gateway VNet permits transit and the other VNet uses its remote gateway.
Why this is not the answer
Real routing appliance, unnecessary requirement: supported gateway transit does not inherently require a third-party NVA.
Why this is not the answer
False blanket restriction: ordinary peering is non-transitive, but explicitly configured gateway transit is supported.
The reasoning
Both flags on their respective sides of the peering. Classic hub-and-spoke pattern: hub owns the gateway; spokes consume it via transit. Reminder: VNet peering is NOT transitive. Spoke A cannot reach Spoke B through the hub without extra routing (route tables + NVA or Virtual WAN).
Q3 (multi-answer)
Which are TRUE about NSG rules?- A. Rules evaluate by priority, lowest number first
- B. First match stops evaluation
- C. Default rules exist (AllowVnetInBound, DenyAllInBound, etc.) at priority 65000+
- D. NSGs are attached to NICs OR subnets (or both simultaneously)
- E. NSGs are stateful
Show answer & explain every option
Correct: A, B, C, D, E
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
True priority rule: lower numeric NSG priorities are evaluated first.
✓ Correct choice
True match behavior: the matching applicable allow/deny rule determines the NSG verdict.
✓ Correct choice
Real default rules: built-in priorities occupy the documented high-numbered range.
✓ Correct choice
Real association choices: subnet and NIC NSGs can both apply, and both must permit the flow.
✓ Correct choice
True statefulness: return traffic for an allowed connection is tracked; changing rules does not necessarily terminate existing flows.
The reasoning
(all true)
NSGs are stateful firewalls with priority-ordered rules. Default rules occupy 65000-65500 and cannot be deleted but can be overridden by higher-priority (lower number) custom rules. Both NIC and subnet attachment are supported; when both, inbound evaluates subnet first then NIC, and outbound evaluates NIC first then subnet.
Q4
Application Gateway v2 hosting multiple websites. What routes traffic to the correct backend?- A. Path-based rule
- B. Multi-site listener with host-based routing (SNI)
- C. NSG
- D. Both A and B depending on the routing need
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real routing rule: path-based routing sends URL paths such as /api to selected pools; it is one possible routing requirement. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real listener: multi-site listeners distinguish hostnames, enabling multiple sites on the gateway. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real packet filter: NSGs filter network traffic and do not choose HTTP backend pools from URL paths or host headers.
✓ Correct choice
Valid combination: listeners distinguish websites while path maps can divide traffic within them, depending on the design.
The reasoning
Multi-site listener uses the HTTP Host header (and TLS SNI for HTTPS listener/certificate selection) to pick a backend site. Path-based rules route by URL path within a site. Combine them for complex apps. NSGs work at Layer 4 and cannot see HTTP host/path.
Q5
Which load balancer operates at Layer 7 with SSL termination and URL-based routing?- A. Basic Load Balancer
- B. Standard Load Balancer
- C. Application Gateway
- D. Traffic Manager
Show answer & explain every option
Correct: C
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real retired Layer-4 SKU: Basic Load Balancer distributes transport flows, not URL paths or TLS termination.
Why this is not the answer
Real Layer-4 service: Standard Load Balancer handles TCP/UDP flows rather than HTTP routing and TLS offload.
✓ Correct choice
Real Layer-7 gateway: Application Gateway supports HTTP-aware routing and TLS termination.
Why this is not the answer
Real DNS router: Traffic Manager returns endpoint DNS answers and does not proxy or terminate the application's TLS connection.
The reasoning
Application Gateway is Layer 7 (HTTP/S). Basic and Standard LB are Layer 4 (TCP/UDP). Traffic Manager is DNS-based (no application traffic passes through it). Front Door is another Layer 7 option, global.
Q6 (multi-answer)
Valid Azure Firewall rule types (pick three)?- A. Application rules (FQDN filtering)
- B. Network rules (IP/port/protocol)
- C. NAT rules (DNAT inbound)
- D. Route rules (change next hop)
- E. Threat Intelligence rules (deny/alert on known-bad IPs)
Show answer & explain every option
Correct: A, B, C
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real rule collection: application rules filter supported application protocols/FQDNs.
✓ Correct choice
Real rule collection: network rules match IP addresses, ports and protocols.
✓ Correct choice
Real rule collection: DNAT rules translate and permit configured inbound flows.
Why this is not the answer
Real routing concept, wrong collection: route tables set next hops; Route is not an Azure Firewall rule-collection type.
Why this is not the answer
Real protection feature: threat intelligence can alert/deny, but is not one of the three named rule-collection types.
The reasoning
Azure Firewall has three authorable rule collections: Application, Network, NAT. Threat Intel is a global toggle (Off / Alert only / Alert and deny), not a rule you author. Route changes belong on a UDR. Firewall must live in a subnet named exactly AzureFirewallSubnet.
Q7
Cross-subscription VNet peering in the same tenant. What role is needed on both sides?- A. Global Administrator on the tenant
- B. Network Contributor (or role with peering permissions) on both VNets
- C. Owner on both subscriptions
- D. Cross-subscription peering is not supported
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real directory role, wrong plane: Global Administrator does not automatically grant Azure VNet peering permissions.
✓ Correct choice
Real network role: Network Contributor or suitably scoped custom permissions can configure both peering ends.
Why this is not the answer
Real role, excessive privilege: Owner can perform the work but grants more access than peering requires.
Why this is not the answer
False restriction: authorized cross-subscription VNet peering is supported.
The reasoning
Cross-subscription peering (same tenant) requires Network Contributor (or similar) on BOTH VNets. Cross-tenant peering also works but needs role assignments in the other tenant. Peering is a two-sided object; both halves must exist for it to be functional.
Q8
Standard Load Balancer requires which Public IP SKU on its frontend?- A. Basic
- B. Any SKU if the public IP is static
- C. Either
- D. SKUs must match; Standard LB requires Standard PIP
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real retired Public IP SKU, incompatible: a Basic public IP does not match a Standard load balancer frontend.
Why this is not the answer
False compatibility rule: static allocation alone does not override the requirement for compatible SKUs.
Why this is not the answer
False equivalence: Basic and Standard public IPs are not interchangeable on the Standard frontend.
✓ Correct choice
Real compatibility requirement: the public frontend IP must use the Standard SKU.
The reasoning
SKUs must match. Basic PIP with Standard LB fails. Basic SKUs (Public IP and Load Balancer) were retired September 30, 2025; migrate remaining Basic resources using the documented upgrade path. Standard PIPs are zone-redundant by default in regions with zones and required for many features (LB frontends, App Gateway v2, NAT Gateway).
Q9
You need transparent encryption of inter-VM traffic within a VNet, no app changes. Feature?- A. Azure Bastion
- B. Azure Virtual Network encryption (requires supported VM configurations)
- C. Application Gateway with SSL passthrough
- D. VPN gateway VNet-to-VNet
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real administrative-access service: Bastion brokers RDP/SSH; it does not transparently encrypt all inter-VM traffic.
✓ Correct choice
Real network feature: VNet encryption protects supported VM-to-VM traffic without rewriting the application; verify supported configurations.
Why this is not the answer
Incorrect gateway feature combination: Application Gateway is an HTTP proxy, not transparent arbitrary inter-VM encryption via SSL passthrough.
Why this is not the answer
Real tunnel feature: a VNet-to-VNet VPN secures traffic between gateway-connected networks, not all local inter-VM flows transparently.
The reasoning
VNet Encryption encrypts inter-VM traffic within a VNet at the SmartNIC layer, transparent to VMs. Requires supported VM SKUs. Bastion is a jump-host service (RDP/SSH). VPN VNet-to-VNet encrypts across VNets via VPN gateways, not within a VNet.
Q10
Which service provides a private low-latency circuit between on-prem and Azure with BGP peering?- A. Site-to-site VPN over the internet
- B. Point-to-site VPN
- C. ExpressRoute
- D. Azure Front Door
Show answer & explain every option
Correct: C
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real encrypted connectivity: site-to-site VPN normally crosses the public internet rather than a dedicated private circuit.
Why this is not the answer
Real remote-user VPN: point-to-site connects individual clients, not a private enterprise circuit with the requested peering.
✓ Correct choice
Real private connectivity service: ExpressRoute uses provider connectivity and BGP; performance depends on circuit and gateway design.
Why this is not the answer
Real global HTTP proxy: Front Door accelerates/routes web requests, not private on-premises circuit connectivity.
The reasoning
ExpressRoute (through a Microsoft Enterprise Edge partner: Equinix, Megaport, and others) provides a private circuit. S2S VPN traverses the internet with IPsec; its SLA depends on configuration. Availability depends on the selected topology and applicable SLA. BGP is required for private peering.
Field anchor: you have shipped ExpressRoute. Exam trap: ExpressRoute is layered (circuit + peering + gateway); a provider-based connection and ExpressRoute Direct have different provisioning models; the ExpressRoute circuit is a logical connection.
Q11
Which listed VPN Gateway SKU supports the highest aggregate throughput?- A. VpnGw1
- B. VpnGw3
- C. VpnGw5
- D. Basic
Show answer & explain every option
Correct: C
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real VPN SKU: VpnGw1 has a lower documented aggregate throughput benchmark than the highest listed SKU.
Why this is not the answer
Real VPN SKU: VpnGw3 offers more capacity than lower tiers, but less than the listed VpnGw5 benchmark.
✓ Correct choice
Real VPN SKU: VpnGw5 is the highest-throughput choice in this list; actual throughput depends on workload and tunnels.
Why this is not the answer
Real legacy gateway SKU: Basic has substantially lower capabilities and is not the highest-throughput option.
The reasoning
VpnGw5 tops the current SKU ladder at 10 Gbps aggregate. VpnGw1/2/3/4/5 scale up tunnels/throughput. Basic is limited to a 100-Mbps benchmark, up to 10 S2S tunnels, and lacks BGP, active-active and ExpressRoute coexistence. The corresponding VpnGw5AZ SKU also has a 10-Gbps aggregate benchmark. Move off Basic for anything production.
Q12 (scenario)
Route all outbound internet traffic from a subnet through a network virtual appliance. What do you configure?- A. NSG deny rule on 0.0.0.0/0
- B. UDR: 0.0.0.0/0 next hop
Virtual Appliance-> NVA IP - C. Peering with the NVA VNet + gateway transit
- D. Enable service endpoints
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real filter: denying traffic blocks it rather than routing it through an appliance.
✓ Correct choice
Real routing rule: a default UDR with virtual-appliance next hop steers traffic to the NVA; forwarding and return paths must also work.
Why this is not the answer
Real peering controls, incomplete: peering/gateway transit alone does not force the desired appliance next hop.
Why this is not the answer
Real service connectivity: service endpoints target supported PaaS access, not generic internet egress inspection.
The reasoning
A UDR in a route table associated with the subnet sets 0.0.0.0/0 with next hop type Virtual Appliance and the NVA's IP. Enable IP forwarding on the NVA's NIC or packets get dropped. NSG deny would just discard traffic. Service endpoints are for Microsoft services, not general internet egress.
Q13
Azure Front Door vs Traffic Manager: primary functional difference?- A. Front Door proxies HTTP(S) traffic; Traffic Manager only returns DNS answers
- B. Front Door supports WAF and TLS offload; Traffic Manager does not
- C. Both A and B
- D. Traffic Manager supports TCP; Front Door does not
Show answer & explain every option
Correct: C
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
True functional distinction: Front Door handles HTTP requests as a proxy; Traffic Manager directs clients through DNS. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
True feature distinction: Front Door provides WAF/TLS capabilities; a DNS response service cannot inspect HTTP payloads or terminate TLS. This is part of the answer; the combined choice includes the other applicable statements too.
✓ Correct choice
Valid combination: both the proxy-versus-DNS distinction and the WAF/TLS implications are correct.
Why this is not the answer
Misleading shorthand: Traffic Manager does not itself carry TCP traffic; it can direct DNS clients for endpoints using various protocols.
The reasoning
Front Door is a full L7 reverse proxy (data plane) with WAF, caching (Standard/Premium), and health probes. Traffic Manager is DNS-based (control plane): clients get an IP from TM's DNS and connect direct to the origin. For HTTP(S) global routing, Front Door is preferred. TM covers non-HTTP protocols and cases where direct client-to-region connectivity is required.
Q14
Which is TRUE about a dedicated Basic-or-higher Azure Bastion deployment?- A. Deploys into a dedicated subnet named
AzureBastionSubnet(/26 minimum) - B. Brokers RDP/SSH via the Azure portal, no client agent, no public IP on target VMs
- C. Standard SKU adds custom port, IP-based connection, native client support
- D. All of the above
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real subnet requirement: dedicated Bastion uses AzureBastionSubnet with the documented minimum prefix; Developer deployments differ. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real access model: portal-based Bastion connects to VM private addresses without requiring a public IP on each target VM. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real Standard features: native-client, IP-based and custom-port features extend Basic capabilities, subject to configuration. This is part of the answer; the combined choice includes the other applicable statements too.
✓ Correct choice
Valid combination for the stated deployment: the dedicated subnet, private-target access and Standard feature distinctions all apply.
The reasoning
Bastion requires AzureBastionSubnet (fixed name) of at least /26. It brokers RDP/SSH via TLS through the portal (Basic) and via native client with Standard SKU. Target VMs need no public IP. Standard supports custom connection ports; session recording requires Premium. The shared Developer SKU does not require a dedicated AzureBastionSubnet.
Q15
Service endpoints vs private endpoints: which is TRUE?- A. Service endpoints extend VNet identity to a PaaS service; traffic uses the Microsoft backbone but the target still has a public IP (firewall-locked)
- B. Private endpoints assign a private IP in your VNet for the PaaS sub-service; DNS resolves to that IP
- C. Service endpoints support cross-region better than private endpoints
- D. A and B
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real service endpoint: subnet identity and service routing protect access to a service still addressed through its public endpoint. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real private endpoint: a VNet private IP represents the service subresource; correct DNS configuration is essential. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Unsupported blanket comparison: cross-region behavior depends on the service and feature; it is not a universal service-endpoint advantage.
✓ Correct choice
Valid combination: the first two accurately distinguish public-service endpoint access from Private Link's private IP.
The reasoning
Service endpoints tag traffic with VNet+subnet metadata that the PaaS firewall enforces; the target keeps a public endpoint. Private endpoints create a NIC in your VNet with a private IP; private DNS zones resolve the PaaS FQDN to that IP. PE is the modern hardening path for regulated workloads.
Q16
Layer 4 load balancer setting that distributes flows using source IP + source port + dest IP + dest port + protocol?- A. Session persistence: None (5-tuple hash)
- B. Session persistence: Client IP (2-tuple)
- C. Session persistence: Client IP and Protocol (3-tuple)
- D. Backend selection: round-robin
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real distribution mode: no session persistence uses the five-tuple, maintaining each flow's backend selection.
Why this is not the answer
Real persistence mode: Client IP uses a two-tuple; it omits ports and protocol from the requested five-tuple model.
Why this is not the answer
Real persistence mode: Client IP and Protocol uses three fields rather than the full five-tuple.
Why this is not the answer
Real algorithm elsewhere, wrong Azure setting: this load-balancer distribution is hash-based, not a configurable round-robin backend selector.
The reasoning
Default Azure LB behavior is 5-tuple hashing. Client IP (2-tuple) sends a client's flows to the same backend consistently. Client IP + Protocol is 3-tuple. There is no "round-robin" option; hashing is the mechanism.
Q17 (multi-answer)
Which two enable outbound internet from VMs behind a Standard Load Balancer?- A. Standard LB outbound rule
- B. NAT Gateway
- C. Public IP on each VM
- D. Azure Firewall SNAT
- E. Rely on default outbound
Show answer & explain every option
Listed key (under review): A, B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Listed key · under review
Real explicit egress: a Standard Load Balancer outbound rule allocates SNAT for eligible backends.
Listed key · under review
Real explicit egress: NAT Gateway provides outbound SNAT for associated subnets.
Alternative · under review
Real explicit egress: a VM public IP can also provide outbound connectivity, so excluding it requires a narrower stem.
Alternative · under review
Real explicit egress: properly routed Azure Firewall can SNAT outbound traffic; the original pick-two wording is incomplete.
Alternative · under review
Legacy implicit egress: do not design on default outbound access; use an explicit supported egress method and check current retirement guidance.
Original explanation · under review
(C and D also work; A and B are Microsoft's recommended scale patterns; E was retired September 30, 2025)
NAT Gateway is the recommended pattern for outbound at scale (predictable SNAT ports, per-subnet association, 64,512 ports per attached PIP). Standard LB outbound rules are also correct. Per-VM public IPs work but do not scale. Default outbound access was retired September 30, 2025; every new deployment must use one of NAT Gateway, LB outbound, per-VM PIP, or firewall SNAT.
Note: SNAT port exhaustion is the top root cause of intermittent outbound failures on LB-only egress; NAT Gateway solves it.
Q18
Lowest priority number (highest precedence) you can assign a custom NSG rule?- A. 1
- B. 100
- C. 65000
- D. 4096
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Numeric distractor: 1 is outside the custom NSG priority range.
✓ Correct choice
Documented minimum: custom NSG priorities start at 100, with smaller numbers evaluated first.
Why this is not the answer
Real default-rule range: priorities around 65000 belong to built-in rules, not user-assigned custom priorities.
Why this is not the answer
Real custom-range endpoint: 4096 is the highest numeric custom priority, meaning lower precedence than 100.
The reasoning
Custom NSG rules use priorities 100 to 4096. Lower number = higher precedence. 100 is the ceiling on precedence for custom rules. Default rules occupy 65000-65500 and cannot be re-prioritized.
Q19
Application Gateway WAF v2: which is TRUE?- A. Managed rulesets include OWASP CRS 3.2 and Microsoft Default Rule Set (DRS)
- B. Custom rules run BEFORE managed rules
- C. WAF has Detection and Prevention modes; policy enabled/disabled state is separate
- D. All of the above
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real managed rulesets: WAF supports documented OWASP/Microsoft ruleset families, with available versions dependent on product support. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
True evaluation order: custom rules are evaluated ahead of managed rules, so their actions affect later processing. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real modes: Detection records matching traffic; Prevention can block it. Policy enablement is a separate control. This is part of the answer; the combined choice includes the other applicable statements too.
✓ Correct choice
Valid combination: all three statements describe distinct WAF configuration/evaluation concepts.
The reasoning
Custom rules always evaluate first. Managed rule sets (such as OWASP CRS 3.2, DRS and Bot Manager) next. Detection mode logs only; Prevention blocks matches; disabling the policy is a separate setting. Per-request exclusions can suppress false positives by header/cookie/argument.
Q20
Which statement describes the documented global VNet peering limitation for legacy Basic Load Balancer frontends?- A. All traffic including transitive routing
- B. Private VM connectivity across regions, but not access to legacy Basic Load Balancer frontends
- C. Only intra-region
- D. Only IPv4
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
False unrestricted claim: VNet peering is not automatically transitive and retains documented endpoint limitations.
✓ Correct choice
Real legacy limitation: global peering can connect VMs privately while legacy Basic load-balancer frontend access is restricted.
Why this is not the answer
False geographic restriction: global peering specifically supports VNets across regions.
Why this is not the answer
False protocol-only explanation: IPv4-only is not the documented Basic frontend limitation being tested.
The reasoning
Global VNet Peering supports VM-to-VM traffic across regions with private IPs. Basic Load Balancer is retired; its legacy frontends cannot be reached via global peering (Standard LB works). Peering is never transitive, intra- or cross-region.
Q21
Azure Private DNS zones linked to a VNet: which is TRUE?- A. Linking a VNet lets its VMs resolve the zone via Azure DNS (168.63.129.16)
- B. VNet must have a custom DNS server for Private DNS to resolve
- C. A registration link auto-creates A records for VMs in that VNet
- D. A and C
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real resolution link: Azure-provided DNS can resolve a linked private zone for that VNet's workloads. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
False requirement: custom DNS is optional; Azure-provided DNS can resolve properly linked private zones.
Why this is not the answer
Real registration option: enabling auto-registration on the VNet link registers supported VM A records. This is part of the answer; the combined choice includes the other applicable statements too.
✓ Correct choice
Valid combination: resolution links and optional auto-registration serve different, supported purposes.
The reasoning
A VNet can have autoregistration enabled for only one private DNS zone. It can link to multiple other zones for resolution, subject to service limits; multiple VNets can resolve one zone. Azure-provided DNS listens at 168.63.129.16. Custom DNS servers can conditionally forward if needed.
Q22 (scenario)
Region-level HA for a web app, users hitting the closest region, both regions active. Best fit?- A. Traffic Manager with performance routing + per-region deployments
- B. Front Door with regional origins and health probes
- C. Cross-region Load Balancer (Standard LB global tier)
- D. Any of the above depending on protocol and features
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real DNS-based global selection: performance routing can direct clients toward suitable regional endpoints with DNS-cache considerations.
Why this is not the answer
Real global HTTP proxy: Front Door routes to healthy origins and supports web acceleration/security features.
Why this is not the answer
Real global Layer-4 distribution: cross-region Load Balancer supports eligible TCP/UDP scenarios without HTTP-specific features.
✓ Correct choice
Valid qualified combination: protocol, application requirements and failover behavior determine which global routing service fits.
The reasoning
HTTP(S) with WAF/caching: Front Door. Non-HTTP or where DNS-level routing suffices: Traffic Manager (Performance mode). Global L4 TCP/UDP: cross-region LB. On the real exam, resolve the choice by the protocol and specific features in the stem.
Q23
Max NSGs applied to a single NIC?- A. 1 (per NIC)
- B. 2 (one at NIC + one at subnet)
- C. 5
- D. Unlimited
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Documented attachment: a NIC can have one directly associated NSG.
Why this is not the answer
Real two-layer filtering, wrong count: a subnet NSG can also affect traffic, but it is attached to the subnet, not as a second NIC NSG.
Why this is not the answer
Numeric distractor: five directly attached NSGs are not supported on one NIC.
Why this is not the answer
False unlimited claim: NSG association counts and rules have documented limits.
The reasoning
(with the note that a subnet NSG can ALSO apply simultaneously)
Explanation: A NIC has at most one NSG. A subnet has at most one NSG. If both are set, both apply in sequence (inbound: subnet first then NIC; outbound: NIC first then subnet). Effective rules can be viewed in the portal or via Get-AzEffectiveNetworkSecurityGroup.
Q24 (multi-answer)
Which two are TRUE for a Point-to-Site (P2S) VPN?- A. Uses OpenVPN, IKEv2, or SSTP
- B. Supported on the Basic VPN Gateway SKU
- C. Users authenticate with Entra ID (OpenVPN only), certificates, or RADIUS
- D. Supports up to 10 concurrent connections regardless of SKU
- E. Requires a public IP on each client
Show answer & explain every option
Listed key (under review): A, C
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Listed key · under review
Real protocol families: available P2S protocols depend on gateway SKU, client OS and configuration.
Alternative · under review
Real legacy SKU with limited P2S support: a blanket exclusion is misleading; Basic protocol and connection limits differ.
Listed key · under review
Real authentication choices: Entra authentication uses supported OpenVPN clients; certificate/RADIUS capabilities depend on the selected protocol.
Alternative · under review
False universal limit: connection capacity varies by gateway SKU and protocol rather than a fixed ten clients.
Alternative · under review
False address requirement: clients can connect from behind NAT and do not each need a dedicated public IP resource.
Original explanation · under review
P2S supports OpenVPN (broad platform), IKEv2 (native Windows/macOS), SSTP (legacy Windows). Auth options: certificate, RADIUS, Entra ID (OpenVPN only). Basic SKU does not support P2S. Concurrent client count scales with the VpnGw SKU (1-5).
Q25
Network Watcher's Connection Troubleshoot test tells you what?- A. Full path from source to destination including hops and per-hop verdicts
- B. Only whether the destination port is open
- C. Only DNS resolution
- D. Only NSG rules
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real diagnostic: Connection Troubleshoot probes connectivity and reports available path/issue information; not every physical hop is necessarily observable.
Why this is not the answer
Too narrow: destination reachability is part of the test, but diagnostics can identify additional path and configuration issues.
Why this is not the answer
Too narrow: DNS can be diagnosed, but the tool also assesses network connectivity.
Why this is not the answer
Too narrow: NSGs are one possible cause; routing, guest and endpoint issues can also matter.
The reasoning
Connection Troubleshoot runs a synthetic probe from a source VM (with Network Watcher extension) to a destination, reporting each hop, NSG blocks, UDR next hops, and end-to-end latency. Different from IP flow verify, which evaluates NSG rules against a hypothetical flow without live traffic.
Q26
Minimum Windows App Service tier with no fixed platform quota on concurrent WebSockets per instance?- A. Free
- B. Basic (cap 350)
- C. Standard or higher
- D. WebSockets are not supported in App Service
Show answer & explain every option
Correct: C
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real hosting tier: Free has restrictive WebSocket quotas and is not the no-fixed-quota choice.
Why this is not the answer
Real hosting tier: Basic has a documented concurrent WebSocket limit, so it does not meet the requirement.
✓ Correct choice
Real tier threshold: Standard and higher Windows tiers have no fixed platform connection quota, though practical resource capacity still limits concurrency.
Why this is not the answer
False feature claim: App Service supports WebSockets on supported configurations.
The reasoning
WebSockets are unlimited on Standard+. Basic has a hard cap of 350 concurrent. Free and Shared support limited WebSocket counts (5 and 35 respectively in the Windows quota table). Practical concurrency is still constrained by worker resources. Trivia-flavor but occasionally shows up.
Q27
ExpressRoute private peering vs Microsoft peering: what is the difference?- A. Private peering carries VNet-bound traffic; Microsoft peering carries Microsoft PaaS + M365 traffic
- B. They are aliases
- C. Microsoft peering is deprecated
- D. Private peering requires a public ASN
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
True peering distinction: private peering reaches VNet resources; Microsoft peering reaches supported Microsoft public services, with M365 eligibility rules.
Why this is not the answer
False equivalence: these peerings advertise different routes and address different connectivity needs.
Why this is not the answer
False retirement claim: Microsoft peering is a documented ExpressRoute feature.
Why this is not the answer
False ASN restriction: supported private peering can use a private ASN; a public ASN is not universally required.
The reasoning
Private peering connects to VNets via the ExpressRoute gateway. Microsoft peering exposes routes to Microsoft PaaS services (subject to route filters). Public peering was retired and replaced by Microsoft peering. The circuit is a logical connection over provider or Direct connectivity; peering defines its routing domains/BGP sessions. Both use BGP; private typically uses a private ASN.
Q28
Which lets you reserve a static public IP that you can detach from one resource and attach to another (same region)?- A. Standard Public IP configured as Static
- B. IP Prefix (reserves a contiguous /28 to /31 block and allocates from it)
- C. Both A and B
- D. Dynamic public IP
Show answer & explain every option
Correct: C
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real reusable resource: a compatible regional Standard static Public IP retains its address while appropriately detached/reassociated. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real allocation pool: a public IP prefix reserves a contiguous range from which static public IP resources can be created. This is part of the answer; the combined choice includes the other applicable statements too.
✓ Correct choice
Valid combination: a standalone static Public IP or one allocated from a prefix can provide a stable compatible address resource.
Why this is not the answer
Real legacy allocation mode, wrong guarantee: a dynamic address does not provide the requested persistent reservation.
The reasoning
A Standard PIP set to Static keeps its address on dissociation. IP Prefix reserves a contiguous block and lets you allocate PIPs from it (predictable ranges for allowlisting). Dynamic PIPs (Basic only) release address on dissociation.
Q29 (drag-and-drop, pair each need with the correct tool)
| Need | Correct tool |
|---|---|
| Force outbound 0.0.0.0/0 through a firewall subnet | User-Defined Route |
| Block internet-bound traffic from a subnet | NSG rule DenyAll outbound to service tag Internet |
| VMs talk to Storage without hitting internet | Service Endpoint or Private Endpoint |
| Distribute HTTP requests to backend pool with WAF | Application Gateway with WAF |
| Global HTTP failover with caching | Front Door |
Straight mappings. On the real exam these often show up as scenarios rather than short labels.
Q30
Azure Firewall vs NVA firewall: which is TRUE?- A. Azure Firewall is a managed PaaS with built-in HA, autoscale, and threat intel; NVA is a third-party VM you patch and scale yourself
- B. NVAs may support more advanced enterprise features at the cost of operational overhead
- C. Azure Firewall Premium adds TLS inspection, signature-based IDPS, URL filtering
- D. All of the above
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real operational distinction: Azure Firewall manages platform availability/scaling; VM-based NVAs require appliance lifecycle operations, with product-specific variations. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real tradeoff: third-party appliances can supply vendor-specific enterprise features while adding operational responsibilities. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real Premium features: TLS inspection, signature-based IDPS and URL filtering extend the managed firewall's capabilities. This is part of the answer; the combined choice includes the other applicable statements too.
✓ Correct choice
Valid combination: managed operations, vendor-specific NVA tradeoffs and Premium inspection features are separate true considerations.
The reasoning
Azure Firewall trades some flexibility for less operational load. NVAs (Palo Alto, Fortinet, Check Point) may be required for specific enterprise features (site-to-site over BGP with policy-based tunnels, or advanced IPS signatures). Premium tier of Azure Firewall closed the gap significantly with TLS inspection + signature-based IDPS.
Scenario-Style Questions
Real-exam-style stems. Multi-sentence context, judgment or troubleshooting. Each has doc links so you can drill into the source.
S1
Hub-and-spoke with 3 spokes. Spokes must reach each other only via Azure Firewall in the hub. UDR pattern?- A. Each spoke: 0.0.0.0/0 next hop = Azure Firewall; peering enables gateway transit
- B. Each spoke: UDR for the OTHER spokes' address spaces (10.1.0.0/16 next hop = Azure Firewall) plus 0.0.0.0/0 to Firewall; peering does NOT transit spoke-to-spoke
- C. Enable transitive peering
- D. Use Traffic Manager
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real default route, incomplete transit: a default alone can lose to more-specific routes; gateway-transit flags do not create firewall spoke transit.
✓ Correct choice
Real hub routing design: explicit spoke prefixes steer traffic through the firewall; configure forwarded traffic, firewall rules and symmetric return routes too.
Why this is not the answer
Invented peering switch: there is no generic enable-transitive-peering setting that automatically connects all spokes.
Why this is not the answer
Real DNS service, wrong layer: Traffic Manager selects public endpoint DNS answers, not private inter-spoke next hops.
The reasoning
VNet peering is never transitive. Explicit UDRs in each spoke pointing at the Firewall for the OTHER spokes' address spaces force spoke-to-spoke through the firewall. Enable forwarded traffic on the relevant peerings, configure symmetric return routing, and allow the flows in the firewall policy.
S2
NSG shows "Allow HTTP" from 0.0.0.0/0 but VM unreachable on port 80. Debug order?- A. Effective security rules (NIC + subnet merge); check UDR for asymmetric routing; verify service listening on 80; check guest OS firewall; run IP flow verify
- B. Blame the router
- C. Restart VM
- D. NSG changes take 24 hours
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real layered diagnosis: examine both NSGs, routing, the guest firewall and listening process; one allow rule is insufficient evidence.
Why this is not the answer
Unsupported blame: identify the failing hop/configuration before attributing it to a router.
Why this is not the answer
Real operation, premature: rebooting does not correct a persistent NSG, route or guest firewall rule.
Why this is not the answer
False fixed delay: NSG rules do not normally require a blanket 24-hour wait before connectivity can be tested.
The reasoning
Systematic debug: effective rules, guest firewall, service listening, UDR asymmetry, Network Watcher tools. NSG changes apply near-instantly.
S3
Application Gateway v2 health probe reports backend unhealthy; VMs serve fine directly. Common causes?- A. Backend Health Settings hostname mismatch with backend cert; probe path returns outside the configured healthy range (default 200–399); probe uses wrong hostname (default 127.0.0.1); NSG blocks AGW subnet's probes; port mismatch
- B. AGW misconfigured for zones
- C. VMs need public IP
- D. WAF blocks probes
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real probe dependencies: hostname, TLS trust, port, path, expected status and network reachability can differ from your direct browser request.
Why this is not the answer
Real placement configuration, unproven: zone setup does not directly explain a backend that fails only the probe's particular request.
Why this is not the answer
False public-IP requirement: Application Gateway can reach private backend addresses with correct connectivity.
Why this is not the answer
Incorrect default explanation: frontend WAF inspection is not normally the component blocking the gateway's own backend health probes.
The reasoning
Backend Health blade in AGW surfaces the reason. Common: probe hostname wrong (backend expects www.contoso.com, probe sends 127.0.0.1), probe path 4xx/5xx, backend NSG not allowing probe traffic from the Application Gateway subnet; separately verify gateway-subnet infrastructure rules.
Docs: AGW health probe | AGW troubleshooting
S4
ExpressRoute circuit provisioned, gateway attached, BGP up, but on-prem can't reach VMs. Missing?- A. Route on the on-premises router pointing to ExpressRoute; or Azure side missing routes advertised by on-prem; Azure VMs may have UDRs overriding learned ExpressRoute routes
- B. VPN tunnel
- C. Additional peering
- D. Public IPs
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real route diagnosis: an established BGP session does not prove the desired prefixes and return paths are present and selected.
Why this is not the answer
Real alternative connection: a VPN tunnel is not required just because a correctly provisioned ExpressRoute path needs route repair.
Why this is not the answer
Real circuit concept, vague fix: verify the required private peering/routes rather than adding unspecified extra peering.
Why this is not the answer
Real addresses, wrong requirement: ExpressRoute private connectivity does not require public IPs on the VMs.
The reasoning
BGP up does not mean both sides have routes to each other's prefixes. On-prem must advertise its subnets. Azure VNet needs the gateway associated and no conflicting UDRs. Effective Routes blade on the NIC shows what Azure uses.
S5
S2S VPN tunnel drops every 3-4 hours. Diagnostic path?- A. IKE Phase 1/Phase 2 lifetime mismatch causing rekey storms; on-prem NAT-T settings; Azure gateway diagnostics for peer disconnect reasons; compare negotiated IKE/IPsec settings and peer disconnect logs before changing routing
- B. Redeploy gateway
- C. VPN is unreliable by nature
- D. Move to ExpressRoute
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real tunnel diagnostics: correlate rekey/lifetime settings and peer logs to explain the periodic disconnect before changing the design.
Why this is not the answer
Real disruptive action, premature: redeploying the gateway can interrupt users without fixing incompatible peer settings.
Why this is not the answer
False generalization: supported VPN configurations can be stable; investigate the recorded disconnect reason.
Why this is not the answer
Real alternative service, premature: purchasing private connectivity is not a diagnosis of the present tunnel's rekey failure.
The reasoning
Recurring drops at consistent intervals suggest SA lifetime rekey issues. Mismatched IKE lifetimes trigger frequent renegotiation. NAT-T (UDP 4500) issues also common. Gateway diagnostics via Network Watcher captures peer disconnect codes.
S6
Private endpoint deployed for storage. VMs still resolve public IP for the storage FQDN. Fix?- A. Link the
privatelink.blob.core.windows.netPrivate DNS zone to the VNet; VMs must use Azure DNS or custom DNS with the appropriate Azure Private Resolver/forwarder path; PE-integrated zone auto-creates records if you selected that option - B. Delete public IP on the storage account
- C. Restart VM
- D. Public firewall rule
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real DNS repair: link/configure the private zone and resolver/forwarding path so the normal service hostname resolves to the private endpoint.
Why this is not the answer
Incorrect resource model: a storage service public endpoint is not a detachable Public IP resource to delete.
Why this is not the answer
Real operation, incomplete: restarting cannot repair a missing private-zone link or DNS forwarder configuration.
Why this is not the answer
Real access control, wrong layer: public firewall rules do not change how the client resolves the service hostname.
The reasoning
PE only works when DNS resolves the FQDN to the PE's private IP. Requires the privatelink.<subresource>.core.windows.net Private DNS zone linked to the VNet. For custom/on-premises DNS, forward the service public zone (for example blob.core.windows.net) to an Azure resolver that can resolve the linked private zone. Do not forward directly from on-premises to 168.63.129.16.
S7
Create subnet in existing VNet fails: "address space overlaps." Cause?- A. CIDR overlaps existing subnet OR reserved range OR subnet in a peered VNet
- B. Region issue
- C. Naming conflict
- D. Quota
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real address conflict: verify the new subnet is inside the VNet and nonoverlapping with existing subnets; peered VNet address spaces must also be nonoverlapping.
Why this is not the answer
Real location setting, wrong error: region mismatch does not directly explain an explicit CIDR overlap message.
Why this is not the answer
Real name constraint, different error: duplicate names are distinct from overlapping IP address ranges.
Why this is not the answer
Real capacity constraint, different error: a subnet quota would not normally be reported as overlapping address space.
The reasoning
Subnets in a VNet cannot overlap each other. VNet address space cannot overlap peered VNets. Choose a CIDR that fits the VNet address space and doesn't collide.
Docs: Virtual network subnets | VNet planning
S8
Front Door WAF blocking legitimate API calls with 403. Diagnose + tune?- A. Enable WAF diagnostic logs; KQL to find rule/ruleset firing; add per-header/per-arg/per-cookie exclusions; test in Detection mode before Prevention
- B. Disable WAF
- C. Whitelist client IP
- D. Move to AGW WAF
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real evidence-based tuning: identify the matched WAF rule and apply narrowly scoped exclusions; test behavior before enforcing the revision.
Why this is not the answer
Real switch, overbroad response: disabling the whole WAF removes protections without isolating the false positive.
Why this is not the answer
Real bypass mechanism, too broad: allowing an IP may bypass protections for unrelated requests and does not fix the specific rule match.
Why this is not the answer
Real alternative WAF, unnecessary migration: moving gateways does not automatically eliminate the same false-positive pattern.
The reasoning
WAF logs show rule ID, matched value, action. Common false positives: SQL injection rule on legitimate query strings, XSS on data-URIs. Exclusions target specific request parts by name-match. Always test tuning in Detection first.
Docs: Front Door WAF | WAF exclusions
S9
Global VNet peering: East US to West Europe. Latency 120 ms. Expected?- A. Yes; transatlantic RTT is 80-120 ms; global peering adds negligible overhead beyond physical propagation delay
- B. Should be < 20 ms
- C. Peering broken
- D. Retry
Show answer & explain every option
Listed key (under review): A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Listed key · under review
Unsupported fixed benchmark: transatlantic latency is plausible, but the given range is not a universal Azure guarantee; compare measured paths and current data.
Alternative · under review
Unsupported target: geography and routing make a universal sub-20-ms expectation unjustified for this intercontinental path.
Alternative · under review
Unsupported failure diagnosis: 120 ms alone does not establish that peering is broken.
Alternative · under review
Real retry action, not a diagnosis: repeatable measurements help, but retry alone neither explains latency nor defines an acceptable baseline.
Original explanation · under review
Can't beat physics. East US to West Europe is ~5,900 km fiber path; ~59 ms minimum RTT. 80-120 ms measured is normal. Replicate the workload regionally for lower latency (Front Door / Traffic Manager).
Docs: Azure network round-trip latency | Global VNet peering
S10
Deploy DNS Private Resolver so on-prem can resolve Azure Private DNS zone names. Components?- A. DNS Private Resolver with Inbound endpoint in a VNet linked to the Private DNS zones; on-prem DNS forwarder forwards the service public zone (for example blob.core.windows.net) queries to the Inbound endpoint IP over ExpressRoute or VPN; optionally Outbound endpoint + forwarding ruleset for Azure -> on-prem
- B. Custom DNS VMs
- C. Azure Firewall DNS proxy alone
- D. Not possible
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real managed DNS bridge: an inbound resolver endpoint accepts on-premises forwarded queries and resolves linked Azure private zones over private connectivity.
Why this is not the answer
Real alternative architecture: DNS VMs can forward queries, but they are not the requested managed Private Resolver components.
Why this is not the answer
Real DNS proxy: Firewall can forward queries, but needs a correct upstream/private-zone resolution design rather than supplying this entire configuration alone.
Why this is not the answer
False limitation: supported hybrid DNS resolution is possible with Private Resolver and correct routing/forwarding.
The reasoning
DNS Private Resolver is the managed replacement for DNS forwarder VMs. Inbound endpoint receives on-prem queries. Link Private DNS zones to the resolver's VNet.
S11
Standard LB inbound works; outbound intermittently fails with connection timeouts. Which potential cause and mitigation should you investigate?- A. SNAT port exhaustion on the LB's outbound path; move to NAT Gateway or configure LB outbound rules with more allocated ports per instance
- B. NSG blocks outbound
- C. Wrong region
- D. LB SKU mismatch
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real outbound bottleneck: SNAT exhaustion can cause intermittent new-connection failures; inspect metrics and configure suitable outbound capacity.
Why this is not the answer
Real filter concern: an outbound deny may block traffic, but inspect effective rules before assuming it explains load-dependent failures.
Why this is not the answer
Real deployment setting, unsupported cause: choosing a different region does not inherently repair SNAT capacity.
Why this is not the answer
Real compatibility constraint, unlikely isolated symptom: a SKU mismatch is a configuration issue, not the established cause of intermittent outbound exhaustion.
The reasoning
Default Standard Load Balancer SNAT allocation decreases per instance as the backend pool grows (for example, 1,024 ports for 1–50 instances versus 512 for 51–100 per frontend IP). Confirm SNAT exhaustion in metrics. Size outbound rules explicitly or use NAT Gateway, which provides 64,512 SNAT ports per public IP and attaches to a subnet; connection reuse and workload sizing still matter.
Docs: Outbound SNAT | NAT Gateway
S12
AGW v2 with path-based routing to 3 backend pools (/api, /static, /admin). All requests hit the first pool regardless of path. Debug?- A. Path map evaluates in order; first rule probably matches too broadly (e.g.,
/*); reorder specific paths first with wildcard/default last - B. Backend health
- C. WAF blocking
- D. Wrong SKU
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real ordered matching: a broad path pattern can capture requests before later specific paths; inspect the listener/rule/path-map association too.
Why this is not the answer
Real backend signal: unhealthy pools affect availability, but do not by themselves explain every path matching the same broad rule.
Why this is not the answer
Real security policy: WAF can reject requests; that is distinct from successful requests consistently selecting the wrong path map.
Why this is not the answer
Real product configuration: v2 supports path routing, so the stated SKU alone is not the reason for this behavior.
The reasoning
Path map is order-sensitive. Rule with / or /api placed before /api/orders* matches first. Reorder from specific to general; default pool last.
S13
NSG effective rules blade shows a Deny you didn't create. Origin?- A. Default rules (65000+); policy-created rule; rule on a subnet-attached NSG you didn't check (NIC + subnet NSGs merge)
- B. Cloudflare
- C. Azure Firewall (but AzFW rules don't show in NSG effective view)
- D. Random Azure change
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real rule sources: default rules and subnet-associated NSGs participate; inspect the owning NSG and any management automation before changing it.
Why this is not the answer
Real external proxy, wrong source: Cloudflare rules are not inserted into Azure's effective NSG rules view.
Why this is not the answer
Real separate firewall: Azure Firewall rules do not appear as NSG effective rules.
Why this is not the answer
Unsupported attribution: a specific default or configured rule has an identifiable source; random change is not a diagnosis.
The reasoning
Default rules include DenyAllInBound at 65500. Azure Policy can auto-create rules. NIC + subnet NSGs both apply; check both.
S14
VMSS behind Standard LB across 3 zones. Zone 2 goes offline. Traffic still hitting zone-2 backend IPs. Why?- A. Health probes must fail before LB removes instances; zone loss appears as instance-unhealthy probes; timing depends on probe protocol, interval, threshold, and response
- B. LB doesn't understand zones
- C. Manual failover required
- D. Restart LB
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real health-based behavior: the load balancer stops assigning new flows according to probe failures; existing-flow behavior and detection time vary.
Why this is not the answer
False blanket claim: Standard Load Balancer supports zonal/zone-redundant designs, but backend health detection still matters.
Why this is not the answer
False general requirement: healthy redundant backends can receive traffic automatically after health detection without manual failover.
Why this is not the answer
Incorrect operational remedy: a managed load balancer is not restarted like a guest process to repair health-probe settings.
The reasoning
Standard LB uses health probes as liveness signal. Probes fail against zone-2 instances; LB stops assigning new connections when probes mark them unhealthy. Existing TCP flows can behave differently; do not promise a universal ten-second failover. Bad probe config (long interval, high threshold) delays failover.
S15
Force-tunnel all outbound internet from every VNet through Azure Firewall in the hub. Design?- A. Hub VNet with Azure Firewall in
AzureFirewallSubnet; every spoke peered to hub with UDR 0.0.0.0/0 next hop = Firewall private IP; firewall SNATs to its PIP - B. Force-tunnel via VPN back to on-prem
- C. Public IPs on every VM
- D. Front Door
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real central egress design: spoke default routes point to the hub firewall, with correct peering, firewall policy and return paths.
Why this is not the answer
Real alternative force-tunnel path: it sends traffic to on-premises equipment rather than the requested Azure Firewall egress.
Why this is not the answer
Real public connectivity, wrong design: per-VM public addresses do not enforce centralized firewall inspection.
Why this is not the answer
Real HTTP edge service: Front Door handles incoming web traffic, not arbitrary outbound VNet traffic enforcement.
The reasoning
Standard hub-spoke egress pattern. AzureFirewallSubnet is a fixed name, /26 minimum. Firewall Standard/Premium SKU. Spoke UDRs override system routes for 0.0.0.0/0.
S16
Migrate production from Basic LB to Standard LB with zero downtime. Approach?- A. Deploy Standard LB alongside Basic with same backends; DNS TTL cutover; delete Basic
- B. Change SKU in place (not supported)
- C. Delete Basic then create Standard
- D. Move to Front Door
Show answer & explain every option
Listed key (under review): A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Listed key · under review
Unsupported zero-downtime claim: the same backend cannot simply participate in both SKU designs as proposed; parallel workloads need a supported cutover plan.
Alternative · under review
Unsupported in-place assumption: Basic-to-Standard migration is not a simple no-impact SKU toggle.
Alternative · under review
Real recreate approach, definite interruption: deleting the old load balancer first cannot satisfy zero downtime.
Alternative · under review
Real Layer-7 alternative: Front Door is not a transparent replacement for all Layer-4 load-balancer workloads.
Original explanation · under review
SKUs cannot change in place. Parallel-deploy pattern: bring up Standard LB, verify probes, switch DNS, retire Basic. Backends need Standard PIPs (SKU must match).
S17
New VNet peering to hub fails: "Connection cannot be created between vnet A and vnet B." Investigation order?- A. Address space overlap; both halves created (peering is two half-objects); RBAC Network Contributor on both; existing peering with different config; cross-tenant auth
- B. Delete VNet
- C. Wrong resource group
- D. Peering disabled
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real prerequisites: check nonoverlapping addresses, both peering resources, correct permissions and applicable cross-tenant authorization.
Why this is not the answer
Real destructive operation, premature: deleting the VNet is unnecessary before identifying the failed prerequisite.
Why this is not the answer
Real grouping concept, usually irrelevant: peered VNets need not reside in the same resource group.
Why this is not the answer
Unsupported generic cause: inspect the explicit deployment/peering error instead of assuming a universal peering-disabled setting.
The reasoning
Most common: overlapping address space. Both halves must exist for Connected state. Cross-tenant peering needs extra auth. If everything looks right, delete both halves and recreate.
S18
Azure Firewall Premium TLS inspection causes cert errors on internal apps. Cause + config?- A. Firewall presents its own cert to clients; clients don't trust the firewall's intermediate CA; deploy the CA to all client trust stores (GPO for domain-joined), OR bypass TLS inspection for those FQDNs
- B. Firewall broken
- C. Move certs to Key Vault
- D. Use plain HTTP
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real TLS interception behavior: clients need the appropriate enterprise trust chain; narrowly bypass inspection only where the design requires it.
Why this is not the answer
Unsupported diagnosis: certificate trust failures can result from expected inspection behavior rather than a broken firewall.
Why this is not the answer
Real certificate store, incomplete fix: placing a certificate in Key Vault alone does not establish client trust in the issuing chain.
Why this is not the answer
Real protocol downgrade, wrong remedy: switching to unencrypted HTTP sacrifices transport security rather than repairing certificate trust.
The reasoning
TLS inspection substitutes the server cert with one signed by the firewall's intermediate CA. Clients must trust that CA. Alternative: TLS bypass on specific FQDNs in the firewall policy.
S19
Network Watcher IP flow verify says "Allowed" but VM unreachable. Next step?- A. Connection Troubleshoot (real synthetic probe with hop-by-hop info); check UDR for asymmetric routing; check guest OS firewall; check service listening
- B. Blame IP flow verify
- C. Restart VM
- D. Recreate NSG
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real next diagnostics: IP flow verify evaluates NSG allowance; actual reachability also depends on routes, guest firewall and the listening service.
Why this is not the answer
False tool expectation: Allowed is an NSG verdict, not a promise that every end-to-end dependency works.
Why this is not the answer
Real operation, premature: restarting may leave routing/listener configuration faults unchanged.
Why this is not the answer
Real disruptive replacement, unjustified: an allowed NSG verdict points to checking other layers before recreating the NSG.
The reasoning
IP flow verify only checks NSG rules against a hypothetical flow. Doesn't check UDR, application layer, or guest firewall. Connection Troubleshoot sends a real probe reporting every hop.
S20
P2S VPN clients connect and receive IP but can't reach any Azure resource. Common issues?- A. Missing route from client to Azure ranges (VPN client config); NSGs blocking the P2S client address pool; UDRs on Azure subnets not routing return traffic to the VPN gateway; DNS resolution failing on client
- B. Wrong subscription
- C. VPN client version
- D. Standard LB required
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real post-connect dependencies: tunnel authentication and address assignment do not prove correct client routes, return routes, filters or DNS.
Why this is not the answer
Real administrative scope, unsupported cause: subscription selection alone does not explain a successfully established client tunnel's missing routes.
Why this is not the answer
Real compatibility concern, unproven: inspect logs/configuration before blaming the client version for all data-path failures.
Why this is not the answer
False dependency: point-to-site access to private resources does not inherently require a Standard Load Balancer.
The reasoning
Client route print should show Azure ranges via the VPN adapter (from the downloaded profile). NSGs on Azure subnets must allow inbound from the P2S client pool. UDRs need a route back to the gateway for return traffic if custom routing.
Docs: P2S VPN troubleshooting | P2S routing