AZ-104 Implement and Manage Storage Practice Question
A hub VNet contains a VPN gateway that provides access to on-premises resources. A spoke VNet is peered to the hub and must send on-premises traffic through the hub gateway without deploying its own gateway. What peering configuration is required?
⚠ Common exam trap
Test-takers frequently confuse 'forwarded traffic' with 'gateway transit'—forwarded traffic only allows traffic from a third VNet to pass through the peering, but it does not enable the hub's VPN gateway to be used by the spoke; gateway transit is the specific setting required for this scenario.
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
✓
Enable gateway transit on the hub peering and Use remote gateways on the spoke peering.
To route spoke VNet traffic through the hub VPN gateway without deploying a separate gateway in the spoke, you must enable 'Use remote gateways' on the spoke peering and 'Gateway transit' on the hub peering. This configuration allows the spoke to use the hub's VPN gateway for on-premises connectivity, leveraging the transitive routing capability of VNet peering.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable forwarded traffic on both peerings and disable gateway transit.
Why it's wrong here
Enabling forwarded traffic on both peerings only permits the hub to forward packets that did not originate within the peered networks—this is intended for traffic transiting a network virtual appliance (NVA). It does not, by itself, allow the spoke to use the hub's VPN gateway for on-premises connectivity. Gateway transit is a distinct peering property: the hub peering must allow gateway transit and the spoke peering must use the remote gateway. Disabling gateway transit explicitly blocks the propagation of on-premises routes from the hub gateway into the spoke's effective route table, so the spoke will never learn routes to on-premises through this path.
When this WOULD be correct
This option would be correct in a scenario where the spoke VNet needs to forward traffic to the hub for inspection (e.g., via a network virtual appliance) but the hub does not provide gateway transit; instead, the spoke has its own VPN gateway for on-premises access.
- ✓
Enable gateway transit on the hub peering and Use remote gateways on the spoke peering.
Why this is correct
This is the correct hub-and-spoke gateway sharing configuration. The hub peering must allow gateway transit, and the spoke peering must use the remote gateway in the hub. Together, these settings let the spoke route on-premises traffic through the hub VPN gateway without deploying a second gateway.
- ✗
Create a second VPN gateway in the spoke and peer the two gateways.
Why it's wrong here
Deploying a second VPN gateway in the spoke and attempting to peer the gateways is an anti-pattern. Azure virtual network peering connects virtual networks, not VPN gateways; VPN gateways cannot be directly peered to each other. This approach duplicates the gateway cost, introduces additional IPsec tunnel management, and requires separate BGP configurations, whereas the hub-and-spoke design already supports gateway transit through peering. The correct configuration uses the hub's existing VPN gateway as the shared egress/ingress point, so a second gateway is unnecessary and will incorrectly try to establish an on-premises connection from the spoke instead of leveraging the hub's already-established connectivity.
When this WOULD be correct
This option would be correct if the question required high availability or isolation, such as when the spoke must have its own direct VPN connection to on-premises for redundancy or compliance, independent of the hub.
- ✗
Configure the spoke subnet with a service endpoint to the hub gateway subnet.
Why it's wrong here
Configuring a service endpoint on the spoke subnet to the hub gateway subnet is fundamentally misapplied. Service endpoints provide private, direct connectivity to Azure PaaS services (such as Azure Storage or SQL Database) over the Microsoft backbone; they are not a routing mechanism for network gateways. The hub gateway subnet is a network resource, not a PaaS service, and service endpoints cannot be used to influence the path toward on-premises networks. This action would have no effect on the spoke's ability to reach on-premises systems through the hub VPN gateway, nor would it modify the effective routes in the spoke subnet.
When this WOULD be correct
This option would be correct in a scenario where a subnet in a spoke VNet needs to securely access an Azure PaaS service (like Azure Storage or SQL Database) without using a public IP, by routing traffic through the hub's service endpoint.
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.
✓Enable gateway transit on the hub peering and Use remote gateways on the spoke peering.Correct answer▾
Why this is correct
This is the correct hub-and-spoke gateway sharing configuration. The hub peering must allow gateway transit, and the spoke peering must use the remote gateway in the hub. Together, these settings let the spoke route on-premises traffic through the hub VPN gateway without deploying a second gateway.
✗Enable forwarded traffic on both peerings and disable gateway transit.Wrong answer — click to see why▾
Why this is wrong here
Option A is wrong because 'disable gateway transit' would prevent the spoke from using the hub's VPN gateway, and 'enable forwarded traffic' alone does not allow the spoke to use the hub gateway for on-premises connectivity.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the spoke VNet needs to forward traffic to the hub for inspection (e.g., via a network virtual appliance) but the hub does not provide gateway transit; instead, the spoke has its own VPN gateway for on-premises access.
Why candidates choose this
Candidates may confuse 'forwarded traffic' with 'gateway transit' or think that enabling forwarded traffic on both peerings is sufficient to route spoke traffic through the hub gateway, overlooking the specific gateway transit setting.
✗Create a second VPN gateway in the spoke and peer the two gateways.Wrong answer — click to see why▾
Why this is wrong here
Creating a second VPN gateway in the spoke defeats the purpose of using hub gateway transit, as it adds cost and complexity. The requirement is to avoid deploying a separate gateway in the spoke.
★ When this WOULD be the correct answer
This option would be correct if the question required high availability or isolation, such as when the spoke must have its own direct VPN connection to on-premises for redundancy or compliance, independent of the hub.
Why candidates choose this
Candidates may think that having a dedicated gateway in the spoke ensures direct connectivity, overlooking the cost and management overhead, or they may confuse this with a scenario where hub transit is not desired.
✗Configure the spoke subnet with a service endpoint to the hub gateway subnet.Wrong answer — click to see why▾
Why this is wrong here
Service endpoints are used to secure Azure service access from a subnet to a service (e.g., Storage, SQL) over the Azure backbone, not to route traffic to a VPN gateway or enable gateway transit.
★ When this WOULD be the correct answer
This option would be correct in a scenario where a subnet in a spoke VNet needs to securely access an Azure PaaS service (like Azure Storage or SQL Database) without using a public IP, by routing traffic through the hub's service endpoint.
Why candidates choose this
Candidates may confuse service endpoints with gateway transit, thinking that a service endpoint can provide connectivity to on-premises resources via the hub gateway, or they may misunderstand the purpose of service endpoints as a general routing feature.
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 peering
VNet peering is a networking connection that links two virtual networks so they can communicate with each other as if they were a single network.
Key term
VNet
A virtual private network inside a cloud provider that lets you securely connect and isolate your cloud resources.
About these practice questions
Courseiva writes every AZ-104 question from scratch — 1,049 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.