Terraform / Language, providers, and managed identity / Lesson 6

Plan, state, and application boundaries

Read proposed changes as a review artifact while recognizing provider reads, sensitive plans, and partial execution failure.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish planning, saved plans, refresh observations, and execution.
Explain why infrastructure application is not a general multi-system transaction.

A plan proposes actions under a specific context

Planning combines configuration, selected providers, input values, state, and available observations to propose changes. It is not a universal dry run with no side effects: providers and data sources can contact APIs or execute supported external behavior, and planning can involve backend locking and local artifacts. It does not apply the proposed infrastructure changes, but that distinction does not authorize running it against an unknown workspace. This course shows only reviewable text and offline records; no plan command is executed.

A saved plan is an artifact with identity and sensitivity

The command below illustrates how a separately authorized workflow might save a plan. It is not run and does not connect this lesson to a backend. A saved plan contains more than the human-readable summary and can carry sensitive values. Bind approval to the exact artifact, source revision, dependency selections, input context, and state lineage. Replacing the file after review or applying a newly generated plan under the same friendly filename breaks that approval relationship.

bash Review-only saved-plan command

terraform plan -out=review.tfplan

This command would perform real Terraform planning and write an artifact if executed in an initialized workspace. It remains non-runnable here. Neither a plan file nor its text summary is fabricated as an observed result; provider/backend access and authorization must be established separately.

Read replacements as both removal and creation

A proposed update is different from replacement. Replacement may involve deleting an old object and creating a new one, with ordering determined by lifecycle and provider constraints. Consider data retention, identity changes, downtime, quotas, dependencies, and uniqueness requirements. A small configuration diff can therefore imply a large operational transition. The synthetic plan-shaped record below is authored teaching data; it is not output from Terraform and cannot establish what any actual resource provider would choose.

python Classify two synthetic proposed actions

changes = [
    {'address': 'terraform_data.catalog', 'actions': ['update']},
    {'address': 'terraform_data.cache', 'actions': ['delete', 'create']},
]
updates = sum(c['actions'] == ['update'] for c in changes)
replacements = sum(set(c['actions']) == {'delete', 'create'} for c in changes)
print(f'updates={updates}')
print(f'replacements={replacements}')

Expected output

updates=1
replacements=1

The fixed record has one update and one replacement. Using a set only for this classification ignores action order intentionally; a real reviewer must inspect the original ordered actions and resource semantics. No state or plan artifact is read.

Application can stop after partial progress

Terraform application is not an atomic transaction across every provider and external system. Earlier actions can succeed before a later one fails, and remote creation can be followed by a state-persistence problem. Preserve diagnostics and determine which operations completed before retrying. A blind rerun, manual deletion, or arbitrary state edit can compound the inconsistency. Recovery requires the approved workspace owner, protected state evidence, provider-specific understanding, and a reviewed reconciliation path. A nonzero exit code alone does not mean nothing changed.

Verify outcomes beyond a successful exit

After a separately approved change, verify intended object identity, required properties, application behavior, policy boundaries, and state consistency. A successful infrastructure operation does not prove that a deployed application is ready or that an external business action completed. Retain the exact reviewed inputs and outcome evidence while redacting sensitive material. If a saved plan becomes stale, regenerate and review it under the correct context rather than bypassing state checks. Safe change depends on ownership and evidence through the whole lifecycle, not on treating one command as infallible.

Common errors and fixes

Saved plan is stale.

Why it happens: The state context changed after the plan was produced.
How to fix it: Generate and review a new plan through the approved workflow rather than bypassing the check.
Prevent it next time: Bind approval to artifact identity and serialize writers appropriately.

A failed application is assumed to have changed nothing.

Why it happens: Partial provider success and state-persistence boundaries were ignored.
How to fix it: Reconcile completed actions and retained evidence before a reviewed retry.
Prevent it next time: Plan recovery for partial failures before execution authority is granted.

Only the number of changed lines is reviewed.

Why it happens: Source diff size was mistaken for operational effect and replacement risk.
How to fix it: Review the proposed actions, identities, dependencies, and data implications.
Prevent it next time: Require action-level review for every sensitive transition.

Check your understanding

1. Does the synthetic record imply two harmless updates?

Show worked solution

No. One entry is classified as an update and another as deletion plus creation. The replacement deserves its own identity, data, availability, and dependency review. The record is illustrative and supplies no evidence that an actual Terraform run or provider has approved either action.

2. Why is plan not automatically safe to run on an unknown project?