Configuration drift
Last updated 2026-06-04
Configuration drift happens when a running cloud or Kubernetes environment diverges from the infrastructure-as-code that is supposed to define it, usually because someone changed the live system directly instead of through code. Common causes include manual console edits, emergency hotfixes, auto-scaling actions, and changes made by other automation. Drift makes infrastructure unpredictable and hard to audit, and the next code deploy can silently revert the change or fail outright when the recorded state and reality disagree. For example, a security group rule added by hand to unblock an incident vanishes the moment the pipeline reapplies the committed template. Teams detect drift by running a plan or diff that compares declared state against live resources, then reconcile by either updating the code or restoring the resource. Cost tools that apply optimizations directly to live resources, through an agent or a console, can introduce drift. LevelFour avoids it by delivering every change as a pull request, keeping Git the source of truth.
Frequently asked questions
- What causes configuration drift?
- Configuration drift is caused by changes made to live infrastructure outside the infrastructure-as-code workflow. Typical sources include manual edits in a cloud console, emergency hotfixes during incidents, auto-scaling and other platform automation, and third-party tools that modify resources directly instead of through committed code.
- How do you detect and fix configuration drift?
- You detect drift by running a plan or diff that compares the declared infrastructure-as-code state against live resources and flags any differences. You fix it by reconciling the two: either update the code to capture the intended change, or reapply the code to restore the resource to its defined state.
LevelFour automates this across AWS, GCP, Azure, and Kubernetes with automated infrastructure-as-code pull requests.