Technical Lab: Deploy a gateway into a virtual hub
Questions
Question 1 — Multiple Choice
When provisioning a VPN gateway in an Azure Virtual WAN virtual hub, an architect needs to decide on the appropriate scale unit. The environment requires support for 2 Gbps aggregation of site-to-site VPN throughput.
What is the direct implication of choosing a scale unit lower than necessary for this requirement?
A) The gateway will be provisioned, but will block new branch connections until the scale is increased.
B) The total available throughput will be limited to the ceiling of the selected unit, potentially causing performance degradation during traffic peaks.
C) Azure will reject the gateway deployment and display a validation error before starting provisioning.
D) The gateway will operate normally, but routing between spokes will be automatically disabled.
Question 2 — Technical Scenario
A team is deploying an ExpressRoute gateway in a virtual hub. After deployment, when trying to associate an ExpressRoute circuit to the hub, the portal displays the following message:
The gateway is not in a succeeded state.
Current state: Updating
The team decides to wait and, after 40 minutes, the state still hasn't changed to Succeeded.
What is the most likely cause and the correct action?
A) The ExpressRoute circuit is in a different region from the hub; it's necessary to recreate the circuit in the same region.
B) The gateway is still being provisioned; gateways in virtual hubs can take up to 60 minutes and the team should continue waiting.
C) The Updating state indicates silent failure; it's necessary to delete the gateway and redeploy it immediately.
D) The circuit association should be done before the gateway completes provisioning to avoid state conflict.
Question 3 — True or False
A virtual hub can simultaneously have a site-to-site VPN gateway, a point-to-site VPN gateway and an ExpressRoute gateway active at the same time, and all can coexist in the same hub without combination restrictions.
Question 4 — Technical Scenario
An organization has a Basic type Virtual WAN. The network team tries to deploy an ExpressRoute gateway in the virtual hub associated with this WAN, but the option doesn't appear in the portal and the CLI operation returns an error.
az network vhub update \
--name myhub \
--resource-group myrg \
--express-route-gateway-scale-unit 1
ERROR: ExpressRoute gateway is not supported for Virtual WAN SKU: Basic
What is the root cause of the problem and the correct solution?
A) The hub needs to be recreated in a region that supports ExpressRoute; the current region is incompatible.
B) The Basic type Virtual WAN doesn't support ExpressRoute gateways; it's necessary to upgrade to the Standard type.
C) Scale unit 1 is invalid for ExpressRoute; increasing to scale unit 2 resolves the error.
D) The ExpressRoute gateway requires that a site-to-site VPN gateway is already provisioned in the same hub before being created.
Question 5 — Multiple Choice
In a Virtual WAN environment with multiple hubs, an administrator needs to ensure that traffic from branches connected via site-to-site VPN in one hub can reach workloads in spokes connected to a different hub in the same Virtual WAN.
Which component is essential and already incorporated in the Virtual WAN architecture to enable this inter-hub routing without additional manual peering configuration?
A) A dedicated ExpressRoute gateway provisioned in each hub to function as a transit point between hubs.
B) The Virtual Hub Router, which enables transitive routing between hubs and between connections of different types within the Virtual WAN.
C) An Azure Route Server deployed separately in each hub to propagate routes between gateways.
D) VNet peering between virtual hubs, which must be manually configured in the Virtual WAN control plane.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The scale unit in virtual hub VPN gateways directly defines the maximum aggregate throughput available for all connections managed by that gateway. Each unit corresponds to a specific capacity range (for example, 500 Mbps per unit in many SKUs). Choosing a unit below what's necessary doesn't prevent provisioning or automatically block new connections; the gateway is created successfully but operates within the lower limit, causing saturation and degradation under real load.
Alternative C represents a common misconception: Azure doesn't validate throughput requirements as a business rule during deployment; sizing responsibility lies with the architect. Alternatives A and D describe behaviors that don't exist in the platform.
Answer Key — Question 2
Answer: B
Gateways deployed in virtual hubs have significantly longer provisioning times than gateways in traditional VNets. The Updating state is expected behavior during this process and can last between 30 and 60 minutes. Interrupting or deleting the gateway during this period (alternative C) would worsen the problem, forcing a new equally lengthy provisioning cycle.
Alternative D represents a serious misconception: attempting to associate resources to a gateway in a non-final state doesn't expedite the process and may generate additional errors. Alternative A confuses circuit peering restrictions with gateway provisioning state.
Answer Key — Question 3
True
A single virtual hub supports the coexistence of all three gateway types: site-to-site VPN, point-to-site VPN, and ExpressRoute. This is a fundamental characteristic of Virtual WAN Standard, which allows the hub to function as a convergence point for multiple connectivity types simultaneously. The relevant restriction here is not about gateway combination, but about Virtual WAN type: this coexistence is only valid in hubs associated with Standard type Virtual WANs; the Basic type has limited support. The statement as presented is true, as it doesn't specify WAN type restrictions.
Answer Key — Question 4
Answer: B
The Basic type Virtual WAN only supports site-to-site VPN connectivity and doesn't offer support for ExpressRoute gateways or point-to-site VPN. The correct solution is to upgrade the Virtual WAN to the Standard type, which enables all gateway types and advanced routing features. This upgrade can be done without needing to recreate the hub or lose existing VPN configurations.
Alternatives A and C are plausible distractors because they refer to real platform restrictions (regional incompatibility, minimum scale units), but neither is the cause of the described error. Alternative D describes an order dependency that doesn't exist in the platform.
Answer Key — Question 5
Answer: B
The Virtual Hub Router is the data plane and control component built into each virtual hub that enables transitive routing within the Virtual WAN, including between distinct hubs and between connections of different types (VPN, ExpressRoute, spoke). It eliminates the need to manually configure peering between hub VNets or provision additional routing devices for inter-hub traffic.
Alternative C represents confusion with Azure Route Server, which is a separate service used in independent VNet architectures, not within Virtual WAN. Alternative D describes a classic VNet connectivity model that doesn't apply to virtual hub architecture. Alternative A incorrectly attributes the inter-hub transit function to the ExpressRoute gateway.