Only the hub has a VPN gateway to the grain elevator. Spokes must use that hybrid path without each deploying a gateway. Which peering settings should the security engineer enable?
Select an answer to reveal the explanation.
Short Explanation
One VPN gateway at the hub is enough. Flip Allow gateway transit on the hub peering and Use remote gateways on the spokes—don’t plant a gateway in every cornfield.
Full Explanation
Gateway transit lets spoke VNets use a VPN or ExpressRoute gateway in a peered hub instead of deploying a gateway in every spoke. Enable Allow gateway transit on the hub peering and Use remote gateways on the spoke peerings so spokes reach the grain elevator’s hybrid path through the hub gateway.
Deploying a VPN gateway in every spoke and disabling hub peering fails cost and the shared-gateway design. Claiming Virtual WAN is the only supported way to share hybrid connectivity fails—classic hub-spoke gateway transit remains valid. Enabling gateway transit on each spoke and Use remote gateways only on the hub reverses the settings and will not work as intended.
Exam caveat: only one gateway transit path is used; know which peering flag belongs on hub versus spoke. Operational check: set Allow gateway transit on hub, Use remote gateways on spokes, confirm spokes learn on-premises prefixes, test hybrid connectivity from a spoke VM, and ensure no competing gateway misconfiguration exists. In municipal Azure estates, document the decision in the change record, validate with a nonproduction rehearsal, and confirm monitoring still pages the on-call operator when the control fails closed during an incident drill.