provision-infrastructure-terraform
About
This skill provisions and manages cloud infrastructure using Terraform's IaC workflow, including modules, remote state, and plan/apply cycles. It's designed for creating new infrastructure, migrating from manual or CloudFormation setups, and managing multi-environment deployments with team collaboration features. Use it to version infrastructure alongside code and enforce standards through reusable modules.
Quick Install
Claude Code
Recommendednpx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/provision-infrastructure-terraformCopy and paste this command in Claude Code to install this skill
Documentation
Provision Infrastructure with Terraform
Implement infrastructure as code using Terraform. Provision, version, manage cloud resources across AWS, Azure, GCP, other providers.
When Use
- Provisioning new cloud infrastructure (VPCs, compute, storage, databases)
- Migrating from ClickOps or CloudFormation to declarative IaC
- Managing multi-environment infrastructure (dev, staging, production)
- Implementing reproducible infrastructure patterns across teams
- Versioning infrastructure changes alongside application code
- Enforcing infrastructure standards through reusable modules
Inputs
- Required: Terraform CLI installed (
terraform --version) - Required: Cloud provider credentials (AWS, Azure, GCP service accounts)
- Required: Remote state backend configuration (S3, Azure Storage, Terraform Cloud)
- Optional: Existing infrastructure to import or migrate
- Optional: Terraform Cloud/Enterprise for team collaboration
- Optional: Pre-commit hooks for validation and formatting
Steps
See Extended Examples for complete configuration files and templates.
Step 1: Initialize Terraform Project Structure
Create organized directory structure with backend configuration and provider setup.
# Create project structure
mkdir -p terraform/{modules,environments/{dev,staging,prod}}
cd terraform
# Create backend configuration
cat > backend.tf <<'EOF'
terraform {
required_version = ">= 1.6"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
backend "s3" {
bucket = "my-terraform-state"
key = "infrastructure/terraform.tfstate"
region = "us-east-1"
encrypt = true
dynamodb_table = "terraform-lock"
# Workspace-specific state files
workspace_key_prefix = "env"
}
}
provider "aws" {
region = var.aws_region
default_tags {
tags = {
ManagedBy = "Terraform"
Environment = terraform.workspace
Project = var.project_name
}
}
}
EOF
# Create variables file
cat > variables.tf <<'EOF'
variable "aws_region" {
description = "AWS region for resources"
type = string
default = "us-east-1"
}
variable "project_name" {
description = "Project name for resource naming and tagging"
type = string
validation {
condition = length(var.project_name) > 0 && length(var.project_name) <= 32
error_message = "Project name must be 1-32 characters"
}
}
variable "environment" {
description = "Environment name (dev, staging, prod)"
type = string
validation {
condition = contains(["dev", "staging", "prod"], var.environment)
error_message = "Environment must be dev, staging, or prod"
}
}
EOF
# Initialize Terraform
terraform init
Got: Terraform initializes successfully. Downloads provider plugins. Configures remote backend. .terraform/ directory created with provider binaries. State backend connection verified.
If fail: Backend initialization fails? Verify S3 bucket exists and IAM permissions allow s3:GetObject, s3:PutObject, dynamodb:GetItem, dynamodb:PutItem. For provider download failures, check network connectivity and corporate proxy settings. Run terraform init -upgrade to update providers.
Step 2: Create Reusable Infrastructure Modules
Build composable modules for VPC, compute, data infrastructure with input validation.
# modules/vpc/main.tf
variable "vpc_cidr" {
description = "CIDR block for VPC"
type = string
default = "10.0.0.0/16"
}
variable "availability_zones" {
description = "List of AZs to use"
type = list(string)
}
variable "project_name" {
description = "Project name for resource naming"
type = string
}
variable "environment" {
description = "Environment name"
type = string
}
locals {
common_tags = {
Project = var.project_name
Environment = var.environment
Module = "vpc"
}
}
resource "aws_vpc" "main" {
cidr_block = var.vpc_cidr
enable_dns_hostnames = true
enable_dns_support = true
tags = merge(local.common_tags, {
Name = "${var.project_name}-${var.environment}-vpc"
})
}
resource "aws_subnet" "public" {
count = length(var.availability_zones)
vpc_id = aws_vpc.main.id
cidr_block = cidrsubnet(var.vpc_cidr, 8, count.index)
availability_zone = var.availability_zones[count.index]
map_public_ip_on_launch = true
tags = merge(local.common_tags, {
Name = "${var.project_name}-${var.environment}-public-${var.availability_zones[count.index]}"
Type = "public"
})
}
resource "aws_subnet" "private" {
count = length(var.availability_zones)
vpc_id = aws_vpc.main.id
cidr_block = cidrsubnet(var.vpc_cidr, 8, count.index + 100)
availability_zone = var.availability_zones[count.index]
tags = merge(local.common_tags, {
Name = "${var.project_name}-${var.environment}-private-${var.availability_zones[count.index]}"
Type = "private"
})
}
resource "aws_internet_gateway" "main" {
vpc_id = aws_vpc.main.id
tags = merge(local.common_tags, {
Name = "${var.project_name}-${var.environment}-igw"
})
}
resource "aws_eip" "nat" {
count = length(var.availability_zones)
domain = "vpc"
tags = merge(local.common_tags, {
Name = "${var.project_name}-${var.environment}-nat-eip-${var.availability_zones[count.index]}"
})
depends_on = [aws_internet_gateway.main]
}
resource "aws_nat_gateway" "main" {
count = length(var.availability_zones)
allocation_id = aws_eip.nat[count.index].id
subnet_id = aws_subnet.public[count.index].id
tags = merge(local.common_tags, {
Name = "${var.project_name}-${var.environment}-nat-${var.availability_zones[count.index]}"
})
depends_on = [aws_internet_gateway.main]
}
# modules/vpc/outputs.tf
output "vpc_id" {
description = "VPC ID"
value = aws_vpc.main.id
}
output "public_subnet_ids" {
description = "List of public subnet IDs"
value = aws_subnet.public[*].id
}
output "private_subnet_ids" {
description = "List of private subnet IDs"
value = aws_subnet.private[*].id
}
output "nat_gateway_ips" {
description = "List of NAT Gateway public IPs"
value = aws_eip.nat[*].public_ip
}
Got: Module creates VPC with public/private subnets across multiple AZs, internet gateway, NAT gateways with EIPs. Output values expose resource IDs for downstream modules.
If fail: CIDR overlap errors? Adjust cidrsubnet() calculation or validate VPC CIDR doesn't conflict with existing networks. Dependency errors? Verify depends_on blocks ensure proper resource creation order. Use terraform graph | dot -Tpng > graph.png to visualize dependencies.
Step 3: Implement Environment-Specific Configurations
Create environment workspaces with variable overrides and data sources.
# environments/prod/main.tf
terraform {
required_version = ">= 1.6"
}
# Import shared backend and provider config
# ... (see EXAMPLES.md for complete configuration)
Got: Environment-specific configuration creates production-sized infrastructure with 3 AZs, larger instance types, production security settings. Data sources resolve latest AMI. Template files render with environment variables.
If fail: Workspace errors? Create workspace with terraform workspace new prod. Data source failures? Verify AWS credentials have ec2:DescribeImages permissions. Template rendering errors? Validate variable types match template expectations.
Step 4: Execute Plan and Apply Workflow
Run Terraform plan. Review changes. Apply with approval workflow.
# Format code
terraform fmt -recursive
# Validate configuration
terraform validate
# ... (see EXAMPLES.md for complete configuration)
For automated CI/CD integration:
# .github/workflows/terraform.yml
name: Terraform
on:
pull_request:
paths:
# ... (see EXAMPLES.md for complete configuration)
Got: Plan shows resource additions/changes/deletions. No drift detected. Apply creates/updates resources without errors. Outputs contain expected values. CI workflow comments plan on PRs, auto-applies on main branch merges.
If fail: Plan failures? Run terraform validate to catch syntax errors. State lock errors? Identify lock holder with aws dynamodb get-item --table-name terraform-lock --key '{"LockID":{"S":"terraform-state-bucket/key"}}' and force-unlock if stale. Apply failures? Check CloudWatch logs for provider-specific errors. Use terraform show to inspect current state.
Step 5: Manage State and Implement Drift Detection
Configure state locking, backup, automated drift detection.
# Create DynamoDB table for state locking
cat > state-backend.tf <<'EOF'
resource "aws_dynamodb_table" "terraform_lock" {
name = "terraform-lock"
billing_mode = "PAY_PER_REQUEST"
hash_key = "LockID"
# ... (see EXAMPLES.md for complete configuration)
For automated drift detection:
# Create drift detection script
cat > scripts/detect-drift.sh <<'EOF'
#!/bin/bash
set -euo pipefail
cd terraform
# ... (see EXAMPLES.md for complete configuration)
Got: State backend configured with versioning and encryption. Drift detection identifies out-of-band changes. State operations (list, show, mv, import) execute without errors. Automated drift checks run on schedule and send alerts.
If fail: State lock timeouts? Verify DynamoDB table exists and has correct key schema. Versioning issues? Check S3 bucket versioning status with aws s3api get-bucket-versioning --bucket bucket-name. Import failures? Verify resource exists and Terraform configuration matches actual resource attributes.
Step 6: Implement Module Testing and Documentation
Add automated tests with Terratest. Generate documentation.
// test/vpc_test.go
package test
import (
"testing"
# ... (see EXAMPLES.md for complete configuration)
Generate documentation:
# Install terraform-docs
go install github.com/terraform-docs/terraform-docs@latest
# Generate module documentation
terraform-docs markdown table modules/vpc > modules/vpc/README.md
# ... (see EXAMPLES.md for complete configuration)
Got: Terratest validates module creates expected resources with correct configuration. Documentation auto-generates from variable descriptions and output definitions. Pre-commit hooks enforce formatting and validation before commits.
If fail: Terratest failures? Check AWS credentials and quotas. Long-running tests? Implement parallel execution with t.Parallel(). Documentation generation errors? Verify all variables have description attributes. Pre-commit failures? Manually run terraform fmt and fix validation errors.
Checks
- Backend configured with encryption, versioning, state locking
- All modules have input validation and output values
- Workspaces isolate environment-specific state
-
terraform planshows no unexpected changes after apply - Drift detection runs automatically and alerts on changes
- Modules tested with Terratest or similar framework
- Documentation auto-generated and kept up-to-date
- Secrets managed via AWS Secrets Manager, not hardcoded
- Cost estimation integrated (Infracost or similar)
- Blast radius minimized with separate state per environment
Pitfalls
-
Hardcoded values: Avoid hardcoding AMI IDs, AZs, account-specific values. Use data sources and variables.
-
Missing lifecycle blocks: Resources recreate unexpectedly. Add
lifecycle { create_before_destroy = true }to prevent downtime during updates. -
No state locking: Concurrent applies corrupt state. Always use DynamoDB table for locking with S3 backend.
-
Overly permissive IAM: Terraform service account has full admin access. Implement least-privilege policies scoped to managed resources.
-
No version constraints: Provider updates break infrastructure. Pin provider versions with
version = "~> 5.0"constraints. -
Secrets in state: Sensitive values stored in plaintext state file. Use
sensitive = trueon outputs, store secrets in AWS Secrets Manager, reference via data sources. -
No backup strategy: State file lost or corrupted with no recovery plan. Enable S3 versioning, implement regular state backups, test recovery procedures.
-
Monolithic configuration: Single state file manages entire infrastructure. Split into logical boundaries (networking, compute, data) to reduce blast radius.
See Also
configure-git-repository- Version control for Terraform codebuild-ci-cd-pipeline- Automated Terraform workflows with GitHub Actionsimplement-gitops-workflow- ArgoCD/Flux integration with Terraformmanage-kubernetes-secrets- Secrets management in Terraform-provisioned clustersdeploy-to-kubernetes- Terraform Kubernetes provider usage
GitHub Repository
Related Skills
qmd
Developmentqmd is a local search and indexing CLI tool that enables developers to index and search through local files using hybrid search combining BM25, vector embeddings, and reranking. It supports both command-line usage and MCP (Model Context Protocol) mode for integration with Claude. The tool uses Ollama for embeddings and stores indexes locally, making it ideal for searching documentation or codebases directly from the terminal.
subagent-driven-development
DevelopmentThis skill executes implementation plans by dispatching a fresh subagent for each independent task, with code review between tasks. It enables fast iteration while maintaining quality gates through this review process. Use it when working on mostly independent tasks within the same session to ensure continuous progress with built-in quality checks.
mcporter
DevelopmentThe mcporter skill enables developers to manage and call Model Context Protocol (MCP) servers directly from Claude. It provides commands to list available servers, call their tools with arguments, and handle authentication and daemon lifecycle. Use this skill for integrating and testing MCP server functionality in your development workflow.
adk-deployment-specialist
DevelopmentThis skill deploys and orchestrates Vertex AI ADK agents using A2A protocol, managing AgentCard discovery, task submission, and supporting tools like Code Execution Sandbox and Memory Bank. It enables building multi-agent systems with sequential, parallel, or loop orchestration patterns in Python, Java, or Go. Use it when asked to deploy ADK agents or orchestrate agent workflows on Google Cloud.
