Target and dependency closure
The example declares source, consumer and independent. Consumer uses source’s output; independent does not participate in that relationship. Planning with a target on consumer includes source and consumer. A warning identifies targeting. The intervention is not limited to the name supplied by the operator because it must include dependencies. Before authorizing a similar operation, inspect every address and action actually present in the plan. In the fictional support situation, a request mentioning one application does not establish that only that application will be affected. Document the necessary components and the reason for exceptional selection.
Local success with work remaining
Saved-plan apply for the limited plan finishes with code 0 and a warning of possible incompleteness. State contains source and consumer. The script then generates a plan without targeting: independent still needs creation. This sequence separates success of the selected operation from convergence of the whole configuration. During an incident, keep omitted work visible and assign its review. Documentation reserves targeting for exceptional situations; it should not be the usual mechanism for hiding persistent differences. For teams with independent operational boundaries, evaluate deliberately separated configurations and dependency contracts.
Values not yet available in the plan
The exercise’s terraform_data resource receives known input, but its output remains unknown until initial application. In plan JSON, after omits output while after_unknown marks output as true. A consumer reading only after can confuse pending information with definitive absence. Combining the structures preserves this distinction. When a rule depends on a value still unknown, record the pending decision and the point at which sufficient evidence will become available. Do not invent an empty value to obtain a favorable result. The local observation also does not measure when a remote service will actually be ready.
Sensitivity and artifact exposure
The workshop uses an explicitly fictional marker containing no credentials in a sensitive variable. Normal plan presentation hides the value; show -json returns it together with sensitivity metadata. After apply, the JSON state representation also contains the marker. The mask guides presentation rather than removing the value from the artifact. When building a report, select necessary fields and honor the markings before displaying them. Define access, retention and destination for generated plans and JSON. Do not assume a log is safe because the human-facing interface showed only sensitive value.
Compound actions and replacement reason
Another case retains the input and explicitly requests replacement of terraform_data.release. The plan presents delete and create actions with reason replace_by_request. The script retains that proposal without executing it. An unchanged input does not exclude operator-requested replacement. A rule searching only for an isolated delete action can miss replacements represented by a sequence. Analyze action elements and their order where relevant. The reason adds context, but an unfamiliar reason code does not justify ignoring destructive actions. For actual resources, capacity, data and continuity require resource-specific analysis.
Evidence suitable for support handover
Deliver a readable sequence: context and target, reviewed plan, included actions, constraints, result and outstanding differences. If the plan was limited, include subsequent reconciliation without targeting. If values remain unknown, explain how they will be confirmed; if sensitive data exists, control the report carrying it. The workshop establishes CLI 1.16.5 behavior using local state and terraform_data in sequential operations. It does not establish concurrent locking, a remote backend, an approval pipeline or cloud infrastructure recovery. In a human workshop, ask the participant to interpret the evidence and justify continuing or suspending.
# In the isolated workshop, consumer references source.output.
terraform plan -input=false -target=terraform_data.consumer -out=target.plan
terraform show -no-color target.plan
terraform apply -input=false target.plan
# Reconcile the complete configuration after the exceptional operation.
terraform plan -input=false -detailed-exitcode
# Treat machine-readable output as potentially sensitive.
terraform show -json target.plan
A targeted plan includes consumer and its source dependency. After successful apply, a full plan still proposes creating independent.
Common pitfalls
Treating target as a boundary without dependencies; publishing sensitive JSON in logs; interpreting unknown as empty; accepting only the final count.
Related topics: Plan review and approval · State and operational recovery
A plan has scope and partial information. Read actions, dependencies and data masks, and establish what execution left out.
Reference: JSON format, unknown values and change representation · Terraform v1.16 concepts; official documentation consulted 2026-09-30; provider and backend capabilities must be confirmed