Terraform CLI: Commands That Actually Matter

Everyone knows terraform init, plan, and apply. But when production breaks and you're staring at a state file corruption error at 2AM, the basic commands won't save your ass. You need the CLI commands they don't teach in tutorials.

State corruption has fucked me over more times than I care to count. Had it take down staging once because someone ran the wrong command. Another time got stuck in a deployment because DynamoDB decided to be DynamoDB. Most recent was my own damn fault - botched an import and spent way too much time fixing it manually.

Here's the CLI arsenal that kept me employed after those disasters.

What Changed That Actually Matters

Terraform 1.14 alpha finally fixed some shit that's been broken since the dawn of time. Testing doesn't randomly panic every other Tuesday, and containers won't murder your CI anymore.

Testing Framework: Went from complete garbage to merely frustrating. Used to fail randomly and take 20 minutes to teardown even simple tests. The parallel cleanup actually works now instead of hanging forever.

Container Performance: Terraform 1.14 alpha detects container resource limits automatically. I used to manually set -parallelism=2 on our GitHub Actions runners because the default would max out CPU and timeout everything. Now it figures this out without me babysitting it.

Import Improvements: Workspace variables and inherited variable sets actually work during imports now. Before this, imports would fail in weird ways if you used Terraform Cloud workspaces.

Error Messages: Type checking errors are slightly less useless now. Still not great, but at least they tell you what went wrong instead of just "Error: Error".

Essential CLI Commands Beyond the Basics

terraform console - The Underdog Command

Nobody talks about terraform console but it's saved my ass more times than I can count. When you're debugging some horrific HCL expression and the error message is useless as shit:

$ terraform console
> length(var.availability_zones)
3
> [for zone in var.availability_zones : "${var.region}${zone}"]
["us-west-2a", "us-west-2b", "us-west-2c"]
> exit

Gotcha: If your config has syntax errors, console won't start. You'll get some useless error message and wonder why. Comment out the broken resources first, then test your expressions.

State Surgery (When Everything Goes to Hell)

State corruption happens to everyone. Usually at the worst possible time. Here's how to fix it without making things worse:

## List all tracked resources
terraform state list

## Inspect specific resource state
terraform state show aws_instance.web

## Move resources between state addresses
terraform state mv aws_instance.old aws_instance.new

## Remove resources from state (without destroying)
terraform state rm aws_instance.legacy

Import Hell (Legacy Infrastructure)

Importing existing infrastructure into Terraform is like trying to reverse-engineer someone else's spaghetti code. Here's how to do it without losing your mind:

## Basic import - write the resource config first, THEN import
terraform import aws_instance.web i-1234567890abcdef0

## Import with variables (this used to be broken)
terraform import -var="environment=prod" aws_rds_cluster.main cluster-id

Write the Terraform config first, then import. I wasted 3 hours trying to figure out why my imported resource kept showing drift before I realized I had the resource definition wrong.

For bulk imports, use Terraformer. It's not perfect but beats importing 200 resources manually.

Debugging and Performance Optimization

Debugging When You're Getting Paged at 3AM

Nothing ruins a good night's sleep like getting paged because Terraform broke production. Here's how to debug without losing what's left of your sanity:

## Enable debug logging (prepare for 50MB of logs)
export TF_LOG=DEBUG
export TF_LOG_PATH=terraform.log
terraform apply

## Provider-specific logging (when AWS decides to be special)
export TF_LOG_PROVIDER=DEBUG
export TF_LOG_CORE=ERROR

Debug logs are huge and 99% garbage. But when AWS is returning cryptic 500 errors at 3AM and you're trying not to get fired, they're the only thing that'll show you what's actually happening.

Performance Optimization Techniques

Parallelism Control:

## Reduce parallelism when providers are slow/throttling
terraform apply -parallelism=5

## Increase for small deployments with independent resources
terraform apply -parallelism=20

Skip Refresh When You Know State is Good:

## Skip refresh to save time
terraform apply -refresh=false

## Refresh only specific resources
terraform apply -refresh-only -target=aws_instance.web

Container Performance Issues

Terraform 1.14 alpha finally figured out that containers exist. Used to be if you didn't set -parallelism=2 manually, it would spawn like 20 threads on a 2-CPU GitHub Actions runner and just hang there eating CPU until the job timed out. Took them years to fix this obvious shit.

Testing Framework (Finally Doesn't Suck)

The testing framework used to be complete garbage - tests would randomly fail and take 20 minutes to teardown. Recent versions fixed the worst issues:

File-Level Variable Management

## test/main.tftest.hcl
variables {
  environment = "test"
  region     = "us-west-1"
}

run "validate_vpc" {
  command = plan
  
  assert {
    condition     = aws_vpc.main.cidr_block == "10.0.0.0/16"
    error_message = "VPC CIDR must be 10.0.0.0/16 for test environment"
  }
}

Parallel Teardown (Finally)

Tests don't take forever to clean up anymore:

## Run tests - teardown is now parallel
terraform test -verbose

Tests still randomly fail sometimes (looking at you, AWS provider), but at least they don't take 20 minutes to tell you they failed.

These are the commands that separate the folks who know what they're doing from the people who just blindly copy-paste Stack Overflow answers. Learn them well, because your infrastructure will break, and when it does, you'll need more than basic terraform apply to save the day.

The terraform stacks command is experimental, but it's the first thing HashiCorp has done that makes managing multiple configs less of a nightmare. Instead of manually running five different Terraform applies and hoping they don't step on each other, stacks handles dependencies for you.

Understanding Terraform Stacks vs Traditional Approaches

Traditional Workflow Pain:

## Old way: Manually babysit each step
cd infrastructure/vpc && terraform apply
cd ../security && terraform apply  
cd ../compute && terraform apply
## Hope nothing breaks the dependency chain

Stacks Approach:

## New way: Let stacks figure out the order
terraform stacks plan
terraform stacks apply

Stacks Command Reference

Access available subcommands with:

terraform stacks -help

The available operations depend on your stacks plugin implementation, but typically include:

• stacks plan - Generate plans for all stack components
• stacks apply - Apply changes across related configurations
• stacks destroy - Coordinated teardown with proper dependency ordering
• stacks status - Cross-stack state and drift detection

Real-World Stacks Implementation Patterns

Multi-Region Infrastructure Stack:

stacks/
├── stack.hcl                    # Stack definition
├── regions/
│   ├── us-west-2/
│   │   ├── vpc.tf              # Regional networking
│   │   └── compute.tf          # Regional compute
│   └── us-east-1/
│       ├── vpc.tf
│       └── compute.tf
└── global/
    ├── dns.tf                  # Cross-region DNS
    └── monitoring.tf           # Global monitoring

Application Deployment Stack:

stacks/
├── stack.hcl
├── foundation/
│   ├── vpc.tf                  # Networking foundation
│   └── security.tf             # Security policies
├── data/
│   ├── rds.tf                  # Database layer
│   └── cache.tf                # Redis/ElastiCache
└── application/
    ├── ecs.tf                  # Container orchestration
    └── alb.tf                  # Load balancing

Advanced CLI Workflows for Production Operations

When Production Dies and You're Getting Blamed

Production is down, Slack is blowing up, and everyone's asking "what did Terraform do?" Here's the panic recovery process that's saved me during outages:

1. Immediate Assessment:

## Check what Terraform thinks vs reality
terraform refresh -no-color > refresh.log 2>&1
terraform plan -no-color > plan.log 2>&1

## Identify resource drift
terraform state list | while read resource; do
  echo \"=== $resource ===\" 
  terraform state show \"$resource\" | head -10
done

2. Surgical State Repair:

## For corrupted state entries
terraform state rm aws_instance.corrupted
terraform import aws_instance.corrupted i-actualinstanceid

## For orphaned resources
terraform state list | grep \"orphaned_pattern\" | \
  xargs -I {} terraform state rm {}

3. Rollback Procedures:

## Using saved plans for quick rollback
terraform show -json last-good.tfplan > rollback-plan.json
terraform apply \"last-good.tfplan\"

Always save your rollback plan first. Learned this the hard way when production died and I had no way to get back to the last working state.

Performance Optimization for Large Infrastructure

Container Runtime Issues:
Recent Terraform versions fixed the parallelism issues in containers. But if you need manual control:

## Rough estimate: don't use more threads than you have GB of RAM
if [ -f /sys/fs/cgroup/memory/memory.limit_in_bytes ]; then
  MEMORY_GB=$(( $(cat /sys/fs/cgroup/memory/memory.limit_in_bytes) / 1073741824 ))
  terraform apply -parallelism=$MEMORY_GB
fi

Resource-Aware Execution:

## For memory-constrained environments
terraform apply -parallelism=2 -target=module.lightweight_resources

## For high-bandwidth environments  
terraform apply -parallelism=25 -target=module.independent_resources

Provider-Specific Pain Points:

## AWS: Reduce API throttling (learned this after AWS throttled us for 2 hours)
export AWS_MAX_ATTEMPTS=10
export AWS_RETRY_MODE=adaptive
terraform apply -parallelism=8

## Azure: Handle rate limits (or get throttled forever)
export ARM_RATE_LIMIT=15
terraform apply -parallelism=5

## GCP: Work around quota limits (GCP quotas everything)
export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform apply -parallelism=12

Testing That Finally Works

Test Suites That Don't Randomly Panic

Recent versions fixed the cleanup bugs so tests don't randomly panic anymore:

## tests/infrastructure.tftest.hcl
variables {
  environment = \"test\"
  destroy_after_test = true
}

run \"validate_networking\" {
  command = plan
  
  variables {
    vpc_cidr = \"10.0.0.0/16\"
  }
  
  assert {
    condition     = length(aws_subnet.private) == 3
    error_message = \"Must have exactly 3 private subnets\"
  }
  
  assert {
    condition     = aws_vpc.main.enable_dns_hostnames == true
    error_message = \"DNS hostnames must be enabled\"
  }
}

run \"deploy_and_validate\" {
  command = apply
  
  variables {
    instance_count = 2
  }
  
  assert {
    condition = length([
      for instance in aws_instance.web : instance
      if instance.instance_state == \"running\"
    ]) == var.instance_count
    error_message = \"All instances must be in running state\"
  }
}

CI/CD Integration Patterns

GitHub Actions Testing:

name: Terraform Test and Deploy
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: \"latest\"
      
      - name: Run Terraform Tests
        run: |
          terraform init
          terraform test -verbose
          
      - name: Test with Stacks (if available)
        run: |
          if terraform stacks -help > /dev/null 2>&1; then
            terraform stacks plan
          fi

Module Testing Best Practices

## Test module in isolation
cd modules/vpc
terraform init
terraform test

## Test module integration
cd ../../examples/complete
terraform init  
terraform test -verbose

## Performance testing for large modules
time terraform plan -parallelism=1  # Baseline
time terraform plan -parallelism=10 # Optimized

Module testing is still annoying as hell, but at least it doesn't randomly panic and leave orphaned resources everywhere.

Troubleshooting Production Issues

Real-Time Debugging Techniques

Live State Analysis:

## Monitor state changes in real-time
watch -n 5 'terraform state list | wc -l'
watch -n 10 'terraform state list | xargs -I {} terraform state show {} | grep -c \"running\"'

Provider API Debugging:

## Enable provider debugging for API issues
export TF_LOG_PROVIDER=DEBUG
export TF_LOG_PATH_MASK=\"provider_%s.log\"
terraform apply 2>&1 | tee apply.log

## Analyze API patterns
grep \"HTTP/1.1\" provider_aws.log | sort | uniq -c | sort -nr

Resource Dependency Analysis:

## Generate dependency graph
terraform graph | dot -Tpng > dependency.png

## Find circular dependencies
terraform graph | grep -E \"(->|<-)\" | sort | uniq -c | sort -nr

Master these CLI commands and you'll actually know what you're doing when production breaks. This is the difference between being the person who fixes the outage and being the person who accidentally makes it worse while everyone watches.