Terraform / OpenTofu · DevOps & CI/CD Deep Dive

Anatomy

The Building Blocks

HCL — HashiCorp Configuration Language; declarative, JSON-equivalent.
Providers — plugins that map HCL resources to API calls (aws, azurerm, google, cloudflare, ...).
Resources & data sources — what you create vs what you read.
Modules — reusable groups of resources, parameterized by variables.
State — JSON file mapping resources to real cloud IDs. Stored remotely (S3+lock, TFC, GCS).
Plan / Apply — preview the diff, then execute. Plans are auditable in PRs.

Workflow

terraform init

→

edit .tf files

→

terraform plan

→

PR review

→

terraform apply

→

state updated

State

State is the source of truth for "what does TF think exists." Lose it, you face import hell.
Always remote — S3 + DynamoDB lock, GCS, TFC, Terraform-compatible backends like Spacelift / env0.
Locking prevents two engineers apply-ing at once.
Workspaces let one config target multiple environments — but most teams prefer separate state files per env.
Drift happens when someone clicks in the console; terraform plan surfaces it.

Tradeoffs

HCL isn't a real language. Loops and conditionals exist but get awkward. Use modules to compose.
Provider quirks. Some resources are eventually consistent; some apply can recreate things you don't want recreated. Always read the plan.
Blast radius. One apply can delete a database. Use prevent_destroy, plan -out, and PR-gated CI.
Licensing pivot. Terraform 1.6+ is BSL; OpenTofu remains MPL. Pick deliberately and watch provider compatibility.
Secrets sprawl — never terraform apply with creds in shell history; use OIDC + assume-role.

Continue