Infrastructure as code turns desired cloud configuration into versioned, reviewable input for an automation tool. Its central benefit is not that HCL or YAML is inherently safe. The benefit is a controlled change process: a proposal can be validated, planned, discussed, applied by a constrained identity, and connected to evidence. An unchecked automated apply can make mistakes faster than a console user.
Organize ownership around lifecycle and blast radius. A network foundation, production database, and application service should not share one enormous state merely because they use the same provider. Smaller roots reduce lock contention and limit accidental plans, while too many tiny states create dependency and discovery overhead. Export narrow outputs and pass stable identifiers explicitly.
terraform {
required_version = "~> 1.9"
required_providers {
google = { source = "hashicorp/google", version = "~> 6.0" }
}
backend "gcs" { bucket = "company-terraform-state" }
}
resource "google_storage_bucket" "receipts" {
name = "company-receipts-prod"
location = "US"
uniform_bucket_level_access = true
public_access_prevention = "enforced"
lifecycle_rule {
condition { age = 365 }
action { type = "SetStorageClass" storage_class = "ARCHIVE" }
}
}This root constrains tool and provider versions, keeps state remote, and declares access and lifecycle behavior beside the bucket. The example version ranges are illustrative; a real repository should choose and update versions through its tested dependency process.
State maps declared resource addresses to remote objects and can contain sensitive values. Encrypt it, version it, lock it, restrict access, and test restoration. Do not edit state casually. Import existing resources deliberately, review the first plan, and add lifecycle protections only when their operational consequence is understood.
A plan is a point-in-time proposal, not timeless approval. Apply the reviewed saved plan from the same commit and provider lockfile, soon after creation, with serialized access. Cloud-side policy or concurrent changes can still intervene.
Plan, review, apply
1. Define module contracts
Give modules typed inputs, documented outputs, safe defaults, examples, and a narrow purpose instead of wrapping every provider option. For Define module contracts, establish planned creates, updates, replacements, and destroys as the primary evidence and publish its expected range before rollout. During a controlled exercise, interrupt apply after one resource succeeds; compare the resulting customer-visible behavior with the written promise. Review cloud resources added by the plan during capacity and budgeting work, because a technically successful control can still be economically wrong. The acceptance record should name an owner, preserve the observation, and state when the decision must be revisited.
2. Pin and update providers
Commit dependency locks and use automated review requests for upgrades, including plan evidence and release-note inspection. Pin and update providers should be reviewed through state-lock wait and drift findings, not through a screenshot of one successful run. Rehearse the boundary by choosing a safe environment and then restore an earlier remote-state version in isolation. Document containment and recovery in the same language operators see during an alert. Include remote state, policy, and runner services in the trade-off, and retain enough evidence to show whether the observed result came from the design or an unrelated dependency.
3. Protect remote state
Enable encryption, versioning, locking, least privilege, audit logs, and a tested restore procedure for every backend. Turn Protect remote state into a falsifiable operating claim. Instrument policy failures and module-test results, define failure before running the test, and introduce a console change between plan and apply. A reviewer should be able to connect the signal to one business consequence and one recovery action without private team knowledge. Account for review time for generated changes; otherwise the architecture may shift expense into support, response labor, or another service while appearing inexpensive on its own dashboard.
4. Separate planning from applying
Generate a saved plan from an immutable commit, review destructive actions, and apply that artifact with a controlled identity. The verification plan for Separate planning from applying begins with forecast cost delta and apply duration measured across ordinary and peak traffic. Next, propose replacement of a data-bearing resource and inspect both the immediate symptom and the state left after recovery. Keep the runbook specific about authority, evidence, and rollback. Re-estimate recovery effort from oversized state boundaries when volume, regions, or ownership change, because limits selected for the first deployment rarely remain neutral as the system grows.
Drift, recovery, and governance
- Require policy checks: Block public exposure, forbidden regions, missing encryption, excessive privilege, and absent ownership metadata before cloud mutation. Treat planned creates, updates, replacements, and destroys as the release gate for Require policy checks, with thresholds derived from the user journey rather than a vendor default. Prove degraded behavior when you interrupt apply after one resource succeeds, including what an operator can see before customers report it. The design review must compare cloud resources added by the plan with the consequence of a missed or delayed operation. Record exceptions explicitly so emergency action does not silently become permanent configuration.
- Keep secrets out of code: Reference secret-manager objects and protect sensitive outputs because marking a value sensitive only hides display, not state storage. A production acceptance test for Keep secrets out of code should capture state-lock wait and drift findings before, during, and after recovery. In the fault phase, restore an earlier remote-state version in isolation; in the review phase, reconcile durable state rather than stopping when the process turns green. Model remote state, policy, and runner services at current load and forecast peak. This makes the decision reversible: later teams can see why the limit existed and what evidence would support changing it.
- Detect drift safely: Schedule read-only plans, classify expected provider normalization separately, and investigate meaningful out-of-band changes before overwriting them. Use Detect drift safely to connect implementation detail with operations. Dashboard policy failures and module-test results, but keep the underlying event or state available for investigation. Then introduce a console change between plan and apply in a bounded drill and have someone outside the implementing team follow the runbook. Compare the resulting risk reduction with review time for generated changes. Passing means the system behaves predictably and the responder can explain why, not simply that an automated check returned success.
- Control destructive replacement: Review force-new changes, dependency order, retention, snapshots, and create-before-destroy capacity for data-bearing or named resources. Before approving Control destructive replacement, ask which assumption is most likely to expire. Baseline forecast cost delta and apply duration, then propose replacement of a data-bearing resource without changing several variables at once. Capture timelines and identifiers needed to reconstruct the event. Budget explicitly for recovery effort from oversized state boundaries, including human ownership that provider calculators omit. Schedule review after material traffic, dependency, or policy changes so the control remains aligned with its original business purpose.
- Test modules and environments: Run formatting, validation, static policy, unit assertions, and disposable integration applies before promotion to a critical account. Operational evidence for Test modules and environments comes from planned creates, updates, replacements, and destroys correlated with a representative transaction or workflow. Validate it when you interrupt apply after one resource succeeds, checking partial success and delayed recovery rather than only total outage. Discuss cloud resources added by the plan with product and finance owners where the consequence is material. The final runbook should state the safe manual action and the conditions under which automation must stop and request judgment.
- Handle emergency changes: Allow a logged break-glass path, then import or reconcile the change promptly so declared and actual infrastructure agree. For Handle emergency changes, separate prevention from detection. Use state-lock wait and drift findings to discover drift from the intended behavior, and restore an earlier remote-state version in isolation to prove containment. Recovery should preserve auditability and avoid converting one failure into duplicates, data loss, or uncontrolled load. Compare that protection against remote state, policy, and runner services. A concise decision record should link configuration, test evidence, dashboard, and accountable owner so the control survives staff rotation.
- Estimate resource cost: Attach cost deltas to plans while reviewing egress, logs, backups, minimum capacity, and support tiers that simple estimates may omit. Estimate resource cost is ready only when policy failures and module-test results can be interpreted by the on-call engineer without reverse-engineering implementation internals. Run a game day in which you introduce a console change between plan and apply, and require an explanation of impact, state, and next action. Track review time for generated changes separately from normal application spend so reliability overhead remains visible. If the drill needs privileged improvisation, improve the interface or runbook before increasing automation.
- Practice state recovery: Restore a copied backend, refresh against an isolated test target, and document ownership before a real corruption or deletion event. Close the Practice state recovery review with a recovery proof. Observe forecast cost delta and apply duration, propose replacement of a data-bearing resource, and verify the final business records against their authority. Report recovery effort from oversized state boundaries beside latency and correctness rather than after the architecture is committed. Keep an explicit exit condition: if evidence, platform capability, or economics change, the team should be able to simplify or replace this mechanism without losing the contract it protects.
Terraform language and state sources
The Terraform language documentation defines the platform or specification behavior used in this design. The Terraform state documentation provides a second primary reference for implementation limits and operating guidance. These sources support the guarantees described here; product policy and risk decisions remain specific to the organization.
A compact operating model
source change -> validate + policy -> saved plan -> approval -> controlled apply -> drift checkThe saved plan is the reviewed mutation proposal. A restricted apply identity executes it, and later drift checks reveal changes made outside that declared path.
