Core Terraform workflow Study Guide — 004

Core Terraform workflow

This domain covers the day-to-day command sequence every Terraform practitioner runs: write → plan → apply, plus the supporting commands terraform init, terraform validate, terraform fmt, and terraform destroy. HashiCorp does not publish per-objective weightings; the ~13% figure used here is an even split across the exam's objective groups, and the commonly cited "57 questions / 70% to pass / 60 minutes" numbers are carried over from version 003 and should be treated as estimates. Regardless of weighting, this is the highest-yield domain on the exam: command flags, plan symbols, and "which command do I run next?" scenarios appear throughout the other domains too. Expect precise questions about exact flag names, defaults, exit codes, what each command does and does not do, and when re-initialization is required.

Describe the Terraform workflow: write, plan, apply

The core Terraform workflow has exactly three steps:

terraform init is a prerequisite/setup step, not one of the three core steps. terraform destroy is the teardown of the lifecycle, not a core workflow step. The exam loves the distractor "write, init, plan, apply" — reject it when the question asks for the core workflow.

How the same workflow scales:

Caption: the full command lifecycle, with the three core workflow steps highlighted in sequence.

Common traps

• Calling init part of the core workflow. The core workflow is write, plan, apply only.
• Assuming plan changes infrastructure. Plan is read-only against infrastructure — it never creates, modifies, or deletes real resources (it may update state metadata only when you explicitly use -refresh-only on apply).
• Assuming apply always runs a plan. It does — unless you hand it a saved plan file, in which case it executes that plan verbatim.
• Thinking a speculative plan in HCP Terraform can apply. Speculative plans cannot be applied; they are plan-only.
• Confusing "the core workflow" with "the enterprise workflow." The steps are identical; only where they run and who reviews them changes.

Initialize a Terraform working directory

terraform init prepares a working directory for use. It is safe to run multiple times (idempotent) and is the first command you run in a new or cloned configuration.

What init does, in order:

1. Backend initialization — reads the backend/cloud block, configures state storage, and offers to migrate existing state if the backend changed.
2. Module installation — downloads/copies every module source into .terraform/modules/ and writes modules.json.
3. Provider plugin installation — resolves version constraints, downloads plugins from the Terraform Registry (registry.terraform.io by default) into .terraform/providers/.
4. Dependency lock file — creates or updates .terraform.lock.hcl in the working directory with selected provider versions and checksums.

The .terraform directory:

.terraform/ is machine-local and belongs in .gitignore. .terraform.lock.hcl must be committed so teammates and CI get identical provider versions.

Key init flags:

When do you need to re-run init?

Caption: decision tree for choosing the right terraform init flag.

Worked scenario: A team has been running Terraform with local state. They add an s3 backend block and rerun terraform init. Terraform detects the backend change and prompts to copy existing state. They want the existing resources preserved in S3 but must run non-interactively in CI. Reasoning: Preserving state = migration, so -reconfigure is wrong (it would discard the association and leave local state behind). Non-interactive migration = terraform init -migrate-state -force-copy (or -migrate-state -input=false with -force-copy). Answer: -migrate-state, with -force-copy to suppress the prompt.

Common traps

• Believing init downloads providers into a global directory by default. They go into the working directory's .terraform/providers/ unless TF_PLUGIN_CACHE_DIR or a filesystem mirror is configured.
• Confusing -reconfigure with -migrate-state. -reconfigure discards the old backend association without migrating state.
• Thinking -upgrade ignores version constraints. It upgrades only within the constraints in required_providers.
• Thinking .terraform.lock.hcl should be gitignored. It should be committed; .terraform/ should not.
• Thinking terraform get is a substitute for init. terraform get installs modules only — no backend, no providers, no lock file.
• Assuming init validates configuration correctness. It parses enough to resolve providers/modules but is not a substitute for validate.
• Believing running init twice is destructive. It is safe and idempotent.