Post-deploy smoke tests for the public-works portal cannot create a work order. What should the delivery pipeline do?
Select an answer to reveal the explanation.
Short Explanation
If smoke cannot open a work order, the release failed the "can citizens get help" test. Block or roll back; expanding the canary or filing the ticket closed anyway is wishing the outage away.
Full Explanation
Failed post-deploy smoke on a critical path means the release has not demonstrated basic citizen capability and must not be treated as successful. When public-works portal smoke tests cannot create a work order, the delivery pipeline should block or roll back because work-order creation is a core public-works service for residents reporting hazards and requests—not a cosmetic check that can be waived under schedule pressure.
Marking the release successful and notifying citizens that work orders are optional reframes a broken critical path as a product decision and erodes trust in municipal service channels. Ignoring smoke results and expanding the canary to 100% immediately amplifies blast radius after clear evidence of failure on the path citizens need. Archiving the smoke logs without acting and closing the change ticket creates a paper trail of negligence while leaving the portal unable to open work.
Exam caveat: only critical-path smoke failures should hard-block; distinguish flaky non-critical checks with quarantine or retries, but never soft-pass work-order creation on a public-works portal. Pair block/rollback with an incident channel so operators know the release halted for cause. Operational check: on smoke failure for work-order create, halt promotion, trigger rollback to last known-good, re-run smoke on the restored version until green, and keep the change ticket open with failure evidence attached.