4 of the 8 questions we have for this objective, shown with the answer and the reasoning.
Design and implement an Azure Virtual WAN architecture
Ashford Analytics has a Standard Virtual WAN hub with four connected virtual networks: vnet-shared (DNS and monitoring), vnet-customer-a, vnet-customer-b, and vnet-customer-c. All connections currently associate with and propagate to the Default route table. Branches connected by site-to-site VPN must continue to reach every virtual network. The company requires that the three customer virtual networks can reach vnet-shared but cannot reach one another, and it does not want to deploy Azure Firewall or an NVA.
Which two actions should you perform? Each correct answer presents part of the solution.
- ACreate a custom route table named RT_Customers; associate the three customer connections with it, have them propagate to the Default route table and to RT_Shared, and select the branch connections as a propagation source for RT_Customers.Associating the customer spokes with their own route table means they learn only routes propagated into that table: the branch prefixes and the shared prefix. Propagating the customer prefixes to Default and RT_Shared keeps them reachable from branches and from vnet-shared.
- BCreate a custom route table named RT_Shared; associate vnet-shared with it, have vnet-shared propagate to RT_Customers and to the Default route table, and select the branch connections as a propagation source for RT_Shared.With vnet-shared propagating into RT_Customers, each customer spoke learns the shared prefix but not the other customers' prefixes, and branch propagation into RT_Shared lets vnet-shared reach the branches. Branches still see everything through Default.
- CAssociate the branch VPN connections with RT_Customers so they inherit the isolation rules.Branch (VPN and ExpressRoute) connections are always associated with the Default route table in Virtual WAN; you control their reachability by what propagates into Default.
- DCreate user-defined routes in each customer virtual network that send the other customers' prefixes to a next hop of None.User-defined routes on spoke subnets can black-hole traffic but are managed per virtual network and bypass the hub routing model; Virtual WAN route tables are the intended mechanism.
- EEnable routing intent with a private traffic policy pointing to the hub router.Routing intent requires Azure Firewall or a supported NVA as the next hop; it cannot point at the hub router and the company excluded firewalls.
Why: Virtual hub routing is built on route tables, associations, and propagations. Each connection is associated with exactly one route table, which determines the routes that connection uses, and it propagates its prefixes to one or more route tables (directly or through labels). Branch connections are always associated with the Default route table, so to give spokes in custom route tables a return path to the branches, the branches must propagate into those custom tables. The design puts the customer spokes in a table that receives only the shared prefix and the branch routes, and puts the shared services spoke in its own table that receives the customer prefixes and branch routes. No firewall is involved, so routing intent does not apply, and per-VNet user-defined routes fight the hub rather than using it.
Design and implement an Azure Virtual WAN architecture
Penrose Capital has a Standard Virtual WAN with a secured hub in North Europe that contains Azure Firewall Premium, 18 connected virtual networks, an ExpressRoute connection, and 9 VPN branches. The security team mandates that all traffic between any two spokes, between spokes and branches, and from spokes to the internet is inspected by the Azure Firewall in the hub. The networking team has been maintaining static routes for 0.0.0.0/0 and all private prefixes in multiple custom route tables and wants a configuration that is simpler to maintain and applies automatically to new connections.
What should you configure?
- ARouting intent on the hub with both the Internet traffic and Private traffic routing policies set to the Azure Firewall as the next hop.Routing intent lets you declare that internet-bound and private traffic must go through the hub's Azure Firewall; Virtual WAN then programs the routes for all current and future connections, replacing hand-maintained static routes.
- BA static route for 0.0.0.0/0 and 10.0.0.0/8 with next hop Azure Firewall in the Default route table, and a user-defined route in every spoke pointing to the firewall's private IP.This is the legacy pattern the team already struggles with; static routes must be maintained manually and spoke UDRs are needed per virtual network, so it does not meet the maintainability goal.
- CHub routing preference set to AS Path so that the firewall's routes are preferred.Hub routing preference influences which path is chosen when the same prefix is learned from ExpressRoute, VPN, and SD-WAN sources; it does not steer traffic through a firewall.
- DRouting intent with only the Internet traffic policy, because private traffic between spokes is always inspected by a secured hub's firewall.Without the Private traffic policy, spoke-to-spoke and spoke-to-branch traffic bypasses the firewall; each policy must be enabled explicitly.
Why: Routing intent and routing policies are the Virtual WAN mechanism for forcing traffic through a security appliance in the hub, either Azure Firewall in a secured hub or a supported third-party NVA. You configure two optional policies: Internet traffic, which sends 0.0.0.0/0 from connected spokes and branches to the next-hop firewall, and Private traffic, which inspects RFC 1918 and any added private prefixes between spokes and branches. Once enabled, Virtual WAN programs the hub's route tables automatically and applies them to new connections, which eliminates the static routes and spoke UDRs the team maintains today. The deciding constraints are full inspection of all three traffic classes and simplicity, so both policies are required; hub routing preference is a path-selection tiebreaker, not a security control.
Design and implement an Azure Virtual WAN architecture
Larkhill Retail uses Cisco Catalyst SD-WAN at 300 stores and is adopting Azure Virtual WAN with Standard hubs in two regions. The network team wants the SD-WAN fabric to extend directly into each hub with the vendor's own appliances, with Microsoft handling the appliance VM lifecycle, scaling, and high availability, and without the team managing virtual machines, GatewaySubnets, or user-defined routes in spoke networks.
What should you implement?
- ADeploy the Cisco Catalyst 8000V SD-WAN network virtual appliance into each virtual hub from Azure Marketplace as a managed application, sized with NVA infrastructure units.Virtual WAN supports integrated third-party NVAs deployed directly inside the hub as managed applications; Microsoft manages the VM lifecycle, scaling, and availability while the vendor's orchestrator manages the SD-WAN configuration.
- BDeploy the Cisco appliances as virtual machines in a spoke virtual network and peer that spoke with the hub, adding user-defined routes in every other spoke.Running the NVA in a spoke is supported but leaves the team managing the VMs, availability sets, and routing, which contradicts the requirement.
- CConnect each store to the hub's site-to-site VPN gateway as a standard IPsec VPN site and remove the SD-WAN appliances.This uses the hub's VPN gateway rather than extending the SD-WAN fabric with the vendor's appliances, which is what the network team requires.
- DDeploy Azure Route Server in each hub and peer the store appliances with it over BGP.Azure Route Server is deployed in customer-managed virtual networks, not in Virtual WAN hubs; the hub has its own router that NVAs integrate with directly.
Why: Virtual WAN offers two ways to use third-party SD-WAN. In the first, partner CPE at branches connects to the hub's site-to-site VPN gateway with automated IPsec provisioning. In the second, the vendor's NVA is deployed directly inside the virtual hub as a managed application from Azure Marketplace, sized in NVA infrastructure units (500 Mbps each), with Microsoft handling the VM infrastructure and the vendor's orchestrator handling the SD-WAN overlay. The deciding constraint is that the appliances must live in the hub with no VM, subnet, or UDR management by the team, which is exactly the integrated NVA model. A spoke-hosted NVA is the older pattern that the hub model replaces, and Route Server belongs to customer-managed hubs.
Design and implement an Azure Virtual WAN architecture
Harwick Foods has a Standard Virtual WAN hub named hub-eastus2 that already contains a site-to-site VPN gateway connecting 12 plants. The company has ordered a 2 Gbps ExpressRoute Standard circuit named er-columbus and wants the plants and the hub-connected virtual networks to reach the Columbus data center over the circuit. An engineer proposes deploying an ErGw1AZ ExpressRoute gateway into a GatewaySubnet in one of the spoke virtual networks and connecting the circuit there.
What should you do instead?
- ADeploy an ExpressRoute gateway into hub-eastus2 with the required scale units and connect er-columbus to the hub's ExpressRoute gateway.In Virtual WAN, ExpressRoute circuits connect to an ExpressRoute gateway deployed inside the virtual hub, which lets the hub router distribute the on-premises routes to every connected spoke and VPN site.
- BDeploy the ErGw1AZ gateway in the spoke as proposed and enable gateway transit on the hub connection.A virtual network connected to a Virtual WAN hub cannot have its own virtual network gateway, and Virtual WAN does not use the peering gateway transit setting.
- CCreate a second virtual hub dedicated to ExpressRoute and connect the circuit there.A hub can contain one gateway of each type (VPN, ExpressRoute, point-to-site) at the same time, so a separate hub is unnecessary and adds cost.
- DReplace the site-to-site VPN gateway in the hub with an ExpressRoute gateway, because a hub supports only one gateway.A virtual hub supports a site-to-site VPN gateway, an ExpressRoute gateway, and a point-to-site gateway simultaneously; the VPN gateway should remain for the plants.
Why: Gateways in Virtual WAN are deployed inside the virtual hub, not in spoke virtual networks, and the hub can host one site-to-site VPN gateway, one ExpressRoute gateway, and one point-to-site gateway at the same time. Spoke virtual networks connected to a hub must not contain their own virtual network gateways, because the hub provides that connectivity and distributes learned routes through the hub router. To add ExpressRoute, you create the ExpressRoute gateway in the hub with a scale unit count sized for the circuit (one unit equals 2 Gbps, so one unit covers the 2 Gbps circuit), then connect the circuit to it, redeeming an authorization key if the circuit is in a different subscription. The plants on VPN and the spokes can then reach the data center. The engineer's spoke-gateway design is the customer-managed hub-and-spoke pattern applied to the wrong architecture.