AZ-104 Implement and Manage Virtual Networking Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Global VNet peering.

  Why this is correct

  Global VNet peering is the correct choice for private connectivity between VNets in different Azure regions. It keeps traffic on the Microsoft backbone, uses private IP addressing, and avoids the added latency and overhead of an external VPN tunnel. Because the VNets already have non-overlapping address spaces, they meet the peering prerequisites. This design is commonly used when multiple regional workloads need fast, private communication without introducing a gateway-based path.

• ✗

  A site-to-site VPN between the two VNets.

  Why it's wrong here

  A site-to-site VPN between the two VNets would require deploying VPN gateways and IPsec tunnels, often routing traffic over the public internet or an ExpressRoute connection, which adds cost, administrative overhead, and higher latency than Microsoft's internal network. While it can technically establish connectivity, Global VNet peering provides direct private IP connectivity over the Azure backbone without gateway resources. Therefore, although this option is functional, it is not the optimal or simplest solution for private cross-region application communication.

  When this WOULD be correct

  A site-to-site VPN would be correct if the requirement is to connect on-premises networks to Azure VNets, or to connect VNets across regions when VNet peering is not supported (e.g., different Azure clouds or classic VNets).

• ✗

  Azure Traffic Manager with two public endpoints.

  Why it's wrong here

  Azure Traffic Manager operates at the DNS layer, directing external client traffic to public endpoints based on routing method or health checks. It does not create a private IP path between the VNets; the applications would still need some other connectivity layer to communicate. Since the requirement is private, low-latency communication between the two regional VNets, DNS-level load balancing cannot replace VNet peering.

  When this WOULD be correct

  This option would be correct in a scenario where the requirement is to distribute incoming user traffic across multiple public endpoints (e.g., web applications) in different regions for high availability and low latency, without needing private IP connectivity between the VNets.

• ✗

  A service endpoint for each application subnet.

  Why it's wrong here

  Service endpoints do not provide any VNet-to-VNet connectivity; they are designed to secure access from a VNet to PaaS resources such as Azure Storage or SQL Database. Enabling a service endpoint on each application subnet only extends the subnet's identity to those services, so the two application VNets remain isolated with no private path between them. Thus, this option fails to satisfy the requirement for cross-region private application traffic.

  When this WOULD be correct

  A question requiring secure, private access from a VNet to an Azure SQL Database or Storage Account, minimizing exposure to the public internet, would make service endpoints the correct answer. For example: 'You need to ensure that traffic from a VNet to Azure Storage never traverses the public internet.'

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Go deeper

Related to this question