Infrastructure Drift: When Reality and Code Diverge
Infrastructure drift is when live systems no longer match their configuration code. This happens when someone manually changes a cloud resource instead of updating the Terraform file. The footgun: your next terraform apply may destroy your manual changes.
Why it exists
Infrastructure as Code (IaC) promises a single source of truth for your systems. But reality is messy. Teams sometimes need to make urgent manual changes, or a forgotten process modifies a resource outside the IaC tool. Drift is the inevitable gap that opens between the code's intent and the infrastructure's actual state.
The mental model
Think of your Terraform state file as the blueprint for a building and your live infrastructure as the building itself. Infrastructure drift is like a contractor making an unapproved change on-site—moving a wall or adding a window. The blueprint is now wrong. The next time you try to build from that blueprint, the tool will try to tear down the new wall to match the old plan.
How it works
An IaC tool like Terraform maintains a state file, a record of all resources it manages. When you run a command like terraform plan, the tool queries the cloud provider to check the current status of these resources. If the actual properties (e.g., an EC2 instance's tags) differ from what the state file expects based on your code, drift has occurred. Terraform will then propose a plan to change the live infrastructure to match your code, not the other way around.
When to use it
You should regularly check for drift as part of your operational hygiene, especially before any major infrastructure change, to avoid surprises. Many teams run scheduled, read-only terraform plan jobs to generate drift reports. This is critical in environments where manual changes are possible, such as for an emergency security patch.
When not to use it
The primary footgun is ignoring drift. If a plan shows unexpected changes, don't blindly apply it; investigate the cause. Another anti-pattern is to "fix" drift by manually editing the state file. The correct fix is almost always to update your Terraform configuration code to reflect the desired change and then apply it. Don't let manual changes become the new source of truth.
One canonical example
A developer uses Terraform to deploy an EC2 instance with a security group allowing SSH on port 22. Later, an admin manually uses the AWS CLI to add a rule for web traffic on port 80. The infrastructure has now drifted. The next time the developer runs terraform apply, Terraform will see the extra port 80 rule, compare it to the code which only specifies port 22, and generate a plan to remove the port 80 rule, potentially causing an outage.
Interview question
When infrastructure drift occurs in a Terraform-managed environment, what is the primary risk during the next terraform apply operation?
- a.Manual changes made to resources will be overwritten, potentially causing unexpected service behavior or outages.Correct
- b.Terraform will automatically update the configuration code to incorporate the manual changes.
- c.The Terraform state file will become permanently corrupted, necessitating a complete infrastructure rebuild.
- d.The terraform apply command will fail outright, preventing any further infrastructure modifications.
Why? this is the answer
The card explicitly states the "footgun" of drift is that a subsequent "terraform apply may destroy your manual changes," which can lead to service disruptions. Terraform's purpose is to enforce the desired state defined in code, not to automatically adapt its code to unapproved manual changes.
Just read this? Test yourself on what you have been reading.
Read the original → developer.hashicorp.com
- #iac
- #terraform
- #devops
- #automation
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on iac — each one lists the topics its interview covers.
See open roles