A new permits-chatbot model fails health checks after deploy, so the pipeline restores the last known-good version automatically. Which practice is demonstrated?

Automated deploy/rollback that returns civic AI to a known-good build is a core secure-delivery practice for municipal services such as a permits chatbot. After deploy, health checks (latency, error rate, safety probes, dependency readiness) validate that the new model or application revision is fit for resident use. When those checks fail, the pipeline automatically restores the last known-good version so the public-facing channel recovers without waiting for an ad-hoc manual scramble. That works because release risk is expected in AI delivery, and civic availability plus safety depend on a rehearsed, automated recovery path rather than hoping operators notice outages first.

Automated canary release that ramps civic AI for subset traffic fails because it describes gradually ramping the new version to a subset of traffic, not automatically restoring the last known-good version when health checks fail. Automated roll-forward that advances civic AI to a hotfix build fails because it deploys a new forward fix rather than restoring the last known-good version described in the scenario. Model registry tagging that versions civic AI builds for audit reuse fails because it provides versioning for audit reuse but does not itself automatically restore service when health checks fail.

Exam caveat: automated rollback must itself be tested; a rollback path that only works in staging, or that restores an old model incompatible with current schemas/prompts, can worsen an outage. Operational check: define health-check thresholds for the permits bot, keep immutable known-good build/model artifacts, run periodic game-day rollbacks, and require post-incident verification that resident-facing traffic fully shifted back to the restored revision.