Infrastructure drift is the divergence between what Terraform's state file believes exists and what actually exists in the cloud. Drift accumulates when engineers modify infrastructure outside Terraform — clicking through the AWS console to change a security group rule, using the AWS CLI to add a tag, manually scaling up an RDS instance, or a cloud provider automatically modifying a resource attribute (like Auto Scaling changing desired_capacity or AWS updating an ECS task definition). Every drift event is a governance risk: the change bypasses the code review, audit trail, and approval gates that Terraform provides. Accumulated drift also creates dangerous surprises — the next 'terraform apply' may undo months of manual configuration changes made by other teams, potentially causing outages. Drift detection as a scheduled CI process catches these divergences automatically and triggers remediation before they accumulate into serious operational risk.
Drift detection is distinct from the regular plan-review-apply workflow. In the regular workflow, an engineer makes a deliberate code change and runs plan to see the impact. In drift detection, no code change has been made — the CI job runs 'terraform plan -refresh-only' or a regular plan on a schedule (nightly, weekly) to detect whether the live infrastructure has diverged from the configuration. The output is not a deployment plan but a drift report: a list of resources whose actual state no longer matches the Terraform configuration. The drift report is then triaged: some drift is expected (Auto Scaling desired_capacity changes should be in ignore_changes), some is an operational mistake to be fixed (someone manually added an inbound SSH rule to a production security group), and some is a security incident (an IAM policy was modified to add admin permissions outside the change management process).