HashiCorp Certified: Terraform Associate
Remote state, backends and state locking for Terraform Associate
By default Terraform keeps state in a local file named terraform.tfstate, which is hard to share. A backend block inside the terraform block stores state in a remote service so a team shares one copy. If the backend supports locking, Terraform locks the state for every operation that could write it, so two runs cannot write at the same time.
Why remote state
With a local state file, each person must make sure they have the latest state before running Terraform, and that nobody else runs Terraform at the same time. With remote state, Terraform writes state to a shared data store. Supported stores include HCP Terraform, Consul, Amazon S3, Azure Blob Storage, Google Cloud Storage and Alibaba Cloud OSS.
Remote state also lets other configurations read your root module outputs through the terraform_remote_state data source. For example, a network team can expose VPC and subnet IDs that application teams consume read-only.
If no backend is configured, Terraform uses the local backend, which stores state as a file on disk.
Configuring the backend block
Put a nested backend "<type>" block inside the top-level terraform block. A configuration can have only one backend block. A backend block cannot refer to input variables, locals or data source attributes. A configuration with a cloud block for HCP Terraform cannot also have a backend block.
Values that differ per environment or are sensitive can be left out. This is a partial configuration. You supply the rest at terraform init with -backend-config=PATH (a file such as prod.s3.tfbackend), with -backend-config="KEY=VALUE", or by answering prompts.
HashiCorp recommends supplying credentials through environment variables. Values given with -backend-config or written into the configuration end up in plain text in the .terraform directory and in plan files.
When you change the backend, run terraform init again. Terraform offers to migrate the existing state to the new backend. HashiCorp recommends backing up terraform.tfstate before migrating.
State locking
If the backend supports it, Terraform locks the state automatically for every operation that could write state. You do not see a message unless getting the lock takes a while. If locking fails, Terraform stops. Not every backend supports locking; each backend's page says whether it does. The local backend locks the state file using system APIs.
-lock-timeout=DURATION, such as -lock-timeout=5m, makes Terraform retry for that long before failing. The default is 0s, which fails at once if someone else holds the lock. -lock=false turns locking off. HashiCorp does not recommend it, because concurrent runs against the same state become possible.
force-unlock
If automatic unlocking failed, for example because a run was killed, terraform force-unlock LOCK_ID removes the lock. Terraform prints the lock ID when unlocking fails. The command does not change your infrastructure.
Use it only to release your own lock. If you unlock a lock that another person's run is holding, two writers can change the state at once.
Where the exam catches people
- Believing a backend block can use
var.bucket: backend blocks cannot refer to variables, locals or data sources. Supply the value withterraform init -backend-config. - Believing every backend locks state: not all do. Check the backend's documentation.
- Believing
-lock=falseis the fix when a pipeline hits a held lock: use-lock-timeoutto wait. Turning locking off allows concurrent writes. - Believing
force-unlockis safe whenever a run is waiting: use it only for your own lock that failed to release. - Believing
-backend-configkeeps secrets out of files: its values are stored in plain text in.terraformand in plan files. Use environment variables for credentials.