A canal authority wants FQDN filtering, threat-intelligence-based deny, and SNAT for many spokes. A contractor proposes adding more NSG rules. What should the security engineer choose?
Select an answer to reveal the explanation.
Short Explanation
NSGs are great at five-tuple stop signs—not FQDN sniffing, threat intel, or hub SNAT. Park Azure Firewall (or a secured hub) in the middle and leave NSGs on the curb.
Full Explanation
Network Security Groups enforce allow and deny on five-tuple criteria at subnet or NIC scope. They do not provide FQDN filtering, threat-intelligence-based deny, or centralized SNAT for many spokes the way Azure Firewall does. For a canal authority that wants those capabilities, deploy Azure Firewall or a secured virtual hub with Firewall, and keep NSGs for local five-tuple allow and deny—not expand NSGs into a faux FQDN firewall.
Expanding NSG five-tuple rules until every FQDN becomes a static IP list fails operations and still lacks threat intelligence deny and managed SNAT. Raising Defender for Cloud Secure Score fails by concept: Secure Score is posture guidance, not a network filtering datapath. Creating a new VNet address space so NSGs automatically gain FQDN and threat-intelligence features is false.
Exam caveat: NSG versus Azure Firewall is a frequent AZ-500 comparison—know which features require Firewall. Operational check: deploy Firewall in the hub, route spoke egress through it, create application rules for required FQDNs, enable threat intelligence per policy, and keep subnet NSGs for micro-segmentation. 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.