State, locking, and drift | Terraform Associate: infrastructure as code

Concept and mechanism

State relates configuration to real objects and may contain sensitive values. The backend defines storage and capabilities, which must be confirmed for the chosen option. Locking, when supported, protects concurrent operations against one state; different branches do not automatically create isolation. Force-unlock is not the routine response to contention: establish that the owning operation is no longer active. Drift describes a difference that must be interpreted against current intent. Refresh-only updates observed records without automatically correcting desired configuration.

Guided application

After an incident intervention, compare the remote object, code, and temporary authorization. Decide whether the change should be reverted or incorporated through the change process. Updating only state does not prevent the next plan from proposing the code value again. To refactor addresses without recreating objects, use a compatible moved block and review the plan. Retain migration evidence and confirm that each object keeps a coherent management binding.

IN PRACTICE

A rule opened during L3 support restores service. The next plan should be reviewed with the owner before automatically restoring the previous rule.

Common pitfalls

Treating every lock as orphaned; confusing refresh-only with code updates.

Related topics: Import, inspection, and diagnosis · HCP Terraform and collaboration

Take this idea with you

Preserving state requires coordination, protection, and explicit drift decisions.

Create account

Reference: State locking · 004