Terraform

Terraform is HashiCorp’s declarative infrastructure-as-code (IaC) tool. It lets engineers define cloud resources, network rules, Kubernetes manifests, SaaS configuration, and more as version-controlled code, then converge real-world infrastructure toward that declared state.

Core Model

A Terraform project is a collection of .tf files written in HashiCorp Configuration Language (HCL). HCL is designed to be readable and concise, but it is a full programming language with variables, modules, loops, and conditional expressions.

The typical workflow has three commands:

Command	Purpose
terraform init	Download providers and initialize backends
terraform plan	Show what changes Terraform would make to reach the declared state
terraform apply	Execute the planned changes

plan is the safety step: it produces a diff that reviewers can inspect before any resource is created, modified, or destroyed.

State and Backends

Terraform keeps a state file that maps the HCL resources to real-world identifiers. Without state, Terraform cannot know which remote object corresponds to a given resource block. State is sensitive: it often contains secrets and is a single point of contention.

Backends determine where state is stored. Common backends include:

• Local: terraform.tfstate on disk (only for single-user learning)
• Remote: S3, GCS, Azure Blob, Terraform Cloud, etc.
• State locking: most production backends support locking to prevent concurrent apply operations from corrupting state

Providers

Providers are plugins that translate HCL resources into API calls. There are official providers for AWS, Azure, GCP, Kubernetes, GitHub, Vault, and hundreds of community providers. A provider is configured in the required_providers block and downloaded during init.

Collaboration Risk

Terraform’s biggest team hazard is concurrent modification. If two engineers run apply against the same state at the same time, the second plan may be based on stale state and can overwrite or conflict with the first change. This is why Terraform workflows enforce serialization: one change at a time per state/workspace.

Tools such as Atlantis, Terraform Cloud, or CI/CD pipelines solve this by wrapping plan and apply inside a review and locking workflow. The 2017 Atlantis demo shows a concrete example of this pattern: atlantis plan posts the plan to a GitHub PR, and atlantis apply is gated until the project lock is released Atlantis Walkthrough.

Security Notes

• Store state files in encrypted backends; never commit state to Git
• Mark sensitive outputs as sensitive = true to prevent leaking values in plan output
• Use least-privilege credentials for the Terraform execution environment
• Scan HCL with tools such as Trivy, Checkov, or tfsec to catch misconfigurations (open S3 buckets, overly permissive security groups) before apply
• Use policy-as-code frameworks such as Terraform Sentinel or Open Policy Agent to enforce organizational rules

See Also

• Atlantis — PR-driven Terraform workflow with plan/apply comments and project locking
• Atlantis Walkthrough — Source: Terraform collaboration through GitHub PRs
• GitOps Security — PAT hygiene, branch protection, and supply-chain hardening for IaC workflows
• DevSecOps Fundamentals — IaC validation in the deploy stage
• Shift Left Security — catching IaC misconfigurations early
• Container Security — IaC as part of the attack surface
• Kubernetes Disaster Recovery — Infrastructure-as-Code as the bottom layer of recovery
• Tooling Index — DevOps and IaC tooling overview