AZ-104 Implement and Manage Virtual Networking Practice Question
An administrator needs two non-overlapping VNets in the same region to communicate directly over private IP addresses without deploying a gateway. What should be configured?
⚠ Common exam trap
Watch out — candidates often confuse VNet peering with VPN gateways or service endpoints, assuming a gateway is always required for cross-VNet communication or that service endpoints can connect VNets, when in fact peering is the direct, gateway-free solution for private IP connectivity.
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 between the two virtual networks.
VNet peering enables direct connectivity between two Azure virtual networks using private IP addresses across the Microsoft backbone, without requiring a gateway or public internet. It supports non-overlapping address spaces in the same region and provides low-latency, high-bandwidth communication. This matches the requirement exactly.
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 between the two virtual networks.
Why this is correct
Azure VNet peering connects the two virtual networks directly over the Microsoft backbone, using private IP addresses with no gateway, VPN tunnel, or public internet traversal. Because the address spaces are non-overlapping, each peered VNet can route traffic to the other's prefix using automatically injected system routes, and unicast traffic can flow in both directions with low and consistent latency. This is the appropriate native mechanism for private VNet-to-VNet communication in the same region, and it can also work globally.
- ✗
A site-to-site VPN gateway connection.
Why it's wrong here
A site-to-site VPN gateway connection creates an encrypted IPsec tunnel through the public internet, typically between an on-premises network and Azure, whereas these are two VNets already hosted in Azure and can communicate without any encrypted overlay. You could use a VPN gateway in a VNet-to-VNet configuration, but that would add a gateway subnet, a gateway SKU with bandwidth limits, and extra latency and cost, all of which are unnecessary when VNet peering provides native private connectivity. Therefore, it is wrong because it is not required for direct VNet-to-VNet communication.
When this WOULD be correct
When connecting on-premises networks to Azure, or connecting VNets across regions or subscriptions where VNet peering is not supported or desired, a site-to-site VPN gateway connection would be correct.
- ✗
A service endpoint on both subnets.
Why it's wrong here
Service endpoints do not establish any path between the two virtual networks; they extend a specific subnet's identity to a supported Azure PaaS service such as Azure Storage or SQL Database, so that traffic to that service is routed over the Microsoft backbone instead of the public endpoint. Each service endpoint is scoped to a single service and cannot make VNet A's resources reachable to VNet B, nor does it act as a network connection between subnets. Enabling service endpoints on both subnets still only affects how those subnets reach PaaS services, leaving VNet-to-VNet traffic unconnected.
When this WOULD be correct
A question asks: 'How to ensure traffic from a subnet to an Azure Storage account stays on the Microsoft backbone and does not traverse the internet?' — here, configuring a service endpoint on the subnet would be correct.
- ✗
A route table with default routes to each VNet.
Why it's wrong here
User-defined routes and route tables influence the next hop chosen by Azure for packets leaving a subnet, but they cannot create a logical private link between VNets on their own. A route table with a route to the other VNet's prefix is meaningless unless some peering, gateway, or virtual appliance already supplies an actual forwarding path; otherwise Azure will drop traffic or use the system default route. The native path that enables private VNet-to-VNet forwarding is peering, not route-table manipulation, so this option lacks the required connectivity mechanism.
When this WOULD be correct
A route table with default routes to each VNet would be correct in a scenario where you need to force-tunnel traffic from both VNets through a network virtual appliance (NVA) or on-premises firewall for inspection, using user-defined routes (UDRs).
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 peering between the two virtual networks.Correct answer▾
Why this is correct
Azure VNet peering connects the two virtual networks directly over the Microsoft backbone, using private IP addresses with no gateway, VPN tunnel, or public internet traversal. Because the address spaces are non-overlapping, each peered VNet can route traffic to the other's prefix using automatically injected system routes, and unicast traffic can flow in both directions with low and consistent latency. This is the appropriate native mechanism for private VNet-to-VNet communication in the same region, and it can also work globally.
✗A site-to-site VPN gateway connection.Wrong answer — click to see why▾
Why this is wrong here
A site-to-site VPN gateway connection requires a gateway and routes traffic over the internet or ExpressRoute, not directly over private IPs, and incurs additional cost and complexity.
★ When this WOULD be the correct answer
When connecting on-premises networks to Azure, or connecting VNets across regions or subscriptions where VNet peering is not supported or desired, a site-to-site VPN gateway connection would be correct.
Why candidates choose this
Candidates may confuse site-to-site VPN with VNet peering, thinking both provide connectivity, but overlook the 'without deploying a gateway' and 'private IP' constraints in the question.
✗A service endpoint on both subnets.Wrong answer — click to see why▾
Why this is wrong here
Service endpoints secure Azure service access from a VNet but do not enable direct private IP communication between two VNets; they only provide a direct path to PaaS services, not VNet-to-VNet connectivity.
★ When this WOULD be the correct answer
A question asks: 'How to ensure traffic from a subnet to an Azure Storage account stays on the Microsoft backbone and does not traverse the internet?' — here, configuring a service endpoint on the subnet would be correct.
Why candidates choose this
Candidates may confuse service endpoints with VNet peering, thinking both provide direct connectivity, but service endpoints are for accessing Azure services, not for VNet-to-VNet communication.
✗A route table with default routes to each VNet.Wrong answer — click to see why▾
Why this is wrong here
Route tables with default routes to each VNet do not enable direct private IP communication between VNets; they only control traffic within a VNet or to forced-tunneling destinations. VNet peering is required for direct connectivity.
★ When this WOULD be the correct answer
A route table with default routes to each VNet would be correct in a scenario where you need to force-tunnel traffic from both VNets through a network virtual appliance (NVA) or on-premises firewall for inspection, using user-defined routes (UDRs).
Why candidates choose this
Candidates may think that adding routes to the other VNet's address space in a route table is sufficient to enable cross-VNet communication, misunderstanding that route tables alone do not establish connectivity without a peering or gateway.
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
Learn chapter
VPN Gateway and ExpressRoute
Key term
VNet
A virtual private network inside a cloud provider that lets you securely connect and isolate your cloud resources.
Key term
Region
A region is a distinct geographic location where a cloud provider operates multiple data centers that are connected by low-latency networks and provide cloud services.
About these practice questions
This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-104 exam.