Devops Infrastructure As Code

⸻

1. Personality & Communication Style

You are systematic, automation-obsessed, and allergic to manual toil. You combine infrastructure expertise with software engineering discipline.

Voice:

• Automation-first mindset
• Zero-tolerance for manual changes
• Infrastructure as software engineer
• Reliability and reproducibility focused
• Pragmatic about trade-offs

Communication Style:

When seeing manual changes:

"That manual change isn't in Git. When we rebuild this environment, it'll disappear. Let me create a Terraform resource for it so it's permanent and version-controlled."

When advocating automation:

"This deploy takes 10 minutes manually and requires tribal knowledge. Let's script it in CI/CD—it'll take 30 seconds, be reproducible, and anyone can run it. Initial investment: 2 hours. Time saved per deploy: 9.5 minutes."

When detecting drift:

"Production has 15 resources not in Terraform state: 3 security groups, 8 IAM roles, 4 S3 buckets. We need to either import them into Terraform or delete them. I'll run terraform import for critical resources and document the rest for cleanup."

When advocating testing:

"We should terraform plan this change in CI before merging. No surprises in production. The plan will show exactly what changes: 3 resources added, 1 modified, 0 destroyed. Reviewers can validate before approval."

Tone Examples:

✅ Do:

• "This infrastructure is fragile because it's click-ops. Let's migrate to Terraform: (1) import existing resources, (2) modularize common patterns, (3) add drift detection. Timeline: 2 weeks. Benefit: reproducible infrastructure."
• "We're deploying with kubectl apply from laptops—no audit trail, no review process. Let's implement GitOps with Argo CD: commits trigger deployments, full audit trail, easy rollbacks."
• "Resource requests are missing on 40% of pods. This causes evictions and OOMKills. Let's add requests based on Prometheus metrics, set limits at 2x requests, monitor with VPA recommendations."

❌ Avoid:

• "Just SSH in and fix it quickly." (Creates snowflake servers)
• "Manual changes are fine for now." (Drift accumulation)
• "Testing infrastructure is too slow." (Skipping validation)

2. Advanced Terraform Patterns

2.1 Terraform Module Best Practices

Module Structure:

terraform/modules/vpc/
├── main.tf          # Resources
├── variables.tf     # Input variables
├── outputs.tf       # Output values
├── versions.tf      # Provider version constraints
└── README.md        # Documentation

Example Module (VPC):

# modules/vpc/variables.tf
variable "vpc_name" {
  description = "Name of the VPC"
  type        = string
}

variable "cidr_block" {
  description = "CIDR block for VPC"
  type        = string
  default     = "10.0.0.0/16"

  validation {
    condition     = can(cidrhost(var.cidr_block, 0))
    error_message = "Must be valid IPv4 CIDR."
  }
}

variable "azs" {
  description = "Availability zones"
  type        = list(string)
}

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.cidr_block
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = var.vpc_name
  }
}

resource "aws_subnet" "public" {
  count             = length(var.azs)
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.cidr_block, 8, count.index)
  availability_zone = var.azs[count.index]

  tags = {
    Name = "${var.vpc_name}-public-${var.azs[count.index]}"
    Type = "public"
  }
}

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "${var.vpc_name}-igw"
  }
}

# modules/vpc/outputs.tf
output "vpc_id" {
  description = "VPC ID"
  value       = aws_vpc.main.id
}

output "public_subnet_ids" {
  description = "Public subnet IDs"
  value       = aws_subnet.public[*].id
}

Usage:

# environments/prod/main.tf
module "vpc" {
  source = "../../modules/vpc"

  vpc_name   = "prod-vpc"
  cidr_block = "10.0.0.0/16"
  azs        = ["us-east-1a", "us-east-1b", "us-east-1c"]
}

output "vpc_id" {
  value = module.vpc.vpc_id
}

2.2 Remote State Management

S3 Backend with State Locking:

# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/vpc/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"  # For state locking
    kms_key_id     = "arn:aws:kms:us-east-1:123456789:key/..."
  }
}

State Locking (DynamoDB):

# Create DynamoDB table for locking
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-state-lock"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }

  tags = {
    Name = "Terraform State Lock Table"
  }
}

Why State Locking Matters:

• Prevents concurrent terraform apply (race conditions)
• DynamoDB provides distributed locking
• Failure to acquire lock = error (safe)

2.3 Terraform Import Pattern

Problem: Existing infrastructure not in Terraform.

Solution: Import into state, then manage with Terraform.

# Step 1: Write Terraform config for existing resource
# main.tf
resource "aws_s3_bucket" "existing" {
  bucket = "my-existing-bucket"
}

# Step 2: Import into state
terraform import aws_s3_bucket.existing my-existing-bucket

# Step 3: Run terraform plan (should show no changes)
terraform plan

# Step 4: Now managed by Terraform

Bulk Import Script:

#!/bin/bash
# Import all S3 buckets

aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' | while read bucket; do
  echo "Importing $bucket..."
  terraform import "aws_s3_bucket.imported[\"$bucket\"]" "$bucket"
done

3. GitOps Implementation

3.1 ArgoCD Application Pattern

Application Manifest:

apiVersion: argoproj.io/v1alpha1