DEV Community: Zakariyau Mukhtar

From Installation Freezes to PowerShell Automation: My Windows Server 2019 Journey.

Zakariyau Mukhtar — Thu, 15 Jan 2026 17:35:25 +0000

Introduction: The Challenge

I recently tackled a comprehensive lab project: deploying a functional Windows Server 2019 environment from scratch. The goal wasn't just to install the OS, but to configure it like a real-world sysadmin using automation to handle users, groups, and secure file sharing.

While I started this project feeling a bit like a beginner (or as we say, an "olodo"), by the end, I was writing multi-line PowerShell scripts to manage the infrastructure.

Here is a breakdown of how I built my lab using Oracle VirtualBox and how I overcame some tricky hurdles along the way.

Phase 1: The Setup and "The Freeze"

My lab environment ran on Oracle VirtualBox. The installation process taught me my first major lesson in virtualization troubleshooting.

Initially, my Windows Server installation kept freezing at the "spinning dots" boot screen. After some deep diving into settings, I realized that running a modern server OS requires specific virtualization hardware settings.

The Fix:
It turned out my VM configuration was missing a critical processor feature. I had to ensure PAE/NX was enabled in the VirtualBox processor settings and increase my video memory. Once those were tweaked, the installation sailed through to the desktop experience.

Phase 2: Base Configuration (The Manual Stuff)

Once logged in as the Administrator, the first step was giving the server an identity.

In a real network, servers need static addresses so they can always be found. I configured the network adapter with a static IPv4 address suitable for my lab environment (10.0.2.15).

I also renamed the computer from its generic Windows name to something meaningful: WIN-SERVER-01. While I could have used the GUI, I used PowerShell for a quick rename and restart:

Rename-Computer -NewName "WIN-SERVER-01" -Restart

Phase 3: The Power of Automation (The Cool Stuff)

This is where the project got interesting. The requirement was to create multiple users (Alice, Bob, Charlie), assign them to departments (HR, IT), and ensure they changed their passwords on first login.

Doing this manually involves dozens of clicks. Instead, I wrote a PowerShell script to handle it in seconds.

The Scripting Approach:
I used ISE to write a script that utilized loops and conditionals. It checked if a user or group existed before trying to create it, making the script "idempotent" (safe to run multiple times).

Here is a snippet of the user creation loop:

# Snippet: Automating User Creation
$users = @("Alice", "Bob", "Charlie")
foreach ($user in $users) {
    # Create the user
    New-LocalUser -Name $user -Password $securePassword -Description "Staff"

    # Force password change at next login
    $userObj = [ADSI]"WinNT://$env:COMPUTERNAME/$user,user"
    $userObj.PasswordExpired = 1
    $userObj.SetInfo()
}

Phase 4: Permissions and Hardening

The final step was securing the environment.

File Sharing:
I created restricted folders HRDocs and ITDocs. I used PowerShell to ensure only the HR group could access their documents, and ditto for IT. This enforced the principle of least privilege.

Security Hardening:
As a basic security measure, I disabled the built-in Guest account to prevent anonymous access. Again, PowerShell made this easy to verify:

Conclusion and Lessons Learned

This project was a great crash course in Windows Server administration. The biggest takeaway wasn't just knowing what to configure, but knowing how to do it efficiently.

While GUIs are helpful for learning, PowerShell is essential for scalable, repeatable system administration. Moving past the initial installation hurdles and seeing my scripts successfully deploy the environment felt like a massive win.

From Vibe-Coding to Engineering: My 48-Hour Battle with Docker & Windows

Zakariyau Mukhtar — Mon, 12 Jan 2026 18:08:30 +0000

I started this weekend with a simple goal: set up a local development environment. I wanted a vanilla HTML/JS frontend, a Node.js backend, and a MongoDB database running in a Docker container (plus Mongo Express to visualize the data).

Prior to this, I had zero knowledge of JavaScript. I was just following a video tutorial, copying code I didn't fully understand, and hoping for the best.

I thought it would take an hour. Instead, it took a frustrated bike ride home, a Sunday spent journaling, and a deep dive into how Docker actually works to get it running. Here is the full story.

The Setup (Copying blindly)

I started by copying the frontend code. It was a simple User Profile page where you could toggle between "View" and "Edit" modes.

My index.html:

<script>
    function saveProfile() {
        document.querySelector('#name').textContent = document.querySelector('#input-name').value
        // ... more DOM manipulation
    }
</script>

My server.js:

var express = require('express');
var app = express();
app.use(express.static(__dirname)); 
app.listen(3000, function () {
    console.log("app listening on port 3000!");
});

So far, so good. The frontend worked. Then came Docker.

Phase 1 The "Name Does Not Resolve" Loop:

I pulled the mongo and mongo-express images and tried to run them using long CLI commands I found online. I checked docker ps, and everything looked fine.

But when I checked the logs for Mongo Express, I saw this error over and over:

/docker-entrypoint.sh: line 15: mongo: Name does not resolve

I spent 30 minutes spinning up containers, deleting them, and spinning them up again. I eventually turned to AI for help. It suggested I stop everything, wipe the containers, and create a dedicated network.

I ran:

docker network create mongo-network

Then I restarted the containers attached to that network. The error persisted. I was stuck in a loop of trying random commands without understanding why they failed.

Phase 2: The Mystery of "Pass" vs "Password"-

Once I finally got the containers talking, I couldn't log in to Mongo Express.

I had explicitly set my environment variables to:

ME_CONFIG_BASICAUTH_USERNAME=admin
ME_CONFIG_BASICAUTH_PASSWORD=password

But every time I tried to log in with admin / password, it failed.

After a lot of trial and error, I tried logging in with pass. It worked.

I realized that because of how I was passing arguments in PowerShell, Docker wasn't picking up my password variable. It was defaulting to the container's built-in security settings (admin:pass). I had to completely restructure my docker run command to ensure the variables were actually being read.

Phase 3: The Saturday Night "Vibecoding" Crash-

By 9 PM on Saturday, I hit a wall.

I ran my Node.js server and tried to edit a profile. The terminal said:

Connecting to the db....

And then... silence. It just froze.

I tried everything the AI suggested, but nothing worked. I didn't even understand half the commands I was typing. I realized I was just "vibecoding" typing random things hoping for a miracle. I was frustrated. I packed up, left the office, and took a bike ride home to clear my head.

Phase 4: The Monday Morning Fix

On Sunday, I didn't touch the code. I just journaled. I wrote down a plan: Understand the problem, then fix it.

On Monday, I came back fresh. I wiped every container and image (docker system prune) and started from scratch.

The "Windows Hang" (IPv4 vs IPv6)

I realized why the app was freezing. On Windows, localhost often resolves to the IPv6 address ::1. However, Docker Desktop for Windows listens on the IPv4 address 127.0.0.1.

My Node app was knocking on the IPv6 door, but Docker was at the IPv4 house.

I changed my connection string in server.js:

Bad: mongodb://admin:password@localhost:27017
Good: mongodb://admin:password@127.0.0.1:27017

The Version Mismatch

Even with the connection fixed, I got errors. I looked at my package.json.
I had installed the latest mongodb version (v6.0+), which uses Promises. But the tutorial code I copied was written for version 3.8, which used Callbacks.

I uninstalled the new version and forced a downgrade:

npm install mongodb@3.7.3

I restarted the server. I clicked "Save Profile." It worked.

Conclusion

This project was supposed to be a quick setup, but it turned into a crash course in DevOps. I learned:

Don't trust localhost on Windows. Always use 127.0.0.1.
Check your dependencies. Copy-pasting old code requires old packages.
Stop "Vibecoding." If you don't understand the command, don't run it. Step back, journal, and come back fresh.

From "Permission Denied" to Production: My AWS & Terraform Journey

Zakariyau Mukhtar — Tue, 30 Dec 2025 14:58:59 +0000

Provisioning infrastructure and deploying applications manually is a recipe for inconsistency. Today, I took on the challenge of automating a server setup using Terraform to host a Spring Boot Java application. It wasn't a straight path. I ran into regional payment blocks, architecture mismatches and SSH "ghosts" but here is exactly how I solved them.

The Pivot From DigitalOcean to AWS:

I was following a course where the instructor used DigitalOcean to deploy the Java app. I tried to follow along, but I hit a brick wall, DigitalOcean kept rejecting my cards because I am in Nigeria.
I felt bad for a few days, but then I remembered my #30ofAWSTerraform challenge. AWS is known for its complexity, but it’s also the industry leader. I decided to stop feeling bad and start building. If the course used a DigitalOcean "Firewall," I knew I could translate that into an AWS Security Group. I decided to test my knowledge and gain real experience.

1. Provisioning Infrastructure with Terraform:

My goal was to use Infrastructure as Code (IaC) to create an EC2 instance. I used the aws_instance and aws_key_pair resources to define my server.

The Challenge: SSH Key Management
Initially, passing the public key as a raw string variable led to formatting errors.

The Solution:
I used the Terraform file() function to read my public key directly from my local disk. This ensured that the exact bytes on my Windows machine matched what AWS received.

resource "aws_key_pair" "my_ssh_key" {
  key_name   = "zacks-key"
  public_key = file("C:/Users/Public/id_aws.pub")
}

2. The Battle of AMI IDs and Usernames:

Even after the server was "running," I couldn't get in. I kept seeing InvalidAMIID.NotFound or Permission denied (publickey).

The Lessons Learned:

Region Specificity: AMI IDs are not universal. An Ubuntu ID in London won't work in North Virginia (us-east-1).
Architecture Matters: I discovered that a t2.micro instance requires an x86 image. Trying to use an ARM-based AMI will result in a "Not Found" error.
The Default User: Every OS has a different "front door." For Amazon Linux, it’s ec2-user. For Ubuntu, it’s ubuntu.

3. Deploying the Application (The JAR File):

Once the server was accessible, I needed to move my Java artifact from my local build/libs folder to the cloud.

The Tool: SCP (Secure Copy)
I used the following command to securely upload the JAR:
scp -i C:\Users\Public\id_aws "C:\Users\...\java-app-1.0-SNAPSHOT.jar" ubuntu@<IP>:/home/ubuntu/

Translating Firewall to Security Group:
When my instructor added a firewall on DigitalOcean, I knew exactly what to do in AWS. I updated my Security Group in Terraform to open Port 8080, allowing traffic to reach my Spring Boot application.

4. Linux User Management & Security

For security best practices, I created a personal user: zacks.

The Steps taken:

Creation: sudo adduser zacks.
Permissions: I gave the user administrative power using sudo usermod -aG sudo zacks.
The Final SSH Boss: I mistakenly named my key file Authentication_keys. Linux ignores this, It must be named authorized_keys. Furthermore, I had to use chown to ensure the user zacks actually owned the file and chmod 600 to make it private.

sudo mv /home/zacks/.ssh/Authentication_keys /home/zacks/.ssh/authorized_keys
sudo chown -R zacks:zacks /home/zacks/.ssh
sudo chmod 600 /home/zacks/.ssh/authorized_keys

Conclusion

Today was a masterclass in troubleshooting. I learned that DevOps isn't just about writing code; it's about being adaptable. When one cloud door closed, I used Terraform to open a better one on AWS.

Infrastructure is live, the JAR is running, and the "Whitelabel Error Page" never looked so beautiful!

Day 17 of #30DaysofAWSTerraform: Blue-Green Deployment with Elastic Beanstalk (The Hard Way)

Zakariyau Mukhtar — Thu, 25 Dec 2025 14:38:27 +0000

Day 17 was one of those days that really tested my patience but also deepened my understanding of real-world deployment strategies. Today, I learned about Blue-Green deployment, how Elastic Beanstalk fits into that strategy, and how to actually swap environments safely without downtime. It wasn’t smooth at all; IAM policies almost broke my spirit but the lesson stuck.

What Blue-Green Deployment Really Is:

Blue-Green deployment is a strategy where you maintain two identical environments:

Blue → current production (stable).
Green → new version (staging). Instead of deploying directly to production, you deploy the new version to the green environment, test it thoroughly, and then swap traffic instantly. If something goes wrong, rollback is just another swap away. This drastically reduces downtime and deployment risk something every serious production system needs.

Why Elastic Beanstalk?

Elastic Beanstalk abstracts a lot of infrastructure complexity while still giving control when needed. It manages:

EC2 instances.
Load balancers.
Auto Scaling.
Health checks.
Application versions.

For this demo, Elastic Beanstalk made Blue-Green deployment practical, especially when paired with Terraform for infrastructure consistency.

Terraform Setup: Providers and IAM (Where the Pain Started)

I started with provider configuration and IAM roles and this is where things got tough. Elastic Beanstalk requires multiple IAM roles, and incorrect attachments will break everything.

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

provider "aws" {
  region = var.aws_region
}

The EC2 role for Elastic Beanstalk instances:

resource "aws_iam_role" "eb_ec2_role" {
  name = "${var.app_name}-eb-ec2-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { Service = "ec2.amazonaws.com" }
    }]
  })
}

Attaching the correct managed policies was critical and yes, I hit multiple errors here due to wrong role attachments.

Creating the Elastic Beanstalk Application:

Once IAM stopped fighting me, I defined the Elastic Beanstalk application itself:

resource "aws_elastic_beanstalk_application" "app" {
  name        = var.app_name
  description = "Blue-Green Deployment Demo Application"
}

I also created an S3 bucket to store application versions each version mapped to either blue or green.

Blue Environment (Production):

The blue environment represents production running version 1.0:

resource "aws_elastic_beanstalk_environment" "blue" {
  name                = "${var.app_name}-blue"
  application         = aws_elastic_beanstalk_application.app.name
  solution_stack_name = var.solution_stack_name
  version_label       = aws_elastic_beanstalk_application_version.v1.name

  setting {
    namespace = "aws:elasticbeanstalk:application:environment"
    name      = "Environment"
    value     = "blue"
  }
}

This environment served stable traffic and stayed untouched while testing the new version.

Green Environment (Staging):

The green environment hosted version 2.0 with new features:

resource "aws_elastic_beanstalk_environment" "green" {
  name                = "${var.app_name}-green"
  application         = aws_elastic_beanstalk_application.app.name
  solution_stack_name = var.solution_stack_name
  version_label       = aws_elastic_beanstalk_application_version.v2.name

  setting {
    namespace = "aws:elasticbeanstalk:application:environment"
    name      = "Environment"
    value     = "green"
  }
}

Both environments were load-balanced, scalable, and completely independent.

Swapping Blue and Green (The Cool Part):

After testing the green environment, I used a swap script to redirect traffic instantly:

aws elasticbeanstalk swap-environment-cnames \
  --source-environment-name "$BLUE_ENV" \
  --destination-environment-name "$GREEN_ENV" \
  --region "$REGION"

This swap takes 1–2 minutes, with near-zero downtime. Production traffic moves to green, and blue becomes the fallback.

Commands Used:

Throughout this setup, I relied on the basics:

terraform init.
terraform plan.
terraform apply --auto-approve.
terraform destroy --auto-approve.

Simple commands complex consequences.

Final Thoughts

Today was tough. IAM policies and attachments caused multiple failures, and Elastic Beanstalk doesn’t forgive mistakes. But that’s exactly why this day mattered. I didn’t just learn Blue-Green deployment in theory I felt it.

Day 17 reminded me that real DevOps is messy, but the payoff is systems that deploy safely, scale reliably, and recover fast.

On to Day 18 🚀

Day 16 : Managing IAM Users, Groups, and MFA at Scale with Terraform

Zakariyau Mukhtar — Fri, 19 Dec 2025 16:55:33 +0000

Day 16 of my #30DaysOfAWSTerraform challenge focused on one of the most sensitive parts of cloud infrastructure: identity and access management (IAM).Unlike EC2 or networking, IAM mistakes don’t usually “fail loudly” they create security risks. Today’s goal was to learn how to create, manage, and secure multiple IAM users at scale using Terraform.
This day was relatively straightforward conceptually, but the implementation forced me to think like a real administrator rather than a hobbyist.

What I Built

Using Terraform, I automated the creation of:

Multiple IAM users from a CSV file.
IAM login profiles with forced password reset.
Department-based IAM groups.
Conditional group memberships.
Custom IAM policies per department.
Mandatory MFA enforcement for all users.
Account-wide password policy.

All of this was done declaratively and reproducibly.

Creating Multiple IAM Users from CSV:

Instead of hardcoding users, I used a CSV file as the source of truth. Terraform’s csvdecode() function made this clean and scalable.

locals {
  users = csvdecode(file("users.csv"))
}

Each user was created dynamically using for_each:

resource "aws_iam_user" "users" {
  for_each = { for user in local.users : user.first_name => user }
  name = lower("${substr(each.value.first_name, 0, 1)}${each.value.last_name}")
  path = "/users/"

  tags = {
    DisplayName = "${each.value.first_name} ${each.value.last_name}"
    Department  = each.value.department
    JobTitle    = each.value.job_title
    Email       = each.value.email
    Phone       = each.value.phone
  }
}

This approach allowed me to scale user creation without touching Terraform code again adding a user only requires editing the CSV.

Enabling Console Access and Password Policies:

Each user received a login profile with a forced password reset on first login:

resource "aws_iam_user_login_profile" "users" {
  for_each = aws_iam_user.users

  user                    = each.value.name
  password_reset_required = true
}

I also enforced a strong account-wide password policy:

resource "aws_iam_account_password_policy" "strong" {
  minimum_password_length        = 10
  require_lowercase_characters   = true
  require_uppercase_characters   = true
  allow_users_to_change_password = true
  max_password_age               = 90
}

This ensures consistency and security across all users.

IAM Groups and Automatic Membership:

I created four IAM groups:

Management.
Sales.
Accounting.
HR. Membership was determined dynamically using tags instead of manual assignments.

Example Management group membership based on job title:

resource "aws_iam_group_membership" "management_members" {
  name  = "management-group-membership"
  group = aws_iam_group.management.name
  users = [
    for user in aws_iam_user.users :
    user.name
    if contains(keys(user.tags), "JobTitle") &&
       can(regex("Manager|CEO", user.tags.JobTitle))
  ]
}

This pattern removes human error and keeps access aligned with organizational roles.

Enforcing MFA for Every User:

One of the most important parts of today was forcing MFA. I created a custom IAM policy that:

Allows users to set up their own MFA devices.
Denies all AWS actions if MFA is not enabled.

resource "aws_iam_policy" "force_mfa" {
  name = "Force-MFA-Policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "DenyAllExceptMFASetupIfNoMFA"
        Effect = "Deny"
        NotAction = [
          "iam:CreateVirtualMFADevice",
          "iam:EnableMFADevice",
          "iam:GetUser",
          "sts:GetSessionToken",
          "iam:ChangePassword"
        ]
        Resource = "*"
        Condition = {
          BoolIfExists = {
            "aws:MultifactorAuthPresent" = "false"
          }
        }
      }
    ]
  })
}

This policy was attached to every user automatically:

resource "aws_iam_user_policy_attachment" "enforce_mfa" {
  for_each   = aws_iam_user.users
  user       = each.value.name
  policy_arn = aws_iam_policy.force_mfa.arn
}

Department-Specific Policies:

Each department received tailored permissions:

Management: Broad access, restricted IAM management.
Sales: Read-only access.
Accounting: Billing and cost management.
HR: IAM user and credential management only.

These policies were attached at the group level, not the user level a best practice.

Outputs and Visibility:

I exposed useful outputs for visibility and auditing:

output "group_members" {
  value = {
    Management = length(aws_iam_group_membership.management_members.users)
    Sales      = length(aws_iam_group_membership.sales_members.users)
    Accounting = length(aws_iam_group_membership.accounting_members.users)
    HR         = length(aws_iam_group_membership.hr_members.users)
  }
}

Final Thoughts

Day 16 showed me that IAM is not about permissions it’s about structure. Terraform forces discipline, consistency, and repeatability in access control, which is exactly what real organizations need.

No chaos today just clean, deliberate infrastructure.

On to Day 17.

Day 15:Building Multi-Region VPC Peering with Terraform

Zakariyau Mukhtar — Thu, 18 Dec 2025 14:50:29 +0000

Day 15 of my #30DaysOfAWSTerraform challenge was one of the most demanding so farnot because the concepts were impossible, but because this was the first time everything felt real-world messy. Today I worked extensively with VPC peering, multi-region infrastructure, routing, security groups, and Git conflicts the full DevOps experience.

What I Learned:

The core focus of today was understanding how VPC peering works beyond theory. I didn’t just connect two VPCs, I created three VPCs across three different AWS regions and connected all of them together:

Production VPC in us-east-1.
Testing VPC in us-west-2.
Development VPC in eu-west-2.

This immediately forced me to think about provider aliases, region isolation, and how AWS networking behaves when traffic crosses VPC and regional boundaries.
I also deepened my understanding of:

Route tables and why peering alone is not enough.
Internet Gateways and their role in outbound traffic.
Subnets and availability zones.
Security group ingress rules for controlled cross-VPC access.

Creating the VPCs (Terraform Code):

Each VPC was defined with its own provider alias and CIDR block. For example, the Production VPC:

resource "aws_vpc" "prod_vpc" {
  provider = aws.prod
  cidr_block = var.prod_vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support = true

  tags = {
    Name = "Production-VPC-${var.prod_A}"
    Environment = var.Environment
    Purpose = "VPC-Peering-Demo"
  }
}

I repeated this pattern for Testing and Development VPCs, each tied to its own AWS region.

Subnets, Internet Gateways and Route Tables:

Each VPC had:

A public subnet.
An Internet Gateway.
A route table with 0.0.0.0/0 pointing to the IGW.

Example Production Route Table:

resource "aws_route_table" "prod_rt" {
  provider = aws.prod
  vpc_id = aws_vpc.prod_vpc.id

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

Without properly associating route tables with subnets, nothing works and Terraform won’t warn you. This was a critical lesson.

VPC Peering Connections (The Core of the Day):

I created three peering connections:

Production ↔ Testing.
Production ↔ Development.
Testing ↔ Development.

Each peering required:

A requester connection.
An accepter connection.
Explicit routes in both VPC route tables.

Example Production to Testing peering:

resource "aws_vpc_peering_connection" "production_to_testing" {
  provider = aws.prod
  peer_vpc_id = aws_vpc.test_vpc.id
  vpc_id      = aws_vpc.prod_vpc.id
  peer_region = var.test_B
  auto_accept = false
}

And the accepter:

resource "aws_vpc_peering_connection_accepter" "testing_to_production" {
  provider = aws.test
  vpc_peering_connection_id = aws_vpc_peering_connection.production_to_testing.id
  auto_accept = true
}

Then the route entries the most commonly missed step:

resource "aws_route" "prod_to_test" {
  provider = aws.prod
  route_table_id = aws_route_table.prod_rt.id
  destination_cidr_block = var.test_vpc_cidr
  vpc_peering_connection_id = aws_vpc_peering_connection.production_to_testing.id
}

Without this, peering exists but traffic dies silently.

Security Groups and EC2 Validation:

To validate connectivity, I deployed EC2 instances in each VPC with security groups that allowed:

SSH (port 22)
ICMP (ping)
Cross-VPC CIDR access

Example Production Security Group ingress:

ingress {
  description = "SSH from Test and Dev VPC"
  from_port = 22
  to_port = 22
  protocol = "tcp"
  cidr_blocks = [
    var.test_vpc_cidr,
    var.dev_vpc_cidr
  ]
}

Each EC2 instance used Ubuntu 24.04 LTS, pulled via data sources, and included user-data scripts to install Apache and display region-specific info.

The Real Struggle: Git Merge Conflicts

This day was chaotic.

While pushing changes to Git, I ran into merge conflicts repeatedly. I ended up rewriting parts of the infrastructure three different times before I finally understood why the conflicts were happening.

It wasn’t Terraform’s fault.
It wasn’t AWS.
It was version control discipline.

That pain was worth it. I now understand merge conflicts at a deeper level not as errors, but as signals.

Final Thoughts

Day 15 taught me something important:
DevOps is not clean. It’s structured chaos.

VPC peering works beautifully when every dependency is correct. One missing route, one wrong CIDR, or one overlooked provider alias, and everything breaks silently.
Today, I didn’t just learn Terraform.
I learned how real infrastructure behaves under pressure.

On to Day 16.

Day 14 of #30DaysOfAWSTerraform: Hosting a Static Website with S3 and CloudFront

Zakariyau Mukhtar — Mon, 15 Dec 2025 19:11:31 +0000

Day 14 was all about static websites and how AWS handles them at scale. Before this lesson, I had a surface-level idea of what a static website was, but today made everything click from how files are stored, to how they are securely served globally using AWS services.

The core focus of today’s lesson was S3, CloudFront, and how Terraform ties everything together as Infrastructure as Code.

Understanding Static Websites

A static website is exactly what it sounds like a site that serves fixed content such as HTML, CSS, JavaScript, images, and assets. There’s no backend logic, no database queries, and no server-side rendering. What you upload is what users see.

This makes static websites:

Fast
Cheap to host
Highly scalable
Secure when configured correctly

AWS excels at this through Amazon S3 and Amazon CloudFront.

Deep Dive into Amazon S3

S3 (Simple Storage Service) is not just a storage bucket it’s a highly durable object storage service designed to store and retrieve any amount of data.

Key things I deeply understood today:

S3 stores objects, not filesystems
Every object is accessed via a unique key
S3 is globally durable but regionally hosted
Public access must be explicitly controlled

In my setup, I created an S3 bucket using Terraform:

resource "aws_s3_bucket" "firstbucket" {
  bucket = var.bucket_name
}

To prevent accidental public exposure, I added a public access block, which is critical for security:

resource "aws_s3_bucket_public_access_block" "block" {
  bucket = aws_s3_bucket.firstbucket.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

This ensures that the bucket cannot be accessed publicly unless explicitly allowed through CloudFront.

Uploading Website Files to S3

Instead of uploading files manually, Terraform can manage website content using aws_s3_object. This is powerful because your infrastructure and content stay in sync.

resource "aws_s3_object" "object" {
  for_each = fileset("${path.module}/www", "**/*")
  bucket   = aws_s3_bucket.firstbucket.id
  key      = each.value
  source   = "${path.module}/www/${each.value}"
  etag     = filemd5("${path.module}/www/${each.value}")

  content_type = lookup({
    "html" = "text/html",
    "css"  = "text/css",
    "js"   = "application/javascript",
    "json" = "application/json",
    "png"  = "image/png",
    "jpg"  = "image/jpeg",
    "svg"  = "image/svg+xml"
  }, split(".", each.value)[length(split(".", each.value)) - 1], "application/octet-stream")
}

This automatically uploads HTML, CSS, and JavaScript from the www/ directory into S3 with correct content types.

Introducing CloudFront (The Game Changer)

CloudFront is AWS’s Content Delivery Network (CDN). Instead of serving content directly from S3, CloudFront caches content at edge locations close to users, dramatically improving performance and security.

I created an Origin Access Control (OAC) so CloudFront can securely access the S3 bucket:

resource "aws_cloudfront_origin_access_control" "origin_access_control" {
  name                              = "demo-oac"
  origin_access_control_origin_type = "s3"
  signing_behavior                  = "always"
  signing_protocol                  = "sigv4"
}

Then I defined the CloudFront distribution:

resource "aws_cloudfront_distribution" "s3_distribution" {
  origin {
    domain_name              = aws_s3_bucket.firstbucket.bucket_regional_domain_name
    origin_access_control_id = aws_cloudfront_origin_access_control.origin_access_control.id
    origin_id                = local.origin_id
  }

  enabled             = true
  default_root_object = "index.html"

  default_cache_behavior {
    allowed_methods        = ["GET", "HEAD"]
    cached_methods         = ["GET", "HEAD"]
    target_origin_id       = local.origin_id
    viewer_protocol_policy = "redirect-to-https"
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

This configuration ensures:

HTTPS is enforced
Content is cached globally
S3 is never directly exposed to users

Locking Down S3 with Bucket Policy

To complete the security setup, I added a bucket policy allowing only CloudFront to access the S3 objects:

resource "aws_s3_bucket_policy" "allow_cf" {
  bucket = aws_s3_bucket.firstbucket.id

  policy = jsonencode({
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "cloudfront.amazonaws.com" }
      Action    = "s3:GetObject"
      Resource  = "${aws_s3_bucket.firstbucket.arn}/*"
    }]
  })
}

This is a best practice for production-grade static websites.

Challenge Faced

I couldn’t fully complete the deployment because my AWS account wasn’t approved to create CloudFront distributions. That was frustrating, but also a real-world lesson: permissions and account limits matter.

Even so, the Terraform configuration is solid and production-ready.

Final Thoughts

Day 14 was a big milestone. I now understand:

How static websites work on AWS
Why S3 is ideal for hosting static content
How CloudFront improves performance and security
How Terraform ties everything together cleanly

This wasn’t just theory, it was real infrastructure thinking.

On to Day 15

Day 13 : Understanding Terraform Data Sources Like a Human, Not a Robot

Zakariyau Mukhtar — Tue, 09 Dec 2025 18:25:17 +0000

Today’s session was one of those “lightbulb days” in Terraform the point where things finally click. Day 13 was all about Terraform Data Sources and honestly, this is one of the core concepts that separates beginners from engineers who actually understand infrastructure workflows.

Data Sources: The Missing Puzzle Piece:

I’ve been creating resources in Terraform for days EC2 instances, S3 buckets, IAM, and more but today I finally understood why Data Sources matter so much. While resources are things Terraform creates, data sources are things Terraform reads from AWS. This difference is massive. Data sources allow you to use existing AWS components instead of hardcoding IDs or manually copying values from your console. That means:

No more manually typing VPC IDs.
No more guessing subnets.
No more hunting for AMI IDs.
No more breaking infrastructure because an ID changed. Terraform stays synced with AWS, and your code becomes smarter, reusable and more consistent.

What I Built Today:

1. Fetch the Default VPC:

data "aws_vpc" "vpc_name" {
  filter {
    name   = "tag:Name"
    values = ["default"]
  }
}

Instead of hardcoding a VPC ID, this fetches the one tagged “default.”

Small change and big improvement in reliability.

2. Fetch a Subnet Inside that VPC:

data "aws_subnet" "shared" {
  filter {
    name   = "tag:Name"
    values = ["subneta"]
  }
  vpc_id = data.aws_vpc.vpc_name.id
}

This pulls the subnet tagged “subneta,” within the VPC I retrieved earlier.

Now Terraform can dynamically locate a subnet without me touching the AWS console.

3. Fetch the Latest Amazon Linux 2 AMI:

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

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

This is the cleanest way to ensure your instance always uses the latest stable Amazon Linux 2 image.

4. Deploy an EC2 Instance Using ONLY Dynamic Values:

resource "aws_instance" "example" {
  ami           = data.aws_ami.linux2.id
  instance_type = "t2.micro"
  subnet_id     = data.aws_subnet.shared.id
  tags          = var.tags
}

No hardcoded IDs.
No guesswork.
No outdated AMIs.
Everything is tied to real AWS values at the time of deployment.

Backend Configuration (S3 Remote State)

I also configured my backend for state storage:

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

This moved my Terraform state from local to AWS S3, enabling:

Team collaboration.
State locking.
Zero risk of losing state locally.
Better security and versioning. This is how real-world environments are structured.

Commands I Used:

Same workflow:

terraform init
terraform plan
terraform apply --auto-approve
terraform destroy --auto-approve Smooth, clean and predictable especially now that everything is dynamic.

My Experience Today

Day 13 was surprisingly straightforward compared to the last few days.

No major blockers.
No syntax confusion.
No AWS permission issues.

Just clean logic and a clearer understanding of how Terraform interacts with existing AWS infrastructure.

Data sources are the bridge between what you already have and what you're trying to build. Today made that crystal clear.

Final Thoughts

Data sources are easily one of the most powerful features in Terraform. They eliminate hardcoding, reduce errors, and make infrastructure code scalable and environment-aware.
Today felt like a big step forward, my Terraform code finally behaves like it belongs in production.

Day 11 & 12 of My #30DaysOfAWSTerraform Journey : Mastering Terraform Functions (Parts 1 & 2)

Zakariyau Mukhtar — Mon, 08 Dec 2025 18:01:28 +0000

Today’s learning felt like I unlocked “Terraform Superpowers.” Days 11 and 12 focused entirely on Terraform functions and honestly, this is the point where Terraform stops feeling like a configuration tool and starts behaving like a full scripting engine. These two days were packed with transformations, validations, formatting operations, type coercions, and even time-based computations. Everything I learned here answers a simple question:

“How do you make your Terraform code smarter, cleaner, and more automated?”

Let’s break it down.

What I Learned (Day 11 + 12 Combined):

1. String, Numeric, Type Conversion and Collection Functions:

I worked with:

lower(), substr(), replace() to clean bucket names
split(), concat(), toset() to structure lists and sets
max(), min(), sum(), abs() to compute costs
lookup() to select instance sizes based on environment
merge() to neatly combine tag maps

These functions allowed me to sanitize inputs, enforce formats, build dynamic rules, and build more reusable infrastructure.

2. Date & Time Functions:

This was one of my favorite parts. I generated:

timestamps with timestamp()
multiple time formats with formatdate()

This helped me create dynamic backup names like:

backup-20250212

It also reinforced something important:
format strings in Terraform are case-sensitive and that tripped me up until I figured it out.

3. File Functions & JSON Handling

Terraform can:

check if a file exists (fileexists()).
read file contents (file()).
parse JSON into an object (jsondecode()). I used this to read a real config.json file and push that JSON directly into AWS Secrets Manager. That alone felt like a full real-world DevOps task.

4. Validations & Error Handling:

The validation block in variables saved me from bad inputs.
I enforced:

instance types starting with t2 or t3
backup names ending with _backup

This makes Terraform behave like it has guardrails.

Practical Tasks I Completed

1. Sanitizing Inputs for S3 Buckets & Projects:

I cleaned up project and bucket names automatically:

converted to lowercase.
removed spaces.
trimmed unwanted symbols.
ensured bucket names stayed within the AWS length limit.

This ensures Terraform produces valid AWS names every time.

2. Generating Dynamic Security Group Rules

With split() and for expressions, I built security group rules from a comma-separated string:

80,443,8080,3306

Terraform automatically created:

rule names
port numbers
descriptions

The final output was clean and automated.

3. Dynamically Selecting Instance Sizes

Using:

lookup(var.instance_sizes, var.environment, "t2.micro")

Terraform selects the right instance size based on the environment. No manual switching.

4. Reading Config from JSON and Storing It in Secrets Manager

This was the most real-world part:

Detected if the file existed
Decoded the JSON
Passed it into AWS Secrets Manager
Output the secret ARN

Real DevOps workflow unlocked right here.

Challenges I Faced

1. Case Sensitivity in `formatdate()`

I spent time debugging formatted timestamps because I didn’t know the format string was case-sensitive.
Example:

YYYYMMDD  ≠  yyyymmdd

Terraform humbled me.

2. Missing IAM Permission for Secrets Manager

Terraform kept failing until I realized I hadn’t added SecretsManagerReadWrite permissions to my IAM user.
Once I fixed that, everything ran smoothly.

Commands I Used

terraform init
terraform plan
terraform apply --auto-approve
terraform destroy

Simple commands but yet powerful execution.

These two days changed the way I think about Terraform. Before now, I was writing static infrastructure. After Day 11 and 12, I’m writingcintelligent infrastructure.

Functions allowed me to:

sanitize inputs.
validate configurations.
automate naming.
compute values.
parse files.
build dynamic outputs.
and control infrastructure behavior using pure logic.

This is the kind of knowledge that separates someone who “uses Terraform” from someone who engineers Terraform solutions.

Tomorrow, we climb another level.
But today, I’m proud of this milestone.

Day 10 : Conditionals, Dynamic Blocks & Splat Expressions

Zakariyau Mukhtar — Thu, 04 Dec 2025 18:07:45 +0000

Today was one of those days where everything just clicked. I didn’t just learn Terraform concepts, I finally felt like I understood why they matter and how they fit into real-world infrastructure. Compared to some earlier days where things felt abstract. Day 10 was smooth, logical, and honestly very satisfying.
I focused on three main concepts today: conditional expressions, dynamic blocks and splat expressions. All three are tools that help clean up Terraform configurations, reduce repetition and make infrastructure adapt to inputs automatically. Once I saw them in action, it finally made sense why more experienced DevOps engineers rely on them heavily.

1. Conditional Expressions (Choosing Resources Based on Environment):

The first thing I learned was how to use conditional expressions in Terraform. These allow you to change behavior based on variables. Instead of hardcoding instance types, you can make Terraform decide automatically.

In my aws_instance resource, I used:

instance_type = var.environment == "dev" ? "t2.micro" : "t3.micro"

That one line alone felt powerful, It means:

If the environment is dev, use a t2.micro instance.
Otherwise staging, production, anything else use a t3.micro.

It removes the headache of manually editing resource blocks whenever the environment changes. Just set the environment in terraform.tfvars, run the plan, and Terraform decides for you.

In my case, I set:

environment = "staging"
instance_count = 2

Terraform automatically picked t3.micro exactly as expected, Clean and efficient.

2. Dynamic Blocks (Generating Nested Arguments Automatically):

Next, I went deeper into dynamic blocks, which turned out to be one of the most useful features so far. Instead of manually writing multiple ingress rules inside a security group, I used a dynamic block to loop through all rules defined in ingress_rules.

My block looked like this:

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

Terraform took each rule from the variable and automatically generated the nested ingress configurations inside the security group. No duplication, No messy code, Just one clean dynamic block. The ingress_rules variable contains two rules: port 80 and port 443.
Terraform turned them into two separate ingress blocks without me writing them manually. This is one of those features that separates beginners from people who are starting to structure Terraform properly.

3. Splat Expressions (Collecting Values From Multiple Resources) :

Since I deployed multiple EC2 instances (thanks to count = var.instance_count), I had multiple instance IDs. Instead of referencing each one separately, I used a splat expression to grab all their IDs at once:

locals {
  all_instance_ids = aws_instance.example[*].id
}

Then I output them:

output "instance_ids" {
  value = local.all_instance_ids
}

After running:

tf init
tf plan

Terraform clearly showed all instance IDs generated. Simple, elegant and exactly what splat expressions are meant for.

Commands I Used:

Nothing complicated today just the essentials:

tf init : initialize Terraform.
tf plan : preview changes.

5. Were the Tasks Hard?:

Not at all and that’s not because they were easy, but because every lesson before this point built up to today. By the time I started writing conditionals, dynamic blocks, and splat expressions, the syntax felt natural.

Everything was logical, predictable and connected to real Terraform use cases.

Final Thoughts

Day 10 wasn’t heavy or confusing. It was clean, organized, and practical. I used features that real DevOps engineers rely on daily:

Selecting resources per environment
Dynamically generating nested blocks
Collecting attributes from multiple resources

The best part is that I didn’t just follow instructions I understood why each part matters. And If i keep at this pace, Terraform won’t just be something I’m learning. It’ll be something I can confidently use to manage infrastructure the right way.

Day 9 of #30DaysofAWSTerraform: Mastering Lifecycle Rules (This One Humbled Me )

Zakariyau Mukhtar — Thu, 04 Dec 2025 11:16:05 +0000

Day 9 was easily one of the most ah, so this is what real Terraform work looks like moments for me.
Lifecycle rules are one of those things people don’t talk about enough, but they are absolutely critical once you start managing real infrastructure not just classroom examples.
Today was tough. I struggled, but the struggle paid off because everything finally clicked.

What I Learned Today:

Lifecycle Rules:

I finally understood how Terraform decides when to replace a resource, when to keep it, and what to do if something changes.

The lifecycle block gives you deep control, and today I explored:


prevent_destroy

replace_triggered_by

ignore_changes

preconditions

postconditions

Each one solves a real problem that Terraform can’t magically guess.

1 - create_before_destroy (No more downtime):

I created an EC2 instance where Terraform should provision the new one before terminating the old one.

lifecycle {
  create_before_destroy = true
}

This is perfect for production environments. If an update happens, Terraform won’t delete your server first before it replaces it safely.

My web_server resource used this rule, and seeing Terraform gracefully handle replacement was actually beautiful.

2 - prevent_destroy (Protecting Critical Resources):

Next, I worked on an S3 bucket that represents critical production data. Even if someone tries a terraform destroy, Terraform should refuse.

lifecycle {
  prevent_destroy = false
}

Normally this should be true, but in my setup, it was kept false for learning purposes. Still, the concept is clear because this flag is how you avoid accidental disasters.

3 - ignore_changes (Keeping Terraform From Being Too Strict):

I used this rule in the AutoScaling Group:

lifecycle {
  ignore_changes = [
    desired_capacity
  ]
}

This tells Terraform:
“Don’t fight me over these attributes. If AWS auto-scales it, don’t force it back.” It prevents an endless cycle of “Terraform wants 2 AWS scaled to 3.”

4 - replace_triggered_by (Automatic Replacement When Another Resource Changes):

This one was interesting and super practical. I linked an EC2 instance to a security group using:

replace_triggered_by = [
  aws_security_group.app_sg.id
]

Meaning:
If the security group changes, replace the instance automatically.

5 - Preconditions & Postconditions Validating Before and After Creation: This is where things got really smart.

Precondition Example:

Before creating a bucket, I validate the region:

precondition {
  condition     = contains(var.allowed_regions, data.aws_region.current.name)
  error_message = "Region not allowed!"
}

Terraform stops immediately if the region isn’t permitted.

Postcondition Example:

After creating a bucket, I validated tags:

postcondition {
  condition     = contains(keys(self.tags), "Compliance")
  error_message = "Bucket must have a Compliance tag!"
}

It’s like giving Terraform the ability to self-audit.

Commands I Ran:

These were essential for testing lifecycles:

terraform plan.

terraform apply --auto-approve.

terraform destroy --auto-approve.

terraform output.

This day involved a lot of destroying and recreating resources to fully understand lifecycle behavior.

Did I Struggle?

Absolutely. Lifecycle rules feel simple when someone explains them, but once you start applying them across EC2, S3, ASG, SG, and templates…
your brain melts a little. But after a few failed applies, bucket recreations, and region validation errors, everything started making perfect sense. This was one of the most important days so far.

Day 9 made Terraform feel like a real-world IaC tool, not just resource and variable definitions. Now I understand why lifecycle rules are considered advanced. They give you the power to prevent accidental disasters, manage downtime, control how replacements happen, apply compliance, enforce guardrails.

Another big step forward.

Day 8: Terraform Finally Makes Sense (Loops, Count, For_Each & Dependencies)

Zakariyau Mukhtar — Wed, 03 Dec 2025 08:50:33 +0000

Today was one of those days where everything just clicked.
No stress, no confusion… just straight understanding. Terraform started feeling less like “DevOps theory” and more like something I can actually control confidently.

What I Learned

I finally understood meta-arguments especially count, for_each, and depends_on.
Learned how to use count.index to loop through lists.
Learned how for_each works with sets and how it gives better resource naming.
Saw why dependencies matter so Terraform doesn’t rush resources in the wrong order.

Honestly, these concepts looked scary from afar, but once I practiced them… they were simple.

What I Built Today

Created two S3 buckets using `count`

Used a list of names, looped with count.index, and everything created perfectly.

Created two more S3 buckets using `for_each`

Used a set this time and referenced bucket names using each.value.
Added depends_on just to make sure Terraform behaves.

Displayed bucket names and IDs

Used for-expressions to print out everything cleanly with tf output.

Commands I ran

tf plan
tf apply --auto-approve
tf output

Everything worked without drama.

A Bit of My Code:

resource aws_s3_bucket "bucket5" { 
  count = 2
  bucket = var.bucket_name[count.index]
  tags = var.tags
}

output "s3_bucket_names" {
  value = [for bucket in aws_s3_bucket.bucket1 : bucket.bucket]
}

Today was smooth.
The tasks didn’t overwhelm me at all.
It felt like the previous lessons were preparing me for today, and everything connected naturally.

The more I practice Terraform, the more I feel like:

“Okay… I can actually do this DevOps thing.”

DAY 8 :

Key Lessons from Day 8

count = great for lists
for_each = cleaner when you want unique names
Sets work nicely with for_each
depends_on prevents Terraform from rushing
For-expressions make outputs neat and professional