Governance
Part of Cloud deployment workflows
Recording infrastructure changes in version control
Trace cloud infrastructure changes through configuration review, current plans and deployment records while protecting state and secrets.
Record a cloud infrastructure change as a reviewed configuration change tied to the deployment that put it into service. Version control shows the intended settings and their history. By itself, it does not show what exists in the cloud now or make a change safe.
Decide what the repository owns
List the resources and settings managed as code, such as application hosting, network rules, deployment identities and monitoring configuration. Give each set an owner and an approved change route.
If an operator makes an urgent console change, record it and bring the managed definition back into agreement after the incident. Otherwise, a later deployment may conflict with the live setting.
Keep environment-specific values clear without committing secret values. Shared modules can define a common pattern while parameters express intentional differences. Review those differences before promotion to production.
Managed vs Unmanaged Infrastructure Changes
- Managed (via code)Changes are tracked, reviewed, and versioned. Reduces drift and improves auditability.
- Unmanaged (console-only)Changes not recorded in code may cause conflicts during future deployments or create unexplained drift.
Make a change reviewable
A proposal should explain why the change is needed, which resources it affects, the expected user effect, the configuration diff and the tool's proposed operations. Review additions, replacements and deletions. A small text edit can cause a substantial infrastructure operation, so the diff alone is insufficient.
For Terraform, terraform plan previews changes by comparing configuration with infrastructure state. Review the final plan before applying it; a saved plan can help ensure the changes applied match those approved, even when deployment happens later or on another machine.
Repository rules can require reviews and passing checks. GitHub branch protection supports these controls when configured, but administrators or other authorised actors may be able to bypass them unless the effective rule prevents it. Check the rule rather than assuming a branch named main is protected.
Keep sensitive runtime files out of commits
Commit infrastructure definitions, not Terraform state or variable files containing secrets. Avoid storing Terraform state in version control or other storage without state locking and secure access control, as this can risk data loss or expose secrets. Store state in HCP Terraform or a suitable remote backend with appropriate access control and locking.
The repository can contain references to approved secret locations and the permissions needed to retrieve them without holding production values. Review access to pipeline logs and plan output as well as the source tree.
Pros and Cons of Storing Terraform State in Version Control
- ProsProvides a complete history of infrastructure state; useful for auditing and recovery.
- ConsHigh risk of data loss or secret exposure if not protected with locking and access control.
Best Practices for Secure Infrastructure as Code
- Do not commit Terraform state
- Store in HCP Terraform or remote backend with locking
- Avoid committing secrets
- Use external secret managers; reference approved locations instead
- Review pipeline logs
- Prevent accidental exposure of sensitive data in plan outputs
Connect intent to the live result
Keep the commit, relevant plan or run identifier, approval, operator, time and apply result together in the change record. Protect that record if its plan output contains sensitive information.
Check the affected resource state and application action after deployment. A successful apply says the tool completed its operation; it does not prove users can complete their work.
If a live resource differs from code, identify whether an emergency edit, another automation path or a failed apply caused the difference. Decide whether to adopt the live setting into code or restore the reviewed setting. Do not overwrite an unexplained difference merely to quiet a drift report.
