Drift Detection on OCI: Keeping Terraform Honest

Every estate that adopts infrastructure as code makes the same silent promise on day one: the code describes the cloud. For the first few weeks the promise holds, because the code created everything and nothing else has touched it. Then a production incident gets fixed in the console at two in the morning, a security group gets widened by hand to unblock a release, an engineer resizes a compute instance directly because the pipeline was down, and the promise starts to fray. Each individual change is reasonable. The sum of them is an estate where the Terraform repository describes a cloud that no longer exists, where running the pipeline has become dangerous because nobody knows what it will revert, and where the next automation project quietly starts from zero because the code can no longer be trusted.

That decay has a name, drift, and it is one of the most underestimated operational risks on OCI precisely because it produces no alarms, no invoices, and no outages until the day it produces a large one. This article covers where drift comes from, how to detect it with the tools OCI and Terraform already give you, and the decision discipline that turns detection into an estate where the code stays authoritative. It is part of our advanced OCI operations series, and it pairs naturally with the resilience practices in incident runbooks for OCI, because incidents are where most drift is born.

Where drift actually comes from

Drift is usually discussed as if it had one cause, the engineer who clicks instead of coding. In real estates it has several distinct sources, and they need different cures, which is why a blanket policy of blaming console access never works.

The table carries the most important point of the whole topic: only some drift is misbehavior. A failover that an automation tool performed, an attribute OCI computed, or an emergency fix that saved a Saturday are all legitimate. The failure is not that drift happened. The failure is an estate that cannot see it, cannot say which kind it is, and cannot decide what should win, the code or the cloud.

Detection: making the gap visible on a schedule

The core mechanic of drift detection is simple, compare what the state file believes against what the OCI control plane reports, and the primary instrument is the one you already have. A Terraform plan run in refresh mode against production, with no pending code changes, should report nothing to do. Anything it does report is drift by definition. The practice that separates operated estates from hopeful ones is running exactly that check on a schedule, daily or weekly, from automation rather than from a laptop, and publishing the result somewhere a human is obliged to look.

OCI Resource Manager

For estates that run their Terraform through OCI Resource Manager, the platform makes this a managed feature: stacks support drift detection as a native operation, reporting which resources have diverged from the last applied configuration and which attributes changed. That report, triggered on a schedule through the platform's own automation, gives you estate level drift visibility without building anything. The limits are the stack boundary, Resource Manager can only report on resources a stack manages, so unmanaged resources stay invisible, which is why coverage matters as much as detection.

Pipelines and external runners

Estates running Terraform from external pipelines get the same result with a scheduled plan job against each root module, failing the job when the plan is not empty. The detail that matters is granularity: one giant root module produces one giant drift report that nobody reads, while modules split along the compartment boundaries described in compartment design patterns for growing tenancies produce small reports with obvious owners. Drift reporting inherits whatever structure your code has, which is one more argument for structuring it deliberately.

Coverage, the drift you cannot see

The blind spot in both approaches is the resource Terraform never knew about. A compute instance created by hand is not drift to Terraform, it is simply invisible. Closing that gap means periodically comparing what exists in the tenancy, through a resource query or tenancy search, against what the state files collectively manage, and treating the difference as an import backlog. Estates that skip this step report zero drift while half the tenancy lives outside the code.

Reconcile or codify: the decision that makes detection useful

Detection without a decision rule produces a backlog, not an outcome. Every confirmed drift finding has exactly two honest resolutions. Reconcile means the code wins: the manual change was wrong or temporary, and the next apply puts the cloud back to what the code declares. Codify means the cloud wins: the manual change was right, so the code is updated to match it, and the state is refreshed so the two agree again. The wrong answer is the third one most estates silently choose, which is neither, leaving the gap in place and teaching everyone that the report is decoration.

The decision rule does not need to be clever, it needs to be fast. A working default: security relevant drift reconciles unless someone defends it in writing within a day, incident driven drift codifies if the fix is still needed once the dust settles, convenience drift reconciles and triggers a conversation about why the pipeline was avoided, and platform computed drift codifies as a code correction. What turns the rule into practice is the same ingredient as every practice in this series, a named owner and a deadline, because a drift finding with neither is just an interesting fact.

A drift management framework

Prevention: making the right path the easy path

Detection is the safety net, but the estates with the least drift are the ones that generate less of it in the first place, and they do it with structure rather than slogans. Write access to production compartments is narrow, granted to the pipeline identity and a small break glass group rather than to every engineer with a justification from 2024. The pipeline itself is fast enough that using it is not a sacrifice, because most convenience drift is a rational response to a slow or flaky deployment path. Emergency console access exists, is logged, and carries one obligation, that whatever was changed lands in the reconcile queue before the incident is closed, a step that belongs in the incident template alongside the timeline and the actions. And tag defaults mark managed resources, so anything without the marks is visibly an outsider the moment anyone looks.

None of this requires new products. It requires the same operating discipline that runs the patch calendar in a patching strategy that survives audits: a cadence, an owner, and a platform configured so the right behavior is the path of least resistance.

Where drift fits in the operating model

Drift detection is the closing loop of an operating model rather than a standalone tool, which is why it appears as the final step of the build sequence in the operations pillar. Every other practice quietly depends on it. Capacity decisions made from code that no longer matches reality are wrong on arrival. A runbook that points at infrastructure the console has since reshaped fails at the worst moment. An audit that samples the estate against its documented configuration finds the gap whether or not you did. The maturity question in an operations maturity model for OCI estates is blunt and worth asking now: does the code that defines each resource match what is actually running, and how do you know.

The staffing reality is the usual one. A scheduled drift check takes an afternoon to set up; the weekly reconciliation habit, the import backlog, and the quarterly trend review are the parts that lapse when the team is stretched, and they are exactly the parts that deliver the value. This is the category of standing work our OCI managed services practice carries on a managed monthly retainer, the watch, the reconcile queue, and the reviews, built on 500+ OCI engagements, so the code keeps describing the cloud long after the project that wrote it has disbanded.

Terraform honesty is not a state you reach, it is a gap you keep small. The estates that manage it share nothing exotic: detection on a schedule, two honest resolutions, owners with deadlines, and a platform that makes the console the exception rather than the habit. Everything else is commentary.