Terraform Practices - The Good, the Bad and the Ugly
summary
Concrete rules and concrete tools: lock provider/module versions and expect breakages when major bumps occur; apply use remote backend S3 with versioning and tfstate locking for backups and secrets; tag every resource consistently to enable cost and ownership tracking; prefer vetted community modules with pinned versions or build stateless generic modules with defaults and validation; keep small state per feature/team, avoid large monoliths, run Terraform remotely, require plan files, and enforce quality via pre-commit, GitHub Actions and Atlantis.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 1:28Introduction
- 3:12Version locking
- 4:38Resource tagging
- 6:26Remote state management
- 8:13Community modules
- 10:19Variables and locals
- 13:55File structure
- 15:41Code best practices
- 18:49Code structuring
- 21:00Workspaces
- 24:50Scalability structuring
- 26:57Remote execution
- 28:43Code quality checks
- 31:54Key takeaways
- 34:20Closing
related talks
29mTerraform Practices - The Good, the Bad, and the Ugly
41mTerraform Practices - The Good, the Bad, and the Ugly
15mTerraform Practices: The Good, the Bad, and the Ugly
30mTerraform Practices to Enable Infrastructure Scaling
31mTerraform Practices to Enable Infrastructure Scaling
46mTerraform best practices with examples and arguments
01h 00mGotchas using Terraform in a secure delivery pipeline
46mTerraform best practices with examples and arguments
