Terraform drift appears when real infrastructure no longer matches the configuration and state assumptions used by the Terraform workflow. The cause may be a manual console edit, an emergency change, another automation system, a service-side default, or an external controller. The important point is not that someone \u201cbroke Terraform.\u201d It is that the declared system and the observed system have diverged, and the next plan must decide what that divergence means.<\/p>\n
Drift detection is a core operating practice in Terraform engineering<\/a>. Terraform refreshes managed object data during normal planning, while HCP Terraform health assessments can periodically evaluate whether real infrastructure still satisfies the configuration. Those mechanisms surface differences; they do not remove the need for ownership and remediation policy.<\/p>\n The Terraform Associate 004<\/a> objectives include managing resource drift and state, which is appropriate because drift sits at the boundary between declarative intent and operational reality. Engineers need to know whether to overwrite, accept, codify, or investigate each class of deviation.<\/p>\n HashiCorp documentation distinguishes configuration drift from state drift. Configuration drift is a real-world change that makes actual infrastructure differ from what the configuration requires. State drift can involve changes to remote objects that alter recorded state information without necessarily invalidating the intended configuration in the same way.<\/p>\n This distinction matters during remediation. A refresh-only operation can update Terraform state to reflect current remote attributes without changing infrastructure, while a normal plan may propose actions that drive infrastructure back toward configured intent. Operators should understand whether they are reconciling Terraform\u2019s record, correcting the remote system, or changing the configuration to accept a new desired state.<\/p>\n The general lesson from baseline configuration management<\/a> applies: a deviation only becomes meaningful when the organization knows which baseline is authoritative and why.<\/p>\n Terraform plans read current information for managed objects and compare it with configuration and prior state. A plan that proposes an unexpected update, replacement, or deletion may be the first evidence that something changed outside the reviewed workflow.<\/p>\n Teams should therefore review plans for cause, not only for action count. An operator who accepts every plan because \u201cTerraform knows best\u201d can overwrite a legitimate emergency fix or reproduce an unrecognized configuration defect. A plan is a diagnostic artifact that should be interpreted in context.<\/p>\n The configuration drift<\/a> mindset is valuable because it treats unexpected differences as evidence about the control system, not merely as noise to be reset.<\/p>\n HCP Terraform health assessments can run periodic evaluations for eligible workspaces and report configuration drift without applying changes. This is useful because drift can accumulate even when nobody is preparing a normal infrastructure deployment. A quiet workspace still needs assurance that the real environment remains consistent with its declared design.<\/p>\n Health assessment findings should enter an owned operational queue. A dashboard full of acknowledged drift does not improve control. Teams need severity criteria, responsible owners, and a time expectation for deciding whether each finding will be reverted or codified.<\/p>\n That governance layer is similar to cloud governance without overengineering<\/a>: automation should surface material exceptions and route them to a decision rather than generate a larger pile of unactioned alerts.<\/p>\n Not all drift is equal. An emergency firewall rule added during an incident has a different meaning from a console tweak made for convenience. A cloud service may populate a computed field that the provider handles normally, while a human may have changed a critical setting that Terraform should restore immediately.<\/p>\n Create practical categories such as approved emergency change, unauthorized manual change, external-controller change, provider\/API normalization, and configuration defect. The classification helps determine whether to update code, revert infrastructure, change ownership boundaries, or adjust lifecycle behavior.<\/p>\n Security teams already use this reasoning in automation APIs designed for drift and human error<\/a>. Infrastructure teams need the same assumption: other actors will change systems, so control depends on detecting and interpreting those changes.<\/p>\n Terraform lifecycle settings can intentionally ignore selected attribute changes, which is useful when another system legitimately owns those attributes. The risk is using ignore behavior to silence recurring diffs without understanding ownership. That converts visible drift into undocumented shared control.<\/p>\n If an attribute is intentionally managed elsewhere, document that boundary and test whether the external owner and Terraform can coexist safely. If the attribute should belong to Terraform, fix the process causing unauthorized changes instead of suppressing the evidence.<\/p>\n Policy management lessons from designing for drift and human error<\/a> are directly relevant: hidden exceptions become future incidents because operators can no longer distinguish intended flexibility from unmanaged divergence.<\/p>\n When a team chooses to accept real-world drift, the configuration should be updated in a reviewed change that explains why the new value is desired. When it chooses to reject drift, the apply should be linked to the finding or incident that justified reverting the remote system. Either path preserves an audit trail.<\/p>\n Emergency changes deserve special attention. They may need to happen outside Terraform for speed, but the follow-up should bring the final decision back into code. Otherwise the next routine apply may silently undo the incident response or preserve a temporary exception indefinitely.<\/p>\n Version control is valuable because it lets the organization connect infrastructure intent to a specific review and decision rather than treating the latest state of the cloud console as historical truth.<\/p>\n Large states can make drift review harder because unrelated components appear in the same plan. Splitting configurations by lifecycle and ownership can reduce the blast radius of remediation and make it clearer which team is responsible for a finding.<\/p>\n The boundary should not be created solely to reduce drift volume, but drift is a useful signal that a state may contain resources with different authorities. If one team intentionally changes networking outside Terraform while another expects full Terraform control over application infrastructure, placing both in one state can create persistent ambiguity.<\/p>\nConfiguration drift and state drift are related but not identical<\/h3>\n
Normal plans are the first line of drift visibility<\/h3>\n
HCP health assessments add periodic drift checks<\/h3>\n
Classify drift by cause before choosing remediation<\/h3>\n
Do not use ignore rules to make meaningful drift invisible<\/h3>\n
Drift remediation should preserve the reason behind the change<\/h3>\n
State boundaries influence how much drift one assessment must reason about<\/h3>\n