AZ-700 Question 139
Single answerYour company has a hub-and-spoke topology in Azure with a hub virtual network (VNet) connected to on-premises via an ExpressRoute gateway. You have created a new spoke VNet containing several subnets that must be reachable from on-premises. However, on-premises hosts cannot currently route to these new spoke subnets. Which approach should you recommend for proper route advertisement from these new subnets back to on-premises?
- A
Enable BGP route propagation on the new spoke� subnets and assign them directly to the ExpressRoute gateway.
- B
Create an ExpressRoute route filter that explicitly includes the new spoke subnets.
- C
Enable �Use remote gateways� in the spoke VNet peering to route traffic through the hub VNet.
- D
Configure a user-defined route in each spoke subnet with Next Hop as on-premises IP to force return traffic.
Show answer and explanation
Correct answer: C
Explanation
In a hub-and-spoke design, revealing spoke routes to on-premises requires the spoke to forward traffic through the hub� ExpressRoute gateway. Peering the spoke VNet to the hub VNet and enabling �Use remote gateways� ensures that the BGP session on the hub� gateway advertises the new spoke subnets back on-premises. For more details, refer to Microsoft documentation on VNet peering and ExpressRoute BGP route advertisement best practices.
- A. Incorrect.
Option 1 is incorrect. While enabling BGP route propagation lets the Azure route tables learn on-premises routes, simply assigning spoke subnets directly to the ExpressRoute gateway is not feasible without proper VNet gateway configuration. Spoke VNets typically do not attach their own ExpressRoute gateways; they use the hub� gateway through peering.
- B. Incorrect.
Option 2 is incorrect. Route filters are used primarily for controlling which Microsoft Peering or public IP prefixes are received over ExpressRoute. They do not automatically advertise new private subnets. The hub gateway BGP session takes care of private address range advertisements, provided the VNets are correctly peered using �Use remote gateways.�
- C. Correct.
Option 3 is correct. Enabling �Use remote gateways� in the peering from the spoke to the hub allows the spoke subnets to send and receive routes through the hub� ExpressRoute gateway. This ensures that on-premises networks learn about the spoke subnets via BGP, and traffic can flow correctly in both directions.
- D. Incorrect.
Option 4 is incorrect. A user-defined route pointing to an on-premises IP for the next hop is not valid because the Azure system cannot directly forward traffic to an on-premises IP. You must rely on the virtual network gateway (in the hub) to advertise and route traffic correctly.