HashiCorp Certified: Terraform Associate

terraform init, plan and apply explained for Terraform Associate

The core Terraform workflow is write, plan, apply. terraform init prepares the working directory first: it sets up the backend, installs child modules and installs providers. terraform plan previews the changes, and terraform apply carries them out, either from a new plan that it asks you to approve or from a saved plan file.

The three steps, and where init fits

HashiCorp describes the core workflow as three steps. Write: author the configuration in your editor, usually in a version-controlled repository. Plan: preview the changes before applying them. Apply: provision the infrastructure. The workflow is a loop that starts again with the next change.

terraform init is the first command to run after writing a new configuration or cloning one from version control. It initializes the backend named in the root module, downloads the source of every module block, and installs the providers the configuration needs. It then writes the selected provider versions to the dependency lock file.

init is safe to run many times. It brings the working directory up to date with the configuration and never deletes your configuration or state.

What plan does

By default terraform plan does three things. It reads the current state of existing remote objects so that the state is up to date. It compares the configuration with that prior state. It then proposes the actions that would make the remote objects match the configuration. The plan command itself changes nothing.

A plan run without -out=FILE is a speculative plan: a description of the effect, with no intent to apply it. Other changes can happen before you apply, so the final plan may differ from the speculative one you reviewed.

-refresh=false skips the sync with remote objects. It makes planning faster with fewer API calls, but Terraform then ignores changes made outside Terraform, so the plan can be incomplete or wrong. Two other planning modes exist: -destroy, which is the same as terraform destroy, and -refresh-only, which only updates state and root module outputs to match remote objects.

Two ways to run apply

Automatic plan mode: terraform apply with no plan file creates a new plan, shows it, and asks you to type yes. -auto-approve skips the question. -input=false turns off all prompts, including the approval prompt, so Terraform assumes you do not want to apply and the run fails.

Saved plan mode: run terraform plan -out=tfplan, review it (for example with terraform show), then run terraform apply tfplan. Terraform performs exactly the operations in the file without prompting, because passing the file counts as approval. -auto-approve is ignored here, and you cannot add planning options such as -var or -replace, because the file already holds the final decisions. HashiCorp recommends this two-step form for automation.

When an apply fails partway

If Terraform or a provider hits an error during apply, Terraform logs the error, updates the state with the changes it did make, unlocks the state and exits. It does not roll back.

For example, if an apply creates four of nine resources and fails on the fifth, the four stay and are recorded in state. After you fix the cause, you run apply again and Terraform plans the remaining work.

Where the exam catches people

Believing -input=false lets an unattended apply go through: it suppresses the approval prompt, so Terraform assumes no and fails. Use -auto-approve or a saved plan file.
Believing a saved plan still needs -auto-approve: passing the plan file is the approval, and Terraform ignores -auto-approve in that case.
Believing a failed apply is rolled back: Terraform records what it created in state and stops. You fix the error and apply again.
Believing -refresh=false is a safe speed-up: Terraform then ignores changes made outside Terraform, so the plan can be incomplete or incorrect.
Believing a speculative plan can be applied later: only a plan saved with -out can be passed to terraform apply.