Validation and change review

Read the change, not just the green check

Terraform offers several checks because they answer different questions. Formatting a configuration cannot establish that an account has permission to create its resources. A successful apply cannot establish that a customer can complete a transaction.

Review one small proposal completely

Return to terraform-basics, which contains the two resources from the earlier lessons. Run:

terraform fmt -check
terraform init
terraform validate
terraform plan -var='environment=qa' -out=study.tfplan
terraform show study.tfplan

Read the resource addresses before the totals. + means create, ~ update in place, - destroy, and combinations such as -/+ indicate replacement. An attribute marked known after apply is not yet available during planning. For this fixture, look for how qa reaches the name input and then the label. Depending on what you previously applied, the plan may contain additions or updates. Explain that history rather than forcing a particular count.

For each action, write one sentence: “This address changes because this input changed.” If a resource unexpectedly disappears, inspect whether its block was removed, its address renamed, or a different root/state selected. Do not approve an unexplained replacement merely because the total number of resources is unchanged.

Applying has consequences that a plan does not

A saved plan is a file representing a particular proposal. terraform apply study.tfplan applies it without the normal interactive approval question. Editing the source afterward does not rewrite that saved plan. State changes can make it stale; changes outside Terraform can also alter what succeeds at apply time. Produce a new plan when the intended change or context changes.

Saved plans and state can contain sensitive values. Store them with appropriate access and retention; do not attach an unredacted plan file to a public issue. For real resources, verify the account, region, state, affected data, and expected interruption as part of the review.

An apply can fail after some operations succeed. Terraform does not automatically undo all completed work. Preserve diagnostics, inspect state and actual resources, correct the cause, and create a fresh plan. A failure writing state requires particular care because remote work and recorded ownership may diverge.

Exercise judgment with three cases

1. validate passes but plan cannot authenticate: fix the selected credential flow; successful syntax checks never proved API access.
2. An unexpected database replacement appears: investigate the changed argument and backup/recovery implications before applying; do not hide it with -target.
3. A no-change plan appears after an alleged manual edit: check the target account, region, state, ignored fields, refresh behavior, and whether Terraform manages that object at all.

-replace=ADDRESS deliberately requests replacement. -target limits a plan for exceptional repair or troubleshooting, but normal use can leave an incomplete picture of the configuration. Terraform tests can also perform real applies; read their provider and resource scope before running them. Mocked tests help check configuration logic but cannot establish real API behavior.

Next, complete the local lab, including a separately reviewed cleanup. Your success criterion is being able to explain the plan and the second no-change run, not simply collecting a successful exit code.

References: plan↗, validate↗, apply↗, and Terraform tests↗.