Infrastructure as Code with Terraform — A Practical Guide for Developers

Terraform is a widely adopted tool for defining cloud infrastructure as code. For developers, Terraform provides a single language (HCL) to describe resources across providers and a plan/apply workflow that makes changes auditable and reviewable.

This guide focuses on practical patterns developers need: module design, remote state and locking, CI validation, testing, and safe workflows for teams deploying to AWS, GCP, or Azure.

Why use Terraform?

• Declarative definitions make changes predictable and reviewable.
• Provider ecosystem covers nearly all cloud services and many SaaS providers.
• Modules enable reuse and enforce standards across teams.

Project layout and modules

Recommended layout:

infra/
  modules/
    vpc/
    database/
  envs/
    dev/
      main.tf
    prod/
      main.tf

• Keep provider-agnostic patterns in modules where possible.
• Surface inputs (variables) deliberately and document defaults.

State management and remote backends

Never keep team state in local files. Use remote backends with locking:

• AWS: S3 + DynamoDB table for state locking.
• GCP: Google Cloud Storage + Terraform locking via state locking tools or Terraform Cloud.
• Terraform Cloud / Enterprise: built-in remote state and run execution.

Example backend (S3):

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "envs/prod/terraform.tfstate"
    region = "us-east-1"
  }
}

Workspaces and environment separation

Use separate workspaces or directories per environment. Prefer directory-per-environment for clearer access control and CI separation.

CI/CD for Terraform

CI jobs should run terraform fmt, terraform validate, terraform init -backend=false (where appropriate), and terraform plan with -out to produce a plan artifact for review. Approve and apply from a controlled runner or Terraform Cloud.

Example steps (GitHub Actions):

1. Checkout code
2. Run terraform fmt and terraform validate
3. Run terraform plan -var-file=... and upload plan
4. Post plan output to PR for review

Testing Terraform

• Unit-test modules with terraform validate and tflint.
• Use terratest or kitchen-terraform for integration tests that provision ephemeral resources in a test account.

Security and secrets

• Never hard-code secrets in HCL. Use secrets managers and inject values via CI variables or providers (e.g., AWS Secrets Manager).
• Limit who can apply production plans; require code review and approvals.

Drift detection and remediation

• Use periodic runs or terraform plan in CI to detect drift.
• Prefer immutable infrastructure patterns to reduce configuration drift.

Migration tips from console to IaC

1. Inventory existing resources and import critical ones only.
2. Start with dev or sandbox accounts and test imports.
3. Maintain a migration log and pin provider versions.

Internal links

• Pillar: Practical Cloud Computing for Developers
• Related: CI/CD in the Cloud
• Related: Getting Started with AWS for Developers

External references

• Terraform docs: https://www.terraform.io/docs
• Terraform best practices (HashiCorp): https://www.terraform.io/docs/cloud/guides

Related articles

Policy-as-code with OPA and GitOps workflows

Practical Cloud Computing for Developers

Reproducible training with infrastructure as code

Secure DevOps with policy-as-code

What is IaaS vs PaaS vs SaaS — Practical Guide for Developers