Multi-env Terraform layout

One environment is easy. Three is where teams discover Terraform best practices. Modules let dev, staging, and prod share configuration. Remote state lets the team avoid stepping on each other. Workspaces isolate each environment cleanly.

terraform/dev/main.tf

hcl

module "lakehouse" {
  source = "../modules/lakehouse"

  pipeline_name   = "lwp-aws-lakehouse-dev"
  datalake_bucket = "learnwithparam-aws-lakehouse-dev"
  scripts_bucket  = "learnwithparam-aws-lakehouse-scripts-dev"
  region          = "us-east-1"
}

Each environment is a thin wrapper around a shared module. Variables differ per env. Code is identical. Drift between environments becomes impossible.

Remote state lives in S3 with DynamoDB locking. The first thing every Terraform module does is configure backend. Without it, two engineers running terraform apply at the same time produces a corrupted state file. With it, the second one waits until the first finishes.

Separate state files per env is more explicit and harder to mess up. Workspaces are convenient for ephemeral envs but easy to apply to the wrong one. The course uses separate state files because production matters more than typing convenience.