Technical Lab: Integrate a virtual hub with a third-party NVA for cloud connectivity
Questions
Question 1 — Multiple Choice
A network team needs to integrate a third-party NVA (Network Virtual Appliance) into a Virtual WAN hub to inspect traffic between branches and Azure. The NVA manufacturer has confirmed that the appliance is compatible with Microsoft's integration program.
What is the fundamental requirement for a third-party NVA to be deployed directly within a managed Virtual WAN hub?
A) The NVA must be manually deployed in a spoke VNet and connected to the hub via VNet peering, without need for additional qualification.
B) The NVA must be an offering published in Azure Marketplace and approved for integration with the Virtual WAN hub by Microsoft's partner program.
C) The NVA must be deployed as a standalone VM and have a UDR pointing its private IP as next-hop in the hub's route tables.
D) The NVA must exclusively support the BGP over IPsec protocol to be accepted as a managed resource within the hub.
Question 2 — Technical Scenario
An engineer is configuring a third-party NVA integrated with a Virtual WAN hub. After provisioning the NVA infrastructure, they observe that traffic between two spoke VNets connected to the same hub is not passing through the NVA, even with routing intent configurations enabled.
Hub: eastus-vwan-hub
NVA: Deployed (status: Succeeded)
Routing Intent: Private Traffic -> NVA (configured)
Spoke VNet A -> Hub: Connected
Spoke VNet B -> Hub: Connected
Observed: Traffic Spoke A <-> Spoke B bypasses the NVA
What is the most likely cause for this behavior?
A) The NVA does not support east-west traffic between spokes; this function is exclusive to Azure Firewall when used as next-hop in the hub.
B) Routing Intent was configured correctly, but the spoke VNets still have custom route tables with static routes that override the routes propagated by the hub.
C) The NVA integrated with the hub only intercepts north-south traffic between on-premises and Azure; traffic between spokes requires a separate classic hub-spoke topology.
D) The "Succeeded" status of the NVA refers only to infrastructure provisioning, not data plane activation; the resource needs to be manually restarted.
Question 3 — True or False
When a third-party NVA is integrated with a Virtual WAN hub through Routing Intent, the hub automatically advertises /0 prefix routes to all connections (branches, VNets, and ExpressRoute) as next-hop pointing to the NVA, without need for additional BGP or route table configuration on the NVA itself.
Is the above statement true or false?
Question 4 — Technical Scenario
A company uses a Virtual WAN hub with an integrated third-party NVA for branch connectivity via SD-WAN. The network team needs to scale the NVA capacity to support higher throughput. The architect proposes increasing the number of NVA instances within the hub.
Current NVA: 2 scale units
Requirement: support up to 3 Gbps aggregate throughput
Manufacturer recommends: 4 scale units for this load
When increasing the NVA scale units in the hub, what behavior should the engineer expect regarding routing and availability?
A) Each additional scale unit creates an independent instance with a dedicated public IP; load balancing must be manually configured via Traffic Manager.
B) Virtual WAN automatically manages load balancing between NVA instances, as scale units are abstracted as a single logical resource within the hub.
C) Increasing scale units requires recreating the NVA resource in the hub from scratch, causing total connectivity interruption during the operation.
D) Additional scale units only function as standby instances; traffic is only redistributed if the primary instance fails, without aggregate throughput gain.
Question 5 — Multiple Choice
An architect needs to choose between two approaches to inspect traffic in a Virtual WAN environment:
| Approach | Description |
|---|---|
| A | Deploy the third-party NVA directly within the Virtual WAN hub using native integration |
| B | Deploy the third-party NVA in a dedicated spoke VNet and use UDRs to redirect traffic |
The main requirement is that branches connected via Site-to-Site VPN in the hub have their traffic inspected by the NVA before reaching spoke VNets, with the least possible routing operational overhead.
Which approach best meets the requirement and why?
A) Approach B, because UDRs offer granular control per prefix, avoiding dependency on Microsoft-managed resources.
B) Approach A, because the NVA integrated with the hub with Routing Intent natively intercepts traffic between branches and spokes without requiring manual UDR maintenance.
C) Approach B, because NVAs integrated with the hub do not support inspection of traffic originating from Site-to-Site VPN connections, only from VNet peerings.
D) Approach A, but only if the NVA is also registered as a BGP peer with the hub using a private ASN below 65000.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
For an NVA to be deployed as a managed resource within a Virtual WAN hub, it needs to be an offering published in Azure Marketplace and certified by Microsoft's integration partner program. This process ensures that the NVA exposes the APIs and management model required by Virtual WAN for provisioning, scaling, and integrated routing.
The main misconception represented by the distractors is confusing native hub integration with alternative valid but distinct topologies: deploying the NVA in a spoke VNet with UDRs (Alternative A) is a legitimate approach, but does not constitute hub integration. The exclusive dependency on BGP over IPsec (Alternative D) is a branch connectivity requirement, not an NVA eligibility requirement for hub integration.
Choosing Alternative A would result in a functional topology, but without the centralized management and Routing Intent benefits available in native integration.
Answer Key — Question 2
Answer: B
Routing Intent instructs the hub to program routes that point to the NVA as next-hop in managed connections. However, if spoke VNets have custom route tables with static routes or associations to route tables that don't respect routes propagated by the hub, these local routes take precedence and traffic is not diverted to the NVA.
Alternative A is incorrect because NVAs integrated with the hub with Routing Intent are capable of intercepting east-west traffic, not just north-south. This is a limitation that existed in classic topologies without Routing Intent. Alternative C describes behavior that doesn't correspond to the current Virtual WAN architecture. Alternative D is a plausible distractor, but "Succeeded" status in the control plane implies that the data plane is operational; the described problem is routing conflict, not resource initialization.
Answer Key — Question 3
Answer: False
The statement contains an important inaccuracy: while Routing Intent indeed simplifies routing by automatically programming hub connections to use the NVA as next-hop, this does not eliminate all need for configuration on the NVA. The NVA still needs to be correctly configured to process and forward traffic in the data plane. Additionally, the behavior of advertising /0 routes occurs for internet traffic (internet traffic policy), while for private traffic the hub advertises more specific prefixes, not necessarily a single default route aggregated for all scenarios.
The critical point is that Routing Intent acts on the hub's control plane, but responsibility for the data plane and functional configuration of the NVA remains with the operator. Assuming that integration is completely passive on the NVA side is a common misconception that leads to silent inspection failures.
Answer Key — Question 4
Answer: B
In the NVA integration model in Virtual WAN hub, scale units are a managed abstraction: Virtual WAN treats the set of instances as a single logical resource and internally manages load balancing between them. The engineer doesn't need to configure external load balancers or manage individual IPs per instance.
Alternative A describes the behavior of unmanaged resources deployed in spokes, not hub-integrated NVAs. Alternative C would be true for some legacy resources, but hub-integrated NVAs support scale unit updates without complete resource recreation. Alternative D describes the active-passive high availability model, which doesn't correspond to scale units behavior, designed for active-active horizontal scaling.
Answer Key — Question 5
Answer: B
Approach A with Routing Intent best meets the requirement because the Virtual WAN hub automatically programs Site-to-Site VPN connections to use the integrated NVA as next-hop. This eliminates the need to create and maintain UDRs manually for each new branch or added prefix, directly reducing operational overhead.
Approach B (Alternative A) is technically viable, but requires continuous UDR maintenance whenever new branches or prefixes are added, which contradicts the requirement for lower operational overhead. Alternative C is incorrect: NVAs integrated with the hub with Routing Intent inspect traffic originating from both VPN connections and VNet peerings. Alternative D is a distractor that correctly mixes the need for BGP in some connectivity scenarios with an ASN requirement that doesn't exist as a restriction for hub integration.