A municipal DevOps pipeline deploys code to production Friday nights. Leadership wants security checks before release. Where should those checks run?
Select an answer to reveal the explanation.
Short Explanation
Bolt security tests into CI so bad builds fail in the garage—not after Friday night deploy when citizens are already using the app.
Full Explanation
Security checks for municipal DevOps releases belong inside continuous integration so failures gate the build before production deploy. Embedding SAST/DAST dependency scans, secret detection, or policy checks in CI makes security a required pipeline stage rather than an optional afterthought, stopping vulnerable builds in the 'garage' before Friday-night citizen-facing releases. That shift-left placement matches secure software deployment expectations for city applications.
Waiting until production users report bugs next month is reactive detection after exposure. Optional manual steps developers may skip under deadline pressure will be skipped precisely when risk is highest. Running checks only on an intern's laptop with no pipeline integration is unverifiable, non-repeatable, and easy to bypass.
Exam caveat: CI gates need actionable severity thresholds so teams fix real issues without ignoring the pipeline; broken or flaky security jobs that everyone force-skips cease to be controls. Pair CI tests with protected branches and deploy keys so production cannot be pushed around the gate.
Operational check: require green security stages on the municipal CI pipeline before deploy jobs run, block direct pushes to production branches, measure mean time to remediate failed security checks, and audit any emergency bypasses with expiry and review.