Lab: plan, apply, inspect, and clean up local Terraform state

Prepare the exact fixture

Use Terraform 1.12.x or a compatible 1.x version meeting the constraint below. Create a new empty directory and save this complete main.tf. Do not combine it with another project's state.

terraform {
  required_version = ">= 1.12, < 2.0"
}
variable "environment" {
  type    = string
  default = "dev"
  validation {
    condition     = contains(["dev", "qa"], var.environment)
    error_message = "Choose dev or qa."
  }
}
resource "terraform_data" "name" {
  input = var.environment
}
resource "terraform_data" "label" {
  input = "study-${terraform_data.name.output}"
}
output "study_label" {
  value = terraform_data.label.output
}

Review and apply

terraform version
terraform fmt
terraform init
terraform validate
terraform plan -out=study.tfplan
terraform show study.tfplan

Identify the two resources and their dependency. Only after reviewing that this fixture contains no external provisioner or cloud resource, run terraform apply study.tfplan. Saved-plan application proceeds without the normal approval prompt.

Inspect terraform state list, terraform state show terraform_data.name, and terraform output. Run another plan and explain why unchanged inputs should produce no changes. Then plan -var='environment=qa' and inspect how the changed input flows through the dependency. Try an invalid value and explain the validation failure; do not count it as an infrastructure outage.

Connect the output to the dependency

The two addresses should be terraform_data.name and terraform_data.label. The first stores the chosen environment. The second depends on its output and adds the study- prefix. With the default applied, terraform output -raw study_label should print study-dev; planning qa alone does not change that applied output.

Inspect the order of your commands as well as the plan. init prepares this new root, validate checks its configuration, and plan -out saves a proposal. Applying that file performs the reviewed change without asking again. A second normal plan should settle because no desired value changed; do not confuse that with a test of any cloud provider.

If the invalid value fails before a plan can be accepted, the input validation is doing its job. Restore the intended input rather than loosening the rule solely to make a command green.

Demonstrate an environment boundary

Copy only main.tf into a second empty practice directory, initialize, and plan it. Do not copy the first directory's state or saved plan. Explain why the second root initially has no recorded managed resources. This is separate local state, not separate cloud-account authorization.

Cleanup and checkpoint

In the first directory, run terraform plan -destroy -out=cleanup.tfplan, review it, then apply that saved cleanup plan. Inspect state afterward. If you applied in the second directory, repeat its separate cleanup. Retain configuration and your report; discard local plan/state artifacts only after confirming cleanup, never by committing them to Git.

Explain formatting versus validation, state versus configuration, provider locking versus state locking, and what this fixture cannot prove about cloud APIs. Revision: review both creation and destruction; preserve state until managed work is accounted for.

Answer the checkpoint

Formatting changes layout; validation checks internal consistency with dependencies available. Configuration expresses intent; state records managed identities and applied outputs. A provider lock file records selected provider packages, while a state lock coordinates writers where supported. The fixture proves neither AWS permissions nor application readiness, because it uses only Terraform's built-in data resource.

Keep the configuration and a short explanation of the first plan, unchanged plan, invalid input, and reviewed cleanup. Those are the habits the MicroBank resource plan will require.

Apply this to MicroBank

After the six foundations modules, use Terraform to provision MicroBank’s local cloud dependencies. Start with the project setup and follow its ordered steps; later implementation stages depend on the earlier files.

Sources and practice status

Primary references: terraform_data↗; Terraform plan↗; Terraform apply↗.

Reviewed against documentation on 1 October 2026. The exercises still need to be run in your environment. Record your results and tool versions in your notes.