A city wants Distributed Firewall in default-deny, but some transport nodes are not yet Up and inventory groups are not built. What should the administrator do during the install workflow?
Select an answer to reveal the explanation.
Short Explanation
Default-deny on a half-built cluster is like locking the stadium before the seats are installed—you just strand the people already inside. Get transport nodes Up and groups built first. Then default-deny is a policy choice, not an outage.
Full Explanation
A city that wants Distributed Firewall default-deny must finish the install workflow so transport nodes are Up and inventory groups exist before flipping aggressive defaults. Default-deny on an unfinished fabric strands management and application traffic without reliable grouping or realization.
Flipping the default rule to Drop immediately on incomplete nodes creates outages, not mature zero-trust. Disabling NSX-T until a multi-year committee finishes paperwork abandons the install without need. Putting all civic VMs on the DFW exclusion list and marking install complete disables micro-segmentation while claiming victory.
Exam caveat: enablement order matters—nodes Up, groups built, allow-list baselined, then tighten default action.
Operational check: confirm all target transport nodes Up, build critical allow groups, validate pilot allows, then change default action in a monitored window with rollback ready.
Default-deny on half-built city fabric creates self-inflicted outages that poison zero-trust programs. Finish node health and group coverage, stage allow rules for management and critical apps, flip default action with SIEM watching unrealized drops, and keep an emergency allow section ready under change control.