The canal authority is moving from a DIY hub-spoke to Virtual WAN and still needs a central inspect-and-deny point. What should the security engineer implement?
Select an answer to reveal the explanation.
Short Explanation
Virtual WAN isn’t “just another peer.” Bolt Azure Firewall onto the hub with Firewall Manager and you’ve got a secured virtual hub that can inspect and deny.
Full Explanation
A secured virtual hub is a Virtual WAN hub with Azure Firewall associated through Azure Firewall Manager, providing a central inspect-and-deny point as the canal authority moves off DIY hub-spoke. Implement that association so branches and spokes can be steered through Firewall rather than unmanaged any-to-any paths.
Dropping an NSG on the Virtual WAN hub address prefix fails: NSGs are not how you turn a Virtual WAN hub into a secured hub. Peering every branch to every other branch and skipping a hub firewall fails centralized inspection. Replacing Virtual WAN with host-based antivirus as the network inspection layer fails by concept.
Exam caveat: secured virtual hub equals Virtual WAN hub plus Firewall via Firewall Manager. Operational check: associate Azure Firewall with the hub, confirm secured hub status, attach connections, and test that policy denies and allows match municipal inspection requirements. 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. 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.