Terraform resource Generator

Terraform and OpenTofu resources in depth: HCL, providers, state and the IaC workflow

Terraform is HashiCorp's Infrastructure as Code (IaC) tool, released in 2014. You describe cloud infrastructure declaratively in HCL (HashiCorp Configuration Language), and Terraform talks to dozens of provider APIs (AWS, Google Cloud, Azure, Kubernetes, GitHub, Cloudflare, Datadog...) to create, update, and destroy resources to match your declared state. In August 2023 HashiCorp moved the source to the BUSL (Business Source License); the community responded with a drop-in open-source fork, OpenTofu, now governed by the Linux Foundation. Both speak the same HCL up through Terraform 1.5.

The core block types in HCL are provider (plugin that calls the cloud API), resource (something to create), data (read-only lookup), variable (input), output (export), locals (named constants), and module (reusable composition). A typical project has a root module wiring providers and locals, plus child modules for repeated patterns.

Resource syntax

terraform {
  required_version = "~> 1.5"
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
  backend "s3" {
    bucket = "tf-state-acme"
    key    = "prod/network.tfstate"
    region = "us-east-1"
    dynamodb_table = "tf-locks"
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.amzn2.id
  instance_type = var.size
  tags = {
    Name        = "web-${var.env}"
    Environment = var.env
  }
}

The two strings after resource are the type (provider-defined: aws_instance, google_compute_instance, kubernetes_deployment) and the local name used to reference it elsewhere (aws_instance.web.public_ip).

State, backends and locking

Terraform keeps a terraform.tfstate file (JSON) that maps each HCL address to the real-world ID it created. Without state, Terraform would re-create everything on every run. For teams the state lives in a remote backend — S3 + DynamoDB (lock table), Google Cloud Storage, Azure Blob, or Terraform Cloud — so concurrent runs do not corrupt each other. Always enable state locking; two simultaneous applies on the same state will produce drift you have to repair by hand.

The init / plan / apply workflow

• terraform init — downloads providers and sets up the backend. Run after cloning or changing required versions.
• terraform plan — prints the diff between code and real state. Read it carefully before applying.
• terraform apply — executes the plan (with confirmation, or -auto-approve in CI).
• terraform destroy — tears it all down. Same diff semantics, in reverse.
• terraform fmt, terraform validate — formatting and basic linting.

Workspaces, modules and CI

Use workspaces to keep separate state per environment in the same code (terraform workspace new staging). For larger orgs, prefer separate directories with separate backends per environment — it makes blast radius and credentials explicit. Modules let you publish a chunk of infrastructure (VPC, EKS cluster, RDS) as a reusable unit, optionally on the Terraform Registry. Atlantis drives PR-based workflows: every PR comments a plan, merges trigger an apply.

Best practices

• Pin provider versions with ~> 5.0 (allow patches, block majors).
• Tag every resource that supports tags — billing audits depend on it.
• Keep prod and staging in separate backends; never share state between envs.
• Run tflint, tfsec, checkov in CI for static security checks.
• Treat .tfvars as code: commit non-secret ones, use TF_VAR_ env vars or Vault for secrets.
• Never edit state by hand unless you run terraform state commands — manual JSON edits will bite you.
• Use moved {} blocks (Terraform 1.1+) when refactoring, not state mv.

FAQ

Can I roll back a Terraform apply? Not natively. The "rollback" is to git revert the change and apply again — which only works if the previous state was clean. Some operations (deleting a database, recreating an IP) are irreversible regardless. Always plan before applying.

How do I detect drift? Run terraform plan on a clean tree: anything that wants to change is drift. Schedule this in CI nightly and alert on diff. Terraform Cloud has built-in drift detection.

Should I migrate to OpenTofu? If you are on Terraform 1.5 or earlier, OpenTofu is a drop-in replacement (same binary name, same HCL). Beyond 1.5 the projects diverge — OpenTofu added features like state encryption and provider mocking earlier than Terraform.

Terraform vs Pulumi vs CDK? Terraform/OpenTofu use HCL (declarative DSL) — the largest provider ecosystem. Pulumi uses real languages (TS, Python, Go) — better for developers comfortable with code. AWS CDK is AWS-only (CDK for Terraform exists but is niche). Pick by team skills and the ecosystem you depend on most.

How do I structure a big repo? The "live" pattern (used by Gruntwork's Terragrunt): a thin per-environment directory that calls shared modules with different inputs. Avoids copy-paste while keeping state separated. Without Terragrunt, you can replicate the pattern by hand with workspaces or explicit backends.