Terraform Associate Notes: workflow and state

Module 1: Infrastructure as code

Infrastructure as code means you describe infrastructure in files that a tool can create, change, and destroy. The files are the source of truth. A console click that nobody reviewed is not. Terraform's language is declarative: you describe the desired end state, and Terraform works out the actions that get there.

Infrastructure as code does not remove drift by itself. Drift is a real object that changed outside Terraform. The next plan shows that difference only if you apply from the files. A repository nobody runs is documentation, not a control.

Module 3: The core workflow

Write configuration, initialize the working directory, review a plan, then apply. Destroy is the same workflow aimed at removal. Format is a style step you can run at any time before you commit.

In a plan, + creates, - destroys, ~ updates in place, and -/+ replaces. A replace destroys and creates because the provider cannot update that argument in place. Deleting a resource block from the configuration, then applying, destroys that one object. terraform destroy targets the whole state for this configuration.

terraform plan does not change remote infrastructure. terraform validate does not tell you whether a cloud API will accept the values. A saved plan can contain sensitive values, so treat the plan file like state.

Module 5: Modules

A module is a directory of Terraform files you call with a module block. The caller sets the child module's input variables as arguments and reads its outputs. Root variables are not visible inside the child. Locals stay in the module that declares them. That boundary is the point of a module: a small interface instead of every variable leaking inward.

Changing a module source or version means running terraform init again. A module that creates resources still stores those resources in the root module's state, under an address like module.network.aws_subnet.public. The child module does not get a separate state file unless it is a separate root configuration.

Module 7: Import, inspect, and logs

Import brings an object that already exists under Terraform's management. An import block names the resource address in to and the existing object's id. terraform plan can then show the import, and terraform plan -generate-config-out can write a starting configuration. The older terraform import command updates state only and does not write the HCL. Neither command destroys the real object. You still review the configuration so the next apply does not immediately change it.

terraform state list prints addresses. terraform state show prints one object's attributes. terraform state rm drops an address from state and leaves the real object in place, which is how you stop managing something without deleting it. terraform state mv renames an address or moves it, for example into a module. Prefer those commands, or a moved block in configuration, to hand-editing the JSON.

Set TF_LOG to TRACE, DEBUG, INFO, WARN, or ERROR when you need a diagnostic. TRACE is the most detailed. TF_LOG_PATH writes the log to a file. Logs can contain secrets and should not be pasted into a ticket. Leave TF_LOG unset for a normal apply.

Extra terraform apply -replace=address forces replacement on the next apply. It replaces the older terraform taint command. The 004 objective list names import, state inspection, and verbose logging, not taint.

Frequently asked questions

Provider arguments and HCP Terraform screen names change. When a note and the current HashiCorp documentation disagree, follow the documentation for the Terraform 1.12 behavior the 004 exam describes.