Terraform: 40 Key Concepts in Simple English

What are the core building blocks?

These are the pieces you write in almost every configuration.

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

Which files does Terraform actually read?

• 10. *.tf files - Terraform reads every .tf file in the folder. Names like main.tf, variables.tf and outputs.tf are conventions, not rules.
• 11. terraform.tfvars and *.auto.tfvars - variable values that load automatically.
• 12. .terraform.lock.hcl - locks provider versions so the whole team uses the same ones. Commit it to git.

What does the everyday workflow look like?

When a resource is healthy as far as Terraform can tell but broken in reality, you can force a single resource to be recreated with the -replace option:

terraform apply -replace="aws_instance.example[0]"

The useful part is that this goes through a normal plan. You see exactly what will be destroyed and recreated before you approve it, and nothing touches state until you do.

How does Terraform remember what it manages?

• 20. State file - Terraform's memory of what it manages.
• 21. Backend - where the state is stored: local disk, S3, Azure Storage, HCP Terraform.
• 22. Remote state - state kept in a shared place so a team can work together.
• 23. State locking - stops two people changing the state at the same time.
• 24. terraform state commands - list, show, mv, rm inspect or carefully edit the state.
• 25. Workspaces (CLI) - separate state instances for the same configuration. They share one backend, so they are not an isolation boundary, and they are not the same as HCP Terraform workspaces.

How do you structure and reuse code?

• 26. Modules - reusable packages of Terraform code.
• 27. Provider alias - use the same provider for several regions or accounts.
• 28. count vs for_each - create several copies by number, or by map or set.
• 29. dynamic blocks - generate repeated nested blocks, such as firewall rules, from a list.
• 30. Functions and expressions - helpers like merge, lookup, cidrsubnet, and conditionals like a ? b : c.

How does Terraform decide what order to do things in?

• 31. Implicit dependencies - Terraform works out the order on its own when one resource references another. This is the preferred way.
• 32. depends_on - set the order explicitly for hidden dependencies.
• 33. Lifecycle rules - create_before_destroy, prevent_destroy, ignore_changes.
• 34. moved and removed blocks - see the warning below.

depends_on has a cost. It is not a free way to be explicit. The docs say: "You should only use depends_on as a last resort" because "it can cause Terraform to create more conservative plans that replace more resources than necessary." Terraform marks more values as unknown, and the docs note this is "especially likely when you use depends_on for modules". Reference the other resource directly wherever you can, and let Terraform infer the edge.

# Removes from state AND destroys the real resource
removed {
  from = aws_instance.example
}

# Removes from state only, leaves the real resource alone
removed {
  from = aws_instance.example

  lifecycle {
    destroy = false
  }
}

How do you keep it safe and tested?

• 35. Validation, preconditions and postconditions - rules that stop the run when values are wrong.
• 36. check blocks - see below. These behave differently from the rules above.
• 37. terraform test - automated tests for your modules.
• 38. Ephemeral resources and write-only arguments - keep secrets out of plan and state files.

check blocks warn, they do not fail. Two things are commonly misstated here. First, they do not run only after apply. The docs say: "The check block executes as the last step of plan or apply operation." Second, and more importantly, a failed check does not stop anything: "Terraform reports a warning and continues executing the current operation."

That is the whole difference between check and preconditions or postconditions. A failed precondition halts the run. A failed check lets it finish and leaves a warning you might scroll past. Use preconditions for things that must be true, and checks for things you want to monitor. check blocks require Terraform v1.5.0 or later.

Ephemeral and write-only are two different features with different requirements. They are often mentioned in one breath, but they are not the same thing and they do not arrive together.

Write-only arguments also depend on the provider, not just on your Terraform version. The docs put it this way: "The implementation of write-only arguments and their version arguments is provider-specific, so consult the Registry for more details about your specific provider." So a recent Terraform is necessary but not sufficient - the resource has to support it too.

How do you bring existing infrastructure under Terraform?

• 39. Import - bring existing resources under Terraform's control.
• 40. Drift detection - terraform plan shows manual changes made outside Terraform.

Prefer the import block over the terraform import command. The docs recommend the block directly: "Instead of manually importing resources, you can add the import block to your Terraform configurations." The reason they give is automation: "Using Terraform configurations lets you automate resource imports as part of your CI/CD pipelines."

The block lives in your configuration, so it is reviewable and repeatable. The command is a one-off that mutates state from someone's laptop.

import {
  to = aws_instance.example
  id = "i-abcd1234"
}

resource "aws_instance" "example" {
  # ... configuration ...
}

For drift, terraform plan -refresh-only shows only how reality differs from your state, and terraform apply -refresh-only accepts those differences into state without changing any infrastructure.

When should you use each?

Many of these come down to picking between two options that look interchangeable but are not.

Bonus: provisioners can run scripts on machines, but the official docs are clear that they are a last resort. Reach for cloud-init, a configuration management tool, or a pre-baked image first.

Frequently asked questions

Official resources

• Output Values and the sensitive argument - HashiCorp
• terraform apply and the -replace option - HashiCorp
• The depends_on meta-argument - HashiCorp
• The removed block - HashiCorp
• Checks to validate infrastructure - HashiCorp
• Ephemeral resources - HashiCorp
• Write-only arguments - HashiCorp
• The import block - HashiCorp
• Manage multiple workspaces - HashiCorp