LEARN. PRACTICE. GROW.Preparing a bounded local experiment
The terraform_data resource lets you observe a managed object’s lifecycle through the built-in provider without creating a machine or contacting a cloud. Use a new directory and only the example shown; local state belongs to the experiment. This path was exercised with Terraform 1.12.2, within the 1.12 version specified for Associate 004. The lab demonstrates CLI and state behavior, not quotas, networks, cloud permissions, or application availability. Before each change, write down the action you expect to observe. Then compare the prediction with the plan and explain any difference before proceeding.
Distinguishing planning, execution, and exit codes
Save the example as main.tf, run terraform init and terraform validate, then terraform plan -detailed-exitcode -out=initial.tfplan. On the first local run, code 2 means success with proposed changes. Code 0 means a plan without differences and code 1 means an error. This convention depends on the -detailed-exitcode option. Plan does not execute proposed actions. Inspect the file with terraform show initial.tfplan before applying it. Passing a saved plan to apply executes its stored decisions without another interactive confirmation. This CLI behavior requires actual review and authorization to have occurred through the appropriate process.
Reading actions and values still unknown
After applying the first local version, an unchanged plan proposes no changes. Changing input from r1 to r2 on terraform_data produces an in-place update. Changing triggers_replace requests replacement. In JSON representation, ["delete","create"] describes deletion before creation; ["create","delete"] describes the opposite order. A field in after_unknown indicates a value not yet known, not an automatically protected secret or a provider error. JSON and plan files may contain sensitive data in real configurations. Review actions by address and attribute; a total count alone does not reveal possible data loss or interruption.
Checking what actually prevents an operation
A false assertion in a check produces a warning and should not be the only gate when a condition must prevent an operation. In the lab, a precondition with approved=false known during plan blocks the proposal, while the corresponding check allows continuation with a warning. Configuration syntax validity does not prove the condition is satisfied. prevent_destroy also has a concrete scope: while the rule is present, it blocks plans requiring resource destruction. If someone removes the entire resource block, the rule no longer exists in configuration and a plan may propose deletion. Review needs to consider the complete change context.
Recognizing when approval no longer matches the plan
Save a plan for r2, generate and apply another for r3 against the same state, then try the first plan. In the lab, Terraform rejects it as Saved plan is stale. Renaming the file, disabling locking, or editing the state serial does not solve the problem. Recalculate and review impact in the current context. You also cannot add planning options, such as new variable values, while applying a saved plan. New intent requires another plan. This specific rejection does not mean Terraform detects every possible external change in advance; the team remains responsible for context, drift, and execution validity.
Resuming changes without assuming rollback
In a fictional cloud situation, the network was created but the instance failed because of quota. The exit code does not establish that everything was rolled back. Inspect actual objects, state bindings, and the error cause; address the cause and review a new plan. Executing this cloud failure is outside the local lab. Using -refresh=false can hide external changes; using -target narrows scope and should be reserved for exceptional situations. The target includes relevant dependencies but does not guarantee coverage of independent work. After targeted recovery, inspect a full plan again and verify functional criteria with the support team.
terraform {
required_version = "~> 1.12.0"
}
resource "terraform_data" "record" {
input = "r1"
}
In a new directory: init, validate, plan -detailed-exitcode -out=initial.tfplan, show initial.tfplan, and apply initial.tfplan. Repeat plan without changing code; then change input to r2 and compare actions.
Common pitfalls
Treating code 2 as an error; using check as a gate; assuming prevent_destroy survives whole-block removal; reapplying an old plan or expecting transactional rollback.
Related topics: Workflow and plans · Configuration and secrets
A plan is contextual evidence of proposed actions. Interpret codes, validation, and state before execution; functional completion still needs its own criteria.
Reference: terraform plan command · 004