Terraform Operations Language

HCL is a declarative configuration language designed by HashiCorp for defining infrastructure in Terraform. Key vocabulary includes resource blocks (declarations of infrastructure objects), data sources (read-only lookups of existing infrastructure), variables (input parameters), outputs (exported values), locals (computed values within a module), and provider blocks (configuration for a cloud or service API). Engineers describe HCL as human-readable and designed for both authoring and machine parsing, with a syntax that resembles JSON but is easier to write.

When reviewing a plan output, engineers use phrases like "the plan shows three resources to be created, one to be modified in-place, and two to be destroyed and recreated." They refer to the symbols in the output—plus signs for additions, tilde for updates, minus signs for deletions, and the "must be replaced" annotation for destructive changes. Teams discuss "reviewing the diff" before applying, "checking for unexpected destroy operations," and "understanding the blast radius of the change."

Terraform state is a JSON file that records the mapping between Terraform-managed resources and real-world infrastructure objects. Key vocabulary includes remote state (storing state in a shared backend like S3, GCS, or Terraform Cloud), state locking (preventing concurrent operations from corrupting state), state drift (when real infrastructure diverges from the recorded state), and terraform import (bringing existing resources under Terraform management). Engineers also discuss state migration, state manipulation commands like terraform state mv and terraform state rm, and the risks of manual state editing.

A Terraform module is a reusable, self-contained package of Terraform configuration that encapsulates related resources behind a defined interface of input variables and output values. Vocabulary includes root module (the top-level configuration), child modules (called modules), module registry (public or private repository of modules), module versioning, and module composition (building infrastructure from layered modules). Engineers discuss "writing opinionated modules," "abstracting complexity," and "exposing only the necessary surface area" when designing module APIs.

Infrastructure as Code is the practice of defining, provisioning, and managing infrastructure through machine-readable configuration files rather than through manual processes or interactive UIs. Key IaC vocabulary includes idempotency (applying the same configuration multiple times yields the same result), declarative vs imperative approach, version control, code review for infrastructure changes, and drift detection. Engineers describe IaC as enabling "reproducible environments," "gitOps workflows," and "infrastructure that is auditable and testable."

Terraform workspaces allow multiple state files to coexist within a single configuration, typically used to manage multiple environments (development, staging, production) from the same codebase. Engineers use the terraform workspace new, select, list, and delete commands and reference the current workspace name via the terraform.workspace variable. However, workspaces have limitations for environment management—many teams prefer separate root modules or separate state backends per environment for stronger isolation, describing workspaces as suitable for lightweight environment differentiation rather than strict environment separation.

Terraform security vocabulary includes sensitive variables (marked with sensitive = true to prevent values appearing in logs), secrets management backends (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager), least privilege IAM roles for the Terraform service account, and SAST (static application security testing) for IaC using tools like Checkov, tfsec, or Terrascan. Engineers discuss the risk of secrets in state files, the use of encrypted remote backends, and the principle of avoiding hardcoded credentials in configuration.

The terraform apply command executes the changes described in the most recent plan, creating, modifying, or deleting infrastructure resources to match the desired state defined in configuration. Engineers describe the workflow as "run plan to preview changes, then apply to execute them." Common phrases include "applying the plan," "auto-approve flag for CI pipelines," "apply failed midway through," "partial apply left resources in an inconsistent state," and "rolling back by reverting the configuration and re-applying."

A Terraform provider is a plugin that implements the CRUD (Create, Read, Update, Delete) operations for a specific cloud platform or service API—such as the AWS, Google Cloud, Azure, or Kubernetes providers. Vocabulary includes provider version pinning, provider configuration block, required_providers block, provider registry (registry.terraform.io), and provider aliases (for managing multiple accounts or regions). Engineers discuss "pinning provider versions to avoid unexpected upgrades" and "writing a custom provider" when existing providers do not cover a needed API.

Terraform refactoring vocabulary includes moved blocks (used to rename resources without destroying and recreating them), terragrunt (a wrapper tool for DRY IaC configurations), monorepo versus multi-repo patterns, backend configuration, remote_state data sources, and module composition patterns. Engineers discuss "splitting a monolithic root module," "extracting reusable components," "reducing duplication with shared modules," and "managing dependencies between stacks" when describing IaC code organisation strategies.