A change to the elections-office CI pipeline definition is proposed. What municipal change-control practice applies?
Select an answer to reveal the explanation.
Short Explanation
You should review and approve pipeline YAML like application code before merging; automation deserves the same change control. Editing the production runner without review, allowing anonymous forks to change production stages, or hiding changes from auditors can undermine security and accountability.
Full Explanation
Pipeline-as-code is still code, so you should review and approve a proposed change to the elections-office CI definition before merging it. Applying the YAML edit directly on the production runner with no review bypasses peer approval and leaves a weaker change history. Permitting anonymous forks to alter production pipeline stages without review or approval lets untrusted contributors potentially disable security jobs or expose secrets through pipeline steps. Hiding pipeline changes from auditors because they are “just automation” fails because automation that builds and deploys elections software is within change control; calling it automation does not exempt it. Reviewing the change as application code helps prevent silent weakening of tests, secret handling, or deployment gates, and preserves an account of who changed the pipeline and why. Exam caveat: this does not mean every runner OS patch must be a Git merge; changes to pipeline definitions that affect stages, triggers, or credential wiring should follow the review-and-approval path. Practical check: submit a merge request for the elections CI YAML, require at least one approval, confirm the protected branch rejects direct pushes, then verify the running pipeline matches the approved revision and the change appears in the audit trail.