Where does a Terraform state lock physically live for the S3, GCS and local backends, and which of those actually protects a team?

## Locking is delegated, not implemented in core Terraform core defines an interface — take a lock, release a lock, report who holds it — and each backend implements it with whatever atomic primitive its storage system provides. There is no Terraform lock server. That is why the answer to "how does locking work" is always "which backend?", and why a backend that cannot offer an atomic conditional write cannot offer locking. ## S3: the lock object, and the DynamoDB era S3 stores objects; for a long time it could not do a conditional create, so the S3 backend borrowed one from DynamoDB. You created a table with a string partition key named exactly `LockID`, pointed the backend at it, and Terraform wrote an item keyed by `<bucket>/<key>` with a conditional expression that fails if the item already exists. Losing the race meant the conditional write failed, which surfaced as `Error acquiring the state lock`. The same table also held a `<bucket>/<key>-md5` digest item that Terraform used to notice a state file changed underneath it. S3 later gained conditional writes, and Terraform 1.10 added `use_lockfile = true` to the S3 backend: the lock becomes an object at `<key>.tflock` in the same bucket, created with an if-none-match precondition. No second service, no extra IAM surface, no table to forget to provision: ```hcl terraform { backend "s3" { bucket = "example-tfstate" key = "prod/network/terraform.tfstate" region = "us-east-1" use_lockfile = true } } ``` The DynamoDB path still works in existing configurations, but new state should use the native lock file; HashiCorp has moved the `dynamodb_table` attribute onto the deprecation path. A practical migration note: while you switch, run with both configured for one cycle so a run using the old mechanism and one using the new do not both think they hold the lock. ## GCS and azurerm The GCS backend writes a lock object alongside the state in the same bucket, using object-generation preconditions to make creation atomic. The azurerm backend uses a different primitive again: it takes a *lease* on the state blob. A lease is time-bounded at the storage layer, which is why a killed run against azurerm can leave a blob you cannot overwrite until the lease is broken. The shape is the same everywhere — an atomic create-if-absent on some object that stands for "a run is in progress", carrying the metadata Terraform prints when acquisition fails. ## HCP Terraform: a queue instead of an object HCP Terraform (and Terraform Enterprise) hold state server-side and queue runs per workspace. Only one run is active at a time by construction, so there is no lock object to inspect or delete; the equivalent of a stuck lock is a run stuck in the queue, and the equivalent of breaking the lock is cancelling that run through the API or UI. If you are asked to compare, this is the cleanest contrast: an object-store backend simulates a mutex with a conditional write, while a run-queue backend never allows two concurrent executions in the first place. ## The local backend, and why it misleads people The local backend is not lock-free: it takes an operating-system file lock on the state file. That genuinely prevents two `terraform apply` processes on the *same* machine from interleaving. What it cannot do is coordinate across machines — two engineers each holding their own copy of `terraform.tfstate` are not sharing anything to lock, so they are not racing on one file so much as maintaining two divergent records of the same infrastructure, which is strictly worse. Local state on a shared network filesystem is the worst of both: file locking semantics over NFS are unreliable, so the lock may appear to succeed for both runs. ## What this means in practice Two checks are worth making on any repository you inherit. First, does the configured backend lock at all, and is anything passing `-lock=false`? Second, can everyone who runs Terraform actually write the lock — an engineer with read-only access to the DynamoDB table or without `s3:PutObject` on the `.tflock` key gets an acquisition failure that looks like contention but is really an IAM problem. Reading the exact error text distinguishes them: a permissions failure names the API call, while genuine contention prints the `Lock Info` block with somebody else's identity in it.