Concept and mechanism
A plan shows proposed differences between configuration and observed objects in the context of a backend, workspace, providers, and inputs. It is more than a final count. Inspect actual resources, actions, dependencies, replacements, and values still unknown. A -/+ action represents destruction followed by creation; a change appearing small in code may require replacement under provider rules. A no-change plan also does not establish functional health or absence of problems outside managed scope. Use validate for internal consistency and plan for contextual decisions. A failed check may produce only a warning; do not treat it as a mandatory gate without understanding the chosen mechanism.
Guided application
In an original exercise, the summary shows four additions, two changes, and one destruction. The team must inspect whether destruction belongs to replacement, which data or clients are affected, and what validation follows. When saving a plan for later application, retain the link between artifact, revision, environment, and approval. Generating another plan after review may change the action set. Passing a saved plan to apply is interpreted by the command as approval, so pipeline authorization must happen first. With detailed-exitcode, two means success with proposed changes; one means error. Automation must preserve that distinction rather than turn every nonzero result into blind execution or an undifferentiated failure.
Exit code 2 from plan with detailed-exitcode requires change review rather than establishing an error.
Common pitfalls
Summary as sufficient analysis; new plan as approved artifact; check as automatic blocking.
Related topics: Configuration and dependencies · State and collaboration · Modules and identity
Approve identified actions in the context and artifact actually reviewed.
Reference: Plan modes artifacts and detailed exit codes · Terraform v1.16 concepts; official documentation consulted 2026-09-30; provider and backend capabilities must be confirmed