Terraform
This section documents our opinionated approach to writing, organizing, and operating Terraform code. It covers naming conventions, structural guidelines, state management, and everyday best practices that every engineer working on infrastructure should follow.
Sections
| Section | Description |
|---|---|
| Naming Conventions | Standardized resource and variable naming patterns |
| Backends | Remote state configuration and locking strategies |
| Module Structure | How to structure reusable Terraform modules |
| Code Organization | Repository layout and file structure guidelines |
| Variables & Outputs | Variable typing, validation, and output conventions |
| Providers | Provider version pinning and configuration |
| Modules | Module design principles |
| Secrets Management | Keeping secrets out of version control |
| CI/CD Pipeline | Workflow rules, validations, drift detection, and GitHub Actions pipeline setup |
| Lifecycle & Version Management | Destroy protection and Terraform version pinning |
Guiding Principles
- Consistency over preference: follow the patterns in this playbook even when you disagree; raise a discussion to change the standard instead of diverging silently.
- Least privilege by default: every IAM permission, policy, and role should grant only what is needed.
- State is sacred: treat the Terraform state as production data; protect it with encryption, access controls, and locking.
- Code review everything: no
terraform applyruns directly from a developer machine against production; all changes go through CI/CD.