Backends and Remote State — Terraform Basics | CertQnA

Backend configuration determines where Terraform stores state and whether it can lock state to prevent concurrent modifications. Choosing and configuring the right backend is critical for any team using Terraform.

The Default Local Backend

Without a backend block, Terraform stores state in terraform.tfstate on disk. This works for solo projects but fails for teams because:

State is not shared between team members
No locking — two people can corrupt state by applying simultaneously
State file contains secrets — easy to accidentally commit

S3 Backend (AWS)

The most common backend for AWS-based teams. Requires an S3 bucket (for state storage) and a DynamoDB table (for locking):

# Create the S3 bucket for state
aws s3api create-bucket --bucket my-terraform-state --region us-east-1
aws s3api put-bucket-versioning --bucket my-terraform-state   --versioning-configuration Status=Enabled
aws s3api put-bucket-encryption --bucket my-terraform-state   --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

# Create the DynamoDB table for locking
aws dynamodb create-table   --table-name terraform-state-lock   --attribute-definitions AttributeName=LockID,AttributeType=S   --key-schema AttributeName=LockID,KeyType=HASH   --billing-mode PAY_PER_REQUEST

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "production/networking/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}

GCS Backend (GCP)

terraform {
  backend "gcs" {
    bucket  = "my-terraform-state"
    prefix  = "production/networking"
  }
}

Azure Blob Storage Backend

terraform {
  backend "azurerm" {
    resource_group_name  = "terraform-state-rg"
    storage_account_name = "myterraformstate"
    container_name       = "tfstate"
    key                  = "production.networking.tfstate"
  }
}

Terraform Cloud Backend

Terraform Cloud (from HashiCorp) is a managed platform with:

Remote state storage with encryption
Remote plan and apply execution
Run history and approval workflows
Sentinel policy-as-code
Variable management

terraform {
  cloud {
    organization = "my-company"
    workspaces {
      name = "production-networking"
    }
  }
}

Reading Remote State from Another Configuration

The terraform_remote_state data source lets one Terraform configuration read the outputs of another. This is how large infrastructure is split into multiple state files while remaining connected:

# In the application stack — read VPC outputs from the networking stack
data "terraform_remote_state" "networking" {
  backend = "s3"
  config = {
    bucket = "my-terraform-state"
    key    = "production/networking/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_db_subnet_group" "main" {
  subnet_ids = data.terraform_remote_state.networking.outputs.private_subnet_ids
}

Workspaces

Workspaces allow multiple state files in the same backend configuration — useful for dev/staging/prod:

terraform workspace new staging
terraform workspace select production
terraform workspace list
terraform workspace show

# Reference workspace in config
locals {
  env = terraform.workspace
}

resource "aws_instance" "app" {
  instance_type = local.env == "production" ? "t3.large" : "t3.micro"
}

Note: For production systems, prefer separate state files in separate directories over workspaces. Workspaces share the same configuration, making it easy to accidentally destroy production when targeting staging.

Next: The Terraform Workflow — init, validate, plan, apply, destroy in detail, with CI/CD integration patterns.