Implement and manage virtual networking: free practice questions

A /23 provides 512 addresses (510 usable hosts), which is the smallest block that can accommodate 500+ hosts across 4 subnets. Each subnet would have approximately 128 addresses, and Azure reserves 5 addresses per subnet, leaving enough room. A /24 provides only 256 addresses (251 usable after Azure reservations per subnet), which is insufficient for 500 hosts. A /22 provides 1024 addresses — sufficient but larger than necessary, violating the 'as small as possible' requirement. A /16 provides 65,536 addresses, which is vastly oversized for this requirement.

To allow spoke VNets to use the hub's VPN Gateway (gateway transit), two peering settings must be configured: (1) 'Allow gateway transit' must be enabled on the hub-to-spoke peering (hub side), which allows the hub to share its gateway with spokes, and (2) 'Use remote gateway' must be enabled on the spoke-to-hub peering (spoke side), which tells the spoke to use the remote (hub) gateway for routing. Both settings together enable transitive connectivity to on-premises. Deploying a separate VPN Gateway in each spoke (option C) is costly, defeats the hub-spoke purpose, and is not required. VNet-to-VNet connectivity (option D) is a different connectivity model and doesn't solve gateway transit. A UDR pointing to the VPN Gateway's public IP (option E) is incorrect — the next hop for a UDR to use a VPN Gateway would reference the gateway's private IP or use 'Virtual Network Gateway' next hop type, and even then, gateway transit settings handle this automatically. BGP (option F) is about route advertisement to on-premises, not about enabling spoke-to-gateway connectivity.

NSG rules are evaluated in ascending priority order (lowest number = highest priority). Rule 100 (Allow, port 443) is evaluated before rule 200 (Deny, port 443). Since rule 100 matches first, the traffic is allowed and evaluation stops — rule 200 is never reached (option B is correct). — Option A is incorrect: rule 200 would only apply if no earlier rule matched; rule 100 takes precedence. Option C is incorrect: while rule 65000 does not cover internet traffic, the evaluation never reaches it because rule 100 already allows the traffic. Option D is incorrect: the actual Azure default rule for inbound is 65500 'DenyAllInBound', which denies all traffic not matched by prior rules — there is no default rule that allows all inbound traffic from any source.

The health probe interval (how often the probe checks) combined with the unhealthy threshold (how many consecutive failures before marking unhealthy) directly controls the detection latency before a VM is removed from rotation (option B). Reducing the probe interval and/or threshold reduces the window during which traffic is sent to a failed instance. — Option A is incorrect: idle timeout governs how long TCP connections are kept alive when idle; it has no effect on health detection or VM removal. Option C is incorrect: Floating IP (also known as Direct Server Return) changes how the destination IP is presented to the backend VM; it has nothing to do with health monitoring. Option D is incorrect: an NSG blocking traffic to the failed VM would prevent legitimate traffic from reaching it but does not interact with the Load Balancer's health probe mechanism and could cause unintended connectivity issues.

A Private Endpoint assigns the App Service a private IP address from the VNet's address space. Disabling public network access on the App Service ensures no internet traffic can reach it. The private DNS zone 'privatelink.azurewebsites.net' linked to the VNet ensures the App Service FQDN resolves to the private IP for clients inside the VNet (and on-premises if DNS forwarding is configured). This fully satisfies all requirements. Access restrictions (Option A) still allow the App Service's public endpoint to exist — it just filters traffic; the FQDN still resolves to a public IP, and determined attackers or accidental exposure remains a risk. VNet Integration (Option B) allows outbound traffic from App Service into the VNet; it does not make the App Service accessible on a private IP from the VNet, nor does it disable the public endpoint for inbound traffic. Azure API Management in internal mode (Option D) could limit access to the VNet but the App Service itself remains publicly accessible, and the FQDN would still resolve to a public IP — this does not meet the private IP resolution requirement.