Terraform init, validate, and plan: the core workflow explained

The core Terraform workflow has three stages: Write configuration as code, Plan to preview the changes Terraform will make, and Apply to execute them. This loop is deliberate: because your infrastructure is declared in files, every change can be reviewed as a diff before it touches real resources. You repeat the loop for every change — edit the configuration, plan, review, apply — whether you work alone on a laptop or in a team with version control and CI.

Two supporting commands wrap the loop. terraform init is a one-time (per working directory, repeated only when dependencies change) setup step that must succeed before plan or apply can run. terraform validate is a quick correctness check you can run at any point after init, typically as the first gate in a CI pipeline. Neither of these touches real infrastructure.

On the exam, expect questions that give you a scenario — a fresh clone of a repository, a newly added provider, an edited resource — and ask which command comes next. The answer is almost always driven by this table: fresh directory or new dependency means init; wanting to preview means plan; making it real means apply.

terraform init initializes a working directory containing Terraform configuration, and it is the first command you run in any new or freshly cloned configuration. Until init succeeds, terraform plan and terraform apply fail, because the provider plugins they need have not been installed. Running init performs four jobs: it configures the backend where state will be stored, downloads the provider plugins the configuration requires, installs any modules the configuration calls, and creates or updates the dependency lock file.

$ terraform init

Initializing the backend...
Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 5.0"...
- Installing hashicorp/aws v5.98.0...
- Installed hashicorp/aws v5.98.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository.

Terraform has been initialized successfully!

Init is safe to run repeatedly — it never destroys infrastructure or modifies your configuration, so rerunning it on an already-initialized directory is a no-op apart from checking dependencies. You must run it again whenever the dependencies of the directory change: you add a provider requirement, add or change a module block or a module's source or version, or change the backend configuration. Terraform will tell you when this is needed — plan fails with an error asking you to run terraform init.

Init downloads two kinds of dependency into the hidden .terraform directory. Provider plugins — the binaries that actually talk to AWS, Google Cloud, Azure, or utility providers like random — are installed under .terraform/providers, selected from the version constraints in your required_providers block. Modules referenced by module blocks are fetched into .terraform/modules, whether they come from the public registry, a Git URL, or a local path. The .terraform directory is machine-local and should never be committed to version control.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    random = {
      source  = "hashicorp/random"
      version = "~> 3.6"
    }
  }
}

Init also writes .terraform.lock.hcl, the dependency lock file. It records the exact provider versions selected and their checksums, so every teammate and every CI run installs identical provider builds. Unlike .terraform, the lock file should be committed to version control. Two exam traps here: the lock file locks providers only — module versions are not recorded in it — and Terraform will not silently drift to a newer provider once the lock file exists. To deliberately upgrade to the newest versions allowed by your constraints, run terraform init -upgrade, which reselects versions and rewrites the lock file.

Init configures the backend — where Terraform stores state — from the backend block inside the terraform block (or the local backend by default). Because backend settings cannot contain variables, partial configuration is common: you supply the rest at init time with -backend-config, either as key=value pairs or a file.

$ terraform init -backend-config="bucket=my-tf-state" -backend-config="region=eu-west-1"

When you change the backend configuration, plain init refuses to guess your intent and asks you to choose: terraform init -migrate-state copies existing state from the old backend to the new one, while terraform init -reconfigure disregards the existing backend configuration entirely and initializes against the new one without migrating anything.

• -upgrade — upgrade providers and modules to the newest versions allowed by constraints, updating the lock file.
• -migrate-state — move existing state to a newly configured backend.
• -reconfigure — reinitialize the backend, ignoring any previously saved configuration and skipping migration.
• -backend-config=... — supply partial backend configuration at init time.
• -backend=false — skip backend initialization entirely; useful in CI jobs that only need to run validate.

Expect scenario questions such as "you moved state storage from local to an S3 bucket and want to keep your existing resources — what do you run?" The answer is terraform init -migrate-state.

terraform validate checks that a configuration is syntactically valid and internally consistent: HCL parses, argument names exist for the resource types used, references point at things that are declared, and types line up. Crucially, it does all of this without contacting any remote service — it never reads state, never calls a cloud API, and never checks whether the values you supplied would actually be accepted by the provider's service. That makes it fast and safe to run anywhere, and it is the standard first gate in a CI pipeline.

$ terraform validate
Success! The configuration is valid.

$ terraform validate -json
{
  "format_version": "1.0",
  "valid": true,
  "error_count": 0,
  "warning_count": 0,
  "diagnostics": []
}

One dependency trips people up on the exam: validate needs the provider schemas to know which arguments are legal, so the working directory must be initialized first. In a CI job that has no backend credentials, initialize without the backend and then validate: terraform init -backend=false followed by terraform validate. The -json flag produces machine-readable output for tooling.

Keep validate's limits straight: it will catch a typo like istance_type or a reference to an undeclared variable, but it will not catch an AMI ID that does not exist, a name that collides with a real resource, or missing IAM permissions — those surface at plan or apply time, when Terraform actually talks to the provider.

terraform plan creates an execution plan: it reads the current state, refreshes Terraform's view of the real objects recorded there, compares that against your configuration, and proposes the minimal set of actions — create, update, or destroy — needed to make reality match the code. Plan is a read-only preview: it never modifies infrastructure and never writes to the state file. Even the refresh it performs by default only updates Terraform's in-memory view for the comparison; the stored state is untouched until apply.

resource "random_pet" "suffix" {
  length = 2
}

resource "aws_instance" "web" {
  ami           = "ami-0c101f26f147fa7fd"
  instance_type = "t3.micro"

  tags = {
    Name = "web-${random_pet.suffix.id}"
  }
}

$ terraform plan

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_instance.web will be created
  + resource "aws_instance" "web" {
      + ami           = "ami-0c101f26f147fa7fd"
      + instance_type = "t3.micro"
      + id            = (known after apply)
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Values Terraform cannot know until the resource actually exists — server-assigned IDs, IP addresses — show as (known after apply). Useful flags: -var and -var-file set input variables, -refresh=false skips the refresh for speed, -refresh-only plans only the reconciliation of state with reality (no configuration changes), -destroy previews a full teardown, and -detailed-exitcode makes plan exit with code 0 for no changes, 1 for error, and 2 for changes present — the standard way CI detects drift or pending changes.

Every proposed action in plan output is marked with a symbol, and the exam expects you to read them at a glance. + means create, ~ means update in-place (the resource survives, an argument changes), and - means destroy. When a changed argument cannot be updated in place — for example changing an aws_instance AMI — Terraform must replace the resource, shown as -/+ (destroy then create) with a note like "forces replacement" beside the offending argument. Data sources that will be read during apply are marked <=.

The summary line — Plan: 1 to add, 1 to change, 1 to destroy — counts these actions, and a replacement counts as both one add and one destroy. Reviewing for unexpected - and -/+ lines before approving is the whole point of the plan stage: an innocent-looking edit that forces replacement of a database is exactly the kind of surprise plan exists to catch.

terraform plan -out=FILE saves the generated plan to a file, and terraform apply FILE later executes exactly those actions — no more prompting, and no risk that the world or the configuration changed between review and execution. Without a saved plan, terraform apply computes a fresh plan at apply time, which may differ from the one you looked at. Saved plans are the backbone of CI/CD pipelines: the plan job produces the file and posts the diff for review; the apply job consumes the same file after approval.

$ terraform plan -out=tfplan
$ terraform show tfplan          # human-readable review of the saved plan
$ terraform show -json tfplan    # machine-readable JSON for policy tools
$ terraform apply tfplan

Three exam-relevant details. First, the plan file is a binary format — you inspect it with terraform show, not a text editor — and it can contain sensitive values, so treat it like a secret. Second, input variable values are captured inside the saved plan, so you do not (and must not) pass -var again at apply time. Third, a saved plan is checked against the state it was created from: if the state has changed since the plan was written, Terraform refuses to apply the stale plan and you must plan again. Applying a saved plan file also skips the interactive approval prompt, because the review already happened when the plan was generated.