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.

• ✗

  Create peering only; the spoke will automatically use the hub gateway without extra settings.

  Why it's wrong here

  VNet peering only establishes IP connectivity between the two virtual networks; it does not automatically enable the hub's VPN gateway for spoke use. Gateway transit is an explicit peering attribute that must be enabled on the hub peering and accepted on the spoke peering. Without setting Allow gateway transit on the hub side and Use remote gateways on the spoke side, Azure will not inject the hub gateway's routes into the spoke's effective route table, so traffic to on-premises will fail or be dropped.

  When this WOULD be correct

  This would be correct if the question stated that the hub VNet already has 'Allow gateway transit' enabled and the spoke VNet has 'Use remote gateways' enabled, and the candidate is asked what additional peering settings are needed—then the answer would be 'none, the settings are already in place'.

• ✗

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

  Why it's wrong here

  These two peering flags have specific, non-interchangeable roles. The hub VNet that owns the VPN gateway must set Allow gateway transit on its peering side to expose the gateway to the peer, while the spoke VNet must set Use remote gateways on its peering side to consume that gateway. Reversing the settings means the hub never advertises the gateway as transitive and the spoke attempts to use a remote gateway that has not been offered; Azure also blocks the Use remote gateways setting when the remote side has not enabled Allow gateway transit.

  When this WOULD be correct

  This option would be correct if the question asked about enabling transit from the hub to the spoke (e.g., allowing the hub to use a gateway deployed in the spoke), or if the roles of hub and spoke were reversed in the peering definitions.

• ✓

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

  Why this is correct

  In a hub-spoke design, the hub VNet that owns the VPN gateway must allow gateway transit, and the spoke must be configured to use the remote gateway. This lets the spoke route on-premises traffic through the hub without deploying its own gateway. The direction of these settings matters, and reversing them breaks the design.

• ✗

  Create a service endpoint from the spoke VNet to the on-premises network.

  Why it's wrong here

  Service endpoints are designed for private access to Azure PaaS services, such as Azure Storage or SQL Database, by adding the VNet's public IP prefix to the service's firewall. They cannot be configured for on-premises network address ranges and do not influence routing toward a VPN gateway or ExpressRoute circuit. Therefore, creating a service endpoint from the spoke to the on-premises network is not a valid operation and would have no effect on on-premises connectivity; the spoke still requires gateway transit or its own gateway to reach on-premises resources.

  When this WOULD be correct

  A question asks: 'You need to allow a VNet to securely access Azure Storage without using a public IP. What should you configure?' In that case, creating a service endpoint from the VNet to the Storage service is 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