Skip to main content

Technical Lab: Create a virtual hub in Virtual WAN

Questions​

Question 1 — Multiple Choice​

When provisioning a virtual hub within an Azure Virtual WAN, an architect needs to define the hub's address space. Which statement correctly describes the expected behavior of this address space?

A) The hub's address space can be freely changed after creation, without impact on existing connections.

B) The hub's address space must be at least a /24 prefix and cannot overlap with the addresses of connected spoke networks.

C) The hub's address space is used exclusively for the hub's internal gateway resources and doesn't need to be routable by spoke networks.

D) The hub's address space is automatically assigned by Azure and cannot be defined by the user at creation time.

Question 2 — Technical Scenario​

A network team created a Standard type Virtual WAN and added a virtual hub in the East US region. After hub creation, the team tries to connect a spoke VNet to the hub, but the option to associate the VNet is unavailable in the portal. The hub was created less than 10 minutes ago.

What is the most likely cause of this behavior?

A) Virtual WAN Standard doesn't support VNet connections directly to the hub; a VPN Gateway within the hub is required.

B) The virtual hub is still in the provisioning state, and VNet connections can only be added after the hub reaches Succeeded state.

C) The spoke VNet is in a different subscription from the Virtual WAN, which requires manual peering configuration before any association.

D) The hub in the East US region requires Routing Intent to be configured before accepting VNet connections.

Question 3 — True or False​

A Basic type virtual hub can be upgraded to Standard type after creation without needing to recreate the hub or existing connections, and this upgrade is irreversible.

Question 4 — Technical Scenario​

A company needs connectivity between branch offices via Site-to-Site VPN and also secure routing between VNets, all managed by the same virtual hub. During planning, the architect evaluates which Virtual WAN SKU to use.

Consider the configuration below:

Virtual WAN
  Type: Basic
  Hub: hub-eastus
    - Site-to-Site VPN Gateway: enabled
    - VNet connections: 3 spoke VNets

What problem does this configuration present regarding the described requirements?

A) The Basic type doesn't support Site-to-Site VPN Gateway; this feature requires the Standard type.

B) The Basic type supports Site-to-Site VPN but doesn't allow spoke VNet connections to the hub, making routing between VNets impossible.

C) The Basic type supports both VPN and VNet connections, but routing between spoke VNets requires the Standard type.

D) The Basic type allows a maximum of 2 VNet connections, making it unfeasible to connect 3 VNets to the same hub.

Question 5 — Multiple Choice​

An engineer needs to deploy a virtual hub with support for ExpressRoute, Site-to-Site VPN, and User VPN (Point-to-Site) in the same region. Which combination of statements correctly describes the gateway restrictions in this scenario?

A) Each gateway type (ExpressRoute, VPN S2S, User VPN) must be deployed in separate hubs; a single hub doesn't support all three simultaneously.

B) A single Standard hub supports all three gateways simultaneously, but each gateway needs to be created independently and has its own provisioning process.

C) The User VPN gateway and Site-to-Site VPN gateway share the same resource instance within the hub, requiring only one of the two to be created.

D) A Standard hub supports all three gateways, but the ExpressRoute Gateway can only be added if the hub was originally created with this option enabled.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

The virtual hub's address space must be a CIDR block of at least /24. This range is reserved by Azure to allocate the hub's internal components, such as gateways and Network Virtual Appliances (NVAs). Additionally, it cannot overlap with the addresses of connected VNets or other hubs within the same Virtual WAN, as this would cause routing conflicts.

The main error represented by the distractors is confusing the hub space with a merely administrative range or something managed completely automatically. In practice, choosing this range incorrectly at creation time has serious consequences: the hub's address space cannot be changed after creation, making it necessary to recreate the hub to correct a planning error.

Answer Key — Question 2​

Answer: B

After creating a virtual hub, Azure executes an internal provisioning process that can take several minutes. While the hub is in the Provisioning state, operations like adding VNet connections, gateways, or routing policies are blocked. Only when the status transitions to Succeeded is the hub ready to receive additional configurations.

The other distractors explore legitimate misconceptions: Virtual WAN Standard does support direct VNet connections (eliminating A); subscription differences may require approval but don't block the portal option this way (eliminating C); and Routing Intent is not a prerequisite for connecting VNets (eliminating D). Acting prematurely on a newly created hub is a frequent operational error in real environments.

Answer Key — Question 3​

Answer: True

Upgrading a Virtual WAN from Basic to Standard type is supported by Microsoft and can be performed without recreating the hub or existing connections. However, this migration is irreversible: once in Standard type, it's not possible to downgrade to Basic. This behavior is relevant from a cost and governance perspective, as the Standard type has a higher data processing cost per hub than Basic.

The non-obvious point here is that irreversibility applies at the Virtual WAN level, not just the hub individually. Upgrading the WAN means all hubs within it also operate under Standard type capabilities and costs.

Answer Key — Question 4​

Answer: C

Virtual WAN Basic type supports Site-to-Site VPN and allows connecting spoke VNets to the hub. What it doesn't support is transitive routing between spoke VNets: packets originating from one spoke VNet are not forwarded by the hub to another spoke VNet in Basic type. This routing behavior between spokes requires Standard type, which enables complete transitive routing within the hub.

Distractors A and D are factually incorrect: Basic supports S2S VPN and doesn't have a fixed limit of 2 VNets. Distractor B incorrectly states that VNets cannot be connected to Basic type. Confusing "connecting VNets to the hub" with "routing between VNets through the hub" is one of the most common planning errors when sizing a Virtual WAN.

Answer Key — Question 5​

Answer: B

A single Standard type virtual hub supports simultaneously an ExpressRoute Gateway, a Site-to-Site VPN Gateway, and a User VPN Gateway (Point-to-Site). Each of these gateways is an independent resource within the hub, with its own provisioning cycle, which can take 20 to 45 minutes each. They coexist in the same hub without conflict.

Distractor C represents an important structural misconception: the User VPN Gateway and VPN S2S Gateway are distinct and separate resources, they don't share an instance. Distractor D is incorrect because the ExpressRoute Gateway can be added to any existing Standard hub, regardless of how it was originally created. Understanding that each gateway has its own provisioning time is critical for planning production deployments.