LEARN. PRACTICE. GROW.A workspace changes selected state
During the default workspace lock, a third directory uses the same configured backend, creates isolated and can plan creation in that separate state. The first run remains active. Later, selecting default in that directory permits reading the completed shared resource. The observation shows why the effective workspace must be recorded together with backend and directory. A command that no longer encounters contention may have changed target rather than resolved original contention. Before applying, confirm whether the plan updates the intended collection or creates a new collection in empty state.
Instance separation and access separation
The script applies simple configuration in the isolated workspace after releasing the holder. Address terraform_data.operation appears in both workspaces, but resource identifiers differ. The default workspace value remains intact. This establishes separation of the tested local states, not separation of credentials or team authorization. The same operating-system identity runs every command. For environments with different access requirements, evaluate configurations and backends with suitable controls. Documentation also distinguishes CLI workspaces from HCP Terraform workspaces; do not automatically transfer guarantees from one product to the other.
The effect precedes the error
A second helper writes a JSON line to a temporary file and exits with code 7. The creation provisioner fails and apply ends with an error. The line remains in the file, and the resource is recorded as tainted in local state. The workshop uses this simple effect to expose an operational issue: a process can perform work before reporting failure. The marker represents neither a real financial transfer nor an external system. In actual bootstrap, inventory records, files, registrations or requests emitted by the script before deciding which actions can be repeated safely.
Replacement does not erase script history
The next plan proposes delete and create with reason replace_because_tainted. The script retains that proposal and changes helper execution to success in a new application. The local resource identifier changes, but the effects file now has two lines: the first was not undone. Recovery of the managed lifecycle and reconciliation of script effects are related but distinct problems. Define operation identity, result verification and retry strategy when the actual system requires idempotency. The workshop implements none of those external mechanisms and establishes no universal compensation policy.
Continuing after error changes the observed result
In another directory, the same helper fails after writing a line, but the provisioner uses on_failure=continue. Apply ends with code 0 and the resource is not tainted. A subsequent plan presents no-op; the failed helper does not rerun during that planning operation. Successful apply therefore does not establish success of every step whose error was explicitly ignored. If the effect is necessary to make the service available, define an acceptance criterion observing it and include it in the promotion decision. Do not hide a mandatory requirement behind continue merely to obtain a green pipeline.
Prepare a recovery decision
In a fictional APS exercise, give the participant the selected workspace, addresses and identifiers, provisioner result, effect lines and next plan. Ask them to separate what was created, what failed, what remains and what could repeat. A useful answer identifies dependencies and acceptance criteria before proposing another run. Results here use temporary files and a built-in resource, without credentials or remote infrastructure. A representative provider, team permissions, remote backend, actual idempotency mechanism and a human workshop with specialist review remain outstanding.
# Observe selection before deciding what a plan refers to.
terraform workspace show
terraform plan -input=false -out=review.plan
terraform show -no-color review.plan
# For a failed provisioner, inspect effects and the recovery proposal.
# A no-op plan does not independently verify an ignored script failure.
A helper appends a line and exits with an error; the line remains. Recovery replaces the local resource and appends another line.
Common pitfalls
Confusing a workspace with separate permissions; treating tainted as rollback; accepting on_failure=continue as proof of helper success.
Related topics: Saved plans and approval · Recovery after partial execution
Separate states create neither a transaction over scripts nor an authorization boundary. Design and verify those guarantees explicitly.
Reference: Provisioner effects, creation failure and continue handling · Terraform v1.16 concepts; official documentation consulted 2026-09-30; provider and backend capabilities must be confirmed