Cloud Resume Challenge · Step 16
From E-8 logistics to a live serverless resume
The Cloud Resume Challenge asks you to put a resume on AWS and prove you can ship. I used it to show a longer story: 26 years of Army logistics leadership, production work for a small Colorado town, and a deliberate move into DevOps. This post covers the trade-offs behind stephenmckitrick.com — not a tutorial of every console click.
What I optimized for
Employers scan fast. The site had to be live, secure, and cheap enough to leave running, with source they can open in two GitHub repos. I split frontend from infrastructure so a static HTML change does not require a Terraform plan, and an IAM change does not redeploy CSS.
Why vanilla HTML plus Syncfusion
Town of Wiley is Angular and PrimeNG. This portfolio is vanilla HTML, CSS, and JavaScript with Syncfusion Essential JS 2 from a CDN. That was deliberate:
- No build step in production. GitHub Actions lints, injects license and API config, then syncs files to S3. Fewer moving parts than a SPA for a single resume.
- CRC fidelity. The challenge wants HTML, CSS, and JavaScript you wrote — not a framework hiding the work.
- Real UI controls. AppBar, Accordion, Grid (Excel/PDF/Print), and Chart show I can ship accessible components, not only a styled document.
The cost is a Syncfusion license for local preview and a heavier CDN payload than a hand-rolled page. I accepted that to keep the resume interactive without standing up a frontend build pipeline. Long term I may align this site with the Angular stack used on townofwiley.gov; for the challenge, lightweight and inspectable won.
OIDC instead of long-lived keys
The first version of many CRC write-ups stores AWS access keys in GitHub Secrets. I used
GitHub OIDC: Actions assumes an IAM role scoped to these two repos and the
main branch. Credentials are short-lived. Rotating a leaked key is not part of
the runbook because there is no static key in CI.
Bootstrap still runs locally once (state bucket, lock table, OIDC provider, deploy role). After that, plan-on-PR and apply-on-main are the only mutation path for production infrastructure.
Free-tier decisions I would make again
- Private S3 + CloudFront OAC. The bucket is not a public website. Only CloudFront reads objects. HTTPS and security headers live at the edge.
-
HTTP API + Lambda + DynamoDB for the visitor counter. Atomic
ADD, CORS allowlist, throttling, and a least-privilege execution role. Pytest with moto gates every Terraform apply. - No WAF, GuardDuty, or Shield Advanced. Shield Standard is already on CloudFront. Paid controls would dominate the monthly bill for a personal site.
- Porkbun DNS for now. CRC accepts any DNS provider. Route 53 records are ready after the registrar-transfer lock; the site already serves on the custom domain.
What the military-to-cloud path actually taught me
The useful carry-over is not “I can follow a checklist.” It is accountability under constraints. BusBuddy cut transportation errors 30% because the people running the routes needed a tool that matched the work. townofwiley.gov is in production because a clerk’s office cannot use a demo. The resume stack is the same habit: make it operable, keep the blast radius small, write down how it is secured.
What I would change next
- Light Playwright coverage for the visitor counter and featured sections.
- A downloadable PDF resume next to the live site.
- Keep collapsing density. Depth stays one click away for interviews.
If you are hiring for DevOps, cloud, or municipal/civic tech: the live site, the two repos, and this post are the packet. Start at the resume, then open ARCHITECTURE.md if you want the diagram.