DEV Community: Udoh Deborah

Managing Terraform State: Best Practices for DevOps

Udoh Deborah — Tue, 31 Mar 2026 20:39:35 +0000

Introduction

If Day 5 was about building scaled infrastructure, Day 6 was about understanding what keeps it all together terraform state.

Today I migrated from local state to a fully remote S3 backend with state locking, and the difference between the two is not a small thing. It is the difference between infrastructure you can trust and infrastructure that is one concurrent run away from disaster.

What is Terraform State?

Every time you run terraform apply, Terraform writes a file called terraform.tfstate. This JSON file is Terraform's complete record of everything it manages — every resource, every attribute, every dependency. It is not a log. It is the source of truth.

When you run terraform plan, Terraform does three things:

Reads your configuration code
Reads the state file
Queries real AWS infrastructure

It then calculates the difference between what your code says should exist and what actually exists. Without state, none of this is possible. Terraform would have no way to know what it already created.

What the state file actually stores

After applying my Day 6 infrastructure, I ran terraform state show aws_lb.web and was surprised by how much detail was recorded. Every attribute AWS returns for the load balancer is stored — not just the ones I configured. Fields like desync_mitigation_mode, idle_timeout, preserve_host_header, and xff_header_processing were all there, even though I never set them in my config.

Running terraform state list showed every resource Terraform was tracking:

data.aws_ami.amazon_linux
data.aws_subnets.default
data.aws_vpc.default
aws_autoscaling_group.web
aws_launch_template.web
aws_lb.web
aws_lb_listener.http
aws_lb_target_group.web
aws_security_group.alb
aws_security_group.instance

Why Local State Breaks Down

Local state works fine when you are the only person touching the infrastructure. The moment a second person gets involved, everything breaks:

Concurrent runs — Two engineers run terraform apply at the same time. Both read the same local state, make different changes, and write back conflicting versions. State is now corrupted.

Lost state — An engineer runs apply on their laptop and the laptop dies. The state file is gone. Terraform no longer knows what it created.

No locking — Local state has no locking mechanism. Nothing stops two operations from running simultaneously.

Secrets in plaintext — The state file stores sensitive values like passwords and access keys in plaintext JSON. Committing it to Git exposes those secrets to everyone with repo access — and to anyone who ever had access, since Git history is permanent.

The Solution: Remote State with S3 and DynamoDB

The fix is to store state remotely in AWS S3, with DynamoDB handling state locking. Every engineer and every CI/CD pipeline reads and writes to the same state file, and only one operation can hold the lock at a time.

The Bootstrap Problem

Here is the challenge: you cannot use Terraform to create the S3 bucket that Terraform itself needs as a backend. The bucket has to exist before terraform init can use it.

The solution is to split the setup into two separate configurations. First, a backend-setup folder creates the S3 bucket and DynamoDB table using local state. Once those exist, the main configuration can use them as its backend.

Creating the S3 Bucket and DynamoDB Table

resource "aws_s3_bucket" "terraform_state" {
  bucket = "terraform-state-585706661633"

  lifecycle {
    prevent_destroy = true
  }
}

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

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

resource "aws_s3_bucket_public_access_block" "public_access" {
  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"
  }
}

Key decisions here:

prevent_destroy = true — stops anyone from accidentally deleting the state bucket with terraform destroy
Versioning enabled — every version of the state file is kept, so you can roll back if something goes wrong
Server-side encryption — state is encrypted at rest using AES256
Public access blocked — the state bucket is never accessible from the internet

Configuring the Backend

terraform {
  backend "s3" {
    bucket       = "terraform-state-585706661633"
    key          = "day6/terraform.tfstate"
    region       = "us-east-1"
    use_lockfile = true
    encrypt      = true
  }
}

Every argument matters here. bucket is where state lives. key is the path inside the bucket — using a path like day6/terraform.tfstate means multiple projects can share one bucket without overwriting each other. use_lockfile enables S3-native state locking. encrypt ensures state is encrypted in transit and at rest.

Note: The older dynamodb_table parameter is now deprecated in Terraform v5. Use use_lockfile = true instead — it achieves the same locking behaviour using S3 natively.

Proof It Worked

After running terraform apply, the infrastructure came up successfully with state stored remotely in S3.

*Terminal output showing successful apply with state lock releasing: *

[! Image description]

The terminal shows all 7 resources created and "Releasing state lock" confirming the lock was acquired and released correctly.

ALB response in browser confirming Day 6 infrastructure is live:

[]

The page explicitly confirms state is stored in the S3 remote backend.

Checking the S3 bucket confirmed the state file was there:

aws s3 ls s3://terraform-state-585706661633/day6/
2026-03-31 08:29:18      28315 terraform.tfstate

28KB, versioned, encrypted, and safely stored in S3.

Testing State Locking

To prove locking works, I opened two terminals pointing at the same configuration. Terminal 1 ran terraform apply. Immediately, Terminal 2 ran terraform plan.

Terminal 2 was blocked with a lock error:

Error: Error acquiring the state lock

Error message: ConditionalRequestFailed: The conditional request failed
Lock Info:
  Path:      terraform-state-585706661633/day6/terraform.tfstate.tflock
  Operation: OperationTypeApply

This is exactly the behaviour you want in a team environment. No two operations can run simultaneously. The second one waits or fails until the first releases the lock.

Errors I Hit and How I Fixed Them

S3 bucket does not exist on terraform init — I ran terraform init in the root folder before the S3 bucket existed. Fix: run the backend-setup config first to create the bucket, then init the main config.

Deprecated dynamodb_table parameter — Terraform v5 replaced this with use_lockfile = true. Updated the backend block accordingly.

Stuck state lock after DNS failure — A DNS drop mid-apply left a .tflock file in S3. Fix: aws s3 rm s3://terraform-state-585706661633/day6/terraform.tfstate.tflock

Intermittent DNS failures — An unstable internet connection caused repeated no such host errors. Fix: wait for connection to stabilise and retry — the infrastructure and state were always fine, just the network dropping temporarily.

Key Takeaways

Terraform state is the source of truth — treat it with the same care as your database
Never commit terraform.tfstate to Git — use remote state from day one
The bootstrap problem is real — always create your backend infrastructure in a separate config
State locking is not optional in a team environment — it is what prevents catastrophic corruption
S3 versioning is your safety net — it lets you recover from a bad apply by rolling back to a previous state version

Managing High Traffic Applications with AWS Elastic Load Balancer and Terraform

Udoh Deborah — Mon, 30 Mar 2026 16:49:16 +0000

Introduction

On Day 5 of the 30-Day Terraform Challenge, I tackled two of the most important concepts in production infrastructure: scaling with an AWS Application Load Balancer (ALB) and understanding Terraform state. By the end of the day, I had a fully load-balanced cluster running across multiple availability zones — and a much deeper understanding of what Terraform is actually doing behind the scenes.

What I Built

A fully production-ready scaled infrastructure consisting of:

An Application Load Balancer accepting public HTTP traffic on port 80
An Auto Scaling Group running a minimum of 2 EC2 instances across multiple AZs
A Target Group with HTTP health checks ensuring only healthy instances receive traffic
Security Groups that restrict direct instance access — only the ALB can talk to the instances

ALB + ASG Setup Walkthrough

The Architecture

Internet
    │
    ▼
[ ALB - port 80 ]
    │
    ▼
[ Target Group ]
    │         │
    ▼         ▼
[EC2 - AZ-a] [EC2 - AZ-b]
  (port 8080) (port 8080)

The ALB sits in front of the ASG. All public traffic hits the ALB on port 80, which forwards it to healthy instances in the target group on port 8080. Instances are not directly accessible from the internet — their security group only allows traffic from the ALB security group.
Security Groups — The Right Way
A common mistake is opening instance security groups to 0.0.0.0/0. The correct pattern is to reference the ALB security group directly:

# ALB accepts traffic from the internet
resource "aws_security_group" "alb" {
  name   = "terraform-day5-alb-sg"
  vpc_id = data.aws_vpc.default.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"]
  }
}

# Instances only accept traffic FROM the ALB security group
resource "aws_security_group" "instance" {
  name   = "terraform-day5-instance-sg"
  vpc_id = data.aws_vpc.default.id

  ingress {
    from_port       = var.server_port
    to_port         = var.server_port
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

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

Launch Template and User Data

Each instance runs a simple Python HTTP server on port 8080, started via a User Data script:

resource "aws_launch_template" "web" {
  name_prefix   = "terraform-day5-"
  image_id      = data.aws_ami.amazon_linux.id
  instance_type = var.instance_type

  vpc_security_group_ids = [aws_security_group.instance.id]

  user_data = base64encode(<<-EOF
    #!/bin/bash
    mkdir -p /var/www
    cat > /var/www/index.html <<HTML
    <html>
      <body>
        <h1>Hello from $(hostname)</h1>
        <p>Instance ID: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)</p>
        <p>AZ: $(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)</p>
      </body>
    </html>
    HTML
    cd /var/www
    nohup python3 -m http.server 8080 &
  EOF
  )
}

Auto Scaling Group

resource "aws_autoscaling_group" "web" {
  name                      = "terraform-day5-asg"
  min_size                  = var.min_size
  max_size                  = var.max_size
  desired_capacity          = var.min_size
  vpc_zone_identifier       = data.aws_subnets.default.ids
  target_group_arns         = [aws_lb_target_group.web.arn]
  health_check_type         = "ELB"
  health_check_grace_period = 60
  wait_for_capacity_timeout = "10m"

  launch_template {
    id      = aws_launch_template.web.id
    version = "$Latest"
  }
}

Application Load Balancer and Target Group

resource "aws_lb" "web" {
  name               = "terraform-day5-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb.id]
  subnets            = data.aws_subnets.default.ids
}

resource "aws_lb_target_group" "web" {
  name     = "terraform-day5-tg"
  port     = var.server_port
  protocol = "HTTP"
  vpc_id   = data.aws_vpc.default.id

  health_check {
    enabled             = true
    path                = "/"
    port                = "traffic-port"
    protocol            = "HTTP"
    healthy_threshold   = 2
    unhealthy_threshold = 2
    interval            = 30
    timeout             = 5
    matcher             = "200"
  }
}

resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.web.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.web.arn
  }
}

Proof It Worked

After terraform apply completed, hitting the ALB DNS name in the browser returned:

[! [Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h0hhsc601uyw5pl8nn3e.png]

Refreshing the page cycled through different instance IDs and AZs — confirming the load balancer was distributing traffic across the cluster.

terraform State Deep Dive

What is Terraform State?
When you run terraform apply, Terraform creates a file called terraform.tfstate. This JSON file is Terraforms source of truth — it maps every resource in your configuration to the real resource that exists in AWS.
Without state, Terraform would have no way to know:

Which resources it already created
What the current configuration of those resources is
What needs to change when you update your code

What the State File Contains
Opening terraform.tfstate after the Day 5 deployment revealed detailed information about every resource:

Resource type and name — e.g. aws_lb.web
Provider metadata — which provider manages the resource
All attributes — ARNs, IDs, DNS names, tags, ports, every setting
Dependencies — which resources depend on which

It is essentially a complete snapshot of your infrastructure at the time of the last apply.
Why State Must Never Be Committed to Git
The state file contains sensitive data — resource IDs, ARNs, and potentially secrets if you have outputs exposing them. Beyond security, committing state to Git causes serious problems in team environments:

Two engineers apply at the same time — state gets corrupted
Someone applies from an old branch — state goes out of sync
Merge conflicts in state files are nearly impossible to resolve safely

The solution is remote state — storing state in S3, Terraform Cloud, or another backend that supports locking.

State Locking

State locking prevents two operations from running simultaneously against the same state. Without it, two engineers running terraform apply at the same time can corrupt the state file permanently. When using S3 as a remote backend, DynamoDB is used for locking:

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

State Experiments

Experiment 1 — Manual State Tampering
I manually edited terraform.tfstate and changed the Day tag value from "5" to "99", then ran terraform plan.
Terraform immediately detected the discrepancy. It compared the state file (which said Day=99) against the configuration code (which said Day=5) and proposed to update the tag back to 5.
Key insight:

Terraform always reconciles three thing... your code, the state file, and real infrastructure. When state and code disagree, Terraform treats the code as the desired state and proposes changes to match it.
After running terraform apply, the tag was corrected and state was back in sync.

Experiment 2 — Infrastructure Drift via AWS Console
I manually changed the Day tag on a running EC2 instance directly in the AWS Console from 5 to MANUAL, without touching any Terraform code.
Running terraform plan detected the drift immediately. Even though the code and state file both said Day=5, Terraform queried AWS directly and saw the real value was MANUAL. It proposed to revert the tag back to 5.

[! Image description]

Key insight: Terraform does not rely solely on the state file — it also refreshes real infrastructure on every plan. This is how it detects drift caused by manual changes outside of Terraform.
Running terraform apply corrected the drift automatically.

Errors I Hit and How I Fixed Them

Error 1 — 502 Bad Gateway
Cause: The EC2 instances had no web server running, so the ALB had no healthy targets to route traffic to.
Fix: Added a User Data script to the Launch Template that starts a Python HTTP server on port 8080 on every instance boot.

Error 2 — Instance type not supported in us-east-1e
Your requested instance type (t3.micro) is not supported in your
requested Availability Zone (us-east-1e)
Cause: The aws_subnets data source was fetching all subnets including us-east-1e, which does not support t3.micro.
Fix: Added an AZ filter to the subnets data source to explicitly exclude us-east-1e:

data "aws_subnets" "default" {
  filter {
    name   = "vpc-id"
    values = [data.aws_vpc.default.id]
  }

  filter {
    name   = "availabilityZone"
    values = ["us-east-1a", "us-east-1b", "us-east-1c", "us-east-1d", "us-east-1f"]
  }
}

Key Takeaways

The ALB + ASG pattern is the foundation of every scalable AWS architecture
Security groups should reference each other, not open 0.0.0.0/0 to everything
Terraform state is the source of truth — understand it before you trust it
Never commit terraform.tfstate to Git — use remote state with locking
Drift happens — terraform plan is your best tool for detecting and fixing it

Day 4: Scaling to the Clouds – Building a Self-Healing Cluster on AWS with Terraform

Udoh Deborah — Thu, 26 Mar 2026 19:12:17 +0000

After successfully launching a single web server on Day 3, today was all about High Availability (HA). I moved away from the "Single Point of Failure" model and built a distributed system that can handle traffic spikes and hardware failures automatically.

The Architecture: From One to Many
Instead of one lonely EC2 instance, I deployed an Application Load Balancer (ALB) sitting in front of an Auto Scaling Group (ASG).

The Stack:

Infrastructure as Code: Terraform

Compute: AWS EC2 (t3.micro)

Scaling: Auto Scaling Group (min: 2, max: 5)

Networking: Application Load Balancer (ALB)

Configuration: Launch Templates with Base64 User Data

The Reality Check: Troubleshooting the "502 Bad Gateway"
If you think Cloud Engineering is just writing code and hitting "Apply," Day 4 will humble you. I ran into several "final bosses" today:

The Launch Template Trap: Unlike standard EC2 instances, Launch Templates require user data to be Base64 encoded. Without this, the bash script never runs, and the server never starts.

The Silent Firewall: I had my security groups open for inbound traffic, but I forgot the egress (outbound) rules. If the ALB can't "talk" to the instances to check their health, it marks them as unhealthy and gives you a 502 Bad Gateway.

Target Group Health Checks: I learned that the "Health Check" is a literal conversation. If the timeout is too short, the instance gets killed before it even finishes booting. Relaxing the health check intervals was the key to stability.

Key Takeaways
DRY (Don't Repeat Yourself): Used Terraform variables to ensure the Load Balancer and the EC2 instances were always aligned on the same port (8080).

Self-Healing: I tested the ASG by manually terminating an instance, and watched as AWS automatically detected the loss and spun up a replacement.

Decoupling: By using an ALB, my "users" only ever see one DNS name, even if the servers behind it are constantly changing.

What’s Next?
Day 4 was a masterclass in networking and state management. Tomorrow, I’ll be diving into Terraform State and how to manage these resources in a team environment without causing a "state-file war."

Deploying Your First Server with Terraform: A Beginner’s Guide

Udoh Deborah — Wed, 25 Mar 2026 20:31:09 +0000

Deploying Your First Server with Terraform: A Beginner’s Guide
Today, I stopped clicking around the console and started writing code.

Welcome to Day 3 of my journey with the #30DayTerraformChallenge. Up until now, everything was conceptual. But today, the rubber hit the road: I successfully deployed a real, live virtual server (EC2) on AWS using only Terraform.

It felt like magic. But like any good magic trick, there's logic, syntax, and a few failed attempts behind the scenes. In this post, I will walk you through exactly how I did it, what the code looks like, what the basic commands do, and the errors that almost stopped me.

What We Are Building Today
We aren't just creating a blank virtual machine. The goal of this task is to spin up a basic, accessible Web Server.

To do that, our configuration file needs to describe three key components working together:

The Environment (Provider): Tell Terraform to talk to AWS and which "room" (region) to work in.

The Firewall (Security Group): Tell AWS to open Port 80, allowing regular web traffic (HTTP) from the internet to reach our server.

The Server (EC2 Instance): This is the virtual machine itself. We will select an eligible "Free Tier" instance type (t3.micro) and add a small User Data script to automatically install Apache and launch a "Hello World" webpage.

The Architecture (Visualized)
This diagram shows exactly how my code relates to real AWS resources and how a user (like you!) connects to the web page over the internet.

Internet Gateway: This is the entrance. Web traffic flows from the User's browser to our network.

Security Group: This is the stateful firewall perimeter surrounding the server. My code opens an "Ingress" path for Port 80 (HTTP) to allow incoming requests.

EC2 Instance: The core virtual server running Amazon Linux 2023. This is what we are deploying.

Deconstructing the Code

This is the entire content of my main.tf file. When writing this, I avoided copy-pasting and typed it all out manually, which is crucial for building muscle memory.

##  1. THE PROVIDER BLOCK
# This tells Terraform that our "cloud platform of choice" is AWS and we want to deploy in N. Virginia (us-east-1). Think of this as the initial connection "handshake."

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

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

# 2. THE AMI DATA SOURCE
# I learned early on that AMI IDs from tutorials expire. This block automatically searches AWS to find the current, compatible, and FREE-TIER ELIGIBLE image for my region.

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

  filter {
    name   = "name"
    values = ["al2023-ami-202*-x86_64"]
  }

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

# 3. THE SECURITY GROUP RESOURCE
# This is our firewall. It defines what can come "in" (ingress) and what can go "out" (egress). 

resource "aws_security_group" "web_sg" {
  name        = "day3-web-sg"
  description = "Allow HTTP inbound traffic on Port 80"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # Open to ALL IP addresses
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1" # Represents ALL Protocols (TCP, UDP, etc.)
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# 4. THE EC2 INSTANCE RESOURCE
# This is the star of the show. Note how we reference the outputs of other blocks rather than hardcoding.

resource "aws_instance" "web_server" {
  ami                    = data.aws_ami.latest_amazon_linux.id # Links to the dynamic search result
  instance_type          = "t2.micro"                      # Falls under AWS Free Tier
  vpc_security_group_ids = [aws_security_group.web_sg.id] # Links the firewall to the server

  # User Data Script: Runs only once on the first boot
  user_data = <<-EOF
              #!/bin/bash
              dnf update -y
              dnf install -y httpd
              systemctl start httpd
              systemctl enable httpd
              echo "<h1>Terraform Day 3: Server Live!</h1>" > /var/www/html/index.html
              EOF

  tags = {
    Name = "Terraform-Day3-Server"
  }
}

# 5. THE PUBLIC IP OUTPUT
# This prints the final Public IP address in my terminal so I don't have to log into the AWS Console to find it.

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

Running the Workflow

Once my code was ready, I ran the foundational Terraform commands in my VS Code terminal.

terraform init

(The Handshake)
This initializes the directory. It reads your provider block, goes online, downloads the necessary AWS plugin (the provider package), and creates the .terraform directory.

[IMAGE PLACEHOLDER: Insert screenshot of terraform init output here]

terraform plan

(The Dry Run)
This is the most critical step. It compares your desired state (your code) with the current state (an empty AWS account) and tells you exactly what it will do. This is your insurance policy against accidental deletions. My plan confirmed: "Plan: 2 to add, 0 to change, 0 to destroy."

terraform apply

(The Provisioning)
This executes the plan. After review, I typed yes and hit Enter. For about 30 seconds, I watched my terminal spin, creating the security group and then the server.

[IMAGE PLACEHOLDER: Insert screenshot of "Apply complete!" with Public IP output here]

Finally, the glorious green text: "Apply complete! Resources: 2 added, 0 changed, 0 destroyed."

Success and Challenges (The Part You Came For)
Confirmation:
I copied the public_ip output from my terminal ([your IP here, e.g., 3.84.152.1]) and pasted it into my browser. Success! The page loaded instantly with my custom message.

[IMAGE PLACEHOLDER: Insert screenshot of the webpage loading in your browser]

Challenges:
It wasn't all smooth sailing. I encountered three major errors that initially stopped me.

Permission Error: My initial apply failed with UnauthorizedOperation.

Fix: I forgot that my newly created IAM user had zero permissions. I went to the AWS IAM console and attached the AdministratorAccess policy directly to the user to allow the code to create resources.

Environment Pathing Error: When I first tried to run terraform init, the terminal gave an error that the command wasn't recognized.

Fix: My initial installation script had a small error. I navigated to my desktop and downloaded a pre-configured, corrected zip file. Once unzipped, I used the PowerShell command Set-Location to move into the correct terraform-day3 folder, where the executable was properly pathed.

AMI Compatibility Error: My deployment repeatedly failed with the message InvalidParameterCombination. It stated the instance type was not eligible for Free Tier.

Fix: I was using an AMI ID from a months-old tutorial. That specific image was deprecated and no longer supported the t2.micro. I resolved this definitively by adding the data "aws_ami" block to dynamically fetch the latest compatible Amazon Linux AMI. Lesson learned: Never hardcode AMI IDs.

The Cleanup

To avoid any unexpected AWS charges, I ran the final command:

terraform destroy

After reviewing the plan (which confirmed "2 to destroy"), I typed yes. Within a minute, Terraform wiped the slate clean.

Conclusion and Day 4 Preview

Infrastructure as Code feels like a superpower. Going from a blank text file to a live server without ever touching the console interface is incredibly powerful for consistency, speed, and recovery.

Stay tuned for Day 4, where we will move past single resources and learn how to manage state files and collaborate effectively.

Day 2: Step-by-Step Guide to Setting Up Terraform, AWS CLI, and Your AWS Environment

Udoh Deborah — Sat, 21 Mar 2026 19:25:09 +0000

Step-by-Step Guide to Setting Up Terraform, AWS CLI, and Your AWS Environment

Getting started with Terraform can feel overwhelming at first, especially when you have to connect multiple tools like AWS, the CLI, and your local environment. But once your setup is done correctly, everything else becomes much easier.

In this guide, I’ll walk through how I set up my environment step-by-step so I’m ready to start deploying real infrastructure using Terraform.

Step 1: Set Up Your AWS Account

If you don’t already have an AWS account, create one and make sure to secure it properly.

The first thing I did after creating my account was:

Enable Multi-Factor Authentication (MFA) on the root account
Set up a billing alert to avoid unexpected charges

This is important because even small mistakes in cloud environments can lead to costs.

Step 2: Create an IAM User for Terraform

Instead of using the root account (which is not recommended), I created a dedicated IAM user for Terraform.

Key steps:

Enabled programmatic access
Attached appropriate permissions (for learning, I used broad access, but in production, least privilege is best)
Saved the Access Key ID and Secret Access Key

This IAM user will be used by Terraform to interact with AWS securely.

Step 3: Install and Configure AWS CLI

Next, I installed the AWS CLI, which allows me to interact with AWS from the terminal.

After installation, I configured it using:

aws configure

I entered:

Access Key
Secret Key
Default region (I chose us-east-1)
Output format (json)

To confirm everything was working, I ran:

aws sts get-caller-identity

This returned my AWS account details, which confirmed that authentication was successful.

Step 4: Install Terraform

I then installed Terraform on my machine.

To confirm installation, I ran:

terraform version

Once this worked, I knew Terraform was ready to use.

Step 5: Connect Terraform to AWS

One thing I learned is that Terraform doesn’t need separate credentials if AWS CLI is already configured.

Terraform automatically uses the credentials stored by the AWS CLI.

This makes things much simpler because once your CLI is working, Terraform can immediately interact with AWS.

Step 6: Set Up Visual Studio Code

To make development easier, I installed:

HashiCorp Terraform extension
AWS Toolkit extension

These help with syntax highlighting, validation, and managing resources more efficiently.

Common Issues and Fixes

One issue I ran into was Terraform not recognizing AWS credentials.

This was resolved by:

Re-running aws configure
Making sure the correct IAM user credentials were used
Verifying setup using aws sts get-caller-identity

This step is important because most Terraform errors at the beginning come from misconfigured credentials.

Key Takeaways

Always use an IAM user, not the root account
Verify your setup early using CLI commands
Terraform depends on AWS CLI configuration for authentication
A proper setup saves time and prevents errors later

Final Thoughts

Day 2 was all about getting the foundation right. It might not feel as exciting as deploying infrastructure, but this setup is what makes everything else possible.

Now that everything is configured and working, I’m ready to start building real infrastructure with Terraform.

Day 1 – 30 Days Terraform Challenge

Udoh Deborah — Mon, 16 Mar 2026 22:13:19 +0000

What is Infrastructure as Code and Why It’s Transforming DevOps

Modern software moves fast. Applications are deployed multiple times a day, teams work across different environments, and infrastructure needs to scale quickly. Managing servers and cloud resources manually simply cannot keep up with this pace. This is where Infrastructure as Code (IaC) comes in.

Infrastructure as Code is the practice of managing and provisioning infrastructure using code instead of manual processes. Instead of logging into a cloud console and creating servers, networks, or databases one by one, engineers write configuration files that define what infrastructure should look like. These files can then be executed to automatically create and manage the resources.

In simple terms, IaC allows infrastructure to be version-controlled, repeatable, and automated, just like application code.

The Problem IaC Solves

Before IaC became widely adopted, infrastructure was often created manually. Engineers would log into servers, configure environments step by step, and deploy resources through web dashboards.

This approach created several problems:
• Inconsistency between environments (development, staging, production)
• Human errors during manual configuration
• Difficult troubleshooting because changes were not always tracked
• Slow deployments due to manual setup processes

Infrastructure as Code solves these problems by allowing teams to define infrastructure in a structured, repeatable way. Once written, the same configuration can be used to create identical environments anywhere.

Declarative vs Imperative Infrastructure

When working with Infrastructure as Code, there are two main approaches: imperative and declarative.

An imperative approach requires you to write instructions step by step. You explicitly tell the system how to create each resource.

A declarative approach, which Terraform uses, focuses on describing the desired final state. Instead of listing every step, you simply declare what resources should exist, and Terraform figures out how to create or modify them.

For example, instead of saying:
• Create a server
• Configure networking
• Attach storage

You define something like:

“I want a server with this configuration.”

Terraform then handles the process of building it.

This makes infrastructure management simpler, safer, and easier to maintain.

Why Terraform is Worth Learning

Terraform is one of the most popular Infrastructure as Code tools because it is cloud-agnostic and highly scalable.

With Terraform, you can manage infrastructure across multiple platforms including AWS, Azure, Google Cloud, and many others using the same workflow.

Some key advantages of Terraform include:
• Automation of infrastructure provisioning
• Consistent environments
• Version control through Git
• Infrastructure visibility through state management
• Ability to manage complex systems easily

Terraform also uses a declarative configuration language called HCL (HashiCorp Configuration Language), which is relatively easy to read and write.

Because of these benefits, Terraform has become a core tool in many DevOps and cloud engineering workflows.

My Goals for the 30-Day Terraform Challenge

As someone actively building skills in cloud engineering and DevOps, I joined the 30-Day Terraform Challenge to deepen my practical understanding of Infrastructure as Code.

My goals for this challenge are simple:
• Gain hands-on experience writing Terraform configurations
• Understand how infrastructure can be automated and scaled
• Learn best practices for managing cloud infrastructure
• Build real-world projects that strengthen my DevOps skills

I believe the best way to learn cloud technologies is by building consistently and sharing the journey.

This challenge is just the beginning.

Over the next 30 days, I’ll be exploring Terraform deeper, creating infrastructure using code, and documenting what I learn along the way.

If you’re also learning Terraform or DevOps, feel free to follow along.

Let’s keep building.

Day 72 : Grafana

Udoh Deborah — Sun, 26 Oct 2025 14:37:43 +0000

Day 72 — Monitoring with Grafana

1️⃣ What is Grafana?

Grafana is an open-source monitoring and visualization platform that allows you to query, analyze, and display metrics from different data sources in real-time dashboards.
It helps teams observe infrastructure, applications, and services through interactive charts and alerts.

2️⃣ Why Grafana?

You can’t manually monitor infrastructure 24/7 — Grafana does it smartly by providing:
• Centralized dashboards for multiple environments.
• Real-time metric visualization.
• Custom alerts that notify you when something’s wrong.
• Easy integration with tools like Prometheus, AWS CloudWatch, InfluxDB, and more.

In short — Grafana turns raw monitoring data into insightful visuals and alerts.

3️⃣ Features of Grafana
• Interactive Dashboards — Create panels, graphs, and charts with drag-and-drop.
• Alerting System — Send notifications via email, Slack, PagerDuty, etc.
• Multi-Source Support — Connect to over 30+ data sources like Prometheus, MySQL, Elasticsearch, AWS CloudWatch, and Loki.
• Plugins — Extend functionality with custom panels and data source plugins.
• User Management — Control who can view, edit, or administer dashboards.
• Annotations — Mark events on graphs to visualize changes (like deployments or outages).

4️⃣ What Type of Monitoring Can Be Done via Grafana?
• Infrastructure Monitoring — Servers, CPU, Memory, Disk, Network.
• Application Monitoring — Microservices, APIs, latency, error rates.
• Cloud Monitoring — AWS, Azure, GCP metrics via native integrations.
• Container Monitoring — Kubernetes, Docker metrics through Prometheus.
• Business Metrics — Custom metrics like sales, traffic, user signups, etc.

5️⃣ Databases That Work with Grafana

Grafana connects to a wide range of data sources, including:
• Prometheus
• InfluxDB
• Graphite
• Elasticsearch
• AWS CloudWatch
• MySQL / PostgreSQL
• Loki (for logs)

6️⃣ Metrics and Visualizations in Grafana
• Metrics → Quantitative data points collected from systems (e.g., CPU usage, requests per second, memory utilization).
• Visualizations → How you display those metrics (graphs, heatmaps, gauges, tables, etc.).

Grafana turns metrics into actionable visualizations.

7️⃣ Grafana vs Prometheus

Feature Grafana Prometheus
Purpose Visualization & Dashboarding Data Collection & Storage
Function Displays metrics & alerts visually Scrapes metrics from targets
Data Storage No data storage (reads from sources) Built-in time-series database
Usage Used for dashboards and alerts Used for monitoring & metric scraping
Integration Uses Prometheus as a data source Exposes data to Grafana

In essence — Prometheus collects data, while Grafana visualizes it.

Day 71 - Terraform Interview Questions

Udoh Deborah — Fri, 24 Oct 2025 13:02:08 +0000

Today’s focus is on preparing for Terraform-related interview questions. These are some of the common ones you might encounter and how to approach them with confidence.

What is Terraform and how is it different from other IaC tools?
Terraform is an open-source Infrastructure as Code tool by HashiCorp that allows you to define and provision infrastructure using a declarative configuration language. It differs from other tools because it’s cloud-agnostic, maintains a state file, uses a declarative syntax, and supports immutable infrastructure.
How do you call a main.tf module?
By using a module block that references the module path or source. For example:

module "ec2_instance" {
  source = "./modules/ec2"
  instance_type = "t2.micro"
}

What is Sentinel and where can it be used? Sentinel is HashiCorp’s policy-as-code framework used to enforce compliance and governance. It helps define rules before Terraform applies changes, such as enforcing tagging standards, ensuring encryption, or restricting certain resource types.
How to create multiple instances of the same resource? You can use the count or for_each meta-arguments. For example:

resource "aws_instance" "web" {
  count = 3
  ami   = "ami-0abcd"
  instance_type = "t2.micro"
}

How to enable debug messages to find provider loading paths? Set the environment variable TF_LOG=TRACE. This enables detailed debug logs showing how Terraform loads providers and modules.
How to exclude a specific resource during destroy? Use the -target flag to specify what to destroy or preserve. Alternatively, comment out the resource you wish to keep before running terraform destroy.
Which module stores the .tfstate file in S3? The S3 backend is used for remote state storage.

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

How to manage sensitive data like API keys or passwords? Use sensitive variables, external secret managers, or environment variables. Avoid committing sensitive data to version control.
How to provision an S3 bucket and a user with read/write access? Use the aws_s3_bucket, aws_iam_user, aws_iam_policy, and aws_iam_policy_attachment resources to configure access permissions for the user.
Who maintains Terraform providers? Terraform providers are maintained by HashiCorp, cloud vendors, or the community. They are available through the Terraform Registry.
How to export data from one module to another? Use outputs from one module and pass them as input variables to another.

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

Then reference it as:

vpc_id = module.vpc.vpc_id

Day 71 reinforces how Terraform’s strength lies not only in writing configurations but also in understanding its internal workings, governance features, and modular structure. Knowing these concepts helps you build scalable, secure, and maintainable infrastructure systems.

Day 70 - Terraform Modules

Udoh Deborah — Fri, 24 Oct 2025 12:55:00 +0000

modules are where Terraform starts to feel like real engineering. Below is a practical, step-by-step workflow follow to design, build, test and publish reusable Terraform modules.

1) Decide module responsibility
1. Pick a single, focused purpose (networking, ec2, rds, alb, etc.).
2. Keep modules small and opinionated enough to enforce best practices, but configurable via variables.

Goal: one module = one responsibility.

2) Create module directory structure

Create a folder for the module and a small, consistent layout:

modules/
  my-server/
    README.md
    main.tf
    variables.tf
    outputs.tf
    examples/
      simple/
        main.tf

examples/simple is for a runnable example that shows how to consume the module.

3) Write module files (what to include)
• main.tf: resource definitions (no hardcoded values).
• variables.tf: declare all inputs, provide clear descriptions and sensible defaults where appropriate. Mark sensitive variables if needed.
• outputs.tf: expose IDs/ARNs/important values consumers will need.
• README.md: usage, inputs, outputs, example, constraints and notes.

Keep tasks idempotent and avoid side effects.

4) Make the module configurable (variables best practices)
• Give descriptive names and description for every variable.
• Use types (string, number, list(string), map(string), object({...})) for clarity.
• Provide reasonable defaults for optional values; require explicit for critical ones (e.g., vpc_id).

Example pattern (conceptually):
variable "instance_type" { type = string; default = "t3.micro"; }

5) Expose useful outputs

Only output what consumers need: resource IDs, ARNs, connection info. Keep outputs minimal and stable. Example: instance_id, subnet_id, security_group_id.

6) Add an example (and test locally)

Create modules/my-server/examples/simple/main.tf that calls your module with realistic variable values. This is how people (and CI) will sanity-check the module.

Run:

cd modules/my-server/examples/simple
terraform init
terraform validate
terraform plan -out plan.tfplan
terraform apply plan.tfplan
# check resources, then:
terraform destroy -auto-approve

7) Format and validate

Before committing:

terraform fmt -recursive
terraform validate

Install and run terraform-docs to auto-generate README sections:

terraform-docs md . > README.md

(Keep a human-written intro + generated inputs/outputs.)

8) Version control and collaboration
• Keep modules in Git (e.g., git repo with modules/ or individual repos per module).
• Use semantic versioning for published modules (v1.0.0).
• Tag releases (git tag v1.0.0 and push tags) so consumers can reference git::https://...//?ref=v1.0.0.

9) CI: run plan & tests on PR

Set up CI that:
1. Runs terraform init and terraform validate for module and examples.
2. Runs terraform fmt -check.
3. Optionally runs integration tests:
• Terratest (Go) for real cloud checks (recommended for modules that create real infra).
• Or lightweight smoke tests: terraform apply against a short-lived test workspace and terraform destroy.

Keep credentials secure (CI secrets, temporary accounts).

10) Documentation & discoverability
• Write a clear README: purpose, usage, inputs, outputs, example, constraints.
• Add use-cases and recommended defaults.
• Add CHANGELOG.md for breaking changes.

11) Publishing and consumption
• Consume locally:

module "server" {
  source = "../modules/my-server"
  ...
}

• Consume from Git:

module "server" {
  source = "git::https://github.com/you/terraform-modules.git//my-server?ref=v1.0.0"
}

• Publish to Terraform Registry (public or private) if you want organization-wide reuse.

12) Maintenance & versioning policy
• Keep modules backward compatible when possible.
• For breaking changes bump major version; provide migration notes.
• Use terraform state mv guidance in docs if consumers need to migrate resources after structural changes.

13) Testing checklist before release
• terraform fmt passed
• terraform validate passed
• Example apply/destroy succeeded
• README autogenerated/updated (terraform-docs)
• CI checks green
• Module documented with inputs/outputs and examples
• Release tag created

14) Example workflow: make a network module then use it

Implement modules/network with VPC/subnets/route tables.
Add example for modules/network/examples/simple and verify apply/destroy.
In root project main.tf reference module via source = "../modules/network".
Run root terraform init → plan → apply.

Day 69 : Meta Arguments in Terraform

Udoh Deborah — Fri, 24 Oct 2025 12:31:51 +0000

A. two ready-to-run Terraform examples (one count demo, one for_each demo),

B. step-by-step instructions to run and inspect results,

C. a clear explanation of meta-arguments and best practices, and (D) cleanup & cost warnings. Replace (AMI, region, key name, etc.) before running.

Quick safety note: the AWS EC2 examples will create real instances that can incur cost. If you only want to experiment without charges, use the local_file or null_resource variants (I include a lightweight local demo below).

A — Example 1 — count (create N identical resources)

Purpose: create N identical resources (same config). Use count when you want a number of identical copies.

Create folder day69-count/ and files:

main.tf

terraform {
  required_providers {
    aws = { source = "hashicorp/aws" version = "~> 5.0" }
  }
}
provider "aws" {
  region = var.region
}

resource "aws_instance" "server" {
  count         = var.instance_count
  ami           = var.instance_ami
  instance_type = var.instance_type
  key_name      = var.key_name

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

variables.tf

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

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

variable "instance_ami" {
  type    = string
  default = "ami-08c40ec9ead489470" # replace for your region
}

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

variable "key_name" {
  type = string
  default = "<YOUR_KEY_PAIR>"
}

outputs.tf

output "instance_ids" {
  value = aws_instance.server[*].id
}
output "instance_public_ips" {
  value = aws_instance.server[*].public_ip
}

Run:

terraform init
terraform plan -out plan.tfplan
terraform apply "plan.tfplan"

Inspect addresses / outputs:
• Resources created are referenced as aws_instance.server[0], aws_instance.server[1], etc.
• count.index inside the block gives the zero-based index.

Change count:
• Update var.instance_count = 4 (or pass -var="instance_count=4"), run terraform apply — Terraform will create additional instances for indices 2 and 3.

B — Example 2 — for_each (create resources with distinct values)

Purpose: multiple similar resources which have different attributes (AMIs, names, or other per-item configuration). Use for_each with a map or set-of-strings so each instance is keyed and stable.

Create folder day69-foreach/ and files:

main.tf

terraform {
  required_providers {
    aws = { source = "hashicorp/aws" version = "~> 5.0" }
  }
}
provider "aws" {
  region = var.region
}

# map of named instances -> ami
variable "servers_map" {
  type = map(string)
  default = {
    "linux"  = "ami-0b0dcb5067f052a63"
    "ubuntu" = "ami-08c40ec9ead489470"
  }
}

resource "aws_instance" "server" {
  for_each      = var.servers_map
  ami           = each.value
  instance_type = var.instance_type
  key_name      = var.key_name

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

variables.tf

variable "region" {
type = string
default = "us-east-1"
}
variable "instance_type" {
type = string
default = "t2.micro"
}
variable "key_name" {
type = string
default = ""
}

outputs.tf

output "server_public_ips" {
value = { for k, r in aws_instance.server : k => r.public_ip }
}


Run: same terraform init && terraform apply.

Inspect addresses / outputs:
    • Resources are referenced by key: e.g. aws_instance.server["linux"], aws_instance.server["ubuntu"].
    • each.key and each.value available inside the block.

Change for_each map:
    • Add or remove keys in servers_map then terraform apply. Terraform will create or destroy only the specific keyed resources — stable mapping reduces accidental replacements.



C — Lightweight demo (no AWS charges) — use local_file and null_resource

If you want to learn semantics without creating cloud resources, try this local demo:

Folder day69-local/:

main.tf

resource "local_file" "count_files" {
count = 3
filename = "${path.module}/count_file_${count.index}.txt"
content = "file created with count index ${count.index}"
}

locals {
items = {
"one" = "first"
"two" = "second"
}
}

resource "local_file" "foreach_files" {
for_each = local.items
filename = "${path.module}/foreach_${each.key}.txt"
content = "for_each created ${each.key} => ${each.value}"
}


Run terraform init && terraform apply — you’ll get files in your folder; no cloud cost.



D — Meta-arguments: what they are & how to use them

Meta-arguments are special arguments accepted by resource/module blocks that control Terraform language behavior. Common meta-arguments include:
• count — number of instances (integer). Addresses use numeric indices: resource.type.name[index].
• for_each — iterate over a map or set; produces one instance per key. Addresses use keys: resource.type.name["key"].
• depends_on — explicit dependency list (useful in rare cases).
• provider — select which provider configuration to use.
• lifecycle — control create_before_destroy, prevent_destroy, ignore_changes.
• provisioner — (discouraged for most cases) run local/remote commands.

Count vs For_each — when to use which
• Use count:
• When you just need N identical copies.
• When order/indices are fine and attributes are identical.
• Example: count = 4 to create 4 identical web servers.
• Use for_each:
• When each instance needs unique attributes (different AMIs, names, sizes).
• When you want stable resource identity across changes (keys are stable).
• Use a map if you need key→value pairs (each.key and each.value).
• Use a set of strings if only names/IDs are needed.

Addressing differences
• count → aws_instance.foo[0], aws_instance.foo[1]
• for_each → aws_instance.foo["linux"], aws_instance.foo["ubuntu"]

State & lifecycle implications
• Changing count may cause Terraform to destroy the highest indexed resources if you reduce the number — which can be destructive.
• for_each keyed resources are more stable when adding/removing different keys.
• If you convert from count → for_each or vice versa, Terraform will typically want to recreate resources (state address changes). Use terraform state mv to migrate state safely if needed.

Tips & best practices
• Prefer for_each (map) for heterogeneous resources or when identity matters.
• Use toset() or tolist() conversions to ensure predictable input types.
• Avoid dynamic index assumptions; don’t depend on count.index to persist a machine’s identity over time.
• Keep resource blocks small and idempotent.
• Use lifecycle { create_before_destroy = true } when replacing resources that affect availability (but be careful).
• For large fleets, consider modules to group repeated logic and pass counts/for_each into module blocks.



E — Example: multiple key/value iteration (map with structured attributes)

If instances need multiple attributes:

variable "servers" {
default = {
web1 = { ami = "ami-aaa", instance_type = "t3.micro" }
web2 = { ami = "ami-bbb", instance_type = "t2.micro" }
}
}

resource "aws_instance" "web" {
for_each = var.servers
ami = each.value.ami
instance_type = each.value.instance_type
tags = { Name = each.key }
}




This is powerful — each.key becomes your stable identifier.



F — How to demonstrate for an interview (suggested steps)
1. Show the count example: instance_count = 2 apply, then change to 4 and apply — show terraform plan then apply.
2. Show the for_each example: add a new map key and terraform apply — point out only that key’s resource is created.
3. Show terraform state list and how addresses look (aws_instance.server[0] vs aws_instance.server["linux"]).
4. Explain migration: demonstrate terraform state mv if you rename keys or move from count→for_each.
5. Discuss real-world choice: use for_each for stable identity (e.g., DB replicas with different roles), count for identical worker nodes when identity is irrelevant (but note the stability issues).



G — Cleanup & cost control
• For AWS examples: terraform destroy -auto-approve to remove resources.
• Always confirm what will be destroyed with terraform plan -destroy.
• Use small instance types (e.g., t3.micro) and a single AZ for demos, or use local_file demo to avoid charges.

Day 68 — Scaling with Terraform

Udoh Deborah — Mon, 20 Oct 2025 16:55:44 +0000

Important: replace every with your actual values (region, AMI, key pair name, VPC/subnet IDs). The AMI in your example may be region-specific — verify it for your region.

Project layout

day68-autoscaling/
  ├─ main.tf
  ├─ variables.tf
  ├─ outputs.tf
  └─ terraform.tfvars   (optional)

variables.tf

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

variable "ami" {
  type    = string
  default = "ami-005f9685cb30f234b" # replace if not available in your region
}

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

variable "key_name" {
  type    = string
  default = "<YOUR_KEY_PAIR_NAME>"
}

variable "vpc_id" {
  type = string
  default = "<YOUR_VPC_ID>"
}

variable "public_subnet_ids" {
  type = list(string)
  default = ["<PUBLIC_SUBNET_ID_1>", "<PUBLIC_SUBNET_ID_2>"]
}

main.tf

This creates a security group (SSH & HTTP), a classic ELB (optional but included because your example referenced a load balancer), a launch configuration, and an autoscaling group.

terraform {

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

provider "aws" {
  region = var.region
}

# --- Security group for web instances ---
resource "aws_security_group" "web_server" {
  name        = "day68-web-sg"
  description = "Allow SSH and HTTP"
  vpc_id      = var.vpc_id

  ingress {
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]    # For demo only. Restrict in production.
  }

  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 = "day68-web-sg" }
}

# --- Optional Classic ELB to attach to ASG (example) ---
resource "aws_elb" "web_server_lb" {
  name               = "day68-web-elb"
  subnets            = var.public_subnet_ids
  security_groups    = [aws_security_group.web_server.id]

  listener {
    instance_port     = 80
    instance_protocol = "http"
    lb_port           = 80
    lb_protocol       = "http"
  }

  health_check {
    healthy_threshold   = 2
    unhealthy_threshold = 2
    timeout             = 3
    target              = "HTTP:80/"
    interval            = 30
  }

  tags = { Name = "day68-web-elb" }
}

# --- Launch configuration (legacy) ---
resource "aws_launch_configuration" "web_server_lc" {
  name_prefix   = "day68-lc-"
  image_id      = var.ami
  instance_type = var.instance_type
  key_name      = var.key_name
  security_groups = [aws_security_group.web_server.id]

  user_data = <<-EOF
              #!/bin/bash
              # simple web page bootstrap
              if command -v yum >/dev/null 2>&1; then
                yum update -y
                yum install -y httpd
                systemctl enable httpd
                systemctl start httpd
                echo "<html><body><h1>You're doing really Great</h1></body></html>" > /var/www/html/index.html
              elif command -v apt-get >/dev/null 2>&1; then
                apt-get update -y
                apt-get install -y apache2
                systemctl enable apache2
                systemctl start apache2
                echo "<html><body><h1>You're doing really Great</h1></body></html>" > /var/www/html/index.html
              fi
              EOF

  lifecycle {
    create_before_destroy = true
  }
}

# --- Auto Scaling Group ---
resource "aws_autoscaling_group" "web_server_asg" {
  name                      = "web-server-asg"
  launch_configuration      = aws_launch_configuration.web_server_lc.name
  min_size                  = 1
  max_size                  = 3
  desired_capacity          = 2
  vpc_zone_identifier       = var.public_subnet_ids
  health_check_type         = "EC2"
  health_check_grace_period = 120

  # attach ELB (classic) created above
  load_balancers = [aws_elb.web_server_lb.name]

  tag {
    key                 = "Name"
    value               = "day68-web"
    propagate_at_launch = true
  }
}

outputs.tf

output "asg_name" {
  value = aws_autoscaling_group.web_server_asg.name
}

output "elb_dns_name" {
  value = aws_elb.web_server_lb.dns_name
}

Run it (commands)
A. Initialize:

cd day68-autoscaling
terraform init

B. Validate & plan:

terraform validate
terraform plan -out plan.tfplan

C. Apply:

terraform apply "plan.tfplan"
# or: terraform apply -auto-approve

Terraform will create the ELB, Launch Configuration, and ASG which launches instances in the two public subnets.

Test scaling (console + CLI)

Console

Go to EC2, Auto Scaling Groups, select web-server-asg.
Click Edit ,change Desired capacity to 3 ,Save.
Wait a few minutes for instances to launch.
Verify in EC2 , Instances.
Change desired capacity back to 1 to scale down and confirm termination.

AWS CLI (optional)

# scale up
aws autoscaling set-desired-capacity --auto-scaling-group-name web-server-asg --desired-capacity 3 --honor-cooldown


# scale down
aws autoscaling set-desired-capacity --auto-scaling-group-name web-server-asg --desired-capacity 1 --honor-cooldown

Verify web page
• If you used ELB, open the ELB DNS:

http://$(terraform output -raw elb_dns_name)

You should see You’re doing really Great.

• Or open the public IP of any instance.

Cleanup

To remove resources and stop charges:

terraform destroy -auto-approve

Troubleshooting tips
• ASG not launching instances: check subnet IDs, IAM permissions, and AMI availability in region.
• User data script failed: inspect instance system logs in EC2 console or SSH and check /var/log/cloud-init-output.log.
• Health check failures: increase health_check_grace_period to allow setup time.
• SSH exposed to 0.0.0.0/0: change ingress to your IP only for security.

Notes & best practice recommendations
• aws_launch_configuration is legacy. Prefer aws_launch_template for new projects — launch templates are more flexible (and needed for many modern features). I can provide a launch_template + ASG + ALB example if you want.
• For HTTP scaling, prefer an ALB (Application Load Balancer) + Target Group instead of Classic ELB. ALB integrates with target tracking and metrics better.
• In production, restrict SSH to your IP or use SSM Session Manager instead of opening port 22.
• For autoscaling based on metrics, add scaling policies (target tracking or step policies) to auto-adjust based on CPU, request counts, etc.

Day 67 : AWS S3 Bucket creation and management using Terraform

Udoh Deborah — Fri, 17 Oct 2025 14:54:51 +0000

Before you start (checks)
• Have AWS CLI configured (aws configure) or set AWS_* env vars.
• Terraform installed (terraform -v).
• Recommended: use an S3 remote backend for state in real projects (not required for testing).

1) Create Terraform files (example structure)

day67-s3/
├─ main.tf
├─ variables.tf
├─ outputs.tf
└─ terraform.tfvars # optional: put bucket_name, region etc here

2) variables.tf

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

variable "bucket_name" {
  type = string
  # bucket names must be globally unique
  default = "my-unique-day67-bucket-<your-unique-suffix>"
}

variable "read_only_principal_arn" {
  description = "ARN of IAM user or role to grant read-only access"
  type        = string
  default     = "arn:aws:iam::<ACCOUNT_ID>:user/<USERNAME>"  # replace
}

3) main.tf — bucket, versioning, policy, (optional) public access block

provider "aws" {
  region = var.region
}

# S3 bucket
resource "aws_s3_bucket" "site" {
  bucket = var.bucket_name

  # If you plan to host a static website, uncomment the website block and adjust
  # website {
  #   index_document = "index.html"
  # }
}

# IMPORTANT: If you want public access via ACL/policy, you may need to allow it:
# Create/Disable the account-level Block Public Access? Here we manage at bucket-level:
resource "aws_s3_bucket_public_access_block" "no_block" {
  bucket = aws_s3_bucket.site.id

  # To allow public access, set all to false. BE CAREFUL in production.
  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

# Enable versioning
resource "aws_s3_bucket_versioning" "v" {
  bucket = aws_s3_bucket.site.id

  versioning_configuration {
    status = "Enabled"
  }
}

# Make bucket objects public-read by default using ACL on the bucket (optional)
# Note: Many modern setups prefer using bucket policy only. If you set ACL,
# ensure the public access block allows it (above).
resource "aws_s3_bucket_acl" "acl" {
  bucket = aws_s3_bucket.site.id
  acl    = "public-read"
}

# Bucket policy to allow public GetObject (if you want fully public)
data "aws_iam_policy_document" "public_read" {
  statement {
    sid     = "AllowPublicGetObject"
    effect  = "Allow"
    principals {
      type        = "AWS"
      identifiers = ["*"]
    }
    actions   = ["s3:GetObject"]
    resources = ["${aws_s3_bucket.site.arn}/*"]
  }
}

resource "aws_s3_bucket_policy" "public_policy" {
  bucket = aws_s3_bucket.site.id
  policy = data.aws_iam_policy_document.public_read.json
}

# Bucket policy granting read-only to a specific IAM user/role
data "aws_iam_policy_document" "read_only_for_principal" {
  statement {
    sid = "AllowReadForSpecificPrincipal"
    effect = "Allow"
    principals {
      type        = "AWS"
      identifiers = [var.read_only_principal_arn]
    }
    actions = [
      "s3:GetObject",
      "s3:ListBucket"
    ]
    # ListBucket must reference bucket arn, GetObject references objects
    resources = [
      aws_s3_bucket.site.arn,
      "${aws_s3_bucket.site.arn}/*"
    ]
  }
}

resource "aws_s3_bucket_policy" "principal_policy" {
  bucket = aws_s3_bucket.site.id
  policy = data.aws_iam_policy_document.read_only_for_principal.json
}

Notes
• The above creates both a public policy (everyone) and a principal-specific policy. In practice use one or the other depending on your requirements. If the bucket should be fully public, keep public_policy; if you want only a specific IAM user/role to read, remove public_policy and aws_s3_bucket_acl and rely only on the principal_policy.
• Modern AWS best practice: avoid public buckets unless necessary. Instead, grant access to specific principals or use CloudFront with signed URLs.

4) outputs.tf

output "bucket_name" {
  value = aws_s3_bucket.site.bucket
}

output "bucket_arn" {
  value = aws_s3_bucket.site.arn
}

output "website_endpoint" {
  value = aws_s3_bucket.site.website_endpoint
  description = "Empty unless you enabled static website hosting."
  sensitive   = false
}

5) Initialize & apply (commands)

cd day67-s3
terraform init
terraform validate
terraform plan -out plan.tfplan
terraform apply "plan.tfplan"
# or terraform apply -auto-approve

Watch outputs for bucket name/ARN. If apply fails with public access errors, check AWS Account Public Access Block settings — account-level block may prevent public policy/ACL.

6) Test public read access
1. Upload a sample file (AWS CLI):

aws s3 cp sample.txt s3://<your-bucket-name>/sample.txt --acl public-read

Open in browser:

https://<your-bucket-name>.s3.amazonaws.com/sample.txt

If publicly accessible you’ll see content.

If you used static website hosting, URL is:

http://<your-bucket-name>.s3-website-<region>.amazonaws.com/index.html

7) Verify versioning

Use AWS CLI:

aws s3api get-bucket-versioning --bucket <your-bucket-name>
# Expected: Status: Enabled

Upload an object, then upload again; list versions:

aws s3api list-object-versions --bucket <your-bucket-name> --prefix sample.txt

8) Clean up (optional)

# remove objects and versions first, then destroy
aws s3 rm s3://<your-bucket-name> --recursive
terraform destroy -auto-approve

S3 buckets with versioning require special handling to delete versions before bucket deletion.