AZ-104 Implement and Manage Virtual Networking Practice Question

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 create a route table in the spoke.

  Why it's wrong here

  Enabling Allow forwarded traffic on both peerings and adding a route table in the spoke is insufficient because that setting only permits traffic from the spoke to hop through network virtual appliances (NVAs) or similar devices in the hub; it does not tell the spoke to use the hub's VPN gateway. VPN gateways do not accept traffic routed to their private IP from a peering as a normal next-hop, and without the dedicated 'Use remote gateways' flag on the spoke peering (along with 'Allow gateway transit' on the hub), the spoke's routes will not learn or utilize the hub's on-premises routes. This approach can even create blackholing if the route table points to a non-existent appliance rather than the gateway.

  When this WOULD be correct

  This option would be correct in a scenario where the spoke VNet needs to route traffic through a hub VNet that is acting as a network virtual appliance (NVA) or firewall, not a VPN gateway. In that case, enabling forwarded traffic on both peerings and adding user-defined routes in the spoke is necessary 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

  This is the standard configuration for letting a spoke VNet use an existing hub VPN gateway. The hub side must allow gateway transit, and the spoke side must be configured to use the remote gateway. Together, these settings let the spoke inherit on-premises connectivity through the hub without deploying a separate gateway.

• ✗

  Deploy a private endpoint in the spoke for each on-premises subnet.

  Why it's wrong here

  Deploying private endpoints in the spoke for each on-premises subnet is invalid because private endpoints are designed to expose a specific Azure PaaS service (like Storage or SQL) via a private IP inside a VNet. They do not represent or connect to arbitrary on-premises networks, and they provide no routing or gateway function between VNets and external locations. On-premises subnets are neither PaaS resources nor consumer services that a private endpoint can target, so this approach cannot inherit the hub's VPN connectivity.

• ✗

  Create a service endpoint on the spoke subnet for Microsoft.Network.

  Why it's wrong here

  Creating a service endpoint on the spoke subnet for Microsoft.Network is not a supported configuration and would not help: service endpoints are meant to extend a VNet's identity and private connectivity to PaaS services such as Storage or SQL, not to route traffic to on-premises. Even if a Microsoft.Network endpoint existed, it would only affect traffic to that service, leaving the spoke without any gateway route toward on-premises prefixes. Thus this action neither enables gateway transit nor provides a path through the hub VPN gateway.

  When this WOULD be correct

  A question asking how to securely access Azure Storage from a spoke VNet without using a public IP, where the storage account is in the hub VNet. In that case, a service endpoint on the spoke subnet for Microsoft.Storage 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.

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