An organization's Chief Technical Officer is concerned that changes to the network using IaC are causing unscheduled outages. Which of the following best mitigates this risk?

The most effective way to mitigate outages from Infrastructure as Code (IaC) changes is to integrate formal change control directly into the automation workflow. Adding review and approval steps to the Continuous Integration/Continuous Deployment (CI/CD) pipeline enforces governance. These steps can include mandatory peer reviews, automated static code analysis, security scans, and manual approval gates before the code is applied to the production environment. This ensures that all changes are vetted for correctness, compliance, and stability, directly addressing the CTO's concern by preventing un-vetted or faulty code from causing unscheduled outages.

A. Making code changes to the master branch: This practice, known as committing directly to the main branch, bypasses all safety checks and reviews, significantly increasing the risk of deploying faulty code and causing outages.
B. Enforcing code review of the change by the author: Self-review is not a reliable control mechanism. An independent review by one or more peers is necessary to identify errors, logic flaws, or unintended consequences that the original author may have overlooked.
C. Forking the code repository before making changes: Forking creates a personal copy of a repository but does not, by itself, enforce any review or approval. The critical control is the process for merging changes back, not the act of forking.

1. Official Vendor Documentation (Analogous Principle): Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley. In Chapter 5, "Anatomy of the Deployment Pipeline," the authors describe the necessity of stages, including manual testing and approval gates, stating, "Sometimes, a fully automated process is not appropriate... In these cases, your deployment pipeline can include a manual stage" (p. 112). This principle directly supports adding manual approval steps for governance.

2. Peer-reviewed Academic Publication: Rahman, A., & Oivo, M. (2021). A Conceptual Framework for CI/CD in a Regulated Medical Software Domain. In Software Business. ICSOB 2021. Lecture Notes in Business Information Processing, vol 434. Springer, Cham. The paper emphasizes the need for formal review and verification stages within the CI/CD pipeline for compliance and safety, stating, "The V&V [Verification and Validation] activities are performed in the CI/CD pipeline... [including] code review, static code analysis, unit testing, integration testing" (Section 4.2, "CI/CD Pipeline"). This highlights the integration of review steps for risk mitigation. DOI: https://doi.org/10.1007/978-3-030-89002-110

3. University Courseware: Miller, R. (2013). Lecture 3: Version Control. MIT OpenCourseWare, 6.170 Software Studio, Spring 2013. The lecture materials discuss branching models where changes are made on separate branches and then merged into the master branch only after review (e.g., via a pull request). This foundational software engineering practice is the basis for controlled changes in CI/CD pipelines. (Available at: https://ocw.mit.edu/courses/6-170-software-studio-spring-2013/)