AZ-104 Implement and Manage Virtual Networking Practice Question
Exhibit
Hub-and-spoke topology: - Hub VNet contains an active VPN gateway. - Spoke VNet has no gateway. - Requirement: Spoke resources must route on-premises traffic through the hub gateway. - Current spoke-to-hub peering settings: Allow virtual network access = Enabled, Use remote gateways = Disabled.
Based on the exhibit, the spoke virtual network must use the hub's existing VPN gateway to reach on-premises networks. Which peering setting should be enabled on the spoke-to-hub peering?
⚠ Common exam trap
Watch out — candidates often confuse 'Allow forwarded traffic' with 'Use remote gateways', mistakenly thinking that enabling forwarded traffic alone is sufficient to route spoke traffic through the hub's VPN gateway, when in fact 'Use remote gateways' is the specific setting required for gateway transit.
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
✓
Use remote gateways on the spoke peering.
The 'Use remote gateways' setting on the spoke-to-hub peering allows the spoke virtual network to use the hub's existing VPN gateway for connectivity to on-premises networks. This setting forwards traffic from the spoke through the hub's gateway, enabling transitive routing without deploying a separate gateway in the spoke. It requires the hub-to-spoke peering to have 'Allow gateway transit' enabled.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Allow forwarded traffic on the spoke peering.
Why it's wrong here
The 'Allow forwarded traffic' setting on a peering permits traffic from a peered VNet to pass through a network virtual appliance in the hub, but it does not enable the spoke to use the hub's VPN gateway. Gateway transit is a separate peering-level setting that allows the spoke to leverage the hub's VPN gateway for connectivity to on-premises networks. Forwarding applies to IP routing between appliances, not to VPN gateway sharing.
When this WOULD be correct
In a scenario where the spoke needs to receive traffic from on-premises networks via the hub, but the spoke itself does not need to initiate connections to on-premises. For example, if the hub has a VPN gateway and the spoke only needs to be reachable from on-premises, enabling 'Allow forwarded traffic' on the spoke peering allows the hub to forward traffic from on-premises to the spoke.
- ✓
Use remote gateways on the spoke peering.
Why this is correct
To let the spoke use the hub's VPN gateway, the spoke-to-hub peering must be configured with Use remote gateways enabled. This tells Azure that the spoke should send gateway-bound traffic through the remote VNet's gateway rather than deploying its own gateway. It is the required setting in a hub-and-spoke design with shared VPN connectivity.
- ✗
Delete the peering and create a virtual network gateway in the spoke.
Why it's wrong here
Deleting the peering and creating a new virtual network gateway in the spoke would give the spoke its own independent gateway, but this defeats the purpose of the hub-and-spoke design and incurs additional cost. It also requires managing separate VPN infrastructure and does not address the requirement to use the hub's gateway. The correct configuration is to keep the peering and enable 'Use remote gateways' on the spoke's peering.
When this WOULD be correct
This option would be correct if the question stated that the spoke network must have its own independent VPN connection to on-premises, and the hub's gateway is not to be used. For example, if the spoke requires dedicated bandwidth or isolation from hub traffic.
- ✗
Enable service endpoints on the spoke subnet.
Why it's wrong here
Service endpoints do not provide access to on-premises networks and do not influence VPN gateway sharing. They restrict Azure service traffic to a VNet via a direct, private connection to specific Azure services (like Storage or SQL) but have no bearing on how VPN traffic is routed or forwarded. Thus they cannot enable the spoke to use the hub's VPN gateway.
When this WOULD be correct
Enable service endpoints on the spoke subnet when the question asks how to restrict access to an Azure Storage account so that only traffic from a specific subnet in the spoke VNet is allowed, while blocking all other internet traffic. This is a common scenario for securing PaaS services.
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.
✓Use remote gateways on the spoke peering.Correct answer▾
Why this is correct
To let the spoke use the hub's VPN gateway, the spoke-to-hub peering must be configured with Use remote gateways enabled. This tells Azure that the spoke should send gateway-bound traffic through the remote VNet's gateway rather than deploying its own gateway. It is the required setting in a hub-and-spoke design with shared VPN connectivity.
✗Allow forwarded traffic on the spoke peering.Wrong answer — click to see why▾
Why this is wrong here
The question requires the spoke to use the hub's VPN gateway, which is achieved by enabling 'Use remote gateways' on the spoke peering, not 'Allow forwarded traffic'. 'Allow forwarded traffic' permits the hub to forward traffic from other networks to the spoke, but does not allow the spoke to use the hub's gateway.
★ When this WOULD be the correct answer
In a scenario where the spoke needs to receive traffic from on-premises networks via the hub, but the spoke itself does not need to initiate connections to on-premises. For example, if the hub has a VPN gateway and the spoke only needs to be reachable from on-premises, enabling 'Allow forwarded traffic' on the spoke peering allows the hub to forward traffic from on-premises to the spoke.
Why candidates choose this
Candidates may confuse 'Allow forwarded traffic' with 'Use remote gateways' because both involve traffic routing through the hub. They might think that allowing forwarded traffic is necessary for the spoke to use the hub's gateway, but the correct setting for gateway transit is 'Use remote gateways'.
✗Delete the peering and create a virtual network gateway in the spoke.Wrong answer — click to see why▾
Why this is wrong here
Deleting the peering and creating a VPN gateway in the spoke would bypass the hub's existing VPN gateway, which contradicts the requirement to use the hub's gateway for on-premises connectivity. This would also incur additional cost and management overhead.
★ When this WOULD be the correct answer
This option would be correct if the question stated that the spoke network must have its own independent VPN connection to on-premises, and the hub's gateway is not to be used. For example, if the spoke requires dedicated bandwidth or isolation from hub traffic.
Why candidates choose this
Candidates may think that a VPN gateway is needed in the spoke for on-premises connectivity, not realizing that using the hub's gateway via 'Use remote gateways' is the proper design for hub-and-spoke topologies.
✗Enable service endpoints on the spoke subnet.Wrong answer — click to see why▾
Why this is wrong here
Service endpoints secure Azure service access from a virtual network to specific Azure services (e.g., Azure Storage) by forcing traffic over the Microsoft backbone. They do not enable a spoke VNet to use a hub's VPN gateway for on-premises connectivity; that requires the 'Use remote gateways' peering setting.
★ When this WOULD be the correct answer
Enable service endpoints on the spoke subnet when the question asks how to restrict access to an Azure Storage account so that only traffic from a specific subnet in the spoke VNet is allowed, while blocking all other internet traffic. This is a common scenario for securing PaaS services.
Why candidates choose this
Candidates may confuse service endpoints with gateway transit because both involve network connectivity and security. They might think enabling service endpoints somehow allows the spoke to 'reach' on-premises networks via the hub, not realizing service endpoints are for Azure service access only.
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
Virtual network
A virtual network is a software-based network that connects computers, servers, and devices over the internet or within a cloud environment, simulating a physical network without requiring dedicated hardware.
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.