Technical Lab: Design a Virtual WAN architecture, including selecting types and services
Questions
Question 1 — Multiple Choice
A multinational company needs to connect 30 branches distributed across three continents to a centralized corporate network in Azure. The main requirement is that traffic between branches should be able to flow directly between them without necessarily transiting through the central hub, and the network team doesn't want to manage routing manually between the spokes.
Which type of Virtual WAN meets this requirement?
A) Virtual WAN Basic, as it supports site-to-site connectivity with automatic routing between branches.
B) Virtual WAN Standard, as it enables transit between VNets and branches through managed hub routing.
C) Virtual WAN Basic with additional hubs per region, as inter-hub routing is automatically managed in this tier.
D) Virtual WAN Standard with mandatory User Defined Routes (UDRs) to enable traffic between branches.
Question 2 — Technical Scenario
An architect is designing a Virtual WAN solution for an organization that requires east-west traffic inspection between VNets connected to the same hub. The proposal includes integrating a third-party firewall (NVA) directly into the hub.
Virtual WAN Hub (Standard)
├── VNet Spoke A (production workloads)
├── VNet Spoke B (staging workloads)
└── Third-party NVA (for L7 inspection)
The architect states that any third-party NVA can be deployed directly in the hub to perform this inspection. What is the error in this statement?
A) NVAs cannot be deployed in Virtual WAN Standard hubs; inspection requires migration to Virtual WAN Basic.
B) Only Azure Firewall can be deployed in the hub as Secured Virtual Hub; third-party NVAs must be deployed in separate spoke VNets.
C) East-west inspection in Virtual WAN requires traffic to be manually redirected via UDR to a transit spoke with the NVA.
D) Only NVAs certified by the Virtual WAN partner program can be deployed directly in the hub.
Question 3 — True or False
A Virtual WAN of type Basic can be converted to type Standard without needing to recreate the resource, and this conversion is bidirectional, allowing return to Basic type later if necessary.
Question 4 — Technical Scenario
An organization already has a traditional hub-and-spoke topology in Azure with manual VNet peering and a central VNet hub managed by the network team. The CTO wants to evaluate migration to Virtual WAN Standard. During analysis, the architect identifies that several spoke VNets already have peering configured with the existing hub VNet.
What is the direct implication when connecting these spoke VNets to the Virtual WAN hub?
A) Spoke VNets can maintain peering with the traditional hub VNet simultaneously with connection to the Virtual WAN hub, without routing conflict.
B) The Virtual WAN hub manages peering automatically, but the existing manual peering with the traditional hub VNet must be removed to avoid asymmetric routing.
C) Connecting spoke VNets to Virtual WAN requires them to be recreated, as the service doesn't accept VNets with pre-existing peerings.
D) The Virtual WAN hub and traditional hub VNet can coexist without restrictions, as they operate on independent control planes.
Question 5 — Multiple Choice
When designing a Virtual WAN architecture with multiple hubs in different regions, an architect needs to ensure that traffic from a branch connected via S2S VPN in region A hub reaches a VNet connected to region B hub.
Which statement correctly describes Virtual WAN Standard behavior in this scenario?
A) Inter-hub traffic is not natively supported; it requires configuring global VNet peering between the two region hubs.
B) Traffic is automatically routed between hubs via Microsoft's backbone, without needing additional routing configuration.
C) Inter-hub routing requires creating a Connection between the two hubs through a dedicated transit VNet resource.
D) Inter-hub traffic is only possible if both hubs are in the same Azure subscription and the same Virtual WAN resource group.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Virtual WAN Standard is the only tier that supports complete transitive routing: branch-to-branch, branch-to-VNet, and VNet-to-VNet, including between branches connected to the same hub or different hubs. This routing is automatically managed by the hub's control plane, eliminating the need for manual UDR configuration for basic transitive flows.
Virtual WAN Basic only supports S2S VPN connectivity and does not enable transit between branches. Option A is incorrect for this reason. Option C is false because automatic inter-hub routing is exclusive to the Standard tier. Option D introduces a non-existent restriction: UDRs are not mandatory for default transit in Virtual WAN Standard.
Answer Key — Question 2
Answer: D
Virtual WAN supports deploying third-party NVAs directly in the hub, but only for partners certified by Microsoft's NVA in-hub integration program (such as Barracuda, Check Point, Fortinet, and others listed in the portal). This model is distinct from Secured Virtual Hub, which uses Azure Firewall and Azure Firewall Manager.
Option B represents the most common misconception: confusing the concept of Secured Virtual Hub (which uses Azure Firewall) with the totality of inspection options in the hub. Certified third-party NVAs can, in fact, be deployed in the hub. Option A is incorrect because NVAs and firewalls are supported in Standard, not Basic. Option C describes a valid topology for non-certified NVAs, but doesn't represent the error in the original statement.
Answer Key — Question 3
Answer: False
Converting Virtual WAN Basic to Standard is supported and can be performed without recreating the resource. However, the operation is unidirectional: once converted to Standard, the Virtual WAN cannot be reverted to Basic. This behavior is relevant in design because it implies a permanent decision regarding tier, with impact on costs and enabled capabilities.
The main risk of ignoring this characteristic is starting with Standard in test environments and assuming it's possible to reduce the tier later for cost control, which is not feasible.
Answer Key — Question 4
Answer: B
When a spoke VNet is connected to a Virtual WAN hub, the service automatically creates a managed peering between the VNet and the hub. If this same VNet already has peering with a traditional hub VNet, the two peerings will coexist at the technical level, but routing will become asymmetric or ambiguous, as the VNet will have two exit paths to the rest of the topology.
The correct solution is to remove the manual peering with the traditional hub VNet before or shortly after connecting the VNet to Virtual WAN. Option A ignores the resulting routing conflict. Option C is incorrect because VNets with existing peerings can be connected to Virtual WAN without recreation. Option D is false because, although the control planes are distinct, the data plane shares the VNet's effective routing table, generating real conflict.
Answer Key — Question 5
Answer: B
In Virtual WAN Standard, connectivity between hubs in different regions is native and automatic. Microsoft maintains a global backbone between hubs of the same Virtual WAN resource, and the control plane propagates routes between them without the architect needing to configure global peering, transit VNets, or additional resources.
Option A describes the behavior of a traditional hub-and-spoke topology, not Virtual WAN. Option C represents a workaround solution used in legacy architectures. Option D introduces a subscription and resource group restriction that doesn't exist in the product: hubs from different subscriptions can compose the same Virtual WAN and communicate between regions.