Cloud Resume Challenge

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 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 host your resume on the cloud, keep a record of the number of visitors that visit the website and display it to the end-user. It also encourages use of Infrastructure as Code and CICD Principles. For the AWS Challenge, the specification includes the following:

1. Certification
2. HTML
3. CSS
4. Static Website
5. HTTPS
6. DNS (no custom domain yet – using CloudFront URL)
7. JavaScript
8. Database (DynamoDB)
9. API (API Gateway + Lambda)
10. Python
11. Tests
12. Infrastructure as Code (AWS SAM)
13. Source Control (GitHub)
14. CI/CD (Backend)
15. CI/CD (Frontend)
16. 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 was, 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 CloudFront as my CDN (a content delivery network is a web service that speeds up the distribution of web content). Although my site is a simple HTML webpage, this allowed it to be cached across AWS CloudFront edge locations, and, more importantly, it gave me exposure to using CloudFront.
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 a DynamoDB table. I got it 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 Gateway 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 page calls the API each time it loads. I also configured CORS (Cross-Origin Resource Sharing) so the browser allows my website's domain to call the API. 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 was learning the fundamentals of a simple serverless application. I was seeing 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 with the website and visitor counter working, I moved on to automating deployments

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 a secret access key or access key ID 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 visitors see the latest version right away.
This stage was good because it 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, instead of chasing an impossible level of technical mastery.
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 better understanding of how cloud applications are built.
You can view my deployed site here and the GitHub repository here.