Infrastructure as Code (IaC) Tools
debt(d9/e7/b7/t3)
Closest to 'silent in production until users hit it' (d9). The detection_hints explicitly state 'automated: no' and list patterns like 'Manual AWS console configuration' and 'no drift detection' — the absence of IaC is invisible until infrastructure diverges, becomes unreproducible, or disaster strikes. None of the listed tools (terraform, pulumi, ansible, cloudformation, cdktf) detect the *absence* of IaC automatically; this only surfaces when something breaks in production or during incident recovery.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix describes adopting Terraform for cloud resources AND Ansible for server configuration, both version-controlled and reviewed. Retroactively codifying existing manual infrastructure means auditing all cloud resources, writing HCL/YAML definitions, importing existing state, setting up remote state backends, and integrating into CI/CD — this spans infrastructure, pipelines, team workflows, and potentially organizational process. It is a significant cross-cutting effort, not a single-file change.
Closest to 'strong gravitational pull' (b7). IaC tooling applies to both web and cli contexts and shapes every infrastructure change, environment provisioning, and deployment decision going forward. The common_mistakes (local state, no modules, hardcoded secrets) compound over time. Once teams operate without IaC, every new resource added manually increases drift and the eventual remediation cost — the choice exerts gravitational pull on all future infrastructure work.
Closest to 'minor surprise (one edge case)' (t3). The misconception is scoped and specific: developers believe IaC is 'only for large teams.' This is a low-stakes cognitive error (it leads to deferral, not catastrophic misuse), and the concept itself behaves largely as named. The common_mistakes (local state, no modules, hardcoded secrets, skipping plan review) are well-documented gotchas but don't represent fundamental behavioral surprises about the concept — more operational hygiene issues.
Also Known As
TL;DR
Explanation
IaC replaces manual console clicks with declarative or imperative code. Terraform (HashiCorp): declarative HCL, provider-agnostic, state file tracks reality. Pulumi: write infrastructure in TypeScript/Python/Go — code-first approach. AWS CDK: TypeScript/Python constructs that synthesise CloudFormation. Key concepts: desired state reconciliation (apply idempotently), state management (what exists vs what's defined), and drift detection (manual console changes not in code). IaC is the foundation of GitOps.
Diagram
flowchart TD
subgraph Terraform - Declarative
TF_CONF[main.tf - desired state]
TF_PLAN[terraform plan - show diff]
TF_APPLY[terraform apply - make it so]
TF_CONF --> TF_PLAN --> TF_APPLY
end
subgraph Ansible - Procedural
PLAY[playbook.yml - steps to run]
ANS[ansible-playbook - execute steps]
PLAY --> ANS
end
subgraph Output
TF_APPLY --> CLOUD[Cloud resources<br/>EC2, RDS, VPC]
ANS --> CONFIG[Server configuration<br/>packages, files, services]
end
style TF_APPLY fill:#238636,color:#fff
style ANS fill:#1f6feb,color:#fff
style CLOUD fill:#238636,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Storing Terraform state locally — remote state (S3 + DynamoDB lock) is required for team use and disaster recovery.
- Not using modules for repeated infrastructure patterns — copy-pasting HCL across environments creates drift.
- Hardcoding secrets in Terraform files — use variables, environment variables, or Vault integration.
- Running terraform apply without terraform plan review — always inspect the plan before applying.
Code Examples
# Terraform with local state and hardcoded secrets:
terraform {
# No backend — state stored locally, lost if machine fails
}
resource "aws_db_instance" "main" {
password = "supersecret123" # Hardcoded in version control!
username = "admin"
}# Remote state + secrets from environment:
terraform {
backend "s3" {
bucket = "myapp-terraform-state"
key = "prod/terraform.tfstate"
region = "eu-west-1"
dynamodb_table = "terraform-locks"
}
}
resource "aws_db_instance" "main" {
password = var.db_password # From TF_VAR_db_password env var
username = var.db_username
}