antonbabenko__terraform-skill/SKILL.md

name, description

name	description
terraform-skill	Use when working with Terraform or OpenTofu - creating modules, writing tests (native test framework, Terratest), setting up CI/CD pipelines, reviewing configurations, choosing between testing approaches, debugging state issues, implementing security scanning (trivy, checkov), or making infrastructure-as-code architecture decisions

Terraform Skill for Claude

Comprehensive Terraform and OpenTofu guidance covering testing, modules, CI/CD, and production patterns. Based on terraform-best-practices.com and enterprise experience.

When to Use This Skill

Activate this skill when:

• Creating new Terraform or OpenTofu configurations or modules
• Setting up testing infrastructure for IaC code
• Deciding between testing approaches (validate, plan, frameworks)
• Structuring multi-environment deployments
• Implementing CI/CD for infrastructure-as-code
• Reviewing or refactoring existing Terraform/OpenTofu projects
• Choosing between module patterns or state management approaches

Don't use this skill for:

• Basic Terraform/OpenTofu syntax questions (Claude knows this)
• Provider-specific API reference (link to docs instead)
• Cloud platform questions unrelated to Terraform/OpenTofu

Core Principles

1. Code Structure Philosophy

Module Hierarchy:

environments/        # Environment-specific configurations
├── prod/
├── staging/
└── dev/

modules/            # Reusable modules
├── networking/
├── compute/
└── data/

examples/           # Module usage examples (also serve as tests)
├── complete/
└── minimal/

Key principle from terraform-best-practices.com:

• Separate environments (prod, staging) from modules (reusable components)
• Use examples/ as both documentation and integration test fixtures
• Keep modules small and focused (single responsibility)

2. Naming Conventions

Resources:

# Good: Descriptive, contextual
resource "aws_instance" "web_server" { }
resource "aws_s3_bucket" "application_logs" { }

# Good: "this" for singleton resources (only one of that type)
resource "aws_vpc" "this" { }
resource "aws_security_group" "this" { }

# Avoid: Generic names for non-singletons
resource "aws_instance" "main" { }
resource "aws_s3_bucket" "bucket" { }

Singleton Resources:

Use "this" when your module creates only one resource of that type:

✅ DO:

resource "aws_vpc" "this" {}           # Module creates one VPC
resource "aws_security_group" "this" {}  # Module creates one SG

❌ DON'T use "this" for multiple resources:

resource "aws_subnet" "this" {}  # If creating multiple subnets

Use descriptive names when creating multiple resources of the same type.

Variables:

# Prefix with context when needed
var.vpc_cidr_block          # Not just "cidr"
var.database_instance_class # Not just "instance_class"

Files:

• main.tf - Primary resources
• variables.tf - Input variables
• outputs.tf - Output values
• versions.tf - Provider versions
• data.tf - Data sources (optional)

Testing Strategy Framework

Decision Matrix: Which Testing Approach?

Your Situation	Recommended Approach	Tools	Cost
Quick syntax check	Static analysis	terraform validate, fmt	Free
Pre-commit validation	Static + lint	validate, tflint, trivy, checkov	Free
Terraform 1.6+, simple logic	Native test framework	Built-in terraform test	Free-Low
Pre-1.6, or Go expertise	Integration testing	Terratest	Low-Med
Security/compliance focus	Policy as code	OPA, Sentinel	Free
Cost-sensitive workflow	Mock providers (1.7+)	Native tests + mocking	Free
Multi-cloud, complex	Full integration	Terratest + real infra	Med-High

Testing Pyramid for Infrastructure

        /\
       /  \          End-to-End Tests (Expensive)
      /____\         - Full environment deployment
     /      \        - Production-like setup
    /________\
   /          \      Integration Tests (Moderate)
  /____________\     - Module testing in isolation
 /              \    - Real resources in test account
/________________\   Static Analysis (Cheap)
                     - validate, fmt, lint
                     - Security scanning

Native Test Best Practices (1.6+)

Before generating test code:

1. Validate schemas with Terraform MCP:

   Search provider docs → Get resource schema → Identify block types
   

2. Choose correct command mode:

   • command = plan - Fast, for input validation
   • command = apply - Required for computed values and set-type blocks

3. Handle set-type blocks correctly:

   • Cannot index with [0]
   • Use for expressions to iterate
   • Or use command = apply to materialize

Common patterns:

• S3 encryption rules: set (use for expressions)
• Lifecycle transitions: set (use for expressions)
• IAM policy statements: set (use for expressions)

For detailed testing guides, see:

• Testing Frameworks Guide - Deep dive into static analysis, native tests, and Terratest
• Quick Reference - Decision flowchart and command cheat sheet

Module Development

Standard Module Structure

my-module/
├── README.md           # Usage documentation
├── main.tf             # Primary resources
├── variables.tf        # Input variables with descriptions
├── outputs.tf          # Output values
├── versions.tf         # Provider version constraints
├── examples/
│   ├── minimal/        # Minimal working example
│   └── complete/       # Full-featured example
└── tests/              # Test files
    └── module_test.tftest.hcl  # Or .go

Best Practices Summary

Variables:

• ✅ Always include description
• ✅ Use explicit type constraints
• ✅ Provide sensible default values where appropriate
• ✅ Add validation blocks for complex constraints
• ✅ Use sensitive = true for secrets

Outputs:

• ✅ Always include description
• ✅ Mark sensitive outputs with sensitive = true
• ✅ Consider returning objects for related values
• ✅ Document what consumers should do with each output

For detailed module patterns, see:

• Module Patterns Guide - Variable best practices, output design, ✅ DO vs ❌ DON'T patterns
• Quick Reference - Resource naming, variable naming, file organization

CI/CD Integration

Recommended Workflow Stages

1. Validate - Format check + syntax validation + linting
2. Test - Run automated tests (native or Terratest)
3. Plan - Generate and review execution plan
4. Apply - Execute changes (with approvals for production)

Cost Optimization Strategy

1. Use mocking for PR validation (free)
2. Run integration tests only on main branch (controlled cost)
3. Implement auto-cleanup (prevent orphaned resources)
4. Tag all test resources (track spending)

For complete CI/CD templates, see:

• CI/CD Workflows Guide - GitHub Actions, GitLab CI, Atlantis integration, cost optimization
• Quick Reference - Common CI/CD issues and solutions

Security & Compliance

Essential Security Checks

# Static security scanning
trivy config .
checkov -d .

Common Issues to Avoid

❌ Don't:

• Store secrets in variables
• Use default VPC
• Skip encryption
• Open security groups to 0.0.0.0/0

✅ Do:

• Use AWS Secrets Manager / Parameter Store
• Create dedicated VPCs
• Enable encryption at rest
• Use least-privilege security groups

For detailed security guidance, see:

• Security & Compliance Guide - Trivy/Checkov integration, secrets management, state file security, compliance testing

Version-Specific Guidance

Terraform 1.0-1.5

• Use Terratest for testing
• No native testing framework available
• Focus on static analysis and plan validation

Terraform 1.6+ / OpenTofu 1.6+

• New: Native terraform test / tofu test command
• Consider migrating from external frameworks for simple tests
• Keep Terratest only for complex integration tests

Terraform 1.7+ / OpenTofu 1.7+

• New: Mock providers for unit testing
• Reduce cost by mocking external dependencies
• Use real integration tests for final validation

Terraform vs OpenTofu

Both are fully supported by this skill. For licensing, governance, and feature comparison, see Quick Reference: Terraform vs OpenTofu.

Additional Resources

Official: Terraform Testing | OpenTofu Docs | HashiCorp Best Practices

Community: terraform-best-practices.com | Terratest | Google Cloud Best Practices

Tools: pre-commit-terraform | terraform-docs | terraform-switcher | TFLint | Trivy

Detailed Guides

This skill uses progressive disclosure - essential information is in this main file, detailed guides are available when needed:

📚 Reference Files:

• Testing Frameworks - In-depth guide to static analysis, native tests, and Terratest
• Module Patterns - Module structure, variable/output best practices, ✅ DO vs ❌ DON'T patterns
• CI/CD Workflows - GitHub Actions, GitLab CI templates, cost optimization, automated cleanup
• Security & Compliance - Trivy/Checkov integration, secrets management, compliance testing
• Quick Reference - Command cheat sheets, decision flowcharts, troubleshooting guide

How to use: When you need detailed information on a topic, reference the appropriate guide. Claude will load it on demand to provide comprehensive guidance.

License & Attribution

This skill is licensed under the Apache License 2.0. See the LICENSE file for full terms.

Copyright © 2026 Anton Babenko

Sources

This skill synthesizes best practices from:

• terraform-best-practices.com by Anton Babenko
• Compliance.tf - Terraform Compliance for Cloud-Native Enterprise (production experience)
• Official HashiCorp Terraform and OpenTofu documentation
• Google Cloud Terraform Best Practices
• AWS Terraform Best Practices
• Community contributions

Attribution

If you create derivative works or skills based on this skill, please include:

Based on terraform-skill by Anton Babenko
https://github.com/antonbabenko/terraform-skill
terraform-best-practices.com | Compliance.tf

About the author

Anton Babenko (@antonbabenko on X) is an AWS Hero and the creator of terraform-best-practices.com. Anton is the founder of Compliance.tf, which helps teams build compliant Terraform for cloud-native enterprises. Anton also curates weekly.tf, the Terraform Weekly newsletter, and maintains the terraform-aws-modules project.