Table of Contents
Somewhere in your environment right now, terraform plan is probably not clean. Not because anyone made a mistake, but because a change happened outside Terraform weeks or months ago, got flagged, and then sat there. Nobody’s fault, technically. Everybody’s problem, eventually.
That’s the pattern I keep running into across platform teams: detection isn’t the hard part anymore. Most teams I work with already have a drift detection pipeline running on a schedule, flagging changes, sending an alert somewhere. I’ve written before about how to build that pipeline in Azure DevOps — the -detailed-exitcode flag, the scheduled runs, the Teams and email notifications. If you haven’t got that in place yet, start there. This post picks up after it.
Because having a pipeline that finds drift and having a team that fixes it are two completely different problems, and I’ve seen plenty of platforms with the first and not the second. In this post we will look into the areas of terraform drift ownership.
Detection Without Ownership Is Just Noise
Here’s what actually happens on a lot of teams. The drift detection pipeline fires. It posts to a Teams channel. Someone sees it, maybe even opens the plan output, and thinks “I’ll come back to that.” Then a sprint ends, priorities shift, and the alert scrolls off the top of the channel.
Three months later the same drift shows up again, except now there are two more changes layered on top of it, and the person who saw the original alert has forgotten it existed.
This is the same failure mode I keep coming back to across this series: platforms don’t fail because the tooling is missing, they fail because nobody decided who’s accountable when the tooling does its job. A drift alert with no owner is just noise with good intentions behind it.
Who Owns a Piece of Drift?
The honest answer on most teams is nobody, by default. Ownership needs to be assigned, not assumed, and it needs to happen before drift shows up, not in the scramble after.
A few ways I’ve seen this work in practice:
Module or resource group owners. If every Terraform module or resource group has a named owner (a person or a team, tracked somewhere visible, not just tribal knowledge), drift in that module has an obvious first point of contact. This only works if the ownership list is actually maintained, which means it needs to live somewhere people update as part of normal change, not a spreadsheet nobody opens.
The platform team as backstop, not first responder. I don’t think it scales for the platform team to personally investigate every piece of drift across every workload. Their role is closer to: make sure every alert has an owner, escalate when it doesn’t, and step in when the assigned owner doesn’t act within an agreed window.
Drift as a tracked work item, not a notification. A message in a channel is easy to lose. A ticket assigned to a person, with a due date, is much harder to quietly ignore. This is a small process change but it’s the difference between drift being visible and drift being actioned.
A Response Process, Not Just a Response Channel
Once ownership is assigned, the team still needs to know what to actually do with a piece of flagged drift. I break it into three outcomes:
Accept it. Sometimes the drift is legitimate. Someone made an emergency change outside the pipeline for a good reason, or a portal-based change is genuinely fine to keep. In this case, update the Terraform configuration to match reality and get it back under management. Don’t leave it flagged forever, that just trains people to ignore the alert.
Remediate it. The change was a mistake, or it violates a standard, and the fix is to run terraform apply and put the resource back the way it’s meant to be. This is the straightforward case and usually the fastest to close out.
Investigate it. The drift doesn’t obviously fall into either bucket, maybe it’s unexplained, maybe it looks like it could be a security concern (a firewall rule added manually, an identity granted access outside the normal process). This is where it escalates, and where having a named owner from the start actually matters, because someone needs to chase down what happened and why.
Whichever bucket it lands in, I’d set an SLA. Something like: drift gets triaged within two working days, and closed out (accepted or remediated) within a sprint. It doesn’t need to be aggressive, it needs to exist, because an SLA is what turns “someone will get to it” into “this is due by Friday.”
Closing the Loop So It Doesn’t Reopen
Fixing the current drift is the easy half. Stopping the same gap from reopening is where the governance work actually pays off.
RBAC is the obvious lever. If engineers genuinely can’t make portal changes to production resources, a whole category of drift disappears before it starts. I know this isn’t always realistic, especially during incidents when someone needs to make an emergency change fast. That’s fine, but it needs a defined path: emergency changes are allowed, and they come with a mandatory follow-up to reconcile the Terraform state within a set window, not a hope that someone remembers.
Beyond RBAC, the same ownership model applies. If every module has a named owner, and every piece of drift becomes a tracked item with an SLA, you’ve built a process where accountability doesn’t depend on someone happening to notice and happening to care. That’s really what this whole series has been about: the platforms that stay healthy aren’t the ones with the most tooling, they’re the ones where every decision, every module, and now every alert has someone’s name attached to it.
——-
Detection tells you drift exists. Ownership is what actually closes it out.
Next up, I want to look at what happens once your platform is stable and well-governed but you still can’t answer a simple question fast: is it actually healthy right now? That’s platform observability, coming next.