How does Terraform detect drift?

Running `terraform plan` (or an equivalent refresh) compares the resource state recorded in Terraform's state file against the actual live configuration in the cloud provider, and reports any differences it finds before proposing an apply.

Is all infrastructure drift bad?

Drift itself isn't inherently malicious, but it's always a signal that the codebase and reality have diverged, which is risky regardless of intent. Even a well-intentioned emergency fix needs to be codified back into IaC promptly, or it risks being silently reverted or causing confusion later.

How can teams prevent drift in the first place?

Common approaches include restricting direct console/CLI write access to production environments, enforcing that all changes go through code review and an IaC pipeline (a GitOps-style workflow), and setting up automated drift-detection alerts to catch any deviations quickly.

What's the difference between drift and a failed deployment?

A failed deployment means an IaC apply didn't complete as intended, often leaving resources in a partially-updated state, but it originates from within the IaC workflow itself. Drift specifically refers to divergence caused by changes made outside that workflow after a successful, consistent deployment.

DevOps

Infrastructure Drift

Q: What happens if I run `terraform apply` when drift exists?

Terraform will attempt to reconcile the live state back to match the declared configuration, which may mean reverting a manual change — potentially undoing an intentional emergency fix — or, in some cases, destroying and recreating a resource if the drift is incompatible with an in-place update.

IntermediateConcept1.4K learners

Infrastructure drift occurs when the actual, live state of cloud or infrastructure resources diverges from the state defined in Infrastructure as Code (IaC) configuration — typically because of manual changes made outside the IaC workflow…

#InfrastructureDrift #DevOps#Concept#Intermediate#PolicyAsCode #GoldenImage #OpenPolicyAgent #ObservabilityPipeline #SoftwareDelivery#Glossary#SkillVeris

Definition

Overview

Infrastructure as Code tools like Terraform, Pulumi, and CloudFormation work on the premise that a declarative configuration file is the single source of truth for infrastructure state, and that applying that configuration is the only way changes should happen. Drift breaks that premise: it happens whenever someone (or some automated process) modifies a resource directly — clicking a change in the cloud console during an incident, running an imperative CLI command to quickly fix something, or another automation tool touching the same resources — without updating the IaC configuration to match. Over time, drift accumulates silently, and the codebase increasingly diverges from reality. Drift is dangerous for several reasons. It undermines the core value proposition of IaC — reproducibility and auditability — because the code no longer accurately describes what's deployed. It creates surprises during the next `terraform apply` or equivalent: the tool detects the live state doesn't match its records and may attempt to 'correct' the drift by reverting the manual change, potentially undoing an intentional emergency fix, or in worse cases, destroying and recreating a resource that had been manually altered in an incompatible way. It also erodes trust in the IaC pipeline, since manual changes made outside of it aren't reviewed, tested, or recorded in version control, making root-cause analysis during incidents harder. Detecting and managing drift is now a standard part of infrastructure operations tooling: Terraform's `plan` command surfaces drift by comparing live state against the state file before any apply; drift-detection services (like AWS Config or dedicated third-party tools) continuously monitor resources and alert when live configuration deviates from expected baselines; and organizational policy typically mandates that all infrastructure changes go through the IaC pipeline, with console/CLI access to production restricted or audited specifically to prevent drift from being introduced in the first place. Remediation options when drift is found include importing the manual change back into IaC configuration (codifying it as the new desired state) or reverting the live resource back to match the code, depending on whether the manual change was intentional and should be preserved.

Key Concepts

Divergence between IaC-declared configuration and the actual live state of resources
Typically caused by manual console/CLI changes made outside the IaC workflow
Detected by comparing live resource state against the IaC state file (e.g. `terraform plan`)
Risks unintended reversion or destructive recreation of manually-modified resources
Erodes reproducibility, auditability, and trust in the infrastructure codebase
Mitigated by drift-detection tooling (AWS Config, Terraform Cloud drift detection, etc.)
Organizational policy typically restricts direct production console/CLI access to prevent drift
Remediated either by codifying the manual change into IaC or reverting the resource to match code

Use Cases

Auditing production infrastructure to confirm it matches version-controlled IaC configuration

Investigating unexpected `terraform plan` output showing unplanned resource changes

Setting up continuous drift-detection alerts for compliance-sensitive environments

Reconciling emergency manual fixes made during an incident back into IaC after the fact

Enforcing policy that restricts direct console access to reduce drift risk

Root-causing incidents where live behavior didn't match what the codebase suggested

Frequently Asked Questions

From the Blog

Cloud & Cybersecurity

Infrastructure as Code Explained: Terraform Basics

Clicking through cloud consoles doesn't scale. Infrastructure as Code (IaC) lets you define, version, and automate your cloud resources in code. This guide explains IaC concepts and walks you through Terraform — the most widely used IaC tool.

Terraform Basics: Infrastructure as Code on AWS

Terraform lets you define cloud infrastructure in code, version it in Git, and deploy it repeatably. This guide covers providers, resources, variables, outputs, state management, and real AWS examples — from a simple S3 bucket to a complete web server setup.