After each staging deploy of a citizen records API, the team wants a fast signal that the environment is basically healthy. What should they automate?
Select an answer to reveal the explanation.
Short Explanation
After you land the plane, check the doors still open. A tiny smoke script—health plus one authenticated read—tells you staging is alive before QA piles on. Waiting for production complaints is not a smoke test.
Full Explanation
After each staging deploy of a citizen records API, the team should automate a post-deploy smoke script that hits health and one authenticated read path against the staging environment. Smoke tests give a fast signal that the municipal environment is basically healthy—routing, auth, and a primary read—before deeper suites or human QA burn time. Domain 3 deployment testing treats these checks as part of the pipeline, not optional courtesy scripts.
Waiting for citizens to report errors in production as the primary deploy signal fails because production users become the test harness. Skipping smoke tests because unit tests already ran in CI before packaging fails conceptually—unit tests do not prove the deployed stage is reachable and correctly wired. Manually clicking random screens once a quarter instead of after each deploy fails as an untimely, non-automated control.
Exam caveat: smoke scripts need non-production credentials and synthetic record IDs; they must not mutate or expose real citizen data while proving health. Operational check: break a staging route on purpose in a drill, confirm the smoke gate fails and blocks promotion, then restore and verify green smoke before continuing.