Transit needs north-south gateway firewall at the civic perimeter, not only east-west host filtering. What must be deployed?
Select an answer to reveal the explanation.
Short Explanation
East-west DFW is a lock on every apartment door; north-south gateway firewall is the lobby door on the street. You still need Edge nodes in an Edge cluster for that lobby—host DFW alone will not inspect traffic leaving toward the ISP.
Full Explanation
North-south gateway firewall at the transit civic perimeter requires NSX Edge nodes joined to an Edge cluster so Tier-0/Tier-1 gateway firewall can inspect traffic toward the ISP. Host Distributed Firewall alone filters east-west at compute vNICs; it does not replace the Edge gateway role for perimeter north-south policy.
Distributed firewall rules on compute hosts only leave the north-south lobby unprotected even when apartment-door east-west locks exist. A Workspace ONE Access policy in front of the ISP handoff is identity and access for apps, not NSX gateway firewall packet enforcement. Carbon Black Cloud prevention on the Edge management VLAN is endpoint control and does not implement Tier-0/Tier-1 gateway firewall for citizen-facing north-south flows.
Exam caveat: map east-west to DFW and north-south perimeter to Edge gateway firewall—do not collapse both into host DFW-only answers.
Operational check: deploy Edges into an Edge cluster, attach uplinks, publish gateway firewall policy for the trip or fare north-south paths, verify hits and Traceflow across the Edge, and document Edge ownership in the transit perimeter runbook.
Gateway firewall on Edges is the transit street door; host DFW remains the office-door lock for east-west. After Edge cluster formation, validate uplink state, publish a temporary deny for a test VIP, and confirm citizen-facing traffic hits gateway counters rather than only host DFW logs so on-call staff know which console to open during an ISP-path incident.