Technical Lab: Configure routing rules
Questions
Question 1 — Multiple Choice
A networking team needs to ensure that traffic originating from a specific subnet in a VNet is always inspected by a Network Virtual Appliance (NVA) before reaching the Internet, even when default routes learned via BGP from a VPN gateway exist.
Which mechanism ensures that the route through the NVA is effectively used?
A) Configure a static route in the VPN gateway route table with next hop type VirtualNetworkGateway
B) Associate a User-Defined Route (UDR) to the subnet with a route for 0.0.0.0/0 and next hop type VirtualAppliance, pointing to the NVA's private IP
C) Enable BGP route propagation in the subnet's route table so the NVA advertises its own default route
D) Create a system route of type VirtualNetworkGateway and associate it directly to the source subnet
Question 2 — Technical Scenario
An engineer configures the following entry in a Route Table associated with a workload subnet:
Destination prefix : 10.2.0.0/16
Next hop type : VirtualAppliance
Next hop address : 10.1.0.4
During testing, traffic destined for 10.2.1.50 reaches the NVA correctly, but traffic destined for 10.2.0.10 doesn't reach the destination machine after passing through the NVA. The NVA is functional and receiving the packets.
What is the most likely cause of the problem?
A) The UDR route covers only the /24 prefix and ignores addresses in the /16 range
B) The NVA doesn't have IP forwarding enabled on the network interface in Azure
C) The destination subnet 10.2.0.0/24 has an overlapping UDR that redirects traffic back to the NVA, causing a loop
D) Azure automatically blocks return traffic on VirtualAppliance type routes by default
Question 3 — True or False
A User-Defined Route with next hop type None associated with a subnet silently drops traffic matching the configured prefix, without generating any ICMP destination unreachable response to the source.
Question 4 — Multiple Choice
A company has two VNets connected via VNet Peering. VNet A contains an NVA that must inspect all traffic between VNet B and on-premises networks connected via VPN gateway in VNet A. The peering is already configured with Allow Gateway Transit in VNet A and Use Remote Gateways in VNet B.
What is still needed for traffic from VNet B to mandatorily pass through the NVA before reaching on-premises?
A) Enable BGP route propagation in VNet B's route table to accept routes advertised by the VPN gateway
B) Create a UDR in VNet B's subnet with a route for on-premises prefixes with next hop VirtualAppliance pointing to the NVA's IP in VNet A
C) Configure a static route in VNet A's VPN gateway redirecting return traffic to the NVA
D) Associate the NVA's Route Table directly to VNet A's gateway subnet
Question 5 — Technical Scenario
A team associated a Route Table to a subnet and disabled gateway route propagation (BGP route propagation = Disabled). After this, machines in that subnet lost connectivity to on-premises networks, but continue reaching resources within the same VNet.
The responsible engineer claims the problem can be solved by manually adding a UDR with next hop VirtualNetworkGateway for on-premises prefixes.
Is the engineer's statement correct?
A) No, because UDRs don't support the VirtualNetworkGateway next hop type in any scenario
B) Yes, because a UDR with next hop VirtualNetworkGateway instructs Azure to forward traffic to the VNet's VPN or ExpressRoute gateway, restoring connectivity
C) No, because disabling gateway route propagation permanently erases entries from the effective route table and they cannot be rewritten via UDR
D) Yes, but only if the gateway is of type ExpressRoute; VPN gateways don't accept this next hop type in UDRs
Answer Key and Explanations
Answer Key — Question 1
Answer: B
A UDR with VirtualAppliance next hop takes precedence over routes learned via BGP from the VPN gateway because UDRs are evaluated before gateway-propagated routes in Azure's preference order. Azure resolves routing conflicts by prefix specificity first and, when prefixes are identical, by route source: UDRs override gateway-propagated routes.
The main misconception represented by the distractors is confusing the precedence hierarchy. Enabling BGP propagation (option C) would do the opposite: make gateway routes visible, not suppress them. Option A configures a route on the wrong side (at the gateway, not the source subnet). Option D describes a system route, which cannot be manually created and has lower precedence than UDRs.
Choosing the wrong alternative would result in traffic bypassing the NVA, eliminating inspection and creating an invisible security gap for the team.
Answer Key — Question 2
Answer: B
When an NVA receives packets and doesn't forward them, the most common problem in Azure is the absence of IP forwarding enabled on the resource's network interface (NIC). Azure, by default, drops packets whose destination is not the NIC's own IP. Enabling IP forwarding on the NIC in the portal/ARM instructs Azure to allow the NVA to function as a router.
Option A is technically incorrect: the UDR covers /16, which includes any 10.2.x.x address. Option C would describe a loop problem, but the statement indicates packets reach the NVA and stop there, not that they return in a loop. Option D doesn't exist as actual Azure behavior.
Without IP forwarding enabled, the NVA logs traffic arriving, but Azure's data plane drops packets before any processing by the NVA's operating system.
Answer Key — Question 3
True
The None next hop type implements a routing "black hole". Azure drops matching packets silently, without sending ICMPv4 Type 3 (Destination Unreachable) back to the source. This behavior is intentional and different from what most traditional routers do.
This has important practical implications: applications that depend on ICMP error messages to detect unreachable destinations may wait for complete TCP connection timeout before noticing the failure, increasing perceived latency and making diagnosis with tools like traceroute difficult.
Answer Key — Question 4
Answer: B
Even with peering configured with Allow Gateway Transit and Use Remote Gateways, Azure learns on-premises routes in VNet B via gateway propagation, but doesn't automatically redirect this traffic through an NVA residing in another VNet. To force passage through the NVA, it's mandatory to create a UDR in VNet B's subnet with on-premises prefixes and next hop VirtualAppliance pointing to the NVA's private IP in VNet A.
The main misconception of the distractors is assuming that peering with transit already guarantees inspection. It only guarantees connectivity via gateway. Option A, enabling BGP propagation, would make on-premises routes appear in VNet B's effective table, but without forcing the path through the NVA. Option D is invalid: associating Route Tables to VNet A's gateway subnet can break gateway functionality and doesn't affect routing originated in VNet B.
Answer Key — Question 5
Answer: B
The VirtualNetworkGateway next hop type is a valid and supported value in UDRs. When gateway route propagation is disabled, routes learned via BGP (from VPN or ExpressRoute gateway) stop appearing automatically in the subnet's effective table. The correct solution is to manually insert UDRs with next hop VirtualNetworkGateway for on-premises prefixes, restoring the path without reactivating automatic propagation.
Option A is factually incorrect: VirtualNetworkGateway is a documented next hop type widely used in hub-and-spoke scenarios where granular control is desired. Option C confuses "disabling propagation" with permanent state destruction. Option D is a classic distractor: VirtualNetworkGateway works for both gateway types, VPN and ExpressRoute.
Understanding that disabling propagation doesn't remove the ability to use the gateway, only the automation of routes, is fundamental for hub-and-spoke scenarios with traffic inspection.