Senior DevOps / SRE Terraform Repository Architecture Enterprise Architecture

Q: How would you structure dev/staging/prod?

Enterprise architectural comparison: Directory-based separation with reusable modules vs Terraform Workspaces, multi-account AWS strategy, and code reuse.

#Terraform #Architecture #Directory Layout #Workspaces #Multi-Account #DRY

🎙️ Candidate Opening & Architectural Context

"For enterprise production infrastructure, the recommended pattern is Directory-Based Separation using Reusable Modules across Multi-Account AWS environments, rather than Terraform Workspaces."

🛠️ Production Runbook & Step-by-Step Resolution

1️⃣

Why Directory-Based Separation Over Workspaces

Understanding the fundamental tradeoff:

Terraform Workspaces: Workspaces share the exact same backend, variables, and code. A single typo in main.tf affects all environments. Workspaces are suitable for testing identical ephemeral branches, but NOT for long-lived Dev/Staging/Prod.
Directory-Based Separation: Completely isolates state files, backend credentials, variables, and provider accounts. An error in Dev cannot touch Production state.

2️⃣

Recommended Repository Layout

Standardized modular directory structure:

terraform/
├── modules/                # Reusable building blocks
│   ├── vpc/
│   ├── eks/
│   └── rds/
└── environments/
    ├── dev/
    │   ├── backend.tf      # S3 backend: key = dev/terraform.tfstate
    │   ├── main.tf         # Calls modules with dev variables
    │   └── terraform.tfvars
    ├── staging/
    └── prod/
        ├── backend.tf      # S3 backend: key = prod/terraform.tfstate
        ├── main.tf
        └── terraform.tfvars

3️⃣

Multi-Account AWS Strategy

Maximum security and blast radius isolation:

Deploy each environment to a dedicated AWS Account: AWS Account Dev, AWS Account Staging, AWS Account Prod under AWS Organizations.
Dev CI/CD runner IAM credentials only have access to the Dev AWS Account.
Production state bucket lives in the Production AWS account with strict KMS key policies.

4️⃣

Version Pinning & Promotion Workflow

How code moves from Dev to Prod:

Environments reference modules using Git tags: source = 'git::https://github.com/org/tf-modules.git//eks?ref=v1.4.0'.
Test module v1.5.0 in Dev.
Promote to Staging and validate with integration tests.
Promote to Prod only after Staging is verified stable.

💡 The Senior SRE Gold Nugget (Key Architectural Takeaway)

"Use directory-based separation with version-pinned reusable modules and separate AWS accounts per environment. Avoid workspaces for multi-environment cloud infrastructure due to shared backend risks."

⚡ 60-Second Elevator Pitch Talking Points

Architecture: Directory-based separation with reusable modules (avoid workspaces for dev/prod due to shared backend blast radius).
Multi-Account: Separate AWS accounts for Dev, Staging, and Prod under AWS Organizations.
State Isolation: Distinct S3 backend keys and DynamoDB locks per environment.
Module Versioning: Environments source modules pinned to immutable Git tags (ref=v1.2.0).
Promotion: Changes are applied to Dev first, validated in Staging, and promoted to Prod via CI/CD approval.