Design a Terraform module structure for a multi-account AWS organization with 50+ teams. How do you handle shared infrastructure, per-team customization, and drift detection?
Quick Answer
Use a layered module architecture: platform modules for shared infra, team-facing wrapper modules for self-service, separate state per account/component, and automated drift detection via CI.
Detailed Answer
Architecture Layers
Layer 1: Platform Modules (maintained by platform team) - VPC, networking, IAM baseline, logging, security guardrails - Published as versioned modules in a private registry (Terraform Cloud or S3) - Semantic versioning: teams pin to major versions, get patches automatically
Layer 2: Team Modules (self-service wrappers) - Opinionated wrappers around platform modules - Example: team-service module creates ECS service + ALB + DNS + monitoring - Teams provide minimal inputs: service name, container image, CPU/memory - Enforces organizational standards (tagging, encryption, logging)
Layer 3: Team Configurations (per-team repos) - Each team has a repo with their environment definitions - Uses team modules via versioned references - Separate state files per environment (dev/staging/prod)
Multi-Account Strategy
- Separate AWS accounts per environment per team (AWS Organizations) - Cross-account IAM roles for Terraform execution - Shared services account for networking, DNS, artifact repositories - State files in a central management account S3 bucket with per-team prefixes
Drift Detection
- Scheduled CI pipeline runs terraform plan nightly across all state files - Alerts on any non-empty plan output (drift detected) - Quarantine: drifted resources tagged, team notified, auto-PR generated
Policy Enforcement
- OPA/Sentinel policies in CI: no public S3 buckets, encryption required, tagging mandatory - Pre-commit hooks for terraform fmt and validate
Code Example
# Module registry structure
modules/
├── platform/
│ ├── vpc/ # Shared VPC module
│ ├── iam-baseline/ # Account security baseline
│ └── logging/ # CloudWatch + S3 log aggregation
├── team/
│ ├── ecs-service/ # Self-service ECS deployment
│ ├── rds-instance/ # Managed database provisioning
│ └── s3-bucket/ # Compliant S3 bucket
└── teams/
├── team-alpha/
│ ├── dev/
│ │ └── main.tf # Uses team/ecs-service v2.1
│ └── prod/
│ └── main.tf
└── team-beta/
└── ...Interview Tip
This is a staff+ platform engineering question. Key signals: versioned module registry, separation of concerns between platform and team layers, per-account state isolation, and automated drift detection. Don't just describe the structure — explain WHY each layer exists.