terraform

name	terraform
title	Terraform
category	Infra & CI/CD
description	Use to manage cloud infrastructure as code — declare resources in HCL, preview with plan, provision with apply, and store state remotely.
tags	["terraform","iac","infrastructure","hcl","providers","state"]
official_docs	https://developer.hashicorp.com/terraform
sources	["https://developer.hashicorp.com/terraform/intro/core-workflow"]
last_verified	2026-08-10T00:00:00.000Z

Terraform — Skillship

Declare infrastructure as code in HCL, preview changes with plan, and provision them with apply. The core loop is Write → Plan → Apply, with state tracking what exists.

🧭 When to use this skill

• Use when: provisioning cloud resources (compute, DBs, DNS, buckets) reproducibly across environments.
• Use when: you want peer-reviewed, version-controlled infra changes instead of clicking in a console.
• Don't use for: app-level deploys that a PaaS already handles, or one-off throwaway experiments.

⚡ Quickstart

1. Write config — main.tf

terraform {
  required_version = ">= 1.9"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"          # pin the provider major version
    }
  }
}

provider "aws" {
  region = var.region
}

variable "region" {
  type    = string
  default = "us-east-1"
}

resource "aws_s3_bucket" "assets" {
  bucket = "my-unique-assets-bucket-2026"
}

output "bucket_name" {
  value = aws_s3_bucket.assets.bucket
}

2. The core workflow

terraform init      # download providers, set up the backend
terraform fmt       # format
terraform validate  # static checks
terraform plan      # preview changes (dry run)
terraform apply     # provision after confirmation (type "yes")
terraform destroy   # tear everything down

🧩 Common recipes

Recipe: Remote state with locking (S3 + native locking)

terraform {
  backend "s3" {
    bucket       = "my-tf-state"
    key          = "prod/terraform.tfstate"
    region       = "us-east-1"
    encrypt      = true
    use_lockfile = true          # state locking to prevent concurrent applies
  }
}

Recipe: Pass secrets via env vars (not committed)

export TF_VAR_db_password="$DB_PASSWORD"   # populates variable "db_password"
terraform apply

variable "db_password" {
  type      = string
  sensitive = true               # keeps it out of CLI/plan output
}

Recipe: Save & apply an exact plan (CI-safe)

terraform plan -out=tfplan
terraform apply tfplan           # applies exactly what was reviewed

Recipe: Workspaces for environments

terraform workspace new staging
terraform workspace select staging

🚀 Ship to production

• Remote state with locking + encryption (S3/GCS/HCP Terraform) — never local state for teams.
• .tfstate, .tfvars with secrets, and .terraform/ are gitignored.
• Provider and module versions pinned; terraform.lock.hcl committed.
• Every change goes through plan review in a PR before apply.
• Secrets injected via TF_VAR_*/secret manager and marked sensitive = true — not hardcoded.
• Apply runs in CI with least-privilege credentials (prefer OIDC over static keys).

🔐 Security & secrets

• State files contain resource attributes in plaintext (including some secrets) — store state encrypted, access-controlled.
• Mark sensitive variables/outputs sensitive = true; never commit *.tfvars holding secrets.
• Use short-lived/OIDC credentials for the provider in CI rather than long-lived access keys.

🐛 Common errors & fixes

Symptom	Likely cause	Fix
Error acquiring the state lock	Concurrent/failed apply	Wait, or terraform force-unlock <ID> if truly stuck
Team overwrites each other's state	Local state	Configure a remote backend with locking
Provider version drift breaks plan	Unpinned provider	Pin version, commit .terraform.lock.hcl
Secret leaked in output/logs	Not marked sensitive	Add sensitive = true; avoid output-ing secrets
apply did something unexpected	Applied without reviewing plan	Use plan -out then apply tfplan

📚 Sources

• https://developer.hashicorp.com/terraform/intro/core-workflow