NOTE: This is my blog post for the Cloud Resume Challenge for my website. The Cloud Resume Challenge is a project comprised of a list of requirements to complete in order to host your resume/portfolio in the cloud using cloud-native infrastructure. Please also visit the GitHub repo for more information as well as the README.
Two Birds, One Stone
For quite some time now, I have wanted to have my own portfolio website to showcase my technical skills to complement my resume. Instead of using a simple web-hosting platform like Wix or Squarespace, I figured I would build it myself in the form of the Cloud Resume Challenge. After all, SRE/DevOps is my career path and I figured it would not only be a good showcase of my skills. but it would end up being cheaper as well while giving me more control over things.
Making It My Own
My infrastructure diagram created in Lucidchart
Instead of doing everything by the book (the challenge allows for flexibility), I decided to take advantage of my already existing Hashicorp Vault hosted in my on-premises Kubernetes cluster. This allows for granular control of exactly how I want JWT to work. It also allows for the keeping of my AWS and other secrets off the cloud and behind a VPN instead.
For IaC, I debated between using Pulumi (Python) and Terraform. Given that I achieved the Terraform Associate certification in 2025 combined with the fact that HCL is pretty industry-standard for IaC right now, I decided to go with that. Despite getting certified, I learned more during this challenge than I ever did studying for the exam. I am now far more inclined to use Terraform/HCL for other things I have been managing, including my UniFi controller, my Hashicorp Vault application and perhaps even my Firewall at home. It has been a pretty eye-opening experience all around, even if I already knew what IaC was beforehand.
Finally, for CI/CD, I kept it as vanilla as ever. I have two GitHub repos (one for the backend and the other for the web frontend) with GitHub Action workflows. Much like Terraform, this was my first time doing something truly real with Actions. Given that it uses fairly standard YAML, I found it intuitive enough. Each repository has two branches: a testing branch and a main branch for live production. The workflow will run terraform plan in the test environment, and if it completes successfully, I merge into main, which then runs another workflow with terraform apply. In case I ever want to destroy infrastructure, I created a workflow dispatch to manually select "Destroy" in case I ever wanted that option.
Building the Frontend
My background is in IT Operations, not web development, so suffice it to say, this was mostly uncharted territory for me. Outside of some very basic HTML concepts, everything was new. I can set up a mean web server, but developing a site? Not so much.
This part was actually very fun. I decided to go with a nice portfolio template from Start Bootstrap, complete with HTML and thousands of lines of CSS. I made quite a few modifications to the HTML and even some CSS. Instead of simply vibe-coding it, I decided to learn a few things (mostly text formatting and using classes to refer to CSS code).
The Javascript was also something pretty fun. I was able to take advantage of localStorage for the visitor counter running in a Lambda Function to ensure that a simple browser refresh would not make the counter go up. Not 100% elegant, but much more so than the alternative, more simple setup.
Even if frontend is not really the focus of my career, I still had fun learning some things about it!
Learning the Backend
Focusing on Terraform, I learned a LOT. Discerning data blocks from resource blocks through experience also makes things a lot clearer. Using locals and especially for_each were also concepts I have not encountered much of yet until this project. After all of this, I am actually considering creating some IAM roles on my personal AWS account to make most things read-only.
If I were to do things differently, I would probably clean up the code a bit more. I did review things to ensure they were not only correct, but also ideal before pushing it to Git, so not too many regrets there, but I cannot help but feel it could be organized better. What I do want to eventually do, however, is add a blog to the portfolio site itself and also upgrade the visitor counter for more info and more accurate counting.
Conclusion
In the end, I see this as not only something to knock out to make my resume look better, but I see this as my continuing portfolio site for hopefully years to come. I have some things I want to add and improve for this, so I will certainly not let this sit and rot.
Top comments (0)