Terraform providers, state, plans and modules

Why and what

Terraform configurations declare resources through providers. State maps configuration addresses to real resources and can contain sensitive values. A plan describes proposed changes; apply performs them. Deleting a resource block can plan real destruction, so review every plan.

Minimal lab

Install a reviewed Terraform version and authenticate to a sandbox AWS account using temporary credentials. Create main.tf:

terraform {
  required_version = ">= 1.10, < 2.0"
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 6.0" }
  }
}
provider "aws" { region = "ap-south-1" }
resource "aws_s3_bucket" "lab" {
  bucket_prefix = "academy-lab-"
  tags = { Project = "cloud-academy" }
}
resource "aws_s3_bucket_public_access_block" "lab" {
  bucket = aws_s3_bucket.lab.id
  block_public_acls = true
  block_public_policy = true
  ignore_public_acls = true
  restrict_public_buckets = true
}
output "bucket_name" { value = aws_s3_bucket.lab.id }

terraform fmt
terraform init
terraform validate
terraform plan -out=lab.plan
terraform apply lab.plan
terraform output

Commit configuration and the provider lock file, but not state, plan files or secrets. Review provider version compatibility when updating the sample.

Remote state

Use a separately bootstrapped private, encrypted, versioned S3 state bucket and supported state locking. Modern Terraform S3 backends support use_lockfile = true; coordinate versions before enabling it. Restrict read/write permissions because state can expose credentials. Never put AWS access keys in backend configuration or source.

Modules and environments

Modules package related resources with inputs/outputs. Separate environments by clear state/account boundaries; a workspace name alone is not an access-control boundary. Use import for existing resources after planning their configuration, and moved blocks when refactoring addresses where appropriate.

Failure and drift

A failed apply can leave partial changes. Inspect state and actual resources before rerunning or deleting state. Never force-unlock without confirming no active writer owns the lock. Use plans to detect drift, but understand provider-specific visibility limits.

Assignment and cleanup

Add a tag, inspect the plan, apply and verify. Review a destroy plan and remove only the disposable lab resources. A nonempty bucket requires intentional content cleanup; do not enable force_destroy on valuable data just to simplify the lab.

Official references

Terraform AWS tutorial Terraform S3 backend

Interview and revision check

Why protect a state file like a secret?

State can contain sensitive resource values and mappings. Limit access, encrypt storage and coordinate writes with locking.