Technical Lab: Design service chaining, including gateway transit
Questions
Question 1 — Multiple Choice
An organization has three virtual networks in Azure: Hub-VNet, Spoke-A, and Spoke-B. The Hub-VNet contains a VPN gateway connected to the on-premises network. Peering between Hub-VNet and each Spoke is configured, but users from the on-premises network cannot reach the VMs in the Spokes.
Which pair of configurations must be enabled in the peerings for on-premises traffic to traverse the Hub gateway to the Spokes?
A) Allow gateway transit in the peering from Hub to Spokes and Use remote gateways in the peering from Spokes to Hub
B) Use remote gateways in the peering from Hub to Spokes and Allow gateway transit in the peering from Spokes to Hub
C) Allow gateway transit on both sides of the peering, both on Hub and Spokes
D) Allow forwarded traffic in the peering from Hub to Spokes and Use remote gateways in the peering from Spokes to Hub
Question 2 — Technical Scenario
An architect configured the topology below to chain services between Spokes using a Network Virtual Appliance (NVA) in the Hub:
Spoke-A (10.1.0.0/16) --> Hub-VNet (10.0.0.0/16) --> Spoke-B (10.2.0.0/16)
NVA: 10.0.1.4
User-defined routes (UDRs) were applied in Spoke-A pointing the next hop to 10.0.1.4. Traffic from Spoke-A reaches the NVA but doesn't proceed to Spoke-B.
What is the most likely cause of the problem?
A) The peering between Hub-VNet and Spoke-B doesn't have Allow forwarded traffic enabled
B) The NVA doesn't have IP Forwarding enabled at the network adapter (NIC) level in Azure
C) The UDR in Spoke-A is pointing to the NVA's IP address instead of the Hub's default gateway
D) The peering between Spoke-A and Hub-VNet doesn't have Use remote gateways enabled
Question 3 — True or False
A Spoke VNet that already uses Use remote gateways to leverage the Hub's VPN gateway can simultaneously have its own virtual network gateway deployed for independent connections to the on-premises network.
Question 4 — Technical Scenario
A company needs all outbound traffic from VMs in Spoke-A to pass through an NVA in the Hub before reaching the internet. The peering between Spoke-A and Hub-VNet is active. The architect applies the following UDR to the Spoke-A subnet:
Destination: 0.0.0.0/0
Next Hop Type: Virtual Appliance
Next Hop Address: 10.0.1.4
After the configuration, traffic still goes directly to the internet without passing through the NVA.
Which missing configuration explains this behavior?
A) Allow gateway transit is not enabled in the peering from Hub to Spoke-A
B) Allow forwarded traffic is not enabled in the peering from Hub-VNet to Spoke-A
C) The UDR was applied to the correct subnet, but the next hop should be of type Internet instead of Virtual Appliance
D) Use remote gateways is not enabled in the peering from Spoke-A to the Hub
Question 5 — Multiple Choice
In a hub-and-spoke topology, what is Azure's default behavior regarding traffic between two Spokes that peer only with the Hub, without direct peering between themselves?
A) Traffic flows automatically between Spokes through the Hub, as peering is transitive by default
B) Traffic between Spokes is blocked by Azure and cannot be routed in any way
C) Traffic between Spokes doesn't flow automatically; a forwarding mechanism in the Hub is required, such as an NVA with UDRs
D) Traffic between Spokes flows automatically only if Allow forwarded traffic is enabled in both peerings with the Hub
Answer Key and Explanations
Answer Key — Question 1
Answer: A
Gateway transit is an asymmetric functionality by design. The side that owns the gateway must enable Allow gateway transit, signaling that it's willing to share it. The side that doesn't have a gateway must enable Use remote gateways, signaling that it wants to use the remote gateway.
Inverting the options (alternative B) is the most common mistake: Use remote gateways on the Hub would be invalid because the Hub is precisely the side that owns the gateway. Alternative C ignores that the options are complementary and directional, not symmetric. Alternative D confuses Allow forwarded traffic, which controls traffic originated outside the VNet, with the gateway sharing mechanism.
Without this correct configuration, the on-premises routes learned by the Hub's gateway simply won't propagate to the Spokes.
Answer Key — Question 2
Answer: B
When a packet arrives at the NVA and needs to be forwarded to another destination, Azure, by default, drops packets whose destination IP address doesn't match the NIC that received them. IP Forwarding must be explicitly enabled on the NVA's NIC in the Azure portal (or via API), in addition to being activated in the VM's operating system.
Alternative A describes a relevant condition for traffic between Spokes, but the problem statement indicates that traffic already leaves Spoke-A and reaches the NVA; the problem is what happens afterward. Alternative C is a conceptual mistake: the UDR correctly points to the NVA's IP as next hop of type Virtual Appliance. Alternative D is irrelevant to this flow, as Use remote gateways is exclusive for VPN/ExpressRoute gateway sharing.
Answer Key — Question 3
Answer: False
Azure enforces an explicit restriction: a VNet that uses Use remote gateways cannot have its own virtual network gateway deployed. The two conditions are mutually exclusive. If a Spoke VNet needs independent connections to the on-premises network, it must have its own gateway and, in that case, cannot activate Use remote gateways.
This behavior exists because Azure cannot consistently determine which gateway should be used to learn and advertise routes if both exist simultaneously. Attempting to deploy a gateway in a VNet with Use remote gateways active will result in an error during deployment.
Answer Key — Question 4
Answer: B
Allow forwarded traffic controls whether the destination VNet accepts packets whose source IP address is outside the VNet from which the traffic was forwarded. When the NVA in the Hub forwards traffic from Spoke-A to the internet, the packet originates from 10.1.x.x (Spoke-A) and arrives at the Hub via peering. For the Hub to accept and process this forwarded traffic, the peering from Hub to Spoke-A needs to have Allow forwarded traffic enabled.
Alternative A refers to gateway transit, which is irrelevant to this outbound flow to the internet via NVA. Alternative C is technically incorrect: Virtual Appliance is the correct next hop type to redirect traffic to an NVA. Alternative D deals with remote gateways, which has no relation to traffic forwarding through NVA.
Answer Key — Question 5
Answer: C
Virtual network peering in Azure is not transitive. This means that even if Spoke-A and Spoke-B peer with the Hub, they don't automatically see each other. Azure doesn't route traffic between peers in a chained manner by default.
To enable communication between Spokes, an explicit mechanism in the Hub is required, with the most common being an NVA combined with UDRs in each Spoke pointing traffic destined for the other Spoke to the NVA's IP.
Alternative A represents the most frequent confusion: assuming transitivity where it doesn't exist. Alternative B is overly restrictive; traffic can be routed, but requires intentional configuration. Alternative D describes a real requirement for forwarded traffic, but alone doesn't solve the absence of transitivity; without the NVA and UDRs, traffic still won't flow between Spokes.