Cloud Resume Challenge

Muhammad Imran — Wed, 14 Oct 2026 17:37:10 +0000

Introduction

I wanted to use all the skills I learned during my time as an AWS consultant to build something useful. I decided to take on the Cloud Resume Challenge because it is a great introduction to building real projects with AWS serverless services.

What Is the Cloud Resume Challenge?

The Cloud Resume Challenge is a practical, hands-on project created by Forrest Brazeal to help people break into cloud engineering. Rather than studying for another certification, you build and deploy a real application, which gives you something concrete to show employers.
The aim is to build and host resume in the cloud, track how many people visit the site and display it to the end user. It also encourages use of Infrastructure as Code and CI/CD principles. For the AWS Challenge, the specification includes the following:

Certification
HTML
CSS
Static Website
HTTPS
DNS (custom domain via Route 53)
JavaScript
Database (DynamoDB)
API (API Gateway + Lambda)
Python
Tests
Infrastructure as Code (Terraform)
Source Control (GitHub)
CI/CD (Backend)
CI/CD (Frontend)
Blog Post

My Cloud Resume Challenge Journey

Stage 1: Build a basic resume website

The first step was to create the website for my resume. I used HTML and CSS to build a clean, simple site with sections for my introduction, experience, skills, and certifications. I used HTML to structure the content and CSS to style the layout, fonts, and colours, keeping the design minimal so that the most important information is easy to find. I also made sure the page was responsive, so it displays well on both desktop and mobile screens.

Stage 2: Building the front end

The first step in this stage is to set up an AWS S3 bucket to host my static website, which was simple enough after following the AWS documentation.
Next, I set up Amazon CloudFront as my content delivery network. A CDN is a service that speeds up the delivery of web content by caching it at edge locations around the world. My site is just a simple HTML page, so I didn’t need it, but it gave me hands-on experience with CloudFront and made the site faster for visitors.
I then bought a domain from AWS Route 53, which came with a hosted zone. After that, I used AWS Certificate Manager (ACM) to create a TLS certificate to enable HTTPS for my custom domain. A few simple DNS changes later, my website was finally in the cloud.

Stage 3: Building the back end

The first part was creating the database and I did that by creating a DynamoDB table. I got the DynamoDB table running and added one item to store my visitor counter.
Then I created a Lambda function, written in Python, which increments the counter in DynamoDB by one every time it runs.
Next, I created an API in AWS API Gateway and this was integrated with the Lambda function. When the API is invoked, it triggers the Lambda, which then increments the visitor counter value in the database.
Finally, I took the API URL from API Gateway and added it to my resume website's JavaScript so the website calls the API each time it loads. I also configured CORS (Cross-Origin Resource Sharing) so the API accepts requests from my website’s domain. Seeing the visitor count update on my live site was a great way to tie all the pieces together.

This was a good experience because I learned the fundamentals of a simple serverless application. I saw how a front end, an API, a function, and a database can work together without me managing a single server, and I now feel far more confident building and connecting AWS services. It also showed me how much of cloud engineering comes down to troubleshooting, whether that was permissions, CORS errors, or reading logs. I moved on to automating deployments using GitHub Actions.

Stage 4: Continuous Integration & Continuous Delivery (CI/CD)

The final stage of the challenge was setting up CI/CD so my website deploys automatically whenever I make a change.
I started by using OpenID Connect (OIDC) to establish trust between my GitHub repository and my AWS account. With OIDC, GitHub can access AWS using short-lived credentials, so there's no need to store an access key ID or secret access key in the repository. I followed the AWS Security Blog guide, Use IAM roles to connect GitHub Actions to actions in AWS, which walks through the setup securely.
Next, I set my workflow to run whenever files in the terraform/assets folder change, since that's where my website content lives. When the frontend changes, the workflow uploads the new files to my S3 bucket and then invalidates the CloudFront cache, so whenever a new request comes in it will fetch updated objects from AWS S3 so visitors see the latest version right away.
This was my first time using GitHub Actions, and it showed me how much time automation can save. Now, every time I push a change, my website updates on its own, with no manual uploads and no long-lived credentials to manage.

Conclusion

Overall, I found the challenge fun and engaging. I got to learn new AWS services and pick up tools as I needed them.
Building the project end to end showed me how a serverless application fits together: a static front end on S3 and CloudFront, a Lambda function and API Gateway handling the logic, and DynamoDB storing the visitor count, all without managing a single server.
If you’re thinking about taking on the Cloud Resume Challenge yourself, my advice is to start small, get each stage working before moving on, and treat every error as part of the learning. You’ll finish with a working project and a better understanding of how cloud applications are built.
You can view my deployed site here and the GitHub repository here.

DEV Community: Muhammad Imran