Skip to main content

Technical Lab: Configure Virtual Hub Routing

Questions​

Question 1 — Multiple Choice​

A network team needs to ensure that traffic between two virtual networks (VNets) connected to the same Virtual WAN hub is inspected by an NVA (Network Virtual Appliance) hosted in a dedicated VNet, also connected to the same hub. The workload VNets should not communicate directly with each other.

Which routing configuration in the Virtual WAN hub meets this requirement?

A) Create a custom Route Table and associate the workload VNet connections to it, with static routes pointing the prefix of other VNets to the next hop in the NVA, and propagate these connections only to the NVA's Route Table.

B) Associate all VNet connections to the default Route Table (defaultRouteTable) and add static routes with the prefix 0.0.0.0/0 pointing to the NVA.

C) Enable Routing Intent with private traffic policy and define the NVA as the next hop, without needing additional custom Route Tables.

D) Create a custom Route Table, associate all VNet connections to it and configure bidirectional propagation between all connections to ensure mutual visibility.

Question 2 — Technical Scenario​

An architect configured the Virtual WAN hub with the following routing structure:

  • VNet-App connection: associated with RT-App, propagates to RT-App and defaultRouteTable
  • VNet-Shared connection: associated with defaultRouteTable, propagates to defaultRouteTable
  • VNet-App does not receive routes from VNet-Shared

After reviewing the logs, the architect confirms that VNet-App cannot reach resources in VNet-Shared. What is the most likely cause?

A) The VNet-App connection propagates to defaultRouteTable, but the defaultRouteTable is not associated with the VNet-App connection, so it doesn't receive the routes that VNet-Shared propagates.

B) VNet-Shared needs to propagate its routes also to RT-App so that VNet-App learns the prefix of VNet-Shared.

C) The Virtual WAN hub requires that both connections be associated with the same Route Table for communication between VNets to be possible.

D) The propagation from VNet-App to defaultRouteTable is creating a routing loop that drops packets before they reach VNet-Shared.

Question 3 — True or False​

Statement: In Azure Virtual WAN, when Routing Intent is enabled with private traffic policy, routes learned via BGP from Site-to-Site VPN and ExpressRoute connections are automatically suppressed from the defaultRouteTable, and the hub starts advertising only the 0.0.0.0/0 route and RFC 1918 prefixes as return routes to the branches.

True or False?

Question 4 — Technical Scenario​

A company has two Virtual WAN hubs in the same vWAN: Hub-East and Hub-West. A VNet connected to Hub-East needs to reach a VNet connected to Hub-West. The network team reports that connectivity between the VNets is not working, despite both connections being associated with and propagating to the defaultRouteTable of their respective hubs.

Hub-East defaultRouteTable:
  - Route to VNet-East: Next Hop = VNet-East connection
  - (no route to Hub-West prefixes)

Hub-West defaultRouteTable:
  - Route to VNet-West: Next Hop = VNet-West connection
  - (no route to Hub-East prefixes)

What is the root cause of the problem?

A) VNet connections need to propagate to the remote hub's Route Table directly, which is not supported in Virtual WAN.

B) Inter-hub connectivity depends on the hubs being connected to each other; if the inter-hub connection is not established or is disabled, prefixes from one hub are not propagated to the other.

C) It's necessary to create manual static routes in both defaultRouteTables pointing remote prefixes to the remote hub's IP address.

D) VNets can only communicate between different hubs if they are associated with a custom Route Table with the cross-hub label enabled.

Question 5 — Multiple Choice​

When configuring static routes in a Virtual WAN hub Route Table, which of the options below correctly describes the behavior of the next hop field?

A) The next hop must be a private IP address of a resource within a VNet connected to the hub, as Virtual WAN does not accept connection objects as next hop.

B) The next hop can be a VNet connection, a VPN connection, an ExpressRoute connection, or the IP address of an NVA in a spoke VNet, depending on the type of route configured.

C) The next hop in static routes in the hub accepts only IP addresses, never connection objects, regardless of traffic type.

D) The next hop for static routes that direct traffic to an NVA must be the NVA's public IP address, as the hub routes traffic via internet before delivering it to the spoke VNet.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: A

Alternative A correctly describes the routing segmentation with NVA inspection pattern in Virtual WAN. The workload VNet connections are associated with a custom Route Table with static routes directing traffic to the next hop in the NVA. Propagation is configured only to the NVA's Route Table, preventing workload VNets from learning routes from each other directly.

The main errors in the distractors:

  • B uses 0.0.0.0/0 to direct all traffic to the NVA, but without segmentation between connections, which allows direct communication between VNets via learned routes.
  • C describes Routing Intent, which is valid for scenarios with Azure Firewall or NVAs supported via Routing Intent, but is not applicable to any arbitrary NVA in a spoke VNet without explicit support.
  • D configures bidirectional propagation between all connections, which allows direct visibility between VNets, violating the isolation requirement.

Answer Key — Question 2​

Answer: B

The central mechanism here is: a VNet connection learns only the routes that are propagated to the Route Table to which it is associated. Since VNet-App is associated with RT-App, it learns only what is propagated to RT-App. The VNet-Shared connection propagates only to defaultRouteTable, not to RT-App. Therefore, VNet-App never learns the prefix of VNet-Shared.

Distractor A confuses the direction of flow: the propagation from VNet-App to defaultRouteTable determines what others learn about VNet-App, not what VNet-App learns about others.

Distractor C is a common misconception: Virtual WAN explicitly supports communication between VNets in different Route Tables, as long as routing is configured correctly.

Answer Key — Question 3​

Answer: False

The statement mixes two distinct behaviors. When Routing Intent with private traffic policy is enabled, the hub advertises RFC 1918 prefixes (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to branches as attraction routes, directing private traffic through the configured next hop (e.g., Azure Firewall). However, routes learned via BGP from branch connections are not simply suppressed from the defaultRouteTable: they continue to be processed by the hub to ensure adequate return routing. Routing Intent modifies the route advertisement behavior to branches, but does not eliminate internal BGP route learning in the hub.

Answer Key — Question 4​

Answer: B

In Virtual WAN, route propagation between hubs occurs automatically only when the hubs are connected to each other (inter-hub connection established within the same vWAN). Without this active connection, each hub operates in isolation: the defaultRouteTables do not exchange information and VNet prefixes from one hub do not appear in the other.

Distractor C describes a solution for routing with NVAs or specific scenarios, but is not the root cause nor the appropriate correction for the described problem. Distractor D is entirely fictitious: there is no concept of a cross-hub label in Virtual WAN.

Answer Key — Question 5​

Answer: B

In Virtual WAN hub Route Tables, the next hop field accepts different types of objects depending on the desired destination. To direct traffic to a spoke VNet, the next hop can be the VNet connection itself. To direct to an NVA within a spoke VNet, the next hop is the private IP address of the NVA. For branches, it can be a VPN or ExpressRoute connection.

Distractor A denies the possibility of using connection objects, which is incorrect. Distractor C incorrectly generalizes that only IPs are accepted. Distractor D is technically invalid: the hub never routes private traffic via a public IP address of an NVA, as this would violate Virtual WAN's private routing model.