Skip to main content

Technical Lab: Create a secure hub by deploying Azure Firewall inside an Azure Virtual WAN hub

Questions​

Question 1 — Multiple Choice​

When converting a standard Azure Virtual WAN hub to a secured virtual hub, which component is automatically deployed inside the hub and starts managing traffic between connections?

A) A third-party Network Virtual Appliance (NVA) registered in the hub
B) Azure Firewall, provisioned directly in the hub's address space
C) An Azure Application Gateway with WAF enabled in the hub subnet
D) A dedicated Route Server that inspects packets before forwarding them

Question 2 — Technical Scenario​

A team configured a secured virtual hub with Azure Firewall and defined routing policies in Azure Firewall Manager. After configuration, traffic between two spoke VNets connected to the same hub continues to be routed directly between them, without passing through the firewall.

Spoke-A (10.1.0.0/16) <--> Hub (10.0.0.0/23) <--> Spoke-B (10.2.0.0/16)
Observed traffic: Spoke-A -> Spoke-B (direct, without inspection)

What is the most likely cause of this behavior?

A) Azure Firewall doesn't support east-west traffic inspection between spoke VNets in Virtual WAN
B) The Private Traffic option in the hub's routing settings wasn't enabled to send inter-spoke traffic through the firewall
C) The spoke VNets are using direct peering between them, bypassing the hub
D) The Firewall Policy associated with the hub is in Alert mode and not in Deny mode, allowing traffic to pass without redirection

Question 3 — True or False​

A secured virtual hub in Azure Virtual WAN with Azure Firewall allows the administrator to freely choose the IP address prefix assigned to the hub after its creation, simply by editing the hub's network settings in the portal.

Question 4 — Technical Scenario​

A company has two secured virtual hubs in different regions (East-Hub and West-Hub), both connected through a Standard type virtual WAN. The security team requires that traffic between the two regions is also inspected by the firewall. After reviewing the configuration, the architect realizes that inter-hub traffic is being routed directly, without inspection.

What adjustment resolves this scenario?

A) Create a global VNet peering between the hubs to force traffic through the firewall
B) Enable the Inter-hub traffic inspection option within the Azure Firewall Manager routing settings for each hub
C) Replace the standard hubs with hubs using third-party NVAs, since Azure Firewall doesn't support traffic inspection between hubs
D) Add static routes in the hub route tables pointing to the private IP of the remote hub's firewall

Question 5 — Multiple Choice​

When deploying Azure Firewall in a secured virtual hub, which tool is Microsoft's recommended approach for centrally managing security policies applied to multiple hubs?

A) Azure Policy with compliance initiatives applied to the virtual WAN scope
B) Azure Firewall Manager, which allows associating a hierarchical Firewall Policy to the hubs
C) Microsoft Defender for Cloud with Defender for Servers plans enabled on the hubs
D) Network Security Groups (NSGs) applied to the firewall interfaces within the hub

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

When enabling security on a Virtual WAN hub, Azure provisions Azure Firewall directly within the hub's own address space, transforming it into a secured virtual hub. This is distinct from a standard hub, where no native security appliance is automatically deployed.

  • Alternative A is plausible because third-party NVAs can be integrated with Virtual WAN, but this process isn't automatic nor does it configure the hub as "secured" in the formal product sense.
  • Alternatives C and D describe components that aren't part of the secured virtual hub architecture: Application Gateway operates at layer 7 for specific web workloads, and Route Server is a separate service for BGP route exchange.

Choosing C or D would lead to an architecture without centralized traffic inspection in the hub, which is exactly the objective of a secured virtual hub.

Answer Key — Question 2​

Answer: B

In Azure Firewall Manager, private traffic routing (east-west between spokes and branch-to-branch) is controlled by the Private Traffic configuration within the hub's Security Configuration options. If this option isn't enabled to route traffic through Azure Firewall, the routes automatically generated by the hub will continue directing traffic directly between spokes.

  • Alternative A is incorrect: Azure Firewall in secured virtual hub explicitly supports east-west inspection between spokes.
  • Alternative C is a common misconception, but spoke VNets connected to Virtual WAN don't establish direct peering between themselves by default; the hub is always the transit point.
  • Alternative D confuses firewall policy behavior (Allow/Deny rules) with routing configuration. Even in Alert mode, routes would need to be directing traffic to the firewall, which doesn't occur if private routing isn't configured.

Answer Key — Question 3​

Answer: False

The address space of an Azure Virtual WAN hub is immutable after creation. The prefix must be defined at the time of hub provisioning and cannot be edited later. This is a fundamental restriction of the Virtual WAN architecture, regardless of whether the hub is standard or secured.

This limitation has direct consequences for planning: an error in prefix sizing requires deleting and recreating the hub, which means reconfiguring all associated connections. The behavior differs from regular VNets, where it's possible to add address spaces after creation, which leads to this misconception.

Answer Key — Question 4​

Answer: B

Azure Firewall Manager offers a specific inspection option for inter-hub traffic (between regions, via Standard virtual WAN). This configuration must be explicitly enabled in each hub so that traffic transiting between hubs is redirected to the local firewall before proceeding to the remote hub.

  • Alternative A is incorrect because global peering between hubs isn't a Virtual WAN functionality; hubs communicate through the WAN backbone, not through VNet peerings.
  • Alternative C is a plausible distractor, but technically incorrect: Azure Firewall supports the inter-hub scenario in Standard WANs.
  • Alternative D could work in a traditional VNet scenario with manual route tables, but in Virtual WAN, inter-hub route management is done by Firewall Manager, and static routes pointing to private IPs of remote hubs aren't a supported mechanism for this purpose.

Answer Key — Question 5​

Answer: B

Azure Firewall Manager is the native tool designed specifically for centralized security management in secured virtual hubs. It allows creating and associating Firewall Policies with hierarchy (base policy and child policies), applying configurations to multiple hubs simultaneously, and viewing the WAN's security state in a consolidated manner.

  • Alternative A confuses Azure Policy (resource governance and compliance in Azure) with operational management of firewall rules.
  • Alternative C describes a security posture and workload protection tool, without the capability to manage network traffic rules in the firewall.
  • Alternative D is technically incorrect for the secured virtual hub context: Azure Firewall within the hub doesn't expose network interfaces accessible to NSGs, as it operates integrated with the hub's routing plane, not as a VM with conventional NICs.