# 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.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## 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.

## Sources

- [HashiCorp: managing resource drift](https://developer.hashicorp.com/terraform/tutorials/state/resource-drift)