Technical Lab: Configure user-defined routes
Questions
Question 1 — Multiple Choice
A security team requires that all outbound traffic from an application subnet to the internet must pass through a Network Virtual Appliance (NVA) deployed in a dedicated subnet. The NVA is already configured with IP forwarding enabled on the network interface.
Which Azure resource must be created and associated to ensure traffic is redirected as required?
A) A Network Security Group (NSG) with an outbound rule pointing to the NVA IP as destination
B) A route table with a user-defined route (UDR) of type VirtualAppliance, associated to the application subnet
C) A route table with a user-defined route (UDR) of type VirtualAppliance, associated to the NVA subnet
D) An Azure Firewall configured as default gateway in the application subnet, overriding any existing routes
Question 2 — Technical Scenario
An administrator created the following route in a route table associated to the app-subnet:
Destination prefix: 0.0.0.0/0
Next hop type: VirtualAppliance
Next hop address: 10.1.1.4
After associating the route table, VMs in the app-subnet completely lose connectivity, including with other subnets within the same VNet. The NVA at IP 10.1.1.4 is running with IP forwarding enabled on the NIC.
What is the most likely cause of the problem?
A) The VirtualAppliance type is not compatible with 0.0.0.0/0 prefix routes; the correct type would be Internet
B) The route table was associated to the wrong subnet; it should be associated to the NVA subnet
C) The NVA is in the same VNet as the VMs, which prevents routing between subnets via UDR
D) The NVA is not processing or forwarding the received traffic, acting as a black hole for all packets
Question 3 — True or False
A user-defined route (UDR) with prefix 10.0.0.0/16 and next hop type None configured in a route table associated to a subnet silently drops all traffic destined to that prefix, preventing communication even if more specific system routes exist for subnets within that range.
Question 4 — Multiple Choice
An organization has two VNets connected via VNet Peering: vnet-hub (10.0.0.0/16) and vnet-spoke (10.1.0.0/16). In vnet-spoke, there is a route table associated to spoke-subnet with the following UDR:
Destination prefix: 10.0.0.0/16
Next hop type: VirtualAppliance
Next hop address: 10.0.1.4
The peering is configured with Allow forwarded traffic enabled on both sides. Even so, traffic from spoke-subnet to vnet-hub does not reach the destination and is dropped.
What is the most likely cause?
A) VNet Peering does not support UDRs that redirect traffic between peered VNets
B) The Use remote gateways option is not enabled on vnet-spoke, preventing routing via NVA
C) The NVA at 10.0.1.4 is in vnet-hub, but the subnet where it resides does not have a route table that allows traffic return to vnet-spoke
D) The UDR in spoke-subnet overrides the peering route, but the NVA is not forwarding traffic to vnet-hub
Question 5 — Technical Scenario
An administrator needs to ensure that VMs in a specific subnet never route traffic to the internet directly, not even via Azure's default gateway. The requirement is that any external access attempt should simply be dropped without redirection.
The administrator creates the following UDR and associates it to the subnet:
Destination prefix: 0.0.0.0/0
Next hop type: ?
Which next hop type meets this exact requirement?
A) Internet
B) VirtualNetworkGateway
C) None
D) VirtualAppliance with address 0.0.0.0
Answer Key and Explanations
Answer Key — Question 1
Answer: B
A route table with a UDR of type VirtualAppliance must be associated to the traffic source subnet, i.e., the application subnet. That is where Azure consults the routing table to decide the next hop for packets originating from that subnet.
The main conceptual error in the distractors is confusing the route table association point. Alternative C associates the table to the NVA subnet, which would control traffic leaving the NVA, not traffic arriving at it. Alternative A confuses NSG with routing: NSGs filter traffic by allowing or denying, but do not redirect packets to a next hop. Alternative D introduces a different service without direct relation to UDR configuration.
Answer Key — Question 2
Answer: D
The route is technically correct in structure: the 0.0.0.0/0 prefix, VirtualAppliance type, and next hop address are valid. IP forwarding enabled on the NVA's NIC is a necessary but not sufficient condition. The NVA also needs to be configured at the operating system level to forward packets (for example, net.ipv4.ip_forward=1 on Linux, or routing enabled on Windows). Without this, the NVA receives the packets but drops them instead of forwarding them, behaving like a black hole.
The other distractors represent common misconceptions: VirtualAppliance is compatible with 0.0.0.0/0 (A is false); the route table should indeed be in the source subnet, not the NVA's (B is the correct behavior and already done); VMs in the same VNet can communicate via NVA with UDRs without topological restriction (C is false).
Answer Key — Question 3
False
This statement is false. UDRs follow the longest prefix match principle. If system routes exist for more specific subnets within 10.0.0.0/16, such as 10.0.1.0/24, these more specific routes prevail over the UDR with the broader prefix. Traffic destined to 10.0.1.5, for example, would use the system /24 route and would not be dropped by the /16 UDR.
The non-obvious point here is that None drops traffic only when no more specific route exists that wins in longest prefix match. Understanding this precedence is essential to avoid accidental blocking or, conversely, to create intentional and precise blocking.
Answer Key — Question 4
Answer: D
When a UDR redirects traffic between peered VNets to an NVA, the NVA is responsible for forwarding that traffic to the final destination. If the NVA is not configured to do IP forwarding at the OS level, packets reach it and are dropped. The peering route was overridden by the UDR (expected and correct behavior), but the next link in the chain, the NVA, did not complete the forwarding.
Alternative C is technically relevant in asymmetric return traffic scenarios, but is not the cause of dropping in the spoke -> hub direction described. Alternative B confuses Use remote gateways with NVA routing: this option is relevant for traffic via VPN Gateway or ExpressRoute, not for NVAs in peering. Alternative A is false: UDRs work normally in topologies with VNet Peering.
Answer Key — Question 5
Answer: C
The next hop type None instructs Azure to silently drop packets that match the prefix, without attempting to forward them to any destination. It is equivalent to a "null route" or "blackhole" route in traditional routing.
Alternative A (Internet) would forward traffic directly to the internet via Azure backbone, the opposite of the requirement. Alternative B (VirtualNetworkGateway) would redirect to a VPN or ExpressRoute gateway, not drop. Alternative D is invalid: VirtualAppliance requires a valid and functional next hop IP address; 0.0.0.0 is not an operational address, and the behavior would be unpredictable or result in configuration error.