Terraform fundamentals Study Guide — 004

Terraform Fundamentals

This domain is part of the HashiCorp Terraform Associate 004 exam (004 has been the only version since January 2026; 003 is retired). HashiCorp does not publish objective weightings, so treat it as one of the current blueprint's estimated-even-weight topic areas rather than a confirmed percentage — do not rely on a specific question count. It tests your ability to use the Terraform CLI correctly, understand the core workflow, recognize valid HCL block types and their syntax, manage variables and outputs, and work with the dependency lock file and state. Expect questions that require you to identify the correct command flag, predict what a command will do, or recognize a valid vs. invalid configuration block.

Core Terraform Workflow: init, plan, apply, destroy

The standard Terraform workflow follows a strict sequence. Understanding what each command does and when to run it is foundational.

Key facts:

• terraform plan does not modify state or infrastructure — it is read-only.
• terraform apply without a saved plan file runs an implicit plan first and prompts for confirmation.
• terraform destroy is equivalent to terraform apply -destroy.
• You must run terraform init any time you add a new provider, change a backend, or clone a configuration into a new directory.

Common traps:

• Exam may ask if terraform plan changes state — it does not.
• Running terraform apply on a directory that has never been initialized will fail.
• terraform destroy does not delete your .tf files — it only removes managed infrastructure.

terraform init

terraform init prepares a working directory for use with Terraform. It is always the first command to run.

What it does:

1. Reads the terraform and required_providers blocks to determine provider requirements.
2. Downloads provider plugins into .terraform/providers/.
3. Downloads module source code into .terraform/modules/.
4. Initializes the backend (where state is stored).
5. Creates or updates the .terraform.lock.hcl dependency lock file.

Key flags:

The .terraform directory is created in the working directory and should not be committed to version control. It is regenerated by terraform init.

Common traps:

• Changing a provider version constraint and running terraform plan without re-running terraform init will cause an error — you must re-run init.
• -reconfigure does not migrate state; -migrate-state does.
• The .terraform directory stores provider binaries, not the state file itself (unless local backend is used separately).