🎯 Today’s Goals

• Import existing resources into Terraform

• Move resources within the state.

• Refactor configurations safely

• Handle resource migrations

📥 Terraform Import

Import adds existing infrastructure to Terraform state without recreating it.

Basic Import Syntax

terraform import <resource_address> <resource_id>

Import Process

1. Write resource block

2. Import into state

3. Run plan to verify

4. Adjust configuration if needed

Example: Import EC2 Instance

# Step 1: Write resource block
resource "aws_instance" "imported" {
  # Required arguments only initially
  ami           = "ami-12345"
  instance_type = "t2.micro"
}

# Step 2: Import
terraform import aws_instance.imported i-1234567890abcdef0
# Step 3: Plan to see differences
terraform plan
# Step 4: Update configuration to match
# Add missing arguments from plan output

Common Resource Imports

# EC2 Instance
terraform import aws_instance.web i-1234567890abcdef0

# VPC
terraform import aws_vpc.main vpc-12345678

# S3 Bucket
terraform import aws_s3_bucket.data my-bucket-name

# Security Group
terraform import aws_security_group.web sg-12345678

# IAM Role
terraform import aws_iam_role.app my-app-role

# RDS Instance
terraform import aws_db_instance.database my-database

🔄 Moving Resources

Within Same State

Use terraform state mv:

# Rename resource
terraform state mv aws_instance.old aws_instance.new

# Move to module
terraform state mv aws_instance.web module.web.aws_instance.server

# Move from module
terraform state mv module.old.aws_instance.web aws_instance.web

# Move with count/index
terraform state mv 'aws_instance.web[0]' 'aws_instance.primary'

Between Different States

# Pull source statet
erraform state pull > source.tfstate

# Pull destination state
terraform state pull > dest.tfstate

🧪 Hands-On Lab

Lab 1: Import Existing Resources

main.tf:

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

provider "aws" {
  region = "us-east-1"
}

# We'll import this later
resource "aws_s3_bucket" "imported" {
  bucket = "BUCKET_NAME"  # Replace after import

  tags = {
    Imported = "true"
  }
}

# Create bucket manually first
BUCKET_NAME="import-lab-$(date +%s)"
aws s3 mb s3://$BUCKET_NAME

# Add bucket name to terraform
sed -i "s/BUCKET_NAME/$BUCKET_NAME/" main.tf

# Import the bucket
terraform import aws_s3_bucket.imported $BUCKET_NAME

# Verify
terraform plan  

# Update tags
terraform apply

# Clean up
terraform destroy

Lab 2: Move Resources

main.tf:

resource "aws_instance" "old_name" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t2.micro"

  tags = {
    Name = "test-instance"
  }
}

data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

# Apply
terraform apply -auto-approve

# Rename in code
mv old_name to new_name in main.tf

# Move in state
terraform state mv aws_instance.old_name aws_instance.new_name

# Verify
terraform plan  

# Should show no changes
# Clean up
terraform destroy

🔧 Import with For_Each

resource "aws_s3_bucket" "imported" {
  for_each = toset([
    "bucket-1",
    "bucket-2",
    "bucket-3"
  ])

  bucket = each.value
}

# Import each
terraform import 'aws_s3_bucket.imported["bucket-1"]' bucket-1
terraform import 'aws_s3_bucket.imported["bucket-2"]' bucket-2
terraform import 'aws_s3_bucket.imported["bucket-3"]' bucket-3

📋 Best Practices

✅ DO:

1. Always back up the state before importing

    terraform state pull > backup.tfstate
   

2. Import in stages

   • Import critical resources first

   • Test thoroughly

   • Document what was imported

3. Use terraform plan to verify

    terraform import <resource> <id>terraform plan  # Should show minimal changes
   

4. Keep import scripts

    # import.sh
    #!/bin/bash
    terraform import aws_vpc.main vpc-12345
    terraform import aws_subnet.public[0] subnet-12345
    terraform import aws_subnet.public[1] subnet-67890
   

❌ DON’T:

1. Don’t import without backing up

2. Don’t modify state files manually

3. Don’t import into production without testing

4. Don’t forget to update configuration after import

🔍 Troubleshooting

Import Fails

# Error: resource already in state
terraform state rm aws_instance.web
terraform import aws_instance.web i-12345
# Error: resource not found
# Check resource ID is correct
aws ec2 describe-instances --instance-ids i-12345

Plan Shows Changes After Import

# Get actual resource configuration
terraform show
# Update your .tf file to match

📝 Summary

Today you learned:

• ✅ Importing existing resources

• ✅ Moving resources in state

• ✅ Refactoring without destruction

• ✅ Import blocks (Terraform 1.5+)

• ✅ Import best practices

🚀 Tomorrow: Provisioners & Null Resources

← Day 21: Workspaces | Day 23: Provisioners →

🎯 Today’s Goals

• Understand Terraform workspaces

• Create and manage workspaces

• Use workspaces for environment isolation

• Learn workspace best practices and limitations

🌍 What Are Workspaces?

Workspaces allow you to manage multiple instances of a single configuration. Each workspace has its own state file.

Same Configuration → Multiple Workspaces → Separate States

my-infrastructure/
├── main.tf (shared)
├── terraform.tfstate.d/
│   ├── dev/terraform.tfstate
│   ├── staging/terraform.tfstate
│   └── prod/terraform.tfstate

📚 Workspace Commands

# List workspaces
terraform workspace list
# Show current workspace
terraform workspace show
# Create new workspace
terraform workspace new dev
# Switch workspace
terraform workspace select dev
# Delete workspace (must be empty)
terraform workspace delete dev

🔧 Using Workspaces

Basic Usage

# main.tf
resource "aws_instance" "app" {
  ami           = "ami-12345"
  instance_type = terraform.workspace == "prod" ? "t3.large" : "t2.micro"

  tags = {
    Name        = "app-${terraform.workspace}"
    Environment = terraform.workspace
  }
}

Workspace-Specific Values

locals {
  env_config = {
    dev = {
      instance_type = "t2.micro"
      instance_count = 1
    }
    staging = {
      instance_type = "t2.small"
      instance_count = 2
    }
    prod = {
      instance_type = "t3.large"
      instance_count = 3
    }
  }

  config = local.env_config[terraform.workspace]
}

resource "aws_instance" "app" {
  count = local.config.instance_count

  ami           = data.aws_ami.amazon_linux.id
  instance_type = local.config.instance_type

  tags = {
    Name = "${terraform.workspace}-app-${count.index}"
  }
}

🧪 Hands-On Lab

Step 1: Create Project

mkdir terraform-workspaces-lab
cd terraform-workspaces-lab

main.tf:

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

provider "aws" {
  region = "us-east-1"
}

locals {
  environments = {
    dev = {
      instance_type = "t2.micro"
      instance_count = 1
      cidr = "10.0.0.0/16"
    }
    staging = {
      instance_type = "t2.small"
      instance_count = 2
      cidr = "10.1.0.0/16"
    }
    prod = {
      instance_type = "t3.medium"
      instance_count = 3
      cidr = "10.2.0.0/16"
    }
  }

  env = local.environments[terraform.workspace]
}

resource "aws_vpc" "main" {
  cidr_block = local.env.cidr

  tags = {
    Name        = "${terraform.workspace}-vpc"
    Environment = terraform.workspace
  }
}

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = cidrsubnet(local.env.cidr, 8, 1)

  tags = {
    Name = "${terraform.workspace}-subnet"
  }
}

data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

resource "aws_instance" "app" {
  count = local.env.instance_count

  ami           = data.aws_ami.amazon_linux.id
  instance_type = local.env.instance_type
  subnet_id     = aws_subnet.public.id

  tags = {
    Name        = "${terraform.workspace}-app-${count.index + 1}"
    Environment = terraform.workspace
  }
}

output "workspace" {
  value = terraform.workspace
}

output "vpc_id" {
  value = aws_vpc.main.id
}

output "instance_ids" {
  value = aws_instance.app[*].id
}

Step 2: Use Workspaces

# Initialize
terraform init

# Create dev workspace
terraform workspace new dev
terraform plan
terraform apply -auto-approve

# Create staging workspace
terraform workspace new staging
terraform plan
terraform apply -auto-approve

# Switch to dev
terraform workspace select dev
terraform output

# List all workspaces
terraform workspace list

# View state files
ls -la terraform.tfstate.d/

# Clean up
terraform workspace select dev
terraform destroy -auto-approve

terraform workspace select staging
terraform destroy -auto-approve
terraform workspace select default

terraform workspace delete dev
terraform workspace delete staging

⚖️ Workspaces vs Directories

Workspaces

✅ Same code for all environments ✅ Easy to switch between environments ✅ Less code duplication ❌ All environments must be similar. ❌ Easy to accidentally apply to wrong environment

Separate Directories

✅ Complete isolation ✅ Different configurations per environment ✅ Safer (harder to make mistakes) ❌ More code duplication ❌ Harder to keep in sync

Recommendation

Use directories for production environments:

terraform/
├── dev/
├── staging/
└── prod/

Use workspaces for:

• Feature branches

• Temporary environments

• Testing

• Development

📝 Summary

Today you learned:

• ✅ Terraform workspaces

• ✅ Workspace commands

• ✅ Environment-specific configurations

• ✅ Workspaces vs directories

🚀 Tomorrow: Terraform Import & Moving Resources

← Day 20: Remote State | Day 23: Terraform Import →

🎯 Learning Objectives

By the end of today, you will be able to:

✅ Configure remote backends (S3 or Terraform Cloud)
✅ Enable state locking using DynamoDB
✅ Read data from remote state files
✅ Manage multiple environments using isolated states
✅ Understand state isolation strategies and best practices

🧩 What Is Terraform State?

Terraform keeps track of your infrastructure resources in a file called terraform.tfstate.
This file acts as a record of what resources Terraform manages and their current attributes (like IDs, IPs, etc).

By default, this state is stored locally (on your machine).
That works fine for testing — but it’s risky for real production environments.

⚠️ Problems with Local State

When Terraform state is stored locally, you face several issues:

✅ Why Use Remote State?

Remote backends solve all of these issues.
When you store your Terraform state remotely (for example, in S3 or Terraform Cloud), you get:

☁️ Remote State with AWS S3 (Recommended)

The most common backend setup for AWS-based projects is S3 + DynamoDB.

S3 stores the state file.
DynamoDB ensures state locking, preventing concurrent writes.

🧱 Basic S3 Backend Example

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

🧠 Explanation:

• bucket: The name of your S3 bucket that stores state.

• key: The path (like a folder) inside the bucket for the state file.

• region: AWS region of the bucket.

🔒 S3 Backend with DynamoDB Locking

terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "project/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
    workspace_key_prefix = "workspaces"
  }
}

🧠 Explanation:

• encrypt = true → Enables server-side encryption (AES-256).

• dynamodb_table → Uses DynamoDB to lock the state during apply.

• workspace_key_prefix → Keeps separate states for each workspace.

🏗️ Create Backend Infrastructure

Before configuring your backend, you must create the S3 bucket and DynamoDB table to store your state safely.

# backend-setup.tf
data "aws_caller_identity" "current" {}

resource "aws_s3_bucket" "terraform_state" {
  bucket = "terraform-state-${data.aws_caller_identity.current.account_id}"

  tags = {
    Name        = "Terraform State"
    Environment = "Production"
  }
}

resource "aws_s3_bucket_versioning" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_s3_bucket_public_access_block" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-state-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }

  tags = {
    Name        = "Terraform State Locks"
    Environment = "Production"
  }
}

🧠 Explanation:

• S3 Bucket: Stores Terraform state.

• Versioning: Keeps history of changes to allow rollback.

• Encryption: Protects your state file.

• Public Access Block: Prevents public exposure.

• DynamoDB Table: Manages state lock to prevent concurrent operations.

🔄 Initialize the Remote Backend

Migrating from Local to Remote

# Step 1: Add backend config

terraform {
  backend "s3" {
    bucket = "bucker-name
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
  }
}

# Step 2: Initialize with migration
terraform init -migrate-state

# Step 3: Verify S3 file
aws s3 ls s3://bucket-name/prod/

Reconfiguring Backend

# To change backend settings
terraform init -reconfigure

# To migrate existing state forcefully
terraform init -migrate-state -force-copy

🧠 Backend Configuration Patterns

Terraform gives you multiple ways to provide backend configuration.

🧩 Pattern 1: Partial Configuration (Recommended)

Keep sensitive values outside your code.

backend.tf

terraform {
  backend "s3" {}
}

backend-config/prod.hcl

bucket         = "prod-terraform-state"
key            = "infrastructure/terraform.tfstate"
region         = "us-east-1"
encrypt        = true
dynamodb_table = "prod-terraform-locks"

Initialize using:

terraform init -backend-config=backend-config/prod.hcl

🧩 Pattern 2: Environment Variables

export TF_CLI_ARGS_init="-backend-config=bucket=my-state-bucket"
terraform init

🧩 Pattern 3: Command Line Arguments

terraform init \
  -backend-config="bucket=my-state-bucket" \
  -backend-config="key=project/terraform.tfstate" \
  -backend-config="region=us-east-1"

🧱 State Isolation Strategies

State isolation ensures different environments (dev, staging, prod) do not interfere with each other.

1️⃣ Directory-Based Isolation

terraform/
├── dev/
│   └── backend.tf  # key = "dev/terraform.tfstate"
├── staging/
│   └── backend.tf  # key = "staging/terraform.tfstate"
└── prod/
    └── backend.tf  # key = "prod/terraform.tfstate"

Each environment has its own backend file and state file.

2️⃣ Workspaces

terraform {
  backend "s3" {
    bucket               = "terraform-state"
    key                  = "project.tfstate"
    workspace_key_prefix = "env"
    region               = "us-east-1"
  }
}

💡 Workspaces create automatically isolated state files:

s3://terraform-state/env/dev/project.tfstate
s3://terraform-state/env/prod/project.tfstate

terraform workspace new dev
terraform workspace select dev

☁️ Terraform Cloud Backend

Terraform Cloud provides a fully managed remote backend with versioning, state locking, and collaboration out of the box.

Basic Configuration

terraform {
  cloud {
    organization = "stackop"

    workspaces {
      name = "dev-workspace"
    }
  }
}

Using Multiple Workspaces

terraform {
  cloud {
    organization = "stackops"

    workspaces {
      tags = ["networking", "production"]
    }
  }
}

🎉 Summary

By now, you’ve learned how to:

✅ Configure and migrate to remote state
✅ Enable state locking with DynamoDB
✅ Organize environments using isolation strategies
✅ Use Terraform Cloud as an alternative backend

🚀 Day 21 Preview

Day 21: Workspaces for Environment Management

focuses on advanced techniques:

• Workspaces

• Terraform import

• Provisioners

• Testing strategies

• CI/CD integration

• Security best practices

← Day 19: Module Sources | Day 22: Workspaces →

Remember: Remote state is essential for team collaboration and production deployments!

By the end of today, you’ll know exactly how to:
✅ Use modules from different sources (local, Git, S3, etc.)
✅ Apply versioning best practices
✅ Manage dependencies between modules
✅ Publish and share your own reusable modules
✅ Upgrade modules safely in production

🎯 Today’s Learning Objectives

• Understand different Terraform module sources

• Learn semantic versioning and version constraints

• Use modules from the Terraform Registry

• Handle dependencies between modules

• Publish and upgrade your own Terraform modules safely

📚 1. Terraform Module Sources Explained

Terraform allows you to use modules from various sources—from your local filesystem to GitHub, Bitbucket, S3, and even Terraform Registry.

Let’s go through each type with examples. 👇

🔹 1. Local Modules

These are modules stored locally on your computer or within your project directory.

module "vpc" {
  source = "./modules/vpc"  # Local relative path
}

module "network" {
  source = "../shared-modules/network"  # Parent directory
}

module "app" {
  source = "/absolute/path/to/module"   # Absolute path
}

💡 Use case:

• You’re developing custom modules for your project

• You’re testing module changes quickly

• You’re working in a single repo (monorepo)

🔹 2. Terraform Registry Modules

These are prebuilt community or official modules available on Terraform Registry.

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.1.2"
}

Format:
<NAMESPACE>/<MODULE_NAME>/<PROVIDER>

💡 Use case:

• Want reliable, production-tested modules

• Want to save time and follow AWS best practices

• Example: terraform-aws-modules/vpc/aws, terraform-aws-modules/eks/aws

🔹 3. GitHub Modules

You can pull modules directly from GitHub via HTTPS, SSH, or specific version references.

# HTTPS
module "vpc" {
  source = "github.com/terraform-aws-modules/terraform-aws-vpc"
}

# Specific version (tag or branch)
module "vpc" {
  source = "github.com/terraform-aws-modules/terraform-aws-vpc?ref=v5.1.2"
}

# Subdirectory
module "example" {
  source = "github.com/hashicorp/terraform-aws-consul//modules/consul-cluster?ref=v0.11.0"
}

💡 Use case:

• Using custom internal modules hosted on GitHub

• Need fine-grained version control via Git tags

• Want to contribute or fork existing modules

🔹 4. Generic Git Repositories

You can use any Git server (GitLab, private repo, etc.):

module "vpc" {
  source = "git::https://gitlab-stackopsdiary.site/vpc.git?ref=v1.2.0"
}

💡 Use case:

• Enterprise teams hosting private infrastructure modules

🔹 5. S3, and HTTP Sources

You can also store your modules as ZIP archives in cloud storage or URLs.

S3 Example:

module "vpc" {
  source = "s3::https://s3-eu-west-1.amazonaws.com/company-modules/vpc-1.2.3.zip"
}

💡 Use case:

• Hosting private modules for secure internal distribution

• Integrating modules in CI/CD pipelines

🏷️ 2. Module Versioning (SemVer Explained)

🧩 Semantic Versioning (SemVer)

Terraform follows Semantic Versioning (MAJOR.MINOR.PATCH).

v1.2.3
 │ │ │
 │ │ └─ PATCH: Bug fixes (no breaking changes)
 │ └─── MINOR: Backward-compatible features
 └───── MAJOR: Breaking changes

So if a module goes from v2.3.1 → v3.0.0, it likely introduces breaking changes.

⚙️ Version Constraints

You can define how Terraform should handle module versions:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0" # Allows 5.x versions but not 6.x
}

✅ Best Practices

Do:

• Always pin versions for production

• Use ~> for minor auto-updates

• Document module version requirements

Don’t:

• Leave version unpinned

• Use latest without testing

• Jump to major versions blindly

🌐 3. Using Terraform Registry Modules

The Terraform Registry is like a module marketplace.

Steps:

1. Go to registry.terraform.io

2. Search, e.g., “aws vpc.”

3. Review downloads, provider support, last update, and documentation

Example: VPC + Security Group + RDS

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"
  name    = "my-vpc"
  cidr    = "10.0.0.0/16"
}

module "web_sg" {
  source  = "terraform-aws-modules/security-group/aws"
  version = "~> 5.0"
  vpc_id  = module.vpc.vpc_id
}

module "db" {
  source  = "terraform-aws-modules/rds/aws"
  version = "~> 6.0"
  engine  = "postgres"
}

These modules are battle-tested, frequently updated, and follow AWS best practices.

🔄 4. Managing Module Dependencies

Modules often depend on each other — e.g., your EC2 needs a VPC ID.

🔸 Implicit Dependency

Terraform automatically detects it when outputs are referenced:

module "vpc" {
  source = "./modules/vpc"
}

module "ec2" {
  source = "./modules/ec2"
  vpc_id = module.vpc.vpc_id  # Dependency created here
}

🔸 Explicit Dependency

You can also manually define dependencies:

module "monitoring" {
  source = "./modules/monitoring"
  depends_on = [module.vpc, module.ec2]
}

📦 5. Publishing Your Own Module

When your module is reusable, you can share it with others!

Structure Example

terraform-aws-mymodule/
├── README.md
├── main.tf
├── variables.tf
├── outputs.tf
├── versions.tf
├── examples/
└── LICENSE

Steps:

1. Create & tag version:

    git tag -a v1.0.0 -m "Initial release"
    git push origin v1.0.0
   

2. Publish on Terraform Registry

3. Follow naming:
   terraform-<PROVIDER>-<MODULE_NAME> (e.g. terraform-aws-vpc)

🧪 6. Hands-On Lab—Using Multiple Module Sources

Goal: Combine Registry, GitHub, and local modules.

mkdir terraform-module-sources-lab
cd terraform-module-sources-lab

main.tf (abridged):

provider "aws" {
  region = "us-east-1"
  profile = "stackops"
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 6.0"

  name = "stackop-main"
  cidr = "10.0.0.0/16"
}

module "security_group_web" {
  source = "github.com/terraform-aws-modules/terraform-aws-security-group?ref=v5.1.0"
  vpc_id = module.vpc.vpc_id
  name = "stackops-web"
}

Then:

terraform init
terraform plan
terraform apply
terraform destroy

You’ll see modules downloaded in .terraform/modules/.

🔧 7. Module Upgrade Strategy

When new versions are released:

1. Check for updates

    terraform init -upgrade
    git diff .terraform.lock.hcl
   

2. Test in dev
   Update the version in yours, apply, and validate.

3. Review changelog
   Always read release notes for breaking changes.

4. Gradual rollout:
   Dev → QA → Staging → Production.

📝 Day 19 Summary

Today, you learned how to:

✅ Use Terraform modules from local, Git, S3, and Registry sources
✅ Apply semantic versioning and constraints
✅ Manage module dependencies
✅ Publish your own modules
✅ Upgrade modules safely without breaking production

🚀 Tomorrow’s Preview

Day 20: Remote State & Backend Configuration

Tomorrow we’ll:

• Configure S3 backend

• Implement state locking

• Use remote state data sources

• Manage multiple state files

• Implement state isolation strategies

← Day 18: Custom Modules | Day 20: Remote State & Backend →

Remember: Proper versioning ensures stable, predictable infrastructure deployments!

If you want to work like a DevOps or cloud engineer in a real-world team, mastering this topic is absolutely essential.

🎯 Today’s Learning Goals

By the end of this lesson, you’ll be able to:

✅ Design production-quality Terraform modules that follow best practices
✅ Handle optional and conditional resources inside modules
✅ Build modular and composable infrastructure
✅ Make your modules flexible and reusable through inputs, locals, and outputs
✅ Use advanced module design patterns used by large organizations

🎨 Terraform Module Design Principles

When creating reusable modules, always design with clarity, flexibility, and simplicity in mind.
Here are the core principles used by top Terraform practitioners.

1. Single Responsibility Principle

Each module should do one thing well and be easy to understand in isolation.

This is similar to how a function in programming should only have one purpose.

❌ Bad Example — “God Module” (Too Big)

modules/infrastructure/
├── vpc, subnets, instances, databases, load balancers...

This “mega-module” mixes everything — networking, compute, database, and load balancers.
It’s hard to maintain, reuse, or debug because a small change can break unrelated components.

✅ Good Example — Focused Modules

modules/
├── networking/       # Handles VPC, subnets, route tables
├── compute/          # Manages EC2 instances or Auto Scaling Groups
├── database/         # Creates RDS or DynamoDB
└── load-balancer/    # Manages ALB or NLB

Now, each module has a single responsibility, making it:

• Easier to test

• Easier to reuse

• Easier to maintain and version

2. Composable Design — Modules Working Together

Think of modules like Lego blocks — small, independent, and connectable.

Each module should expose outputs that can be consumed by another module.

Example:

# Create a network (VPC and subnets)
module "network" {
  source = "./modules/networking"
}

# Compute module (EC2) depends on VPC outputs
module "compute" {
  source = "./modules/compute"

  vpc_id     = module.network.vpc_id
  subnet_ids = module.network.private_subnet_ids
}

# Database module reuses same network data
module "database" {
  source = "./modules/database"

  vpc_id     = module.network.vpc_id
  subnet_ids = module.network.database_subnet_ids
}

Here:

• module.network → provides foundational infrastructure

• module.compute and module.database → consume network outputs

• Each module can be updated independently

3. Sensible Defaults

Always define defaults for common cases so users can use the module with minimal setup.

When building reusable modules, your goal is to make them simple for beginners but flexible for experts.

Example:

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"  # Common low-cost instance
}

variable "monitoring" {
  description = "Enable detailed monitoring"
  type        = bool
  default     = false       # Optional feature, off by default
}

Now, your module can be used without providing extra inputs:

module "web" {
  source = "./modules/compute"
}

Or overridden easily when needed:

module "web" {
  source        = "./modules/compute"
  instance_type = "t3.medium"
  monitoring    = true
}

4. Input Validation — Guard Against Mistakes

Validation helps catch invalid configurations early before Terraform even runs.

Without validation, a user could accidentally input something wrong — like instance_count = 0 — and cause unexpected errors.

Example:

variable "environment" {
  type = string

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod."
  }
}

variable "instance_count" {
  type = number

  validation {
    condition     = var.instance_count > 0 && var.instance_count <= 10
    error_message = "Instance count must be between 1 and 10."
  }
}

🧠 Tip:
Validations help prevent “human error” and enforce team-wide standards.

🧩 Advanced Module Patterns

Now let’s dive into advanced design patterns that make modules dynamic, flexible, and smart.

🧱 Pattern 1: Optional Resources (Using count)

Sometimes, you want certain resources (like bastion hosts or ALBs) to be optional — depending on configuration.

Example:

variables.tf

variable "create_bastion" {
  description = "Whether to create a bastion host"
  type        = bool
  default     = false
}

variable "create_alb" {
  description = "Whether to create an Application Load Balancer"
  type        = bool
  default     = true
}

main.tf

resource "aws_instance" "bastion" {
  count = var.create_bastion ? 1 : 0

  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t2.micro"
}

resource "aws_lb" "app" {
  count = var.create_alb ? 1 : 0

  name               = "${var.name}-alb"
  load_balancer_type = "application"
}

This makes your module conditional — creating resources only when needed.

🚩 Pattern 2: Feature Flags (Turn Features On or Off)

Feature flags allow users to toggle specific features of your module without changing the logic.

Example:

variable "features" {
  description = "Feature toggles for the module"
  type = object({
    auto_scaling = bool
    monitoring   = bool
    backup       = bool
  })
  default = {
    auto_scaling = false
    monitoring   = false
    backup       = false
  }
}

resource "aws_autoscaling_group" "this" {
  count = var.features.auto_scaling ? 1 : 0
  # ...
}

resource "aws_cloudwatch_dashboard" "this" {
  count = var.features.monitoring ? 1 : 0
  # ...
}

Users can now control features easily:

module "app" {
  source = "./modules/app"

  features = {
    auto_scaling = true
    monitoring   = true
    backup       = false
  }
}

🏗️ Pattern 3: Environment-Specific Behavior

Use environment names (dev, staging, prod) to dynamically change resource settings.

This is one of the most realistic and powerful Terraform techniques — commonly used in enterprise setups.

Example:

variable "environment" {
  description = "Environment name (dev, staging, prod)"
  type        = string
}

locals {
  is_production = var.environment == "prod"

  instance_config = {
    dev = {
      type  = "t2.micro"
      count = 1
    }
    staging = {
      type  = "t2.small"
      count = 2
    }
    prod = {
      type  = "t3.medium"
      count = 3
    }
  }

  selected_config = local.instance_config[var.environment]
}

resource "aws_instance" "app" {
  count         = local.selected_config.count
  instance_type = local.selected_config.type
  monitoring    = local.is_production
}

✅ Result:

• Dev → 1 small instance

• Staging → 2 medium instances

• Prod → 3 large instances with monitoring enabled

This makes a single module automatically adapt to different environments.

🏷️ Pattern 4: Flexible Tagging System

Consistent tagging helps with cost tracking, ownership, and automation.
You can merge “standard tags” with user-provided ones.

Example:

variable "tags" {
  description = "Additional custom tags"
  type        = map(string)
  default     = {}
}

variable "name" {
  description = "Resource name"
  type        = string
}

locals {
  common_tags = merge(
    {
      Name        = var.name
      ManagedBy   = "Terraform"
      Module      = "app"
    },
    var.tags  # Allow users to override or add
  )
}

resource "aws_instance" "this" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t2.micro"
  tags          = local.common_tags
}

✅ Resulting Tags Example:

tags = {
  Name        = "web-server"
  ManagedBy   = "Terraform"
  Module      = "app"
  Environment = "staging"  # Custom user tag
}

🧪 Hands-On Practice (Recommended)

We'll use:

• ✅ Conditional logic (locals)

• ✅ Clean module structure

• ✅ Simple user-data.sh to run a web server

• ✅ A reusable module you can plug anywhere

🌟 Goal

A Terraform project that:

• Creates a VPC (basic networking)

• Creates 1 EC2 instance

• Automatically configures instance type based on environment (dev, qa, staging, prod)

• Outputs the public IP so you can open it in your browser

📂 Folder Structure

terraform-env-ec2-lab/
├── main.tf
├── outputs.tf
├── providers.tf
└── modules/
    ├── vpc/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    └── web-app/
        ├── main.tf
        ├── variables.tf
        ├── locals.tf
        ├── outputs.tf
        └── templates/
            └── user-data.sh

🌐 1. VPC Module

modules/vpc/variables.tf

variable "vpc_name" {
  description = "VPC name"
  type        = string
}

variable "vpc_cidr" {
  description = "VPC CIDR block"
  type        = string
  default     = "10.0.0.0/16"
}

variable "azs" {
  description = "Availability zones"
  type        = list(string)
}

variable "public_subnets" {
  description = "Public subnet CIDRs"
  type        = list(string)
}

variable "tags" {
  description = "Additional tags"
  type        = map(string)
  default     = {}
}

modules/vpc/main.tf

resource "aws_vpc" "this" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = merge(
    {
      Name = var.vpc_name
    },
    var.tags
  )
}

resource "aws_internet_gateway" "this" {
  vpc_id = aws_vpc.this.id
  tags = {
    Name = "${var.vpc_name}-igw"
  }
}

resource "aws_subnet" "public" {
  count                   = length(var.public_subnets)
  vpc_id                  = aws_vpc.this.id
  cidr_block              = var.public_subnets[count.index]
  map_public_ip_on_launch = true
  availability_zone       = var.azs[count.index % length(var.azs)]

  tags = {
    Name = "${var.vpc_name}-public-${count.index + 1}"
  }
}

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.this.id
  tags = {
    Name = "${var.vpc_name}-public-rt"
  }
}

resource "aws_route" "public_internet" {
  route_table_id         = aws_route_table.public.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.this.id
}

resource "aws_route_table_association" "public" {
  count          = length(aws_subnet.public)
  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

modules/vpc/outputs.tf

output "vpc_id" {
  value = aws_vpc.this.id
}

output "public_subnet_ids" {
  value = aws_subnet.public[*].id
}

💻 2. Environment-Aware EC2 Module

modules/web-app/variables.tf

variable "name" {
  description = "Application name"
  type        = string
}

variable "environment" {
  description = "Environment name (dev, qa, staging, prod)"
  type        = string

  validation {
    condition     = contains(["dev", "qa", "staging", "prod"], var.environment)
    error_message = "Environment must be one of: dev, qa, staging, prod."
  }
}

variable "vpc_id" {
  description = "VPC ID"
  type        = string
}

variable "subnet_id" {
  description = "Subnet ID for EC2 instance"
  type        = string
}

variable "key_name" {
  description = "Key pair name for SSH access"
  type        = string
}

variable "allowed_cidr_blocks" {
  description = "CIDR blocks allowed to access EC2"
  type        = list(string)
  default     = ["0.0.0.0/0"]
}

variable "tags" {
  description = "Additional resource tags"
  type        = map(string)
  default     = {}
}

modules/web-app/locals.tf

locals {
  # Define instance configuration based on environment
  instance_config = {
    dev = {
      type = "t2.micro"
    }
    qa = {
      type = "t3.medium"
    }
    staging = {
      type = "t3.large"
    }
    prod = {
      type = "t3.xlarge"
    }
  }

  instance_type = lookup(local.instance_config[var.environment], "type", "t2.micro")

  name_prefix = "${var.name}-${var.environment}"

  common_tags = merge(
    {
      Name        = local.name_prefix
      Environment = var.environment
      ManagedBy   = "Terraform"
      Module      = "web-app"
    },
    var.tags
  )
}

modules/web-app/main.tf

data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

# Security Group
resource "aws_security_group" "this" {
  name        = "${local.name_prefix}-sg"
  description = "Allow HTTP and SSH"
  vpc_id      = var.vpc_id

  ingress {
    description = "Allow HTTP"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = var.allowed_cidr_blocks
  }

  ingress {
    description = "Allow SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = var.allowed_cidr_blocks
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = local.common_tags
}

# EC2 Instance
resource "aws_instance" "this" {
  ami                    = data.aws_ami.amazon_linux.id
  instance_type          = local.instance_type
  subnet_id              = var.subnet_id
  key_name               = var.key_name
  vpc_security_group_ids = [aws_security_group.this.id]
  associate_public_ip_address = true

  user_data = templatefile("${path.module}/templates/user-data.sh", {
    app_name    = var.name
    environment = var.environment
  })

  tags = local.common_tags
}

modules/web-app/outputs.tf

output "instance_id" {
  value = aws_instance.this.id
}

output "public_ip" {
  value = aws_instance.this.public_ip
}

output "private_ip" {
  value = aws_instance.this.private_ip
}

output "instance_type" {
  value = aws_instance.this.instance_type
}

modules/web-app/templates/user-data.sh

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd

cat > /var/www/html/index.html <<EOF
<html>
  <head><title>${app_name}</title></head>
  <body>
    <h1>${app_name}</h1>
    <p>Environment: ${environment}</p>
    <p>Instance Type: $(curl -s http://169.254.169.254/latest/meta-data/instance-type)</p>
    <p>Instance ID: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)</p>
    <p>Availability Zone: $(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)</p>
  </body>
</html>
EOF

🧩 3. Root Configuration

main.tf

# VPC module
module "vpc" {
  source = "./modules/vpc"

  vpc_name       = "env-vpc"
  vpc_cidr       = "10.0.0.0/16"
  azs            = ["us-east-1a", "us-east-1b"]
  public_subnets = ["10.0.1.0/24", "10.0.2.0/24"]

  tags = {
    Project = "env-based-ec2"
  }
}

# Dev Environment EC2
module "dev_app" {
  source = "./modules/web-app"

  name        = "webapp"
  environment = "dev"
  vpc_id      = module.vpc.vpc_id
  subnet_id   = module.vpc.public_subnet_ids[0]
  key_name    = "stackops" # replace this

  tags = {
    Environment = "Dev"
    Team        = "Platform"
    Owner       = "StackOps"
  }
}

# QA Environment EC2
module "qa_app" {
  source = "./modules/web-app"

  name        = "webapp"
  environment = "qa"
  vpc_id      = module.vpc.vpc_id
  subnet_id   = module.vpc.public_subnet_ids[1]
  key_name    = "stackops" # replace this

  tags = {
    Environment = "QA"
    Team        = "Platform"
    Owner       = "StackOps"
  }
}

# Prod Environment EC2
module "prod_app" {
  source = "./modules/web-app"

  name        = "webapp"
  environment = "prod"
  vpc_id      = module.vpc.vpc_id
  subnet_id   = module.vpc.public_subnet_ids[0]
  key_name    = "stackops" # replace this

  tags = {
    Environment = "production"
    Team        = "Platform"
    Owner       = "StackOps"
  }
}

providers.tf

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

provider "aws" {
  region  = "us-east-1"
  profile = "stackops"
}

outputs.tf

output "dev_public_ip" {
  value = module.dev_app.public_ip
}

output "qa_public_ip" {
  value = module.qa_app.public_ip
}

output "prod_public_ip" {
  value = module.prod_app.public_ip
}

4. Run

terraform fmt
terraform init
terraform validate
terraform plan
terraform apply

✅ Terraform will:

• Create a VPC

• Deploy 3 EC2 instances (dev, qa, prod)

• Each instance will use the right instance type:

  • dev → t2.micro

  • qa → t3.medium

  • staging → t3.large (if added)

  • prod → t3.xlarge

Then you’ll get outputs like

dev_public_ip = 3.87.122.14
qa_public_ip = 18.205.33.19
prod_public_ip = 54.165.211.75

🌐 Test in Browser

Open in your browser:

http://<dev_public_ip>
http://<qa_public_ip>
http://<prod_public_ip>

Each page shows:

• Environment name

• Instance type

• Instance ID and AZ

🧹 Cleanup

terraform destroy -auto-approve

📝 Summary

Today you learned:

• ✅ Module design principles

• ✅ Optional and conditional resources

• ✅ Feature flags pattern

• ✅ Environment-specific behavior

• ✅ Production-ready module structure

• ✅ Module composition

🚀 Tomorrow’s Preview

Day 19: Module Sources & Versioning

Tomorrow we’ll:

• Publish modules to registries

• Version modules properly

• Use remote module sources

• Manage module dependencies

• Implement module upgrades

← Day 17: Introduction to Modules | Day 19: Module Sources →

Remember: Well-designed modules are reusable, flexible, and easy to understand!

Modules allow you to organize, reuse, and simplify your infrastructure code. Once you understand modules, you’ll be able to build scalable, clean, and production-grade Terraform configurations.

🎯 Today’s Goals

By the end of this lesson, you will be able to:

• ✅ Understand what Terraform modules are and why they’re so powerful

• ✅ Learn how modules are structured and organized

• ✅ Use public modules from the Terraform Registry

• ✅ Pass data between modules using input variables and outputs

• ✅ Build your first custom module step by step

📦 What Are Terraform Modules?

In simple terms, a module is just a collection of Terraform files that work together to manage a set of related resources.

Every Terraform configuration — even a simple one — is technically a module called the root module.
Any module that you call or include inside it is called a child module.

🧩 Why Use Modules?

Here’s why modules are essential when your infrastructure grows:

💡 Think of Modules Like Functions

Terraform modules are similar to programming functions:

For example, instead of repeating the same EC2 setup in 5 different projects, you can wrap it in a module and just call it wherever you need it.

🏗️ Module Structure

Let’s look at what a module typically looks like.

Basic Module Layout

my-module/
├── main.tf          # Main resource definitions
├── variables.tf     # Input variable declarations
├── outputs.tf       # Output value declarations
├── README.md        # Documentation (how to use the module)
└── versions.tf      # Provider and version constraints (optional)

Each file has a purpose:

• main.tf → defines your resources (e.g., AWS EC2, S3, etc.)

• variables.tf → defines configurable inputs (like instance type)

• outputs.tf → defines what data you want to expose (like IDs or IPs)

• README.md → explains how to use your module (important when sharing)

• versions.tf → locks provider versions to prevent breaking changes

Root Module vs Child Module

Here’s how your project might look when using multiple modules:

project/
├── main.tf          # Root module (entry point)
├── variables.tf     # Root module inputs
├── outputs.tf       # Root module outputs
└── modules/
    ├── vpc/         # Child module 1
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    └── ec2/         # Child module 2
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

The root module is your main Terraform directory — the one you run commands in.
The child modules are reusable building blocks stored in the modules/ folder.

📥 Using Modules in Terraform

You can include a module using the module block.

Basic Module Usage

module "module_name" {
  source = "./path/to/module"  # Location of the module folder

  # Provide input variables
  variable_name = value
}

🧠 Example: Creating and Using a Simple S3 Module

Let’s create a reusable module that provisions an S3 bucket.

Step 1: Create the Module

Folder: modules/s3-bucket/

main.tf

resource "aws_s3_bucket" "this" {
  bucket = var.bucket_name
  tags   = var.tags
}

variables.tf

variable "bucket_name" {
  description = "Name of the S3 bucket"
  type        = string
}

variable "tags" {
  description = "Tags for the S3 bucket"
  type        = map(string)
  default     = {}
}

outputs.tf

output "bucket_id" {
  description = "The ID of the S3 bucket"
  value       = aws_s3_bucket.this.id
}

output "bucket_arn" {
  description = "The ARN of the S3 bucket"
  value       = aws_s3_bucket.this.arn
}

Step 2: Use the Module in Root Configuration

main.tf

module "logs_bucket" {
  source = "./modules/s3-bucket"

  bucket_name = "my-logs-bucket"
  tags = {
    Purpose = "Logs"
    Owner   = "DevOps"
  }
}

# Access outputs from the module
output "logs_bucket_id" {
  value = module.logs_bucket.bucket_id
}

🌍 Different Module Sources

Terraform modules can come from many sources — not just local folders.

1. Local Path

module "vpc" {
  source = "./modules/vpc"
}

module "network" {
  source = "../shared-modules/network"
}

2. Terraform Registry

You can use official or community modules from registry.terraform.io.

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"

  name = "my-vpc"
  cidr = "10.0.0.0/16"
}

3. GitHub

module "vpc" {
  source = "github.com/terraform-aws-modules/terraform-aws-vpc"
}

# Use a specific branch or tag
module "vpc" {
  source = "github.com/terraform-aws-modules/terraform-aws-vpc?ref=v5.0.0"
}

4. S3 Bucket

module "vpc" {
  source = "s3::https://s3.amazonaws.com/mybucket/modules/vpc.zip"
}

📋 Module Input Variables (Passing Data In)

Modules use input variables to accept configuration from the root module.

Example – modules/ec2/variables.tf

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t2.micro"
}

variable "instance_count" {
  description = "Number of instances to launch"
  type        = number
}

variable "tags" {
  description = "Tags for EC2 instances"
  type        = map(string)
  default     = {}
}

Using the Module:

module "web_servers" {
  source = "./modules/ec2"

  # passing the variable values from the root module main.tf 
  instance_type  = "t2.small"
  instance_count = 3
  tags = {
    Environment = "production"
    Team        = "platform"
    Owner       = "StackOps"
  }
}

📤 Module Outputs — Getting Data Out of a Module

In Terraform, outputs are a way for a module to expose information about the resources it manages.

You can think of outputs like return values from a function in programming.

🧠 What Are Outputs?

When you define a module, it may create multiple resources — for example:

• EC2 instances

• S3 buckets

• VPCs

• Load balancers

Sometimes, you want to use information from those resources outside the module (in your root configuration or another module).

That’s where outputs come in.

📦 Outputs let you “export” specific data from a module so that other parts of your Terraform configuration can use it.

⚙️ Output Declaration — The Syntax

To define an output inside a module, use the output block:

output "<name>" {
  description = "Description of what this output represents"
  value       = <expression>
}

Fields explained:

• name → The name you’ll use to reference this output later (e.g., bucket_arn)

• description → Optional but helpful when sharing modules

• value → The actual Terraform expression or attribute you want to expose

🧩 Example: S3 Bucket Module Outputs

Let’s look at a simple example.

Imagine you created an S3 bucket module (modules/s3-bucket) like this:

main.tf

resource "aws_s3_bucket" "this" {
  bucket = var.bucket_name
  tags   = var.tags
}

Now, you might want to expose:

• The Bucket ID

• The Bucket ARN

outputs.tf

output "bucket_id" {
  description = "The ID of the S3 bucket"
  value       = aws_s3_bucket.this.id
}

output "bucket_arn" {
  description = "The ARN (Amazon Resource Name) of the S3 bucket"
  value       = aws_s3_bucket.this.arn
}

🧱 Using Outputs in the Root Module

Now in your root module (the main Terraform project folder), you use the S3 module:

main.tf

module "logs_bucket" {
  source = "./modules/s3-bucket"

  bucket_name = "my-logs-bucket"
  tags = {
    Purpose = "Logs"
  }
}

Once Terraform creates the S3 bucket, the module outputs can be accessed using the following syntax:

module.<module_name>.<output_name>

So in this case:

module.logs_bucket.bucket_id
module.logs_bucket.bucket_arn

You can use them in:

• Other resource definitions

• Other modules

• Root-level outputs (to display after apply)

🖥️ Displaying Outputs in the Root Module

If you want Terraform to print those outputs after you run terraform apply, define an output block in your root module too:

output "logs_bucket_id" {
  value = module.logs_bucket.bucket_id
}

output "logs_bucket_arn" {
  value = module.logs_bucket.bucket_arn
}

When you run terraform apply, Terraform will show something like:

logs_bucket_id = "my-logs-bucket"
logs_bucket_arn = "arn:aws:s3:::my-logs-bucket"

🔁 Real-World Example — Using Outputs Between Modules

Let’s say you have:

• A VPC module that creates a VPC and subnets.

• An EC2 module that launches instances.

You want the EC2 module to automatically use the subnet IDs from the VPC module.

Step 1: VPC Module Outputs

modules/vpc/outputs.tf

output "vpc_id" {
  value = aws_vpc.main.id
}

output "public_subnets" {
  value = aws_subnet.public[*].id
}

Step 2: EC2 Module Inputs

modules/ec2/variables.tf

variable "subnet_ids" {
  description = "List of subnet IDs where EC2 instances will be launched"
  type        = list(string)
}

Step 3: Pass Output Data Between Modules

Now in your root module:

module "vpc" {
  source = "./modules/vpc"
  cidr_block = "10.0.0.0/16"
}

module "ec2" {
  source = "./modules/ec2"

  subnet_ids = module.vpc.public_subnets  # 👈 Using output from another module
}

Terraform will automatically pass the list of subnet IDs from the VPC module’s outputs into the EC2 module’s inputs.

🧪 Hands-On Lab: Build Your First Module

Let’s create a reusable VPC module!

Step 1: Create Project Structure

mkdir terraform-modules-lab
cd terraform-modules-lab
mkdir -p modules/vpc

Step 2: Create VPC Module

modules/vpc/variables.tf:

variable "vpc_name" {
  description = "Name of the VPC"
  type        = string
}

variable "vpc_cidr" {
  description = "CIDR block for VPC"
  type        = string
  default     = "10.0.0.0/16"
}

variable "azs" {
  description = "Availability zones"
  type        = list(string)
}

variable "public_subnets" {
  description = "Public subnet CIDR blocks"
  type        = list(string)
}

variable "private_subnets" {
  description = "Private subnet CIDR blocks"
  type        = list(string)
  default     = []
}

variable "enable_nat_gateway" {
  description = "Enable NAT gateway"
  type        = bool
  default     = false
}

variable "tags" {
  description = "Additional tags"
  type        = map(string)
  default     = {}
}

modules/vpc/main.tf:

# VPC
resource "aws_vpc" "this" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = merge(
    var.tags,
    { Name = var.vpc_name }
  )
}

# Internet Gateway
resource "aws_internet_gateway" "this" {
  vpc_id = aws_vpc.this.id

  tags = merge(
    var.tags,
    { Name = "${var.vpc_name}-igw" }
  )
}

# Public Subnets
resource "aws_subnet" "public" {
  count = length(var.public_subnets)

  vpc_id                  = aws_vpc.this.id
  cidr_block              = var.public_subnets[count.index]
  availability_zone       = var.azs[count.index]
  map_public_ip_on_launch = true

  tags = merge(
    var.tags,
    {
      Name = "${var.vpc_name}-public-${count.index + 1}"
      Type = "Public"
    }
  )
}

# Private Subnets
resource "aws_subnet" "private" {
  count = length(var.private_subnets)

  vpc_id            = aws_vpc.this.id
  cidr_block        = var.private_subnets[count.index]
  availability_zone = var.azs[count.index]

  tags = merge(
    var.tags,
    {
      Name = "${var.vpc_name}-private-${count.index + 1}"
      Type = "Private"
    }
  )
}

# Public Route Table
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.this.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.this.id
  }

  tags = merge(
    var.tags,
    { Name = "${var.vpc_name}-public-rt" }
  )
}

# Public Route Table Associations
resource "aws_route_table_association" "public" {
  count = length(aws_subnet.public)

  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

# NAT Gateway (conditional)
resource "aws_eip" "nat" {
  count = var.enable_nat_gateway ? length(var.azs) : 0

  domain = "vpc"

  tags = merge(
    var.tags,
    { Name = "${var.vpc_name}-nat-eip-${count.index + 1}" }
  )
}

resource "aws_nat_gateway" "this" {
  count = var.enable_nat_gateway ? length(var.azs) : 0

  allocation_id = aws_eip.nat[count.index].id
  subnet_id     = aws_subnet.public[count.index].id

  tags = merge(
    var.tags,
    { Name = "${var.vpc_name}-nat-${count.index + 1}" }
  )
}

# Private Route Tables (if NAT enabled)
resource "aws_route_table" "private" {
  count = var.enable_nat_gateway ? length(var.azs) : 0

  vpc_id = aws_vpc.this.id

  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.this[count.index].id
  }

  tags = merge(
    var.tags,
    { Name = "${var.vpc_name}-private-rt-${count.index + 1}" }
  )
}

# Private Route Table Associations
resource "aws_route_table_association" "private" {
  count = var.enable_nat_gateway ? length(aws_subnet.private) : 0

  subnet_id      = aws_subnet.private[count.index].id
  route_table_id = aws_route_table.private[count.index].id
}

modules/vpc/outputs.tf:

output "vpc_id" {
  description = "VPC ID"
  value       = aws_vpc.this.id
}

output "vpc_cidr" {
  description = "VPC CIDR block"
  value       = aws_vpc.this.cidr_block
}

output "public_subnet_ids" {
  description = "Public subnet IDs"
  value       = aws_subnet.public[*].id
}

output "private_subnet_ids" {
  description = "Private subnet IDs"
  value       = aws_subnet.private[*].id
}

output "igw_id" {
  description = "Internet Gateway ID"
  value       = aws_internet_gateway.this.id
}

output "nat_gateway_ids" {
  description = "NAT Gateway IDs"
  value       = aws_nat_gateway.this[*].id
}

output "public_route_table_id" {
  description = "Public route table ID"
  value       = aws_route_table.public.id
}

output "private_route_table_ids" {
  description = "Private route table IDs"
  value       = aws_route_table.private[*].id
}

Step 3: Use the Module

Create root module files:

main.tf:

data "aws_availability_zones" "available" {
  state = "available"
}

# Development VPC
module "dev_vpc" {
  source = "./modules/vpc"

  vpc_name        = "dev-vpc"
  vpc_cidr        = "10.0.0.0/16"
  azs             = slice(data.aws_availability_zones.available.names, 0, 2)
  public_subnets  = ["10.0.1.0/24", "10.0.2.0/24"]
  private_subnets = ["10.0.11.0/24", "10.0.12.0/24"]

  enable_nat_gateway = false

  tags = {
    Environment = "development"
    Project     = "modules-lab"
    Owner       = "StackOps"
  }
}

# Production VPC
module "prod_vpc" {
  source = "./modules/vpc"

  vpc_name        = "prod-vpc"
  vpc_cidr        = "172.16.0.0/16"
  azs             = slice(data.aws_availability_zones.available.names, 0, 3)
  public_subnets  = ["172.16.1.0/24", "172.16.2.0/24", "172.16.3.0/24"]
  private_subnets = ["172.16.11.0/24", "172.16.12.0/24", "172.16.13.0/24"]

  enable_nat_gateway = true

  tags = {
    Environment = "production"
    Project     = "modules-lab"
    Owner       = "StackOps"
  }
}

variables.tf:

variable "aws_region" {
  type    = string
  default = "us-east-1"
}

outputs.tf:

output "dev_vpc_info" {
  description = "Development VPC information"
  value = {
    vpc_id             = module.dev_vpc.vpc_id
    public_subnet_ids  = module.dev_vpc.public_subnet_ids
    private_subnet_ids = module.dev_vpc.private_subnet_ids
  }
}

output "prod_vpc_info" {
  description = "Production VPC information"
  value = {
    vpc_id             = module.prod_vpc.vpc_id
    public_subnet_ids  = module.prod_vpc.public_subnet_ids
    private_subnet_ids = module.prod_vpc.private_subnet_ids
    nat_gateway_ids    = module.prod_vpc.nat_gateway_ids
  }
}

providers.tf:

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

provider "aws" {
  region = var.aws_region
}

Step 4: Deploy

# Initialize (downloads module dependencies)
terraform fmt
terraform init
# Plan
terraform plan
# Apply
terraform apply
# View outputs
terraform output
# Destroy
terraform destroy -auto-approve

🔗 Module Best Practices

✅ DO:

1. Keep modules focused - One purpose per module

2. Use clear naming - Descriptive variable names

3. Document everything - README, variable descriptions

4. Version your modules - Use tags/releases

5. Provide defaults - Sensible default values

6. Use outputs - Expose useful information

❌ DON’T:

1. Don’t hardcode values - Use variables

2. Don’t create god modules - Keep them small

3. Don’t skip documentation

4. Don’t ignore versioning

📝 Summary

Today you learned:

• ✅ What modules are and their benefits

• ✅ Module structure and organization

• ✅ Module sources (local, registry, git)

• ✅ Input variables and outputs

• ✅ Creating and using custom modules

• ✅ Module best practices

🚀 Tomorrow’s Preview

Day 18: Creating Your Own Reusable Modules

Tomorrow we’ll:

• Design production-ready modules

• Handle optional resources

• Create module composition patterns

• Implement module testing

• Publish modules to registry

Happy Learning! 🎉

Thanks For Reading, Follow Me For More

Subscribe youtube channel for the recap video

Have a great day!..

← Day 16: Dynamic Blocks | Day 18: Custom Modules →

Remember*: Modules are the foundation of scalable, maintainable infrastructure!*

🎯 Today’s Goals

• Understand dynamic blocks and their purpose

• Create dynamic security group rules

• Use for_each in dynamic blocks

• Handle complex nested blocks

• Build flexible, data-driven resources

🧩 What is a Dynamic Block in Terraform?

A dynamic block allows you to generate nested blocks dynamically inside a resource — especially useful when the number of nested blocks changes based on variables or lists.

Normally, in Terraform, you would define multiple ingress or egress rules like this:

resource "aws_security_group" "example" {
  name        = "example-sg"
  description = "Example security group"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

But what if your ingress rules are dynamic, and you want to loop over them instead of writing each one manually?

That’s where dynamic blocks come in.

🚀 Syntax of a Dynamic Block

A dynamic block has this format:

dynamic "<block_label>" {
  for_each = <collection>
  content {
    # configuration for each generated block
  }
}

Explanation:

• block_label → the nested block name (e.g., ingress, egress)

• for_each → the list or map to iterate over

• content → defines the inside of each block

🛠 Example: AWS Security Group with Dynamic Ingress Rules

Let’s make it practical. 👇

variables.tf

variable "ingress_rules" {
  type = list(object({
    from_port   = number
    to_port     = number
    protocol    = string
    cidr_blocks = list(string)
  }))
  default = [
    {
      from_port   = 22
      to_port     = 22
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    },
    {
      from_port   = 80
      to_port     = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    },
    {
      from_port   = 443
      to_port     = 443
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }
  ]
}

main.tf

provider "aws" {
  region = "ap-southeast-1"
}

resource "aws_security_group" "web_sg" {
  name        = "web-sg"
  description = "Security group with dynamic ingress rules"
  vpc_id      = "vpc-1234567890abcdef0" # Replace with your VPC ID

  # Dynamic ingress rule generation
  dynamic "ingress" {
    for_each = var.ingress_rules
    content {
      from_port   = ingress.value.from_port
      to_port     = ingress.value.to_port
      protocol    = ingress.value.protocol
      cidr_blocks = ingress.value.cidr_blocks
    }
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "web-sg"
  }
}

🧠 What’s Happening Here?

Terraform will loop through each item in var.ingress_rules and create one ingress block for each.

So the final plan will be equivalent to manually writing:

ingress {
  from_port   = 22
  to_port     = 22
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
}

ingress {
  from_port   = 80
  to_port     = 80
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
}

ingress {
  from_port   = 443
  to_port     = 443
  protocol    = "tcp"
  cidr_blocks = ["0.0.0.0/0"]
}

🧩 Optional — Using Maps Instead of Lists

You can also use a map, which gives you access to both the key and value.

provider "aws" {
  region = "ap-southeast-1"
}

variable "ingress_rules_map" {
  type = map(object({
    from_port   = number
    to_port     = number
    protocol    = string
    cidr_blocks = list(string)
  }))

  default = {
    ssh = {
      from_port   = 22
      to_port     = 22
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }
    http = {
      from_port   = 80
      to_port     = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }
  }
}

resource "aws_security_group" "web_sg_map" {
  name   = "web-sg-map"
  vpc_id = "vpc-1234567890abcdef0"

  dynamic "ingress" {
    for_each = var.ingress_rules_map
    content {
      description = ingress.key
      from_port   = ingress.value.from_port
      to_port     = ingress.value.to_port
      protocol    = ingress.value.protocol
      cidr_blocks = ingress.value.cidr_blocks
    }
  }
}

This version adds a description for each ingress rule based on the map key (e.g., "ssh", "http").

✅ Benefits of Using Dynamic Blocks

Let’s go deep into nested dynamic blocks — like how to dynamically generate tags, or even deeper structures inside a resource.

🧩 What Is a Nested Dynamic Block?

A nested dynamic block means a dynamic block inside another dynamic block or a nested configuration.

In simple words:

You use a dynamic block inside another block (static or dynamic) to generate multiple levels of configuration dynamically.

🧠 Why Do We Need Nested Dynamic Blocks?

Some Terraform resources (like aws_lb_listener, aws_ecs_task_definition, etc.) have deeply nested configurations — e.g.:

• multiple rules

• each rule has multiple cidr_blocks or tags

• each tag or rule may differ depending on input

In those cases, you can nest dynamic blocks.

⚙️ Example 1: Dynamic + Nested Dynamic Block for ALB listener

Goal: Create an AWS Application Load Balancer (ALB) listener

• with multiple actions (dynamic)

• each action can have multiple target groups (nested dynamic).

You’ll see a real, supported nested dynamic → dynamic pattern.

🗂️ variables.tf

variable "listener_actions" {
  description = "List of listener actions with nested target groups"
  type = list(object({
    type          = string
    order         = number
    target_groups = list(object({
      arn   = string
      weight = number
    }))
  }))

  # Example demo data
  default = [
    {
      type  = "forward"
      order = 1
      target_groups = [
        { arn = "arn:aws:elasticloadbalancing:ap-southeast-1:111122223333:targetgroup/app1-tg/aaaa", weight = 1 },
        { arn = "arn:aws:elasticloadbalancing:ap-southeast-1:111122223333:targetgroup/app2-tg/bbbb", weight = 2 }
      ]
    },
    {
      type  = "redirect"
      order = 2
      target_groups = []
    }
  ]
}

🗂️ main.tf

provider "aws" {
  region = "ap-southeast-1"
}

# Mock Load Balancer just for structure demo (you can skip or replace)
resource "aws_lb" "demo_lb" {
  name               = "demo-alb"
  internal           = false
  load_balancer_type = "application"
  subnets            = ["subnet-aaa111", "subnet-bbb222"] # replace with yours
}

resource "aws_lb_listener" "demo_listener" {
  load_balancer_arn = aws_lb.demo_lb.arn
  port              = 80
  protocol          = "HTTP"

  # ----------------------------------- #
  # Dynamic Block: default_action       #
  # ----------------------------------- #
  dynamic "default_action" {
    for_each = var.listener_actions
    content {
      type  = default_action.value.type
      order = default_action.value.order

      # ----------------------------------- #
      # Nested Dynamic Block: forward block #
      # ----------------------------------- #
      dynamic "forward" {
        for_each = (
          default_action.value.type == "forward" ?
          [default_action.value] : []
        )
        content {

          # ------------------------------------------------- #
          # Nested Dynamic Block inside forward: target_group #
          # ------------------------------------------------- #
          dynamic "target_group" {
            for_each = forward.value.target_groups
            content {
              arn    = target_group.value.arn
              weight = target_group.value.weight
            }
          }
        }
      }

      # Example: redirect block for second action
      dynamic "redirect" {
        for_each = (
          default_action.value.type == "redirect" ?
          [default_action.value] : []
        )
        content {
          port        = "443"
          protocol    = "HTTPS"
          status_code = "HTTP_301"
        }
      }
    }
  }
}

🗂️ outputs.tf

output "listener_actions_result" {
  value = var.listener_actions
}

Run & Test

terraform init
terraform validate
terraform plan

✅ Expected result:
Terraform will successfully validate and show dynamically generated nested blocks:

Plan: 2 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + listener_actions_result = [
      + {
          + order         = 1
          + target_groups = [
              + {
                  + arn    = "arn:aws:elasticloadbalancing:ap-southeast-1:111122223333:targetgroup/app1-tg/aaaa"
                  + weight = 1
                },
              + {
                  + arn    = "arn:aws:elasticloadbalancing:ap-southeast-1:111122223333:targetgroup/app2-tg/bbbb"
                  + weight = 2
                },
            ]
          + type          = "forward"
        },
      + {
          + order         = 2
          + target_groups = []
          + type          = "redirect"
        },
    ]

🏗 Example 2: Simple Dynamic Tags for Any Resource

If your resource supports a tags block (not just a map), you can use:

dynamic "tags" {
  for_each = var.tags
  content {
    key   = tags.key
    value = tags.value
  }
}

But—most AWS resources already accept tags = {} maps directly, so you usually don’t need a dynamic block for tags.

✅ Key Takeaways

🧪 Hands-On Lab: Dynamic Blocks Mastery

Let’s build flexible infrastructure using dynamic blocks!

Step 1: Create Project

mkdir terraform-dynamic-blocks-lab
cd terraform-dynamic-blocks-lab

Step 2: Create variables.tf

# variables.tf

variable "aws_region" {
  type    = string
  default = "us-east-1"
}

variable "project_name" {
  type    = string
  default = "dynamic-demo"
}

variable "environment" {
  type    = string
  default = "dev"
}

variable "security_groups" {
  description = "Security group configurations"
  type = map(object({
    description = string
    ingress_rules = list(object({
      description = string
      from_port   = number
      to_port     = number
      protocol    = string
      cidr_blocks = list(string)
    }))
    egress_rules = list(object({
      description = string
      from_port   = number
      to_port     = number
      protocol    = string
      cidr_blocks = list(string)
    }))
  }))

  default = {
    web = {
      description = "Security group for web servers"
      ingress_rules = [
        {
          description = "HTTP from anywhere"
          from_port   = 80
          to_port     = 80
          protocol    = "tcp"
          cidr_blocks = ["0.0.0.0/0"]
        },
        {
          description = "HTTPS from anywhere"
          from_port   = 443
          to_port     = 443
          protocol    = "tcp"
          cidr_blocks = ["0.0.0.0/0"]
        }
      ]
      egress_rules = [
        {
          description = "All traffic"
          from_port   = 0
          to_port     = 0
          protocol    = "-1"
          cidr_blocks = ["0.0.0.0/0"]
        }
      ]
    }

    app = {
      description = "Security group for app servers"
      ingress_rules = [
        {
          description = "App port from VPC"
          from_port   = 8080
          to_port     = 8080
          protocol    = "tcp"
          cidr_blocks = ["10.0.0.0/16"]
        }
      ]
      egress_rules = [
        {
          description = "HTTPS to internet"
          from_port   = 443
          to_port     = 443
          protocol    = "tcp"
          cidr_blocks = ["0.0.0.0/0"]
        },
        {
          description = "Database access"
          from_port   = 5432
          to_port     = 5432
          protocol    = "tcp"
          cidr_blocks = ["10.0.0.0/16"]
        }
      ]
    }

    db = {
      description = "Security group for databases"
      ingress_rules = [
        {
          description = "PostgreSQL from app tier"
          from_port   = 5432
          to_port     = 5432
          protocol    = "tcp"
          cidr_blocks = ["10.0.0.0/16"]
        }
      ]
      egress_rules = []
    }
  }
}

variable "instances" {
  description = "Instance configurations with dynamic volumes"
  type = map(object({
    instance_type = string
    ami_filter    = string
    volumes = list(object({
      device_name = string
      size        = number
      type        = string
    }))
    tags = map(string)
  }))

  default = {
    web = {
      instance_type = "t2.micro"
      ami_filter    = "amzn2-ami-hvm-*"
      volumes = [
        { device_name = "/dev/sdf", size = 30, type = "gp3" }
      ]
      tags = {
        Tier = "Web"
        Role = "Frontend"
      }
    }

    app = {
      instance_type = "t2.small"
      ami_filter    = "amzn2-ami-hvm-*"
      volumes = [
        { device_name = "/dev/sdf", size = 50, type = "gp3" },
        { device_name = "/dev/sdg", size = 100, type = "gp3" }
      ]
      tags = {
        Tier = "App"
        Role = "Backend"
      }
    }
  }
}

variable "s3_buckets" {
  description = "S3 bucket configurations with dynamic lifecycle rules"
  type = map(object({
    versioning = bool
    lifecycle_rules = list(object({
      id         = string
      enabled    = bool
      prefix     = string
      expiration_days = number
    }))
  }))

  default = {
    logs = {
      versioning = true
      lifecycle_rules = [
        {
          id              = "delete-old-logs"
          enabled         = true
          prefix          = "logs/"
          expiration_days = 90
        },
        {
          id              = "delete-temp"
          enabled         = true
          prefix          = "temp/"
          expiration_days = 7
        }
      ]
    }

    data = {
      versioning = true
      lifecycle_rules = [
        {
          id              = "archive-old-data"
          enabled         = true
          prefix          = "archive/"
          expiration_days = 365
        }
      ]
    }
  }
}

Step 3: Create main.tf

# main.tf

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

provider "aws" {
  region = var.aws_region
}

# VPC
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "${var.project_name}-vpc"
  }
}

# Subnets
resource "aws_subnet" "public" {
  count = 2

  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 1}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "${var.project_name}-public-${count.index + 1}"
  }
}

data "aws_availability_zones" "available" {
  state = "available"
}

# Security Groups with Dynamic Blocks
resource "aws_security_group" "groups" {
  for_each = var.security_groups

  name        = "${var.project_name}-${each.key}-sg"
  description = each.value.description
  vpc_id      = aws_vpc.main.id

  # Dynamic ingress rules
  dynamic "ingress" {
    for_each = each.value.ingress_rules
    iterator = rule

    content {
      description = rule.value.description
      from_port   = rule.value.from_port
      to_port     = rule.value.to_port
      protocol    = rule.value.protocol
      cidr_blocks = rule.value.cidr_blocks
    }
  }

  # Dynamic egress rules
  dynamic "egress" {
    for_each = each.value.egress_rules
    iterator = rule

    content {
      description = rule.value.description
      from_port   = rule.value.from_port
      to_port     = rule.value.to_port
      protocol    = rule.value.protocol
      cidr_blocks = rule.value.cidr_blocks
    }
  }

  tags = {
    Name = "${var.project_name}-${each.key}-sg"
    Tier = title(each.key)
  }
}

# AMI Data Source
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

# EC2 Instances with Dynamic EBS Volumes
resource "aws_instance" "servers" {
  for_each = var.instances

  ami           = data.aws_ami.amazon_linux.id
  instance_type = each.value.instance_type
  subnet_id     = aws_subnet.public[0].id

  vpc_security_group_ids = [
    aws_security_group.groups[each.key].id
  ]

  # Dynamic EBS volumes
  dynamic "ebs_block_device" {
    for_each = each.value.volumes
    iterator = volume

    content {
      device_name = volume.value.device_name
      volume_size = volume.value.size
      volume_type = volume.value.type
      encrypted   = true
      tags = {
        Name = "${var.project_name}-${each.key}-volume-${volume.key}"
      }
    }
  }

  tags = merge(
    each.value.tags,
    {
      Name        = "${var.project_name}-${each.key}"
      Environment = var.environment
    }
  )
}

# S3 Buckets with Dynamic Lifecycle Rules
resource "random_id" "bucket" {
  for_each    = var.s3_buckets
  byte_length = 4
}

resource "aws_s3_bucket" "buckets" {
  for_each = var.s3_buckets

  bucket = "${var.project_name}-${each.key}-${random_id.bucket[each.key].hex}"

  tags = {
    Name = "${var.project_name}-${each.key}"
    Type = each.key
  }
}

resource "aws_s3_bucket_versioning" "buckets" {
  for_each = var.s3_buckets

  bucket = aws_s3_bucket.buckets[each.key].id

  versioning_configuration {
    status = each.value.versioning ? "Enabled" : "Disabled"
  }
}

resource "aws_s3_bucket_lifecycle_configuration" "buckets" {
  for_each = var.s3_buckets

  bucket = aws_s3_bucket.buckets[each.key].id

  dynamic "rule" {
    for_each = each.value.lifecycle_rules
    iterator = lifecycle

    content {
      id     = lifecycle.value.id
      status = lifecycle.value.enabled ? "Enabled" : "Disabled"

      filter {
        prefix = lifecycle.value.prefix
      }

      expiration {
        days = lifecycle.value.expiration_days
      }
    }
  }
}

Step 4: Create outputs.tf

# outputs.tf

output "security_groups" {
  description = "Security group details"
  value = {
    for key, sg in aws_security_group.groups :
    key => {
      id               = sg.id
      name             = sg.name
      ingress_count    = length(var.security_groups[key].ingress_rules)
      egress_count     = length(var.security_groups[key].egress_rules)
    }
  }
}

output "instances" {
  description = "Instance details"
  value = {
    for key, instance in aws_instance.servers :
    key => {
      id          = instance.id
      private_ip  = instance.private_ip
      volume_count = length(var.instances[key].volumes)
      tags        = var.instances[key].tags
    }
  }
}

output "s3_buckets" {
  description = "S3 bucket details"
  value = {
    for key, bucket in aws_s3_bucket.buckets :
    key => {
      name                = bucket.id
      versioning          = var.s3_buckets[key].versioning
      lifecycle_rule_count = length(var.s3_buckets[key].lifecycle_rules)
    }
  }
}

output "dynamic_block_summary" {
  description = "Summary of resources created with dynamic blocks"
  value = {
    security_groups = {
      total           = length(aws_security_group.groups)
      total_ingress   = sum([for sg in var.security_groups : length(sg.ingress_rules)])
      total_egress    = sum([for sg in var.security_groups : length(sg.egress_rules)])
    }
    instances = {
      total         = length(aws_instance.servers)
      total_volumes = sum([for inst in var.instances : length(inst.volumes)])
    }
    s3_buckets = {
      total                 = length(aws_s3_bucket.buckets)
      total_lifecycle_rules = sum([for bucket in var.s3_buckets : length(bucket.lifecycle_rules)])
    }
  }
}

Step 5: Deploy and Test

# Initialize
terraform init
# Plan
terraform plan
# Apply
terraform apply -auto-approve
# View outputs
terraform output
# Check security group rules
terraform output security_groups
# Check instance volumes
terraform output instances
# Check S3 lifecycle rules
terraform output s3_buckets
# Clean up
terraform destroy -auto-approve

📝 Best Practices

✅ DO:

1. Use dynamic blocks for repeated nested blocks

2. Keep dynamic blocks simple and readable

3. Document complex dynamic structures

4. Validate input data structure

❌ DON’T:

1. Don’t use dynamic blocks for single blocks

2. Don’t nest too many levels of dynamic blocks

3. Don’t create overly complex conditions in dynamic blocks

4. Don’t use dynamic blocks when static blocks are clearer

📝 Summary

Today you learned:

• ✅ Dynamic block syntax and structure

• ✅ Creating dynamic security group rules

• ✅ Nested dynamic blocks

• ✅ Dynamic blocks with for_each

• ✅ Real-world dynamic block patterns

🚀 Tomorrow’s Preview

Day 17: Introduction to Modules

Tomorrow we’ll:

• Understand Terraform modules

• Learn module structure

• Use public modules

• Pass data between modules

• Organize code with modules

← Day 15: Built-in Functions | Day 17: Introduction to Modules →

Remember: Dynamic blocks eliminate repetition and make resources data-driven!

Terraform functions allow you to manipulate data, perform calculations, handle text, work with networks, and much more — all inside your configuration files.

🎯 Today’s Goals

By the end of this lesson, you’ll be able to:

• Master essential Terraform functions

• Use encoding and cryptographic functions

• Work with date/time and filesystem functions

• Apply functions to real-world scenarios

🔐 Encoding Functions

Terraform’s encoding functions convert data between different formats so you can use it across APIs, files, and configurations.
These are extremely useful when you:

• pass data to AWS user_data or templates

• store structured info in strings

• interact with APIs that expect Base64, JSON, or YAML

🧩 1. base64encode() and base64decode()

📘 Description

These convert text into Base64 format and back again.

• base64encode(string) → encodes plain text

• base64decode(base64_string) → decodes back to original text

Base64 encoding is commonly used in:

• AWS EC2 user_data scripts

• Secrets stored in S3 or external systems

• API payloads

🧠 Example

locals {
  original = "Hello, World"
  encoded  = base64encode(local.original)
  decoded  = base64decode(local.encoded)
}

🧾 Output

encoded = "SGVsbG8sIFdvcmxkCg=="
decoded = "Hello, World"

💡 Real-world use case

Encoding a startup script for an EC2 instance:

resource "aws_instance" "app" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  user_data     = base64encode(file("${path.module}/scripts/startup.sh"))
}

→ AWS expects Base64 input, so this function is perfect.

💾 2. jsonencode() and jsondecode()

📘 Description

Terraform natively uses HCL (HashiCorp Configuration Language),
but many cloud APIs and tools (like AWS Lambda, Datadog, Kubernetes) require JSON input.

• jsonencode(map or list) → converts Terraform data into JSON string

• jsondecode(json_string) → parses JSON back into Terraform data types

🧠 Example

locals {
  data = {
    name    = "Terraform"
    version = 1.6
  }

  json_string = jsonencode(local.data)
  parsed      = jsondecode(local.json_string)
}

🧾 Output

json_string = "{\"name\":\"Terraform\",\"version\":1.6}"
parsed      = { name = "Terraform", version = 1.6 }

💡 Real-world use case

You can store configuration data in S3 or pass it to an API in JSON format:

resource "aws_s3_object" "config" {
  bucket = "my-config-bucket"
  key    = "app_config.json"
  content = jsonencode({
    env     = "production"
    version = "1.0.0"
    enabled = true
  })
}

This automatically converts the Terraform map into a JSON file inside S3.

🧱 3. yamlencode() and yamldecode()

📘 Description

YAML is widely used for configuration files (like Kubernetes manifests or Ansible playbooks).
Terraform can convert its internal data structures to YAML and back.

• yamlencode() → Converts Terraform data → YAML string

• yamldecode() → Parses YAML string → Terraform data

🧠 Example

locals {
  data = {
    app = "web"
    port = 8080
  }

  yaml_string = yamlencode(local.data)
  yaml_parsed = yamldecode(local.yaml_string)
}

🧾 Output

yaml_string:
app: web
port: 8080
yaml_parsed: { app = "web", port = 8080 }

💡 Real-world use case

Generate a Kubernetes deployment file dynamically:

resource "local_file" "k8s_manifest" {
  content = yamlencode({
    apiVersion = "v1"
    kind       = "Pod"
    metadata = { name = "nginx" }
    spec = {
      containers = [{
        name  = "nginx"
        image = "nginx:latest"
      }]
    }
  })
  filename = "${path.module}/nginx.yaml"
}

📋 4. csvdecode()

📘 Description

Parses a CSV-formatted string into a list of maps.
This is helpful when reading structured data from CSV files like user lists, IPs, or configuration tables.

🧠 Example

locals {
  csv_data = csvdecode("name,age\nAlice,30\nBob,25")
}

🧾 Output

[
  { name = "Alice", age = "30" },
  { name = "Bob",   age = "25" }
]

💡 Real-world use case

Imagine you have a CSV file of instance names and sizes:

name,type
web,t2.micro
db,t3.micro

You can load and use it:

locals {
  instances = csvdecode(file("${path.module}/instances.csv"))
}

resource "aws_instance" "csv_based" {
  for_each = { for row in local.instances : row.name => row }

  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = each.value.type
  tags = {
    Name = each.value.name
  }
}

✅ Automatically creates EC2 instances from your CSV!

🔑 Cryptographic Functions

These functions deal with data integrity, security, and uniqueness.
They are especially important when:

• creating hashed passwords

• verifying file content integrity

• generating stable resource names

🔹 1. md5()

📘 Description

Generates a 128-bit MD5 hash of a string (commonly used for file integrity).

md5("Terraform") # => "e5bdf6e80e63f03d7a26dd9a88a234f0"

💡 Example use:

locals {
  checksum = md5(file("${path.module}/app.zip"))
}

→ Useful for detecting when a file changes.

🔹 2. sha1(), sha256(), sha512()

📘 Description

These are stronger cryptographic hash functions —
they generate longer, more secure digests than MD5.

🧠 Example

locals {
  data = "Hello, Terraform!"
  sha1_value   = sha1(local.data)
  sha256_value = sha256(local.data)
  sha512_value = sha512(local.data)
}

🔹 3. bcrypt()

📘 Description

Generates a secure hash for passwords using the bcrypt algorithm.
Unlike SHA, bcrypt hashes are salted — even if the same password is hashed twice, the result is different.

🧠 Example

locals {
  password = "supersecret"
  bcrypt_hash = bcrypt(local.password)
}

Output → $2a$10$Jd2P8y... (random each time)

💡 Common in user provisioning:

resource "aws_iam_user_login_profile" "user" {
  user    = "admin"
  pgp_key = "keybase:exampleuser"
  password_reset_required = false
  password = bcrypt("MySecurePassword123")
}

🧠 Summary

📅 Date and Time Functions

These are used to manage timestamps — such as for naming resources with deployment time, scheduling, auditing, or versioning.

🕒 1. timestamp()

Purpose:
Returns the current UTC timestamp in ISO 8601 format (e.g., "2025-10-22T08:00:00Z").

locals {
  now = timestamp()
}

Example Output:

"2025-10-22T08:00:00Z"

✅ Use Cases:

• Tagging resources with deployment time.

• Creating unique names for artifacts.

• Logging when a deployment occurred.

tags = {
  CreatedAt = timestamp()
}

🗓️ 2. formatdate(format, timestamp)

Purpose:
Formats a timestamp into a human-readable string using custom format tokens.

locals {
  formatted1 = formatdate("DD MMM YYYY hh:mm:ss", timestamp())
  formatted2 = formatdate("YYYY-MM-DD", timestamp())
}

Output:

"22 Oct 2025 14:30:00"
"2025-10-22"

✅ Use Cases:

• Version tagging (e.g., v2025-10-22)

• Logging or backup filenames

• Human-readable labels in outputs

output "build_version" {
  value = "v${formatdate("YYYYMMDD-hhmm", timestamp())}"
}

⏩ 3. timeadd(timestamp, duration)

Purpose:
Adds a duration to a timestamp (supports seconds, minutes, hours, days, weeks).

locals {
  now        = timestamp()
  tomorrow   = timeadd(local.now, "24h")
  next_week  = timeadd(local.now, "168h") # 7 days
}

✅ Use Cases:

• Setting expiry times (e.g., certificate expiry, temporary access)

• Scheduling delayed actions

📁 Filesystem Functions

These allow Terraform to interact with files on your local filesystem — reading, checking, finding, or rendering templates.

📄 1. file(path)

Purpose:
Reads the contents of a file as a string.

locals {
  script_content = file("${path.module}/scripts/init.sh")
}

✅ Use Cases:

• Load shell scripts, config files, or policies to inject into resources.

• Pass user_data to EC2 or container startup scripts.

✅ 2. fileexists(path)

Purpose:
Checks whether a file exists and returns true or false.

locals {
  has_config = fileexists("${path.module}/config.yaml")
}

✅ Use Cases:

• Conditional logic to include optional files.

• Avoid Terraform errors when optional inputs are missing.

📂 3. fileset(directory, pattern)

Purpose:
Returns a list of filenames in a directory matching a pattern (e.g., all .sh files).

locals {
  all_scripts = fileset(path.module, "scripts/*.sh")
}

✅ Use Cases:

• Automatically include all scripts or templates in a directory.

• Create multiple resources (e.g., upload all scripts to S3).

🧩 4. templatefile(path, vars)

Purpose:
Reads a file and replaces placeholders with variable values.
Placeholders use the ${var_name} syntax.

locals {
  user_data = templatefile("${path.module}/templates/user-data.sh", {
    hostname = "web-server"
    port     = 8080
  })
}

If user-data.sh contains:

#!/bin/bash
echo "Starting ${hostname} on port ${port}"

✅ Output:

#!/bin/bash
echo "Starting web-server on port 8080"

✅ Use Cases:

• Dynamically generate scripts, configuration files, or manifest templates.

🧭 5. Path Utility Functions

✅ Use Cases:

• Managing file paths in reusable modules.

• Normalizing paths across systems.

🌐 IP Network Functions

These functions help manipulate and calculate IP network addresses — crucial for VPC, subnets, and CIDR management in AWS, Azure, or GCP.

🌍 1. cidrhost(cidr, hostnum)

Purpose:
Returns a specific host IP address from a given subnet.

locals {
  vpc_cidr = "10.0.0.0/16"
  first_ip = cidrhost(local.vpc_cidr, 0)
  second_ip = cidrhost(local.vpc_cidr, 1)
}

Output:

"10.0.0.0"
"10.0.0.1"

✅ Use Cases:

• Assign static IPs in subnets.

• Generate predictable host IPs.

🧱 2. cidrnetmask(cidr)

Purpose:
Returns the netmask of a CIDR block.

cidrnetmask("10.0.0.0/16") # => "255.255.0.0"

✅ Use Case: Documentation or tagging (helps identify subnet size easily).

🧩 3. cidrsubnet(cidr, newbits, netnum)

Purpose:
Subdivides a larger CIDR into smaller subnet blocks.

locals {
  subnet1 = cidrsubnet("10.0.0.0/16", 8, 0) # 10.0.0.0/24
  subnet2 = cidrsubnet("10.0.0.0/16", 8, 1) # 10.0.1.0/24
}

✅ Use Cases:

• Create multiple subnets dynamically for different environments or AZs.

🧮 4. cidrsubnets(cidr, newbits...)

Purpose:
Generates multiple subnets at once from one parent network.

locals {
  subnets = cidrsubnets("10.0.0.0/16", 8, 8, 8)
}

Output:

["10.0.0.0/24", "10.0.1.0/24", "10.0.2.0/24"]

✅ Use Cases:

• Automatically allocate subnets for each application layer.

🧪 Hands-On Lab

📁project structure

terraform-day15/
├── main.tf
├── variables.tf
├── locals.tf
├── outputs.tf
├── scripts/
│   └── init.sh
├── templates/
│   └── user-data.sh
└── config.yaml

This lab uses Date/Time, Filesystem, IP Network, and Type Conversion functions all together.

🧠 Scenario

We’ll simulate deploying a web server into a generated subnet inside a VPC.
Terraform will:

• Calculate subnets using IP functions. 🧮

• Generate timestamps and version tags using Date/Time functions ⏱️

• Read files and templates using Filesystem functions 📁

• Use Type Conversion functions for safe, flexible data handling 🔄

1️⃣ variables.tf

variable "project_name" {
  description = "Project name for tagging and resource naming"
  type        = string
  default     = "terraform-lab"
}

variable "region" {
  description = "AWS region to deploy to"
  type        = string
  default     = "us-east-1"
}

variable "vpc_cidr" {
  description = "CIDR block for the VPC"
  type        = string
  default     = "10.0.0.0/16"
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t2.micro"
}

variable "enable_public_access" {
  description = "Allow public access to the instance?"
  type        = string
  default     = "true" # as string for demonstration of tobool()
}

2️⃣ locals.tf

locals {
  # -------------------------
  # 📅 Date & Time Functions
  # -------------------------
  current_time   = timestamp()
  formatted_time = formatdate("YYYY-MM-DD hh:mm:ss", local.current_time)
  build_version  = formatdate("YYYYMMDD-hhmm", local.current_time)
  expire_time    = timeadd(local.current_time, "168h") # +7 days

  # -------------------------
  # 🌐 IP Network Functions
  # -------------------------
  vpc_cidr  = var.vpc_cidr
  subnet1   = cidrsubnet(local.vpc_cidr, 8, 0) # "10.0.0.0/24"
  subnet2   = cidrsubnet(local.vpc_cidr, 8, 1) # "10.0.1.0/24"
  first_ip  = cidrhost(local.subnet1, 10)
  netmask   = cidrnetmask(local.vpc_cidr)

  # -------------------------
  # 📁 Filesystem Functions
  # -------------------------
  script_content = file("${path.module}/scripts/init.sh")
  has_config     = fileexists("${path.module}/config.yaml")
  all_scripts    = fileset(path.module, "scripts/*.sh")

  # Render a user-data template with variables
  user_data = templatefile("${path.module}/templates/user-data.sh", {
    hostname = "${var.project_name}-server"
    port     = 8080
  })

  # -------------------------
  # 🔄 Type Conversion Functions
  # -------------------------
  is_public   = tobool(var.enable_public_access)
  number_test = try(tonumber("123"), 0)
  is_number   = can(tonumber("abc")) # false

  # Convert set → list → string for display
  tags_set  = toset(["app", "terraform", "infra", "app"])
  tags_list = tolist(local.tags_set)
  tags_str  = tostring(join(",", local.tags_list))
}

3️⃣ main.tf

(This simulates deployment logic — no real AWS resources needed, you can run this locally and observe outputs.)

terraform {
  required_version = ">= 1.6.0"
}

provider "aws" {
  region = var.region
}

# Example local resource to simulate usage of all functions
resource "null_resource" "example" {
  triggers = {
    build_version = local.build_version
    subnet        = local.subnet1
    netmask       = local.netmask
    has_config    = tostring(local.has_config)
    tags          = local.tags_str
  }

  provisioner "local-exec" {
    command = "echo '🚀 Deploying ${var.project_name} version ${local.build_version}'"
  }
}

# Save rendered user-data to file for demonstration
resource "local_file" "rendered_user_data" {
  content  = local.user_data
  filename = "${path.module}/rendered-user-data.sh"
}

4️⃣ outputs.tf

output "📅_date_time" {
  value = {
    now          = local.current_time
    formatted    = local.formatted_time
    version_tag  = local.build_version
    expires_at   = local.expire_time
  }
}

output "🌐_network_details" {
  value = {
    vpc_cidr  = local.vpc_cidr
    subnet1   = local.subnet1
    subnet2   = local.subnet2
    first_ip  = local.first_ip
    netmask   = local.netmask
  }
}

output "📁_filesystem_info" {
  value = {
    config_exists = local.has_config
    scripts_found = local.all_scripts
    user_data     = local.user_data
  }
}

output "🔄_type_conversions" {
  value = {
    is_public   = local.is_public
    number_test = local.number_test
    is_number   = local.is_number
    tags        = local.tags_str
  }
}

5️⃣ scripts/init.sh

#!/bin/bash
echo "Initializing system..."
echo "Date: $(date)"

6️⃣ templates/user-data.sh

#!/bin/bash
echo "🚀 Launching ${hostname}"
echo "Listening on port ${port}"

7️⃣ config.yaml

project: terraform-lab
environment: dev
owner: example@example.com

Run

# Initialize
terraform init
# Use console to test functions
terraform console
# Try these:
> cidrsubnet("10.0.0.0/16", 8, 0)
"10.0.0.0/24"
> cidrhost("10.0.1.0/24", 5)
"10.0.1.5"
> format("%s-%03d", "web", 5)
"web-005"
> timestamp()
"2025-10-22T09:38:22Z"
> formatdate("DD-MM-YYYY", timestamp())
"22-10-2025"
> md5("terraform")
"1b1ed905d54c18e3dd8828986c14be17"
> range(5)
tolist([
  0,
  1,
  2,
  3,
  4,
])
> exit
# Apply
terraform apply -auto-approve
# View outputs
terraform output

#Output look like this 
null_resource.example: Creating...
local_file.rendered_user_data: Creating...
null_resource.example: Provisioning with 'local-exec'...
local_file.rendered_user_data: Creation complete after 0s [id=2b67ae43a0bde8eaf87b28a86c7c9b9bf94cd3d5]
null_resource.example (local-exec): Executing: ["/bin/sh" "-c" "echo '🚀 Deploying terraform-lab version 20251022-0940'"]
null_resource.example (local-exec): 🚀 Deploying terraform-lab version 20251022-0940
null_resource.example: Creation complete after 0s [id=6127148458059718850]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Outputs:
date_time = {
  "expires_at" = "2025-10-29T09:40:25Z"
  "formatted" = "2025-10-22 09:40:25"
  "now" = "2025-10-22T09:40:25Z"
  "version_tag" = "20251022-0940"
}
filesystem_info = {
  "config_exists" = true
  "scripts_found" = toset([
    "scripts/init.sh",
  ])
  "user_data" = <<-EOT
  #!/bin/bash
  echo "🚀 Launching terraform-lab-server"
  echo "Listening on port 8080"
  EOT
}
network_details = {
  "first_ip" = "10.0.0.10"
  "netmask" = "255.255.0.0"
  "subnet1" = "10.0.0.0/24"
  "subnet2" = "10.0.1.0/24"
  "vpc_cidr" = "10.0.0.0/16"
}
type_conversions = {
  "is_number" = false
  "is_public" = true
  "number_test" = 123
  "tags" = "app,infra,terraform"
}

# Clean up
terraform destroy -auto-approve

📝 Summary

Today you learned:

• ✅ Encoding functions (base64, json, yaml)

• ✅ Crypto functions (md5, sha256, bcrypt)

• ✅ Date/time functions (timestamp, formatdate)

• ✅ Network functions (cidrsubnet, cidrhost)

• ✅ Filesystem functions (file, templatefile)

🚀 Tomorrow’s Preview

Day 16: Dynamic Blocks for Flexible Resources

Tomorrow we’ll:

• Master dynamic blocks

• Create flexible security groups

• Build dynamic ingress/egress rules

• Use for_each in dynamic blocks

• Handle complex nested blocks

← Day 14: Conditionals & Logic | Day 16: Dynamic Blocks →

Remember: Functions are powerful tools for data transformation and manipulation!

Terraform functions allow you to manipulate data, perform calculations, handle text, work with networks, and much more — all inside your configuration files.

🎯 Today’s Goals

By the end of this lesson, you’ll be able to:

• ✅ Master essential Terraform functions

• ✅ Understand string functions

• ✅ Understand numeric functions

• ✅ Apply them in real-world Terraform projects

🔢 Numeric Functions — Explained for Beginners

Terraform numeric functions help you perform mathematical calculations directly in your configuration files.
You can use them to calculate:

• How many instances or subnets to create

• How large a storage volume should be

• How to round or constrain numeric inputs

Let’s go through each function carefully. 👇

🧮 Mathematical Operations

Here’s a breakdown of each numeric function from the example:

🧩 1. abs(number) — Absolute Value

The absolute value means “ignore the negative sign.”

locals {
  absolute = abs(-15)
}

📘 Explanation:
If the number is negative, abs() turn it into a positive number.
If it’s already positive, it stays the same.

Example use case:
If you’re calculating a difference between two values (like used vs. available storage), you can use it abs() to make sure the result is always positive.

locals {
  storage_difference = abs(50 - 100)  # => 50
}

🧩 2. ceil(number) — Round Up

Always rounds a decimal number up to the nearest whole number.

locals {
  ceiling = ceil(5.1)  # => 6
}

📘 Example:

• ceil(3.1) → 4

• ceil(7.9) → 8

💡 Use case:
You can use this when dividing resources and you want to avoid losing part of a unit.
For example, if each subnet can handle 2 servers, and you have 5 servers → ceil(5 / 2) = 3 subnets needed.

🧩 3. floor(number) — Round Down

Always rounds a decimal number down to the nearest whole number.

locals {
  floored = floor(5.9)  # => 5
}

📘 Example:

• floor(4.9) → 4

• floor(6.3) → 6

💡 Use case:
If you need to calculate full “groups” of resources and you can’t have fractions (like 5.9 groups → only 5 real groups).

🧩 4. max(a, b, c, …) — Find Maximum Value

Returns the largest number from a list of numbers.

locals {
  maximum = max(5, 12, 9)  # => 12
}

📘 Example:

• max(3, 10, 7) → 10

• max(0, -5, 8) → 8

💡 Use case:
You can use it max() to make sure something never goes below a minimum—for example, the number of servers should be at least 1.

🧩 5. min(a, b, c, …) — Find Minimum Value

Returns the smallest number.

locals {
  minimum = min(5, 12, 9)  # => 5
}

💡 Use case:
When you want to limit a maximum value—for example, if a user requests 10 subnets but you only want to allow up to 6:

locals {
  subnet_count = min(var.requested_subnets, 6)
}

🧩 6. pow(base, exponent) — Power Function

Raises a number to a power.
(Mathematically: base^exponent)

locals {
  power = pow(2, 3)  # => 8  (2×2×2)
}

📘 Example:

• pow(3, 2) → 9

• pow(10, 3) → 1000

💡 Use case:
Useful when you need exponential scaling—e.g., storage or CPU size that doubles with every increase in instance count.

🧩 7. log(base, number) — Logarithm

Calculates how many times you multiply the base to get the number.

locals {
  logarithm = log(10, 100)  # => 2
}

📘 Explanation:
10² = 100 → That’s why log(10, 100) = 2.
It’s like saying, “How many times must I multiply 10 to get 100?”

💡 Use case:
You might use it log() when scaling values logarithmically—for instance, computing tiers or power-of-two sizes.

🧩 8. signum(number) — Get the Sign

Returns:

• 1 if number is positive

• -1 if negative

• 0 if zero

locals {
  sign = signum(-15)  # => -1
}

💡 Use case:
When you want to check the direction or “trend” of a value.
Example:

locals {
  delta = var.new_value - var.old_value
  direction = signum(local.delta)
}
# If new_value > old_value → +1 (increase)
# If new_value < old_value → -1 (decrease)
# If same → 0

🧠 Summary Table

🧰 Practical Terraform Example

Now, let’s look at the real Terraform snippet and explain each part 👇

variable "instance_count" {
  type = number
}

locals {
  # Ensure minimum of 1 instance
  final_count = max(1, var.instance_count)

  # Calculate storage based on instance count
  total_storage_gb = pow(2, ceil(log(var.instance_count, 2)))

  # Round up subnet count
  subnet_count = ceil(var.instance_count / 2.0)
}

💡 Step-by-step Explanation

1️⃣ final_count = max(1, var.instance_count)

Ensures that even if someone sets instance_count = 0, Terraform will still create at least 1 instance.

2️⃣ total_storage_gb = pow(2, ceil(log(var.instance_count, 2)))

This line automatically scales storage capacity using a power of two rule.

Let’s break it down:

• log(var.instance_count, 2) → finds the power needed to reach instance_count with base 2

• ceil() → rounds that up

• pow(2, …) → calculates 2 raised to that rounded number

🧠 Meaning:
If you scale up instances, your total storage scales automatically in powers of two — a common pattern in cloud infrastructure design.

3️⃣ subnet_count = ceil(var.instance_count / 2.0)

This means each subnet will hold 2 instances, and Terraform will round up if there’s an extra one.

💡 This ensures no instance is left without a subnet.

🧪 Try It Yourself in Terraform Console

You can test these functions directly in Terraform:

terraform console
> abs(-20)
> ceil(4.3)
> floor(9.8)
> max(1, 9, 5)
> pow(2, 4)
> log(10, 1000)
> signum(-99)
> exit

🔤 Terraform String Functions

Terraform string functions help you manipulate, search, and format text.

You’ll use these functions a lot to:

• Build clean resource names

• Format instance IDs, tags, or DNS names

• Extract or modify text values dynamically

🎯 What is a String?

A string is simply text inside quotes, e.g. "Terraform", "hello world" ", " "web-server-001"

🧰 1. String Manipulation Functions

These functions change the appearance of a string — like converting to lowercase, trimming spaces, or removing parts of it.

locals {
  name = "Terraform"

  lowercase   = lower(name)
  uppercase   = upper(name)
  titlecase   = title("hello world")
  trimmed     = trim("  hello  ", " ")
  trimprefix  = trimprefix("mr-bean", "mr-")
  trimsuffix  = trimsuffix("hello.txt", ".txt")
  cleaned     = trimspace("  hello world  ")
}

🔍 Let’s explain each one:

💡 Real-world Example

Imagine your project name input is messy:

variable "project_name" {
  default = "  MyAPP  "
}

You can clean and format it for consistent naming:

locals {
  clean_name = lower(trimspace(var.project_name))
}
# "myapp"

Now your resource names will be uniform and lowercase.

🔍 2. String Searching and Replacement

These functions help you extract, replace, and format parts of text.

locals {
  text = "Hello, World!"

  substring = substr(text, 0, 5)
  replaced  = replace(text, "World", "Terraform")
  extracted = regex("([A-Z][a-z]+)", text)
  all_words = regexall("[A-Z][a-z]+", text)
  formatted = format("The answer is %d", 42)
  formatted2 = format("%s-%s-%03d", "web", "server", 5)
  starts     = startswith(text, "Hello")
  ends       = endswith(text, "!")
}

Let’s look at each in detail 👇

🧩 Example Breakdown:

locals {
  text = "Hello, World!"
  substring = substr(text, 0, 5)  # "Hello"
  replaced  = replace(text, "World", "Terraform")  # "Hello, Terraform!"
}

🧠 Explanation:

• substr(text, 0, 5) → starts from position 0 (the first letter), takes 5 letters.

• replace() → looks for "World" and swaps it with "Terraform".

💡 Real-world Use Case

You can use string formatting for naming multiple instances:

locals {
  environment = "dev"
  server_name = format("%s-%s-%03d", "myapp", local.environment, 1)
}
# Output: "myapp-dev-001"

This makes your resource names look clean and consistent like:

myapp-dev-001  
myapp-dev-002  
myapp-dev-003

🧩 3. String Splitting and Joining

You often need to break apart or combine strings in Terraform — for example, splitting an email or joining tags into a single line.

locals {
  words    = split(",", "apple,banana,orange")
  csv      = join(",", ["apple", "banana", "orange"])
  chomped  = chomp("hello\n")
  indented = indent(2, "hello\nworld")
}

Explanation:

💡 Real-world Example: Extracting Email Domain

locals {
  email  = "admin@example.com"
  domain = split("@", local.email)[1]
}
# Output: "admin", "example.com"

🧠 Explanation:
split("@", local.email) → splits into ["admin", "example.com"]
[1] → gets the second element (index starts at 0)

🧱 4. Practical String Example in Terraform

Let’s put all the string functions together into a real Terraform example 👇

variable "environment" {
  default = "dev"
}

variable "project_name" {
  default = "MyApp"
}

locals {
  # 1️⃣ Make clean prefix (lowercase, environment)
  resource_prefix = "${lower(var.project_name)}-${var.environment}"
  # => "myapp-dev"

  # 2️⃣ Format instance names (like server IDs)
  instance_names = [
    for i in range(3) :
    format("%s-web-%03d", local.resource_prefix, i + 1)
  ]
  # => ["myapp-dev-web-001", "myapp-dev-web-002", "myapp-dev-web-003"]

  # 3️⃣ Extract domain name from admin email
  admin_email = "admin@example.com"
  domain      = split("@", local.admin_email)[1]
  # => "example.com"

  # 4️⃣ Build DNS name dynamically
  dns_name = "${local.resource_prefix}.${local.domain}"
  # => "myapp-dev.example.com"
}

🧠 Explanation:

🧪 Try it in Terraform Console

You can test any string function easily:

terraform console
> lower("Terraform")
> upper("cloud")
> split(",", "a,b,c")
> join("-", ["apple", "banana"])
> format("%s-%03d", "web", 7)
> replace("dev", "d", "prod")
> exit

🧭 Summary Table

🧪 Hands-On Lab

📁 Project Structure

terraform-numeric-string-lab/
├── main.tf
├── variables.tf
├── outputs.tf
└── locals.tf

🧰 Step 1: variables.tf

This file defines user inputs.
We’ll use variables for project naming, instance count, and region.

# variables.tf

variable "aws_region" {
  description = "AWS region where EC2 instances will be created"
  type        = string
  default     = "us-east-1"
}

variable "project_name" {
  description = "Name of your project"
  type        = string
  default     = "NumericStringDemo"
}

variable "environment" {
  description = "Deployment environment (dev, stage, prod)"
  type        = string
  default     = "dev"
}

variable "instance_count" {
  description = "Number of instances you want to create"
  type        = number
  default     = 3
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t2.micro"
}

variable "base_storage" {
  description = "Base storage size (GB) for each instance"
  type        = number
  default     = 10
}

🧮 Step 2: locals.tf

Here’s where we use numeric and string functions to calculate and generate smart values.

# locals.tf

locals {
  # ✅ String Functions

  # Create a consistent lowercase prefix for all resources
  resource_prefix = "${lower(var.project_name)}-${lower(var.environment)}"
  # Example: "numericstringdemo-dev"

  # Format EC2 instance names dynamically
  instance_names = [
    for i in range(var.instance_count) :
    format("%s-web-%03d", local.resource_prefix, i + 1)
  ]
  # ["numericstringdemo-dev-web-001", "numericstringdemo-dev-web-002", ...]

  # ✅ Numeric Functions

  # Ensure we have at least 1 instance
  final_instance_count = max(1, var.instance_count)

  # Calculate total storage: power of 2 * base storage
  # e.g., if count=3 => ceil(log(3,2))=2 => pow(2,2)=4 => 4 * 10 = 40GB total
  total_storage_gb = pow(2, ceil(log(local.final_instance_count, 2))) * var.base_storage

  # Divide instances into subnets (2 per subnet, rounded up)
  subnet_count = ceil(local.final_instance_count / 2.0)

  # String join example: create a simple description
  description = join(" ", [
    "Project:", var.project_name,
    "Environment:", var.environment,
    "Instances:", tostring(local.final_instance_count)
  ])
}

☁️ Step 3: main.tf

Now, we’ll use those locals to dynamically create EC2 instances with smart naming and scaling logic.

# main.tf

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

provider "aws" {
  region = var.aws_region
}

# ✅ Data source to fetch latest Amazon Linux AMI
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

# ✅ Create EC2 instances using for_each
resource "aws_instance" "web" {
  for_each = toset(local.instance_names)

  ami           = data.aws_ami.amazon_linux.id
  instance_type = var.instance_type

  tags = {
    Name        = each.key
    Environment = var.environment
    Description = local.description
  }
}

🧠 Explanation:

• for_each = toset(local.instance_names) — creates one instance per formatted name

• each.key — gives each instance name dynamically

• tags use string functions to create readable tags

• Numeric functions were already used in locals.tf to decide count, storage, and subnet count

📤 Step 4: outputs.tf

We’ll show computed results and demonstrate how our functions affected the setup.

# outputs.tf

output "instance_names" {
  description = "List of generated EC2 instance names"
  value       = local.instance_names
}

output "total_storage_gb" {
  description = "Total calculated storage based on instance count"
  value       = local.total_storage_gb
}

output "subnet_count" {
  description = "Calculated subnet count (2 instances per subnet)"
  value       = local.subnet_count
}

output "description" {
  description = "Auto-generated description using join and tostring"
  value       = local.description
}

🧩 Step 5: Run and Test

✅ Initialize Terraform

terraform init

✅ Validate your code

terraform validate

✅ Preview your plan

terraform plan

You’ll see something like

Plan: 3 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + instance_names = [
      "numericstringdemo-dev-web-001",
      "numericstringdemo-dev-web-002",
      "numericstringdemo-dev-web-003",
    ]
  + total_storage_gb = 40
  + subnet_count = 2
  + description = "Project: NumericStringDemo Environment: dev Instances: 3"

✅ Deploy your lab

terraform apply

✅ Check outputs

terraform output

Expected output:

instance_names = [
  "numericstringdemo-dev-web-001",
  "numericstringdemo-dev-web-002",
  "numericstringdemo-dev-web-003",
]
total_storage_gb = 40
subnet_count = 2
description = "Project: NumericStringDemo Environment: dev Instances: 3"

✅ Clean up

terraform destroy -auto-approve

🧠 What You Learned

🚀 Tomorrow’s Preview

Day 16: Dynamic Blocks for Flexible Resources

Tomorrow we’ll:

• Collection functions (merge, lookup, flatten)

• Encoding functions (base64, json, yaml)

• Crypto functions (md5, sha256, bcrypt)

• Date/time functions (timestamp, formatdate)

• Network functions (cidrsubnet, cidrhost)

• Filesystem functions (file, templatefile)

← Day 13: Conditionals & Logic | Day 15: Dynamic Blocks →

Remember: Functions are powerful tools for data transformation and manipulation!

🎯 Today’s Goals

• Understand count and for_each meta-arguments

• Learn when to use count vs for_each

• Master resource indexing and references

• Handle dynamic resource creation

• Avoid common pitfalls

🔢 The Count Meta-Argument

Count creates multiple instances of a resource based on a number.

Basic Count Syntax

resource "aws_instance" "web" {
  count = 3

  ami           = "ami-12345"
  instance_type = "t2.micro"

  tags = {
    Name = "web-server-${count.index}"
  }
}

# Creates: web[0], web[1], web[2]

count.index

count.index is the current iteration number (0-based):

resource "aws_subnet" "public" {
  count = 3

  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 1}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name  = "public-subnet-${count.index + 1}"
    Index = count.index
  }
}

# Creates:
# - public[0]: 10.0.1.0/24 in us-east-1a
# - public[1]: 10.0.2.0/24 in us-east-1b
# - public[2]: 10.0.3.0/24 in us-east-1c

Dynamic Count with Variables

variable "instance_count" {
  type    = number
  default = 3
}

resource "aws_instance" "app" {
  count = var.instance_count

  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t2.micro"
}

Conditional Count (Create or Not)

variable "create_instance" {
  type    = bool
  default = true
}

resource "aws_instance" "optional" {
  count = var.create_instance ? 1 : 0

  ami           = "ami-12345"
  instance_type = "t2.micro"
}

# If true: creates 1 instance
# If false: creates 0 instances (none)

Count with length()

variable "availability_zones" {
  type = list(string)
  default = ["us-east-1a", "us-east-1b", "us-east-1c"]
}

resource "aws_subnet" "public" {
  count = length(var.availability_zones)

  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index}.0/24"
  availability_zone = var.availability_zones[count.index]
}

Referencing Count Resources

# Reference all instances
output "all_instance_ids" {
  value = aws_instance.web[*].id
}

# Reference specific instance
output "first_instance_id" {
  value = aws_instance.web[0].id
}

# Use in another resource
resource "aws_eip" "web" {
  count    = length(aws_instance.web)
  instance = aws_instance.web[count.index].id
}

🔁 The For_Each Meta-Argument

For_each creates multiple resources based on a map or set.

Basic For_Each Syntax

resource "aws_instance" "servers" {
  for_each = toset(["web", "api", "worker"])

  ami           = "ami-12345"
  instance_type = "t2.micro"

  tags = {
    Name = "server-${each.key}"
  }
}

# Creates: servers["web"], servers["api"], servers["worker"]

each.key and each.value

# With set: each.key == each.value
for_each = toset(["web", "api"])
# each.key = "web", each.value = "web"

# With map: each.key = key, each.value = value
for_each = {
  web = "t2.micro"
  api = "t2.small"
}
# each.key = "web", each.value = "t2.micro"

For_Each with Maps

variable "instances" {
  type = map(object({
    instance_type = string
    ami           = string
  }))

  default = {
    web = {
      instance_type = "t2.micro"
      ami           = "ami-12345"
    }
    api = {
      instance_type = "t2.small"
      ami           = "ami-67890"
    }
    worker = {
      instance_type = "t2.micro"
      ami           = "ami-12345"
    }
  }
}

resource "aws_instance" "servers" {
  for_each = var.instances

  ami           = each.value.ami
  instance_type = each.value.instance_type

  tags = {
    Name = each.key
    Type = each.value.instance_type
  }
}

For_Each with Sets

variable "subnet_names" {
  type    = set(string)
  default = ["public-1", "public-2", "private-1"]
}

resource "aws_subnet" "subnets" {
  for_each = var.subnet_names

  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.${index(var.subnet_names, each.key)}.0/24"

  tags = {
    Name = each.key
  }
}

Referencing For_Each Resources

# Reference all instances
output "all_instance_ids" {
  value = values(aws_instance.servers)[*].id
}

# Reference specific instance
output "web_instance_id" {
  value = aws_instance.servers["web"].id
}

# Create map of IDs
output "instance_id_map" {
  value = {
    for key, instance in aws_instance.servers :
    key => instance.id
  }
}

# Use in another resource
resource "aws_eip" "server_ips" {
  for_each = aws_instance.servers

  instance = each.value.id

  tags = {
    Name = "eip-${each.key}"
  }
}

⚖️ Count vs For_Each: When to Use Which

Use Count When:

✅ Creating a specific number of identical resources

resource "aws_instance" "web" {
  count = 5  # Create exactly 5 instances
}

✅ Conditional resource creation (0 or 1)

count = var.create_bastion ? 1 : 0

✅ Resources are truly identical and order doesn’t matter

resource "aws_subnet" "public" {
  count = 3
}

Use For_Each When:

✅ Each resource has unique configuration

for_each = {
  web = { type = "t2.micro", ami = "ami-123" }
  api = { type = "t2.small", ami = "ami-456" }
}

✅ Resources are identified by name/key

for_each = toset(["production", "staging", "development"])

✅ You need to add/remove specific items

# Removing "staging" won't affect "production"
for_each = toset(["production", "development"])

The Key Difference

# COUNT: Resources identified by index
aws_instance.web[0]
aws_instance.web[1]
aws_instance.web[2]

# If you remove the middle item, indices shift!
# web[1] becomes what was web[2]

# FOR_EACH: Resources identified by key
aws_instance.servers["web"]
aws_instance.servers["api"]
aws_instance.servers["worker"]

# Removing "api" doesn't affect "web" or "worker"

⚙️ 1️⃣ Using count

Example:

resource "aws_instance" "web" {
  count = 3

  ami           = "ami-123456"
  instance_type = "t2.micro"
}

✅ What Terraform does:

• Creates 3 resources, indexed by number (starting from 0):

    aws_instance.web[0]
    aws_instance.web[1]
    aws_instance.web[2]
  

🧩 Access Example:

You can reference a specific one using its index:

aws_instance.web[1].id

⚠️ The Problem:

If you remove or reorder items (for example, if you reduce count to 2 or skip the middle one),
Terraform reindexes the remaining ones.

So if you had:

aws_instance.web[0]  -> stays
aws_instance.web[1]  -> deleted
aws_instance.web[2]  -> becomes web[1]

Result: Terraform may destroy and recreate resources unexpectedly because the index numbers shift.

💡 Best for:

Simple, fixed-size lists—e.g., creating N identical servers.

⚙️ 2️⃣ Using for_each

Example:

resource "aws_instance" "servers" {
  for_each = {
    web    = "t2.micro"
    api    = "t2.small"
    worker = "t3.micro"
  }

  ami           = "ami-123456"
  instance_type = each.value
  tags = {
    Name = each.key
  }
}

✅ What Terraform does:

Creates resources identified by key names, not numbers:

aws_instance.servers["web"]
aws_instance.servers["api"]
aws_instance.servers["worker"]

Each one is uniquely named and stable — based on its key.

🧩 Access Example:

You can reference a specific one by its key:

aws_instance.servers["web"].id

💪 The Advantage:

If you remove "api" from the map, Terraform only deletes that one:

aws_instance.servers["api"]  -> destroyed

✅ "web" and "worker" stay exactly the same — no index shifting, no recreation.

🧠 The Key Difference (Summary)

⚠️ Common Pitfalls and Solutions

Pitfall 1: Count Index Shift

# ❌ BAD: Using count with list
variable "servers" {
  default = ["web", "api", "db"]
}

resource "aws_instance" "bad" {
  count = length(var.servers)
  # If you remove "api", "db" shifts from index 2 to 1
  # Terraform will destroy and recreate it!
}

# ✅ GOOD: Use for_each
resource "aws_instance" "good" {
  for_each = toset(var.servers)
  # Removing "api" doesn't affect "web" or "db"
}

Pitfall 2: Can’t Use Both

# ❌ ERROR: Cannot use both
resource "aws_instance" "invalid" {
  count    = 3
  for_each = toset(["a", "b"])  # ERROR!
}

Pitfall 3: For_Each Requires Map or Set

# ❌ ERROR: for_each needs map or set, not list
variable "azs" {
  default = ["us-east-1a", "us-east-1b"]
}

resource "aws_subnet" "bad" {
  for_each = var.azs  # ERROR! List not supported
}

# ✅ GOOD: Convert to set
resource "aws_subnet" "good" {
  for_each = toset(var.azs)
}

🧪 Hands-On Lab: Count vs For_Each

Let’s build infrastructure demonstrating both approaches!

Step 1: Create Project

mkdir terraform-count-foreach-lab
cd terraform-count-foreach-lab

Step 2: Create variables.tf

# variables.tf

variable "aws_region" {
  type    = string
  default = "us-east-1"
}

variable "environment" {
  type    = string
  default = "dev"
}

# For count example
variable "public_subnet_count" {
  type    = number
  default = 3
}

variable "availability_zones" {
  type    = list(string)
  default = ["us-east-1a", "us-east-1b", "us-east-1c"]
}

# For for_each example
variable "applications" {
  type = map(object({
    instance_type = string
    desired_count = number
    port          = number
  }))

  default = {
    web = {
      instance_type = "t2.micro"
      desired_count = 2
      port          = 80
    }
    api = {
      instance_type = "t2.small"
      desired_count = 2
      port          = 8080
    }
    worker = {
      instance_type = "t2.micro"
      desired_count = 3
      port          = 0
    }
  }
}

variable "create_bastion" {
  type    = bool
  default = true
}

Step 3: Create main.tf

# main.tf

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

provider "aws" {
  region = var.aws_region
}

# VPC
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true

  tags = {
    Name = "count-foreach-demo-vpc"
  }
}

# Internet Gateway
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "main-igw"
  }
}

# ============================================
# COUNT EXAMPLES
# ============================================

# Public Subnets using COUNT
resource "aws_subnet" "public" {
  count = var.public_subnet_count

  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.${count.index + 1}.0/24"
  availability_zone       = var.availability_zones[count.index % length(var.availability_zones)]
  map_public_ip_on_launch = true

  tags = {
    Name  = "public-subnet-${count.index + 1}"
    Index = count.index
  }
}

# Conditional Bastion using COUNT
resource "aws_instance" "bastion" {
  count = var.create_bastion ? 1 : 0

  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t2.micro"
  subnet_id     = aws_subnet.public[0].id

  tags = {
    Name = "bastion-host"
  }
}

# ============================================
# FOR_EACH EXAMPLES
# ============================================

# Application-specific Subnets using FOR_EACH
locals {
  app_subnets = {
    for app_name in keys(var.applications) :
    app_name => {
      cidr_block = "10.0.${10 + index(keys(var.applications), app_name)}.0/24"
      az         = var.availability_zones[0]
    }
  }
}

resource "aws_subnet" "app_subnets" {
  for_each = local.app_subnets

  vpc_id            = aws_vpc.main.id
  cidr_block        = each.value.cidr_block
  availability_zone = each.value.az

  tags = {
    Name        = "${each.key}-subnet"
    Application = each.key
  }
}

# Security Groups using FOR_EACH
resource "aws_security_group" "app_sgs" {
  for_each = var.applications

  name        = "${each.key}-sg"
  description = "Security group for ${each.key}"
  vpc_id      = aws_vpc.main.id

  dynamic "ingress" {
    for_each = each.value.port > 0 ? [1] : []
    content {
      from_port   = each.value.port
      to_port     = each.value.port
      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"]
  }

  tags = {
    Name        = "${each.key}-sg"
    Application = each.key
  }
}

# AMI Data Source
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

# Application Instances using nested COUNT and FOR_EACH
locals {
  # Flatten applications into individual instances
  app_instances = flatten([
    for app_name, app_config in var.applications : [
      for i in range(app_config.desired_count) : {
        key           = "${app_name}-${i}"
        app_name      = app_name
        instance_type = app_config.instance_type
        index         = i
      }
    ]
  ])

  # Convert to map for for_each
  app_instances_map = {
    for inst in local.app_instances :
    inst.key => inst
  }
}

resource "aws_instance" "app_instances" {
  for_each = local.app_instances_map

  ami                    = data.aws_ami.amazon_linux.id
  instance_type          = each.value.instance_type
  subnet_id              = aws_subnet.app_subnets[each.value.app_name].id
  vpc_security_group_ids = [aws_security_group.app_sgs[each.value.app_name].id]

  user_data = <<-EOF
              #!/bin/bash
              echo "${each.value.app_name} instance ${each.value.index}" > /tmp/info.txt
              EOF

  tags = {
    Name        = each.key
    Application = each.value.app_name
    Index       = each.value.index
  }
}

Step 4: Create outputs.tf

# outputs.tf

# COUNT outputs
output "public_subnet_ids_count" {
  description = "Public subnet IDs (created with count)"
  value       = aws_subnet.public[*].id
}

output "bastion_instance_id" {
  description = "Bastion instance ID (conditional with count)"
  value       = length(aws_instance.bastion) > 0 ? aws_instance.bastion[0].id : "Not created"
}

# FOR_EACH outputs
output "app_subnet_ids_foreach" {
  description = "App subnet IDs (created with for_each)"
  value = {
    for key, subnet in aws_subnet.app_subnets :
    key => subnet.id
  }
}

output "security_group_ids_foreach" {
  description = "Security group IDs (created with for_each)"
  value = {
    for key, sg in aws_security_group.app_sgs :
    key => sg.id
  }
}

output "app_instances_by_type" {
  description = "Instances grouped by application"
  value = {
    for app_name in keys(var.applications) :
    app_name => [
      for key, instance in aws_instance.app_instances :
      {
        id         = instance.id
        private_ip = instance.private_ip
      }
      if local.app_instances_map[key].app_name == app_name
    ]
  }
}

output "total_instance_count" {
  description = "Total number of instances"
  value = {
    bastion = var.create_bastion ? 1 : 0
    apps    = sum([for app in var.applications : app.desired_count])
    total   = (var.create_bastion ? 1 : 0) + sum([for app in var.applications : app.desired_count])
  }
}

Step 5: Test Count Behavior

# Initialize
terraform init
# Applyt
erraform apply -auto-approve
# View outputs
terraform output
# Now test count index shift issue
# Modify variables.tf: change public_subnet_count from 3 to 2
# Plan again
terraform plan
# Notice: Terraform wants to destroy public[2]
# If resources depend on indices, this can be problematic!

Step 6: Test For_Each Behavior

# Remove one application from variables.tf
# Change applications map to remove "api"
terraform plan
# Notice: Only "api" resources are destroyed
# "web" and "worker" are unchanged!

Step 7: Clean Up

terraform destroy -auto-approve

📝 Best Practices

✅ DO:

1. Prefer for_each for named resources

    for_each = toset(["web", "api", "worker"])
   

2. Use count for conditional creation

    count = var.enabled ? 1 : 0
   

3. Use count for simple multiples

    count = 5  # When you just need 5 identical things
   

4. Convert lists to sets for for_each

    for_each = toset(var.list)
   

❌ DON’T:

1. Don’t use count with lists that might change

2. Don’t use both count and for_each together

3. Don’t make count/for_each depend on resource attributes

📝 Summary

Today you learned:

• ✅ Count meta-argument and count.index

• ✅ For_each meta-argument with maps and sets

• ✅ each.key and each.value

• ✅ When to use count vs for_each

• ✅ Common pitfalls and solutions

• ✅ Resource referencing patterns

🚀 Tomorrow’s Preview

Day 13: Conditional Expressions & Logic

Tomorrow we’ll:

• Master conditional expressions

• Learn ternary operators

• Use logical operators

• Implement complex conditions

• Build conditional infrastructure

← Day 11: Lists, Maps & Sets | Day 13: Conditionals & Logic →

Remember: Choose for_each for flexibility, count for simplicity!

🎯 Today’s Goals

• Master collection manipulation (lists, maps, sets)

• Learn for expressions and splat expressions

• Use collection functions effectively

• Transform and filter data

• Build dynamic, data-driven configurations

📋 Collection Types Review

# List - ordered, indexed
variable "azs" {
  type = list(string)
  default = ["us-east-1a", "us-east-1b", "us-east-1c"]
}

# Map - key-value pairs
variable "instance_types" {
  type = map(string)
  default = {
    dev  = "t2.micro"
    prod = "t3.large"
  }
}

# Set - unique, unordered
variable "security_groups" {
  type = set(string)
  default = ["sg-123", "sg-456"]
}

🔄 For Expressions

For expressions transform and filter collections.

Syntax

# List comprehension
[for item in list : transformation]

# Map comprehension
{for key, value in map : new_key => new_value}

# Conditional filtering
[for item in list : item if condition]

List to List

variable "names" {
  default = ["alice", "bob", "charlie"]
}

locals {
  # Convert to uppercase
  upper_names = [for name in var.names : upper(name)]
  # Result: ["ALICE", "BOB", "CHARLIE"]

  # Add prefix
  prefixed_names = [for name in var.names : "user-${name}"]
  # Result: ["user-alice", "user-bob", "user-charlie"]

  # Filter and transform
  long_names = [for name in var.names : upper(name) if length(name) > 3]
  # Result: ["ALICE", "CHARLIE"]
}

List to Map

variable "users" {
  default = ["alice", "bob", "charlie"]
}

locals {
  # Create map from list
  user_map = {
    for user in var.users :
    user => {
      email = "${user}@example.com"
      role  = "developer"
    }
  }
  # Result: {
  #   alice = { email = "alice@example.com", role = "developer" }
  #   bob = { email = "bob@example.com", role = "developer" }
  #   ...
  # }
}

Map to List

variable "servers" {
  default = {
    web = { ip = "10.0.1.10", port = 80 }
    api = { ip = "10.0.2.10", port = 8080 }
  }
}

locals {
  # Extract IPs
  server_ips = [for name, config in var.servers : config.ip]
  # Result: ["10.0.1.10", "10.0.2.10"]

  # Create connection strings
  connections = [
    for name, config in var.servers :
    "${config.ip}:${config.port}"
  ]
  # Result: ["10.0.1.10:80", "10.0.2.10:8080"]
}

This part:

• Uses a for-expression to loop through var.servers.

• For each server:

  • name is the key (web, api).

  • config is the value ({ ip = "10.0.1.10", port = 80 }).

• It extracts only the ip field from each server config.

Complex Transformations

🧱 Step 1: Define the variable

variable "subnets" {
  default = [
    { cidr = "10.0.1.0/24", az = "us-east-1a", type = "public" },
    { cidr = "10.0.2.0/24", az = "us-east-1b", type = "public" },
    { cidr = "10.0.10.0/24", az = "us-east-1a", type = "private" }
  ]
}

🧩 What this means:

• subnets is a list of maps (a list of objects).

• Each subnet has three attributes:

  • cidr → CIDR block of the subnet.

  • az → Availability Zone.

  • type → Whether it’s public or private.

📊 Visual structure:

🧮 Step 2: Locals (computed values)

Now you define local variables to transform or filter that data.

🟩 (1) Filter public subnets

public_subnets = [
  for subnet in var.subnets :
  subnet if subnet.type == "public"
]

🔍 Explanation:

• Terraform loops through every element in var.subnets.

• Each element is temporarily named subnet.

• The if condition filters only subnets where subnet.type == "public".

✅ Result:

[
  { cidr = "10.0.1.0/24", az = "us-east-1a", type = "public" },
  { cidr = "10.0.2.0/24", az = "us-east-1b", type = "public" }
]

So you now have a list that only contains the public subnets.

🟦 (2) Transform to a specific structure

subnet_configs = [
  for idx, subnet in var.subnets : {
    name = "subnet-${idx}"
    cidr = subnet.cidr
    az   = subnet.az
    tags = {
      Type  = subnet.type
      Index = idx
    }
  }
]

🔍 Explanation:

This is another for-expression, but this time:

• It uses both the index (idx) and the item (subnet).

• For every subnet, Terraform builds a new object with a custom structure.

Let’s break it down:

✅ Resulting local.subnet_configs:

[
  {
    name = "subnet-0"
    cidr = "10.0.1.0/24"
    az   = "us-east-1a"
    tags = {
      Type  = "public"
      Index = 0
    }
  },
  {
    name = "subnet-1"
    cidr = "10.0.2.0/24"
    az   = "us-east-1b"
    tags = {
      Type  = "public"
      Index = 1
    }
  },
  {
    name = "subnet-2"
    cidr = "10.0.10.0/24"
    az   = "us-east-1a"
    tags = {
      Type  = "private"
      Index = 2
    }
  }
]

🛠️ Essential Collection Functions

Length and Size

length(list)      # Number of elements
length(map)       # Number of keys
length(string)    # Number of characters

#Example
locals {
  az_count      = length(var.availability_zones)  # 3
  subnet_count  = length(var.subnets)             # 5
  name_length   = length("terraform")             # 9
}

Element and Index

element(list, index)  # Get element (wraps around)
index(list, value)    # Find index of value

locals {
  first_az  = element(var.availability_zones, 0)
  # Safe access - wraps around
  safe_az   = element(var.availability_zones, 10)  
  # Wraps to index 1 if list has 3 items
  # Find position
  az_index  = index(var.availability_zones, "us-east-1b")  # 1
}

Let’s go line by line.

1️⃣ first_az = element(var.availability_zones, 0)

• Picks the first element (index 0).

• Result:

    "us-east-1a"
  

2️⃣ safe_az = element(var.availability_zones, 10)

• The list has 3 items, but index 10 is out of range.

• Terraform wraps around using modulo math:

    10 % 3 = 1
    # Result 
    "us-east-1b"
  

• So it returns the element at index 1.

• This is why it’s called “safe access” — it won’t crash even if you go out of range.

3️⃣ az_index = index(var.availability_zones, "us-east-1b")

• Finds the position of "us-east-1b" in the list.

• "us-east-1b" is at position 1 (0-based).

✅ Result:

1

🧠 Summary Table

Contains and Keys/Values

contains(list, value)  # Check if list contains value
keys(map)              # Get all keys
values(map)            # Get all values

locals {
  has_prod = contains(["dev", "staging", "prod"], var.environment)

  # Map operations
  env_names = keys(var.instance_types)    # ["dev", "prod"]
  types     = values(var.instance_types)  # ["t2.micro", "t3.large"]
}

Distinct and Sort

distinct(list)  # Remove duplicates
sort(list)      # Sort alphabetically

locals {
  # Remove duplicates
  unique_azs = distinct(["us-east-1a", "us-east-1b", "us-east-1a"])
  # Result: ["us-east-1a", "us-east-1b"]

  # Sort
  sorted_names = sort(["charlie", "alice", "bob"])
  # Result: ["alice", "bob", "charlie"]

  # Reverse sort
  reverse_sorted = reverse(sort(var.names))
}

Lookup

Safely get a value from a map — with a default fallback if the key doesn’t exist.
Unlike direct access (var.map["key"]), lookup() won’t fail when the key is missing.

🔹 Syntax:

lookup(map, key, default)

💡 Example 1 — Basic lookup

variable "instance_types" {
  default = {
    dev  = "t2.micro"
    prod = "t3.large"
  }
}

variable "environment" {
  default = "staging"
}

locals {
  instance_type = lookup(
    var.instance_types,
    var.environment,
    "t2.micro"  # default
  )
}

✅ Since "staging" isn’t a key in var.instance_types,
local.instance_type = "t2.micro"

💡 Example 2 — Safe nested lookup

variable "database_config" {
  default = {
    dev = { port = 3306 }
    prod = { port = 5432 }
  }
}

variable "environment" {
  default = "qa"
}

locals {
  db_port = lookup(
    lookup(var.database_config, var.environment, {}),
    "port",
    5432
  )
}

Explanation:

• The first lookup() tries to get the qa configuration from var.database_config.
  If not found, returns {} (an empty map).

• The second lookup() then tries to get "port" from that map.
  If it’s missing, returns 5432 as the default.

✅ Result:
db_port = 5432

🧪 Hands-On Lab: Collection Mastery

Let’s build a complex infrastructure using advanced collection techniques!

Step 1: Create Project

mkdir terraform-collections-lab
cd terraform-collections-lab

Step 2: Create variables.tf

# variables.tf

variable "aws_region" {
  type    = string
  default = "us-east-1"
}

variable "project_name" {
  type    = string
  default = "collections-demo"
}

variable "availability_zones" {
  type    = list(string)
  default = ["us-east-1a", "us-east-1b", "us-east-1c"]
}

variable "subnet_configurations" {
  description = "List of subnet configurations"
  type = list(object({
    name = string
    cidr = string
    type = string
    tier = string
  }))

  default = [
    { name = "web-1", cidr = "10.0.1.0/24", type = "public", tier = "web" },
    { name = "web-2", cidr = "10.0.2.0/24", type = "public", tier = "web" },
    { name = "app-1", cidr = "10.0.11.0/24", type = "private", tier = "app" },
    { name = "app-2", cidr = "10.0.12.0/24", type = "private", tier = "app" },
    { name = "db-1", cidr = "10.0.21.0/24", type = "private", tier = "db" },
    { name = "db-2", cidr = "10.0.22.0/24", type = "private", tier = "db" }
  ]
}

variable "instance_configs" {
  description = "Instance configurations per tier"
  type = map(object({
    instance_type = string
    count         = number
    user_data     = string
  }))

  default = {
    web = {
      instance_type = "t2.micro"
      count         = 2
      user_data     = "#!/bin/bash\\necho 'Web Server' > /var/www/html/index.html"
    }
    app = {
      instance_type = "t2.small"
      count         = 2
      user_data     = "#!/bin/bash\\necho 'App Server'"
    }
  }
}

variable "common_tags" {
  type = map(string)
  default = {
    Project   = "Collections Demo"
    ManagedBy = "Terraform"
  }
}

Step 3: Create locals.tf

# locals.tf

locals {
  # Filter subnets by type
  public_subnets = [
    for subnet in var.subnet_configurations :
    subnet if subnet.type == "public"
  ]

  private_subnets = [
    for subnet in var.subnet_configurations :
    subnet if subnet.type == "private"
  ]

  # Group subnets by tier
  subnets_by_tier = {
    for tier in distinct([for s in var.subnet_configurations : s.tier]) :
    tier => [
      for subnet in var.subnet_configurations :
      subnet if subnet.tier == tier
    ]
  }

  # Create subnet map for easy lookup
  subnet_map = {
    for subnet in var.subnet_configurations :
    subnet.name => subnet
  }

  # Get all tiers
  all_tiers = distinct([for s in var.subnet_configurations : s.tier])

  # Get all CIDR blocks
  all_cidrs = [for s in var.subnet_configurations : s.cidr]

  # Distribute subnets across AZs
  subnet_az_mapping = {
    for idx, subnet in var.subnet_configurations :
    subnet.name => var.availability_zones[idx % length(var.availability_zones)]
  }

  # Create security group rules matrix
  tier_connectivity = {
    web = ["app"]
    app = ["db"]
    db  = []
  }

  # Flatten instance deployments
  instance_deployments = flatten([
    for tier, config in var.instance_configs : [
      for i in range(config.count) : {
        tier          = tier
        index         = i
        instance_type = config.instance_type
        user_data     = config.user_data
        subnet        = local.subnets_by_tier[tier][i % length(local.subnets_by_tier[tier])].name
      }
    ]
  ])

  # Create deployment map
  deployment_map = {
    for deployment in local.instance_deployments :
    "${deployment.tier}-${deployment.index}" => deployment
  }

  # Calculate network statistics
  network_stats = {
    total_subnets    = length(var.subnet_configurations)
    public_subnets   = length(local.public_subnets)
    private_subnets  = length(local.private_subnets)
    tiers            = length(local.all_tiers)
    total_instances  = sum([for c in var.instance_configs : c.count])
    azs_used         = length(var.availability_zones)
  }

  # Merge tags for each tier
  tier_tags = {
    for tier in local.all_tiers :
    tier => merge(
      var.common_tags,
      { Tier = tier }
    )
  }
}

Step 4: Create main.tf

# main.tf

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

provider "aws" {
  region = var.aws_region
}

# VPC
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true

  tags = merge(var.common_tags, {
    Name = "${var.project_name}-vpc"
  })
}

# Internet Gateway
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id

  tags = merge(var.common_tags, {
    Name = "${var.project_name}-igw"
  })
}

# Subnets using for_each
resource "aws_subnet" "subnets" {
  for_each = local.subnet_map

  vpc_id                  = aws_vpc.main.id
  cidr_block              = each.value.cidr
  availability_zone       = local.subnet_az_mapping[each.key]
  map_public_ip_on_launch = each.value.type == "public"

  tags = merge(local.tier_tags[each.value.tier], {
    Name = "${var.project_name}-${each.key}"
    Type = each.value.type
  })
}

# Route Table for Public Subnets
resource "aws_route_table" "public" {
  count = length(local.public_subnets) > 0 ? 1 : 0

  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }

  tags = merge(var.common_tags, {
    Name = "${var.project_name}-public-rt"
  })
}

# Route Table Associations
resource "aws_route_table_association" "public" {
  for_each = {
    for subnet in local.public_subnets :
    subnet.name => aws_subnet.subnets[subnet.name].id
  }

  subnet_id      = each.value
  route_table_id = aws_route_table.public[0].id
}

# Security Groups per tier
resource "aws_security_group" "tier_sgs" {
  for_each = toset(local.all_tiers)

  name        = "${var.project_name}-${each.key}-sg"
  description = "Security group for ${each.key} tier"
  vpc_id      = aws_vpc.main.id

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = merge(local.tier_tags[each.key], {
    Name = "${var.project_name}-${each.key}-sg"
  })
}

# AMI Data Source
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

# EC2 Instances
resource "aws_instance" "instances" {
  for_each = local.deployment_map

  ami                    = data.aws_ami.amazon_linux.id
  instance_type          = each.value.instance_type
  subnet_id              = aws_subnet.subnets[each.value.subnet].id
  vpc_security_group_ids = [aws_security_group.tier_sgs[each.value.tier].id]
  user_data              = each.value.user_data

  tags = merge(local.tier_tags[each.value.tier], {
    Name  = "${var.project_name}-${each.key}"
    Index = each.value.index
  })
}

Step 5: Create outputs.tf

# outputs.tf

output "network_statistics" {
  description = "Network statistics"
  value       = local.network_stats
}

output "subnets_by_tier" {
  description = "Subnets grouped by tier"
  value = {
    for tier, subnets in local.subnets_by_tier :
    tier => [for s in subnets : s.name]
  }
}

output "subnet_details" {
  description = "Detailed subnet information"
  value = {
    for name, subnet in aws_subnet.subnets :
    name => {
      id   = subnet.id
      cidr = subnet.cidr_block
      az   = subnet.availability_zone
    }
  }
}

output "instance_distribution" {
  description = "Instances per tier"
  value = {
    for tier in local.all_tiers :
    tier => length([
      for key, inst in local.deployment_map :
      inst if inst.tier == tier
    ])
  }
}

output "instance_ips_by_tier" {
  description = "Instance IPs grouped by tier"
  value = {
    for tier in local.all_tiers :
    tier => [
      for key, instance in aws_instance.instances :
      instance.private_ip if local.deployment_map[key].tier == tier
    ]
  }
}

output "all_instance_ips" {
  description = "All instance IPs"
  value       = values(aws_instance.instances)[*].private_ip
}

output "tier_security_groups" {
  description = "Security group IDs per tier"
  value = {
    for tier, sg in aws_security_group.tier_sgs :
    tier => sg.id
  }
}

Step 6: Deploy and Explore

# Initialize
terraform init
# Plan and review the collections magic!
terraform plan
# Apply
terraform apply -auto-approve
# View outputs
terraform output network_statistics
terraform output subnets_by_tier
terraform output instance_distribution
terraform output instance_ips_by_tier
# Clean up
terraform destroy -auto-approve

📝 Summary

Today you learned:

• ✅ For expressions (list, map transformations)

• ✅ Splat expressions for attribute extraction

• ✅ Essential collection functions

• ✅ Advanced filtering and grouping

• ✅ Complex data transformations

• ✅ Dynamic infrastructure patterns

🚀 Tomorrow’s Preview

Day 12: Count and For_Each - Creating Multiple Resources

Tomorrow we’ll:

• Master count and for_each

• Understand when to use each

• Create dynamic resources

• Manage resource indexes

• Build scalable configurations

← Day 10: Outputs & Locals | Day 12: Count & For_Each →

Remember: Collections and transformations are the key to dynamic infrastructure!

🎯 Today’s Goals

• Master output values and their uses

• Learn local values and when to use them

• Understand output dependencies

• Share data between root and child modules

• Organize complex expressions with locals

📤 Output Values Deep Dive

Output values expose information about your infrastructure after Terraform runs. Think of them as return values from your configuration.

Basic Output Syntax

output "output_name" {
  description = "Description of what this outputs"
  value       = expression
  sensitive   = false  # optional
  depends_on  = []     # optional
}

Why Use Outputs?

1. Display information to users after apply

2. Share data between configurations

3. Pass data to parent modules

4. Feed data to other tools (CI/CD, scripts)

5. Document infrastructure details

🎨 Output Value Examples

Simple Outputs

output "vpc_id" {
  description = "ID of the VPC"
  value       = aws_vpc.main.id
}

output "instance_public_ip" {
  description = "Public IP of the instance"
  value       = aws_instance.web.public_ip
}

output "region" {
  description = "AWS region"
  value       = var.aws_region
}

List Outputs

output "subnet_ids" {
  description = "IDs of all subnets"
  value       = aws_subnet.public[*].id
}

output "availability_zones" {
  description = "Availability zones used"
  value       = aws_subnet.public[*].availability_zone
}

# Output list of maps
output "subnet_details" {
  description = "Detailed subnet information"
  value = [
    for subnet in aws_subnet.public : {
      id   = subnet.id
      cidr = subnet.cidr_block
      az   = subnet.availability_zone
    }
  ]
}

Map Outputs

output "instance_ips" {
  description = "Map of instance names to IPs"
  value = {
    for name, instance in aws_instance.servers :
    name => instance.public_ip
  }
}

output "security_group_rules" {
  description = "Security group details"
  value = {
    for sg_name, sg in aws_security_group.groups :
    sg_name => {
      id          = sg.id
      name        = sg.name
      description = sg.description
    }
  }
}

Computed Outputs

output "website_url" {
  description = "Full URL to access the website"
  value       = "<https://$>{aws_instance.web.public_dns}"
}

output "connection_string" {
  description = "Database connection string"
  value       = "postgresql://${aws_db_instance.main.username}@${aws_db_instance.main.endpoint}/${aws_db_instance.main.db_name}"
}

output "total_subnet_count" {
  description = "Total number of subnets"
  value       = length(aws_subnet.public) + length(aws_subnet.private)
}

Sensitive Outputs

output "db_password" {
  description = "Database password"
  value       = aws_db_instance.main.password
  sensitive   = true  # Won't show in console output
}

output "api_key" {
  description = "API key for application"
  value       = random_password.api_key.result
  sensitive   = true
}

# View sensitive outputs
# terraform output -raw db_password

Conditional Outputs

output "nat_gateway_ip" {
  description = "NAT Gateway public IP"
  value       = var.create_nat_gateway ? aws_nat_gateway.main[0].public_ip : "Not created"
}

output "load_balancer_dns" {
  description = "Load balancer DNS name"
  value       = var.environment == "prod" ? aws_lb.main[0].dns_name : null
}

🔄 Output Dependencies

Sometimes an output needs to wait for other resources:

# Output depends on route table association being complete
output "vpc_ready" {
  description = "VPC is fully configured"
  value       = "VPC ${aws_vpc.main.id} is ready"

  depends_on = [
    aws_route_table_association.public,
    aws_internet_gateway.main
  ]
}

📍 Local Values

Local values assign names to expressions, making configurations more readable and reducing repetition.

Basic Local Syntax

locals {
  # Simple locals
  environment = "production"
  region      = "us-east-1"

  # Computed locals
  common_tags = {
    Environment = var.environment
    ManagedBy   = "Terraform"
    Project     = var.project_name
  }

  # String interpolation
  resource_prefix = "${var.project_name}-${var.environment}"

  # Conditional locals
  instance_type = var.environment == "prod" ? "t3.large" : "t2.micro"
}

# Reference with local.name
resource "aws_instance" "web" {
  instance_type = local.instance_type
  tags          = local.common_tags
}

When to Use Locals

✅ Use locals for:

1. Repeated expressions - DRY principle

2. Complex calculations - Improve readability

3. Conditional logic - Simplify resource blocks

4. Combining variables - Create derived values

5. Transforming data - Process variable inputs

❌ Don’t use locals for:

1. Simple variable references

2. One-time expressions

3. Values that should be variables

🎯 Locals vs Variables

🧪 Hands-On Lab: Outputs & Locals

Let’s build a complete infrastructure using outputs and locals effectively!

Step 1: Create Project Structure

mkdir terraform-outputs-locals
cd terraform-outputs-locals

Step 2: Create variables.tf

# variables.tf

variable "aws_region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

variable "project_name" {
  description = "Project name"
  type        = string
  default     = "webapp"
}

variable "environment" {
  description = "Environment (dev, staging, prod)"
  type        = string

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Must be dev, staging, or prod."
  }
}

variable "vpc_cidr" {
  description = "VPC CIDR block"
  type        = string
  default     = "10.0.0.0/16"
}

variable "availability_zones" {
  description = "Availability zones"
  type        = list(string)
  default     = ["us-east-1a", "us-east-1b"]
}

variable "create_nat_gateway" {
  description = "Create NAT gateway for private subnets"
  type        = bool
  default     = false
}

variable "enable_monitoring" {
  description = "Enable detailed monitoring"
  type        = bool
  default     = false
}

Step 3: Create locals.tf

# locals.tf

locals {
  # Naming convention
  resource_prefix = "${var.project_name}-${var.environment}"

  # Common tags
  common_tags = {
    Project     = var.project_name
    Environment = var.environment
    ManagedBy   = "Terraform"
    CreatedAt   = timestamp()
  }

  # Environment-specific configurations
  instance_type = {
    dev     = "t2.micro"
    staging = "t2.small"
    prod    = "t3.large"
  }

  instance_count = {
    dev     = 1
    staging = 2
    prod    = 3
  }

  # Network calculations
  public_subnet_cidrs = [
    for idx in range(length(var.availability_zones)) :
    cidrsubnet(var.vpc_cidr, 8, idx)
  ]

  private_subnet_cidrs = [
    for idx in range(length(var.availability_zones)) :
    cidrsubnet(var.vpc_cidr, 8, idx + 10)
  ]

  # Security group rules based on environment
  allowed_ssh_cidrs = var.environment == "prod" ? ["10.0.0.0/8"] : ["0.0.0.0/0"]

  # Conditional resource creation flags
  create_private_subnets = var.environment != "dev"
  enable_vpc_flow_logs   = var.environment == "prod"

  # Backup configuration
  backup_retention_days = {
    dev     = 7
    staging = 14
    prod    = 30
  }

  # Computed values
  all_subnet_cidrs = concat(local.public_subnet_cidrs, local.private_subnet_cidrs)
  total_subnets    = length(local.all_subnet_cidrs)

  # Feature flags
  features = {
    monitoring       = var.enable_monitoring
    nat_gateway      = var.create_nat_gateway
    private_subnets  = local.create_private_subnets
    flow_logs        = local.enable_vpc_flow_logs
  }
}

Step 4: Create main.tf

# main.tf

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

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = local.common_tags
  }
}

# VPC
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "${local.resource_prefix}-vpc"
  }
}

# Internet Gateway
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "${local.resource_prefix}-igw"
  }
}

# Public Subnets
resource "aws_subnet" "public" {
  count = length(var.availability_zones)

  vpc_id                  = aws_vpc.main.id
  cidr_block              = local.public_subnet_cidrs[count.index]
  availability_zone       = var.availability_zones[count.index]
  map_public_ip_on_launch = true

  tags = {
    Name = "${local.resource_prefix}-public-${count.index + 1}"
    Type = "Public"
  }
}

# Private Subnets (only in staging and prod)
resource "aws_subnet" "private" {
  count = local.create_private_subnets ? length(var.availability_zones) : 0

  vpc_id            = aws_vpc.main.id
  cidr_block        = local.private_subnet_cidrs[count.index]
  availability_zone = var.availability_zones[count.index]

  tags = {
    Name = "${local.resource_prefix}-private-${count.index + 1}"
    Type = "Private"
  }
}

# Public Route Table
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }

  tags = {
    Name = "${local.resource_prefix}-public-rt"
  }
}

# Route Table Associations
resource "aws_route_table_association" "public" {
  count = length(aws_subnet.public)

  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

# Security Group
resource "aws_security_group" "web" {
  name        = "${local.resource_prefix}-web-sg"
  description = "Security group for web servers"
  vpc_id      = aws_vpc.main.id

  ingress {
    description = "HTTP"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTPS"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = local.allowed_ssh_cidrs
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "${local.resource_prefix}-web-sg"
  }
}

# Data source for latest AMI
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

# EC2 Instances
resource "aws_instance" "web" {
  count = local.instance_count[var.environment]

  ami                    = data.aws_ami.amazon_linux.id
  instance_type          = local.instance_type[var.environment]
  subnet_id              = aws_subnet.public[count.index % length(aws_subnet.public)].id
  vpc_security_group_ids = [aws_security_group.web.id]
  monitoring             = var.enable_monitoring

  user_data = <<-EOF
              #!/bin/bash
              yum update -y
              yum install -y httpd
              systemctl start httpd
              systemctl enable httpd
              echo "<h1>Instance ${count.index + 1} in ${var.environment}</h1>" > /var/www/html/index.html
              echo "<p>Deployed by Terraform</p>" >> /var/www/html/index.html
              EOF

  tags = {
    Name  = "${local.resource_prefix}-web-${count.index + 1}"
    Tier  = "Web"
    Index = count.index + 1
  }
}

Step 5: Create outputs.tf

# outputs.tf

# VPC Outputs
output "vpc_id" {
  description = "ID of the VPC"
  value       = aws_vpc.main.id
}

output "vpc_cidr" {
  description = "CIDR block of the VPC"
  value       = aws_vpc.main.cidr_block
}

output "vpc_arn" {
  description = "ARN of the VPC"
  value       = aws_vpc.main.arn
}

# Network Outputs
output "public_subnet_ids" {
  description = "IDs of public subnets"
  value       = aws_subnet.public[*].id
}

output "private_subnet_ids" {
  description = "IDs of private subnets"
  value       = aws_subnet.private[*].id
}

output "all_subnet_ids" {
  description = "All subnet IDs"
  value       = concat(aws_subnet.public[*].id, aws_subnet.private[*].id)
}

# Instance Outputs
output "instance_ids" {
  description = "IDs of EC2 instances"
  value       = aws_instance.web[*].id
}

output "instance_public_ips" {
  description = "Public IPs of instances"
  value       = aws_instance.web[*].public_ip
}

output "instance_private_ips" {
  description = "Private IPs of instances"
  value       = aws_instance.web[*].private_ip
}

# Website URLs
output "website_urls" {
  description = "URLs to access instances"
  value = [
    for instance in aws_instance.web :
    "<http://$>{instance.public_ip}"
  ]
}

# Security Group Output
output "web_security_group_id" {
  description = "ID of web security group"
  value       = aws_security_group.web.id
}

# Environment Information
output "environment_config" {
  description = "Environment configuration summary"
  value = {
    environment    = var.environment
    region         = var.aws_region
    instance_type  = local.instance_type[var.environment]
    instance_count = local.instance_count[var.environment]
    features       = local.features
  }
}

# Computed Outputs
output "total_resources" {
  description = "Total count of resources created"
  value = {
    vpc               = 1
    subnets           = length(aws_subnet.public) + length(aws_subnet.private)
    instances         = length(aws_instance.web)
    security_groups   = 1
  }
}

# Infrastructure Summary
output "infrastructure_summary" {
  description = "Complete infrastructure summary"
  value = <<-EOT

    ========================================
    Infrastructure Deployment Summary
    ========================================
    Project: ${var.project_name}
    Environment: ${var.environment}
    Region: ${var.aws_region}

    VPC ID: ${aws_vpc.main.id}
    VPC CIDR: ${aws_vpc.main.cidr_block}

    Subnets:
    ${join("\\n", [for subnet in aws_subnet.public : "  - ${subnet.id} (${subnet.cidr_block})"])}

    Instances:
    ${join("\\n", [for idx, instance in aws_instance.web : "  - Instance ${idx + 1}: ${instance.public_ip}"])}

    Access URLs:
    ${join("\\n", [for instance in aws_instance.web : "  - <http://$>{instance.public_ip}"])}
    ========================================
  EOT
}

# Local Values Output (for debugging)
output "local_values" {
  description = "Local values for reference"
  value = {
    resource_prefix       = local.resource_prefix
    public_subnet_cidrs   = local.public_subnet_cidrs
    private_subnet_cidrs  = local.private_subnet_cidrs
    backup_retention_days = local.backup_retention_days[var.environment]
  }
}

Step 6: Create terraform.tfvars

# terraform.tfvars

aws_region         = "us-east-1"
project_name       = "myapp"
environment        = "dev"
vpc_cidr           = "10.0.0.0/16"
availability_zones = ["us-east-1a", "us-east-1b"]
create_nat_gateway = false
enable_monitoring  = false

Step 7: Deploy and Test

# Initialize
terraform init
# Plan
terraform plan
# Apply
terraform apply -auto-approve
# View all outpu
tsterraform output
# View specific output
terraform output vpc_id
# View formatted summary
terraform output infrastructure_summary
# Get raw value for scripting
PUBLIC_IP=$(terraform output -raw instance_public_ips | jq -r '.[0]')curl http://$PUBLIC_IP

Step 8: Test Different Environments

Create prod.tfvars:

environment        = "prod"
vpc_cidr           = "172.16.0.0/16"
create_nat_gateway = true
enable_monitoring  = true

terraform plan -var-file="prod.tfvars"

Notice how locals change the configuration based on the environment!

Step 9: Query Outputs Programmatically

# Get JSON output
terraform output -json > outputs.json
# Parse with jq
cat outputs.json | jq '.instance_public_ips.value'
# Use in scripts
terraform output -json | jq -r '.website_urls.value[]' | while read url; do  echo "Testing $url"  curl -I $urldone

Step 10: Clean Up

terraform destroy -auto-approve

📝 Best Practices

Outputs

✅ DO:

• Add descriptions to all outputs

• Mark sensitive data with sensitive = true

• Group related outputs logically

• Use outputs to share data between configurations

• Output useful debugging information

❌ DON’T:

• Output unnecessary information

• Forget to mark sensitive values

• Use outputs for internal-only values (use locals)

Locals

✅ DO:

• Use locals for repeated expressions

• Name locals clearly and descriptively

• Group related locals in locals blocks

• Use locals for complex calculations

• Document complex local expressions

❌ DON’T:

• Overuse locals for simple values

• Create overly complex local expressions

• Use locals when a variable is more appropriate

📝 Summary

Today you learned:

• ✅ Output values and their purposes

• ✅ Different output types (simple, lists, maps, computed)

• ✅ Sensitive outputs

• ✅ Output dependencies

• ✅ Local values and when to use them

• ✅ Locals vs variables

• ✅ Organizing complex configurations

🚀 Tomorrow’s Preview

Day 11: Working with Lists, Maps, and Sets

Tomorrow we’ll:

• Deep dive into collection manipulation

• Master for expressions

• Learn splat expressions

• Use collection functions

• Build dynamic configurations

← Day 9: Input Variables | Day 11: Lists, Maps & Sets →

Remember: Outputs share data, locals reduce repetition!

🎯 Today’s Goals

• Master all variable types in depth

• Learn complex type constructors

• Implement robust variable validation

• Understand type constraints and conversion

• Build production-ready variable configurations

📊 Variable Type System

Terraform has a rich type system:

Primitive Types          Complex Types
├── string              ├── list(type)
├── number              ├── set(type)
└── bool                ├── map(type)
                        ├── object({...})
                        └── tuple([...])

Special Type
└── any (accepts anything)

🔤 Primitive Types Deep Dive

String Type

variable "region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

variable "project_name" {
  type    = string
  default = "myproject"
}

# Multi-line strings
variable "user_data" {
  type = string
  default = <<-EOT
    #!/bin/bash
    echo "Hello World"
    yum update -y
  EOT
}

Number Type

variable "instance_count" {
  description = "Number of instances to create"
  type        = number
  default     = 3
}

variable "max_size" {
  type    = number
  default = 10
}

# Decimals are supported
variable "cpu_credits" {
  type    = number
  default = 0.5
}

Bool Type

variable "enable_monitoring" {
  description = "Enable detailed monitoring"
  type        = bool
  default     = true
}

variable "is_production" {
  type    = bool
  default = false
}

# Usage in resources
resource "aws_instance" "web" {
  monitoring = var.enable_monitoring
}

📋 Collection Types

List Type

Ordered collection of values of the same type.

variable "availability_zones" {
  description = "List of availability zones"
  type        = list(string)
  default     = ["us-east-1a", "us-east-1b", "us-east-1c"]
}

variable "allowed_ports" {
  description = "List of allowed ports"
  type        = list(number)
  default     = [80, 443, 8080]
}

# Access elements
resource "aws_subnet" "example" {
  availability_zone = var.availability_zones[0]  # First element
}

# Iterate over list
resource "aws_subnet" "public" {
  count             = length(var.availability_zones)
  availability_zone = var.availability_zones[count.index]
}

Set Type

Unordered collection of unique values.

variable "security_group_ids" {
  description = "Set of security group IDs"
  type        = set(string)
  default     = ["sg-12345", "sg-67890"]
}

# Sets automatically remove duplicates
# ["a", "b", "a"] becomes ["a", "b"]

Map Type

Collection of key-value pairs.

variable "instance_types" {
  description = "Instance types per environment"
  type        = map(string)
  default = {
    dev     = "t2.micro"
    staging = "t2.small"
    prod    = "t3.large"
  }
}

variable "common_tags" {
  description = "Tags to apply to all resources"
  type        = map(string)
  default = {
    Project     = "MyApp"
    ManagedBy   = "Terraform"
    Environment = "Production"
  }
}

# Access map values
resource "aws_instance" "web" {
  instance_type = var.instance_types["prod"]
  tags          = var.common_tags
}

🏗️ Structural Types

Object Type

Structured type with named attributes of different types.

variable "vpc_config" {
  description = "VPC configuration"
  type = object({
    cidr_block           = string
    enable_dns_hostnames = bool
    enable_dns_support   = bool
    name                 = string
  })

  default = {
    cidr_block           = "10.0.0.0/16"
    enable_dns_hostnames = true
    enable_dns_support   = true
    name                 = "main-vpc"
  }
}

# Usage
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_config.cidr_block
  enable_dns_hostnames = var.vpc_config.enable_dns_hostnames
  enable_dns_support   = var.vpc_config.enable_dns_support

  tags = {
    Name = var.vpc_config.name
  }
}

Tuple Type

Sequence with fixed length and specific types for each position.

variable "network_config" {
  description = "Network configuration [cidr, az, public]"
  type        = tuple([string, string, bool])
  default     = ["10.0.1.0/24", "us-east-1a", true]
}

# Access by index
locals {
  cidr_block   = var.network_config[0]
  az           = var.network_config[1]
  is_public    = var.network_config[2]
}

🔐 Advanced Variable Validation

Basic Validation

variable "environment" {
  description = "Environment name"
  type        = string

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod."
  }
}

Multiple Validation Rules

variable "instance_count" {
  description = "Number of instances (1-10)"
  type        = number

  validation {
    condition     = var.instance_count > 0
    error_message = "Instance count must be positive."
  }

  validation {
    condition     = var.instance_count <= 10
    error_message = "Instance count cannot exceed 10."
  }
}

Regex Validation

variable "bucket_name" {
  description = "S3 bucket name"
  type        = string

  validation {
    condition     = can(regex("^[a-z0-9][a-z0-9-]{1,61}[a-z0-9]$", var.bucket_name))
    error_message = "Bucket name must be 3-63 characters, lowercase alphanumeric and hyphens."
  }
}

variable "ip_address" {
  description = "IP address"
  type        = string

  validation {
    condition = can(regex(
      "^([0-9]{1,3}\\\\.){3}[0-9]{1,3}$",
      var.ip_address
    ))
    error_message = "Must be a valid IPv4 address."
  }
}

variable "email" {
  description = "Email address"
  type        = string

  validation {
    condition     = can(regex("^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\\\.[a-zA-Z]{2,}$", var.email))
    error_message = "Must be a valid email address."
  }
}

Complex Validation Logic

variable "instance_config" {
  description = "Instance configuration"
  type = object({
    type  = string
    count = number
  })

  validation {
    condition     = contains(["t2.micro", "t2.small", "t3.medium"], var.instance_config.type)
    error_message = "Instance type must be t2.micro, t2.small, or t3.medium."
  }

  validation {
    condition     = var.instance_config.count >= 1 && var.instance_config.count <= 5
    error_message = "Instance count must be between 1 and 5."
  }
}

Validation Functions

variable "region" {
  type = string

  validation {
    # Check if region starts with valid prefix
    condition = anytrue([
      startswith(var.region, "us-"),
      startswith(var.region, "eu-"),
      startswith(var.region, "ap-"),
    ])
    error_message = "Region must start with us-, eu-, or ap-."
  }
}

variable "tags" {
  type = map(string)

  validation {
    # Ensure required tags exist
    condition     = alltrue([
      contains(keys(var.tags), "Environment"),
      contains(keys(var.tags), "Project"),
    ])
    error_message = "Tags must include Environment and Project."
  }
}

Map of Objects

variable "applications" {
  description = "Application configurations"
  type = map(object({
    instance_type = string
    instance_count = number
    subnets        = list(string)
    enable_monitoring = bool
  }))

  default = {
    web = {
      instance_type     = "t3.medium"
      instance_count    = 3
      subnets           = ["subnet-1", "subnet-2"]
      enable_monitoring = true
    }
    api = {
      instance_type     = "t3.large"
      instance_count    = 2
      subnets           = ["subnet-3", "subnet-4"]
      enable_monitoring = true
    }
    worker = {
      instance_type     = "t3.small"
      instance_count    = 5
      subnets           = ["subnet-5"]
      enable_monitoring = false
    }
  }
}

# Usage
resource "aws_instance" "apps" {
  for_each = var.applications

  instance_type = each.value.instance_type
  # ... use other values
}

🧪 Hands-On Lab: Advanced Variables

Let’s build a complete infrastructure with advanced variable types and validation!

Step 1: Create Project

mkdir terraform-advanced-variables
cd terraform-advanced-variables

Step 2: Create variables.tf

# variables.tf

variable "aws_region" {
  description = "AWS region for resources"
  type        = string
  default     = "us-east-1"

  validation {
    condition = can(regex("^(us|eu|ap|sa|ca|me|af)-(north|south|east|west|central|northeast|southeast)-[1-3]$", var.aws_region))
    error_message = "Must be a valid AWS region."
  }
}

variable "environment" {
  description = "Environment name"
  type        = string

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod."
  }
}

variable "vpc_config" {
  description = "VPC configuration"
  type = object({
    cidr_block           = string
    enable_dns_hostnames = bool
    enable_dns_support   = bool
    enable_nat_gateway   = bool
  })

  validation {
    condition     = can(cidrhost(var.vpc_config.cidr_block, 0))
    error_message = "VPC CIDR block must be valid."
  }
}

variable "subnets" {
  description = "Subnet configurations"
  type = list(object({
    name              = string
    cidr_block        = string
    availability_zone = string
    type              = string  # "public" or "private"
  }))

  validation {
    condition = alltrue([
      for subnet in var.subnets :
      contains(["public", "private"], subnet.type)
    ])
    error_message = "Subnet type must be either 'public' or 'private'."
  }

  validation {
    condition = alltrue([
      for subnet in var.subnets :
      can(cidrhost(subnet.cidr_block, 0))
    ])
    error_message = "All subnet CIDR blocks must be valid."
  }
}

variable "security_groups" {
  description = "Security group configurations"
  type = map(object({
    description = string
    ingress_rules = list(object({
      from_port   = number
      to_port     = number
      protocol    = string
      cidr_blocks = list(string)
      description = string
    }))
  }))
}

variable "instance_configs" {
  description = "EC2 instance configurations"
  type = map(object({
    instance_type = string
    count         = number
    subnet_type   = string
    security_groups = list(string)
  }))

  validation {
    condition = alltrue([
      for key, config in var.instance_configs :
      config.count >= 0 && config.count <= 10
    ])
    error_message = "Instance count must be between 0 and 10."
  }
}

variable "tags" {
  description = "Common tags for all resources"
  type        = map(string)

  validation {
    condition = alltrue([
      contains(keys(var.tags), "Project"),
      contains(keys(var.tags), "Owner"),
    ])
    error_message = "Tags must include Project and Owner."
  }
}

variable "enable_backup" {
  description = "Enable automated backups"
  type        = bool
  default     = true
}

Step 3: Create terraform.tfvars

# terraform.tfvars

aws_region  = "us-east-1"
environment = "dev"

vpc_config = {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  enable_nat_gateway   = false
}

subnets = [
  {
    name              = "public-subnet-1"
    cidr_block        = "10.0.1.0/24"
    availability_zone = "us-east-1a"
    type              = "public"
  },
  {
    name              = "public-subnet-2"
    cidr_block        = "10.0.2.0/24"
    availability_zone = "us-east-1b"
    type              = "public"
  },
  {
    name              = "private-subnet-1"
    cidr_block        = "10.0.10.0/24"
    availability_zone = "us-east-1a"
    type              = "private"
  }
]

security_groups = {
  web = {
    description = "Security group for web servers"
    ingress_rules = [
      {
        from_port   = 80
        to_port     = 80
        protocol    = "tcp"
        cidr_blocks = ["0.0.0.0/0"]
        description = "HTTP from anywhere"
      },
      {
        from_port   = 443
        to_port     = 443
        protocol    = "tcp"
        cidr_blocks = ["0.0.0.0/0"]
        description = "HTTPS from anywhere"
      }
    ]
  }
  app = {
    description = "Security group for application servers"
    ingress_rules = [
      {
        from_port   = 8080
        to_port     = 8080
        protocol    = "tcp"
        cidr_blocks = ["10.0.0.0/16"]
        description = "App port from VPC"
      }
    ]
  }
}

instance_configs = {
  web = {
    instance_type   = "t2.micro"
    count           = 2
    subnet_type     = "public"
    security_groups = ["web"]
  }
  app = {
    instance_type   = "t2.small"
    count           = 2
    subnet_type     = "private"
    security_groups = ["app"]
  }
}

tags = {
  Project     = "AdvancedVariables"
  Owner       = "DevOps Team"
  Environment = "Development"
  ManagedBy   = "Terraform"
}

enable_backup = true

Step 4: Create main.tf

# main.tf

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

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = var.tags
  }
}

# VPC
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_config.cidr_block
  enable_dns_hostnames = var.vpc_config.enable_dns_hostnames
  enable_dns_support   = var.vpc_config.enable_dns_support

  tags = {
    Name = "${var.environment}-vpc"
  }
}

# Internet Gateway (for public subnets)
resource "aws_internet_gateway" "main" {
  count = length([for s in var.subnets : s if s.type == "public"]) > 0 ? 1 : 0

  vpc_id = aws_vpc.main.id

  tags = {
    Name = "${var.environment}-igw"
  }
}

# Subnets
resource "aws_subnet" "subnets" {
  for_each = { for idx, subnet in var.subnets : subnet.name => subnet }

  vpc_id                  = aws_vpc.main.id
  cidr_block              = each.value.cidr_block
  availability_zone       = each.value.availability_zone
  map_public_ip_on_launch = each.value.type == "public"

  tags = {
    Name = each.value.name
    Type = each.value.type
  }
}

# Security Groups
resource "aws_security_group" "groups" {
  for_each = var.security_groups

  name        = "${var.environment}-${each.key}-sg"
  description = each.value.description
  vpc_id      = aws_vpc.main.id

  dynamic "ingress" {
    for_each = each.value.ingress_rules
    content {
      from_port   = ingress.value.from_port
      to_port     = ingress.value.to_port
      protocol    = ingress.value.protocol
      cidr_blocks = ingress.value.cidr_blocks
      description = ingress.value.description
    }
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "${var.environment}-${each.key}-sg"
  }
}

Step 5: Test Validation

# Initialize
terraform init
# Test with invalid environment
terraform plan -var="environment=production"
# Error: Environment must be dev, staging, or prod.
# Test with invalid region
terraform plan -var="aws_region=invalid-region"
# Error: Must be a valid AWS region.
# Test with valid values
terraform plan

Step 6: Test Different Environments

Create prod.tfvars:

environment = "prod"

vpc_config = {
  cidr_block           = "172.16.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  enable_nat_gateway   = true
}

instance_configs = {
  web = {
    instance_type   = "t3.medium"
    count           = 4
    subnet_type     = "public"
    security_groups = ["web"]
  }
}

terraform plan -var-file="prod.tfvars"

Step 7: Apply and Clean Up

# Apply
terraform apply -auto-approve

# Destroy
terraform destroy -auto-approve

📝 Variable Best Practices

✅ DO:

1. Always specify types

2. Add descriptions

3. Use validation for critical values

4. Provide sensible defaults

5. Use complex types when appropriate

6. Document validation rules

❌ DON’T:

1. Don’t use any type unless necessary

2. Don’t skip validation for user input

3. Don’t make everything a variable

4. Don’t use overly complex nested types

📝 Summary

Today you learned:

• ✅ All Terraform variable types

• ✅ Complex type constructors (list, map, object, tuple)

• ✅ Advanced validation techniques

• ✅ Regex and custom validation

• ✅ Nested and complex types

• ✅ Type-safe configurations

🚀 Tomorrow’s Preview

Day 10: Output Values & Local Values

Tomorrow we’ll:

• Master output values

• Learn local values and when to use them

• Understand output dependencies

• Share data between configurations

• Build modular outputs

← Day 8: Terraform CLI | Day 10: Outputs & Locals →

Remember: Type safety and validation prevent errors before they happen!

🎯 Today’s Goals

• Master all essential Terraform CLI commands

• Learn command options and flags

• Understand command workflows

• Practice debugging and troubleshooting

• Explore advanced CLI features

🔧 Terraform CLI Structure

terraform <command> [options] [arguments]

Example:
terraform apply -auto-approve -var="region=us-west-2"
          │      │            │
       Command  Options    Arguments

📚 Essential Commands Reference

1. init - Initialize Working Directory

# Basic initialization
terraform init

# Upgrade providers
terraform init -upgrade

# Reconfigure backend
terraform init -reconfigure

# Copy from existing backend
terraform init -migrate-state

# Skip provider plugins
terraform init -backend=false

What init does:

• Downloads provider plugins

• Initializes backend

• Creates .terraform directory

• Generates lock file

Example:

terraform init -upgrade -backend-config="bucket=my-state-bucket"

2. plan - Preview Changes

# Basic plan
terraform plan

# Save plan to file
terraform plan -out=tfplan

# Show resource changes
terraform plan -detailed-exitcode

# Target specific resources
terraform plan -target=aws_instance.web

# Refresh state before planning
terraform plan -refresh=true

# Variable passing
terraform plan -var="instance_type=t2.small"
terraform plan -var-file="production.tfvars"

Exit codes:

• 0 = No changes

• 1 = Error

• 2 = Successful plan with changes

Example:

terraform plan -out=production.tfplan -var-file="prod.tfvars"

3. apply - Execute Changes

# Interactive apply (prompts for confirmation)
terraform apply

# Auto-approve (skip confirmation)
terraform apply -auto-approve

# Apply saved plan
terraform apply tfplan

# Target specific resource
terraform apply -target=aws_instance.web

# Parallelism control
terraform apply -parallelism=10

# Replace specific resource
terraform apply -replace=aws_instance.web

Example:

terraform apply -auto-approve -var="environment=production"

4. destroy - Delete Infrastructure

# Interactive destroy
terraform destroy

# Auto-approve
terraform destroy -auto-approve

# Destroy specific resource
terraform destroy -target=aws_instance.web

# Destroy with variables
terraform destroy -var-file="dev.tfvars"

Example:

terraform destroy -target=aws_s3_bucket.temp -auto-approve

5. validate - Check Configuration

# Validate syntax
terraform validate

# JSON output
terraform validate -json

Checks for:

• Syntax errors

• Invalid resource references

• Missing required arguments

Example:

terraform validate && echo "Configuration is valid!"

6. fmt - Format Code

# Format current directory
terraform fmt

# Format recursively
terraform fmt -recursive

# Check if formatting is needed
terraform fmt -check

# Show diff
terraform fmt -diff

# Write to specific file
terraform fmt main.tf

Example:

terraform fmt -recursive -diff

7. show - Display State or Plan

# Show current state
terraform show

# Show specific resource
terraform state show aws_instance.web

Example:

terraform show -json | jq '.values.root_module.resources'

8. output - Display Outputs

# Show all outputs
terraform output

# Specific output
terraform output vpc_id

# Raw output (no quotes)
terraform output -raw public_ip

# JSON format
terraform output -json

Example:

# Use output in scripts
PUBLIC_IP=$(terraform output -raw instance_public_ip)curl http://$PUBLIC_IP

10. import - Import Existing Resources

# Import resource into state
terraform import aws_instance.web i-1234567890abcdef0

# Import with variable
terraform import -var-file="prod.tfvars" aws_vpc.main vpc-12345

Example:

# First, write the resource blockresource "aws_instance" "existing" {
  # ... configuration}

# Then import
terraform import aws_instance.existing i-1234567890abcdef0

🗂️ State Management Commands

11. state list - List Resources

# List all resources
terraform state list

# Filter by pattern
terraform state list | grep aws_instance

# List module resources
terraform state list module.vpc

12. state show - Display Resource

# Show resource details
terraform state show aws_instance.web

# With address
terraform state show 'aws_instance.web[0]'

13. state mv - Move Resources

# Rename resource
terraform state mv aws_instance.web aws_instance.webserver

# Move to module
terraform state mv aws_instance.web module.compute.aws_instance.web

# Move from module
terraform state mv module.old.aws_instance.web aws_instance.web

14. state rm - Remove Resources

# Remove from state (doesn't delete resource)
terraform state rm aws_instance.web

# Remove multiple
terraform state rm aws_instance.web aws_instance.db

# Remove with index
terraform state rm 'aws_subnet.public[1]'

15. state pull/push

# Download remote state
terraform state pull > backup.tfstate

# Upload state (dangerous!)
terraform state push backup.tfstate

16. force-unlock - Remove Lock

# Unlock stuck state
terraform force-unlock LOCK_ID

📊 Workspace Commands

# List workspaces
terraform workspace list

# Create workspace
terraform workspace new dev

# Switch workspace
terraform workspace select prod

# Show current workspace
terraform workspace show

# Delete workspace
terraform workspace delete dev

🔍 Advanced Commands

17. graph - Visualize Dependencies

# Generate dependency graph
terraform graph

# For planned changes
terraform graph -type=plan

# For destroy operation
terraform graph -type=plan-destroy

# Visualize with Graphviz
terraform graph | dot -Tpng > graph.png

18. providers - Show Providers

# List providers
terraform providers

# Show provider schema
terraform providers schema

# Mirror providers locally
terraform providers mirror ./providers

# Lock providers
terraform providers lock

🧪 Hands-On Lab: CLI Commands Mastery

Let’s practice all these commands!

Step 1: Create Project

mkdir terraform-cli-lab
cd terraform-cli-lab

Step 2: Create Configuration

main.tf:

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

provider "aws" {
  region = var.region
}

variable "region" {
  description = "AWS region"
  type        = string
  default     = "us-east-1"
}

variable "environment" {
  description = "Environment name"
  type        = string
  default     = "dev"
}

variable "instance_count" {
  description = "Number of instances"
  type        = number
  default     = 2
}

# VPC
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name        = "cli-lab-vpc-${var.environment}"
    Environment = var.environment
  }
}

# Subnets
resource "aws_subnet" "public" {
  count = var.instance_count

  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 1}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "public-subnet-${count.index + 1}"
  }
}

# Data source
data "aws_availability_zones" "available" {
  state = "available"
}

# Outputs
output "vpc_id" {
  value = aws_vpc.main.id
}

output "subnet_ids" {
  value = aws_subnet.public[*].id
}

output "region" {
  value = var.region
}

Step 3: Practice Commands

Initialization

# Initializeterraform init
# Check what was createdls -la .terraform/
cat .terraform.lock.hcl

Validation and Formatting

# Check format
terraform fmt -check

# Format files
terraform fmt

# Validate
terraform validate

Planning

# Basic plan
terraform plan

# Plan with variables
terraform plan -var="environment=staging"

# Save plan
terraform plan -out=dev.tfplan

# View saved plan
terraform show dev.tfplan

Apply

# Apply saved plan
terraform apply dev.tfplan

# Direct apply with auto-approve
terraform apply -auto-approve -var="instance_count=3"

State Operations

# List all resources
terraform state list

# Show specific resource
terraform state show aws_vpc.main

# Show subnet with index
terraform state show 'aws_subnet.public[0]'

Outputs

# All outputs
terraform output

# Specific output
terraform output vpc_id

# Raw output for scripting
terraform output -raw region

# JSON output
terraform output -json | jq

Graph Visualization

# Generate graph
terraform graph > graph.dot

# If you have Graphviz installed:
terraform graph | dot -Tpng > infrastructure.png

Targeted Operations

# Plan specific resource
terraform plan -target=aws_subnet.public[0]

# Apply to specific resource
terraform apply -target=aws_vpc.main -auto-approve

# Destroy specific resource
terraform destroy -target='aws_subnet.public[1]' -auto-approve

Step 4: Practice State Manipulation

# Pull state for backup
terraform state pull > backup.tfstate

# List resources
terraform state list

# Move resource (rename)
terraform state mv 'aws_subnet.public[0]' aws_subnet.primary

# Show renamed resource
terraform state show aws_subnet.primary

# Move it back
terraform state mv aws_subnet.primary 'aws_subnet.public[0]'

Step 5: Workspaces

# List workspaces
terraform workspace list

# Create new workspace
terraform workspace new staging

# Switch workspaces
terraform workspace select default
terraform workspace select staging

# Deploy to staging
terraform apply -auto-approve -var="environment=staging"

# Switch back to default
terraform workspace select default

# Delete staging workspace
terraform destroy -auto-approve  

# In staging workspace first
terraform workspace select default
terraform workspace delete staging

Step 6: Cleanup

terraform destroy -auto-approve

🎯 Command Cheat Sheet

Daily Commands

# Initialize project
terraform init 

# Format code
terraform fmt

# Check syntax
terraform validate

# Preview changes            
terraform plan              

# Apply changes
terraform apply    

# Show outputs  
terraform output   

# Delete everything
terraform destroy

Advanced

# Import existing
terraform import               

# Manage workspaces
terraform workspace            

# Manage providers
terraform providers

# Unlock state          
terraform force-unlock

📝 CLI Best Practices

✅ DO:

1. Always run plan before apply

    terraform plan && terraform apply
   

2. Save plans for review

    terraform plan -out=plan.tfplan
   
    # Review the plan
    terraform apply plan.tfplan
   

3. Use auto-approve only in automation

    # In CI/CD
    terraform apply -auto-approve
   

4. Format before committing

    terraform fmt -recursive
    git add .
    git commit -m "Formatted Terraform files"
   

5. Validate regularly

    terraform validate
   

❌ DON’T:

1. Don’t skip planning in production

2. Don’t use auto-approve interactively

3. Don’t forget to backup before state operations

4. Don’t use state push unless absolutely necessary

🐛 Debugging Commands

# Enable debug logging
export TF_LOG=DEBUG
terraform apply

# Log to file
export TF_LOG=TRACE
export TF_LOG_PATH=./terraform.log

terraform apply

# Disable logging
unset TF_LOG
unset TF_LOG_PATH

# Crash logs
cat crash.log

Log Levels:

• TRACE - Most verbose

• DEBUG - Debug information

• INFO - General information

• WARN - Warnings

• ERROR - Errors only

📝 Summary

Today you learned:

• ✅ All essential Terraform CLI commands

• ✅ Command options and flags

• ✅ State management commands

• ✅ Workspace commands

• ✅ Debugging and troubleshooting

• ✅ CLI best practices

• ✅ Command workflows

🚀 Tomorrow’s Preview

Day 9: Input Variables - Types & Validation

Tomorrow we’ll:

• Deep dive into variable types

• Master complex variable structures

• Learn advanced validation rules

• Work with variable precedence

• Build type-safe configurations

💭 Challenge Exercise

Create a script that:

1. Runs terraform plan and saves to file

2. Checks exit code

3. If changes exist (exit code 2), shows the plan

4. Asks for confirmation before applying

5. Backs up state after apply

#!/bin/bash
terraform plan -out=plan.tfplan -detailed-exitcode
EXIT_CODE=$?
if [ $EXIT_CODE -eq 2 ];
then  terraform show plan.tfplan
  read -p "Apply changes? (yes/no): " CONFIRM  
    if [ "$CONFIRM" = "yes" ]; 
    then terraform state pull > backup.tfstate
    terraform apply plan.tfplan
  fi
fi

← Day 6: State Management | Day 9: Input Variables Deep Dive →

Remember: The CLI is your primary interface to Terraform. Master it!

🎯 Today’s Goals

• Understand what Terraform state is and why it matters

• Learn state file structure and contents

• Master state commands

• Configure remote state backends

• Implement S3 backend with state locking

• Learn state best practices and security

📦 What is Terraform State?

Terraform state is a JSON file that maps your configuration to real-world resources. It’s Terraform’s memory of what infrastructure exists.

Why State Exists

Your Code      |    State File         | Real World
(.tf files)    | (terraform.tfstate)   | (AWS)
               |                       |
resource "     |   {                   | ┌─────────┐
aws_instance"  |   "resources": [      │ | EC2     │
"web" {        |   {                   │ | Instance│
  ...          |   "type":             │ | i-12345 │
}              |   "aws_instance",     | └─────────┘
               |   "name": "web",      |
               |  "instances": [       |
               |     {                 |
               |       "id": "i-12345" |
               |     }                 |
               |   ]                   |
               | }]                    |
               |}                      |

      ▲                  ▲                      ▲
      │                  │                      │
      └──────────────────┴──────────────────────┘
              Terraform uses state to map
              code to real infrastructure

What State Stores

1. Resource IDs - Links code to actual resources

2. Attributes - Current resource configuration

3. Metadata - Dependencies, provider info

4. Outputs - Output values from your configuration

🔍 State File Structure

Let’s examine a typical state file:

{  "version": 4,  "terraform_version": "1.6.0",  "serial": 1,  "lineage": "a1b2c3d4-e5f6-g7h8-i9j0-k1l2m3n4o5p6",  "outputs": {    "instance_id": {      "value": "i-1234567890abcdef0",      "type": "string"    }  },  "resources": [    {      "mode": "managed",      "type": "aws_instance",      "name": "web",      "provider": "provider[\\"registry.terraform.io/hashicorp/aws\\"]",      "instances": [        {          "schema_version": 1,          "attributes": {            "id": "i-1234567890abcdef0",            "ami": "ami-0c55b159cbfafe1f0",            "instance_type": "t2.micro",            "public_ip": "54.123.45.67",            ...          }        }      ]    }  ]}

Key Fields

• version: State file format version

• terraform_version: Terraform version used

• serial: Increments with each state change

• lineage: Unique ID for this state file

• resources: All managed resources

• outputs: Output values

🚨 State File Warnings

⚠️ IMPORTANT: State files contain sensitive data!

{  "resources": [    {      "type": "aws_db_instance",      "attributes": {        "password": "supersecret123",  // 🔴 Sensitive!        "endpoint": "db.example.com",        ...      }    }  ]}

State files may contain:

• Passwords

• API keys

• Private IPs

• SSH keys

• Any sensitive resource attributes

Security rules:

• ❌ Never commit state to version control

• ❌ Never share state files publicly

• ✅ Use remote state with encryption

• ✅ Enable state locking

• ✅ Restrict access to state

🎛️ State Commands

Terraform provides commands to inspect and manage state:

1. Show State

# Show all resources
terraform show

# Show in JSON format
terraform show -json

# Show specific resource
terraform state show aws_instance.web

2. List Resources

# List all resources in state
terraform state list

# Filter by pattern
terraform state list | grep vpc

3. Move Resources

# Rename resource in state
terraform state mv aws_instance.web aws_instance.webserver

# Move resource to a module
terraform state mv aws_instance.web module.web.aws_instance.server

4. Remove Resources

# Remove from state (doesn't delete real resource)
terraform state rm aws_instance.web

# Remove all instances of a resource type
terraform state rm 'aws_subnet.public[*]'

5. Pull/Push State

# Download remote state to stdout
terraform state pull

# Manually upload state (dangerous!)
terraform state push terraform.tfstate

6. Replace Provider

# Update provider in state
terraform state replace-provider hashicorp/aws registry.terraform.io/hashicorp/aws

💾 Local vs Remote State

Local State (Default)

project/
├── main.tf
├── terraform.tfstate         ← Stored locally
└── terraform.tfstate.backup  ← Previous version

Pros:

• Simple setup

• No additional configuration

• Fast access

Cons:

• ❌ No collaboration (can’t share)

• ❌ No locking (risk of concurrent changes)

• ❌ No encryption at rest

• ❌ Risk of loss (local file)

Remote State (Recommended)

State stored in shared location (S3, Terraform Cloud, etc.)

Pros:

• ✅ Team collaboration

• ✅ State locking prevents conflicts

• ✅ Encryption at rest

• ✅ Versioning and backup

• ✅ Audit trail

Cons:

• Requires additional setup

• Network dependency

🪣 Remote State with S3

The most common remote backend is S3 + DynamoDB:

• S3: Stores state file

• DynamoDB: Provides state locking

Backend Configuration

terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "project/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}

🧪 Hands-On Lab: Remote State with S3

Let’s set up remote state storage with S3 and DynamoDB!

Step 1: Create State Backend Infrastructure

First, we need to create S3 bucket and DynamoDB table. Create a new directory:

mkdir terraform-state-backend
cd terraform-state-backend

Create backend-setup.tf:

# backend-setup.tf

terraform {
  required_version = ">= 1.0"

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

provider "aws" {
  region = "us-east-1"
}

# Random suffix for unique bucket name
resource "random_id" "bucket_suffix" {
  byte_length = 4
}

# S3 Bucket for Terraform State
resource "aws_s3_bucket" "terraform_state" {
  bucket = "terraform-state-${random_id.bucket_suffix.hex}"

  tags = {
    Name        = "Terraform State Bucket"
    Environment = "Learning"
  }
}

# Enable versioning
resource "aws_s3_bucket_versioning" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id

  versioning_configuration {
    status = "Enabled"
  }
}

# Enable encryption
resource "aws_s3_bucket_server_side_encryption_configuration" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

# Block public access
resource "aws_s3_bucket_public_access_block" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# DynamoDB Table for State Locking
resource "aws_dynamodb_table" "terraform_locks" {
  name         = "terraform-state-lock"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }

  tags = {
    Name        = "Terraform State Lock Table"
    Environment = "Learning"
  }
}

# Outputs
output "s3_bucket_name" {
  description = "S3 bucket name for state"
  value       = aws_s3_bucket.terraform_state.id
}

output "dynamodb_table_name" {
  description = "DynamoDB table name for locking"
  value       = aws_dynamodb_table.terraform_locks.name
}

output "backend_config" {
  description = "Backend configuration to use"
  value = <<-EOT
    terraform {
      backend "s3" {
        bucket         = "${aws_s3_bucket.terraform_state.id}"
        key            = "project/terraform.tfstate"
        region         = "us-east-1"
        encrypt        = true
        dynamodb_table = "${aws_dynamodb_table.terraform_locks.name}"
      }
    }
  EOT
}

Add terraform.tf for the random provider:

# terraform.tf
terraform {
  required_providers {
    random = {
      source  = "hashicorp/random"
      version = "~> 3.0"
    }
  }
}

Step 2: Create Backend Infrastructure

terraform init
terraform apply

Type yes to create the S3 bucket and DynamoDB table.

Save the outputs! You’ll need them.

# Save bucket name
terraform output -raw s3_bucket_name > ../bucket_name.txt

# View the backend config
terraform output backend_config

Step 3: Create a Project with Remote State

Create a new directory:

cd ..
mkdir terraform-remote-state-demo
cd terraform-remote-state-demo

Step 4: Configure Remote Backend

Create backend.tf:

# backend.tf

terraform {
  backend "s3" {
    bucket         = "terraform-state-XXXX"  # Replace with your bucket name
    key            = "demo/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}

Replace terraform-state-XXXX with your actual bucket name from step 2!

Step 5: Create Resources

Create main.tf:

# main.tf

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

provider "aws" {
  region = "us-east-1"
}

# VPC
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "remote-state-demo-vpc"
  }
}

# Subnet
resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"

  tags = {
    Name = "remote-state-demo-subnet"
  }
}

# Security Group
resource "aws_security_group" "web" {
  name        = "remote-state-demo-sg"
  description = "Demo security group"
  vpc_id      = aws_vpc.main.id

  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"]
  }

  tags = {
    Name = "remote-state-demo-sg"
  }
}

Create outputs.tf:

# outputs.tf

output "vpc_id" {
  description = "VPC ID"
  value       = aws_vpc.main.id
}

output "subnet_id" {
  description = "Subnet ID"
  value       = aws_subnet.public.id
}

output "security_group_id" {
  description = "Security Group ID"
  value       = aws_security_group.web.id
}

Step 6: Initialize with Remote Backend

terraform init

You’ll see:

Initializing the backend...

Successfully configured the backend "s3"!

Step 7: Apply Configuration

terraform apply

Type yes to create resources.

Step 8: Verify State in S3

# List state files in S3
aws s3 ls s3://terraform-state-XXXX/demo/

# Download and view state
aws s3 cp s3://terraform-state-XXXX/demo/terraform.tfstate - | jq '.'

Step 9: Test State Locking

Terminal 1:

terraform plan
# Keep this running

Terminal 2 (while Terminal 1 is still running):

terraform plan

You should see:

Error: Error acquiring the state lock

Lock Info:
  ID:        abc123...
  Path:      terraform-state-XXXX/demo/terraform.tfstate
  Operation: OperationTypeApply
  Who:       user@hostname
  Version:   1.6.0
  Created:   2024-01-15 10:30:00

This proves state locking is working! ✅

Step 10: Verify State in DynamoDB

# Check lock table
aws dynamodb scan --table-name terraform-state-lock

# During an active plan/apply, you'll see:{  "Items": [
    {      "LockID": {
        "S": "terraform-state-XXXX/demo/terraform.tfstate"      },      "Info": {
        "S": "{\\"ID\\":\\"...\\",\\"Operation\\":\\"OperationTypePlan\\",\\"Who\\":\\"user@hostname\\",...}"      }    }  ]}

Step 11: Inspect State Commands

# List resources (reads from S3)
terraform state list

# Show specific resource
terraform state show aws_vpc.main

# Pull state locally for inspection
terraform state pull > local_state.json
cat local_state.json | jq '.resources'

Step 12: Clean Up

# Destroy project resources
terraform destroy

# Go back and destroy backend infrastructure
cd ../terraform-state-backend
terraform destroy

🔐 State Security Best Practices

1. Use Remote State

terraform {
  backend "s3" {
    bucket  = "terraform-state"
    encrypt = true  # ✅ Always encrypt!
  }
}

2. Enable Versioning

resource "aws_s3_bucket_versioning" "state" {
  versioning_configuration {
    status = "Enabled"  # ✅ Recover from accidents
  }
}

3. Restrict Access

# Use IAM policies to restrict access
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::terraform-state/*",
  "Condition": {
    "StringEquals": {
      "aws:userid": ["allowed-user-id"]
    }
  }
}

4. Use Separate States

• Different states for different environments

• Blast radius limitation

s3://terraform-state/
├── dev/terraform.tfstate
├── staging/terraform.tfstate
└── prod/terraform.tfstate

📊 State Best Practices

✅ DO:

1. Use remote state for team projects

2. Enable state locking to prevent conflicts

3. Encrypt state at rest (S3 encryption)

4. Enable versioning for recovery

5. Use separate states per environment

6. Back up state files regularly

7. Use terraform state commands carefully

❌ DON’T:

1. Don’t commit state to git

    # .gitignore
    *.tfstate
    *.tfstate.backup
   

2. Don’t manually edit state files

   • Use terraform state commands instead

3. Don’t share state files publicly

4. Don’t use same state for all environments

5. Don’t forget to lock the state.

🆘 State Troubleshooting

Problem: State Drift

Resources changed outside Terraform.

# Detect drift
terraform plan

# Refresh state
terraform apply -refresh-only

Problem: Lost State

State file deleted or corrupted.

# With S3 versioning
aws s3api list-object-versions --bucket terraform-state
# Restore previous version
aws s3api get-object --bucket terraform-state --key terraform.tfstate --version-id VERSION_ID terraform.tfstate

Problem: State Lock Stuck

Lock not released after the crash.

# Force unlock (use carefully!)
terraform force-unlock LOCK_ID

📝 Summary

Today you learned:

• ✅ What Terraform state is and why it exists

• ✅ State file structure and contents

• ✅ State security considerations

• ✅ Essential state commands

• ✅ Local vs remote state

• ✅ S3 + DynamoDB backend setup

• ✅ State locking mechanism

• ✅ State best practices and troubleshooting

🎉 Week 1 Complete!

Congratulations! You’ve completed Week 1 and learned:

• Infrastructure as Code fundamentals

• Terraform installation and setup

• Providers and their configuration

• Variables and outputs

• Resource dependencies and data sources

• State management

🚀 Week 2 Preview

Day 8: Terraform CLI Commands Deep Dive

Next week we’ll:

• Master all Terraform CLI commands

• Learn workspace management

• Explore advanced variable types

• Work with complex data structures

• Build more sophisticated infrastructure

💭 Weekend Challenge

1. Create a remote state backend in your AWS account

2. Build a multi-tier application with remote state

3. Practice state commands

4. Set up separate states for dev and prod

← Day 5: Dependencies & Data Sources | Day 8: Terraform CLI Deep Dive →

Remember: Proper state management is the foundation of reliable infrastructure automation!

🎊 Enjoy your Sunday rest! See you on Monday for Week 2!

🎯 Today’s Goals

• Understand implicit vs explicit dependencies

• Master the depends_on meta-argument

• Learn about data sources and their uses

• Query existing AWS resources

• Build infrastructure that references external resources

• Understand the resource graph

🔗 Resource Dependencies

When building infrastructure, resources often depend on each other. Terraform needs to know the order to create or destroy them.

Example Dependency Chain

    VPC
     │
     ├─► Subnet
     │     │
     │     └─► EC2 Instance
     │
     └─► Internet Gateway
           │
           └─► Route Table

🤝 Implicit Dependencies

Implicit dependencies are automatically detected when one resource references another’s attributes.

# VPC is created first (no dependencies)
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

# Subnet depends on VPC (implicit dependency)
resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id  # ← This creates implicit dependency
  cidr_block = "10.0.1.0/24"
}

# Instance depends on Subnet (implicit dependency)
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  subnet_id     = aws_subnet.public.id  # ← Implicit dependency
}

Terraform’s creation order:

1. VPC

2. Subnet (waits for VPC)

3. Instance (waits for Subnet)

Destruction order (reverse):

1. Instance

2. Subnet

3. VPC

📌 Explicit Dependencies (depends_on)

Sometimes dependencies exist that Terraform can’t detect automatically. Use depends_on for explicit dependencies.

When to Use depends_on

# IAM role must exist before instance profile
resource "aws_iam_role" "instance_role" {
  name = "instance-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
    }]
  })
}

# IAM policy attachment
resource "aws_iam_role_policy_attachment" "instance_policy" {
  role       = aws_iam_role.instance_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

# Instance profile needs the policy to be attached
resource "aws_iam_instance_profile" "instance_profile" {
  name = "instance-profile"
  role = aws_iam_role.instance_role.name

  # Explicit dependency - ensure policy is attached first
  depends_on = [aws_iam_role_policy_attachment.instance_policy]
}

Multiple Dependencies

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  depends_on = [
    aws_iam_instance_profile.instance_profile,
    aws_security_group.web,
    aws_subnet.public
  ]
}

🔍 Data Sources

Data sources allow Terraform to query existing infrastructure or external information. They don’t create resources - they only read data.

Data Source Syntax

data "provider_resource" "name" {
  # Filter criteria
}

# Reference with: data.provider_resource.name.attribute

Example: Query Existing VPC

# Query existing VPC by tag
data "aws_vpc" "existing" {
  tags = {
    Name = "production-vpc"
  }
}

# Use the VPC ID in a new subnet
resource "aws_subnet" "new_subnet" {
  vpc_id     = data.aws_vpc.existing.id
  cidr_block = "10.0.10.0/24"
}

📚 Common AWS Data Sources

1. AWS AMI (Amazon Machine Image)

# Get latest Amazon Linux 2 AMI
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t2.micro"
}

2. AWS Availability Zones

# Get all available AZs in current region
data "aws_availability_zones" "available" {
  state = "available"
}

resource "aws_subnet" "public" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]
}

3. AWS Account Information

data "aws_caller_identity" "current" {}

output "account_id" {
  value = data.aws_caller_identity.current.account_id
}

output "caller_arn" {
  value = data.aws_caller_identity.current.arn
}

4. AWS Region

data "aws_region" "current" {}

output "current_region" {
  value = data.aws_region.current.name
}

5. Existing Security Group

data "aws_security_group" "default" {
  name   = "default"
  vpc_id = aws_vpc.main.id
}

6. Existing Subnet

data "aws_subnet" "selected" {
  filter {
    name   = "tag:Name"
    values = ["production-subnet-1"]
  }
}

🧪 Hands-On Lab: Dependencies & Data Sources

Let’s build a complete infrastructure using both implicit/explicit dependencies and data sources!

Step 1: Create Project Directory

mkdir terraform-dependencies-lab
cd terraform-dependencies-lab

Step 2: Create data-sources.tf

# data-sources.tf

# Get current AWS region
data "aws_region" "current" {}

# Get current AWS account
data "aws_caller_identity" "current" {}

# Get available availability zones
data "aws_availability_zones" "available" {
  state = "available"
}

# Get latest Amazon Linux 2 AMI
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  filter {
    name   = "root-device-type"
    values = ["ebs"]
  }
}

Step 3: Create main.tf

# main.tf

terraform {
  required_version = ">= 1.0"

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

provider "aws" {
  region = "us-east-1"
}

# VPC
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "dependencies-lab-vpc"
  }
}

# Internet Gateway (implicit dependency on VPC)
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "dependencies-lab-igw"
  }
}

# Public Subnets using data source for AZs
resource "aws_subnet" "public" {
  count = 2

  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.${count.index + 1}.0/24"
  availability_zone       = data.aws_availability_zones.available.names[count.index]
  map_public_ip_on_launch = true

  tags = {
    Name = "public-subnet-${count.index + 1}"
    AZ   = data.aws_availability_zones.available.names[count.index]
  }
}

# Route Table
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }

  tags = {
    Name = "public-route-table"
  }
}

# Route Table Association
resource "aws_route_table_association" "public" {
  count = 2

  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

# Security Group
resource "aws_security_group" "web" {
  name        = "web-security-group"
  description = "Allow HTTP and SSH"
  vpc_id      = aws_vpc.main.id

  ingress {
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTP"
    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"]
  }

  tags = {
    Name = "web-sg"
  }
}

# IAM Role for EC2
resource "aws_iam_role" "ec2_role" {
  name = "ec2-ssm-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "ec2.amazonaws.com"
      }
    }]
  })

  tags = {
    Name = "ec2-ssm-role"
  }
}

# Attach SSM policy to role
resource "aws_iam_role_policy_attachment" "ssm_policy" {
  role       = aws_iam_role.ec2_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

# Instance Profile (explicit dependency on policy attachment)
resource "aws_iam_instance_profile" "ec2_profile" {
  name = "ec2-instance-profile"
  role = aws_iam_role.ec2_role.name

  # Explicit dependency to ensure policy is attached first
  depends_on = [aws_iam_role_policy_attachment.ssm_policy]
}

# EC2 Instance using AMI from data source
resource "aws_instance" "web" {
  ami                    = data.aws_ami.amazon_linux.id
  instance_type          = "t2.micro"
  subnet_id              = aws_subnet.public[0].id
  vpc_security_group_ids = [aws_security_group.web.id]
  iam_instance_profile   = aws_iam_instance_profile.ec2_profile.name

  user_data = <<-EOF
              #!/bin/bash
              yum update -y
              yum install -y httpd
              systemctl start httpd
              systemctl enable httpd
              echo "<h1>Hello from Terraform!</h1>" > /var/www/html/index.html
              echo "<p>Instance in ${data.aws_availability_zones.available.names[0]}</p>" >> /var/www/html/index.html
              echo "<p>AMI: ${data.aws_ami.amazon_linux.id}</p>" >> /var/www/html/index.html
              EOF

  tags = {
    Name = "web-server"
  }

  # Explicit dependency on route table association
  depends_on = [aws_route_table_association.public]
}

Step 4: Create outputs.tf

# outputs.tf

output "account_id" {
  description = "AWS Account ID"
  value       = data.aws_caller_identity.current.account_id
}

output "region" {
  description = "AWS Region"
  value       = data.aws_region.current.name
}

output "availability_zones" {
  description = "Available AZs"
  value       = data.aws_availability_zones.available.names
}

output "ami_id" {
  description = "AMI ID used for instance"
  value       = data.aws_ami.amazon_linux.id
}

output "ami_name" {
  description = "AMI name"
  value       = data.aws_ami.amazon_linux.name
}

output "vpc_id" {
  description = "VPC ID"
  value       = aws_vpc.main.id
}

output "subnet_ids" {
  description = "Subnet IDs"
  value       = aws_subnet.public[*].id
}

output "instance_id" {
  description = "EC2 Instance ID"
  value       = aws_instance.web.id
}

output "instance_public_ip" {
  description = "EC2 Instance Public IP"
  value       = aws_instance.web.public_ip
}

output "website_url" {
  description = "Website URL"
  value       = "http://${aws_instance.web.public_ip}"
}

Step 5: Initialize and Plan

terraform init
terraform plan

Notice in the plan:

• Data sources are read first

• Resources are created in dependency order

• Implicit dependencies shown with arrows

Step 6: Visualize Dependencies

terraform graph | dot -Tpng > dependencies.png

Open dependencies.png to see the dependency graph!

Step 7: Apply Configuration

terraform apply

Type yes to confirm.

Step 8: Test the Website

After apply completes:

# Get the website URL
terraform output website_url
# Test with curl
curl $(terraform output -raw website_url)

You should see the HTML page with instance details!

Step 9: Examine Data Source Values

terraform output ami_id
terraform output ami_name
terraform output availability_zones

These values were queried from AWS, not hardcoded!

Step 10: Understand the Dependency Chain

Data Sources (Read First)
├── aws_region.current
├── aws_caller_identity.current
├── aws_availability_zones.available
└── aws_ami.amazon_linux

Resources (Created in Order)
├── 1. aws_vpc.main
├── 2. aws_internet_gateway.main (depends on VPC)
├── 3. aws_subnet.public[0,1] (depends on VPC, uses AZ data)
├── 4. aws_security_group.web (depends on VPC)
├── 5. aws_iam_role.ec2_role
├── 6. aws_iam_role_policy_attachment.ssm_policy (depends on role)
├── 7. aws_iam_instance_profile.ec2_profile (explicit depends_on policy)
├── 8. aws_route_table.public (depends on VPC and IGW)
├── 9. aws_route_table_association.public[0,1] (depends on subnet and RT)
└── 10. aws_instance.web (depends on subnet, SG, profile, uses AMI data)

Step 11: Clean Up

terraform destroy

Terraform destroys in reverse dependency order!

🎨 Resource Graph

Terraform builds a dependency graph to determine execution order:

# Generate graph in DOT format
terraform graph
# With specific plan
terraform graph -type=plan
# For destroy operations
terraform graph -type=plan-destroy

📊 Data Sources vs Resources

🔑 Key Concepts

Implicit Dependencies

• Created automatically when referencing attributes

• Most common type

• Terraform detects them automatically

Explicit Dependencies

• Use depends_on meta-argument

• For non-obvious dependencies

• Accepts list of resources

Data Sources

• Query existing infrastructure

• Read external information

• Don’t create resources

• Evaluated before resources

📝 Best Practices

✅ DO:

1. Prefer implicit dependencies

    subnet_id = aws_subnet.main.id  # ✅ Implicit
   

2. Use depends_on sparingly

    # Only when necessary
    depends_on = [aws_iam_role_policy_attachment.policy]
   

3. Use data sources for existing resources

    data "aws_ami" "latest" {
      most_recent = true
    }
   

4. Document why depends_on is needed

    depends_on = [aws_route_table.main]
    # Ensure route exists before instance tries to access internet
   

❌ DON’T:

1. Don’t use depends_on when implicit dependencies work

2. Don’t create circular dependencies

3. Don’t hardcode AMI IDs - use data sources

4. Don’t assume resource creation order without dependencies

📝 Summary

Today you learned:

• ✅ Implicit vs explicit dependencies

• ✅ When and how to use depends_on

• ✅ Data sources and their purpose

• ✅ Common AWS data sources

• ✅ How Terraform builds the resource graph

• ✅ Best practices for managing dependencies

🚀 Tomorrow’s Preview

Day 6: State Management Fundamentals

Tomorrow we’ll:

• Deep dive into Terraform state

• Understand state file structure

• Learn about state locking

• Configure remote state backends

• Master state commands

• Implement S3 backend for state storage

💭 Challenge Exercise

Modify today’s lab to:

1. Use a data source to find an existing S3 bucket

2. Add a resource that depends on both the VPC and the bucket

3. Create an explicit dependency between two resources

4. Add a data source for AWS SSM parameters

← Day 4: Variables & Outputs | Day 6: State Management →

Remember: Understanding dependencies is crucial for building reliable, complex infrastructure!

🎯 Today’s Goals

• Understand input variables and why they matter

• Learn variable types and validation

• Master output values

• Create reusable, parameterized configurations

• Build a complete infrastructure with variables

🔄 The Problem with Hardcoded Values

Remember our VPC from yesterday?

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"  # ❌ Hardcoded

  tags = {
    Name = "main-vpc"  # ❌ Hardcoded
  }
}

Problems:

• Can’t reuse for different environments (dev, staging, prod)

• Changing values requires editing code

• Difficult to customize deployments

• Not DRY (Don’t Repeat Yourself)

📥 Input Variables

Input variables are parameters for your Terraform configuration. Think of them like function arguments in programming.

Basic Variable Syntax

variable "variable_name" {
  description = "Description of the variable"
  type        = string
  default     = "default_value"
}

Variable Structure Explained

┌──────────────────────────────────────┐
│ variable "vpc_cidr" {                │
│          ────┬────                   │
│              │                       │
│         Variable name                │
│                                      │
│   description = "VPC CIDR block"     │
│   ──────┬──────   ──────┬────────    │
│         │                │           │
│    Attribute         Value           │
│                                      │
│   type    = string                   │
│   default = "10.0.0.0/16"            │
│ }                                    │
└──────────────────────────────────────┘

Using Variables

Reference variables with var. prefix:

resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr

  tags = {
    Name = var.vpc_name
  }
}

📊 Variable Types

Terraform supports several variable types:

1. String

variable "region" {
  type    = string
  default = "us-east-1"
}

2. Number

variable "instance_count" {
  type    = number
  default = 2
}

3. Bool

variable "enable_dns" {
  type    = bool
  default = true
}

4. List

variable "availability_zones" {
  type    = list(string)
  default = ["us-east-1a", "us-east-1b"]
}

# Access: var.availability_zones[0]

5. Map

variable "instance_types" {
  type = map(string)
  default = {
    dev  = "t2.micro"
    prod = "t3.large"
  }
}

# Access: var.instance_types["dev"]

6. Object

variable "vpc_config" {
  type = object({
    cidr_block = string
    name       = string
    enable_dns = bool
  })

  default = {
    cidr_block = "10.0.0.0/16"
    name       = "main-vpc"
    enable_dns = true
  }
}

# Access: var.vpc_config.cidr_block

🎯 Variable Definition Precedence

Terraform loads variables in this order (later sources override earlier):

1. Environment variables      (TF_VAR_name)
2. terraform.tfvars           (auto-loaded)
3. *.auto.tfvars              (auto-loaded alphabetically)
4. -var flag                  (command line)
5. -var-file flag             (command line)

Example:

# Environment variable
export TF_VAR_region="us-west-2"

# terraform.tfvars file
region = "us-east-1"

# Command line (highest priority)
terraform apply -var="region=eu-west-1"

# Result: region = "eu-west-1"

📝 Ways to Set Variable Values

Method 1: Default Values (in variables.tf)

variable "region" {
  type    = string
  default = "us-east-1"
}

Method 2: terraform.tfvars File

# terraform.tfvars
region         = "us-east-1"
instance_type  = "t2.micro"
instance_count = 3

Method 3: Custom .tfvars File

# production.tfvars
region         = "us-east-1"
instance_type  = "t3.large"
instance_count = 10

Apply with:

terraform apply -var-file="production.tfvars"

Method 4: Environment Variables

export TF_VAR_region="us-east-1"
export TF_VAR_instance_type="t2.micro"
terraform apply

Method 5: Command Line

terraform apply -var="region=us-east-1" -var="instance_type=t2.micro"

Method 6: Interactive Prompt

If no value is provided and there’s no default:

$ terraform apply
var.region  Enter a value: us-east-1

✅ Variable Validation

Add validation rules to ensure correct values:

variable "region" {
  type        = string
  description = "AWS region"

  validation {
    condition     = can(regex("^(us|eu|ap)-", var.region))
    error_message = "Region must start with us-, eu-, or ap-."
  }
}

variable "instance_count" {
  type        = number
  description = "Number of instances"

  validation {
    condition     = var.instance_count > 0 && var.instance_count <= 10
    error_message = "Instance count must be between 1 and 10."
  }
}

📤 Output Values

Outputs expose information about your infrastructure after it’s created.

Basic Output Syntax

output "output_name" {
  description = "Description of the output"
  value       = resource.name.attribute
}

Example Outputs

output "vpc_id" {
  description = "ID of the VPC"
  value       = aws_vpc.main.id
}

output "public_subnet_ids" {
  description = "IDs of public subnets"
  value       = aws_subnet.public[*].id
}

output "instance_public_ips" {
  description = "Public IPs of instances"
  value       = aws_instance.web[*].public_ip
}

Sensitive Outputs

Mark sensitive data to hide from console output:

output "database_password" {
  description = "Database password"
  value       = aws_db_instance.main.password
  sensitive   = true
}

Using Outputs

View outputs after applying:

# View output
terraform output

# View specific output
terraform output vpc_id

# Output as JSON
terraform output -json

🧪 Hands-On Lab: Parameterized VPC Infrastructure

Let’s rebuild our VPC with variables and outputs!

Step 1: Create Project Structure

mkdir terraform-variables-lab
cd terraform-variables-lab

Create these files:

• variables.tf - Variable definitions

• main.tf - Resources

• outputs.tf - Output values

• terraform.tfvars - Variable values

Step 2: Create variables.tf

# variables.tf

variable "aws_region" {
  description = "AWS region for resources"
  type        = string
  default     = "us-east-1"
}

variable "project_name" {
  description = "Project name for tagging"
  type        = string
  default     = "terraform-learning"
}

variable "environment" {
  description = "Environment (dev, staging, prod)"
  type        = string

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Environment must be dev, staging, or prod."
  }
}

variable "vpc_cidr" {
  description = "CIDR block for VPC"
  type        = string
  default     = "10.0.0.0/16"
}

variable "public_subnet_cidrs" {
  description = "CIDR blocks for public subnets"
  type        = list(string)
  default     = ["10.0.1.0/24", "10.0.2.0/24"]
}

variable "availability_zones" {
  description = "Availability zones"
  type        = list(string)
  default     = ["us-east-1a", "us-east-1b"]
}

variable "enable_dns_hostnames" {
  description = "Enable DNS hostnames in VPC"
  type        = bool
  default     = true
}

variable "common_tags" {
  description = "Common tags for all resources"
  type        = map(string)
  default = {
    ManagedBy = "Terraform"
  }
}

Step 3: Create main.tf

# main.tf

terraform {
  required_version = ">= 1.0"

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

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = var.common_tags
  }
}

# VPC
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = var.enable_dns_hostnames
  enable_dns_support   = true

  tags = {
    Name        = "${var.project_name}-${var.environment}-vpc"
    Environment = var.environment
  }
}

# Internet Gateway
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name        = "${var.project_name}-${var.environment}-igw"
    Environment = var.environment
  }
}

# Public Subnets
resource "aws_subnet" "public" {
  count = length(var.public_subnet_cidrs)

  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnet_cidrs[count.index]
  availability_zone       = var.availability_zones[count.index]
  map_public_ip_on_launch = true

  tags = {
    Name        = "${var.project_name}-${var.environment}-public-subnet-${count.index + 1}"
    Environment = var.environment
    Type        = "Public"
  }
}

# Route Table
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }

  tags = {
    Name        = "${var.project_name}-${var.environment}-public-rt"
    Environment = var.environment
  }
}

# Route Table Associations
resource "aws_route_table_association" "public" {
  count = length(var.public_subnet_cidrs)

  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

# Security Group
resource "aws_security_group" "web" {
  name        = "${var.project_name}-${var.environment}-web-sg"
  description = "Security group for web servers"
  vpc_id      = aws_vpc.main.id

  ingress {
    description = "HTTP from anywhere"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTPS from anywhere"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    description = "All traffic outbound"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name        = "${var.project_name}-${var.environment}-web-sg"
    Environment = var.environment
  }
}

Step 4: Create outputs.tf

# outputs.tf

output "vpc_id" {
  description = "ID of the VPC"
  value       = aws_vpc.main.id
}

output "vpc_cidr" {
  description = "CIDR block of the VPC"
  value       = aws_vpc.main.cidr_block
}

output "public_subnet_ids" {
  description = "IDs of public subnets"
  value       = aws_subnet.public[*].id
}

output "public_subnet_cidrs" {
  description = "CIDR blocks of public subnets"
  value       = aws_subnet.public[*].cidr_block
}

output "internet_gateway_id" {
  description = "ID of the Internet Gateway"
  value       = aws_internet_gateway.main.id
}

output "web_security_group_id" {
  description = "ID of the web security group"
  value       = aws_security_group.web.id
}

output "availability_zones" {
  description = "Availability zones used"
  value       = aws_subnet.public[*].availability_zone
}

output "environment" {
  description = "Environment name"
  value       = var.environment
}

Step 5: Create terraform.tfvars

# terraform.tfvars

environment          = "dev"
project_name         = "myapp"
vpc_cidr             = "10.0.0.0/16"
public_subnet_cidrs  = ["10.0.1.0/24", "10.0.2.0/24"]
availability_zones   = ["us-east-1a", "us-east-1b"]
enable_dns_hostnames = true

common_tags = {
  ManagedBy = "Terraform"
  Owner     = "DevOps Team"
  Purpose   = "Learning"
}

Step 6: Initialize and Validate

terraform init
terraform fmt
terraform validate

Step 7: Plan with Different Environments

Development:

terraform plan

Staging (create staging.tfvars):

# staging.tfvars
environment = "staging"
vpc_cidr    = "10.1.0.0/16"
public_subnet_cidrs = ["10.1.1.0/24", "10.1.2.0/24"]

terraform plan -var-file="staging.tfvars"

Step 8: Apply Configuration

terraform apply

Type yes when prompted.

Step 9: View Outputs

# All outputs
terraform output
# Specific output
terraform output vpc_id
# JSON format
terraform output -json > infrastructure.json

Expected output:

availability_zones = [
  "us-east-1a",
  "us-east-1b",
]
environment = "dev"
internet_gateway_id = "igw-xxxxx"
public_subnet_cidrs = [
  "10.0.1.0/24",
  "10.0.2.0/24",
]
public_subnet_ids = [
  "subnet-xxxxx",
  "subnet-yyyyy",
]
vpc_cidr = "10.0.0.0/16"
vpc_id = "vpc-xxxxx"
web_security_group_id = "sg-xxxxx"

Step 10: Test Variable Validation

Try an invalid environment:

terraform apply -var="environment=production"

You’ll get an error:

Error: Invalid value for variable

Environment must be dev, staging, or prod.

Step 11: Clean Up

terraform destroy

📋 Variable Best Practices

✅ DO:

1. Use descriptive names

    variable "vpc_cidr_block" {}  # ✅ Clear
    variable "cidr" {}             # ❌ Vague
   

2. Always add descriptions

    variable "region" {
      description = "AWS region for all resources"
      type        = string
    }
   

3. Specify types explicitly

    variable "count" {
      type = number  # ✅ Explicit
    }
   

4. Use validation when appropriate

    validation {
      condition     = var.instance_count > 0
      error_message = "Must be positive."
    }
   

5. Group-related variables

    # Network variables
    variable "vpc_cidr" {}
    variable "subnet_cidrs" {}
   
    # Compute variables
    variable "instance_type" {}
    variable "instance_count" {}
   

❌ DON’T:

1. Don’t hardcode sensitive values

2. Don’t use overly complex variable structures

3. Don’t skip documentation

4. Don’t use inconsistent naming

📝 Summary

Today you learned:

• ✅ Input variables and their importance

• ✅ All variable types (string, number, bool, list, map, object)

• ✅ Variable definition precedence

• ✅ Multiple ways to set variable values

• ✅ Variable validation

• ✅ Output values and their uses

• ✅ Built parameterized, reusable infrastructure

🚀 Tomorrow’s Preview

Day 5: Resource Dependencies & Data Sources

Tomorrow we’ll:

• Understand implicit vs explicit dependencies

• Learn about depends_on

• Master data sources to query existing infrastructure

• Reference external resources

• Build complex interdependent infrastructure

💭 Challenge Exercise

Create a production.tfvars file that:

1. Uses a different VPC CIDR (172.16.0.0/16)

2. Creates 3 subnets instead of 2

3. Sets environment to “prod”

4. Adds a custom tag “CostCenter = Production”

Then apply it:

terraform apply -var-file="production.tfvars"

Happy Learning! 🎉

Thanks For Reading, Follow Me For More and subscribe youtube channel for the recap videos

Have a great day!..

← Day 3: Understanding Providers | Day 5: Dependencies & Data Sources →

Remember: Variables make your Terraform code reusable, flexible, and maintainable!