Courseiva
Implement and Manage StoragemediumMultiple ChoiceObjective-mapped

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?”

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 →

How Courseiva writes practice questions · Editorial policy

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.