Azure AZ-104: Implement and manage virtual networking Practice Questions

When peering status is 'Connected' on both sides, the peering itself is functioning correctly, so the issue lies in filtering or routing. An NSG on the Prod-VNet subnet blocking the 10.1.0.0/16 source range is a very common cause of post-peering connectivity failure. A misconfigured user-defined route (UDR) in Dev-VNet that sends traffic to a next-hop (e.g., an NVA) that is not forwarding packets would silently drop traffic while peering still shows Connected. VNet peering does support cross-region (global peering), so that is not a valid limitation here. The address spaces 10.0.0.0/16 and 10.1.0.0/16 do not overlap — if they did, Azure would have prevented the peering from being created at all. 'Allow forwarded traffic' affects whether traffic forwarded through a VM/NVA in one VNet can traverse the peering; it is not required for direct VM-to-VM communication within the peered VNets.

A private DNS zone must have a virtual network link to each VNet whose VMs need to resolve records in that zone. Adding a virtual network link for Spoke-VNet to 'corp.internal' allows VMs in Spoke-VNet to resolve names in the zone. VNet peering does not automatically extend private DNS zone resolution — a separate link is required. Using DNS proxy via Azure Firewall is a valid alternative architecture but requires additional configuration and is not the simplest fix here. A CNAME record does not solve the zone visibility problem. Moving the resource group has no effect on DNS zone scoping.

Application Security Groups act as logical groupings of NIC resources. Once the NSG rule references ASG-WebTier as the destination, any NIC associated with that ASG is automatically covered by the rule. Simply associating VM4's NIC with ASG-WebTier is all that is needed — the NSG rule itself does not require modification. Updating the rule to add VM4's IP defeats the purpose of ASGs and introduces manual maintenance. Creating a new rule per VM is also unnecessary and operationally costly. Subnet membership does not grant ASG membership; ASG association is done at the NIC level explicitly.

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.

Azure VPN Gateways must be deployed into a subnet named exactly 'GatewaySubnet' — this is a hard requirement enforced by the Azure platform. No other name is accepted. 'VpnSubnet' is a plausible-sounding alternative but is not recognized by Azure. 'AzureGatewaySubnet' and 'RouteGatewaySubnet' are invented names that also do not meet the naming requirement.