A Terraform plan can show that a remote resource differs from Terraform’s records or configuration, but the diff alone cannot tell you whether the change is intentional, safe to keep, or even observed in the right account and region. First confirm what Terraform is looking at; then decide whether to bring configuration in line with the change or restore the configured value.
What Terraform means by drift
Terraform makes decisions using three views: your written configuration, Terraform’s prior state, and the provider’s current observations of remote objects. State is Terraform’s record of the resources it manages. It is neither a statement of desired values nor a guarantee that a remote object still matches those values.
HashiCorp distinguishes two useful cases. Configuration drift means a remote change conflicts with the intent expressed in configuration. State drift means the remote object changed but the configuration does not conflict with that change. The distinction matters: a difference that contradicts your declared intent may call for restoration, while an accepted change that configuration permits may call for updating state and recording the new intent declaratively. A refresh difference is evidence to investigate, not a verdict.
How to inspect a suspected change safely
Start with a normal plan
A normal terraform plan refreshes its observations of remote resources in memory before calculating proposed actions. terraform apply also refreshes as part of planning. Review the plan for what Terraform proposes to change, remove, or replace; do not treat the word “drift” as permission to apply.
Recommended Free Tools
#1 Best Overall
Use refresh-only mode to review state updates
- Run
terraform plan -refresh-onlyto review which state values Terraform would update based on its observations. This is a plan for inspection; it does not itself modify remote infrastructure or commit those state changes. - Check that the provider configuration, credentials, account, region, and target objects are the ones you intended to inspect. A refresh-only diff shows what Terraform observed, not whether the change was authorized or whether Terraform queried the correct scope.
- If the observations are valid and you want Terraform to record them, run
terraform apply -refresh-onlyand approve the proposed state update. This updates state without changing the remote objects. - Run a normal
terraform planafterward to see whether configuration and the observed infrastructure now agree, or whether Terraform still proposes infrastructure changes.
HashiCorp’s resource-drift tutorial explains that a refresh-only operation does not attempt to make infrastructure match configuration; it lets you review and track drift in the state file. That separation is useful when an emergency change is intentional: record what exists first, then update configuration so the accepted value is represented as desired state.
Check provider scope before accepting apparent deletion
An object that appears absent may be outside Terraform’s configured provider scope rather than actually deleted. In HashiCorp’s provider-region example, changing the configured AWS region makes an EC2 instance unavailable to that provider configuration, and Terraform proposes removing it from state. Before accepting a removal or a broad set of changes, verify the provider’s region and credentials, along with the account and object you expect it to manage.
The terraform refresh command is deprecated. HashiCorp warns that it applies refresh behavior automatically and that bad credentials or provider configuration can make tracked resources appear deleted and lead to their removal from state. Prefer the reviewable refresh-only plan and make an explicit decision before applying it. Avoid routine -target use as a drift-management strategy: HashiCorp warns that targeting can leave drift undetected and make resource relationships harder to understand.
Decide whether to keep or revert the change
For a consequential edit, identify who made it and why before choosing a remediation. A plan describes proposed actions; it does not establish that the change was authorized or that the proposed action is safe.
Rank #3
| Decision | When it fits | What to do | Risk to review |
|---|---|---|---|
| Keep the outside change | The change is intentional, authorized, and should become the new desired behavior. | Update configuration or its variable inputs to represent the accepted value. Review and apply a refresh-only plan to record the observed values in state, then use a normal plan to check convergence. | Configuration must capture the accepted intent; otherwise a later normal plan may propose changing the resource back. Inspect any proposed in-place change, replacement, or removal. |
| Revert the outside change | The edit was accidental, unauthorized, or conflicts with policy and the declared configuration. | Run a normal plan and inspect the actions Terraform proposes to bring infrastructure toward configuration. Apply only after you understand and approve those actions. | Restoration can have a wider impact than the original edit. Check for destructive actions or replacement, and assess the effect on dependent resources. |
HashiCorp’s plan command documentation describes plans as proposed actions: the normal plan/apply path is what changes infrastructure toward configuration, whereas a refresh-only apply records observations in state without modifying remote resources. If the plan contains a replacement or removal, consider its operational impact and blast radius before approving it.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Manual review and HCP Terraform assessments
Manual CLI review and HCP Terraform health assessments differ in where and how they run, and in what an operator can do with the result.
| Aspect | Manual Terraform CLI | HCP Terraform health assessment |
|---|---|---|
| Timing | Run a plan when you choose to inspect a workspace’s resources. | The HashiCorp assessment tutorial says assessments run about every 24 hours after enablement and can be rescheduled by a new workspace run. Cadence can change. |
| Execution context | Uses the provider configuration and credentials available to the chosen CLI execution context. | Runs in an HCP Terraform workspace. The tutorial lists Terraform 0.15.4 or later, a prior successful run, and remote or agent execution mode among its prerequisites. |
| Effect of assessment | A refresh-only plan is reviewable; an operator can explicitly apply it to update state. A normal plan proposes infrastructure actions. | Assessments use non-actionable refresh-only plans to compare provider-reported resources with workspace state. They report findings but do not update state or configuration, or automatically remediate resources. |
| Scope and availability | Depends on the provider scope and setup for the CLI run. | Health-detection behavior and availability depend on HCP Terraform edition and current product terms. Check the health documentation for current details. |
HCP Terraform documents drift detection as detecting configuration drift, not state drift. When it reports configuration drift, the documented choices are to plan and apply configured values to overwrite the drift, or change configuration to represent the accepted remote change. An assessment is a useful signal, not a substitute for checking intent, provider scope, and risk before remediation.
Quick Recap
A practical decision checklist
- Confirm scope: Check provider configuration, credentials, account, region, and the specific resources Terraform is observing.
- Classify the difference: Ask whether the remote change conflicts with configuration or is a change configuration permits.
- Establish intent: Identify the owner and reason for an out-of-band edit, especially before accepting consequential changes.
- Choose the right operation: Use refresh-only planning to review state updates; use a normal plan to inspect changes that would bring infrastructure toward configuration.
- Inspect consequences: Read every removal, replacement, or other destructive action and assess its blast radius before applying.
- Close the loop: If keeping the change, represent it in configuration and check the result with a normal plan. If reverting it, apply only the understood and approved normal plan.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →
