Why I Took on the Cloud Resume Challenge
My journey with the AWS Cloud Resume Challenge began as I transitioned from software engineering to cloud and network engineering. While studying, watching YouTube tutorials, and exploring ways to gain practical experience, I discovered the challenge and immediately recognized its potential.
I started building the frontend of my website, but the demands of university coursework eventually pushed the project to the back burner.
During that time, I continued developing my skills through free and accessible learning resources, including a Verizon-sponsored year of AWS Skill Builder. These opportunities helped me better understand AWS services, experiment with smaller projects, and begin building a GitHub portfolio documenting my progress.
After completing a virtualization course, I felt it was time to put more of that knowledge into practice. I wanted to develop and build something beyond my LinkedIn profile and certifications. I wanted a working portfolio that demonstrated what I could actually build.
So I returned to the Cloud Resume Challenge with a different approach: tear down what I had started and rebuild it from the beginning.
This time, I wanted to understand the architecture, work through errors, strengthen my command-line and VS Code skills, and challenge myself to troubleshoot independently before turning to AI for assistance.
The process wasn't always smooth, but that became part of its value.
My goal wasn't simply to finish the challenge. It was to develop the practical skills, problem-solving habits, and confidence needed to become a cloud engineer.
Designing the Architecture: How the Pieces Fit Together
One of the biggest learning opportunities in the Cloud Resume Challenge was understanding how individual AWS services work together to deliver a complete application.
The challenge required building a cloud-hosted resume website with a serverless visitor counter. While I was becoming familiar with many of these services through my coursework and AWS Skill Builder, connecting them into a working application gave me a much deeper understanding of their roles.
The frontend uses HTML, CSS, and JavaScript, with Amazon S3 storing the website files. Amazon CloudFront delivers the content over HTTPS, Route 53 manages DNS for my custom domain, and AWS Certificate Manager provides the TLS certificate.
I also configured CloudFront Origin Access Control (OAC), allowing the website to remain publicly accessible while keeping the S3 bucket private.
The backend powers the visitor counter. When someone visits my homepage, JavaScript sends an HTTPS POST request to Amazon API Gateway, which invokes a Python AWS Lambda function. Lambda uses DynamoDB's atomic update operation to increment the count and return the updated value to the browser.
This approach gave me hands-on experience connecting frontend code to cloud services without managing a traditional web server.
I maintained separate frontend and backend GitHub repositories. GitHub Actions automates frontend deployments to S3 and CloudFront, while the backend pipeline runs Python tests and uses AWS SAM and CloudFormation to deploy a separate test environment.
Both deployment pipelines use AWS OpenID Connect (OIDC) for authentication rather than storing long-lived AWS access keys.
The biggest takeaway was learning to see the architecture as a connected system, not just a collection of AWS services.
When Things Didn't Work: Troubleshooting and Problem-Solving
Getting the individual AWS services configured was one challenge. Getting them to communicate and work together reliably was another.
Some of my most valuable lessons came when something appeared to be configured correctly, but the application still didn't behave as expected.
An HTTP 200 Doesn't Always Mean Everything Is Working
One of my early troubleshooting experiences involved the visitor counter. The JavaScript file appeared to load successfully, and the browser returned an HTTP 200 response, but the counter wasn't updating.
Using Chrome Developer Tools and examining the files stored in S3, I discovered that the expected JavaScript object was empty. Another copy had been uploaded under an incorrect S3 key.
After correcting the file placement, verifying its contents, and invalidating the CloudFront cache, the counter began working.
Lesson learned: A successful HTTP response doesn't necessarily mean the application received the content it expected.
Understanding CORS and Browser Security
After configuring my custom domain, the visitor counter stopped communicating successfully with the backend API.
The browser's developer tools pointed to a Cross-Origin Resource Sharing (CORS) issue. API Gateway allowed requests from the original CloudFront domain, but not from my new custom domain.
Updating the allowed origins to include both marriohinkle.com and www.marriohinkle.com resolved the problem.
This helped reinforce my understanding of browser security and why different domain names are treated as separate origins.
GitHub Actions and AWS Authentication
Automating deployments introduced another set of challenges.
My frontend GitHub Actions workflow initially failed when attempting to authenticate with AWS through OpenID Connect (OIDC).
The error involved sts:AssumeRoleWithWebIdentity.
Rather than repeatedly changing permissions without understanding the cause of the failure, I examined the IAM trust policy and the identity claims provided by GitHub.
A temporary diagnostic step helped identify a mismatch between the GitHub OIDC token's subject and the IAM role's trust policy.
After correcting the trust policy, the workflow authenticated successfully. I then removed the diagnostic step.
Lesson learned: Authentication problems often require understanding how identities, trust relationships, and permissions interact—not simply granting more access.
CloudFormation and Deployment Permissions
The backend CI/CD pipeline became more complex when I began automating deployments using AWS SAM and CloudFormation.
I learned that the IAM role used by GitHub Actions and the execution role used by CloudFormation have different responsibilities.
Resolving the deployment authorization issues required examining those roles and configuring the permissions necessary for CloudFormation to manage the test environment.
Eventually, I had an automated pipeline that could run Python tests, build the serverless application, and deploy it to AWS without modifying my production visitor counter.
This was one of the clearest examples of why understanding IAM and infrastructure automation matters in cloud engineering.
The biggest lesson from these experiences was that troubleshooting isn't separate from learning cloud engineering. It's an essential part of it.
What I Learned and What's Next
When I returned to the Cloud Resume Challenge, my goal wasn't simply to launch a website. I wanted to become more comfortable building, configuring, and troubleshooting cloud infrastructure.
Along the way, I gained practical experience with AWS networking and security, serverless applications, Python, infrastructure as code, and CI/CD automation.
But some of the most valuable lessons weren't tied to a particular AWS service.
The process strengthened my ability to read and interpret error messages, investigate problems through browser developer tools, and use the command line to diagnose issues. It also reinforced the importance of understanding what commands actually do, rather than simply executing them to get a desired result. AI became a valuable resource throughout this process, not just for finding solutions, but for helping me understand the reasoning behind them.
This project isn't the end of that learning process. Some improvements I'd like to explore include expanding automated integration tests, adding monitoring and alerts, and eventually managing the production backend through infrastructure as code.
For now, I've accomplished what I set out to do: build a working cloud-hosted portfolio that demonstrates more than what I've studied.
I can point to something I've built, explain how it works, discuss what went wrong, and describe how I worked through those problems.
That's the kind of progress I was hoping to make when I decided to start over.
Explore the Project
- Live Portfolio: marriohinkle.com
- Frontend Repository: github.com/Aruande/cloud-resume-frontend
- Backend Repository: github.com/Aruande/cloud-resume-backend
If you're working through the Cloud Resume Challenge or making your own transition into cloud engineering, I'd be interested to hear which part of the process has challenged you the most.
Top comments (0)