Infrastructure drift control
Read the replacement actions before approving an infrastructure plan
A small configuration edit can replace a stateful resource. Review the proposed lifecycle effect and its data consequences, not only the changed line of code.
In this article
Identify every destructive transition
Inspect resources marked for replacement or deletion and determine why the provider requires that action. Include dependent resources that may also change.
A renamed variable or altered immutable property can have a much larger effect than the source diff suggests. Use the generated plan for the exact provider and configuration.
Do not approve an unexpected replacement because the rest of the plan looks routine.
Check what must survive
For stateful resources, identify data, addresses, identifiers and external references that must remain usable. Determine how the proposed action preserves or migrates them.
A new empty database with the same configuration is not an equivalent service. Likewise, replacing a network endpoint can break an external allowlist or callback even when internal health checks pass.
Require a tested recovery or migration path appropriate to the change.
Examine drift and plan freshness
Confirm that the plan reflects current live state and the reviewed code. Look for emergency changes that the proposed apply would undo.
If the environment changes after review, reassess the plan under the delivery system's safeguards. An approval should not silently cover a different set of actions.
Check ignored fields and external controllers so a seemingly stable plan does not hide unresolved ownership conflicts.
Verify the resulting service
Define post-apply checks before execution. Include the business workflow and external dependencies affected by replacement, not only infrastructure creation status.
Record any interruption and the condition that triggers recovery. A successful provider operation can still leave the application unable to connect or read its data.
The review is complete when the team understands the lifecycle action, its preservation requirements and the evidence needed afterwards. Treating the plan as a formality removes the last practical opportunity to catch a destructive interpretation of a small code change.
Primary sources
HashiCorp: managing resource driftReferences checked 11 September 2026.