The city’s pipeline policy marks the build red when static analysis reports a high-severity finding so the artifact is not deployed. What benefit does that quality gate provide?
Select an answer to reveal the explanation.
Short Explanation
A real gate stops the train—high-severity findings paint the pipeline red so the bad crate never leaves. A warning nobody must honor is just a sticky note.
Full Explanation
Marking the build red when static analysis reports a high-severity finding so the artifact is not deployed provides a consistent automated stop: known-bad artifacts do not leave the municipal pipeline when policy thresholds are crossed. The quality gate’s value is enforcement—pipeline status fails—rather than a polite suggestion developers can click past while still promoting the image.
An advisory-only scan that developers may ignore while still promoting the image is exactly what a failing gate prevents; advisory mode alone does not deliver that benefit. A Kubernetes rolling-update strategy document unrelated to CI findings does not implement a static-analysis quality gate. A manual email that never fails the pipeline job status likewise leaves promote available despite high-severity findings.
Exam caveat: the benefit under test is the automated stop tied to pipeline status, not the mere existence of a scanner brand or a human notification thread. Operational check: introduce a deliberate high-severity finding in a non-prod branch, confirm the static-analysis job fails the pipeline, and verify deploy/promote stages do not run until the finding is remediated or formally waived under city policy.