Remote State on Azure Storage
Store Terraform state securely in Azure Blob Storage with locking for teams.
Terraform records what it manages in a state file. Locally that’s
terraform.tfstate — fine solo, dangerous for teams. The azurerm backend
stores state in an Azure Storage blob so the whole team shares one source of
truth, and Azure Blob’s native lease provides state locking to prevent
concurrent applies from corrupting it.
State can contain secrets (passwords, keys), so the storage account must be private, encrypted, and access-controlled. A common pattern is a dedicated “bootstrap” resource group holding the state storage account.
terraform {
backend "azurerm" {
resource_group_name = "rg-tfstate"
storage_account_name = "sttfstate0001"
container_name = "tfstate"
key = "prod.terraform.tfstate"
}
}terraform init # migrates/initializes the remote backend
terraform plan # state is now read from Azure Blob, with locking- Configure an azurerm backend block pointing at a storage container.
- Explain why remote state with locking matters for a team.
- List two reasons the state storage account must be tightly secured.
- Describe the “bootstrap” pattern for creating the state backend itself.
Cheat Sheet▾
| Item | Detail |
|---|---|
| Local state | terraform.tfstate (solo only) |
| Remote backend | backend "azurerm" |
| Locking | Azure Blob lease (automatic) |
| Secrets risk | State may hold plaintext secrets |
| Secure with | Private account, RBAC, encryption |
| Init | terraform init migrates state |
Common Interview Questions▾
Why use remote state with locking?
It gives a team one shared, authoritative state and prevents two simultaneous applies from racing and corrupting it — Azure Blob’s lease provides the lock.
Why must Terraform state be kept secure?
State can contain plaintext secrets and a full map of your infrastructure, so it must be private, encrypted at rest, access-controlled, and never committed to git.