explaingit

edwinjdevops/damolak-challenge

0HCLAudience · ops devopsComplexity · 3/5ActiveSetup · hard

TLDR

DevOps challenge submission shipping a FastAPI service on ECS Fargate with Terraform modules for VPC, ECR, IAM, ALB, and a GitHub Actions OIDC pipeline.

Mindmap

mindmap
  root((damolak-challenge))
    Inputs
      FastAPI source
      Dockerfile
      Terraform modules
      GitHub push
    Outputs
      ECS Fargate service
      ALB endpoint
      CloudWatch metrics
    Use Cases
      Reference AWS stack
      Practice CI to ECS
      Show Terraform layout
    Tech Stack
      Python
      FastAPI
      Docker
      Terraform
      AWS
      GitHub Actions

Things people build with this

USE CASE 1

Copy the Terraform module layout for a fresh AWS Fargate project

USE CASE 2

Study a GitHub Actions OIDC flow that avoids long-lived AWS keys

USE CASE 3

Use the FastAPI plus multi-stage Dockerfile as a small service template

Tech stack

PythonFastAPIDockerTerraformAWSECS FargateGitHub Actions

Getting it running

Difficulty · hard Time to first run · 1h+

Needs an AWS account, Terraform installed, and a GitHub OIDC trust set up before the pipeline can deploy; state is local so collaborators must coordinate.

In plain English

This repository is a submitted answer to a 96-hour DevOps Engineer practical challenge from a company called Damolak Technologies. The author, Chibuike Obi, packages a small Python web service together with the cloud infrastructure and automation needed to run it on Amazon Web Services. The point of the exercise is to show end-to-end skill: write the code, containerize it, describe the cloud setup in files, and wire up an automated pipeline that ships changes when you push to the main branch. The application itself is a FastAPI service with three endpoints (/health, /info, and /). It runs inside a Docker container that is built in two stages so the final image is small and runs as a non-root user. The container is stored in Amazon ECR (a private image registry) and run on ECS Fargate, which is a serverless way to run containers without managing virtual machines. Traffic from the internet goes through an Application Load Balancer in public subnets, while the tasks themselves sit in private subnets across two availability zones, so they have no public addresses. The cloud setup is written in Terraform, split into separate modules for the VPC network, the ECR registry, IAM permissions, the load balancer, and the ECS service. A GitHub Actions workflow uses OIDC to obtain short-lived AWS credentials, so there are no long-lived access keys stored anywhere. The pipeline runs tests with pytest, builds and pushes the Docker image, then updates the ECS service in a rolling, zero-downtime way. CloudWatch Container Insights collects metrics and logs, with a CPU alarm above eighty percent. The README lists known limitations: HTTP only with no HTTPS, a fixed task count instead of autoscaling, local Terraform state, and environment variables for secrets instead of Secrets Manager.

Copy-paste prompts

Prompt 1
Walk me through deploying this stack to a fresh AWS account with terraform apply
Prompt 2
Show me how the GitHub Actions workflow uses OIDC to assume the AWS role
Prompt 3
Add HTTPS to the ALB module with an ACM certificate and listener
Prompt 4
Replace the fixed task count with an ECS autoscaling target tracking policy
Open on GitHub → Explain another repo

Generated 2026-05-22 · Model: sonnet-4-6 · Verify against the repo before relying on details.