Multi-env layout for GCP

Three environments. Same code. Different GCP projects (or at least different datasets and buckets). Terraform modules and per-env state files make this clean. The course shows the layout that scales beyond one engineer per environment.

terraform/dev/main.tf

hcl

terraform {
  backend "gcs" {
    bucket = "learnwithparam-tfstate-dev"
    prefix = "ecommerce-bq-dbt"
  }
}

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

  gcp_project_id = "learnwithparam-dev"
  region         = "us-central1"
  gcs_raw_bucket = "learnwithparam-ecommerce-raw-dev"
  bq_dataset     = "ecommerce_marts_dev"
}

Each env folder calls the shared module with its own vars. Code is identical. Drift between envs becomes impossible.

Remote state lives in GCS with object locking via Cloud Storage versioning. Two engineers running terraform apply at the same time means one sees a "state locked" error and waits. With local state, you would corrupt the file silently.

A standard flow. Apply to dev. Verify with smoke tests. Open a PR that updates the prod env folder. Review. Merge. Apply to prod from CI with a service account that has the production role binding. Never apply to prod from a developer laptop.