City council asks whether production Distributed Firewall still defaults to deny. What should the administrator show?
Select an answer to reveal the explanation.
Short Explanation
Council is asking if the front-door default is still locked, not if someone wrote a poem about locks last year. Open production NSX-T, show the default action, and show who last changed it.
Full Explanation
When city council asks whether production Distributed Firewall still defaults to deny, the administrator should show the current NSX-T Distributed Firewall default action in production and the last change record. Treat the live default action as the last city gate setting, verified on the production board rather than remembered from last year's rehearsal or assumed from a written policy binder. A lab screenshot from last year's proof of concept fails by concept because lab state is not production baseline and cannot answer the council's live question. The Tier-0 default route as a proxy for the Distributed Firewall default action fails because a default route is routing behavior, not the DFW default allow or drop applied to unmatched overlay conversations. A written deny-by-default policy with no check of the live NSX-T setting fails because a written intent without a live check does not prove whether production still denies by default. Exam caveat: baseline monitoring of key security settings means inspecting the live production DFW default action and its change history, not lab artifacts or routing tables. Operational check: open production NSX, record the Distributed Firewall default action, attach the last change ticket, compare to the approved baseline, and schedule recurring verification for the city security baseline report.