Courseiva
Implement and Manage StoragemediumMultiple ChoiceObjective-mapped

AZ-104 Implement and Manage Storage Practice Question

A hub VNet already has a VPN gateway connected to on-premises. A spoke VNet must send on-premises traffic through the hub gateway without deploying its own gateway. Which peering settings are needed?

⚠ Common exam trap

Many exam-takers confuse 'forwarded traffic' with 'gateway transit' — forwarded traffic only allows VNet-to-VNet traffic forwarding, while gateway transit specifically enables a spoke to use a hub's VPN gateway for external 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

Enable gateway transit on the hub peering and use remote gateways on the spoke peering.

It enables gateway transit on the hub-side peering connection and uses remote gateways on the spoke-side peering connection. This configuration allows the spoke VNet to route on-premises traffic through the hub's VPN gateway without deploying its own gateway, leveraging the hub as a transit point.

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 add a route table to the spoke subnet.

    Why it's wrong here

    Enabling 'Allow forwarded traffic' on both peerings permits the hub to pass traffic between peered VNets or from a spoke to an on-premises network only after a route is explicitly present. Adding a route table to the spoke subnet can define custom routes, but without 'Use remote gateways' and 'Allow gateway transit,' the spoke still lacks a reachable gateway IP and the required VPN/BGP route propagation to send traffic to on-premises. Forwarded traffic controls packet relay, not gateway discovery or route advertisement, so this combination cannot implement gateway reuse.

    When this WOULD be correct

    Option A would be correct in a scenario where a spoke VNet needs to route traffic through a hub VNet's network virtual appliance (NVA) for inspection, without involving a VPN gateway. In that case, you enable forwarded traffic on both peerings and add a route table to the spoke subnet to direct traffic to the NVA.

  • Enable gateway transit on the hub peering and use remote gateways on the spoke peering.

    Why this is correct

    In VNet peering, setting 'Allow gateway transit' on the hub-side peering and 'Use remote gateways' on the spoke-side peering allows the spoke VNet to leverage the hub's VPN gateway for on-premises connectivity without deploying any gateway in the spoke. This configures the peering to advertise the hub gateway routes to the spoke, and the spoke's route table will contain the on-premises prefix as propagated via the hub. It is the only option that satisfies the requirement of using the existing hub gateway while avoiding a dedicated gateway in the spoke.

  • Create a private endpoint in the spoke VNet and route on-premises traffic through it.

    Why it's wrong here

    A private endpoint in the spoke VNet assigns the endpoint a private NIC with an IP from the spoke subnet, enabling inbound connections from on-premises to a specific PaaS service (e.g., SQL or Storage) over the hub VPN, but it is not a routing infrastructure for general spoke workloads. On-premises traffic destined to ordinary workload addresses in the spoke cannot be 'routed through a private endpoint' because a private endpoint only maps to a particular resource's DNS/IP and does not act as a next-hop VPN gateway or virtual appliance. Also, using a private endpoint for this purpose would be aimed at consuming a PaaS service rather than allowing the on-premises site to reach the spoke VNet's range.

    When this WOULD be correct

    In a scenario where a spoke VNet needs to securely access an Azure Storage account or SQL Database without exposing it to the public internet, and the traffic must stay within the Microsoft backbone, creating a private endpoint in the spoke VNet would be the correct answer.

  • Deploy a second VPN gateway in the spoke and connect it in active-active mode.

    Why it's wrong here

    Deploying a second VPN gateway in the spoke and running it in active-active mode directly violates the requirement that the spoke not deploy its own gateway. Even ignoring that, active-active mode only provides gateway redundancy and higher availability for the spoke's own connection, not on-premises connectivity via the hub; it introduces significant extra cost, configuration overhead, and SKU requirements. The hub gateway already exists, so the correct pattern is to reuse it through gateway transit rather than create a parallel VPN infrastructure.

    When this WOULD be correct

    This option would be correct if the question asked for high availability or increased throughput for site-to-site connections from the spoke VNet, requiring an active-active VPN gateway in the spoke itself.

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

In VNet peering, setting 'Allow gateway transit' on the hub-side peering and 'Use remote gateways' on the spoke-side peering allows the spoke VNet to leverage the hub's VPN gateway for on-premises connectivity without deploying any gateway in the spoke. This configures the peering to advertise the hub gateway routes to the spoke, and the spoke's route table will contain the on-premises prefix as propagated via the hub. It is the only option that satisfies the requirement of using the existing hub gateway while avoiding a dedicated gateway in the spoke.

Enable forwarded traffic on both peerings and add a route table to the spoke subnet.Wrong answer — click to see why

Why this is wrong here

Option A is wrong because enabling forwarded traffic alone does not allow the spoke to use the hub's VPN gateway; it only permits traffic to be forwarded between VNets. The correct approach requires enabling gateway transit on the hub peering and using remote gateways on the spoke peering.

★ When this WOULD be the correct answer

Option A would be correct in a scenario where a spoke VNet needs to route traffic through a hub VNet's network virtual appliance (NVA) for inspection, without involving a VPN gateway. In that case, you enable forwarded traffic on both peerings and add a route table to the spoke subnet to direct traffic to the NVA.

Why candidates choose this

Candidates may confuse the need for forwarding traffic between VNets with the specific requirement to use a VPN gateway. They might think enabling forwarded traffic is sufficient, not realizing that gateway transit is a separate setting required for VPN gateway sharing.

Create a private endpoint in the spoke VNet and route on-premises traffic through it.Wrong answer — click to see why

Why this is wrong here

A private endpoint is used for secure access to Azure PaaS services over a private IP, not for routing on-premises traffic through a hub VPN gateway. It does not provide transit routing between VNets or to on-premises.

★ When this WOULD be the correct answer

In a scenario where a spoke VNet needs to securely access an Azure Storage account or SQL Database without exposing it to the public internet, and the traffic must stay within the Microsoft backbone, creating a private endpoint in the spoke VNet would be the correct answer.

Why candidates choose this

Candidates may confuse private endpoints with network virtual appliances or think that any private IP-based solution can route traffic, misunderstanding the purpose of private endpoints as a routing mechanism.

Deploy a second VPN gateway in the spoke and connect it in active-active mode.Wrong answer — click to see why

Why this is wrong here

Deploying a second VPN gateway in the spoke VNet contradicts the requirement to avoid deploying its own gateway. The goal is to route on-premises traffic through the hub gateway, not add another gateway.

★ When this WOULD be the correct answer

This option would be correct if the question asked for high availability or increased throughput for site-to-site connections from the spoke VNet, requiring an active-active VPN gateway in the spoke itself.

Why candidates choose this

Candidates may think adding a gateway in the spoke provides more control or redundancy, overlooking the explicit requirement to use the hub gateway without deploying a spoke 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?”

About these practice questions

One of 1,049 original AZ-104 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.