Terraform

Mini definitions

Absolutely! Let’s create a Terraform cheat sheet in the same “Service/Component: One-line definition” style, including all core concepts, resources, and features relevant for interviews. I’ll make it complete, concise, and ready to speak naturally.

---

Terraform Cheat Sheet: Core Concepts & Components

Core Concepts

• Terraform: Terraform is an infrastructure-as-code tool that allows you to define and provision cloud and on-prem resources using declarative configuration files.

• Provider: A Provider is a plugin that allows Terraform to interact with a specific cloud platform or service (e.g., AWS, Azure, GCP).

• Resource: A Resource is a specific infrastructure object managed by Terraform, such as an EC2 instance, S3 bucket, or VPC.

• Data Source: A Data Source allows Terraform to fetch existing infrastructure details from providers without managing them.

• Variable: A Variable is a parameter used to make Terraform configurations flexible and reusable.

• Output: An Output is a value exported from Terraform that can be displayed or used by other configurations.

• State File: The State File is a local or remote file that stores the current state of your infrastructure managed by Terraform.

• Module: A Module is a reusable group of Terraform configurations that can be shared and instantiated multiple times.

• Workspace: A Workspace allows multiple independent states within the same configuration, useful for environments like dev, staging, prod.

---

Commands / Actions

• terraform init: Initializes a Terraform configuration and downloads required providers and modules.

• terraform plan: Generates an execution plan showing what changes Terraform will make to reach the desired state.

• terraform apply: Applies the planned changes to provision or modify infrastructure.

• terraform destroy: Destroys all resources managed by Terraform in a configuration.

• terraform fmt: Formats Terraform configuration files to standard style.

• terraform validate: Validates syntax and structure of Terraform configuration files.

• terraform import: Imports existing infrastructure into Terraform state management.

• terraform taint: Marks a resource for recreation on the next apply.

• terraform state: Commands to inspect and manipulate Terraform state file.

---

Advanced Concepts

• Provisioner: A Provisioner allows execution of scripts or commands on a resource after it’s created, e.g., for configuration management.

• Lifecycle Block: Lifecycle Block controls resource behavior, like create_before_destroy or prevent_destroy.

• Backend: Backend defines where Terraform state is stored, e.g., locally or remotely in S3, Terraform Cloud, or Consul.

• Count & For_Each: count and for_each allow creating multiple resources dynamically.

• Expressions / Interpolation: Expressions allow referencing variables, attributes, and outputs in configurations.

• Dynamic Blocks: Dynamic blocks allow generating nested configuration blocks programmatically.

---

Best Practices / Concepts Often Asked

• Immutable Infrastructure: Terraform encourages creating new resources rather than modifying in-place to reduce errors.

• Version Control: All Terraform configurations should be version-controlled using Git.

• Remote State Locking: Remote state ensures multiple users don’t overwrite state concurrently.

• Modular Design: Use modules to create reusable, maintainable infrastructure components.

• Idempotency: Terraform ensures repeated apply runs produce the same infrastructure state.

---

If you want, I can now condense all this into a 1-minute “memorize-and-speak” Terraform cheat sheet with short, precise one-line definitions for every core concept — perfect for interviews.

Do you want me to do that?

✅ Problem Statement: Why Do We Need Terraform?

• Managing cloud infrastructure manually (via UI or CLI) leads to:

  • Human errors during provisioning or changes

  • Lack of version control over infrastructure

  • Difficulty replicating environments (e.g., staging ≠ production)

  • Complex dependency management between resources (e.g., VPCs before subnets)

  • Challenges in collaboration and auditing changes

• As infrastructure grows, manual methods become slow, error-prone, and unscalable — especially across teams or multiple environments.

---

🛠️ Solution: What Terraform Offers

• Terraform is an open-source Infrastructure as Code (IaC) tool by HashiCorp that enables safe and predictable infrastructure provisioning.

• Key benefits:

  • Declarative syntax: Define desired state using simple .tf configuration files.

  • Version control: Store infrastructure code in Git for auditing and collaboration.

  • Idempotency: Ensures consistent results — running the same code multiple times doesn't break anything.

  • Plan and apply workflow:

    • terraform plan: Preview changes

    • terraform apply: Safely make those changes

  • Multi-cloud support: Works with AWS, GCP, Azure, and more — using the same language.

  • Supports modules and reusability, making complex setups easier to manage and scale.

  • Enables automation and CI/CD integration for infrastructure deployments.

awesome! here’s a compact-but-complete “Terraform Concepts” cheat sheet in the same spirit as your Kubernetes notes—each concept has a quick purpose line + a crisp example block + a few extra nuggets (like your kube-proxy round-robin note).

---

Terraform Architecture & Core Flow

What Terraform is: Declarative IaC tool. You describe desired state in HCL; Terraform builds a dependency graph and converges infra to match it.

Core workflow: init → plan → apply → destroy (with state stored locally or remotely).

Planner & Graph:

• Builds a graph from references (resource A uses resource B.id) and meta-args (depends_on).

• Parallel apply is controlled by -parallelism (default 10).

---

Project Structure & Files

.
├── main.tf        # resources, providers, modules
├── variables.tf   # inputs (types, validation)
├── outputs.tf     # outputs
├── locals.tf      # computed values
├── versions.tf    # required terraform & provider versions
├── terraform.tfvars  # default values (auto-loaded)
└── modules/...

Tip: Use versions.tf to pin versions and prevent accidental upgrades.

terraform {
  required_version = "~> 1.9"
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

---

Providers

Purpose: Plugins that talk to cloud APIs (AWS/Azure/GCP/K8s/etc).

provider "aws" {
  region = var.region
}

# Multiple accounts/regions via alias
provider "aws" {
  alias  = "logs"
  region = "us-west-2"
}

resource "aws_s3_bucket" "app" {
  bucket = "${var.project}-bucket"
  # Use default provider (no alias)
}

resource "aws_cloudwatch_log_group" "lg" {
  name     = "/app/main"
  provider = aws.logs
}

Notes:

• Auth via env vars, shared config, or explicit creds (avoid hardcoding).

• Use provider aliases for multi-account, multi-region, cross-service patterns.

---

Resources (Create Things)

resource "aws_instance" "web" {
  ami           = var.ami
  instance_type = "t3.micro"
  tags = {
    Name = "web-1"
  }
}

Meta-arguments you’ll use a lot:

• depends_on – force edges in the graph.

• count / for_each – multiplicity.

• lifecycle – create_before_destroy, prevent_destroy, ignore_changes.

• provider – choose an alias.

---

Data Sources (Read Things)

Purpose: Query existing objects for IDs/attributes (no changes).

data "aws_ami" "ubuntu" {
  owners      = ["099720109477"] # Canonical
  most_recent = true
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
}

resource "aws_instance" "vm" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
}

---

Variables (Inputs) & Validation

variable "region" {
  type        = string
  description = "AWS region"
  validation {
    condition     = contains(["ap-south-1","ap-southeast-1"], var.region)
    error_message = "Region must be Mumbai or Singapore."
  }
}

variable "allowed_ips" {
  type = list(string)
  default = []
}

# Load: terraform.tfvars / *.auto.tfvars / -var / -var-file / ENV TF_VAR_*

---

Locals (Computed)

locals {
  common_tags = {
    Project = var.project
    Env     = var.env
  }
  is_prod = var.env == "prod"
}

---

Outputs

output "alb_dns" {
  value       = aws_lb.app.dns_name
  description = "Public DNS"
  sensitive   = false
}

---

Expressions, Loops, Conditionals, Functions

# Conditional
instance_type = local.is_prod ? "t3.large" : "t3.micro"

# for expressions
tags = {
  for k, v in local.common_tags : k => v
}

# dynamic block
resource "aws_security_group" "web" {
  name = "web-sg"

  dynamic "ingress" {
    for_each = var.allowed_ips
    content {
      from_port   = 443
      to_port     = 443
      protocol    = "tcp"
      cidr_blocks = [ingress.value]
      description = "HTTPS"
    }
  }
}

Useful functions: coalesce, try, regex, format, join/split, cidrsubnet, jsonencode, file, templatefile.

---

State (The Source of Truth)

Purpose: Tracks real-world objects ↔ Terraform resources.

Local vs Remote: Use remote for teams to enable locking, versioning, and DR.

terraform {
  backend "s3" {
    bucket         = "tf-state-prod"
    key            = "apps/web/terraform.tfstate"
    region         = "ap-south-1"
    dynamodb_table = "tf-locks"          # enables state locking
    encrypt        = true
  }
}

State Locking:

• S3 backend + DynamoDB provides a lock to prevent concurrent apply (like your “round-robin” nugget, here the key point is optimistic locking using a conditional write).

• Terraform Cloud/Enterprise backends lock automatically.

Key Commands:

• terraform state list/show/mv/rm – inspect & refactor state.

• terraform refresh – re-read remote objects (or -refresh-only plan).

• terraform taint (legacy) → prefer -replace=addr during apply.

---

Workspaces (Logical Environments)

Purpose: Multiple state instances from same config (e.g., dev, stage, prod).

terraform workspace new dev
terraform workspace select dev

locals {
  name_suffix = terraform.workspace
}
resource "aws_s3_bucket" "b" {
  bucket = "${var.project}-${local.name_suffix}"
}

Note: Great for sandboxes; for serious prod, prefer separate folders/stacks & remote state per env.

---

Modules (Reuse & Composition)

Purpose: Package infra patterns; version via registry or Git.

modules/
  vpc/
    main.tf variables.tf outputs.tf

module "vpc" {
  source = "./modules/vpc"
  name   = "core"
  cidr   = "10.0.0.0/16"
  azs    = ["ap-south-1a","ap-south-1b"]
}

Best practices:

• Minimal inputs, typed vars, sensible defaults.

• Version pinning for registry modules (source = "terraform-aws-modules/vpc/aws" version = "~> 5.0").

• Expose clean outputs; avoid leaking internals.

---

Lifecycle & Change Control

resource "aws_launch_template" "lt" {
  name = "app"

  lifecycle {
    create_before_destroy = true       # zero-downtime for replaceable resources
    prevent_destroy       = false
    ignore_changes        = [image_id] # let image drift (e.g., baked AMIs)
  }
}

Replace flows:

• terraform apply -replace=aws_instance.web

• Use moved blocks to keep history on refactors (rename resource addresses):

moved {
  from = aws_instance.web
  to   = aws_instance.app
}

---

Count vs for_each (Cardinality)

# count: index-based
resource "aws_iam_user" "u" {
  count = length(var.user_names)
  name  = var.user_names[count.index]
}

# for_each: stable keys (better for drift-free changes)
resource "aws_iam_user" "u2" {
  for_each = toset(var.user_names)
  name     = each.key
}

---

Provisioners (Last Resort)

Use only when nothing else works (prefer cloud-init/user-data, Packer, or config mgmt).

resource "null_resource" "bootstrap" {
  triggers = { version = var.bootstrap_version }

  provisioner "local-exec" {
    command = "ansible-playbook -i inventory site.yml"
  }
}

Notes: Non-idempotent, flaky; failures require special handling (on_failure).

---

Files, Templates & Cloud-Init

# Render a file with variables
locals {
  user_data = templatefile("${path.module}/cloud_init.tftpl", {
    app_name = var.project
  })
}

resource "aws_instance" "web" {
  ami           = var.ami
  instance_type = "t3.micro"
  user_data     = local.user_data
}

cloud_init.tftpl example:

#cloud-config
write_files:
  - path: /etc/app/name
    content: "${app_name}"
runcmd:
  - systemctl enable app
  - systemctl start app

---

Importing Existing Infra

Modern approach (HCL import blocks):

terraform {
  required_version = ">= 1.5.0"
}

# Declare the resource
resource "aws_s3_bucket" "logs" {}

# Map real object → resource
import {
  to = aws_s3_bucket.logs
  id = "my-existing-logs-bucket"
}

Then: terraform plan shows proposed state; apply records it without changing the bucket.

---

Testing (terraform test) & Validation

Unit-ish tests for modules using .tftest.hcl.

tests/basic.tftest.hcl

run "plan_basic" {
  command = plan
  variables {
    project = "demo"
    env     = "dev"
  }
  assert {
    condition = length(planned_values.root_module.resources) > 0
    error_message = "No resources planned."
  }
}

Run: terraform test

---

Policy as Code & Security

• Sentinel / OPA (Conftest) to enforce rules (tags required, regions restricted).

• Sensitive inputs/outputs:

  variable "db_password" {
    type      = string
    sensitive = true
  }
  output "pw" {
    value     = var.db_password
    sensitive = true
  }

• State protection: Enable encryption & locking; never commit state. Use workspaces or separate backends per env.

---

Drift & Change Review

• terraform plan -out=tfplan → store artifact in CI, review before apply.

• Refresh-only plan: detect drift safely.

  terraform plan -refresh-only

• terraform apply tfplan ensures you apply what you reviewed.

---

CI/CD Patterns

• Lint: tflint, terraform fmt -check, terraform validate.

• Plan on PR, comment summary; manual or auto-apply on main.

• Use Terraform Cloud (VCS-driven runs, remote state, policies) or self-hosted runners with an S3 backend + DynamoDB lock.

---

Workhorse Meta-Args Cheat Sheet

resource "X" "r" {
  for_each   = var.map_or_set
  count      = 3
  depends_on = [X.a, X.b]

  lifecycle {
    create_before_destroy = true
    prevent_destroy       = var.env == "prod"
    ignore_changes        = [tags["LastUpdated"]]
  }

  provisioner "local-exec" {
    when    = destroy
    command = "echo destroying ${self.id}"
  }
}

When to use what (like your node selector/affinity/taints table):

• Simple multiplicity: count

• Stable keyed multiplicity: for_each

• Ordering / explicit edge: depends_on

• Zero-downtime replace: create_before_destroy

• Keep hands off drift: ignore_changes

• Force recreate: -replace on apply

---

Useful CLI

terraform init -upgrade           # pull newer provider versions within constraints
terraform validate                # syntax & internal checks
terraform fmt -recursive          # canonical formatting
terraform plan -var-file=prod.tfvars
terraform apply -auto-approve
terraform destroy -target=...     # surgical tear-down (use sparingly)
terraform output -json            # feed CI or other tools

---

End-to-End Mini Example (AWS: VPC + EC2 + Remote State)

backend.tf

terraform {
  backend "s3" {
    bucket         = "tf-state-mumbai"
    key            = "demo/ec2/terraform.tfstate"
    region         = "ap-south-1"
    dynamodb_table = "tf-locks"
    encrypt        = true
  }
}

main.tf

terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

provider "aws" { region = var.region }

locals {
  common_tags = { Project = var.project, Env = var.env }
}

resource "aws_vpc" "this" {
  cidr_block = "10.10.0.0/16"
  tags       = merge(local.common_tags, { Name = "${var.project}-vpc" })
}

resource "aws_subnet" "public" {
  vpc_id            = aws_vpc.this.id
  cidr_block        = "10.10.1.0/24"
  map_public_ip_on_launch = true
  availability_zone = "ap-south-1a"
  tags              = merge(local.common_tags, { Name = "public-a" })
}

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.this.id
  tags   = local.common_tags
}

resource "aws_route_table" "rt" {
  vpc_id = aws_vpc.this.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
}

resource "aws_route_table_association" "a" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.rt.id
}

data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"]
  filter { name = "name" values = ["ubuntu/images/hvm-ssd/ubuntu-*-amd64-server-*"] }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow SSH and HTTP"
  vpc_id      = aws_vpc.this.id

  ingress { from_port = 22  to_port = 22  protocol = "tcp" cidr_blocks = var.allowed_ips }
  ingress { from_port = 80  to_port = 80  protocol = "tcp" cidr_blocks = ["0.0.0.0/0"] }
  egress  { from_port = 0   to_port = 0   protocol = "-1"  cidr_blocks = ["0.0.0.0/0"] }
}

resource "aws_instance" "web" {
  ami                    = data.aws_ami.ubuntu.id
  instance_type          = local.is_prod ? "t3.small" : "t3.micro"
  subnet_id              = aws_subnet.public.id
  vpc_security_group_ids = [aws_security_group.web.id]
  user_data              = templatefile("${path.module}/cloud_init.tftpl", { app_name = var.project })

  tags = merge(local.common_tags, { Name = "${var.project}-web" })

  lifecycle { create_before_destroy = true }
}

locals {
  is_prod = var.env == "prod"
}

output "public_ip"  { value = aws_instance.web.public_ip }
output "public_dns" { value = aws_instance.web.public_dns }

variables.tf

variable "project"  { type = string }
variable "env"      { type = string }
variable "region"   { type = string  default = "ap-south-1" }
variable "allowed_ips" {
  type        = list(string)
  description = "CIDRs allowed for SSH"
  default     = ["0.0.0.0/0"]
}

cloud_init.tftpl

#cloud-config
package_update: true
packages: [nginx]
write_files:
  - path: /var/www/html/index.html
    content: |
      <h1>${app_name} running on $(hostname)</h1>
runcmd:
  - systemctl enable nginx
  - systemctl restart nginx

Run:

terraform init
terraform plan -var 'project=superset' -var 'env=dev'
terraform apply -auto-approve -var-file=prod.tfvars

---

Extra Nuggets (like your kube-proxy “round robin” bit)

• Graph & Ordering: Terraform doesn’t “sequence” files; it resolves dependencies from references and depends_on.

• Parallelism: Increase with -parallelism=50 for read-heavy plans; be careful with API rate limits.

• Zero-Downtime Swaps: Use create_before_destroy + unique names (or LT + ASG rolling deployments).

• Idempotence: Prefer data sources + computed names to avoid accidental replacement.

• Cost Controls: Tag everything; integrate infracost in PRs.

• Secrets: Use external secret stores (SSM Parameter Store, Secrets Manager); mark vars as sensitive.

• RBAC/IAM blast radius: Use separate AWS accounts per env when possible; provider aliases keep config tidy.

---

If you want, I can drop this into a printable doc or a one-file reference with a few ready-to-run module templates (VPC, ALB, EKS, RDS) tailored to your ₹2000/mo Superset offering.

Great question, Pavan. Below is a comprehensive list of Terraform components, resources, and concepts, along with real-world use cases — exactly the kind of deep practical understanding Amazon expects at a senior DevOps level.

---

✅ Terraform Core Concepts, Resources, and When to Use Them

---

1. resource

• Definition: Defines an infrastructure object (e.g., aws_instance, aws_s3_bucket).

• Use When: You want to create, manage, or destroy infrastructure in a declarative way.

---

2. data (Data Source)

• Definition: Reads existing information from a provider without creating it.

• Use When: You need to reference existing resources (e.g., AMI IDs, VPCs, SSM parameters).

---

3. variable

• Definition: Parameterizes inputs to make modules/configs dynamic.

• Use When: You want to avoid hardcoding and allow flexibility across environments.

---

4. output

• Definition: Prints values after apply or passes values between modules.

• Use When: You want to expose resource attributes like ALB DNS, RDS endpoint.

---

5. module

• Definition: A self-contained group of resources reused across configurations.

• Use When: You want to reuse infrastructure patterns (e.g., VPC, ECS, IAM roles).

---

6. locals

• Definition: Temporary named values for computation within a module.

• Use When: You want to simplify logic, DRY up repeated expressions.

---

7. provider

• Definition: Plugin that lets Terraform communicate with APIs (e.g., AWS, GCP).

• Use When: You define what cloud or service Terraform should use.

---

8. terraform block

• Definition: Defines backend, required providers, versions.

• Use When: You configure state storage, required versions, provider constraints.

---

9. backend

• Definition: Where Terraform stores state (e.g., S3, remote, local).

• Use When: You want to enable team collaboration and persistence of infra state.

---

10. workspace

• Definition: Isolated state for the same config (e.g., dev, prod).

• Use When: You want multiple environments from a single codebase.

---

11. lifecycle

• Definition: Controls resource behavior during create/update/delete.

Lifecycle Meta-Arg	Use Case
prevent_destroy	Prevent accidental deletion of critical resources (e.g., RDS, ALB)
create_before_destroy	Avoid downtime by creating new before destroying old (e.g., ALB listener rules, EC2 AMIs)
ignore_changes	Prevent unnecessary changes from triggering updates (e.g., external secrets rotation)

---

12. depends_on

• Definition: Explicitly define dependency between resources.

• Use When: Implicit dependency isn't enough (e.g., Lambda depends on IAM policy).

---

13. count

• Definition: Creates multiple instances of a resource based on integer value.

• Use When: You need N identical resources (e.g., multiple subnets, EC2s).

---

14. for_each

• Definition: Create resources from a set or map.

• Use When: You want unique named resources (e.g., per-service ALB rule, tagging).

---

15. dynamic blocks

• Definition: Programmatically build nested blocks like ingress or statement.

• Use When: You want to generate variable numbers of blocks from data (e.g., security group rules, IAM policies).

---

16. templatefile()

• Definition: Loads external template files (e.g., userdata scripts).

• Use When: You need to inject variables into files like EC2 user_data, config files.

---

17. remote-exec, local-exec provisioners

• Definition: Run shell scripts after resource creation.

• Use When: Temporary bootstrapping (e.g., install agent, trigger CI webhook).

⚠️ Avoid overusing; violates declarative IaC principles.

---

18. terraform import

• Definition: Brings existing resources under Terraform management.

• Use When: Migrating unmanaged infrastructure to Terraform without recreate.

---

19. terraform taint / terraform untaint

• Definition: Marks a resource for recreation on next apply.

• Use When: Force resource replacement (e.g., corrupted EBS volume).

---

20. terraform state

• Definition: Command to inspect, move, or remove state data manually.

• Use When: Fix drift, split state, remove orphaned resources.

---

21. null_resource

• Definition: A resource that does nothing but allows provisioners or triggers.

• Use When: Control logic like scripts or wait conditions without infra.

---

22. time_sleep, external, random_* resources

• Use Cases:

  • time_sleep: Add wait time during deployment.

  • external: Run external scripts (JSON I/O).

  • random_id, random_pet: Unique naming for buckets, instances.

---

23. sensitive attribute

• Definition: Marks an output or variable as sensitive.

• Use When: You want to hide secrets in CLI output (e.g., passwords, tokens).

---

24. override files (override.tf)

• Definition: Allow user-local overrides.

• Use When: Rarely used — mostly in legacy projects.

---

25. Pre/Post condition checks (v1.2+)

• Use When: Enforce resource constraints:

  resource "aws_instance" "example" {
    ami           = var.ami
    instance_type = var.type
  
    lifecycle {
      precondition {
        condition     = var.type != "t2.micro"
        error_message = "t2.micro is not allowed in production"
      }
    }
  }

---

🔧 DevOps/Production Usage Scenarios Table

Concept	Use Case
prevent_destroy	Protect prod RDS, S3, ALBs
create_before_destroy	Rolling updates, immutable infra
ignore_changes	Ignore drift like password rotation or manually updated tags
count	Spin up 3 NAT gateways or AZs
for_each	Create resources per service (tags, IAM roles)
modules	Reuse: VPC, ALB, ECS, RDS, CloudWatch
workspaces	Isolate dev/stage/prod environments
backend "s3"	Remote state for collaboration
dynamodb_table	Locking to prevent race conditions
locals	DRY up repeated values like common_tags
templatefile()	Dynamic EC2 user-data or app config
external	Call external scripts (e.g., fetch from REST API)
random_id	Generate unique names for globally-scoped resources (e.g., S3)

---

Let me know if you want:

• A PDF cheat sheet of this

• A diagram of Terraform architecture

• Terraform design doc template for real projects (great for interviews)

Would you like me to build that next?