After a test-environment deploy of a permit-write API, the pipeline should prove one critical path still works without leaving junk data. What should run next?
Select an answer to reveal the explanation.
Short Explanation
Smoke the kitchen after remodel—one burner on, then wipe the counters. A canary write/read with cleanup proves the path without littering the test table. Waiting for citizens or laptop-only clicks is too late or too tribal.
Full Explanation
After a test-environment deploy of a permit-write API, the pipeline should execute a post-deploy canary script that performs a controlled write/read and then cleans up the test records. Canaries automate validation of a critical municipal path after infrastructure and code are live, proving end-to-end behavior without leaving junk permits in shared test data. Stack success from CodePipeline is necessary but not sufficient for promotion readiness.
Marking the deploy successful based solely on the CodePipeline stage turning green for CloudFormation fails because resources can exist while the write path is broken by IAM, VPC, or application bugs. Waiting for citizens to report broken permits in production as the first signal fails conceptually by using production users as monitoring. Manually clicking through the API once on a developer laptop and discarding session notes fails as non-automated, non-auditable evidence.
Exam caveat: canary credentials and permit IDs must be test-scoped, and cleanup must run even on assertion failure to avoid littering the shared table. Operational check: deploy to test, run the canary write/read/cleanup, fail the pipeline on mismatch or leftover records, and store canary logs with the deploy record.