Free — no signup required

Drift Detection: Reality vs. Code

2 min read

When Reality Deviates

Configuration drift occurs when the actual state of your infrastructure diverges from what your Terraform code describes. This happens because the real world doesn't always go through Terraform.

Common causes of drift:
- A sysadmin manually opens a firewall port in the AWS console during an incident and forgets to close it.
- An auto-scaling group replaces an EC2 instance with a slightly different configuration.
- A cloud provider automatically modifies a resource (e.g., AWS updates a managed policy).
- A developer uses the CLI to quickly test something and never cleans it up.

Drift is dangerous because it means your code no longer accurately describes your infrastructure. The next terraform apply might undo the manual change — including the emergency fix that's keeping production alive.

How Terraform Detects Drift

Terraform detects drift during the refresh phase of terraform plan. Before computing a diff, Terraform calls the cloud provider's API to get the current state of every resource in the state file, then compares that against both the state file and your code.

If the real resource differs from the state file, Terraform updates the state file to reflect reality, then shows you the diff between reality and your code.

Automating Detection with Scheduled Plans

Drift only surfaces when you run Terraform. In a busy environment where apply only runs when code changes, drift can go undetected for weeks.

The solution is a scheduled drift detection job — a CI/CD pipeline that runs terraform plan on a schedule (e.g., nightly) and alerts the team if drift is found. The mechanism that makes this automatable is a plan flag that turns the exit code itself into a meaningful signal: 0 means no changes (infrastructure matches code), 1 means an error occurred, and 2 specifically means changes were detected — drift exists. A scheduled pipeline can branch on that distinction directly: exit code 2 triggers an alert (a Slack notification, typically), while 0 and 1 are handled differently.
```

Key Point: Drift detection tells you that drift exists, but it doesn't tell you whether the drift is intentional or accidental. A mature drift response process includes a human review step: "Is this change something we want to keep (and therefore codify in Terraform), or something we want to revert?" Automatically running terraform apply to fix drift without human review is dangerous — you might undo an emergency fix that's keeping production running.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free