Courts operations discover hotfix DDL applied directly in production that never updated the SQL Database Project model. How should the pipeline respond to that drift?

Courts operations discover hotfix DDL applied directly in production that never updated the SQL Database Project model. The pipeline should fail when schema drift reports show production differs from the Database Project model, forcing the courts team to reconcile the hotfix into source-controlled DDL before further releases proceed. Drift failure is a municipal CI/CD control that keeps production from becoming an undocumented fork of the project—critical for hearing calendars, docket objects, and other court schema that must remain reviewable.

Ignoring drift reports so hotfixes remain undocumented indefinitely fails by accepting permanent model divergence and defeating database-as-code. Deleting the project model so production becomes the only source of truth fails by abandoning the deployable, testable project artifact DP-800 centers for SQL Database Projects. Auto-approving every production difference without notifying code owners fails governance: silent acceptance of hotfix DDL removes the reconciliation and review step the drift signal exists to trigger.

Exam caveat: schema drift detection is useful only when the pipeline treats unexplained production differences as blocking. Answers that ignore, delete, or auto-approve drift invert the control. Expect stems about hotfixes applied outside the project to point at fail-on-drift plus reconcile-to-model.

Operational check: enable a compare/drift step against courts production (or a mirrored probe), introduce a known out-of-band column on a non-prod twin, and confirm the pipeline fails with a clear drift report. Script the hotfix into the SQL Database Project, pass review, redeploy, and verify the drift check returns clean before opening the release gate again.