Implement and Manage Virtual Networking →mediumMultiple ChoiceObjective-mapped

AZ-104 Implement and Manage Virtual Networking Practice Question

VNet-Hub and VNet-Spoke1 are in the same region and subscription. Resources in the two VNets must communicate over the Microsoft backbone without using a VPN gateway. What should you configure?

⚠ Common exam trap

A common mix-up: candidates confuse VNet peering with VPN gateways or service endpoints, mistakenly thinking a VPN gateway is required for cross-VNet communication or that service endpoints can connect VNets, when in fact VNet peering is the native, gateway-free solution for direct VNet-to-VNet connectivity within the same region.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

VNet peering

VNet peering enables direct connectivity between two virtual networks in the same region and subscription over the Microsoft backbone, without requiring a VPN gateway or public internet. This is the correct solution because it provides low-latency, private communication using the Azure infrastructure, and it supports resources in both VNets to communicate as if they were on the same network.

Answer analysis

Option-by-option breakdown

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

✓
VNet peering
Why this is correct
VNet peering is the native Azure connectivity mechanism that links two virtual networks through the Microsoft backbone infrastructure, providing low-latency, private, and high-bandwidth communication without traversing the public internet. Because both VNets reside in the same region and subscription, you can simply enable peering between them, and the existing routing automatically allows resources in vnet spoke1 to reach resources in vnet hub with no additional gateway or encryption overhead.
✗
A site-to-site VPN gateway in each VNet
Why it's wrong here
A site-to-site VPN gateway in each VNet is designed to create an encrypted IPSec tunnel over the public internet, typically for connecting a VNet to an on-premises network or to VNets in different regions or tenants. For two VNets in the same Azure region and subscription, this approach is unnecessarily complex, requiring a gateway subnet, VPN gateway instances, and per-hour/gigabyte pricing—all while adding latency compared to the direct Azure backbone path offered by VNet peering.
When this WOULD be correct
A site-to-site VPN gateway would be correct if the VNets are in different regions or different tenants, or if you need encrypted traffic over the public internet, or if VNet peering is not supported (e.g., overlapping address spaces).
✗
A private endpoint
Why it's wrong here
A private endpoint is an Azure Network Interface with a private IP address placed in a VNet to access a specific PaaS service, such as Azure Storage or Azure SQL Database, privately from within the VNet. It does not provide a mechanism for routing traffic between two VNets; it only exposes an individual service resource into a single VNet, so it cannot be used to interconnect vnet hub and vnet spoke1 for general workload traffic.
When this WOULD be correct
A question asking: 'You need to securely connect an Azure SQL database to a VNet so that traffic never traverses the public internet. What should you configure?' — here, a private endpoint would be the correct answer.
✗
A service endpoint
Why it's wrong here
Service endpoints extend a VNet's private address space to an Azure PaaS service by creating a direct route to that service's public endpoint, typically for scoping the service's firewall rules to a specific VNet. They are not a VNet-to-VNet connectivity feature; they apply only to Azure service resources and do not establish any bidirectional routing or forwarding between two virtual networks, making them irrelevant for connecting vnet hub to vnet spoke1.
When this WOULD be correct
A question asking how to securely access an Azure Storage account from a VNet without using a public IP address would make service endpoints correct, as they provide direct connectivity to PaaS services over the Microsoft backbone.

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.

✓VNet peeringCorrect answer▾

Why this is correct

VNet peering is the native Azure connectivity mechanism that links two virtual networks through the Microsoft backbone infrastructure, providing low-latency, private, and high-bandwidth communication without traversing the public internet. Because both VNets reside in the same region and subscription, you can simply enable peering between them, and the existing routing automatically allows resources in vnet spoke1 to reach resources in vnet hub with no additional gateway or encryption overhead.

✗A site-to-site VPN gateway in each VNetWrong answer — click to see why▾

Why this is wrong here

A site-to-site VPN gateway requires traffic to traverse the public internet or a VPN tunnel, not the Microsoft backbone, and incurs additional cost and complexity. The question explicitly requires communication over the Microsoft backbone without a VPN gateway.

★ When this WOULD be the correct answer

A site-to-site VPN gateway would be correct if the VNets are in different regions or different tenants, or if you need encrypted traffic over the public internet, or if VNet peering is not supported (e.g., overlapping address spaces).

Why candidates choose this

Candidates may think VPN gateways are the standard way to connect VNets, especially when security is a concern, and may overlook that VNet peering uses the Microsoft backbone and is simpler for same-region connections.

✗A private endpointWrong answer — click to see why▾

Why this is wrong here

A private endpoint enables secure access to a specific Azure service (e.g., Azure SQL) from a VNet via a private IP, but it does not connect two VNets together. The question requires inter-VNet communication, which private endpoints cannot provide.

★ When this WOULD be the correct answer

A question asking: 'You need to securely connect an Azure SQL database to a VNet so that traffic never traverses the public internet. What should you configure?' — here, a private endpoint would be the correct answer.

Why candidates choose this

Candidates may confuse private endpoints with VNet peering because both use private IPs and the Microsoft backbone, but private endpoints are for accessing PaaS services privately, not for VNet-to-VNet connectivity.

✗A service endpointWrong answer — click to see why▾

Why this is wrong here

Service endpoints allow access to Azure PaaS services from a VNet over the Microsoft backbone, but they do not enable communication between two VNets. VNet peering is required for direct VNet-to-VNet connectivity.

★ When this WOULD be the correct answer

A question asking how to securely access an Azure Storage account from a VNet without using a public IP address would make service endpoints correct, as they provide direct connectivity to PaaS services over the Microsoft backbone.

Why candidates choose this

Candidates may confuse service endpoints with VNet peering because both use the Microsoft backbone and avoid VPN gateways, but service endpoints are for PaaS services, not VNet-to-VNet communication.

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

AZ-104 Implement and Manage Virtual Networking Practice Question

Why each option matters

Option-by-option breakdown

Why each answer is right or wrong

Related to this question