AZ-104 Implement and Manage Storage Practice Question
A hub VNet already has a VPN gateway connected to on-premises networks. A new spoke VNet must reach those on-premises networks through the existing gateway without deploying another gateway. Which peering settings are required?
⚠ Common exam trap
Watch out — candidates often confuse which peering (hub or spoke) gets which setting, incorrectly assuming 'Use remote gateways' goes on the hub and 'Gateway transit' on the spoke, or they think 'Forwarded traffic' is sufficient for gateway routing.
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 allow a spoke VNet to use the hub VNet's VPN gateway without deploying its own, you must enable 'Use remote gateways' on the spoke peering and 'Gateway transit' on the hub peering. This configuration allows the spoke to route traffic destined for on-premises networks through the hub's VPN gateway, leveraging the existing site-to-site VPN connection.
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 gateway transit on the hub peering and use remote gateways on the spoke peering.
Why this is correct
To let a spoke VNet use the hub's gateway, the hub side must allow gateway transit and the spoke side must be configured to use the remote gateway. This combination lets the spoke send traffic to on-premises networks through the existing hub VPN gateway, avoiding duplicate gateway deployment. It is the standard design for hub-and-spoke environments that centralize connectivity and reduce cost and operational overhead.
- ✗
Enable forwarded traffic on both peerings and leave gateway settings disabled.
Why it's wrong here
The 'Allow forwarded traffic' flag permits a network virtual appliance (NVA) in one peered VNet to forward packets from another VNet, enabling traffic to pass through an NVA for inspection or routing. It does not make the hub's VPN gateway available to the spoke, and leaving gateway settings disabled means the hub gateway's routes are not propagated into the spoke. Without gateway transit, the spoke has no default route or learned on-premises prefix pointing to the hub gateway, so spoke traffic to on-premises has no next hop and is dropped rather than sent through the VPN.
When this WOULD be correct
This option would be correct in a scenario where traffic must flow between two peered VNets through a network virtual appliance (NVA) in the hub, but the hub does not have a VPN gateway. For example, if the hub VNet has an NVA for inspection and the spoke VNet needs to send traffic to another spoke via the hub, enabling forwarded traffic on both peerings allows the NVA to route traffic between them.
- ✗
Enable use remote gateways on the hub peering and gateway transit on the spoke peering.
Why it's wrong here
These settings are directional and locked to the VNet that actually contains the gateway. The hub's peering connection must have 'Allow gateway transit' enabled because it is the VNet with the VPN gateway; the spoke's peering connection must then select 'Use remote gateways' to consume that hub gateway. Reversing them makes the hub attempt to use the spoke's remote gateway, which does not exist, and makes the spoke try to provide transit without a local gateway, so no on-premises route is ever advertised to the spoke and the configuration fails.
When this WOULD be correct
This option would be correct if the VPN gateway were deployed in the spoke VNet instead of the hub. In that scenario, the spoke would enable gateway transit, and the hub would enable use remote gateways to access the spoke's gateway.
- ✗
Create a private endpoint between the two VNets.
Why it's wrong here
A private endpoint is a network interface with a private IP address that attaches a specific PaaS resource, such as SQL Database or Azure Storage, to a VNet; it is not a connection mechanism between two VNets and it cannot expose a VPN gateway as a consumable service. Even if a private endpoint were placed in the spoke, the hub VPN gateway is not a PaaS endpoint and no transitive route to on-premises would be created. Therefore, creating a private endpoint would have no effect on spoke-to-on-premises routing and is unrelated to sharing a gateway across peered VNets.
When this WOULD be correct
A question asks: 'You need to securely connect an Azure VM to an Azure Storage account without using the public internet. Which solution should you use?' In that scenario, creating a private endpoint for the Storage account in the same VNet would be correct.
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
To let a spoke VNet use the hub's gateway, the hub side must allow gateway transit and the spoke side must be configured to use the remote gateway. This combination lets the spoke send traffic to on-premises networks through the existing hub VPN gateway, avoiding duplicate gateway deployment. It is the standard design for hub-and-spoke environments that centralize connectivity and reduce cost and operational overhead.
✗Enable forwarded traffic on both peerings and leave gateway settings disabled.Wrong answer — click to see why▾
Why this is wrong here
Option B is wrong because enabling forwarded traffic alone does not allow the spoke VNet to use the hub's VPN gateway. Gateway transit must be enabled on the hub peering, and the spoke must use remote gateways to route traffic through the hub's gateway.
★ When this WOULD be the correct answer
This option would be correct in a scenario where traffic must flow between two peered VNets through a network virtual appliance (NVA) in the hub, but the hub does not have a VPN gateway. For example, if the hub VNet has an NVA for inspection and the spoke VNet needs to send traffic to another spoke via the hub, enabling forwarded traffic on both peerings allows the NVA to route traffic between them.
Why candidates choose this
Candidates may confuse 'forwarded traffic' with gateway transit, thinking that enabling forwarded traffic allows the spoke to use the hub's gateway. They might also overlook that gateway transit is a separate setting specifically for VPN/ExpressRoute gateways.
✗Enable use remote gateways on the hub peering and gateway transit on the spoke peering.Wrong answer — click to see why▾
Why this is wrong here
Option C reverses the required settings: gateway transit must be enabled on the hub (where the gateway resides) and use remote gateways on the spoke. Enabling use remote gateways on the hub would attempt to use a non-existent gateway in the spoke, and gateway transit on the spoke would not allow the spoke to use the hub's gateway.
★ When this WOULD be the correct answer
This option would be correct if the VPN gateway were deployed in the spoke VNet instead of the hub. In that scenario, the spoke would enable gateway transit, and the hub would enable use remote gateways to access the spoke's gateway.
Why candidates choose this
Candidates may confuse which VNet hosts the gateway and incorrectly assume the spoke should enable gateway transit because it needs to 'transit' traffic, or they may misremember the direction of the settings.
✗Create a private endpoint between the two VNets.Wrong answer — click to see why▾
Why this is wrong here
A private endpoint enables secure connectivity to a specific Azure service (e.g., Storage, SQL) over the Microsoft backbone, not transitive routing to on-premises networks through a VPN gateway. It does not provide network-level routing between VNets or to on-premises.
★ When this WOULD be the correct answer
A question asks: 'You need to securely connect an Azure VM to an Azure Storage account without using the public internet. Which solution should you use?' In that scenario, creating a private endpoint for the Storage account in the same VNet would be correct.
Why candidates choose this
Candidates may confuse private endpoints with VNet peering or think that any 'private' connection can replace gateway transit, not understanding that private endpoints are for PaaS services, not for routing traffic between networks.
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
VPN Gateway
A VPN Gateway is a network device or service that creates an encrypted tunnel between two or more networks over the internet, allowing secure communication.
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
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.