A night-shift design review stacks NSG, Azure Firewall, and Application Gateway on the same flow without clear roles. How should the security engineer assign jobs?
Select an answer to reveal the explanation.
Short Explanation
NSG = local 5-tuple bouncer, Firewall = hub egress/DNAT/FQDN/threat intel, Application Gateway = regional L7 reverse proxy. Stack them on purpose, not by accident.
Full Explanation
On a night-shift design review for canal traffic, assign clear jobs: NSGs perform subnet/NIC 5-tuple filtering; Azure Firewall centralizes spoke egress, DNAT, FQDN application rules, and threat intelligence; Application Gateway provides the regional Layer-7 HTTP(S) reverse proxy (with WAF when needed). Stacking products without those roles creates overlapping or contradictory controls.
Assigning NSG for global anycast HTTP(S), Firewall for NIC-only 5-tuple, and Application Gateway for RDP DNAT only fails by concept: those jobs are swapped—anycast global HTTP(S) is Front Door territory, Firewall owns centralized FQDN/DNAT/threat intel, and NSGs are local 5-tuple filters. Making Azure Firewall the only control and deleting NSGs and Application Gateway fails by concept: one product does not replace every layer’s appropriate control. Using Application Gateway for all VNet egress FQDN filtering and threat intelligence fails by concept: those are Azure Firewall strengths, not Application Gateway’s regional reverse-proxy role.
Exam caveat: service-selection questions reward correct layering—NSG vs Firewall vs Application Gateway—not product consolidation myths. Operational check: document each control’s job on the flow diagram, confirm NSGs remain on subnets/NICs, Firewall handles hub egress/DNAT/FQDN/threat intel, and Application Gateway terminates regional L7 HTTP(S) for the web tier.