Change management requires human approvals before production OU deploys, while sandbox accounts may deploy continuously. How should the deployment strategy align?

Change management should match risk across a municipal AWS Organization: production organizational units that serve citizens need human approval before promotion, while sandbox accounts can iterate continuously for learning and vendor experiments. Configuring the CI/CD pipeline with mandatory approval stages for production OU targets and unattended continuous deploy into sandboxes implements that dual-track policy in one toolchain with clear audit evidence. Identical unattended continuous deploy to production and sandbox ignores production risk and public-service audit expectations. Blocking all sandbox deploys freezes learning environments and pushes experimentation into uncontrolled channels outside the pipeline. Requiring wet-signature paper tickets for every sandbox commit while leaving production ungated inverts risk controls and slows the wrong tier. Exam caveat: approvals must bind to environment or OU conditions in the pipeline—not merely a social convention—so a mis-targeted promote cannot skip the gate. Operational check: attempt a production OU deploy without approval and confirm it pauses; push the same artifact to a sandbox account and confirm it proceeds; review the approval audit trail for the production run.