Terraform State: Backends, Locking, Remote State, and Drift

The local backend is what Terraform uses when your configuration declares no backend or cloud block: it stores state as a terraform.tfstate file in the current working directory and keeps the previous version in terraform.tfstate.backup. You never have to configure it - run terraform init and terraform apply in a fresh directory and the local backend is already in effect.

You can also declare it explicitly, which is mainly useful for pointing state at a non-default path:

terraform {
  backend "local" {
    path = "state/terraform.tfstate"
  }
}

The local backend does support state locking - Terraform takes a lock on the state file on disk, so two terminals on the same machine cannot write it simultaneously. What it cannot do is share state: the file exists only on one machine, teammates cannot see it, there is no central lock across machines, and any sensitive attribute values (passwords, keys) sit in plain text on a laptop. That combination is exactly why the exam expects you to reach for a remote backend for any team or production workflow.

State locking makes Terraform acquire a lock before any operation that could write state - plan, apply, destroy, and the state-modifying subcommands - and hold it until the operation finishes. Without it, two people running terraform apply against the same state at the same time could interleave writes and leave the file corrupted or missing resources, which is one of the worst failure modes in Terraform. Locking happens automatically whenever the backend supports it; you do not enable it in configuration.

Most commonly used backends support locking: local (a lock on the state file), s3 (a native S3 lock file via use_lockfile = true; the older DynamoDB-table mechanism is deprecated), gcs, azurerm (a blob lease), kubernetes, consul, pg, and the remote backend / HCP Terraform. If another run holds the lock, your command fails with a lock error that includes a lock ID.

Two flags control locking behavior per command, and one command exists for emergencies:

terraform apply -lock-timeout=5m     # retry acquiring the lock for up to 5 minutes
terraform apply -lock=false          # skip locking entirely (discouraged)
terraform force-unlock LOCK_ID       # manually release a stuck lock

terraform force-unlock is a last resort: use it only when a lock was left behind by a crashed run and you are certain no other operation is still in progress. It takes the lock ID reported in the error and only releases locks for the current configuration. Disabling locking with -lock=false reintroduces the corruption risk locking exists to prevent, so the exam treats it as almost never the right answer.

You configure remote state by adding a backend block inside the top-level terraform block, naming a backend type and its settings. A configuration can have at most one backend (or a cloud block for HCP Terraform, but not both). Terraform 1.12 ships backends including s3, gcs, azurerm, kubernetes, consul, pg, http, oss, cos, and remote.

terraform {
  backend "s3" {
    bucket       = "acme-tf-state-prod"
    key          = "network/terraform.tfstate"
    region       = "us-east-1"
    use_lockfile = true
  }
}

A Google Cloud equivalent uses the gcs backend, which locks natively with no extra settings:

terraform {
  backend "gcs" {
    bucket = "acme-tf-state"
    prefix = "prod/network"
  }
}

Two rules are heavily tested. First, backend configuration is evaluated before almost anything else, so it cannot reference variables, locals, or any named values - every argument must be a literal (or be supplied at init time, covered next). Second, any change to the backend block only takes effect after you re-run terraform init. Remote state gives the team one shared source of truth with locking and durable storage, but remember the state itself still contains sensitive values - protect the bucket or container with encryption and tight access controls.

Partial configuration means leaving some backend arguments out of the backend block and supplying them when you run terraform init. Because the block cannot use variables, this is the supported way to keep secrets and per-environment values (bucket names, access credentials) out of version control. You pass the missing values with -backend-config, either as a file of key/value pairs or as individual pairs:

terraform init -backend-config=prod.s3.tfbackend

terraform init \
  -backend-config="bucket=acme-tf-state-prod" \
  -backend-config="key=network/terraform.tfstate" \
  -backend-config="region=us-east-1"

Terraform merges these with whatever is in the block and can prompt interactively for anything still missing.

When you change the backend - say, moving from local to s3 - terraform init detects the change and refuses to proceed until you choose what to do with existing state. Run terraform init -migrate-state to copy the current state into the new backend (Terraform prompts for confirmation), or terraform init -reconfigure to adopt the new backend configuration while ignoring the old one entirely, without migrating anything. Migration is the normal path: it is how you promote a laptop-only project to shared remote state without losing the mapping to existing infrastructure.

The terraform_remote_state data source lets one configuration read another configuration's state file and consume its root module outputs. It is how a separately managed application stack can reference, for example, the subnet IDs that a network stack created, without hard-coding them:

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "acme-tf-state-prod"
    key    = "network/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_instance" "app" {
  ami           = "ami-0abcd1234example"
  instance_type = "t3.micro"
  subnet_id     = data.terraform_remote_state.network.outputs.subnet_id
}

Two exam-relevant limits. Only values the producing configuration explicitly declares as output blocks in its root module are visible - internal resources and module outputs that were not re-exported are not. And to read the outputs, the consumer needs read access to the entire state file, which may contain sensitive data; where the provider offers a normal data source for the same information (for example a data lookup by tag), that is often the better-scoped choice. Use terraform_remote_state when the producing side is also Terraform and you control both configurations.

Drift is when real infrastructure no longer matches what Terraform state recorded - someone resized an instance in the console, a security rule was deleted by hand, an external process changed a tag. Terraform detects drift by refreshing: reading the real remote objects through the provider and comparing them to state. A normal terraform plan refreshes first, then diffs the refreshed picture against your configuration, so drifted attributes show up as planned changes; since Terraform 0.15.4 the refreshed data is used in memory for that plan but is not persisted to the state file by plan itself.

To look at drift in isolation, use refresh-only mode. A refresh-only plan proposes no infrastructure changes at all - it only shows what Terraform would update in state to match reality, and a refresh-only apply writes those updates to state:

terraform plan -refresh-only    # preview drift: what state would change
terraform apply -refresh-only   # accept drift into state, change no infrastructure

The standalone terraform refresh command still exists but is deprecated: it behaves like terraform apply -refresh-only -auto-approve, silently rewriting state with no chance to review, which is exactly why the reviewed -refresh-only workflow replaced it. Once drift is visible you have two honest options: run a normal terraform apply to push infrastructure back to what the configuration declares, or update the configuration (and accept the drift with a refresh-only apply) if the out-of-band change is what you actually want.

The terraform state subcommands (plus a few related top-level commands) let you inspect and rewrite the state's mapping without touching infrastructure. These appear constantly in objective 6 questions:

The deprecation pattern is a favorite exam theme: terraform taint gave way to the plannable terraform apply -replace="aws_instance.web", just as terraform refresh gave way to -refresh-only. Similarly, modern configuration-driven alternatives exist for state surgery itself - a moved block records a rename in configuration instead of a one-off state mv, and a removed block (Terraform 1.7+) can forget a resource in a reviewed plan instead of state rm.

terraform state mv aws_instance.app aws_instance.web
terraform apply -replace="aws_instance.web"

Remember the boundary: state mv and state rm edit only Terraform's records. state rm never destroys anything - the resource keeps running, Terraform just stops managing it (and a later plan may propose creating a duplicate if the configuration still declares it).