The Basic Workflow

The daily Terraform workflow is a small, repeatable cycle. Every operational improvement in this course — state, plan review, saved plans, CI/CD, policy — is a refinement of this cycle. The cycle is:

Write configuration
   ↓
terraform fmt
   ↓
terraform init
   ↓
terraform validate
   ↓
terraform plan
   ↓
Review the plan
   ↓
terraform apply
   ↓
Validate infrastructure

Each step has a specific role. Each step has a limit.

Write the configuration

The first step is the only one that requires human creativity. The configuration is a .tf file (or several) that declares the desired state.

terraform {
  required_version = ">= 1.9.0"
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.0"
    }
  }
}

resource "local_file" "hello" {
  filename = "${path.module}/hello.txt"
  content  = "Hello from Terraform!\n"
}

The configuration is the only artefact that lives in source control. Every other artefact (state, plan, lock file) is generated.

terraform fmt

terraform fmt rewrites the configuration files to a canonical style:

terraform fmt

The command:

• Reformats whitespace, alignment, and indentation.
• Groups related arguments.
• Sorts argument order within blocks.
• Does not change semantics.

terraform fmt -check is the CI form: it exits non-zero if any file would be changed, but does not change files.

terraform fmt -check -recursive

Most teams run terraform fmt -check in CI on every commit. The CI fails if the configuration is not formatted. The engineer runs terraform fmt locally to fix the failure.

The course has a CI workflow in Part LXXXVII that runs fmt -check as the first step.

terraform init

terraform init prepares a working directory for use:

terraform init

The command:

• Downloads the providers listed in required_providers.
• Downloads modules from their sources.
• Initialises the backend (creates a state file if local, or negotiates with the remote backend if remote).
• Creates or updates the .terraform.lock.hcl file.
• Caches the working directory in .terraform/.

terraform init is safe to re-run. It is idempotent: re-running with no changes is a no-op; re-running after a required_providers change triggers a re-download.

terraform init -upgrade    # upgrade providers within the constraints
terraform init -reconfigure   # reconfigure backend, do not re-download

-upgrade is appropriate when a provider has released a new patch version. -reconfigure is appropriate when the backend configuration has changed.

The course returns to init failure cases in Part CVII.

terraform validate

terraform validate performs static checks on the configuration:

terraform validate

The command:

• Parses the configuration.
• Checks the type and existence of variables, outputs, and resources.
• Verifies that provider blocks are configured.
• Verifies that module references are correct.

The command does not:

• Connect to the provider API.
• Verify that the resources can be created.
• Check the state.
• Validate the identity of the resources against the real world.

A configuration that passes terraform validate may still be insecure, expensive, or operationally wrong. The validate step catches syntactic and structural errors, not semantic ones.

terraform plan

The plan is the operational artefact. The course has a dedicated lesson on the plan (Part VI). The one-line summary:

terraform plan

The plan reads the configuration, reads the state, asks the provider to refresh state, and computes the diff. The output is the proposal.

A saved plan:

terraform plan -out=production.tfplan

A saved plan is the input to terraform apply. It is the unit of review.

terraform apply

The apply is the moment the plan becomes reality. The course has a dedicated lesson on apply (Part VII). The one-line summary:

terraform apply                  # interactive approval
terraform apply production.tfplan # apply the saved plan

The apply walks the resource graph, sends API calls to the provider, and updates state after each successful operation.

terraform destroy

The destroy is the inverse of the apply. The course has a dedicated lesson on destroy (Part VIII). The one-line summary:

terraform destroy

The destroy reads the configuration (or the state, if no configuration is present), computes the destroy plan, prompts for approval, and removes the resources.

What the workflow does not do

Two important gaps:

The workflow does not validate against the real world. A plan that says “5 to add” assumes the providers and the real world are available. A plan that succeeds does not guarantee that the resulting infrastructure is healthy.

The workflow does not validate security. A valid Terraform configuration can be insecure. The course returns to security in Part LIII.

The workflow as a habit

The daily workflow is the answer to the question “is this change safe to apply”. The answer is composed of:

• A formatted configuration (fmt).
• An initialised working directory (init).
• A structurally valid configuration (validate).
• A reviewed plan (plan + human review).
• A controlled apply (apply with a saved plan where possible).

Each step has a cost. The cost of skipping any step is usually paid later, with interest.

What comes next

The next lesson is terraform init in depth — what it does, what it does not, and the failure modes that show up in production.