How can I prevent drift between Terraform state and deployed resources?

[Stephen61]

So I’ve been trying to get my team to adopt infrastructure as code, but honestly, it’s been a bit of a slog. We keep running into this situation where someone makes a manual tweak in the console “just this once,” and then our Terraform plan wants to revert it next time we run it. It feels like we’re constantly reconciling what’s in the code with what’s actually deployed. I’m starting to wonder if we’re even doing this right, or if this drift is just a normal part of the process that everyone quietly deals with.

[Nathan_M]

I hear you. infrastructure as code sounds great until someone nudges the console and says just this once, and suddenly the plan wants to roll back what’s live. The friction is real, and it can feel like you’re chasing a moving target. Do you have a policy that blocks manual changes in production and routes changes through PRs?

[Jerry_R]

From a systems view drift is a symptom, not a bug. The code is the truth, the running environment is a lived record of who touched what. Tie it to a strict CI gate that runs terraform plan and requires approval when the state would diverge, and surface drift before apply. It won’t fix the psychology overnight, but it changes incentives.

[Lily72]

I’m skeptical that drift alone is the whole story. Sometimes the console tweak is hiding a legitimate tweak the code should absorb. If you keep fighting drift with more plans you might be missing a chance to evolve the IaC as your architecture evolves.

[Richard2]

Framing shift: maybe the goal isn’t to erase drift but to manage velocity. Reframe as capturing every change in code first, and treat experiments as code changes rather than quick hits in the console. That reframing can reduce the sense of firefighting.

[Stella_W]

On the craft side, write like you are documenting a playbook. Clear module boundaries, readable variable names, and commit messages that explain why this change exists. infrastructure as code becomes a living contract instead of a pile of one offs.

[Madison52]

Start small and build guards around one service. Pair on changes, enforce a PR only policy, and run drift checks in CI. Would a tiny pilot help you see a path forward?