A municipal DevOps policy says the test environment deploys from the develop branch while production deploys only from tagged releases on main. How should the team wire deployments?
Select an answer to reveal the explanation.
Short Explanation
Branches and tags are the labels on the shipping crates. Point test at develop and production only at tagged main releases so unfinished work never rides into citizen-facing systems. Feature-branch prod deploys and hand-copied zips skip that gate.
Full Explanation
Municipal DevOps policy that deploys test from the develop branch and production only from tagged releases on main should be wired as environment-specific pipelines or deploy jobs consuming those refs. Associating non-production with an integration branch and production with annotated release tags is a standard promotion model for CodePipeline-style developer workflows. It keeps unfinished county routes out of production while preserving a clear audit of what was released to citizens.
Deploying both test and production from the same untagged commit on a personal feature branch fails because production then tracks unfinished work without release governance. Allowing production to pull latest develop on every push fails conceptually by auto-promoting integration code. Disabling repository tags and promoting by copying zip files between S3 buckets by hand fails because it loses provenance and invites human error.
Exam caveat: tag immutability and branch protection matter—anyone who can move a production tag can bypass the intended control. Operational check: confirm the prod pipeline trigger filters on release tags on main, confirm test tracks develop, and attempt a feature-branch prod deploy to verify it is blocked.