DEV Community: Anthony Uketui

Lambda + ALB 503 Error Debugging Guide

Anthony Uketui — Tue, 10 Mar 2026 11:12:04 +0000

Debugging AWS Lambda + ALB 503 Errors: A Step‑by‑Step Guide to Event Format Mismatches

When I first put an AWS Lambda behind an Application Load Balancer (ALB), everything looked correct:

The Lambda worked perfectly when tested directly.
The ALB target group was configured for Lambda.
Listener rules and routing looked fine.
Permissions were in place.

But calling the Lambda through the ALB kept returning:

503 Service Unavailable

Meanwhile, the same Lambda worked through a Function URL and API Gateway v2. The root cause turned out to be a subtle event format mismatch between what the Lambda handler expected and what ALB actually sends.

This post walks through the exact debugging steps, how I identified the mismatch, and how to fix it.

Step 1: Verify Lambda Function Health

Estimated Time: 2–3 minutes

Action: Test the Lambda function directly.

Use a Function URL or the Lambda console test feature.
Confirm that the function executes successfully.

Expected Outcome: Lambda works fine in isolation.

Key Insight:

If the Lambda works when tested directly, the issue is in the integration layer (ALB), not the Lambda code itself.

Step 2: Check ALB Target Group Configuration

Estimated Time: 5 minutes

Action: Verify your ALB target group.

Target type: lambda
Lambda function registered as target
Health checks: disabled (normal for Lambda)
Target status: unavailable (expected for Lambda targets)

Key Insight:

“Unavailable” status with disabled health checks is normal for Lambda targets — it is not the cause of 503 errors.

Step 3: Verify ALB Permissions

Estimated Time: 3 minutes

Action: Check the Lambda resource policy to ensure ALB can invoke the function:

aws lambda get-policy --function-name my-lambda-function

Verify:

The ALB has lambda:InvokeFunction permission.
The ALB ARN is present in the policy.

Key Insight:

Missing permissions would usually result in 403 or 502 errors, not 503. Still, it’s worth ruling out early.

Step 4: Analyze ALB Listener Rules

Estimated Time: 10 minutes

Action: Check routing configuration on the ALB listener.

For example:

Rule priority: 155
Path pattern: /plugin/*
Host header: api.example.com
Target group: MY-LAMBDA-TG

Key Insight:

ALB routing is strict — both path and host header must match exactly. A mismatch here can easily cause requests to hit the wrong target or no target at all.

Step 5: Test with Correct Routing

Estimated Time: 5 minutes

Action: Hit the ALB with the correct host and path.

curl -H "Host: api.example.com" https://my-alb-123456.eu-west-2.elb.amazonaws.com/plugin/test

Result: In my case, this still returned 503, even though routing looked correct.

Key Insight:

Correct routing alone does not guarantee success. If the Lambda works directly but fails through the ALB, start suspecting an event format mismatch.

Step 6: Compare Working vs Non‑Working Scenarios

Estimated Time: 5 minutes

Pattern Recognition:

Function URL: works
API Gateway v2: works
ALB: fails (503)

Key Insight:

The working integrations (Function URL and API Gateway v2) share the same event format, which ALB does not use. That difference becomes important.

Step 7: Examine the Lambda Handler Signature

Estimated Time: 3 minutes

Action: Inspect the Lambda handler to see what type of event it expects.

For example (pseudo-steps):

aws lambda get-function --function-name my-lambda-function
# Then inspect / decompile the handler class if needed
javap -cp . -public com.example.demo.LambdaRequestHandler

Handler Signature Example (Java):

public class LambdaRequestHandler implements RequestHandler<APIGatewayV2HTTPEvent, LambdaResponse> {
    @Override
    public LambdaResponse handleRequest(APIGatewayV2HTTPEvent event, Context context) {
        // ...
    }
}

Key Insight:

The handler here expects APIGatewayV2HTTPEvent, which is the event format used by API Gateway HTTP APIs and Function URLs — not the ApplicationLoadBalancerRequestEvent style payload that ALB sends.

Step 8: Analyze CloudWatch Logs

Estimated Time: 2 minutes

Action: Look for exceptions in CloudWatch Logs.

aws logs filter-log-events \
  --log-group-name "/aws/lambda/my-lambda-function" \
  --filter-pattern "Exception" \
  --max-items 5

Example Error:

NullPointerException: Cannot invoke "String.hashCode()" because "<localX>" is null
    at com.example.demo.LambdaRequestHandler.handleRequest(LambdaRequestHandler.java:77)

Root Cause:

Because the handler expects a specific JSON structure (APIGatewayV2HTTPEvent), it tries to access fields that don’t exist in the ALB event → resulting in NullPointerException and ultimately a 503 from ALB.

Step 9: Identify the Event Format Mismatch

Estimated Time: 2 minutes

Let’s compare the incoming event shapes.

Expected by Lambda (API Gateway v2 / Function URL):

{
  "version": "2.0",
  "routeKey": "POST /plugin",
  "rawPath": "/plugin/payment",
  "httpMethod": "POST",
  "headers": { "...": "..." },
  "body": "..."
}

Sent by ALB:

{
  "requestContext": { "elb": { /* ... */ } },
  "httpMethod": "POST",
  "path": "/plugin/payment",
  "headers": { "...": "..." },
  "body": "..."
}

Problem:

The JSON structure is different. Fields your code assumes exist (e.g., version, routeKey, rawPath) are not present in the ALB event. Accessing them directly leads to NullPointerException and a 503 at the ALB level.

Step 10: Verify with Test Events

Estimated Time: 3 minutes

You can simulate both event types in the Lambda console.

ALB Test Event (will fail if your handler expects API Gateway v2):

{
  "requestContext": {
    "elb": {
      "targetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/my-target-group/1234567890abcdef"
    }
  },
  "httpMethod": "POST",
  "path": "/plugin/payment",
  "headers": {
    "content-type": "application/json"
  },
  "body": "{\"test\": \"data\"}"
}

API Gateway v2 Test Event (will work with APIGatewayV2HTTPEvent handler):

{
  "version": "2.0",
  "routeKey": "POST /plugin",
  "rawPath": "/plugin/payment",
  "httpMethod": "POST",
  "headers": {
    "content-type": "application/json"
  },
  "body": "{\"test\": \"data\"}"
}

Result:

If the API Gateway v2 event works but the ALB event fails with an exception, you’ve confirmed the event format mismatch as the root cause.

The Fix: Update the Lambda Handler to Support ALB

Once you know the issue is an event format mismatch, you have two main options:

Option 1: Change the Handler Input Type to ALB’s Event

For Java, for example:

Before (expects API Gateway v2):

import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.events.APIGatewayV2HTTPEvent;

public class LambdaRequestHandler implements RequestHandler<APIGatewayV2HTTPEvent, LambdaResponse> {
    @Override
    public LambdaResponse handleRequest(APIGatewayV2HTTPEvent event, Context context) {
        // Your existing logic
    }
}

After (expects ALB event):

import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.events.ApplicationLoadBalancerRequestEvent;

public class LambdaRequestHandler implements RequestHandler<ApplicationLoadBalancerRequestEvent, LambdaResponse> {
    @Override
    public LambdaResponse handleRequest(ApplicationLoadBalancerRequestEvent event, Context context) {
        // Adapt your logic to read from ALB's event shape:
        // event.getPath(), event.getHttpMethod(), event.getHeaders(), event.getBody(), etc.
    }
}

This makes the function compatible with ALB’s event structure.

Option 2: Use an Adapter Layer

If you need to support multiple event sources (e.g., API Gateway v2 and ALB) with the same business logic:

Accept the raw event (or use a common internal model).
Detect which event type you received (ALB vs API Gateway v2).
Map it into a unified internal request object.
Pass that object to your core handler logic.

Conceptually:

public class LambdaEntryPoint implements RequestHandler<Map<String, Object>, LambdaResponse> {
    @Override
    public LambdaResponse handleRequest(Map<String, Object> rawEvent, Context context) {
        InternalRequest request = EventAdapter.toInternalRequest(rawEvent);
        return CoreHandler.handle(request);
    }
}

This pattern decouples your core business logic from AWS-specific event shapes.

Quick Diagnosis Checklist for Lambda + ALB 503 Errors

Step	Action
Function Health	Test Lambda directly
Permissions	Confirm ALB invoke policy
Routing Rules	Path & host header check
Event Format	Compare working vs failing integration
Logs	Check for NPE or other stack traces

Common Gotchas:

Ignoring ALB event format.
Assuming Lambda target health status matters for 503s.
Missing Host header or path mismatch.
Testing with the wrong event data in the console.
Handler tightly coupled to one event type (e.g., API Gateway v2 only).

Key Takeaways

Lambda + ALB 503 errors can also happen due to event format mismatch, not just networking or permissions.
The handler signature dictates the expected input. If it expects APIGatewayV2HTTPEvent, it won’t magically understand ALB’s event format.
Function URLs and API Gateway v2 share the same event format, so a handler that works there may still fail behind an ALB.
ALB sends a different JSON structure (e.g., requestContext.elb, different path fields), which can break your code if you assume API Gateway-style fields.
CloudWatch logs reveal stack traces and NPEs — always check them first when debugging 503s.

IAM Policies vs Resource Policies: Lessons from Production (and the Gym)

Anthony Uketui — Tue, 09 Dec 2025 13:08:37 +0000

Early in my AWS journey, I ran into a problem that had me scratching my head for hours.

A frontend engineer came up to me:

"Tony, I just want users to see our app logos and images, but it’s not working. They keep getting denied."

I double-checked the IAM permissions—everything looked fine. The user had the right access. So why were people still blocked?

It wasn’t IAM at all. It was the S3 bucket’s resource policy.

That’s when it clicked: managing AWS access is a lot like managing a gym or sticking to a disciplined fitness routine.

Before you say how...

Let me explain.

IAM Policies = Your Personal Trainer

IAM policies are like your personal trainer. They define what you (the identity) are allowed to do:

Can you lift weights today?

Can you run on the treadmill?

Can you skip cardio?

In AWS, IAM policies attach to users, groups, or roles. They control what actions an identity can perform and on which resources.

In production, I also enforced MFA for all IAM users. Think of it like adding a second checkpoint before entering a VIP gym area—you might have the keycard (password), but without the fingerprint (MFA), you can’t get in. Simple, but it drastically increases security.

Resource Policies = The Gym Rules

Resource policies are like the rules posted on the gym wall. Even if your trainer gives you permission, the rules might still restrict your access:

Only VIP members can use certain equipment
Some areas are off-limits

In AWS, resource policies attach directly to resources, like S3 buckets, Lambda functions, or SQS queues. They define who can access the resource, including other AWS accounts or the public.

Here’s what I did in production:

ALB Logs: Edited the bucket policy so our Application Load Balancer could send access logs safely, without extra permissions.

Frontend Images/Logos: Created a bucket policy allowing users to read logos and images—but blocked access to sensitive files. Users got exactly what they needed.

Scaling Access: IAM vs Resource Policies

One thing I learned quickly: scale changes everything.

IAM policies scale best for identities. One policy can manage multiple users, groups, or roles. Perfect for internal teams.

Resource policies scale best for resources. When sharing across accounts or publicly, resource policies give the resource control over access.

Using both together is essential. IAM ensures users only do what they should, while resource policies ensure resources themselves are protected—even if IAM permissions exist.

Example: Our financial reports bucket had IAM permissions for finance guys, but the resource policy restricted access to our AWS account only. Layered security prevented accidental or malicious access and gave us peace of mind.

Layered Security = Layered Discipline
OOps that sounded cringe. haha

But just like weight loss or fitness, success in AWS access control comes from layers of discipline:

IAM = your workout plan → defines what identities can do
Resource policy = gym rules → defines who can access resources

Both together produce sustainable results which ultimately prevents mistakes, leaks, or misuse.

Ignoring one layer is like skipping cardio or not tracking calories.

You might get some results, but you’ll eventually hit problems.

In AWS, ignoring resource policies while relying solely on IAM can lead to “mystery denied” errors and frustrated users.

Takeaways from the battlefield

Always check both IAM and resource policies. A deny in either will block access.

Enforce MFA. It’s a small step with huge security payoff.

Use resource policies for cross-account or public access—especially when sharing logs, images, or APIs.

Test every access path. Users may have the right IAM permissions but still get blocked.

Think in layers.

Identity control + resource control = secure, scalable access.

Cheers

CI/CD for Infrastructure That Actually Works.

Anthony Uketui — Sat, 13 Sep 2025 10:58:09 +0000

Moving beyond demos: secure identity and cost visibility

Why Infrastructure Pipelines Still Fail

Too often, Terraform runs still happen on laptops with static AWS keys. The result?

Credentials at risk — long-lived keys sitting in repos or local machines
Undocumented changes — no audit trail, no shared visibility
Environment drift — dev, staging, and prod no longer match
Forgotten test resources — quietly inflating cloud bills

Running IaC this way feels fast — until it breaks consistency, costs money, or exposes credentials.

CI/CD fixes this, but to move beyond a “demo pipeline,” two practices make the difference in production:

OIDC-based authentication → no long-lived credentials
Cost visibility in PRs → prevent financial surprises

The 8 Steps of CI/CD (Infrastructure Edition)

Code pushed → pipeline triggers
Build → package artifact / generate Terraform plan
Validate → syntax check, terraform validate
Scan → security/compliance checks
Deploy to dev/staging → safe sandbox
Integration tests → real environment validation
Deploy to prod → gated promotion
Monitor → logs, costs, drift

This is the same framework as app pipelines — only the artifact changes.

Production-Ready Differentiators

1. OIDC: Secure, Short-Lived Credentials

Instead of storing AWS keys in GitHub secrets, pipelines use OIDC to assume roles dynamically.

Short-lived credentials, nothing to leak
Environment-specific IAM roles (dev/staging/prod)
Every assumption logged in CloudTrail

Minimal AWS trust policy for GitHub OIDC (example):

resource "aws_iam_role" "terraform_dev" {
  name = "uketui-terraform-cicd-dev"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Federated = aws_iam_openid_connect_provider.github.arn
        }
        Action = "sts:AssumeRoleWithWebIdentity"
        Condition = {
          StringEquals = {
            "token.actions.githubusercontent.com:sub" = "repo:Anthonyuketui/Terraform-Project-with-Multi-Environment-Support-on-AWS:environment:dev"
            "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
          }
        }
      }
    ]
  })
}

2. Cost Visibility: Infracost in PRs

With a single step, you can post cost estimates into pull requests after terraform plan.

Example PR comment:

This puts financial awareness into the code review process. A financial mistake gets caught before merge, not on the next AWS bill.

Example Dev Pipeline (GitHub Actions)

This workflow runs in a dev environment for iteration. It’s intentionally lightweight, but notice how it already includes the production-grade practices (OIDC, cost checks, environment isolation) that make the same design safe to scale into staging and prod.

name: Terraform Dev DevSecOps Pipeline

on:
  pull_request:
    branches:
      - dev
  push:
    branches:
      - dev

jobs:
  cost-analysis:
    runs-on: ubuntu-latest
    environment: dev
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Run Infracost
        uses: infracost/actions/setup@v2
        with:
          api-key: ${{ secrets.INFRACOST_API_KEY }}

      - name: Generate Infracost diff
        run: |
          cd environments/dev
          terraform init -backend=false
          infracost breakdown --path . \
            --format table \
            --out-file cost-estimate.txt
      - name: Output cost estimate
        run: cat environments/dev/cost-estimate.txt

      - name: Post cost estimate on PR
        if: github.event_name == 'pull_request'
        run: |
          body="#### Infracost Estimate
          \`\`\`
          $(cat environments/dev/cost-estimate.txt)
          \`\`\`"

          echo "comment=${body}" >> $GITHUB_OUTPUT
        id: cost_estimate

      - name: Add PR comment
        if: github.event_name == 'pull_request'
        uses: actions/github-script@v6
        with:
          script: |
            const body = `${{ steps.cost_estimate.outputs.comment }}`;
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: body
            });

  terraform-dev:
    runs-on: ubuntu-latest
    environment: dev
    needs: cost-analysis

    permissions:
      id-token: write
      contents: read

    env:
      TF_IN_AUTOMATION: true

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.TERRAFORM_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Terraform Format Check
        working-directory: environments/dev
        run: terraform fmt -recursive


      - name: Terraform Init
        working-directory: environments/dev
        run: terraform init -backend-config=backend.tfvars

      - name: Terraform Validate
        working-directory: environments/dev
        run: terraform validate

      - name: Terraform Plan
        working-directory: environments/dev
        run: terraform plan -var-file=terraform.tfvars -out=tfplan

      # -------------------------
      # Optional: Conftest (policy checks)
      # -------------------------
      # - name: Run Conftest
      #   uses: instrumenta/conftest-action@master
      #   with:
      #     files: environments/dev/tfplan
      #     policy: policy/

      # -------------------------
      # Optional: Security checks (uncomment for strict DevSecOps)
      # -------------------------
      # security-checks:
      #   runs-on: ubuntu-latest
      #   steps:
      #     - name: Checkout code
      #       uses: actions/checkout@v4
      #
      #     - name: Run Checkov
      #       uses: bridgecrewio/checkov-action@v12
      #       with:
      #         directory: environments/dev
      #         framework: terraform
      #         skip_check: CKV_AWS_79,CKV_AWS_126
      #
      #     - name: Run tfsec
      #       uses: aquasecurity/tfsec-action@v1.0.3
      #       with:
      #         working_directory: environments/dev
      #
      #     - name: Run Terrascan
      #       uses: tenable/terrascan-action@main
      #       with:
      #         iac_type: 'terraform'
      #         iac_dir: 'environments/dev'

      - name: Terraform Apply (on push only)
        if: github.event_name == 'push'
        working-directory: environments/dev
        run: terraform apply -auto-approve tfplan

For staging/prod, add approval gates and stricter IAM roles.

Multi-Environment Setup

Use separate directories and state backends:

├── environments/
│   ├── dev/
│   ├── staging/
│   └── prod/
├── modules/
└── .github/workflows/

Each environment:

Own terraform.tfvars + backend.tfvars
Own S3 bucket + DynamoDB lock table
Role isolation via IAM

Why This Matters

For engineers: this structure eliminates environment drift and makes infra deployments reproducible.
For managers: it reduces credential risk, prevents surprise costs, and creates a clear audit trail.

Building a Production-Ready Terraform Project with Multi-Environment Support on AWS

Anthony Uketui — Fri, 29 Aug 2025 12:52:53 +0000

When I started this project, my goal was simple but ambitious. I wanted to build a production-ready infrastructure that could automatically scale based on demand. I also wanted to organize everything in a way that supports multiple environments like dev and prod.

I’ll walk you through my full process, including the reasoning behind each step, challenges I faced, and how I resolved them.

I'd also share snippets of my code

But, here's the code if you want to follow along: https://tinyurl.com/aedduwdm

Step 1: Project Structure and Multi-Environment Setup

I wanted to keep my project modular and clean. To achieve this, I structured my directory in this way:

Modules contain reusable building blocks like VPC, ALB, EC2, RDS, and Monitoring.
Environments (dev and prod) each have their own main.tf and terraform.tfvars files that reference the modules.

This structure makes it easy to manage different configurations without duplicating code.

Step 2: Defining the VPC

My first step was to create a dedicated VPC with public and private subnets. Public subnets are for load balancers, and private subnets are for EC2 and RDS.

Code Snippet (VPC module)

resource "aws_vpc" "this" {
  cidr_block = var.vpc_cidr
  tags       = { Name = "${var.env}-vpc" }
}

I chose to keep the database and application instances in private subnets for security reasons.

Step 3: Application Load Balancer (ALB)

The ALB distributes traffic across EC2 instances. This ensures high availability.

Code Snippet (ALB module)

resource "aws_lb" "this" {
  name               = "${var.env}-alb"
  load_balancer_type = "application"
  subnets            = var.public_subnets
}

By using public subnets, the ALB became internet-facing, while the EC2 instances behind it stayed private.

Step 4: EC2 Auto Scaling Group

Next, I set up EC2 instances with auto scaling. This way, when CPU usage is high, new instances are launched automatically.

Code Snippet (EC2 module)

resource "aws_autoscaling_group" "this" {
  desired_capacity     = var.desired_capacity
  max_size             = var.max_size
  min_size             = var.min_size
  vpc_zone_identifier  = var.private_subnets
}

I used Amazon Linux 2 AMI and passed in user data through a template to bootstrap the instances.

Step 5: RDS Database Setup

For the database, I used Amazon RDS with MySQL. One challenge here was how to handle credentials securely.

At first, I hardcoded them, but I quickly realized that wasn’t safe. I switched to AWS Secrets Manager combined with a random password generator.

Code Snippet (RDS module)

resource "random_password" "db_password" {
  length  = 16
  special = true
}

resource "aws_secretsmanager_secret" "db_pwd" {
  name = "${var.env}/db_password"
}

This allowed me to store the password securely and avoid exposing it in my code.

Step 6: Monitoring and Alerts

I didn’t want to stop at just provisioning resources. I also wanted monitoring and alerts for key components like EC2, ALB, and RDS.

I used CloudWatch Alarms with SNS topics to send email alerts.

Code Snippet (Monitoring module)

resource "aws_cloudwatch_metric_alarm" "cpu_high" {
  alarm_name          = "${var.env}-cpu-high"
  metric_name         = "CPUUtilization"
  threshold           = 70
  comparison_operator = "GreaterThanThreshold"
  namespace           = "AWS/EC2"
  statistic           = "Average"
  period              = 300
  evaluation_periods  = 2
  alarm_actions       = [aws_sns_topic.alerts.arn]
}

This way, I get notified if something goes wrong.

Step 7: Multi-Environment Variables

Each environment has its own terraform.tfvars file. For example, my dev environment uses smaller instances while prod uses larger ones.

Dev `terraform.tfvars`

environment = "dev"
region      = "us-east-1"
instance_type = "t3.micro"
desired_capacity = 1
db_instance_class = "db.t3.micro"

Prod `terraform.tfvars`

environment = "prod"
region      = "us-east-1"
instance_type = "t3.medium"
desired_capacity = 2
db_instance_class = "db.t3.medium"

This separation made it easy to spin up lightweight dev infrastructure without affecting production.

Dev Environment

Prod Environment

Step 8: Running the Project

Here are the commands I used to apply everything:

cd envs/dev
terraform init
terraform plan -var-file="terraform.tfvars"
terraform apply -var-file="terraform.tfvars"

cd ../prod
terraform init
terraform plan -var-file="terraform.tfvars"
terraform apply -var-file="terraform.tfvars"

This workflow gave me a smooth way to deploy separate environments using the same modules.

Challenges and How I Solved Them

Hardcoding DB credentials: Initially I put the password directly in code. I later switched to using Secrets Manager with random_password to improve security.
Auto scaling not attaching correctly to ALB: At first, my instances weren’t registering as healthy. The fix was to ensure the security groups allowed the right ports and the target group health checks matched the app.
Multi-environment management: I struggled with duplication until I split logic into modules and kept only environment-specific variables in tfvars.

Conclusion

This project gave me a hands-on understanding of how to structure a Terraform project for scalability, security, and maintainability. By modularizing infrastructure, securing credentials, and setting up monitoring, I ended up with a production-grade setup.

How I passed my AZ-104 (Associate Administrator) exams in less than 21 days.

Anthony Uketui — Sun, 13 Apr 2025 14:39:34 +0000

The title might seem misleading, but it's the truth. To top it off, I scored an 854/1000, too. But that's by the way. I'm not her8e to brag, after all, it's just a paper.

I'm writing this so you become armed enough to write this exam in one sitting.

For clarity's sake, I've outlined this in steps.

Ready?

Go.

Step 1: Book the exam.

Create that pressure and set a deadline for yourself; that way, you don't end up in a vicious cycle of procrastination.

Step 2: Gather thy resources.

I watched tons of videos researching for the best resources. I watched to the extent that it became a form of procrastination. Instead of reading, studying, and practicing, I was all over YouTube scrolling for "Best Az-104" resources. I don't want you wasting time, so here are the resources I used.

1)Video Course
2)Text course
3)Labs(Hands-on Practice)
4)Practice questions.

People learn differently, but I'm sure with a mix of all things, you can never go wrong.

Before I continue... Labs are really important to do. Get familiar with the portal and the cloud shell.

Get your hands dirty. The exam is not so easy, and it's an associate exam. So if you have zero experience playing with Azure.

Please create an Azure account and start getting your hands muddy.

For the text course, I used Ms learn. And I solidified the concepts with something visual, like a video course.

For the Video course, I had access to Kodekloud, so I took a course on Az-104 on it, and I supplemented it with an Udemy course by Scott Duffy.

As you finish a certain topic, like compute or Storage, try to build projects related to the topic.

These are some labs I did

MicrosoftLearning / AZ-104-MicrosoftAzureAdministrator

AZ-104 Microsoft Azure Administrator

AZ-104: Microsoft Azure Administrator

Welcome

This repository is for instructors teaching Microsoft courses. If you are in class, please ask your instructor for assistance.

Link to demonstrations and labs (HTML format)
Are you an MCT? - Have a look at our GitHub User Guide for MCTs
To preview this course in a self-paced format, see our interactive lab simulations. You may find slight differences between the interactive simulations and the hosted labs, but the core concepts and ideas being demonstrated are the same.

Security Issue - April 2023

Effective immediately, the Admin password will be removed from the JSON template parameter files. This means students will have to provide a password when the template is deployed. This affects Labs 4, 5, 6, 7, 10 and 11. The lab instructions will be changed to reflect this change.

What are we doing?

To support this course, we will need to make…

View on GitHub

After two weeks of study, I immersed myself in practice questions, thinking I was ready. Alas, I scored 45%. Haha.

Practice questions point out your flaws and loopholes. Things you might have avoided because you thought it was unimportant. And it also shows you how the questions would be structured.

When you do this. Review your weak areas and go back to your text or video course to cement them. Go back to doing labs if it demands that. I supplemented with Azure documentation

Azure documentation | Microsoft Learn

Learn how to build and manage powerful applications using Microsoft Azure cloud services. Get documentation, example code, tutorials, and more.

learn.microsoft.com

and a Free YouTube video course playlist by Susanth Sutheesh

Never try to memorize the practice questions. Strive to understand the concepts instead.

Aside from the certification, you wouldn't want to be a scam when you eventually get a job and you're told to do something basic.

So in a nutshell, lock in!

For Practice questions, I used TechBlackboard AZ-104 YouTube playlist as my go-to guide because it explained each option and why they aren't the correct one. I warn you, some answers can be wrong, so go through the comments from time to time.

I also supplemented with a YouTube playlist that I found interesting. You can consume this probably a day before your exams, just to further solidify concepts

Hopefully, this made sense to you. You can always reach out to me on LinkedIn

I'm rooting for you and hope you crush your exam!

Building an Automated Football Match Schedule Notification System with AWS

Anthony Uketui — Thu, 13 Mar 2025 04:57:55 +0000

Introduction

In this post, I’ll walk you through how I built a serverless application that automatically checks for match schedules and sends email notifications using AWS services. This project leverages AWS Lambda, Amazon SNS, and Amazon EventBridge, demonstrating a practical use case of event-driven architecture in the cloud.

Why I did this?

Checking match schedules manually can be tedious, and missing a match can be frustrating. What if we could automate this process so that users receive timely notifications about upcoming matches?

Solution Overview

To solve this, I created an AWS-based system that:

Fetches match schedules using a Lambda function.
Triggers email notifications via Amazon SNS.
Uses EventBridge as a scheduler to run the Lambda function at set intervals.

Implementation Steps

1. Setting Up the SNS Topic

Created an SNS topic in the AWS console.

Added an email subscription to receive notifications.

Confirmed the subscription via email.

I also created IAM roles and policies so that our SNS topic can communicate with our lambda function

2. Writing the Lambda Function

I Used Python to fetch match schedules from an API.
Processed the data and sent a message to SNS.
Deployed the function to AWS Lambda.

Sample Lambda Code (Python):

import os
import json
import urllib.request
import boto3
from datetime import datetime, timezone

def fetch_football_data(api_url, headers):
    request = urllib.request.Request(api_url, headers=headers)
    try:
        with urllib.request.urlopen(request) as response:
            return json.loads(response.read().decode())
    except Exception as e:
        print(f"Error fetching data from API: {e}")
        return None

def format_match_data(match):
    status = match.get("status", "Unknown")
    home_team = match.get("homeTeam", {}).get("name", "Unknown")
    away_team = match.get("awayTeam", {}).get("name", "Unknown")
    home_score = match.get("score", {}).get("fullTime", {}).get("homeTeam", "N/A")
    away_score = match.get("score", {}).get("fullTime", {}).get("awayTeam", "N/A")
    competition = match.get("competition", {}).get("name", "Unknown Competition")
    match_time = match.get("utcDate", "Unknown")

    if status == "FINISHED":
        return (f"Competition: {competition}\n"
                f"{home_team} vs {away_team}\n"
                f"Final Score: {home_score}-{away_score}\n"
                f"Date & Time: {match_time}\n")
    elif status == "IN_PLAY":
        return (f"Competition: {competition}\n"
                f"{home_team} vs {away_team}\n"
                f"Current Score: {home_score}-{away_score}\n"
                f"Match is in progress!\n")
    elif status == "SCHEDULED":
        return (f"Competition: {competition}\n"
                f"{home_team} vs {away_team}\n"
                f"Scheduled Time: {match_time}\n")
    else:
        return (f"Competition: {competition}\n"
                f"{home_team} vs {away_team}\n"
                f"Status: {status}\n")

def lambda_handler(event, context):
    api_key = os.getenv("FOOTBALL_API_KEY")
    sns_topic_arn = os.getenv("SNS_TOPIC_ARN")
    sns_client = boto3.client("sns")

    # Fetch today's matches
    today_date = datetime.now(timezone.utc).strftime("%Y-%m-%d")
    api_url = f"https://api.football-data.org/v4/matches?dateFrom={today_date}&dateTo={today_date}"
    headers = {"X-Auth-Token": api_key}

    print(f"Fetching football matches for {today_date}")
    data = fetch_football_data(api_url, headers)

    if not data or "matches" not in data:
        return {"statusCode": 500, "body": "Error fetching match data"}

    matches = data["matches"]
    messages = [format_match_data(match) for match in matches]
    final_message = "\n---\n".join(messages) if messages else "No matches available for today."

    # Publish to SNS
    try:
        sns_client.publish(
            TopicArn=sns_topic_arn,
            Message=final_message,
            Subject="Football Match Updates"
        )
        print("Message published to SNS successfully.")
    except Exception as e:
        print(f"Error publishing to SNS: {e}")
        return {"statusCode": 500, "body": "Error publishing to SNS"}

    return {"statusCode": 200, "body": "Football match data processed and sent to SNS"}

I added an environment variable so our function recognizes the API key and the SNS topic URL

3. Scheduling Lambda with EventBridge

Created a new EventBridge rule to trigger the Lambda function at specific times.

Configured it to run daily or at specific match times.

Linked the rule to the Lambda function.

Testing & Results

Deployed and tested the function manually.

Verified that SNS successfully delivered email notifications.

Future Improvements

Store match schedules in DynamoDB for historical data.
Extend notifications to SMS or mobile apps.
Create a User Interface

Conclusion

This project showcases how AWS services can be combined to build an automated notification system. By leveraging Lambda, SNS, and EventBridge, I’ve created a serverless solution that keeps users informed without manual effort.

Developing an API to Retrieve Football Game Schedules - Using Docker and AWS Services

Anthony Uketui — Mon, 10 Mar 2025 07:00:08 +0000

Who Doesn't Love Football? ⚽

Before diving into my passion for the game, let’s tackle an important question:

Why Do We Need an API for Football Schedules?

Manually gathering football schedules from multiple websites is time-consuming and inefficient. Instead, an API allows us to integrate live updates directly into applications, websites, or analytics tools, making it easy to access real-time football schedules seamlessly.

🛠 Breaking It Down with an Analogy

Imagine you want to order food from a restaurant. Instead of going to the kitchen, checking ingredients, and preparing the meal yourself, you simply ask the waiter for what you want. The waiter communicates with the kitchen, retrieves the meal, and serves it to you—quick, accurate, and hassle-free.

An API works like that waiter. When you need football game schedules, instead of manually collecting data from multiple sources, the API acts as a middleman, fetching the latest updates for you instantly.

✅ This saves time, ensures accuracy, and eliminates manual work, making it easier for apps and websites to display real-time football schedules.

Project Overview

In this project, I developed an API that retrieves football game schedules using:

✅ Flask (for the API)
✅ Docker (for containerization)
✅ AWS Services (for scalability and reliability)

Tech Stack Breakdown

🚀 Flask Framework

Flask is a lightweight Python web framework that allows for rapid development. I used it to create API endpoints that handle requests for football game schedules.

📦 Docker

Docker enables packaging applications into containers—ensuring that they run consistently across different environments. By containerizing the Flask app, I simplified deployment and eliminated compatibility issues.

☁️ AWS Services Used

Elastic Container Registry (ECR) – A managed container registry to store our Docker images securely.
Elastic Container Service (ECS) – Used to deploy and manage the Dockerized API efficiently.
Elastic Load Balancing (ELB) – Distributes traffic across multiple instances to ensure high availability.
API Gateway – Exposes the API via a secure and scalable endpoint.

This combination ensures the API can handle real-time requests with high availability.

Development and Deployment Steps

1️⃣ Developing the Flask API

Created a Python-based Flask application to handle API requests.
Ensured the application fetched and processed football schedules from Football-Data.org.

2️⃣ Containerizing the Application with Docker

Wrote a Dockerfile to define the environment and dependencies.
Built and tested a Docker image locally.

3️⃣ Pushing the Docker Image to AWS ECR

Created an ECR repository to store the Docker image.
Tagged and pushed the image to ECR.

4️⃣ Deploying on AWS ECS

Set up an ECS cluster to manage containerized applications.
Defined a task definition specifying the Docker image and resource requirements.
Created a service to maintain the desired number of running tasks.

5️⃣ Configuring Networking & Load Balancing

Implemented an Application Load Balancer (ALB) for traffic distribution.
Configured security groups to allow API access.

6️⃣ Exposing the API via AWS API Gateway

Created an API Gateway to serve as the entry point.

- Routed traffic through API Gateway to the ALB.

Developing the API with Python (Flask)

I used Python to create the API, ensuring it could efficiently fetch and format football schedules.

Key Features

✅ Fetches live football schedules

✅ Formats responses in JSON

✅ Handles errors gracefully

Flask Code:

from flask import Flask, jsonify
import requests
import os

app = Flask(__name__)

FOOTBALL_API_URL = "https://api.football-data.org/v4/matches"
FOOTBALL_API_KEY = os.getenv("FOOTBALL_API_KEY", "your_api_key_here")

@app.route('/football', methods=['GET'])
def get_football_schedule():
    """Fetches upcoming football matches and returns as JSON."""
 8   try:
        headers = {"X-Auth-Token": FOOTBALL_API_KEY}
        response = requests.get(FOOTBALL_API_URL, headers=headers)
        response.raise_for_status()
        data = response.json()

        matches = data.get("matches", [])
        if not matches:
            return jsonify({"message": "No upcoming football matches found.", "matches": []}), 200

        formatted_matches = [
            {
                "competition": match.get("competition", {}).get("name", "Unknown"),
                "home_team": match.get("homeTeam", {}).get("name", "Unknown"),
                "away_team": match.get("awayTeam", {}).get("name", "Unknown"),
                "venue": match.get("venue", "Unknown"),
                "date": match.get("utcDate", "Unknown"),
            }
            for match in matches
        ]

        return jsonify({"message": "Football schedule fetched successfully.", "matches": formatted_matches}), 200

    except Exception as e:
        return jsonify({"message": "An error occurred.", "error": str(e)}), 500

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

To confirm the code works we test it in our local machine by running the command below.

Here's the output. It works!

Why Did I Containerize the Application? 🍽

A Simple Analogy

Using Docker is like a chef preparing a meal in a food container instead of serving it on a plate.

Without a container, the food might spill, mix with other meals, or not fit different kitchens. But with a container, the meal stays intact, portable, and works anywhere—whether in a restaurant, a food truck, or a customer's home.

Similarly, Docker packages our app with everything it needs, ensuring it runs smoothly on any system without issues.

What Does a Dockerfile Do? 📜

A Dockerfile is like a recipe—it provides step-by-step instructions to build our container consistently.

Here’s my Dockerfile:

# Use a lightweight Python image  
FROM python:3.9-slim  

# Set the working directory inside the container  
WORKDIR /app  

# Copy the requirements file into the container  
COPY requirements.txt requirements.txt  

# Install dependencies  
RUN pip install -r requirements.txt  

# Copy all files from the current directory into the container  
COPY . .  

# Expose the port  
EXPOSE 8080  

# Command to run the application  
8CMD ["python", "app.py"]

Deploying on AWS ☁️

Since we're deploying on AWS, I used ECR instead of Docker Hub for:

✅ Better security

✅ Faster performance

✅ Seamless AWS integration

Pushing the Docker Image to AWS ECR

Step 1: Create an ECR Repository

If you haven't already created an ECR repository, do so with:

Step 2: Authenticate Docker with AWS ECR

Before pushing the image, log in to AWS ECR using the AWS CLI:

Step 3: Tag the Docker Image

Retrieve the repository URL and tag your Docker image:

Step 4: Push the Image to ECR

Now, push the tagged image to the repository:

Configuring AWS ECS

Why Do We Need to Configure ECS?

Think of ECS as a restaurant kitchen that runs and manages containers. But before it can start serving meals (running containers), you need to:

✅ Set up the kitchen (configure ECS)

✅ Tell the chefs what recipes to use (define services and tasks)

✅ Assign kitchen equipment (8choose EC2 or Fargate)

Without proper ECS configuration, it won’t know where or how to run our containers.

Steps to Configure ECS

1️⃣ Create a Cluster – The foundation for running containers.

2️⃣ Define a Task Definition – Like a recipe that specifies:

Which container image to use (the image in our ECR)
CPU & memory allocation
Port settings and environment variables

3️⃣ Create a service:

We set up how many tasks we want defined(we used 2)
We set up security groups, Iam Policies(default)
We configured our load balancer from here.

Load Balancing

To distribute incoming traffic evenly across multiple containers, we configured an Application Load Balancer (ALB).

✅ High availability – If one container goes down, traffic is redirected to another.

✅ Better performance – Ensures no single container is overloaded.

To verify, we searched for our load balancer under EC2 Services and accessed our API via the ALB's DNS. It worked! 🎉

Creating an API Gateway Endpoint

Instead of exposing our ECS services directly, we used API Gateway as a front door to handle incoming requests.

Analogy: API Gateway is Like a Receptionist

Just like a receptionist in a big company handles all incoming guests, directs them appropriately, and ensures security, API Gateway:

📌 Receives incoming requests

📌 Routes them to the right backend service (ECS)

📌 Ensures security and authentication

Steps to Set Up API Gateway

1️⃣ Created a REST API

2️⃣ Created a resource & method

3️⃣ Deployed the API

Now, we can invoke our API successfully to access football game schedules. 🚀

Conclusion

Through this process, we successfully:

✅ Built and containerized a football schedule API

✅ Deployed it on AWS using ECS & Fargate

✅ Configured a load balancer for high availability

✅ Integrated API Gateway for security and request management

Now, users can access football schedules via our API! ⚽

Developing an API to Retrieve Football Game Schedules - Using Docker and AWS Services

Anthony Uketui — Mon, 10 Mar 2025 07:00:08 +0000

Who Doesn't Love Football? ⚽

Before diving into my passion for the game, let’s tackle an important question:

Why Do We Need an API for Football Schedules?

🛠 Breaking It Down with an Analogy

✅ This saves time, ensures accuracy, and eliminates manual work, making it easier for apps and websites to display real-time football schedules.

Project Overview

In this project, I developed an API that retrieves football game schedules using:

✅ Flask (for the API)
✅ Docker (for containerization)
✅ AWS Services (for scalability and reliability)

Tech Stack Breakdown

🚀 Flask Framework

Flask is a lightweight Python web framework that allows for rapid development. I used it to create API endpoints that handle requests for football game schedules.

📦 Docker

☁️ AWS Services Used

Elastic Container Registry (ECR) – A managed container registry to store our Docker images securely.
Elastic Container Service (ECS) – Used to deploy and manage the Dockerized API efficiently.
Elastic Load Balancing (ELB) – Distributes traffic across multiple instances to ensure high availability.
API Gateway – Exposes the API via a secure and scalable endpoint.

This combination ensures the API can handle real-time requests with high availability.

Development and Deployment Steps

1️⃣ Developing the Flask API

Created a Python-based Flask application to handle API requests.
Ensured the application fetched and processed football schedules from Football-Data.org.

2️⃣ Containerizing the Application with Docker

Wrote a Dockerfile to define the environment and dependencies.
Built and tested a Docker image locally.

3️⃣ Pushing the Docker Image to AWS ECR

Created an ECR repository to store the Docker image.
Tagged and pushed the image to ECR.

4️⃣ Deploying on AWS ECS

Set up an ECS cluster to manage containerized applications.
Defined a task definition specifying the Docker image and resource requirements.
Created a service to maintain the desired number of running tasks.

5️⃣ Configuring Networking & Load Balancing

Implemented an Application Load Balancer (ALB) for traffic distribution.
Configured security groups to allow API access.

6️⃣ Exposing the API via AWS API Gateway

Created an API Gateway to serve as the entry point.

- Routed traffic through API Gateway to the ALB.

Developing the API with Python (Flask)

I used Python to create the API, ensuring it could efficiently fetch and format football schedules.

Key Features

✅ Fetches live football schedules

✅ Formats responses in JSON

✅ Handles errors gracefully

Flask Code:

from flask import Flask, jsonify
import requests
import os

app = Flask(__name__)

FOOTBALL_API_URL = "https://api.football-data.org/v4/matches"
FOOTBALL_API_KEY = os.getenv("FOOTBALL_API_KEY", "your_api_key_here")

@app.route('/football', methods=['GET'])
def get_football_schedule():
    """Fetches upcoming football matches and returns as JSON."""
 8   try:
        headers = {"X-Auth-Token": FOOTBALL_API_KEY}
        response = requests.get(FOOTBALL_API_URL, headers=headers)
        response.raise_for_status()
        data = response.json()

        matches = data.get("matches", [])
        if not matches:
            return jsonify({"message": "No upcoming football matches found.", "matches": []}), 200

        formatted_matches = [
            {
                "competition": match.get("competition", {}).get("name", "Unknown"),
                "home_team": match.get("homeTeam", {}).get("name", "Unknown"),
                "away_team": match.get("awayTeam", {}).get("name", "Unknown"),
                "venue": match.get("venue", "Unknown"),
                "date": match.get("utcDate", "Unknown"),
            }
            for match in matches
        ]

        return jsonify({"message": "Football schedule fetched successfully.", "matches": formatted_matches}), 200

    except Exception as e:
        return jsonify({"message": "An error occurred.", "error": str(e)}), 500

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

To confirm the code works we test it in our local machine by running the command below.

Here's the output. It works!

Why Did I Containerize the Application? 🍽

A Simple Analogy

Using Docker is like a chef preparing a meal in a food container instead of serving it on a plate.

Similarly, Docker packages our app with everything it needs, ensuring it runs smoothly on any system without issues.

What Does a Dockerfile Do? 📜

A Dockerfile is like a recipe—it provides step-by-step instructions to build our container consistently.

Here’s my Dockerfile:

# Use a lightweight Python image  
FROM python:3.9-slim  

# Set the working directory inside the container  
WORKDIR /app  

# Copy the requirements file into the container  
COPY requirements.txt requirements.txt  

# Install dependencies  
RUN pip install -r requirements.txt  

# Copy all files from the current directory into the container  
COPY . .  

# Expose the port  
EXPOSE 8080  

# Command to run the application  
8CMD ["python", "app.py"]

Deploying on AWS ☁️

Since we're deploying on AWS, I used ECR instead of Docker Hub for:

✅ Better security

✅ Faster performance

✅ Seamless AWS integration

Pushing the Docker Image to AWS ECR

Step 1: Create an ECR Repository

If you haven't already created an ECR repository, do so with:

Step 2: Authenticate Docker with AWS ECR

Before pushing the image, log in to AWS ECR using the AWS CLI:

Step 3: Tag the Docker Image

Retrieve the repository URL and tag your Docker image:

Step 4: Push the Image to ECR

Now, push the tagged image to the repository:

Configuring AWS ECS

Why Do We Need to Configure ECS?

Think of ECS as a restaurant kitchen that runs and manages containers. But before it can start serving meals (running containers), you need to:

✅ Set up the kitchen (configure ECS)

✅ Tell the chefs what recipes to use (define services and tasks)

✅ Assign kitchen equipment (8choose EC2 or Fargate)

Without proper ECS configuration, it won’t know where or how to run our containers.

Steps to Configure ECS

1️⃣ Create a Cluster – The foundation for running containers.

2️⃣ Define a Task Definition – Like a recipe that specifies:

Which container image to use (the image in our ECR)
CPU & memory allocation
Port settings and environment variables

3️⃣ Create a service:

We set up how many tasks we want defined(we used 2)
We set up security groups, Iam Policies(default)
We configured our load balancer from here.

Load Balancing

To distribute incoming traffic evenly across multiple containers, we configured an Application Load Balancer (ALB).

✅ High availability – If one container goes down, traffic is redirected to another.

✅ Better performance – Ensures no single container is overloaded.

To verify, we searched for our load balancer under EC2 Services and accessed our API via the ALB's DNS. It worked! 🎉

Creating an API Gateway Endpoint

Instead of exposing our ECS services directly, we used API Gateway as a front door to handle incoming requests.

Analogy: API Gateway is Like a Receptionist

Just like a receptionist in a big company handles all incoming guests, directs them appropriately, and ensures security, API Gateway:

📌 Receives incoming requests

📌 Routes them to the right backend service (ECS)

📌 Ensures security and authentication

Steps to Set Up API Gateway

1️⃣ Created a REST API

2️⃣ Created a resource & method

3️⃣ Deployed the API

Now, we can invoke our API successfully to access football game schedules. 🚀

Conclusion

Now, users can access football schedules via our API! ⚽

Deploying a FastAPI App with CI/CD: GitHub Actions, Docker, Nginx & AWS EC2

Anthony Uketui — Thu, 13 Feb 2025 17:09:33 +0000

Tired of manually deploying your applications?

What if you could push code to GitHub, run tests automatically, and deploy updates to your live server—without lifting a finger?

That’s exactly what I did with my FastAPI project using CI/CD.

In this guide...

I’ll walk you through how I set up a Continuous Integration (CI) pipeline to automatically test my code...

And...

Continuous Deployment (CD) pipeline to push updates to an AWS EC2 instance.

You'll learn how to:

Fork the repository and set up FastAPI locally
Create a GitHub Actions CI pipeline for automated testing
Automate deployment with Docker, Nginx, and EC2

By the end, you’ll have a fully automated deployment workflow that keeps your FastAPI app up-to-date with zero manual effort. Let’s dive in! 🚀

Let's quickly go over how we would set everything

Overview of the Workflow

In this guide, we’ll go through the end-to-end process of deploying a FastAPI application using CI/CD with GitHub Actions, Docker, Nginx, and AWS EC2. Here’s a high-level breakdown of what we’ll cover:

Setting up the project – Forking the repo, setting up a virtual environment, and implementing the missing endpoint.
Testing locally – Running tests using pytest to ensure our changes work before deployment.
Setting up CI (Continuous Integration) – Creating a GitHub Actions pipeline to automatically test our code on every pull request.
Preparing for deployment – Adding necessary configuration files like nginx.conf, Dockerfile, and docker-compose.yml.
Deploying to AWS EC2 – Creating an EC2 instance, installing dependencies, and running our FastAPI app inside Docker.
Setting up CD (Continuous Deployment) – Automating the deployment process so that every merge to the main branch updates the live server.

1. Forked the Repo and Set It Up Locally

I forked the FastAPI Book Project Template repo and added my remote repo so I could track my changes.

git clone https://github.com/my-username/fastapi-book-project.git
cd fastapi-book-project

Then, I created a virtual environment and installed the dependencies:

python -m venv venv
source venv/bin/activate  # (Windows: venv\Scripts\activate)
pip install -r requirements.txt

venv is an indicator that I'm in the virtual environment

2. Added the Missing Endpoint

I created the missing endpoint in books.py to fetch books by ID:

@router.get("/{book_id}", response_model=Book, status_code=status.HTTP_200_OK)  # New endpoint
async def get_book(book_id: int):
    book = db.books.get(book_id)
    if not book:
        raise HTTPException(
            status_code=status.HTTP_404_NOT_FOUND, 
            detail="Book not found"
        )
    return book

I made sure to import HTTPException. if not it wouldn't work

After that...

Then, I ran tests locally using pytest to confirm it worked:

pytest

3. Created the CI Pipeline

I created a .github/workflows/ci.yml file to automate testing.

name: CI Pipeline

on:
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo
        uses: actions/checkout@v2

      - name: Set up Python
        uses: actions/setup-python@v3
        with:
          python-version: '3.9'

      - name: Install dependencies
        run: |
          python -m venv venv
          source venv/bin/activate
          pip install -r requirements.txt

      - name: Run tests
        run: |
          source venv/bin/activate
          pytest

I created a feature branch and pushed my changes:

git checkout -b feature-branch
git add .
git commit -m "Added missing endpoint and CI pipeline"
git push origin feature-branch

Then, I created a pull request. The CI pipeline ran and passed, so I merged it.

it's this way on my end because I've previously created a pull request and merged it.

4. Deployment Setup - Tested Locally

I first tested everything locally before deploying.

Added Required Files:

nginx.conf:

  server {
    listen 80;
    server_name your_domain_or_IP;
    location / {
        proxy_pass http://app:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For 
        $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Dockerfile:

  # Use an official lightweight Python image
FROM python:3.9-slim

# Set the working directory
WORKDIR /app

# Copy only the necessary files
COPY requirements.txt .

# Install dependencies
RUN pip install --no-cache-dir -r requirements.txt

# Copy the rest of the application
COPY . .

# Expose the required port
EXPOSE 8000

# Start FastAPI application
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

docker-compose.yml:

  version: '3.8'
services:
  app:
    build: .
    container_name: fastapi-app
    ports:
      - "8000:8000"

  nginx:
    image: nginx:latest
    container_name: fastapi-nginx
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
    ports:
      - "80:80"
    depends_on:
      - app

I built and ran it locally:

docker-compose up --build -d

Checked running containers:

docker ps

Tested it using my local IP in my browser:

It worked, so I pushed my changes.

git add .
git commit -m "Added Docker and Nginx setup"
git push origin main

5. Deployed to AWS EC2

I created an Ubuntu 22.04 EC2 instance, allowing inbound rules for ports 80 (HTTP) and 22 (SSH).

SSH into EC2 and Install Docker:

ssh -i my-key.pem ubuntu@my-ec2-ip
sudo apt update && sudo apt install -y docker.io docker-compose

Verify if it(docker and docker-compose) has been installed.

Cloned My Repo into EC2:

git clone https://github.com/my-username/fastapi-book-project.git
cd fastapi-book-project

Ran Docker on EC2:

sudo docker-compose up --build -d

Checked running containers:

sudo docker ps

Tested it on EC2:

I copied my EC2 public IP and tested it in a browser:

The app was running fine.

6. Automated Deployment with CD Pipeline

I automated deployment by creating a .github/workflows/cd.yml file.

name: CD Pipeline
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Deploy via SSH
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USER }}
          key: ${{ secrets.EC2_SSH_KEY }}
          script: |
            # Update package index and install dependencies
            sudo apt-get update -y
            sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common

            # Add Docker's official GPG key
            curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
            sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

            # Install Docker
            sudo apt-get update -y
            sudo apt-get install -y docker-ce docker-ce-cli containerd.io

            # Add the SSH user to the Docker group
            sudo usermod -aG docker ${{ secrets.EC2_USER}}

            cd /home/ubuntu/fastapi-book-project
            git fetch --all
            git reset --hard origin/main
            git pull origin main

            # Restart the Docker container
            docker-compose down
            docker-compose up -d --build

I added GitHub Secrets:

EC2_HOST → EC2 Public IP
EC2_USER → EC2 OS
EC2_PRIVATE_KEY → My SSH Key

To add Github Secrets go to the settings>>Secrets&Variables>>Actions

Then I committed and pushed the changes:

git add .
git commit -m "Added CD pipeline"
git push origin main

Now, every time I push changes and create a pull request:

CI pipeline runs tests
After merging, CD pipeline deploys the app to EC2 automatically

Final Workflow Summary

Forked the repo and cloned it locally
Added missing endpoints, and tested locally
Created CI pipeline to automate tests
Added Nginx, Docker, and Docker Compose and tested locally
Deployed to AWS EC2 and confirmed it worked
Created CD pipeline to automate future deployments

🚀 Now, any time I push new changes, my app gets automatically tested and deployed to EC2!

Before we go...

Here are some challenges I faced.

Challenges Faced

GitHub Actions Configuration Issues – I initially had syntax errors in my CI/CD YAML files, which caused the workflows to fail.
Pull Request Comparison Issue – I mistakenly compared the main branch of the forked repo with my feature branch, instead of comparing my own main branch with the feature branch.
Docker installation on my Ec2 Server- The initial commands flagged an error so I had to take another path if you noticed I added this in my cd pipeline
Unsuccessful Deployment of latest commits- I Had to use the git fetch command so my directory recognizes commits/changes that will be made. You can see it in my cd pipeline yaml file above.
Virtual environment & Dependency Issues

Building a Number Classification API using AWS Lambda.

Anthony Uketui — Fri, 07 Feb 2025 03:14:08 +0000

Deploying APIs can be complex, but AWS Lambda simplifies the process with a serverless, cost-effective, and scalable approach. Instead of managing servers, Lambda runs only when triggered, making it perfect for low-traffic APIs. In this project, I built a number classification API using AWS Lambda, API Gateway, and Python, ensuring fast execution and minimal costs. Here’s how I did it. 🚀

Why Use Lambda?

Before diving into this project, it's important to understand what our API is doing and why we're using AWS Lambda instead of other deployment methods.

There are multiple ways to make an API publicly accessible:

EC2: I initially deployed an API using Amazon EC2, which required setting up a virtual server, installing dependencies, and managing uptime.
Vercel, Render & Elastic Beanstalk: Both provide managed environments for running applications with minimal configuration.

However, for this project, I chose AWS Lambda because it is serverless—meaning I don't need to manage servers. AWS automatically provisions the infrastructure, executes the code, and shuts down after execution, making it highly cost-effective since I'm only billed when the function runs.

This is perfect for low-traffic APIs like this one. Instead of keeping an EC2 instance running all the time, Lambda only executes when a request is made.

Additionally, Lambda functions run in milliseconds, making it incredibly fast.

In summary, AWS Lambda was the best choice because it is:

✅ Lightweight—Runs only when triggered

✅ Cost-effective—No server maintenance costs

✅ Fast—Executes within milliseconds

✅ Fully managed—AWS handles scaling and availability

How the API Works (Simplified Explanation)

The API is designed to classify a number based on its properties and return some interesting facts. The flow works as follows:

A user requests the API
The API Gateway forwards the request to AWS Lambda
AWS Lambda processes the request and generates a response
The API Gateway sends the response back to the user

Analogy: Restaurant Example

If this concept is unclear, think of it like a restaurant:

You (the user) walk into a restaurant and place an order
The waiter (API Gateway) takes your order to the kitchen
The kitchen (AWS Lambda) prepares the meal
The waiter brings the meal back to you

Just like how you don’t need to know how the kitchen operates, the user doesn’t need to worry about the backend—Lambda handles everything behind the scenes.

Step 1: Setting Up AWS Lambda

I logged into AWS Lambda, clicked "Create Function", and chose "Author from Scratch" with the following settings:

Runtime: Python 3.x
Permissions: Created a new execution role with basic Lambda permissions

Step 2: Writing the Lambda Function (Python)

I wrote a Python function that classifies a number and returns its properties. It checks for:

✅ Prime numbers

✅ Armstrong numbers

✅ Even or odd classification

✅ Sum of digits

✅ A fun fact about the number (using Numbers API)

Here’s the function:

import json
import math
import requests

# Function to check if a number is prime
def is_prime(n):
    if n < 2:
        return False
    if n in (2, 3):
        return True
    if n % 2 == 0 or n % 3 == 0:
        return False
    for i in range(5, int(math.sqrt(n)) + 1, 2):
        if n % i == 0:
            return False
    return True

# Function to check if a number is an Armstrong number
def is_armstrong(n):
    if n < 0:
        return False
    digits = [int(digit) for digit in str(n)]
    power = len(digits)
    return sum(digit ** power for digit in digits) == n

# Function to check if a number is a perfect number
def is_perfect(n):
    if n < 1:
        return False
    return sum(i for i in range(1, n // 2 + 1) if n % i == 0) == n

# Function to get a fun fact about the number
def get_fun_fact(n):
    if n < 0:
        return "Fun fact not available for negative numbers."
    try:
        response = requests.get(f"http://numbersapi.com/{n}/math", 2timeout=5)
        if response.status_code == 200:
            return response.text
    except requests.exceptions.RequestException:
        pass
    return "Fun fact not available."

# AWS Lambda Handler
def lambda_handler(event, context):
    query_params = event.get("queryStringParameters", {})
    number_str = query_params.get("number") if query_params else None

    if not number_str:
        return {
            "statusCode": 400,
             "headers": {
                "Access-Control-Allow-Origin": "*",
                "Access-Control-Allow-Methods": "GET",
                "Access-Control-Allow-Headers": "Content-Type"
 2           },
            "body": json.dumps({"error": "No number provided."})
        }

    try:
        number = int(float(number_str))
    except ValueError:
        return {
            "statusCode": 400,
             "headers": {
                "Access-Control-Allow-Origin": "*",
                "Access-Control-Allow-Methods": "GET",
                "Access-Control-Allow-Headers": "content-type"
            },
            "body": json.dumps({
                "error": "Invalid number format",
                 'invalid_input': number_str  # Include the invalid input in the response
                })
        }

    properties = ["odd" if number % 2 else "even"]
    if is_armstrong(number):
        properties.insert(0, "armstrong")

    response_body = {
        "number": number,
        "is_prime": is_prime(number),
        "is_perfect": is_perfect(number),
        "properties": properties,
        "digit_sum": sum(int(d) for d in str(abs(number))),
        "fun_fact": get_fun_fact(number)
    }

    return {
        "statusCode": 200,
        "headers": {
            "Access-Control-Allow-Origin": "*",
            "Access-Control-Allow-Methods": "GET",
            "Access-Control-Allow-Headers": "Content-Type"
        },
        "body": json.dumps(response_body)
    }

Step 3: Deploying API Gateway

To make the function accessible via an HTTP request, I integrated it with AWS API Gateway:

Went to API Gateway
Created a new HTTP API
Set up a GET method
Integrated it with my Lambda function
Enabled CORS to allow frontend applications to call the API

After deployment, I got a public API endpoint like this:

https://taeiej1dj0.execute-api.us-east-1.amazonaws.com/prod/api/classify-number?number=371

Step 4: Testing the API

I tested the API using my browser

When I sent a valid request i got the required information and a 200 status code:

https://taeiej1dj0.execute-api.us-east-1.amazonaws.com/prod/api/classify-number?number=800

If I sent an invalid request (e.g., letters instead of numbers), I received a 400 Bad Request response:

If I didnt send any request (e.g no number or letter), I received a 400 Bad Request response:

Step 5: Hosting the Code on GitHub

Since I needed Version control, I:

Created a public GitHub repository
Pushed my Lambda function code with a well-structured README.md

🔗 GitHub Repo: [https://github.com/Anthonyuketui/API-NumberClasifier]

Conclusion

✅ AWS Lambda is serverless—no need to manage infrastructure

✅ API Gateway makes the function publicly accessible

✅ CORS enabled—any frontend can call the API

✅ Fast & lightweight—response time under 500ms

This setup provides a scalable, cost-effective, and efficient way to deploy APIs without managing a web server.

NGINX web server Configuration.

Anthony Uketui — Thu, 30 Jan 2025 07:58:39 +0000

Before we delve into configurations and all that.

You might be wondering...

Tony, What the heck is Nginx and why is it one of the most popular web servers used.

Before anything,

A web server is simply anything that stores, processes, and delivers web pages to users. It handles requests from web browsers (like Chrome) and sends back the requested content, such as websites, images, videos, or data.

if that seems too complex.

Imagine you walk into a restaurant and order Fried rice with chicken.

Here’s how the process works:

You (the browser) make a request → You tell the waiter your order.
The waiter (web server) processes it → He goes to the kitchen and gets your food.

The kitchen (database/backend) prepares the food → If the food is ready, he brings it immediately; if not, he tells you it’s unavailable (404 error).

The waiter serves you (delivers the web page) → You enjoy your Fried rice (website content).

But before we talk about Nginx...
let's talk about this other web server called Apache

Nginx came into place because of Apache's major limitation.

which was...

Not doing well under heavy traffic because of it's (Process/thread based nature)

And thats when Nginx came into the picture.

So what exactly is Nginx.

What is Nginx?
Nginx is a high-performance web server that also functions as a reverse proxy, load balancer, and HTTP cache. It is widely used for handling high amounts of traffic efficiently and is known for its speed, scalability, and lightweight resource usage.

Unlike Apache that is process/thread based. It is Event-driven

To Keep it simple it can do the following;

It can handle thousands of requests without consuming too many system resources.(lightweight)
It Distributes traffic across multiple servers, improving availability and reliability.(load-balancing)
It Reduces latency by storing frequently requested data.(speed)

So now we understand Nginx

Lets quickly set up some configurations to serve our web page.

Pre-requisites:

Linux Machine(in my case, i used ubuntu)
key pair(ssh)
NGINX
Application code
Internet Connection

Here's My Approach to do this.

To start,i launched an ec2 instance to get my ubuntu machine running and connected to it via ssh.

I needed to install Nginx on my Linux machine. This was a relatively straightforward task. Using the package manager on my system (Ubuntu), I ran the following commands to install Nginx:

sudo apt update && sudo apt install nginx -y

Once installed, I enabled the service to start on boot and immediately started it by running:

sudo systemctl enable nginx
sudo systemctl start nginx

After installation, I verified the Nginx service was running using:

sudo systemctl status nginx

Seeing the service running was a satisfying confirmation that I was on the right track.

The next step was to configure Nginx to serve a custom HTML page as the default page. I modified the default index.html file located in /var/www/html/index.html and replaced its contents with:

I then restarted Nginx so changes in my configurations would reflect. using the below command

sudo systemctl restart nginx

It works!

I know it's not the prettiest but it works.

In terms of challenges, i didn't really encounter much as this was a pretty straightforward task.

But...

Here are some common challenges people face while trying to set this up:

Firewall issues,(make sure http isn't blocked)
Permission issues(solved by using sudo) e.t.c

Also, this task helped me improve my web server management skills, which are essential in any DevOps role. By learning how to install, configure, and troubleshoot Nginx,

I now have a deeper understanding of how web servers function and how to ensure they are running smoothly.

Additionally, configuring Nginx as a web server is a foundational skill for DevOps Engineers and cloud engineers, both of which are roles I aspire to fill.

This task directly aligns with my long-term goals of working with cloud-based applications and building scalable web architectures.

DEV Community: Anthony Uketui

Lambda + ALB 503 Error Debugging Guide

Debugging AWS Lambda + ALB 503 Errors: A Step‑by‑Step Guide to Event Format Mismatches

Step 1: Verify Lambda Function Health

Step 2: Check ALB Target Group Configuration

Step 3: Verify ALB Permissions

Step 4: Analyze ALB Listener Rules

Step 5: Test with Correct Routing

Step 6: Compare Working vs Non‑Working Scenarios

Step 7: Examine the Lambda Handler Signature

Step 8: Analyze CloudWatch Logs

Step 9: Identify the Event Format Mismatch

Step 10: Verify with Test Events

The Fix: Update the Lambda Handler to Support ALB

Option 1: Change the Handler Input Type to ALB’s Event

Option 2: Use an Adapter Layer

Quick Diagnosis Checklist for Lambda + ALB 503 Errors

Key Takeaways

IAM Policies vs Resource Policies: Lessons from Production (and the Gym)

IAM Policies = Your Personal Trainer

Resource Policies = The Gym Rules

Here’s what I did in production:

Scaling Access: IAM vs Resource Policies

Takeaways from the battlefield

CI/CD for Infrastructure That Actually Works.

Why Infrastructure Pipelines Still Fail

The 8 Steps of CI/CD (Infrastructure Edition)

Production-Ready Differentiators

1. OIDC: Secure, Short-Lived Credentials

2. Cost Visibility: Infracost in PRs

Example Dev Pipeline (GitHub Actions)

Multi-Environment Setup

Why This Matters

Building a Production-Ready Terraform Project with Multi-Environment Support on AWS

Step 1: Project Structure and Multi-Environment Setup

Step 2: Defining the VPC

Code Snippet (VPC module)

Step 3: Application Load Balancer (ALB)

Code Snippet (ALB module)

Step 4: EC2 Auto Scaling Group

Code Snippet (EC2 module)

Step 5: RDS Database Setup

Code Snippet (RDS module)

Step 6: Monitoring and Alerts

Code Snippet (Monitoring module)

Step 7: Multi-Environment Variables

Dev terraform.tfvars

Prod terraform.tfvars

Dev Environment

Prod Environment

Step 8: Running the Project

Challenges and How I Solved Them

Conclusion

How I passed my AZ-104 (Associate Administrator) exams in less than 21 days.

Step 1: Book the exam.

Step 2: Gather thy resources.

MicrosoftLearning / AZ-104-MicrosoftAzureAdministrator

AZ-104 Microsoft Azure Administrator

AZ-104: Microsoft Azure Administrator

Welcome

Security Issue - April 2023

What are we doing?

Azure documentation | Microsoft Learn

Building an Automated Football Match Schedule Notification System with AWS

Introduction

Why I did this?

Solution Overview

Implementation Steps

1. Setting Up the SNS Topic

2. Writing the Lambda Function

3. Scheduling Lambda with EventBridge

Testing & Results

Future Improvements

Conclusion

Developing an API to Retrieve Football Game Schedules - Using Docker and AWS Services

Who Doesn't Love Football? ⚽

Why Do We Need an API for Football Schedules?

🛠 Breaking It Down with an Analogy

Project Overview

Tech Stack Breakdown

Dev `terraform.tfvars`

Prod `terraform.tfvars`