Infrastructure-as-code implications — why IaC has a stricter version-control bar than application code

Application code, when deployed, runs in a process. Infrastructure code, when applied, changes the world: it creates users, opens ports, provisions databases, configures Terraform state, rotates credentials, grants role permissions. The surface area of an infrastructure change is the cloud provider’s API surface, not a single process boundary. The version-control discipline for an infrastructure repository is the discipline that constrains this surface area to changes that have been reviewed, recorded, and are recoverable.

Blast radius

The blast radius of a change is the scope of the consequences if the change goes wrong. For application code, the blast radius is bounded by the process, the request, and the user. A bad release of an application is corrected by a subsequent release; the database is untouched, the network is unchanged, the operating system is unchanged. For infrastructure code, the blast radius is the API surface of the cloud provider.

A bad Terraform plan can:

• Delete a database. The state file records the deletion; the database is the cloud’s problem.
• Open a security group to 0.0.0.0/0. The fix is a subsequent commit, but the window of exposure is real.
• Rotate a credential out of cycle. The old credential stops working for every consumer that depended on it.
• Apply a policy with a typo. The typo is now a security control failure.

The asymmetry is that an application bug is recoverable by a redeployment; an infrastructure bug is recoverable only by a subsequent infrastructure commit, and the original bug has already changed the world.

flowchart LR
    A["App code commit"] --> B["Process restart"]
    B --> C["Old process replaced"]
    C --> D["Failure contained"]

    E["IaC commit"] --> F["Cloud API call"]
    F --> G["World changed"]
    G --> H["Recovery requires new commit"]

Rollback constraints

Rollback for application code is the redeployment of the previous version. The previous version is recoverable from the artifact registry; the redeploy is a routine operation. Rollback for infrastructure code is a forward change: revert the configuration commit, run terraform plan against the current state, review the full plan, and apply. The state file is never “rolled back” as part of it.

• Terraform state. The state file is the record of what was applied. It lives in a locked, versioned remote backend; the versioned backup exists to recover from proven state corruption or loss, not to serve as a rollback mechanism. A state file on a developer’s laptop is unrecoverable when the laptop fails.
• Cloud provider audit log. CloudTrail, Cloud Audit Logs, or equivalent is the cloud-side record of what API calls were made. This is the second source of truth for what was applied, and it must be enabled and retained.
• State lock. A state lock prevents two terraform apply operations from running concurrently. The lock is held by the pipeline that performed the apply, and the lock is released when the apply completes. Concurrent applies would corrupt the state.

The version-control discipline for rollback is: every change is a commit, every commit is in a repository, every repository is backed up, and the state file is never committed to Git — it contains plaintext secrets and Git provides no locking — but held in a locked, access-controlled, versioned remote backend.

sequenceDiagram
    participant R as Repository
    participant CI as CI pipeline
    participant TF as Terraform
    participant Cloud as Cloud provider
    R->>CI: commit hash
    CI->>TF: plan with that commit
    TF->>Cloud: read state
    CI->>TF: apply
    TF->>Cloud: write state
    Cloud->>Cloud: API calls
    Note over R,Cloud: rollback path:\ncheckout prior commit,\nre-apply

Audit and state recovery

The audit requirement for application code is “what version is running?”. The audit requirement for infrastructure code is “what is the global state of the cloud, and how did it get there?”. The difference is the scope: an application is a process; an infrastructure is a set of cloud resources.

The state recovery requirement is also different. An application state is reconstructible from the database and the application itself. An infrastructure state is reconstructible only from the state file, the cloud provider’s API, and the version-control history. If any of these is missing, the recovery is incomplete.

# A state recovery requires three sources
git log --oneline -- state.tf    # the source commits
terraform state pull             # the current state
aws cloudtrail lookup-events     # the cloud-side record

Production discipline

Four rules apply:

1. Branch protection is mandatory. Direct commits to main are not allowed in an IaC repository. Every change arrives through a PR with at least one reviewer and a green CI run.
2. The apply is from CI, never from a laptop. The deploy identity is the only identity that can apply a change to the cloud. Personal credentials are a production hazard.
3. The state lives in a locked, versioned remote backend. The backup exists to recover from proven state corruption or loss — rollback is a reverted commit re-applied against the current state, not a state restore. A state file in a developer’s laptop is irrecoverable when the laptop fails.
4. The plan is reviewed, not just the diff. The HCL diff hides the resource-level effects. The terraform plan output is the artefact that names the affected resources, and the reviewer must read the plan, not the diff.

Cross-course references

• Linux for Production Sysadmins - Part XXXIV (ConfigMgmt) discusses the version-control discipline for system configuration, which is the system-level analogue of IaC.
• Ansible for Production Sysadmins - Parts XXXVII (RepoArch) through XL (PR) cover the IaC-style discipline for Ansible repositories, including the blast-radius argument.
• Terraform for Production Sysadmins - Part IX (State) through Part XXVIII (Audit) cover the state-management and audit-trail disciplines that are specific to Terraform and that depend on the version-control foundation in this lesson.

Quiz