DEV Community: Emmanuel E. Ebenezer

Stop Creating Everything: The Art of Terraform Data Sources

Emmanuel E. Ebenezer — Mon, 08 Dec 2025 00:09:36 +0000

It's Day 13 of the AWS Challenge, and today I learned something that reshaped my perspective of Infrastructure as Code: You don't have to manage everything.

Up until now, every Terraform practice I've done was about creating resources. VPCs? Create them. Subnets? Create them. Security groups? Create them all! But in industry practice, especially in companies with multiple teams, you can't just create everything from scratch. The networking team already built the VPC. The security team manages the security groups. Your job is to deploy your app into existing infrastructure.

That's where data sources come in, and they're absolutely game-changing.

Hey, I'm learning terraform within 30 days. Or at least I'm trying to. You too can join the challenge.

Resources vs. Data Sources

Here's the fundamental difference that took me way too long to understand:

Resource Block = "I own this. I manage its entire lifecycle."

resource "aws_vpc" "my_vpc" {
  cidr_block = "10.0.0.0/16"
  # Terraform creates, updates, and destroys this
}

Data Block = "This already exists. I just need to reference it."

data "aws_vpc" "existing_vpc" {
  filter {
    name   = "tag:Name"
    values = ["shared-network-vpc"]
  }
  # Terraform just reads this, never touches it
}

That's it. That's the whole concept. But the implications are huge.

Why This Matters: The Multi-Team Reality

Let me paint a realistic scenario:

Your company has:

A networking team that manages all VPCs and subnets
A security team that maintains security groups and IAM policies
An infrastructure team (that's you!) that deploys applications

Without data sources:
You'd either need:

Access to everyone's Terraform state files (good luck with that)
Manually copy-paste IDs everywhere
Create duplicate resources (definitely calling for chaous)

With data sources:
You just query what you need:

# Find the VPC the cloud networking team created
data "aws_vpc" "company_vpc" {
  filter {
    name   = "tag:ManagedBy"
    values = ["cloud-networking-team"]
  }
}

# Find the security group the security team manages
data "aws_security_group" "approved_sg" {
  filter {
    name   = "tag:ManagedBy"
    values = ["security-team"]
  }
}

# Deploy your app using their infrastructure
resource "aws_instance" "my_app" {
  ami           = data.aws_ami.latest_amazon_linux.id
  subnet_id     = data.aws_subnet.app_subnet.id
  vpc_security_group_ids = [data.aws_security_group.approved_sg.id]

  # Your app, their infrastructure. Perfect harmony.
}

Beautiful. Clean. No stepping on anyone's toes.

My Hands-On Demo: The Three Essential Data Sources

I worked through a scenario that simulates practical infrastructure sharing. Here's what I built:

Setup: Simulating Existing Infrastructure

First, I created "existing" infrastructure (pretending another team already did this):

# This simulates what the networking team already deployed
resource "aws_vpc" "shared" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "shared-network-vpc"  # ← This tag is key!
  }
}

resource "aws_subnet" "shared" {
  vpc_id     = aws_vpc.shared.id
  cidr_block = "10.0.1.0/24"
  tags = {
    Name = "shared-primary-subnet"  # ← This too!
  }
}

After deploying this, I pretended to forget it exists lol (as you do in large organizations).

Data Source #1: Finding the VPC

Now, from a completely separate Terraform configuration, I need to deploy an EC2 instance into that VPC. Here's how I find it:

data "aws_vpc" "shared" {
  filter {
    name   = "tag:Name"
    values = ["shared-network-vpc"]
  }
}

What this does:

Queries AWS for a VPC with that specific tag
Returns the VPC ID, CIDR block, and all other attributes
Updates every time I run Terraform (always fresh data)

Pro tip: I tested this in terraform console before using it:

terraform console
> data.aws_vpc.shared.id
"vpc-0a1b2c3d4e5f6"
> data.aws_vpc.shared.cidr_block
"10.0.0.0/16"

Seeing real AWS data returned in real-time? muah... to my fingers

Data Source #2: Finding the Subnet (Chained!)

Now I need the subnet. But wait—there might be multiple subnets. I can narrow it down by both tag AND VPC:

data "aws_subnet" "shared" {
  filter {
    name   = "tag:Name"
    values = ["shared-primary-subnet"]
  }
  vpc_id = data.aws_vpc.shared.id  # ← Using the first data source!
}

What I learned:

You can chain data sources (use one to refine another)
The vpc_id parameter narrows the search
This prevents grabbing the wrong subnet if multiple have similar names

Data Source #3: Latest AMI (The Dynamic One)

Instead of hardcoding an AMI ID (which goes stale), I can dynamically fetch the latest approved AMI:

data "aws_ami" "amazon_linux_2" {
  most_recent = true
  owners      = ["amazon"]  # Only official Amazon AMIs

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

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

Why this is brilliant:

most_recent = true always grabs the newest matching AMI
Wildcards (*) allow flexible pattern matching
Multiple filters ensure you get exactly what you want
Your instances automatically use the latest AMI on next deploy

No more "Oops, I'm using an AMI from 2019."

Putting It All Together: The Final Resource

Now I use all three data sources to deploy my EC2 instance:

resource "aws_instance" "main" {
  ami           = data.aws_ami.amazon_linux_2.id           # ← Data source
  instance_type = "t2.micro"
  subnet_id     = data.aws_subnet.shared.id                # ← Data source
  private_ip    = "10.0.1.50"

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

When I ran terraform plan:

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

Only 1 resource being created! The VPC and subnet aren't in the plan because Terraform isn't managing them. It's just referencing them.

This is the magic. One configuration, seamless integration with existing infrastructure.

The Power Move: Terraform Console Testing

Before you deploy anything, you can test your data sources in the console:

terraform console

# Test VPC data source
> data.aws_vpc.shared.id
"vpc-0a1b2c3d4e5f6"

# Test subnet data source
> data.aws_subnet.shared.cidr_block
"10.0.1.0/24"

# Test AMI data source
> data.aws_ami.amazon_linux_2.name
"amzn2-ami-hvm-2.0.20231218.0-x86_64-gp2"

You can see actual AWS data, verify your filters work, and confirm everything before you deploy.

Common Data Sources You'll Actually Use

After doing this demo, I researched what data sources are most useful in real projects. Here's my cheat sheet:

Network Resources

# VPC lookup
data "aws_vpc" "main" { ... }

# Subnet lookup
data "aws_subnet" "main" { ... }

# Security Group lookup
data "aws_security_group" "main" { ... }

# All availability zones in current region
data "aws_availability_zones" "available" {
  state = "available"
}

Compute Resources

# Latest AMI (super common)
data "aws_ami" "latest" { ... }

# Existing EC2 instance
data "aws_instance" "main" { ... }

Identity & Metadata

# Current AWS account ID
data "aws_caller_identity" "current" {}

# Current AWS region
data "aws_region" "current" {}

# Example usage:
# "My account is ${data.aws_caller_identity.current.account_id}"
# "I'm deploying to ${data.aws_region.current.name}"

Storage

# S3 Bucket lookup
data "aws_s3_bucket" "main" { ... }

# RDS Instance lookup
data "aws_db_instance" "main" { ... }

Industry Practice Patterns I Discovered

Pattern 1: Tag-Based Discovery

Best practice: Use consistent, unique tags

data "aws_vpc" "main" {
  filter {
    name   = "tag:Environment"
    values = ["production"]
  }
  filter {
    name   = "tag:ManagedBy"
    values = ["networking-team"]
  }
}

Why multiple filters? Precision. One filter might match multiple resources. Two or three? Much more specific.

Pattern 2: ID-Based Lookup (When You Have It)

If you know the exact ID, use it:

data "aws_vpc" "main" {
  id = "vpc-12345678"
}

Pros: Fast, precise, no ambiguity
Cons: Less flexible, harder to maintain if IDs change

Pattern 3: Fallback Values

What if the data source doesn't find anything? Use try():

locals {
  vpc_id = try(data.aws_vpc.shared.id, var.default_vpc_id)
}

This gives you a safety net.

The Bigger Picture: Why This Matters

After today, I finally understand how Terraform works in an ideal Engineering Department:

Team A (Networking):

Manages VPCs, subnets, route tables
Tags everything consistently
Provides documentation of available resources

Team B (Security):

Manages security groups, IAM policies
Creates "approved" security group templates
Tags them for easy discovery

Team C (Applications):

Uses data sources to find Team A's VPCs
Uses data sources to find Team B's security groups
Deploys apps without touching core infrastructure
Everyone stays in their lane, no conflicts

This is collaborative Infrastructure as Code. Not just "my infrastructure," but "our infrastructure, properly managed."

Key Takeaways

Data sources read, resources manage. Know the difference, use them appropriately.
Tag everything meaningfully. Your future self (and your teammates) will thank you.
Test in terraform console. Verify your data sources work before deploying.
Use multiple filters for precision. One tag might match multiple resources; two or three gets specific.
Data sources query every run. They always reflect current AWS state, unlike hardcoded IDs.
Chain data sources. Use one to refine another for precise targeting.
Always fetch latest AMIs dynamically. Never hardcode AMI IDs; they go stale.

What's Next?

Tomorrow (Day 14), I'll be building a mini project to test the waters with my terraform knowledge.

The pieces are coming together. Functions make your code intelligent. Data sources connect you to existing infrastructure.

This is getting really good.

See yaa! (And seriously, go use terraform console to explore your AWS account. It's like having X-ray vision for your infrastructure.)

Terraform Functions: Where Your Infrastructure Gets Superpowers

Emmanuel E. Ebenezer — Sun, 07 Dec 2025 23:31:42 +0000

It's Day 11 and 12, because honestly, there's just too much good stuff here and it needed two full days of the AWS 30 days Challenge, and I'm not gonna lie, I almost skipped this topic. "Functions? That sounds familiar," I thought. "I'll just Google them when I need them."

Turns out, Terraform's built-in functions are like discovering your car has turbo boost after driving it in first gear for months. These aren't just "nice-to-haves"—they're the difference between writing 500 lines of hacky code and writing 50 lines of elegant, production-ready infrastructure.

Hey, I'm learning terraform within 30 days. Or at least I'm trying to. You too can join the challenge.

Part one:

Part two:

I spent two full days working through 12 hands-on assignments covering every most used function category, and my mind was blown multiple times. Here's what I learned (and why you absolutely need to know this stuff).

Why Functions Matter: A Reality Check

Before diving in, let me paint a picture. You're trying to:

Name an S3 bucket, but AWS won't accept uppercase letters or underscores
Merge tags from three different sources without overwriting important values
Split a comma-separated string of ports into actual security group rules
Validate that instance types match your company's naming convention
Format timestamps so your backup tags don't look like garbage

Without functions? You're copying Stack Overflow code, praying it works, and crying into your keyboard at 2 AM.

With functions? You write one line that does exactly what you need. Clean. Elegant. Chef's kiss.

The Terraform Console: My New Best Friend

First things first, before you touch main.tf, you need to know about terraform console. It's an interactive shell where you can test functions without deploying anything.

terraform console

Then you can just... play:

> lower("HELLO WORLD")
"hello world"

> max(5, 12, 9)
12

> split(",", "80,443,8080")
[
  "80",
  "443",
  "8080",
]

> reverse(["a", "b", "c"])
[
  "c",
  "b",
  "a",
]

This is game-changing. No more "deploy and pray." You test your logic in the console, then drop it into your config.

The 12 Assignments: My Greatest Hits

I worked through 12 practical assignments, each focusing on possible cloud ops scenarios. Here are the ones that completely changed how I think about Terraform:

Assignment 1: Project Naming (String Functions)

The Problem: You have "Project ALPHA Resource" but AWS resources need lowercase, hyphenated names like "project-alpha-resource".

The Solution:

locals {
  clean_name = lower(replace(var.project_name, " ", "-"))
}

resource "aws_resourcegroups_group" "project" {
  name = local.clean_name
}

What I learned: lower() and replace() are your bread and butter. You'll use these constantly for naming conventions.

Assignment 3: S3 Bucket Naming (String Acrobatics)

This one was chef's kiss because S3 buckets are picky. They want:

Lowercase only
No underscores
No special characters
3-63 characters max

The Problem: Your input is "My_Super-Awesome-Bucket!!!!" (yeah, users are wild).

The Solution:

locals {
  sanitized_bucket_name = substr(
    lower(
      replace(
        replace(var.bucket_name_input, "_", "-"),
        "/[^a-z0-9-]/", ""
      )
    ),
    0, 63
  )
}

What I learned: Functions nest beautifully. Read from inside out, replace underscores, strip invalid chars, lowercase everything, then truncate. One expression solves it all.

Assignment 4: Security Group Ports (Collections Are Magic)

The Problem: Your variable is a string: "80,443,8080". You need actual security group ingress rules.

Without functions:

# Manually create three ingress blocks
# Copy-paste hell
# Cry when you need to add port 3000

With functions:

variable "allowed_ports" {
  default = "80,443,8080"
}

locals {
  ports_list = split(",", var.allowed_ports)
}

resource "aws_security_group" "web" {
  name = "web-sg"

  dynamic "ingress" {
    for_each = local.ports_list
    content {
      from_port   = tonumber(ingress.value)
      to_port     = tonumber(ingress.value)
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }
  }
}

What I learned: split() turns strings into lists. Combine it with dynamic blocks (from yesterday!), and you've got data-driven security groups. Add a port? Change the variable. Done.

Assignment 5: Environment Lookup (The Decision Maker)

The Problem: Different environments need different instance sizes. Dev gets t3.micro, prod gets t3.large.

The Old Way: Multiple terraform.tfvars files, or worse, separate directories per environment.

The Function Way:

variable "environment" {
  default = "dev"
}

locals {
  instance_types = {
    dev     = "t3.micro"
    staging = "t3.small"
    prod    = "t3.large"
  }

  selected_type = lookup(local.instance_types, var.environment, "t3.micro")
}

resource "aws_instance" "app" {
  ami           = var.ami_id
  instance_type = local.selected_type
}

What I learned: lookup() is conditional expressions on steroids. Give it a map and a key, it returns the value. Give it a fallback, and you've got safety built in. One config, infinite environments.

Assignment 6: Instance Validation (The Validator)

This one blew my mind. You can validate inputs before deploying.

The Problem: Your company requires instance types to match pattern: t3.* or t2.* only.

The Solution:

variable "instance_type" {
  type = string

  validation {
    condition = can(regex("^(t2|t3)\\.", var.instance_type))
    error_message = "Instance type must start with 't2.' or 't3.'"
  }
}

What I learned:

can() tries an expression and returns true/false instead of erroring
regex() validates patterns
length() checks counts
Combine them in validation blocks to catch mistakes before you deploy

No more "oops, I deployed a c5.24xlarge in dev and my AWS bill is now a mortgage payment."

Assignment 7: Backup Configuration (Sensitive Data)

The Problem: You're handling database passwords and backup configs. You need validation AND security.

The Solution:

variable "backup_name" {
  type = string

  validation {
    condition     = endswith(var.backup_name, "-backup")
    error_message = "Backup name must end with '-backup'"
  }
}

variable "db_password" {
  type      = string
  sensitive = true
}

output "backup_info" {
  value = {
    name     = var.backup_name
    password = sensitive(var.db_password)
  }
  sensitive = true
}

What I learned:

endswith() (and startswith()) validate naming conventions
sensitive() marks values so they don't appear in logs or console output
Terraform respects your secrets if you tell it to

Assignment 10: Cost Calculation (Math That Actually Works)

The Problem: You have monthly costs and credits. You need to calculate actual bills.

variable "monthly_costs" {
  default = [120.50, 85.00, 200.75, 50.00]
}

variable "credit" {
  default = -50.00  # Negative credit
}

locals {
  total_cost       = sum(var.monthly_costs)
  actual_credit    = abs(var.credit)
  final_cost       = max(local.total_cost - local.actual_credit, 0)
  highest_cost     = max(var.monthly_costs...)
}

output "cost_summary" {
  value = {
    total_before_credit = local.total_cost
    credit_applied      = local.actual_credit
    final_bill          = local.final_cost
    highest_single_cost = local.highest_cost
  }
}

What I learned:

sum() adds all list elements
abs() converts negatives to positives
max() finds the highest value (or ensures non-negative results)
The ... operator unpacks lists

Math in Terraform actually makes sense!

Assignment 11: Timestamp Management (Time Flies)

The Problem: You need timestamps for backup tags and resource naming.

locals {
  current_time = timestamp()

  formatted_tags = {
    CreatedAt    = formatdate("YYYY-MM-DD hh:mm:ss ZZZ", local.current_time)
    BackupDate   = formatdate("YYYY-MM-DD", local.current_time)
    Year         = formatdate("YYYY", local.current_time)
  }
}

resource "aws_s3_bucket" "backups" {
  bucket = "backups-${formatdate("YYYY-MM-DD", timestamp())}"

  tags = local.formatted_tags
}

What I learned:

timestamp() gets current UTC time
formatdate() formats it however you want
Perfect for backup naming and audit tags

Assignment 12: File Content Handling (The JSON Master)

This was the final boss—reading JSON configs and storing them in AWS Secrets Manager.

The Problem: You have a config file with database credentials. You need to read it and store it securely.

The Solution:

locals {
  # Check if file exists
  config_exists = fileexists("${path.module}/config/database.json")

  # Read and parse JSON
  db_config = jsondecode(file("${path.module}/config/database.json"))
}

resource "aws_secretsmanager_secret" "db_credentials" {
  name = "database-credentials"
}

resource "aws_secretsmanager_secret_version" "db_credentials" {
  secret_id     = aws_secretsmanager_secret.db_credentials.id
  secret_string = jsonencode(local.db_config)
}

What I learned:

fileexists() checks before reading (no crashes!)
file() reads file contents
jsondecode() parses JSON into Terraform objects
jsonencode() converts back to JSON strings
You can manage external configs elegantly

The Function Categories That Matter Most

After working through everything, here's my personal ranking of function categories by usefulness:

Tier 1 (Use Daily):

String Functions: lower(), upper(), replace(), trim(), split(), join()
Collection Functions: length(), concat(), merge(), toset()
Lookup Functions: lookup(), element()

Tier 2 (Use less frequently):

Validation Functions: can(), regex(), contains()
Type Conversion: tonumber(), tostring(), tolist()
Numeric Functions: max(), min(), sum()

Tier 3 (Use When Needed):

File Functions: file(), fileexists(), dirname()
Date/Time Functions: timestamp(), formatdate()
Encoding Functions: jsondecode(), jsonencode(), base64encode()

The "Aha!" Moment

The real breakthrough came when I realized: Terraform functions turn static configs into intelligent, adaptive infrastructure.

Before functions, all my configs were rigid from day01. If I needed a change, I edited code. If I needed environment differences, I copied files. It was Infrastructure as Code, but it was dumb code.

After understanding terraform functions, my configs are becoming smart. They validate inputs, handle edge cases, adapt to environments, and gracefully handle changes. This is Infrastructure as Intelligent Code.

What's Next?

Tomorrow (Day 13), I'm diving into Terraform Data Sources and honestly, after learning functions, this is perfect timing. Data sources let you query existing infrastructure (like "what VPCs do I already have?" or "what's the latest AMI?"), and now that I know how to manipulate and validate data with functions, I can actually do something intelligent with those queries.

Also, I'm starting to see how all these concepts connect:

Day 9 (Lifecycle): Control how resources change
Day 10 (Expressions): Make configs adaptive
Day 11-12 (Functions): Make configs intelligent
Day 13 (Data Sources): Query and integrate existing infrastructure

This is all building toward something bigger, and I'm here for it.

See yaa! (And seriously, open that Terraform console and just... play. You'll thank me.)

Write Once, Deploy Everywhere: Mastering Terraform's Expression Toolkit

Emmanuel E. Ebenezer — Sun, 07 Dec 2025 22:56:43 +0000

It's Day 10 of the AWS Challenge, and today I'm exploring the features that transform Terraform from a simple declarative tool into a flexible, intelligent configuration powerhouse. If yesterday's lifecycle meta-arguments were about surgical control, today's expressions are about surgical precision with maximum reusability.

I'm talking about Conditional Expressions, Dynamic Blocks, and Splat (Funny thing is.... I called that word seplat and spelled it seplat in my previous blogs...) Expressions, the trio that eliminates code duplication and makes your infrastructure truly adaptable across environments.

Hey, I'm learning terraform within 30 days. Or at least I'm trying to. You too can join the challenge.

Here's how these three expression types became game-changers in my infrastructure code.

1. Conditional Expressions: Decision-Making in Your Config

Think of conditional expressions as the if-else statements of Terraform. They let you make intelligent decisions right in your configuration without duplicating entire files.

The Syntax:

condition ? true_value : false_value

How it works: Terraform evaluates the condition. If true, it uses the first value; if false, it uses the second. Simple, but incredibly powerful.

Real-World Example:

resource "aws_instance" "app_server" {
  ami           = var.ami
  instance_type = var.environment == "production" ? "t3.large" : "t3.micro"

  monitoring = var.environment == "production" ? true : false

  tags = {
    Name        = "${var.environment}-app-server"
    Environment = var.environment
    CostCenter  = var.environment == "production" ? "prod-ops" : "dev-team"
  }
}

In this example, production gets beefier instances with monitoring enabled, while dev environments stay lean. One configuration, multiple environments, no code duplication.

Use Cases:

Selecting instance sizes based on environment
Enabling expensive features (like enhanced monitoring) only in production
Choosing different AMIs per region
Setting resource counts (scale production higher than dev)
Applying environment-specific security policies

Pro Tip: Don't nest these too deeply. If you find yourself chaining multiple ternary operators, use locals blocks to break down the logic into readable chunks.

2. Dynamic Blocks: The Code Duplication Killer

This is where Terraform goes from good to great. Dynamic blocks let you generate multiple nested blocks from a single definition. If you've ever copied and pasted the same ingress rule 10 times in a security group, this is your salvation.

The Syntax:

dynamic "block_name" {
  for_each = var.collection
  content {
    # Configuration using block_name.value
  }
}

You might be asking why not just using for_each tf meta argument? The reason is for_each works only at a resources level but dynamic blocks helps to make the arguments for resouces flexible.
How it works: The for_each argument takes a list or map and iterates over it. For each item, Terraform generates a complete block using the template in the content section.

Real-World Example: Security Group Rules

Instead of this nightmare:

resource "aws_security_group" "app_sg" {
  name = "app-security-group"

  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"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]
  }
  # ... and 7 more repeated blocks
}

You write this beauty:

variable "ingress_rules" {
  type = list(object({
    port        = number
    protocol    = string
    cidr_blocks = list(string)
    description = string
  }))
  default = [
    {
      port        = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
      description = "HTTP access"
    }...
  ]
}

resource "aws_security_group" "app_sg" {
  name = "app-security-group"

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

Why This is Brilliant:

Adding a new rule? Just add it to the variable, no code changes needed.
Environment-specific rules? Pass different lists per environment.
Want to disable all external access? Pass an empty list.
Need to audit all open ports? Check one variable instead of scattered code.

Other Powerful Use Cases:

Multiple EBS volumes attached to EC2 instances
IAM policy statements
Route table routes
CloudWatch alarm actions
Any nested block that repeats with variation

Important: Dynamic blocks work for nested blocks within resources, not for creating multiple resources. For multiple resources, use count or for_each on the resource itself.

3. Splat Expressions: Data Extraction Made Elegant

Splat expressions are Terraform's way of saying "give me this attribute from every item in this list." The [*] operator is your friend here.

The Syntax:

resource_list[*].attribute_name

How it works: Instead of writing a loop to extract values, you use [*] to tell Terraform "get this attribute from all elements."

Real-World Example:

resource "aws_instance" "web_servers" {
  count         = 3
  ami           = var.ami_id
  instance_type = "t3.micro"

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

# Output all instance IDs in one line
output "instance_ids" {
  value = aws_instance.web_servers[*].id
}

# Output all private IPs
output "private_ips" {
  value = aws_instance.web_servers[*].private_ip
}

# Use those IPs in another resource
resource "aws_lb_target_group_attachment" "web" {
  count            = length(aws_instance.web_servers)
  target_group_arn = aws_lb_target_group.web.arn
  target_id        = aws_instance.web_servers[*].id[count.index]
}

Without splat expressions, you'd need a complex for loop or repeated code. With them, it's one elegant line.

Common Use Cases:

Extracting IDs from multiple EC2 instances for use in other resources
Collecting all subnet IDs from a VPC data source
Getting security group IDs to attach to resources
Gathering ARNs for IAM policies
Building lists for outputs and dependencies

Pro Tip: Combine splat with other functions like join() for even more power:

output "all_ips_comma_separated" {
  value = join(",", aws_instance.web_servers[*].private_ip)
}

Bringing It All Together: A Real-World Scenario

Here's how these three expressions work together in a production-grade configuration:

variable "environment" {
  type = string
}

variable "ingress_rules" {
  type = map(object({
    port        = number
    cidr_blocks = list(string)
  }))
}

# Conditional: Different instance types per environment
resource "aws_instace" "app" {
  count         = var.environment == "production" ? 3 : 1
  ami           = var.ami_id
  instance_type = var.environment == "production" ? "t3.large" : "t3.micro"

  vpc_security_group_ids = [aws_security_group.app.id]

  tags = {
    Name        = "${var.environment}-app-${count.index}"
    Environment = var.environment
  }
}

# Dynamic: Generate security rules from variable
resource "aws_security_group" "app" {
  name = "${var.environment}-app-sg"

  dynamic "ingress" {
    for_each = var.ingress_rules
    content {
      from_port   = ingress.value.port
      to_port     = ingress.value.port
      protocol    = "tcp"
      cidr_blocks = ingress.value.cidr_blocks
    }
  }
}

# Splat: Extract all instance IDs for output
output "instance_ids" {
  description = "IDs of all app instances"
  value       = aws_instance.app[*].id
}

# Splat: Get all private IPs for configuration
output "private_ips" {
  description = "Private IPs for load balancer config"
  value       = aws_instance.app[*].private_ip
}

My key Takeaways

Conditional Expressions give you environment-aware configurations without file duplication. One codebase, infinite environments (maybe lol).
Dynamic Blocks eliminate the pain of repetitive nested blocks. Your security groups and policies become data-driven and maintainable.
Splat Expressions make data extraction effortless. No more loops or complex logic to grab attributes from multiple resources.
Together, these expressions transform Terraform from a declarative tool into an intelligent, flexible infrastructure-as-code platform. I think they're the difference between maintaining 5 separate environment configs and maintaining one adaptive configuration that scales with your needs, the industry might say different but let me enjoy the joy of the new knowledge while I can.
Tomorrow's topic dives into Terraform's built-in functions where I'll unlock even more power for data manipulation and transformation giving me that full programming experience. See yaa!

Level Up Your Infrastructure: Mastering Terraform's Lifecycle Meta-arguments

Emmanuel E. Ebenezer — Sun, 07 Dec 2025 22:27:04 +0000

It’s Day 9 of the AWS Challenge, well.... for me lol, and today’s focus is based yesterdays topic, Terraform metadata. However it's a deep dive to all about controlling one of the most critical aspects of Infrastructure as Code: the resource lifecycle.

Terraform’s default behavior is great, but when you're managing production systems, you need surgical precision. That’s where the six powerful lifecycle meta-arguments come in. These are the tools that let you enforce zero-downtime updates, protect your critical data, and handle complex hybrid management scenarios.

Hey, I'm learning terraform within 30days. Or at least I'm trying to. You too can join the challenge.

Here's a breakdown of the six arguments that are now firmly in my IaC toolkit.

create_before_destroy: The zero-downtime hero. Terraform's default is to destroy the old resource, then create the new one. This causes a service interruption—a big no for production.

The create_before_destroy argument flips this process.

How it works: Terraform creates the new resource first, updates dependencies (like a load balancer's target group), and then destroys the old one.
Use Case: Essential for zero-downtime deployments of resources behind a load balancer, such as EC2 instances or RDS instances with read replicas. This enables a simple, automated blue/green deployment strategy.

  resource "aws_instance" "blog_server" {
    #... resource arguments
    lifecycle {
      create_before_destroy = true
    }
  }

prevent_destroy: The Production Guardrail This is perhaps the most crucial safety feature. If you have a resource that should never be accidentally deleted—like your production database or a critical S3 bucket containing sensitive data—you must use this.

How it works: Setting this to true will cause any terraform destroy command that targets the resource to fail with an error.
Use Case: Protecting stateful resources like RDS, critical S3 buckets, and your ECR/EC2 key pairs. It forces a deliberate manual step (temporarily commenting it out) before a deletion can occur.

  resource "aws_resource_example" "blog_server" {
      #... arguments
      lifecycle {
      prevent_destroy = true
    }
  }

Infrastructure often isn't managed solely by Terraform. Auto-scaling, external monitoring tools, and even other teams can modify resources.

ignore_changes: Accepting External Management Configuration drift is a nightmare. It happens when an external system (or person) changes a resource attribute, and Terraform constantly tries to revert it on the next run.

How it works: You tell Terraform to stop caring about changes to specific attributes.

Use Case: Ignoring changes to an Auto Scaling Group's desired_capacity (as it's managed by scaling policies) or EC2 instance tags added by a monitoring agent.

  resource "aws_resource_example" "blog_server" {
      #... arguments
    lifecycle {
      ignore_changes = [
      desired_capacity,
      tags
      ]
    }
}

replace_triggered_by: Forced Replacement Sometimes a change in one resource doesn't automatically trigger a replacement of a dependent resource, even if it should. This argument enforces that link.

How it works: If the specified dependency resource is replaced, the resource containing this argument will also be replaced, even if its configuration hasn't changed.

Use Case: Forcing an EC2 instance to be re-created whenever its referenced Security Group changes. It’s excellent for enforcing immutable infrastructure patterns.

resource "aws_security_group" "app_sg" {
  #... arguments
}

resource "aws_instance" "app_with_sg" {
  # ..arguments
  vpc_security_group_ids = [aws_security_group.app_sg.id] #ref: app_sg

  # Lifecycle Rule: Replace instance when security group changes
  lifecycle {
    replace_triggered_by = [
      aws_security_group.app_sg.id
    ]
  }
}

Enforcing Policy with Validation

The final pair of arguments is all about validating your resources before and after deployment to enforce organizational standards.

precondition: Pre-Deployment Sanity Checks Why wait for a costly, time-consuming failure? You can validate deployment requirements before Terraform even starts building.

How it works: You define a condition (condition = ...) that must evaluate to true. If it's false, the deployment fails immediately with a custom error_message.

Use Case: Ensuring the deployed AWS region is in an approved list, or validating that a required environment variable is present in the configuration.

postcondition: Post-Deployment Verification After the resource is built, you can verify that it meets the required state and compliance standards.

How it works: Similar to precondition, but it runs after the resource has been created or updated. It can check the resource's final attributes (self.attribute).

Use Case: Verifying that a critical tag (like Compliance or Environment) was successfully applied to the resource, or checking that the output of a module is in the expected format.

They look something like this..

# ...placed inside a resource block
  resource "some_resource" "resource_ref_tf" {
    precondition {
      condition     = contains(keys(var.resource_tags), "Environment")
      error_message = "Critical table must have Environment tag for compliance!"
    }

    postcondition {
      condition     = self.billing_mode == "PAY_PER_REQUEST" || self.billing_mode == "PROVISIONED"
      error_message = "Billing mode must be either PAY_PER_REQUEST or PROVISIONED!"
    }
  }

Key Takeaway

The lifecycle block isn't a feature you use every day, but it’s absolutely non-negotiable for managing infrastructure at scale. It's the difference between a shaky, risky update process and a robust, collaborative, compliant, and zero-downtime deployment pipeline.

Tommorrow's topic excites me because it helps me achieve more flexibility with my Infrastructure configuration which is what code should feel like. see yaa.

Meta Arguments in Terraform: Transform the Behaviour of Resources

Emmanuel E. Ebenezer — Tue, 02 Dec 2025 14:26:21 +0000

Terraform meta arguments are resource arguments that can be used with any resource types to alter the default behavior of the resource. For instance a resource that is created once with normal arguments can be created 3 times with similar metadata by adding a meta argument count to the resource.

Today was chill, nice music and wonderful topic on the challenge, welcome to my series in #30DaysOfAwsTerraform, today, I learned about these Terraform meta arguments.

count - Create multiple resource instances based on a number

resource "aws_s3_bucket" "example" {
  count  = 3
  bucket = "my-bucket-${count.index}"
}

This creates N identical resources with unique names, in this case N is 3.
However, count has a key limitation:
👉 Terraform identifies resources by their index, not their value.

This results in address like:

aws_s3_bucket.example[0]
aws_s3_bucket.example[1]
aws_s3_bucket.example[2]

If you delete bucket ...example-[1] and reduce count from 3 to 2.

Terraform thinks [1] should still exist, it recreates it
Then deletes the last one, which is an unintended replacement.

This makes count fragile for production unless used carefully.

for_each - Create multiple resources with maps/sets

resource "aws_s3_bucket" "example" {
  for_each = toset(["bucket1", "bucket2", "bucket3"])
  bucket   = each.value
}

For each solves the count problem because resources are indexed by keys, not by numeric positions.

So deleting "bucket2" does not affect "bucket1" or "bucket3"
This is best for complex configurations, stable resource identities and large infrastructure.

depends_on - Explicit resource dependencies

resource "aws_s3_bucket" "dependent" {
  bucket = "my-bucket"

  depends_on = [aws_s3_bucket.primary]
}

This is useful for explicit resource ordering and extremely useful for ensuring resources are created in specific order.

lifecycle - Control resource creation and destruction behavior

resource "aws_s3_bucket" "example" {
  bucket = "my-bucket"

  lifecycle {
    prevent_destroy       = true  # Prevent accidental deletion
    create_before_destroy = true  # Create new before destroying old
    ignore_changes        = [tags] # Ignore changes to tags
  }
}

This meta argument is added to resources to protect them from deleted and any mishap that may affect it's existence. It can be used to control zero-downtime updates, ignore external changes to specific attributes and protect crititcal resources from deletion.

provider - Use alternate provider configurations

resource "aws_s3_bucket" "example" {
  provider = aws.west  # Use alternate provider
  bucket   = "my-bucket"
}

This can be useful for multi-region deployments and multi-provider setups. Resources can be configured using one terraform project and infrastructure would be provisioned based on the provider(credentials) used.

I also learned how to use the splat operator, it necessarily doesn't add any improvements in value but it makes it fun to write and interest to look at.

## This is fine
output "s3_bucket_arns_count" {
  description = "ARNs of S3 buckets created with count"
  value = [for bucket in aws_s3_bucket.task_count_buckets: bucket.arn]
}
## But we could use the seplat operator
output "s3_bucket_arns_count" {
  description = "ARNs of S3 buckets created with count"
  value       = aws_s3_bucket.task_count_buckets[*].arn
}

Tomorrow I'll be diving deep into Lifecyle meta argument to understand how to manage lifecyle better.

Hey you can follow along with the challenge, Learn with amazing people from CloudOps Community on discord.

What are variables in Terraform? And how do I arrange my files?

Emmanuel E. Ebenezer — Mon, 01 Dec 2025 06:12:59 +0000

Variables are a fundamental concept in every programming language because they are useful in building dynamic programs. We use variables to store temporary or "permanent" values so they can assist programming logic in simple as well as complex programs.

The result of an expression is a value. All values have a type, which dictates where that value can be used and what transformations can be applied to it. Well said by Hashicorp.

Welcome to my day05-07 in #30DaysOfAwsTerraform and in this post, we discuss the types of Variables in Terraform, how they are used and how to setup of Terraform directory for clean configurations.

Terraform variables are essential for building, scalable, highly maintainable and adaptable infrastructure configurations, effectively contributing efficient infrastructure management and deployment practices.

Let's dive in.

Variables day05

Variables can be categorized based on these two categories:

Based on Purpose:
- Input: these variables serve as parameters for your Terraform modules, allowing you to customize configurations without changing the source code. They make your code reusable and flexible.
  Example:
  The input variable is declared with the variable block, and used in the resource block.
```
variable "environment" {
    description = "Environment name"
    type        = string
}

resource "aws_instance" "web" {
    ami           = "ami-12345678"
    instance_type = var.instance_type

    tags = {
        Environment = var.environment
    }
}
```
- Output variables export values from your module, making them available for other configurations or displaying important information after deployment.
  
  Example: this values will be printed by default to the console after terraform applies the desired configurations
```
output "instance_public_ip" {
description = "Public IP of the EC2 instance"
value       = aws_instance.web.public_ip
}

output "instance_id" {
description = "ID of the EC2 instance"
value       = aws_instance.web.id
}
```
- Local Variables
  Locals are temporary values you define in Terraform to avoid repetition and clean up complex expressions. Terraform calculates them once when the configuration is evaluated, and you can reuse them anywhere.
  
  They differ from input variables in one important way:
  
  Input variables can be changed at runtime (through a dedicated variables file, CLI flags, workspaces, etc.).
  
  Locals cannot be changed at runtime — they are fixed inside the module and can only be derived from other values (including input variables). Terraform computes them after the plan starts and they cannot be overridden.
  
  In short:
  Variables are inputs. Locals are internal helpers.
  
  Example:
```
locals {
common_tags = {
    Project     = "MyApp"
    Environment = var.environment
    ManagedBy   = "Terraform"
}

instance_name = "${var.environment}-web-server"
}

# main.tf - Using locals
resource "aws_instance" "web" {
ami           = "ami-12345678"
instance_type = var.instance_type

tags = merge(
    local.common_tags,
    {
    Name = local.instance_name
    }
)
}
```

Variables Based on Values

Primitive Types

Simple, single-value data types
String:

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

Number:

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

Bool:

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

Complex Types

Structured data types that can hold multiple values.

List:

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

# Usage
resource "aws_subnet" "public" {
    count             = length(var.availability_zones)
    availability_zone = var.availability_zones[count.index]
    # ... other configuration
}

Map:

variable "instance_types" {
    type = map(string)
    default = {
        dev  = "t2.micro"
        prod = "t3.large"
    }
}

# Usage
resource "aws_instance" "app" {
    instance_type = var.instance_types[var.environment]
    # ... other configuration
}

Object:

variable "server_config" {
type = object({
    instance_type = string
    volume_size   = number
    enable_backup = bool
})

default = {
    instance_type = "t2.micro"
    volume_size   = 20
    enable_backup = true
}
}

# Usage
resource "aws_instance" "server" {
    instance_type = var.server_config.instance_type

    root_block_device {
        volume_size = var.server_config.volume_size
        }
}

Set:

variable "allowed_ports" {
    type    = set(number)
    default = [22, 80, 443]
}

# Usage
resource "aws_security_group_rule" "allow_ports" {
    for_each = var.allowed_ports

    type        = "ingress"
    from_port   = each.value
    to_port     = each.value
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
}

Any or Null Types

Any:

variable "custom_config" {
    description = "Flexible configuration that can accept any type"
    default     = {}
}

Nullable:

variable "backup_retention_days" {
    type    = number
    default = null  # Allows explicit null value
}

Hey, you can still join the #30DaysOfAwsTerraform. And learn Terraform on AWS for within 30 days.

Terraform Directory Structure, day06

With the knowledge of variables, we can intuitively separate terraform files for better management, instead of putting everything in a single .tf file.

A collection of .tf files is called a module (still more of this later in the series)
Terraform always runs in the context of a single root module. A complete Terraform configuration consists of a root module and the tree of child modules (which includes the modules called by the root module, any modules called by those modules, etc.). In Terraform CLI, the root module is the working directory where Terraform is invoked.

So a sample terraform project would look like this:

terraform-project/
├── main.tf           # Primary resource definitions
├── variables.tf      # Input variable declarations
├── outputs.tf        # Output variable declarations
├── locals.tf         # Local variable definitions
├── providers.tf      # Provider configurations
├── versions.tf       # Terraform and provider version constraints
├── terraform.tfvars  # Variable value assignments (not committed to git)
└── modules/
    └── networking/
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

This structure keeps your configurations organized, maintainable, and easy to navigate following good file organization principles

Separation of Concerns: Group related resources together
Logical Grouping: Organize by service or function
Consistent Naming: Use clear, descriptive file names
Modular Approach: Keep files focused on specific areas
Documentation: Include README and comments

I'm learning Terraform within 30days with Piyush. You can still join the challenge here.

Type Contraints day07

Because Terraform is mostly configuration files than logical programming, resources and terraform blocks need specific types of values, if not provided appropriately, the configuration would never work.

Common Type Patterns Include:

Environment-specific configurations
Resource sizing based on type
Tag standardization
Network configuration validation
Security policy enforcement

Best Practices for writing configuration files include

Always specify types for variables
Use validation blocks for business rules
Provide meaningful error messages
Use appropriate collection types (list vs set vs map)
Validate complex objects thoroughly
Use type conversion functions when needed
Document type requirements in descriptions

Comprehensive Example: VPC Configuration Variable

# variables.tf

variable "vpc_config" {
  description = "object configuration for a vpc"
  type = object({
    cidr_block         = string
    name               = string
    enable_dns         = bool
    environment        = string
    availability_zones = set(string)
    subnet_configs     = map(string)
  })
  validation {
    condition     = contains(["dev", "staging", "prod"], var.vpc_config.environment)
    error_message = "Environment must be one of: dev, staging, prod."
  }

# main.tf - Using the variable with type conversion

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_config.cidr_block
  enable_dns_hostnames = var.vpc_config.enable_dns
  enable_dns_support   = var.vpc_config.enable_dns

  tags = {
    Name        = var.vpc_config.name
    Environment = var.vpc_config.environment
    ManagedBy   = "Terraform"
  }
}

resource "aws_subnet" "subnets" {
  for_each = var.vpc_config.subnet_configs

  vpc_id            = aws_vpc.main.id
  cidr_block        = each.value
  availability_zone = element(tolist(var.vpc_config.availability_zones), index(keys(var.vpc_config.subnet_configs), each.key))

  tags = {
    Name        = each.key
    Environment = var.vpc_config.environment
  }
}

# terraform.tfvars - Example values

vpc_config = {
  cidr_block         = "10.0.0.0/16"
  name               = "my-production-vpc"
  enable_dns         = true
  environment        = "prod"
  availability_zones = ["us-east-1a", "us-east-1b", "us-east-1c"]
  subnet_configs = {
    "public-subnet-1"  = "10.0.1.0/24"
    "public-subnet-2"  = "10.0.2.0/24"
    "private-subnet-1" = "10.0.10.0/24"
    "private-subnet-2" = "10.0.11.0/24"
  }
}
## What This Example Demonstrates

1. Type specification: Complex `object()` type clearly defined
2. Validation block: validation for business rules
3. Meaningful error message: The validation explains what is wrong and how to fix it
4. Appropriate collections: `set` for unique AZs, `map` for subnet configs
5. Thorough validation: Validates nested object properties using `alltrue()` and loops
6. Type conversion: Uses `tolist()` and `element()` to convert set to list for indexing
7. Documentation: Detailed description with heredoc syntax explaining all requirements

This single variable enforces infrastructure standards while remaining flexible and well-documented!

It's been a wonderful weekend and I'm one more step closer to writing Terraform configurations that effective for deployment, and very explicit for collaborative development.

See you on the next one.

If you want to build infrastructure with code, join Piyush on Youtube and the CloudOps Community on discord.

Securing Your Infrastructure State on AWS with Terraform

Emmanuel E. Ebenezer — Fri, 28 Nov 2025 11:58:05 +0000

Every day of this #30DaysOfAwsTerraform challenge feels like peeling back another layer of how real infrastructure works. And honestly? The deeper I go, the more I realize how much engineering simply involves understanding where things live, when to move them and how to protect them.
Today was one of those “oh… this is serious” days.

Day 04 was all about understanding Terraform state; what it is, why it matters, and why storing it locally is basically an invitation for chaos.
My goal today was simple: move my state to a secure, "production-style" Terraform remote backend on AWS.

I started today thinking, “State file? Okay cool, it’s probably one of those files Terraform needs somewhere.”
Then I learned it contains sensitive configurations, IDs, metadata, resource secrets and the entire known state of my infrastructure. Basically, everything Terraform uses to decide what to create, update, or destroy.

That was the moment things got real.

Terraform literally compares your real infrastructure to your desired config every time you run plan, apply, or destroy.

If that state file gets corrupted or overwritten by someone else?

Terraform will make wrong assumptions.
Wrong assumptions = scary outcomes.

So keeping it locally felt… irresponsible. Especially if you work in a team of engineers.
It’s not like an .env file you just pass around, this state file should never be edited manually and must always be protected.

So how did I add a remote backend to Terraform?
A sample of this configuration.

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

  backend "s3" {
    bucket       = "terraform-state-1764317914"
    key          = "dev/terraform.tfstate"
    region       = "eu-west-3"
    use_lockfile = true
    encrypt      = true
    profile      = "<your aws profile for credentials>"
  }
}

Did you notice, the use_lockfile field. That field tells Terraform:
“Before you touch anything… lock the state.” This prevents anyone else from running updates until the process is finished — avoiding concurrent modifications.

The bucket (terraform-state-1764317914, always use a unique name for your buckets) needs to exist before Terraform initializes. I didn’t want to click through the console anymore lol, so I used a shell script to create it with secure configurations.
A sample of this shell script is below:

#!/bin/bash

BUCKET_NAME="terraform-state-$(date +%s)"
REGION="eu-west-3"
PROFILE="<your aws profile for credentials>"

aws s3 mb s3://$BUCKET_NAME --region $REGION --profile $PROFILE

aws s3api put-bucket-versioning --profile $PROFILE \
  --bucket $BUCKET_NAME \
  --versioning-configuration Status=Enabled

aws s3api put-bucket-encryption --profile $PROFILE \
  --bucket $BUCKET_NAME \
  --server-side-encryption-configuration '{
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "AES256"
        }
      }
    ]
  }'

echo "======================================"
echo "S3 Backend Setup Complete!"

Versioning + encryption are essential for state locking and security, so I made sure those were enabled immediately.

The biggest thing I walked way with today is the purpose of a remote state:

It keeps your infrastructure data safe
It prevents concurrent updates, if configured correctly.
It allows collaboration
And with s3 versioning, every change to the state file gets saved as a backup automatically

I also finally understand how terraform actually thinks... It's always reconciling my current infrastructure with the desired config. The state file is that source of truth.

Getting better at terraform feels really good, I getting really close to setting up a good production ready Infrastructure with code. Next, I'll be learning about Terraform Variables.

I’m still curious about:

deeper state management workflows
workspace organization

and how teams structure their Terraform environments.
On to the day05.

Join in the challenge to learn terraform in 30days. Or at least try.

How to provision an S3 storage with an Implicit Dependency to VPC on AWS

Emmanuel E. Ebenezer — Thu, 27 Nov 2025 10:52:27 +0000

The four-step or should I say, two-step ritual every engineer configuring infrastructure eventually lives by.

In my previous posts, we explored what Terraform is, why it matters, its components, how to install it, and how to prepare it for real use.
Now it’s time to actually use it. Today, we’ll be provisioning an object storage bucket on AWS — using code.

If you haven’t been following from the start, here are some helpful resources to get you up to speed (assuming you use a Linux system):
What is terraform
Install terraform
Get started with Terraform on AWS

Alright, let's dive in.
A quick overview of what we would be doing today.

First, create a folder and your Terraform configuration file.

mkdir tf-practice
cd tf-practice
touch main.tf

Before you go on, be sure to have aws credentials that would have access to the s3 resource.
Open main.tf with your favourite editor and paste this configuration.
Feel free to customise it using the documentation: S3 resource documentation.

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

}
provider "aws" {
    region = "eu-west-2"
    # profile = "<leave commented if you have only one aws profile>"
}
resource "aws_s3_bucket" "demo-resource-creation" {
  bucket = "<use a name you know nobody else would>"
  force_destroy = true

  tags = {
    Name        = "My bucket"
    Environment = "Demo"
  }
}

Now we create the resources.
Make sure you’re still in the folder we created (tf-practice) and you’ve installed Terraform properly.Then use the following commands to perform the infrastructure magic lol.

terraform plan

terraform apply

Approve the changes and…
Ta-daa! You’ve just provisioned an S3 bucket on AWS using code.

Here’s something fun to try: update the tags to see how Terraform tracks and manages resource changes.

resource "aws_vpc" "demo_vpc" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "demo-vpc"
  }
}

resource "aws_s3_bucket" "demo-resource-creation" {
  bucket = "<use a name you know nobody else would>"
  force_destroy = true

  tags = {
    Name        = "My bucket 2.0"
    Environment = "New Demo"
    VpcId       = aws_vpc.demo_vpc.id
  }
}

Run terraform apply again and check the AWS console, your updated tags should appear.
That still feels magical to me.

Now what do these commands do.

Terraform plan : A dry-run.It shows what Terraform will create, change, or destroy before it touches or changes anything.

Terraform apply: This is the command that tells Terraform to call the AWS API and actually create or update your resources.

And of course, my favourite command Terraform destroy.
It removes everything Terraform created, super helpful for cleaning up and avoiding unnecessary cloud bills.

When you are satisfied with the newly ingested IaC wisdom, run terraform destroy to destroy our practice s3 bucket.

Learning this was genuinely exciting, and sharing it feels even better.
When I think about how software blends with infrastructure, and the kinds of tools I'd to build for cloud operations someday, understanding this flow helps shape my wild imaginations.

Hey, I'm upskilling with Piyush and the CloudOps Community on discord.

Thank you for reading and see ya tomorrow.

Terraform Provider Deep Dive

Emmanuel E. Ebenezer — Wed, 26 Nov 2025 10:05:02 +0000

Without a provider, Terraform is useless.
Welcome to day 2 of the #30daysofawsterraform challenge!
By the end of this post, you'll have an understanding of the most important conponent of terraform as an IaC tool, the provider.
If you already know the provider I guarantee you'll learn at least one new angle today, or provide me with one in the comments.
So ease in, let's dive.

Concepts to be aware of:

Registry: more common as a place were records a kept. In this case, we refer to a registry as a central location were providers and modules (more on modules soon) are published, versioned and downloaded.

Provider: plugins that allow Terraform to interact with target APIs: cloud platforms, Kubernetes, Docker, Saas/Paas APIs, etc. Each provider is versioned separately from Terraform Core. For AWS, we use the hashicorp/aws provider.

Terraform Core: The Terraform binary that processes .tf files, manages state and orchestrates the workflow.

A provider interpretes the .tf files for the target API. For example, when you deploy an object storage, whether clicking through the console, or using the CLI, you are ultimately talking to a cloud provider's APIs. Terraform lets you to declare the resources you want, and the provider communicates with the API to provision them.

Because Terraform Core and providers are developed by different teams and versioned separately, version compatibility is important for stability, reproducibility, and predictable behavior.

To ensure consistent versioning, version constraints are used:

= 1.2.3 - exact version
>= 1.2 - greater than or equal to
<= 1.2 - less than or equal to
~> 1.2 - pessimistic constraint (allow patch releases)
>= 1.2, < 2.0 - Range constraint (allow a range of versions)

Basic AWS Provider Setup

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

provider "aws" {
  region = "eu-west-2"
}

To know how these configuration blocks are structured, always refer to the provider's documentation on the registry: registry.terraform.io/providers/hashicorp/aws.
I love to treat documentation as the single source of truth and in some situations, the direct code, because LLM's are not always trained with the latest update. I know you can ask it to search the internet but reading documentation is a good skill to have you know.

Yes, you could have multiple providers in single Terraform configuration. As seen in this example, the random provider to generate random values is used with the aws provider.

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

After writing your terraform files, you run :

terraform init

init downloads providers from the registry, installs plugins, and prepares Terraform to interact with your configured APIs. Authentication happens during this process too.

To experience this hands-on, try the AWS Terraform tutorial here: get started

Hey, you can get the juice directly from the source

It feels great to finally understand how Terraform performs its magic behind the scenes.
One quick tip I use for AWS authentication is adding a profile field to provider block of the .tf file and it's value is the name of my profile. Your AWS credentials live in ~/.aws/config (assumming you use a linux OS), and you can login to and store your credentials with a named profile using this command

aws login --profile <profile-name>

Terraform respects that configuration too.
Good luck exploring Terraform and building your infrastructure with code!

Tomorrow, we’ll explore the rest of the Terraform workflow. We’ll look at the plan command, create actual resources, and understand how Terraform decides what to provision.

Cheers! And see you tomorrow.

No More Click Click Click

Emmanuel E. Ebenezer — Tue, 25 Nov 2025 09:00:25 +0000

I love programming and after exploring cloud and devops, I was almost giving up but terraform is sparking my interest again.

I think I’m one of the few people who actually enjoy a formal introduction to things. Today was my official introduction to Terraform. I explored why Terraform exists, the problems it solves, the old-school way people used to interact with cloud platforms, and why Infrastructure as Code matters in modern engineering.

If Terraform or IaC still sound new to you, here’s the simplest update: Infrastructure as Code is a way to create cloud resources using code instead of clicking around dashboards. Terraform is the most popular tool for this, letting you describe the infrastructure you want and then letting Terraform talk to the cloud provider on your behalf. Get started with terraform here.

This session felt more like discovering the idea behind Terraform rather than building something. I spent time understanding the workflow, the concepts, and why engineers rely on automation instead of manual actions.

The main thing I learned today was Terraform’s basic workflow:

terraform init - Set up the working directory
terraform validate - Check for syntax and configuration issues
terraform plan - Preview what changes Terraform will make
terraform apply - Execute the plan and create/update resourcesstate
terraform destroy - Remove infrastructure when you no longer need it

terraform destroy is my favorite for now. It feels like giving orders to tiny minions that quickly tear down everything so you don’t accidentally keep resources running and racking up costs.

I clearly understand that IaC tools are basically talking to cloud APIs for us. And with that, you can create repeatable, scalable infrastructure without the stress of manual setup.

Piyush, my wonderful instructor whom I recently encounted on youtube, explained this in a way that clicks for me.
You can check out his video.

And if you like a supportive learning environment, the cloudops community is worth joining. It’s full of motivated engineers, learners, and enthusiasts.

It's a 30 day challenge to learn and use terraform and I’m doing this challenge to improve my Terraform and AWS skills, but also to sharpen my writing. I’m excited to look back at the end and see how far I’ve come.

Today I've just known about terraform. and talked about it and it's possibilites. Tomorrow we plan on provisioning some infrastructure with it. I'd love to see the magic. I'll command, apply! and watch how the infrastructure comes alive. Join the #30daysofawsterraform challenge and upskill too.