Terraform Associate (004) Cheat Sheet

Cheat sheet: compare Terraform workflow and state operations, module and provider boundaries, and Terraform 1.12 sensitive-data behavior.

Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.

Operations that are easy to confuse

OperationMain purposeBoundary to remember
terraform fmt -checkCheck formattingIt is not configuration or remote-API validation.
terraform initInitialize a working directoryIt does not apply infrastructure changes.
terraform init -upgradeReconsider provider and module selections within constraintsReview resulting dependency changes and the next plan.
terraform validateCheck configuration syntax and internal consistencyIt does not prove an apply will succeed against a remote API.
terraform plan -out=review.tfplanSave a proposed changeThe plan file can contain sensitive data.
terraform apply review.tfplanExecute the saved planProtect and review the artifact before executing it.
terraform state list / state showInspect tracked addresses and stored object detailsStored state is not a fresh API query.
terraform importBind an existing object to a resource addressIt does not create the object; the CLI form needs matching configuration.
terraform state rmStop tracking an objectIt does not delete the remote object.
Notes and examples

See the Terraform 1.12 CLI documentation for options and prerequisites. Commands here are reference examples, not a sequence to run against an existing environment.

Configuration boundaries

  • Provider requirement: identifies a provider source and compatible versions. A provider configuration supplies settings for an instance of that provider.
  • Module input: passes a value into the child module’s scope. A child output exposes a value to its caller.
  • Dependency: orders operations. Configuration references often create dependencies automatically; explicit dependencies cover relationships Terraform cannot infer from values.
  • State binding: links a Terraform address to an existing object. Refactoring that address and replacing the object are different decisions.

Display versus persistence

sensitive = true is a redaction signal, not encryption. State, saved plans, direct named-output requests, or JSON output may expose sensitive values depending on the operation. Terraform 1.12’s ephemeral values and provider-defined write-only arguments have additional persistence rules. Check the versioned documentation rather than treating every secret-handling feature as equivalent.

For a workflow that combines these boundaries, return to scenario practice or try a fresh mixed set in IT Mastery.

Review the decision, not just the command

Use this short checklist after an attempt. It is a way to locate a gap, not a substitute for the official 004 objectives and tutorials .

When the question shows…Check…
A fresh checkout or provider changeProvider requirements, the dependency lock file, module installation, and whether an upgrade was requested.
A plan or apply sequenceWhether the operation creates a fresh plan or applies an existing saved plan, and whether the relevant state changed.
HCL expressions or module callsValue type, scope, provider mapping, and the caller’s supplied inputs.
A dependency diagramArrow direction, the specified action, and any lifecycle rules.
Drift or an importConfiguration intent, tracked addresses, and the difference between state reconciliation and infrastructure changes.
A secretDisplay redaction, state/plan persistence, and where ephemeral or write-only values are permitted.
HCP TerraformExecution mode, workspace context, permissions, and the distinction between triggering a run and sharing outputs.

Terraform 1.12 distinctions to revisit

A sensitivity marker controls ordinary display behavior; it does not encrypt state or automatically omit a value from it. Ephemeral values and write-only arguments solve different persistence problems and have specific allowed contexts. Review sensitive-data handling when these appear in a missed question.

Custom conditions also have different effects. Input validation, preconditions, postconditions, and checks are not interchangeable merely because they contain Boolean expressions. Read the custom-condition guidance with the failing stage in mind.

Return to practice

Choose one uncertainty, verify it, and try a new example in IT Mastery. The reference tables on this page help distinguish operations; the scenario guide helps you read configuration, plans, and diagrams together.

Put the review into practice