A public-health script proposal would disable Distributed Firewall through the API on a cron so nightly batch jobs always succeed. What should the administrator do?

A public-health proposal to disable Distributed Firewall through the API on a cron so nightly batch jobs always succeed must be rejected as unsafe automation; require scoped allow rules for the batch window instead. Treat nightly batch as a scheduled clinic courier that needs a temporary hallway pass, not as permission to unlock every door in the building until sunrise. Approving the cron because any API call counts as safe policy automation fails by concept because the API is only a transport—disabling Distributed Firewall periodically is still a default-allow blast radius regardless of how it is invoked. Moving the same disable into a T0 BGP community fails because BGP communities steer routing, not Distributed Firewall enablement, and cannot sanitize an unsafe disable pattern. Replacing NSX-T with an any-any physical firewall for the night window fails because swapping control planes for a nightly free-for-all still abandons micro-segmentation and creates an unmanaged north-south hole. Exam caveat: security-policy automation must publish intended allows, groups, and time windows—not periodically disable Distributed Firewall; API usage does not make an unsafe change acceptable. Operational check: publish time-scoped Distributed Firewall allows for the batch security groups, verify hit counts during the night window, confirm Distributed Firewall remains enabled, and reject any automation that toggles DFW off via API.