Which pattern would follow IaC best practices for making a change to an infrastructure stack running in a public cloud?

Which pattern would follow IaC best practices for making a change to an infrastructure stack running in a public cloud?

• A. Submit a pull request and wait for an approved merge of the proposed changes
• B. Clone the repository containing your infrastructure code and then run the code
• C. Use the public cloud console to make the change after a database record has been approved
• D. Make the change via the public cloud API endpoint

Answer: (A)

When managing infrastructure with Infrastructure as Code, changes should flow through a version-controlled, reviewed workflow. Submitting a pull request captures the proposed changes as code, shows a clear diff, and requires an explicit approval before merging. This gives you governance, an auditable history, and the chance for peers to review for correctness, security, and compliance. It also enables automated tests and validations in a CI/CD pipeline, so deployments are tested before they reach production and the deployment becomes repeatable and predictable. Once merged, the change is applied through the established deployment process, keeping the live environment in sync with the code. Making changes directly in the cloud console or via the cloud API bypasses this controlled process. It risks configuration drift, reduces traceability, and makes it harder to reproduce or roll back changes. Similarly, running the code locally after cloning it may not engage the formal review and integration steps that ensure consistency across environments.

When managing infrastructure with Infrastructure as Code, changes should flow through a version-controlled, reviewed workflow. Submitting a pull request captures the proposed changes as code, shows a clear diff, and requires an explicit approval before merging. This gives you governance, an auditable history, and the chance for peers to review for correctness, security, and compliance. It also enables automated tests and validations in a CI/CD pipeline, so deployments are tested before they reach production and the deployment becomes repeatable and predictable. Once merged, the change is applied through the established deployment process, keeping the live environment in sync with the code.

Making changes directly in the cloud console or via the cloud API bypasses this controlled process. It risks configuration drift, reduces traceability, and makes it harder to reproduce or roll back changes. Similarly, running the code locally after cloning it may not engage the formal review and integration steps that ensure consistency across environments.