The Cloud Resume Challenge: CI/CD, Python, and Surviving a Security Scare

Amine Traibi — Fri, 13 Mar 2026 23:11:43 +0000

Introduction

Theoretical knowledge is foundational, but engineering competency is built through implementation.

I realized that understanding the theory of services like S3, Lambda, and DynamoDB wasn't enough. I wanted to demonstrate that I could orchestrate them into a secure, automated, production-grade application.

The Cloud Resume Challenge—created by Forrest Brazeal—was the perfect framework to bridge the gap between architectural concepts and real-world DevOps implementation.

Here is how I built a serverless resume website, automated the deployment with GitHub Actions, and solved the engineering hurdles along the way

The Architecture
The project requirement is simple: "Host a resume online." But the architecture I implemented is pure Cloud Engineering:

Frontend: HTML/CSS hosted on S3, accelerated by CloudFront (HTTPS) for global caching.
Backend: An AWS Lambda function (Python) handling API requests.
Database: DynamoDB (NoSQL) for storing the visitor count.
Infrastructure: Fully automated CI/CD pipelines using GitHub Actions.

Level 1: The Frontend Glue (JavaScript)

The website itself is static HTML/CSS, but making it dynamic required JavaScript. I wrote a script to fetch the visitor count from my API Gateway trigger.

The biggest hurdle here was CORS (Cross-Origin Resource Sharing). My JavaScript running on aminetraibi.com was trying to talk to an AWS Lambda URL, and the browser blocked it for security reasons.

The Fix: I had to configure my Python Lambda function to return specific headers (Access-Control-Allow-Origin: *) so the browser would accept the response.

// Fetching the view count
fetch(apiUrl)
    .then(response => response.json())
    .then(data => {
        document.getElementById('counter').innerText = data.views;
    });

Level 2: The Backend Logic (Python & DynamoDB)

I needed an atomic counter that increments every time the page loads. I wrote a Python script using boto3 to talk to DynamoDB.

One specific challenge was handling DynamoDB reserved words. Since "views" is a reserved keyword in DynamoDB, I had to use ExpressionAttributeNames to map it correctly.

# Atomic update using UpdateExpression
response = table.update_item(
    Key={'id': 'page_view'},
    UpdateExpression='SET #v = #v + :val',
    ExpressionAttributeNames={'#v': 'views'},
    ExpressionAttributeValues={':val': 1},
    ReturnValues='UPDATED_NEW'
)

Level 3: The Security Lesson 🚨

This was the most critical part of my learning journey.

I learned a hard lesson about Secrets Management. Early in the build, I accidentally committed credentials to the repository.

I immediately identified the risk, revoked the keys in IAM, and migrated to GitHub Secrets.

It was a practical lesson in why security must be automated, not manual. I now use a dedicated IAM user with "Least Privilege" permissions, and my keys are injected only at runtime via the CI/CD pipeline.

Level 4: Automated Testing & Mocking

The challenge requires Python unit tests. This was one of the hardest parts of the build.

When I ran tests locally, boto3 tried to connect to the real AWS DynamoDB. However, in the CI/CD environment, I didn't want my tests to rely on an internet connection or require live database permissions.

The Solution: Mocking
I used the unittest.mock library to simulate the AWS services. By mocking the DynamoDB table resource, I could test the logic of my function without making any actual API calls.

# Using MagicMock to fake the database response
mock_table = MagicMock()
mock_table.update_item.return_value = {'Attributes': {'views': 123}}
lambda_function.table = mock_table

This ensures my pipeline is fast, robust, and doesn't incur AWS costs during testing.

Level 5: CI/CD (The "Green Checkmark")

The ultimate goal was to move away from the AWS Console ("ClickOps") and use proper DevOps practices.

I built two separate GitHub Actions workflows:

Frontend Pipeline: Detects changes in HTML/CSS, syncs them to S3, and invalidates the CloudFront cache.
Backend Pipeline: Detects changes in Python code, runs the unit tests, zips the code, and updates the Lambda function.
Now, I simply push to main, and the entire application updates itself.

Conclusion & Next Steps

This project forced me to touch every part of the stack: Networking (DNS/Route53), Security (IAM), Compute (Lambda), Database (DynamoDB), and Frontend logic (JavaScript).

My next milestone is to continue building on this foundation—specifically diving deeper into Infrastructure as Code with Terraform and exploring containerization with Docker/ECS.

If you are looking for a Cloud Engineer who learns by doing, breaks things, and fixes them—let's connect!

Check out the live project here:

Live Site: https://aminetraibi.com
GitHub Repository: https://github.com/AmineTra/cloud-resume-challenge

DEV Community: Amine Traibi

The Cloud Resume Challenge: CI/CD, Python, and Surviving a Security Scare