Terraform's declarative resource model and state file, CloudFormation as the AWS-native alternative, why reading IaC is a lead-level skill even without authoring most of it, and drift detection.
Published September 23, 2026
resource "aws_instance" "web" {
ami = "ami-0abc123"
instance_type = "t3.medium"
tags = { Name = "web-server" }
}
terraform plan # shows WHAT WOULD CHANGE, without applying anything — the critical review step
terraform apply # actually applies the changes
Terraform is DECLARATIVE — you describe the DESIRED end state of infrastructure (a specific EC2 instance should exist, with these properties), not a sequence of imperative steps to get there, and Terraform figures out the actual API calls needed. It tracks a state file — its own record of what it believes currently exists — and computes the diff between that recorded state and the desired configuration on every plan. This state file is critical infrastructure in its own right: if it's lost or gets out of sync with reality, Terraform's diff calculation becomes unreliable, which is why state is typically stored remotely (in S3 with locking, not a local file) for any real team usage.
CloudFormation is AWS's own IaC service — same declarative philosophy as Terraform, but AWS-only (no multi-cloud portability) and natively integrated with AWS's own change-management and rollback tooling (a failed CloudFormation stack update can automatically roll back to the last good state, a built-in safety net Terraform doesn't provide out of the box). Terraform's main advantage is provider-agnostic portability (the same tool manages AWS, GCP, Kubernetes, and dozens of other providers with one consistent workflow); CloudFormation's main advantage is deeper native AWS integration and no separate state-file management burden (AWS manages the state itself).
Infrastructure changes (a new database, a changed security group rule, a scaled-up instance type) increasingly ship as IaC pull requests, reviewed the same way as application code — a lead who can't read a Terraform diff and understand its actual real-world consequence (this change opens a new inbound port; this change replaces, rather than modifies, a resource, which might mean DOWNTIME) is reviewing infrastructure changes blind. This doesn't mean a lead needs to author most day-to-day IaC changes personally — it means genuinely UNDERSTANDING what a proposed change does before approving it, the same review-competency expectation as any other code review (directly connecting to Volunteer for PR Reviews' broader review-ownership theme).
terraform plan # if someone manually changed something in the AWS console,
# Terraform's plan will show a DIFF trying to revert it back
# to match the IaC-defined state — this IS drift
Drift occurs when the ACTUAL infrastructure state diverges from what the IaC configuration declares — most commonly from a manual console change made outside the IaC workflow (someone "just quickly" adjusts a setting directly in the AWS console during an incident, without updating the Terraform code to match). The next terraform plan after drift has occurred will show a diff trying to revert that manual change back to match the (now outdated) declared state — a genuinely dangerous moment if someone runs apply without noticing what that diff actually represents, potentially undoing a legitimate emergency fix. Drift is best prevented by discipline (ALL changes go through IaC, even during incidents, or the IaC is updated to match immediately afterward) rather than caught after the fact.
Q: What's a concrete example of a Terraform change that looks small in the diff but actually causes downtime? A: Changing certain 'immutable' properties of a resource (like an RDS instance's engine version in some configurations, or certain EC2 launch-template properties) forces Terraform to DESTROY and RECREATE the resource rather than update it in place — a diff that looks like a one-line change can actually mean 'delete this database and create a new empty one,' which is exactly the kind of consequence a lead reviewing the plan output needs to be able to recognize before approving.
Q: How does remote state locking prevent a real problem?
A: Without locking, two people running terraform apply concurrently could both read the same stale state and make conflicting changes, corrupting the state file's accuracy — a remote backend with locking (e.g. S3 + DynamoDB for lock coordination) ensures only one apply can run at a time, directly analogous to the mutual-exclusion problem Distributed Lock Service covers generally.
Q: If an incident requires an emergency manual console change, what's the correct process afterward?
A: Update the IaC configuration to match the emergency change as soon as possible after the incident (a 'reconciliation' pull request), specifically to prevent the drift scenario described above from silently reverting the emergency fix on the next routine apply — treating the manual change as temporary and the IaC as the ultimate source of truth that must eventually catch up.
Q: Is there a safer way to review a Terraform plan's DESTROY/CREATE actions before they run?
A: Yes — terraform plan's output explicitly marks each resource action (+ create, - destroy, ~ update in place, or -/+ destroy-and-recreate), and a disciplined review process specifically scans for any - or -/+ on a stateful resource (a database, a volume) as a required manual sign-off point, rather than approving a large diff purely by skimming the overall summary count.