Transit publishes a citizen trip-planner app north-south to the Internet. Where should the administrator place the primary Internet-facing firewall rules?
Select an answer to reveal the explanation.
Short Explanation
Internet-facing traffic is the front door, and the gateway firewall sits in that doorway on the Tier-1 or Tier-0 uplink. Distributed Firewall still matters east-west, but it is not the whole north-south story. Carbon Black on the Edge guest OS is not the NSX gateway.
Full Explanation
Transit’s citizen trip-planner published north-south to the Internet needs primary Internet-facing firewall rules on the Tier-1 or Tier-0 gateway that owns that uplink. Gateway firewall is the north-south control at the civic perimeter; Distributed Firewall on the web VM alone is not a complete Internet-edge story.
Using Distributed Firewall only on the web VM while claiming gateway firewall never sees north-south is false for traffic that traverses the Tier-0/Tier-1 uplink. Carbon Black Cloud host firewall on the Edge guest OS is not the NSX gateway firewall for citizen north-south policy. Workspace ONE UEM compliance does not inspect inbound Internet packets at the hypervisor for that app.
Exam caveat: Internet-facing north-south → gateway firewall on the owning Tier-0/Tier-1; DFW complements but does not replace the edge.
Operational check: publish gateway firewall for the trip-planner uplink, verify external test hits on the Edge/gateway path, keep DFW as defense-in-depth on the web group, and document which tier owns Internet policy.
Internet-facing trip-planner policy belongs on the gateway that owns the uplink, with DFW as depth. After gateway rules publish, test from an external probe, correlate Edge/gateway hit counters, and write an ownership matrix so NOC pages the Edge owners—not only the web VM owners—during citizen outages.