Infrastructure as code promised us reproducible, version-controlled infrastructure. Yet in 2026, teams still stumble over the same Terraform pitfalls that plagued early adopters. After auditing dozens of enterprise IaC codebases, these five anti-patterns remain the most common — and the most costly.

If your team ships Terraform daily, this post will save you hours of debugging and potentially thousands in incident costs.

1. Hardcoding Values Instead of Using Variables and Locals

The Problem

Hardcoded values scatter magic numbers and strings across your configurations. When a region changes, an instance size needs updating, or a tag policy shifts, you are hunting through hundreds of files instead of changing one variable.

The Wrong Way

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  subnet_id     = "subnet-0bb1c79de3EXAMPLE"
tags = {     Environment = "production"     Team        = "platform"   } }

The Right Way

variable "instance_type" {
  description = "EC2 instance type for web tier"
  type        = string
  default     = "t3.medium"
validation {     condition     = can(regex("^t3\\.", var.instance_type))     error_message = "Only t3 instance types are approved for this workload."   } }
locals {   common_tags = {     Environment = var.environment     Team        = var.team_name     ManagedBy   = "terraform"   } }
resource "aws_instance" "web" {   ami           = data.aws_ami.ubuntu.id   instance_type = var.instance_type   subnet_id     = var.subnet_id
tags = local.common_tags }

Business Impact

Teams that parameterize configurations report 60% fewer deployment failures caused by environment mismatches. Variable validation blocks catch misconfigurations before they reach terraform apply, turning runtime failures into immediate feedback.

2. Monolithic Configurations Instead of Composable Modules

The Problem

A single main.tf that defines networking, compute, databases, and monitoring is impossible to test in isolation, reuse across projects, or reason about during code review.

The Wrong Way

# main.tf — 2,000 lines covering VPC, ECS, RDS, CloudWatch, IAM...
resource "aws_vpc" "main" { ... }
resource "aws_ecs_cluster" "app" { ... }
resource "aws_db_instance" "primary" { ... }
... hundreds more resources in one file

The Right Way

module "networking" {
  source  = "app.terraform.io/acme/networking/aws"
  version = "~> 3.2"
vpc_cidr     = var.vpc_cidr   environment  = var.environment }
module "database" {   source  = "app.terraform.io/acme/rds-postgres/aws"   version = "~> 2.1"
subnet_ids   = module.networking.private_subnet_ids   environment  = var.environment }

Use your organization's private module registry (Terraform Cloud, Spacelift, or even a simple S3-backed registry) with strict semantic versioning. Pin module versions with ~> constraints so patch updates flow automatically while breaking changes require explicit approval.

Business Impact

Versioned, composable modules cut new-environment provisioning time from days to under 30 minutes. Teams reuse validated patterns instead of copying and pasting stale configurations.

3. Ignoring State Management

The Problem

Terraform state contains the mapping between your config and the real world. Committing terraform.tfstate to Git, running without state locking, or leaving state unencrypted are all recipes for data loss and race conditions.

The Wrong Way

# .gitignore is missing terraform.tfstate
Team members run terraform apply concurrently
State file is plain JSON with database passwords in cleartext
git add terraform.tfstate
git commit -m "update infra"

The Right Way

terraform {
  backend "s3" {
    bucket         = "acme-terraform-state"
    key            = "prod/networking/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
    kms_key_id     = "alias/terraform-state"
  }
}

Since Terraform 1.5+, leverage moved blocks for safe refactoring and import blocks for declarative resource imports — both eliminate manual terraform state mv commands that have historically caused outages:

import {
  to = aws_s3_bucket.logs
  id = "acme-access-logs-prod"
}
moved {   from = aws_instance.web   to   = module.compute.aws_instance.web }

Business Impact

State corruption is the number-one cause of Terraform-related outages. Remote backends with locking and encryption reduce state-related incidents by over 80%, and moved/import blocks eliminate the risky manual state surgery that caused those incidents in the first place.

4. Storing Secrets in Plain Text

The Problem

Database passwords in terraform.tfvars, API keys in variable defaults, and secrets scattered across plan output. Even with a private repo, plain-text secrets get cached in state files, CI logs, and developer laptops.

The Wrong Way

variable "db_password" {
  default = "SuperSecret123!"  # Committed to Git
}
resource "aws_db_instance" "primary" {   password = var.db_password }

The Right Way

variable "db_password" {
  description = "RDS master password"
  type        = string
  sensitive   = true  # Redacts from plan output and logs
}
Option A: Pull from AWS Secrets Manager at plan time
data "aws_secretsmanager_secret_version" "db" {
  secret_id = "prod/rds/master-password"
}
resource "aws_db_instance" "primary" {   password = data.aws_secretsmanager_secret_version.db.secret_string }

For file-level encryption of variable files, use Mozilla SOPS with age or KMS keys. For runtime secret injection, integrate HashiCorp Vault via the vault provider. Always mark secret variables with sensitive = true — this has been stable since Terraform 0.14 and there is no excuse to skip it in 2026.

Business Impact

Credential leaks cost enterprises an average of $4.45 million per breach (IBM 2025 report). Proper secret management with sensitive marking and external vaults eliminates the most common leak vector in IaC pipelines.

5. No Drift Detection or CI Validation

The Problem

Someone clicks through the AWS console. An automated process modifies a security group. A teammate applies without running plan first. Without drift detection and CI-enforced validation, your Terraform code slowly diverges from reality until the next apply produces terrifying diffs.

The Wrong Way

# Developer workflow: YOLO apply
terraform apply -auto-approve

The Right Way

# .github/workflows/terraform.yml
jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform validate
      - run: terraform plan -out=plan.tfplan
      - run: opa eval -d policies/ -i plan.json "data.terraform.deny"
drift:     runs-on: ubuntu-latest     schedule:       - cron: "0 6   *"  # Daily at 6 AM UTC     steps:       - run: terraform plan -detailed-exitcode       # Exit code 2 = drift detected, triggers alert

Platforms like Spacelift and Terraform Cloud offer built-in drift detection with scheduled runs and notification integrations. Combine with Open Policy Agent (OPA) or Sentinel policies to enforce guardrails — no public S3 buckets, no overly permissive IAM, no untagged resources.

Business Impact

Teams running terraform plan in CI catch 90% of misconfigurations before they reach production. Scheduled drift detection reduces mean time to detect (MTTD) configuration anomalies from weeks to hours.

The Path Forward

None of these anti-patterns require exotic tooling to fix. Variables, modules, remote state, secret management, and CI validation are all built into the Terraform ecosystem today. The cost of ignoring them compounds with every deployment.

Start with a quick audit: search your codebase for hardcoded AMI IDs, check whether your state is encrypted, and verify that terraform plan runs in your CI pipeline. Those three checks alone will surface the most urgent gaps.

Need help modernizing your Terraform codebase? VVVHQ specializes in IaC audits, module library design, and CI/CD pipeline hardening for cloud-native teams. Get in touch for a free infrastructure review.