This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure storage, databases, and networking (25–30%)
   --> Implement security for Azure network services
      --> Configure security for an Azure Virtual WAN

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Virtual WAN is a Microsoft-managed networking service that provides centralized connectivity between Azure virtual networks, branch offices, remote users, and other connected environments. It combines networking, routing, VPN, ExpressRoute, and security capabilities through a unified operational model.

For the SC-500 exam, the important security concept is that Azure Virtual WAN should not be viewed only as a connectivity service. It can also provide a centralized inspection and enforcement point for traffic flowing between:

• Azure virtual networks
• On-premises branch offices
• Remote users
• Other Virtual WAN hubs
• The internet
• Azure platform services and private resources

A common secure design is to use a secured virtual hub, Azure Firewall, Firewall Manager, and Virtual WAN routing capabilities to ensure that traffic is inspected before reaching protected destinations.

What Is Azure Virtual WAN?

Azure Virtual WAN consists of several major components:

Virtual WAN resource

The Virtual WAN resource is the top-level container for one or more virtual hubs. It provides a centralized management and configuration boundary.

Virtual hub

A virtual hub is a Microsoft-managed network infrastructure component deployed in an Azure region. It provides connectivity and routing services for connected networks and gateways.

A virtual hub can contain or provide access to:

• Site-to-site VPN gateways
• Point-to-site user VPN gateways
• ExpressRoute gateways
• The Virtual WAN hub router
• Azure Firewall
• Supported network virtual appliances
• Connections to Azure virtual networks
• Connections to branch sites

Unlike a customer-managed hub VNet, a Virtual WAN hub is operated by Microsoft. You do not directly deploy or manage the underlying hub virtual network in the same way that you manage a normal Azure VNet.

Virtual network connections

Azure VNets connect to a Virtual WAN hub through virtual network connections. These connections allow workloads in the VNets to communicate with other connected networks according to the hub’s routing configuration.

VPN and ExpressRoute connections

Branch offices and on-premises networks can connect to Virtual WAN through:

• Site-to-site VPN
• ExpressRoute
• Point-to-site user VPN

The connection type depends on the organization’s requirements for connectivity, performance, availability, and authentication.

Basic and Standard Virtual WAN

Azure Virtual WAN is available in two primary types:

For most enterprise security scenarios, Standard Virtual WAN is required because secured hubs, Azure Firewall, advanced transit, and additional gateway capabilities depend on Standard functionality.

A Basic Virtual WAN can be upgraded to Standard, but it cannot be downgraded from Standard back to Basic.

What Is a Secured Virtual Hub?

A secured virtual hub is an Azure Virtual WAN hub with an integrated Azure Firewall.

Azure Firewall provides centralized traffic inspection and policy enforcement for traffic moving through the Virtual WAN environment. A secured hub can inspect traffic destined for:

• Private IP addresses
• Azure virtual networks
• Other connected networks
• The internet
• Azure platform services, depending on the routing and security design

Azure Firewall can inspect traffic between different network locations, including:

• North-south traffic: traffic between on-premises networks and Azure
• East-west traffic: traffic between Azure networks or workloads
• Internet-bound traffic: traffic from Azure workloads to the internet

This approach centralizes security enforcement rather than requiring every workload or spoke network to independently deploy a firewall.

Why use a secured virtual hub?

A secured virtual hub can provide:

• Centralized traffic inspection
• Consistent firewall policies
• Reduced need for manually configured routes
• Centralized security management across multiple hubs
• Protection for Azure and branch connectivity
• A more consistent Zero Trust architecture
• Easier enforcement of organization-wide security requirements

For example, an organization might connect several regional VNets and branch offices to Virtual WAN. Instead of deploying and maintaining separate firewalls in every location, the organization can use Azure Firewall in secured hubs and apply consistent policies.

Azure Firewall Manager

Azure Firewall Manager provides centralized management for firewall policies and secured virtual hubs.

It can be used to:

• Create secured virtual hubs
• Manage Azure Firewall policies
• Apply consistent security rules across multiple hubs
• Configure routing-related security settings
• Manage security for multiple regions
• Separate centralized security administration from individual workload administration

Firewall Manager is particularly useful when an organization has multiple Virtual WAN hubs in different Azure regions.

For example:

• A global company has hubs in North America, Europe, and Asia.
• Each hub connects regional VNets and branch offices.
• Security administrators manage common firewall policies centrally.
• Regional teams manage their workloads without independently designing the entire network security architecture.

Firewall Manager supports centralized rule management across secured hubs.

Routing Intent

One of the most important security features in Azure Virtual WAN is routing intent.

Routing intent allows you to define how traffic should be routed through a security solution, such as Azure Firewall or a supported network virtual appliance.

Common routing intent patterns include:

Internet traffic inspection

Internet-bound traffic from connected VNets or branches is routed through the security solution before reaching the internet.

This helps enforce policies such as:

• Blocking malicious destinations
• Restricting outbound access
• Inspecting internet-bound traffic
• Applying centralized filtering
• Logging traffic for investigation

Private traffic inspection

Private traffic between connected networks is routed through the security solution.

For example:

• VNet A communicates with VNet B.
• A branch office communicates with an Azure workload.
• One regional hub communicates with another regional hub.

Routing intent can be used to steer this private traffic through the firewall for inspection.

Why routing intent matters

Without centralized routing, administrators may need to create and maintain multiple user-defined routes. Incorrect or incomplete routes can allow traffic to bypass inspection.

Routing intent helps simplify this process by automatically steering specified traffic categories through the security solution. The Virtual WAN architecture is designed to reduce the need for manually maintained routing configurations.

Traffic Flow Through a Secured Virtual Hub

A simplified secure traffic flow might look like this:

Branch Office
     |
     | Site-to-site VPN or ExpressRoute
     |
Virtual WAN Hub
     |
Azure Firewall
     |
     +--------------------+
     |                    |
Private Azure VNet     Internet

For traffic between two Azure VNets:

VNet A
  |
  | Virtual WAN connection
  |
Virtual WAN Hub
  |
Azure Firewall
  |
Virtual WAN Hub
  |
  | Virtual WAN connection
  |
VNet B

The exact traffic path depends on the hub configuration, routing intent, firewall policy, connection settings, and whether the traffic is classified as private or internet-bound.

The important exam concept is:

A connection to Virtual WAN does not automatically mean that all traffic is inspected by Azure Firewall. The routing and security configuration must direct the traffic through the security solution.

Azure Firewall Policy in a Secured Virtual Hub

Azure Firewall policies define the traffic that is allowed, denied, or inspected.

Depending on the Azure Firewall tier and configuration, policies can include:

• Network rules
• Application rules
• NAT rules
• Threat intelligence filtering
• DNS-related security controls
• TLS inspection capabilities, where supported and configured
• IDPS capabilities with Azure Firewall Premium

Network rules

Network rules control traffic based on characteristics such as:

• Source address
• Destination address
• Protocol
• Destination port

Examples include:

• Allow TCP 443 from a corporate network to an application subnet
• Deny TCP 22 from untrusted networks
• Allow DNS traffic to an approved DNS service
• Block traffic to a known prohibited network range

Application rules

Application rules can control supported application-layer traffic, such as HTTP and HTTPS, based on:

• Fully qualified domain names
• Web categories
• Application characteristics

For example, an organization might allow servers to access only approved software repositories.

NAT rules

NAT rules can publish selected internal services through a public IP address. NAT should be configured carefully because it can expose internal resources to external traffic.

Security considerations include:

• Restricting source addresses
• Limiting exposed ports
• Avoiding unnecessary public exposure
• Applying least privilege
• Monitoring inbound connections
• Using private connectivity whenever possible

Virtual WAN Network Virtual Appliances

Azure Virtual WAN can also support supported network virtual appliances, depending on the Virtual WAN type and deployment architecture.

A network virtual appliance might provide specialized capabilities such as:

• Third-party firewall functionality
• Intrusion prevention
• Secure web gateway features
• Specialized network inspection
• Vendor-specific security controls

However, an NVA is not automatically equivalent to Azure Firewall. Before selecting an NVA, verify:

• Supported Virtual WAN integration
• Routing behavior
• High availability
• Scaling model
• Inspection capabilities
• Logging and monitoring
• TLS inspection support
• Compatibility with required traffic patterns
• Whether the appliance supports the organization’s security requirements

Microsoft documentation specifically notes that NVAs deployed in a Virtual WAN hub can have different capabilities from Azure Firewall.

Virtual WAN Hub Address Space

When creating a Virtual WAN hub, you must specify a hub address space.

Important considerations include:

• The minimum hub address space is /24.
• Microsoft recommends using /23 or larger when future growth is expected.
• If Azure Firewall is used in the Virtual WAN hub, a minimum /22 address space is required to provide sufficient IP address capacity for firewall scaling.
• The hub address space cannot be changed after the hub is created.
• The hub address space must not overlap with connected VNets, on-premises networks, or other Virtual WAN hub address spaces.

The address space is used internally by the hub and its services, including the hub router, VPN gateways, ExpressRoute, Azure Firewall, and supported NVAs.

Exam warning

Do not select a hub address range that overlaps with:

• An on-premises network
• A connected VNet
• Another Virtual WAN hub
• A future planned network

Address-space overlap can cause routing conflicts and connectivity failures.

Virtual WAN Connectivity Security

Site-to-site VPN

Site-to-site VPN provides encrypted connectivity between an on-premises VPN device and a Virtual WAN hub.

The on-premises device generally requires:

• An externally reachable public IP address
• IPsec/IKE compatibility
• Correct VPN configuration
• Matching authentication and encryption settings
• Appropriate routing configuration

Virtual WAN supports IPsec/IKE VPN connectivity, including IKEv1 and IKEv2 scenarios.

Security best practices include:

• Use strong pre-shared keys or supported authentication methods.
• Store sensitive VPN secrets securely.
• Rotate credentials according to organizational policy.
• Avoid exposing management interfaces on the public internet.
• Monitor VPN connection status and gateway logs.
• Use redundant connections for critical sites.
• Validate learned and advertised routes.

Point-to-site user VPN

Point-to-site VPN allows individual users to connect to a Virtual WAN hub.

Authentication can be integrated with Microsoft Entra ID. This enables centralized identity-based access and can support organizational authentication requirements.

Security controls may include:

• Microsoft Entra authentication
• Multifactor authentication
• Conditional Access
• Group-based authorization
• Device compliance requirements
• Restricted user access
• Short-lived or controlled access
• Monitoring of user VPN activity

The key distinction is that site-to-site VPN connects networks, while point-to-site VPN connects individual users or devices.

ExpressRoute

ExpressRoute provides private connectivity between on-premises infrastructure and Azure.

ExpressRoute traffic does not traverse the public internet in the same way as ordinary internet-based connectivity. Virtual WAN can provide transit connectivity and routing between connected networks.

Security considerations include:

• Controlling which routes are advertised
• Avoiding unintended transit
• Applying private traffic inspection where required
• Monitoring route propagation
• Using encryption requirements appropriate to the organization
• Understanding that private connectivity does not automatically eliminate the need for authorization and inspection

Route Tables and Route Propagation

Virtual WAN uses hub routing and route tables to determine how traffic is forwarded between connected networks.

A route table can define:

• Which routes a connection learns
• Which routes are propagated to a connection
• Which networks can communicate
• Whether a connection receives default routes
• Whether traffic is directed toward a firewall or NVA

Route association

A connection is associated with a Virtual WAN route table. The association determines which route table is used for forwarding decisions.

Route propagation

Route propagation determines which routes are advertised to a connection.

For example, a connection might receive routes for:

• Other VNets
• Branch networks
• Other Virtual WAN hubs
• The internet default route
• Specific private address ranges

Security importance

Route propagation can affect whether traffic:

• Reaches a protected network
• Can communicate with another spoke
• Is routed through a firewall
• Can access the internet
• Can bypass an inspection point

A secure configuration should advertise only the routes that are necessary.

Internet Security and the Default Route

The default route is:

0.0.0.0/0

When internet security is enabled and routing is configured to send internet traffic through a firewall or NVA, the default route can be advertised to connected VNets.

This causes internet-bound traffic from those VNets to use the centralized security solution.

However, administrators must understand the operational impact:

• Internet access may be blocked unless firewall rules allow it.
• DNS resolution may be affected by routing and firewall policies.
• Application dependencies may fail if required endpoints are not allowed.
• The firewall must be configured to permit legitimate outbound traffic.
• Route propagation must be validated after changes.

The security objective is to prevent workloads from bypassing the organization’s inspection and filtering controls.

Private Traffic Inspection

Private traffic inspection is used when traffic between private networks must pass through a security solution.

Examples include:

• VNet-to-VNet communication
• Branch-to-VNet communication
• Hub-to-hub communication
• Traffic between application tiers
• Traffic between production and shared services

Private traffic inspection is especially important in Zero Trust architectures because private IP addressing alone does not prove that traffic is trustworthy.

A workload in one VNet should not automatically be trusted merely because it is connected to the same Virtual WAN environment.

Security policies should consider:

• Source network
• Destination network
• Application role
• Protocol
• Port
• Identity and workload context
• Required business relationship
• Logging and monitoring requirements

Branch-to-Branch and Hub-to-Hub Connectivity

Virtual WAN can provide transit connectivity between connected branch sites and hubs.

This can simplify global network architecture, but it also creates security considerations.

For example, if branch-to-branch traffic is enabled, one branch may be able to communicate with another branch through Virtual WAN. This may be useful, but it could also create an unintended trust relationship.

Before enabling branch-to-branch connectivity, determine:

• Which branches should communicate
• Whether branch traffic must be inspected
• Whether segmentation is required
• Whether the firewall can inspect the traffic
• Whether route propagation exposes unnecessary networks
• Whether the connectivity requirement is temporary or permanent

The principle is:

Enable only the transit connectivity that is required by the business and security architecture.

Azure Virtual WAN and Zero Trust

A Zero Trust design assumes that no network location is inherently trusted.

For Virtual WAN, this means:

• Do not trust traffic solely because it originates from a connected VNet.
• Do not assume private traffic is safe.
• Inspect traffic where required.
• Use least-privilege routing.
• Restrict internet access.
• Authenticate remote users.
• Apply consistent firewall policies.
• Monitor traffic and configuration changes.
• Segment workloads and branches.
• Avoid unnecessary route propagation.

A secured Virtual WAN hub can support Zero Trust by centralizing inspection and reducing opportunities for traffic to bypass security controls.

Logging and Monitoring

Virtual WAN and related resources can produce resource logs that can be sent to:

• Log Analytics workspaces
• Event Hubs
• Storage accounts

Logging can support:

• Security investigations
• VPN troubleshooting
• Route analysis
• Firewall monitoring
• Compliance evidence
• Detection of configuration changes
• Investigation of unexpected connectivity

Resource logs are not necessarily enabled automatically. The organization must configure diagnostic settings and select the appropriate destination.

A recommended design is to send security-relevant logs to a centralized Log Analytics workspace and integrate them with Microsoft Sentinel when broader security analytics and incident response are required.

Monitor these areas

Monitor:

• Virtual hub health
• Hub router status
• VPN connection state
• ExpressRoute connectivity
• Learned routes
• Advertised routes
• Firewall health
• Firewall rule hits
• Denied connections
• Unexpected internet access
• Configuration changes
• Resource deployment failures

Hub Router Status

A Virtual WAN hub router can have statuses such as:

• Provisioned
• Provisioning
• Failed
• None

A Failed status may indicate a problem during router instantiation.

A None status may occur when the router was not provisioned, including scenarios involving Basic Virtual WAN or older hub deployments.

The hub router is important because it provides the routing infrastructure for transit connectivity. If the router is not functioning correctly, connected networks may experience routing or connectivity problems.

Security Best Practices

1. Use Standard Virtual WAN for enterprise security scenarios

Standard Virtual WAN supports the capabilities generally required for secured hubs, advanced transit, ExpressRoute, point-to-site VPN, Azure Firewall, and supported NVAs.

2. Use secured virtual hubs for centralized inspection

Deploy Azure Firewall in the Virtual WAN hub when traffic from multiple networks must be inspected consistently.

3. Use Firewall Manager for centralized policy management

Use centralized firewall policies to reduce inconsistent regional configurations.

4. Configure routing intent deliberately

Ensure private and internet-bound traffic is routed through the appropriate security solution.

5. Avoid overlapping address spaces

Plan hub, VNet, branch, and on-premises address spaces before deployment.

6. Use least-privilege route propagation

Advertise only the routes that each connection needs.

7. Do not assume connected networks are trusted

Apply inspection and access controls based on the required communication paths.

8. Protect VPN credentials

Store VPN secrets securely and rotate them according to policy.

9. Monitor logs centrally

Enable diagnostic settings and send relevant logs to a centralized monitoring destination.

10. Validate changes before production deployment

Test:

• Route propagation
• Firewall inspection
• VPN connectivity
• Internet access
• Private network access
• DNS resolution
• Failover behavior
• Logging and alerting

Common Exam Traps

Trap 1: “A VNet connected to Virtual WAN automatically uses Azure Firewall.”

Not necessarily. Traffic must be routed through the firewall using the appropriate security and routing configuration.

Trap 2: “Basic Virtual WAN supports Azure Firewall.”

Basic Virtual WAN does not support Azure Firewall. Standard Virtual WAN is required.

Trap 3: “A private connection is automatically secure.”

Private connectivity reduces exposure to the public internet, but it does not replace authorization, segmentation, inspection, or monitoring.

Trap 4: “Routing intent is only for internet traffic.”

Routing intent can be used for internet-bound traffic and private traffic inspection.

Trap 5: “The Virtual WAN hub address space can be changed later.”

The hub address space cannot be modified after the hub is created.

Trap 6: “An NVA and Azure Firewall always have identical capabilities.”

They do not. Validate the NVA’s supported features and Virtual WAN integration.

Trap 7: “Enabling branch-to-branch connectivity is always desirable.”

It can create additional trust paths and should be enabled only when required.

Practice Exam Questions

Question 1

An organization has several Azure VNets and branch offices connected through Azure Virtual WAN. The security team requires all internet-bound traffic from the VNets to pass through a centralized Azure Firewall.

What should the organization configure?

A. A network security group on every subnet
B. Routing intent that directs internet traffic through Azure Firewall
C. A point-to-site VPN connection for every workload
D. A separate public IP address for every VNet

Correct answer: B

Explanation: Routing intent can direct internet-bound traffic through Azure Firewall in a secured virtual hub. NSGs do not provide centralized internet traffic inspection across Virtual WAN.

Question 2

Which Virtual WAN type is required for an architecture that uses Azure Firewall, ExpressRoute, and inter-hub transit?

A. Basic Virtual WAN
B. Standard Virtual WAN
C. Basic virtual hub with a route table
D. Any Virtual WAN type

Correct answer: B

Explanation: Standard Virtual WAN supports Azure Firewall, ExpressRoute, inter-hub transit, point-to-site VPN, and other advanced capabilities. Basic Virtual WAN is limited primarily to site-to-site VPN connectivity.

Question 3

A company wants to centrally manage Azure Firewall policies across secured Virtual WAN hubs deployed in multiple regions.

Which service should it use?

A. Azure Network Watcher
B. Azure Bastion
C. Azure Firewall Manager
D. Azure DNS Private Resolver

Correct answer: C

Explanation: Azure Firewall Manager provides centralized management of firewall policies and secured virtual hubs across regions.

Question 4

An administrator is creating a Virtual WAN hub that will use Azure Firewall. Which address-space decision is appropriate?

A. Use an address space that overlaps with the largest connected VNet
B. Use a minimum /30 address space
C. Use a minimum /22 address space for a hub with Azure Firewall
D. Use the same address space as the on-premises network

Correct answer: C

Explanation: A Virtual WAN hub using Azure Firewall requires a minimum /22 address space to provide sufficient capacity for firewall scaling. The address space must also avoid overlap with connected networks.

Question 5

An organization wants to inspect traffic between two Azure VNets connected to the same Virtual WAN environment.

Which capability is most relevant?

A. Private traffic inspection through routing intent
B. Azure Storage firewall rules
C. Point-to-site VPN authentication
D. Azure Resource Locks

Correct answer: A

Explanation: Private traffic inspection allows traffic between connected private networks to be directed through a firewall or supported NVA.

Question 6

A security engineer enables branch-to-branch connectivity in Virtual WAN. What is the primary security concern?

A. Branches will no longer be able to use VPN
B. Branch-to-branch connectivity may create unintended trust paths
C. Azure Firewall will be automatically deleted
D. ExpressRoute will be converted to a public connection

Correct answer: B

Explanation: Branch-to-branch connectivity can allow one branch to communicate with another. It should be enabled only when required and should be evaluated against segmentation and inspection requirements.

Question 7

Which statement about the Virtual WAN hub address space is correct?

A. It can be changed at any time after hub deployment
B. It must overlap with the connected VNets
C. It cannot overlap with connected or on-premises address spaces
D. It is used only for point-to-site VPN clients

Correct answer: C

Explanation: The hub address space cannot be changed after creation and must not overlap with other Virtual WAN hubs, connected VNets, or on-premises networks.

Question 8

A company wants to connect individual employees to a Virtual WAN hub and authenticate them using Microsoft Entra ID.

Which connectivity option should it use?

A. Site-to-site VPN
B. Point-to-site user VPN
C. ExpressRoute Direct
D. VNet peering

Correct answer: B

Explanation: Point-to-site user VPN connects individual users or devices and can be configured with Microsoft Entra ID authentication.

Question 9

An administrator configures routing intent but users report that internet access is failing from a connected VNet. What should the administrator check first?

A. Whether the firewall policy allows the required outbound traffic
B. Whether every VM has a public IP address
C. Whether the VNet has a storage account
D. Whether Azure Bastion is deployed

Correct answer: A

Explanation: Routing internet traffic through Azure Firewall does not automatically allow it. The firewall policy must permit the required destinations, protocols, and ports.

Question 10

A security team needs to investigate unexpected VPN disconnects and routing changes in Virtual WAN.

What should it configure?

A. Azure Resource Locks only
B. Diagnostic settings that send Virtual WAN resource logs to a monitoring destination
C. A public IP address on every connected subnet
D. A separate Virtual WAN for every VPN connection

Correct answer: B

Explanation: Virtual WAN and related resources can produce resource logs that can be sent to Log Analytics, Event Hubs, or a storage account. These logs support troubleshooting, auditing, and security investigations.

Key Takeaways

For the SC-500 exam, remember these core points:

• Standard Virtual WAN is required for advanced enterprise capabilities.
• A secured virtual hub integrates Azure Firewall with a Virtual WAN hub.
• Azure Firewall Manager centralizes firewall policy management.
• Routing intent directs private or internet-bound traffic through a security solution.
• Connected networks are not automatically trusted.
• Plan Virtual WAN hub address spaces carefully because they cannot be changed after creation.
• Avoid address-space overlap.
• Use least-privilege route propagation.
• Secure site-to-site and point-to-site connectivity.
• Monitor Virtual WAN resource logs, routes, gateways, and firewall activity.
• Validate that traffic actually passes through the intended inspection point.

Go to the SC-500 Exam Prep Hub main page