Technical Lab: Recommend a route advertisement configuration
Questions
Question 1 — Multiple Choice
A company has two environments connected to Azure via ExpressRoute: the main headquarters with a 1 Gbps circuit, and a branch office with a 200 Mbps circuit. Both circuits are associated with the same ExpressRoute Gateway in a Virtual Network (VNet). The network team needs to ensure that outbound traffic from Azure destined to headquarters preferentially uses the headquarters circuit, not the branch office circuit.
Which routing mechanism should be configured to influence this preference on the Azure side?
A) Increase the route weight on the branch office circuit to make it less preferred by the gateway
B) Configure AS Path Prepending on routes advertised by headquarters so Azure prefers the shorter path
C) Increase the route weight on the headquarters circuit so the Azure gateway prefers this path
D) Configure Local Preference on the Azure gateway BGP to prioritize the headquarters circuit
Question 2 — Technical Scenario
An engineer configures a Site-to-Site VPN connection between Azure and an on-premises datacenter. The on-premises VPN device advertises the prefix 10.10.0.0/16 via BGP. The Azure VNet has the address space 10.20.0.0/16.
After the connection is established, virtual machines in the VNet can ping the on-premises gateway but cannot reach hosts in specific subnets within the 10.10.0.0/16 block. The engineer verifies that the VMs' effective route table shows only the route to 10.10.0.0/16.
What is the most likely cause of the problem?
A) The Local Network Gateway is configured with an address space different from the prefix advertised via BGP
B) The on-premises VPN device is not advertising the more specific subnet prefixes via BGP, only the supernet
C) The Azure VNet does not support routing to prefixes smaller than /16 via BGP
D) The Azure VPN Gateway is dropping more specific prefixes due to conflict with the VNet address space
Question 3 — True or False
When using Azure Route Server together with a Network Virtual Appliance (NVA), routes learned by the NVA via BGP and propagated to Route Server are automatically injected into the route tables of all VNets peered with the VNet containing the Route Server, as long as Branch-to-Branch is disabled.
True or False?
Question 4 — Technical Scenario
An organization uses Azure Virtual WAN (vWAN) with managed hubs and has branch offices connected via S2S VPN and a spoke VNet connected to the hub. The network team reports that branch offices can communicate with the spoke VNet, but two branch offices cannot communicate directly with each other.
The current hub configuration is:
Hub Routing Preference: ExpressRoute
Branch-to-Branch: Disabled
Which change resolves the communication problem between branch offices?
A) Change the Hub Routing Preference from ExpressRoute to VPN
B) Enable Branch-to-Branch in the vWAN hub settings
C) Create a User Defined Route (UDR) in the spoke VNet pointing to the hub
D) Configure BGP peering directly between the VPN devices of the branch offices
Question 5 — Multiple Choice
An architect is designing connectivity between two Azure regions using Global VNet Peering. The solution must allow resources in both VNets to communicate with the on-premises network connected via ExpressRoute to only one of the VNets.
What gateway transit configuration is needed for the remote VNet (without ExpressRoute) to reach the on-premises network?
A) Enable Allow Gateway Transit on the VNet that has the ExpressRoute gateway and Use Remote Gateways on the remote VNet
B) Enable Use Remote Gateways on both VNets so the peering is bidirectional
C) Enable Allow Gateway Transit on both VNets, as global peering requires symmetric configuration
D) Enable Allow Forwarded Traffic on the VNet that has the gateway and Use Remote Gateways on the remote VNet
Answer Key and Explanations
Answer Key — Question 1
Answer: C
Route weight is a local attribute of the Azure gateway used to break ties for routes learned via BGP when multiple paths are available. A higher weight indicates preference. Since both circuits arrive at the same gateway, increasing the weight on the headquarters circuit makes Azure prefer that path when making outbound routing decisions.
The main error in the distractors lies in scope confusion: AS Path Prepending (B) is a technique to influence inbound routing to Azure, making a path less preferred for traffic coming from outside, not outbound. Local Preference (D) is a BGP attribute that exists within an AS and is not directly configurable on the Azure gateway. Increasing the weight of the branch office (A) would make that path more preferred, the opposite of the objective.
Answer Key — Question 2
Answer: B
When BGP is enabled on a VPN connection, the Local Network Gateway loses its function of manually defining reachable prefixes. The Azure route table is populated exclusively by prefixes advertised via BGP by the on-premises peer. If the on-premises device advertises only the supernet 10.10.0.0/16 and not the more specific subnet prefixes, Azure learns only this aggregate route. Traffic reaches the on-premises gateway, but without more specific subnet information, local routing may fail for specific hosts depending on the on-premises topology.
Alternative (A) would only be relevant for connections without BGP. Alternative (C) is incorrect: Azure supports prefixes up to /32 via BGP. Alternative (D) is incorrect because 10.10.0.0/16 and 10.20.0.0/16 do not overlap, so there is no conflict.
Answer Key — Question 3
False
Azure Route Server propagates routes learned from the NVA to gateways (VPN and ExpressRoute) and to VNets in the same VNet. For these routes to propagate to peered VNets, the peering must have gateway transit properly configured, and this is not automatic just because peering exists.
Additionally, the statement's condition inverts the Branch-to-Branch logic: this feature, when enabled, allows Route Server to exchange routes between gateways and the NVA, enabling communication between branches. Disabling it restricts this behavior. The statement combines two concepts that are individually correct in an incorrect way, creating a false conclusion.
Answer Key — Question 4
Answer: B
In Azure Virtual WAN, direct communication between branches (branch-to-branch) is controlled by the Branch-to-Branch configuration. When this option is disabled, the hub does not propagate routes from one branch to another, even if both are connected to the same hub. Enabling this configuration resolves the problem without requiring changes to spoke VNets or branch devices.
Alternative (A) changes the hub's routing preference but does not enable route exchange between branches. Alternative (C) affects spoke VNet traffic, not branch-to-branch communication. Alternative (D) would create a direct tunnel outside vWAN, which bypasses the managed solution and is not the correct approach within the vWAN model.
Answer Key — Question 5
Answer: A
Gateway transit in VNet Peering works asymmetrically by design. The VNet that has the gateway must have Allow Gateway Transit enabled, authorizing other VNets to use its gateway. The remote VNet, which does not have a gateway, must have Use Remote Gateways enabled to point to the partner VNet's gateway.
Alternative (B) is incorrect because Use Remote Gateways can only be enabled on VNets that do not have their own gateway. Configuring this on both would result in an error. Alternative (C) is incorrect: the configuration is not symmetric and Allow Gateway Transit on both does not make logical sense. Alternative (D) confuses Allow Forwarded Traffic (which allows traffic originated outside the VNet to pass through peering) with Allow Gateway Transit (which allows gateway usage), being distinct concepts with different purposes.