DevOps IaC Engineer Skill

A Claude Code skill for designing, implementing, and maintaining cloud infrastructure using Infrastructure as Code — covering Terraform, Pulumi, CloudFormation, and multi-cloud deployment patterns.

When to Use This Skill

Choose this skill when:

• Provisioning cloud infrastructure (AWS, GCP, Azure) with code
• Writing or reviewing Terraform modules and configurations
• Setting up CI/CD pipelines for infrastructure deployment
• Designing multi-environment infrastructure (dev, staging, production)
• Implementing infrastructure security best practices
• Migrating from manual console-based infrastructure to IaC

Consider alternatives when:

• You need application deployment procedures (use a deployment skill)
• You need container orchestration (use a Kubernetes skill)
• You need a single cloud service quickstart (use a cloud-specific skill)

Quick Start

Copy
# Initialize Terraform project
mkdir infrastructure && cd infrastructure
terraform init

# Add the skill to Claude Code
claude mcp add devops-iac

Copy
# main.tf - AWS Infrastructure Example
terraform {
  required_version = ">= 1.5"
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
  }
}

provider "aws" {
  region = var.aws_region
  default_tags {
    tags = {
      Environment = var.environment
      ManagedBy   = "terraform"
      Project     = var.project_name
    }
  }
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "${var.project_name}-${var.environment}"
  cidr = "10.0.0.0/16"

  azs             = ["us-east-1a", "us-east-1b"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = var.environment != "production"
}

Core Concepts

IaC Tool Comparison

Feature	Terraform	Pulumi	CloudFormation
Language	HCL	Python/TS/Go	YAML/JSON
State	Remote backend	Pulumi Cloud	CloudFormation stack
Multi-cloud	Yes	Yes	AWS only
Modularity	Modules + Registry	Packages (npm/pip)	Nested stacks
Drift Detection	terraform plan	pulumi preview	Drift detection API
Learning Curve	Medium	Low (if you know a language)	Medium

Environment Architecture

Copy
# environments/production/main.tf
module "app" {
  source = "../../modules/app"

  environment    = "production"
  instance_type  = "t3.large"
  min_instances  = 3
  max_instances  = 10
  multi_az       = true
  backup_enabled = true
}

# environments/staging/main.tf
module "app" {
  source = "../../modules/app"

  environment    = "staging"
  instance_type  = "t3.small"
  min_instances  = 1
  max_instances  = 3
  multi_az       = false
  backup_enabled = false
}

Configuration

Parameter	Type	Default	Description
iac_tool	string	"terraform"	IaC tool: terraform, pulumi, cloudformation, cdk
cloud_provider	string	"aws"	Cloud provider: aws, gcp, azure, multi
state_backend	string	"s3"	State storage: s3, gcs, azurerm, terraform-cloud
environment	string	"production"	Target environment for plan/apply
module_style	string	"monorepo"	Module organization: monorepo, multi-repo
drift_detection	boolean	true	Enable drift detection checks
cost_estimation	boolean	true	Include cost estimates in plan output

Best Practices

1. Always run terraform plan before apply — review the planned changes carefully; a single misconfigured resource can delete production infrastructure. Never auto-approve plans in production.

2. Use remote state with locking — store Terraform state in S3 with DynamoDB locking (or equivalent) to prevent concurrent modifications that corrupt state.

3. Tag every resource with environment, project, and managed-by — tags enable cost tracking, security auditing, and make it clear which resources are managed by IaC vs. manually created.

4. Create modules for repeated patterns — if you define the same VPC + subnets + security groups for every environment, extract it into a reusable module with variables for the differences.

5. Separate state files per environment — never share a single state file between dev and production; a mistake in dev state could trigger changes in production.

Common Issues

Terraform state gets out of sync with reality — Someone made a manual change in the console. Run terraform plan to detect drift, then either import the manual change with terraform import or revert it by applying the existing config.

Destroying resources accidentally — A renamed resource is treated as destroy + create. Use terraform state mv to rename in state without destroying. Always review plan output for unexpected destroys.

Module version upgrades break infrastructure — Pin module versions with exact constraints (version = "5.2.1") in production. Use ~> constraints only in staging where breaking changes are acceptable.