What if I lose the state file?

Terraform no longer knows what it manages, and it may try to create duplicates. You can rebuild state by importing existing resources, which is tedious, so back up state through a versioned remote backend.

Does a remote backend make secrets safe?

It protects state from loss and concurrent changes, but the secrets inside are still plain text. Restrict access tightly, encrypt the storage, and avoid putting secrets in state wherever the provider allows.

Terraform State, Remote Backends, and Protecting Secrets

Introduction

State is how Terraform remembers what it manages. It makes everything work, and it is also the most sensitive and fragile file in a Terraform project. This lesson explains what state contains, why local state does not suit teams, and how a remote backend with locking solves the problem.

Prerequisites

Terraform variables and outputs lesson

Step-by-Step Guide

Step 1: See what state is

State maps the resources in your configuration to the real objects Terraform created and records their attributes. By default it is a JSON file named terraform.tfstate in your working folder, with a backup of the previous version beside it. Do not edit it by hand. Inspect it with commands instead.

terraform state list
terraform show

Step 2: Never commit state to Git

State can contain secrets in plain text, including passwords and keys that providers return, and Git has no locking, so two people applying at once can corrupt it or lose data. Ignore state files, the .terraform folder, saved plan files, and any tfvars files with secrets, and treat saved plans as sensitive too.

# .gitignore
.terraform/
*.tfstate
*.tfstate.*
*.tfplan
*.auto.tfvars

Step 3: Why teams need a remote backend

With local state, each person has a different view of reality. A remote backend stores state in one shared, secure place, supports locking so only one apply runs at a time, and can keep a version history. Common choices are an object storage bucket, a cloud-hosted Terraform service, or another supported backend.

Step 4: Configure an S3 backend with locking

The S3 backend stores state in a bucket. Locking is opt-in: the use_lockfile setting enables S3-native locking, and the older DynamoDB table method is deprecated. Turn on versioning for the bucket so you can recover earlier state, keep it private and encrypted, and supply credentials through environment variables rather than putting them in the configuration. Run terraform init again after adding or changing a backend.

terraform {
  backend "s3" {
    bucket       = "my-team-terraform-state"
    key          = "projects/app/terraform.tfstate"
    region       = "us-east-1"
    use_lockfile = true
  }
}

Step 5: Protect the state and the plan

Restrict who can read the state bucket, because reading state can reveal secrets. Prefer short-lived credentials and secrets managers over long-lived keys written into configuration. In team pipelines, run plan on pull requests, require review of the plan, and apply only from the main branch using the reviewed plan file, which is deleted afterward.

terraform plan -out=tfplan
terraform apply tfplan

FAQs

What if I lose the state file?: Terraform no longer knows what it manages, and it may try to create duplicates. You can rebuild state by importing existing resources, which is tedious, so back up state through a versioned remote backend.
Does a remote backend make secrets safe?: It protects state from loss and concurrent changes, but the secrets inside are still plain text. Restrict access tightly, encrypt the storage, and avoid putting secrets in state wherever the provider allows.

Summary

State links your code to real infrastructure, so keep it out of Git, store it in a private, versioned remote backend with locking, and treat both state and saved plans as sensitive.