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:

Hierarchy: Resource → Resource Module → Infrastructure Module → Composition

Directory Structure:

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)

For detailed module architecture, see: Code Patterns: Module Types & Hierarchy

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?

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:

3. command = plan - Fast, for input validation

4. command = apply - Required for computed values and set-type blocks

5. Handle set-type blocks correctly:

6. Cannot index with [0]