Destroy and Format

What it is

terraform destroy removes every object that the current working directory and workspace manage, according to state. It is the end of a configuration's life cycle, common for short-lived test and development environments.

terraform fmt rewrites configuration files into Terraform's canonical format and style. It changes layout only, never meaning, and is usually run before every commit or checked in a pipeline.

How it works

Destroying everything

terraform plan -destroy
terraform destroy

terraform destroy is a shortcut for terraform apply -destroy. It builds a plan in which every managed object is marked -, shows it and waits for yes; -auto-approve skips the prompt.

terraform plan -destroy previews the same plan without changing anything. You can save it with -out=FILE and apply that file later.

Terraform destroys in reverse dependency order: an instance goes before the subnet it sits in, and the subnet before its VPC. Objects that Terraform does not manage are never touched, even if they sit in the same account.

After a destroy

The configuration files are not touched, and the state file remains with no resources in it. Running terraform apply again builds the whole environment from scratch, which is why destroy suits temporary environments.

Destroying part of the infrastructure

Deleting a block is the normal way to remove one object. The next plan shows it with -, because it is in state but no longer in the configuration.

resource "aws_db_instance" "main" {
  # ... other arguments ...

  lifecycle {
    prevent_destroy = true
  }
}

With prevent_destroy, any plan that would destroy this object, including terraform destroy, fails with an error. It does not help if you delete the whole resource block, because the setting goes with it.

Formatting with terraform fmt

terraform fmt
terraform fmt -recursive
terraform fmt -check

By default fmt rewrites .tf and .tfvars files in the current directory only and lists the files it changed. -recursive also processes subdirectories, such as local modules.

-check is the usual choice in a pipeline, where a non-zero exit fails the build.

What fmt changes

resource "aws_instance" "web" {
  ami           = "ami-0123456789abcdef0"
  instance_type = "t3.micro"

  tags = {
    Name = "web"
  }
}

The output above is canonical: two spaces per nesting level and the equals signs of consecutive arguments aligned. fmt fixes indentation, alignment and spacing like this, but it keeps your blank lines rather than adding them.

fmt does not rename resources, reorder blocks, catch wrong values or fix logic. A file with a syntax error cannot be parsed, so fmt reports the error instead of formatting it.

Style conventions beyond fmt

HashiCorp's style guide adds habits that fmt does not enforce: lowercase names with underscores, meta-arguments such as count or for_each first in a block, and nested blocks after arguments. Common file names are main.tf, variables.tf, outputs.tf and providers.tf.

How the exam asks about this

• "Preview what terraform destroy would remove without removing anything." Run terraform plan -destroy.
• "A pipeline must fail when configuration is not formatted, without rewriting files." Use terraform fmt -check, with -recursive to include subdirectories.
• "True or false: terraform destroy is equivalent to terraform apply -destroy." True.