The city requires scan results, model tests, and dual human approval before promoting a parks chatbot to production. Which deployment practice is this?

Secure automated deployment gates combining scans, model tests, and dual human approval are the right pattern when a city requires all three before promoting a parks chatbot. Technical gates catch known classes of defects (vulnerable code/deps, unsafe model outputs), while dual approval enforces separation of duties so one person cannot unilaterally put a public municipal bot live. The combination works because civic AI risk is both technical and organizational: scans and tests reduce defect escape, and dual approval reduces process bypass, insider error, and “ship Friday” pressure on a resident-facing channel.

Manual deployment checklist requiring scans, model tests, and dual approval fails because a manual checklist relies on human attestation rather than enforced automation, so required scans, tests, and approvals can be skipped or inconsistently applied before the parks chatbot is promoted. Secure automated build gates combining scans, model tests, and dual approval fails on lifecycle stage — build gates validate the build, not promotion to production, so they cannot enforce the pre-production deployment check the policy requires. Secure automated monitoring alerts combining scans, model tests, and dual approval fails on timing and control — monitoring alerts observe the system after release and cannot block promotion, so they do not enforce the required deployment gate.

Exam caveat: dual approval is weak if both approvers are the same person under two accounts, or if emergency break-glass paths are undocumented and overused. Operational check: enforce parks chatbot promotion as a pipeline stage that cannot complete without scan+test evidence and two distinct authenticated approvers; review break-glass events weekly and require retroactive model-card updates after any emergency promotion.