Week 10: Terraform Modules & Remote State

1. Input Variables & Outputs

You already used a variable block in Week 9 to parameterize a bucket name. Variables can also declare a type, a default, and validation rules, which turns a typo into an immediate error instead of a confusing plan later:

variable "environment" {
  description = "Deployment environment name"
  type        = string
  default     = "dev"

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "environment must be one of: dev, staging, prod."
  }
}

variable "enable_versioning" {
  description = "Whether to enable S3 bucket versioning"
  type        = bool
  default     = false
}

Values can come from a terraform.tfvars file, a -var flag, or an environment variable prefixed TF_VAR_ — useful for keeping a value out of a file entirely:

environment       = "dev"
enable_versioning = true

Outputs are the reverse direction: values Terraform prints after apply, and — more importantly — values one module exposes so another module or the root configuration can consume them:

output "bucket_arn" {
  description = "ARN of the created bucket"
  value       = aws_s3_bucket.this.arn
}

output "bucket_id" {
  value = aws_s3_bucket.this.id
}

2. Writing a Reusable Module

A module is just a directory of .tf files with its own variables and outputs — every configuration you've written so far is technically the "root module". Pulling repeated infrastructure into its own module directory means you write the S3-bucket-with-versioning pattern once and reuse it for every bucket your team creates:

variable "bucket_name" {
  description = "Globally unique S3 bucket name"
  type        = string
}

variable "environment" {
  type = string
}

variable "enable_versioning" {
  type    = bool
  default = false
}

resource "aws_s3_bucket" "this" {
  bucket = var.bucket_name

  tags = {
    Environment = var.environment
    ManagedBy   = "terraform"
  }
}

resource "aws_s3_bucket_versioning" "this" {
  count  = var.enable_versioning ? 1 : 0
  bucket = aws_s3_bucket.this.id

  versioning_configuration {
    status = "Enabled"
  }
}

output "bucket_arn" {
  value = aws_s3_bucket.this.arn
}

output "bucket_id" {
  value = aws_s3_bucket.this.id
}

A root configuration then calls the module with a module block, pointing source at the module's path and passing its variables as arguments:

module "app_logs" {
  source = "../../modules/s3-bucket"

  bucket_name       = "codeverse-app-logs-ada"
  environment       = "dev"
  enable_versioning = true
}

output "app_logs_bucket_arn" {
  value = module.app_logs.bucket_arn
}

The count = var.enable_versioning ? 1 : 0 trick is a common pattern for making a resource conditional — Terraform doesn't have an if statement, but a resource with count = 0 simply isn't created. Run terraform init again after adding a module block; it needs to fetch and register the module's contents just like a provider.

3. Remote State Backends

Local state — a terraform.tfstate file sitting next to your .tf files — works for a single person experimenting, and stops working the instant a second person needs to run apply against the same infrastructure: there's no shared source of truth, no lock to stop two applies from racing, and the file itself would have to be emailed or committed to be shared at all.

A remote backend moves state into shared storage that everyone's Terraform client reads from and writes to. The standard AWS pattern pairs an S3 bucket (durable storage for the state file, with versioning so a bad state can be rolled back) with a DynamoDB table (a lock, so only one apply can run at a time):

aws s3api create-bucket --bucket codeverse-terraform-state --region us-east-1
aws s3api put-bucket-versioning \
  --bucket codeverse-terraform-state \
  --versioning-configuration Status=Enabled

aws dynamodb create-table \
  --table-name terraform-locks \
  --attribute-definitions AttributeName=LockID,AttributeType=S \
  --key-schema AttributeName=LockID,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

This is one of the rare cases where creating infrastructure by hand (or in a tiny, separate Terraform config with its own local state) is correct — the backend that stores your state can't also store its own state, so it has to be bootstrapped outside the system it will end up supporting.

terraform {
  backend "s3" {
    bucket         = "codeverse-terraform-state"
    key            = "dev/app-logs/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

$ terraform init
Initializing the backend...
Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "local" backend
  to the newly configured "s3" backend.

  Enter "yes" to copy and "no" to start with an empty state.

  Enter a value: yes

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

The key is the state file's path inside the bucket — using a different key per environment (dev/app-logs/terraform.tfstate, prod/app-logs/terraform.tfstate) is how you keep dev and prod state fully isolated from each other while reusing the same bucket and module.

4. Team Collaboration: Locking & Avoiding Concurrent Applies

With the DynamoDB table wired up, Terraform automatically acquires a lock at the start of every plan or apply and releases it when the command finishes. If a teammate tries to run apply while yours is still in progress, they get a clear error instead of two processes corrupting the same state file:

$ terraform apply
Error: Error acquiring the state lock

Lock Info:
  ID:        7f3a2b1c-9e4d-4a2f-8b3e-2d1c4f5a6b7c
  Path:      codeverse-terraform-state/dev/app-logs/terraform.tfstate
  Operation: OperationTypeApply
  Who:       ada@ci-runner
  Created:   2026-08-03 14:22:10 UTC

Terraform acquires a state lock to protect the state from being written
by multiple users at the same time. Please resolve the issue above and
try again.

You wait for the lock to clear naturally in almost every case. terraform force-unlock <LOCK_ID> exists for the rare case where a process crashed mid-apply and left a stale lock behind — but running it while an apply is genuinely still in progress is exactly how two concurrent applies corrupt state, so treat it as a last resort you confirm with your team first, not a routine command.

The rest of safe collaboration is process, not tooling: infrastructure changes go through a pull request like any other code change (the same Git branching workflow from Week 2), a CI job runs terraform plan and posts the output as a comment for review, and only a merged, approved PR triggers the actual apply — mirroring the required-reviewer pattern from Week 7's GitHub Environments, just gating infrastructure changes instead of application deploys.

5. Hands-on Exercise

6. Knowledge Check

Four quick questions. Expand each to check your answer.