Forem: Trinity Klein

Cloud Resume Challenge - Chunk 5 - The Final Write-Up

Trinity Klein — Tue, 11 Nov 2025 17:11:47 +0000

After weeks of effort, late-night debugging, and countless commits, my Cloud Resume Challenge is finally complete.

This project wasn’t just about hosting a résumé on AWS. It was about learning real-world cloud engineering practices, from IAM fundamentals to Infrastructure as Code, CI/CD pipelines, and supply chain security.

In this post, I’ll tie everything together, walk through the full journey, and share what I learned.

🧩 Breaking It Down - The 5 Chunks

Throughout the challenge, I split the work into five chunks. Here’s a recap:

🔹 Chunk 0 - Access, Credentials, and Certification Prep

Got AWS Certified Cloud Practitioner.
Created and secured an AWS Organization (1 org, 2 OUs, MFA everywhere).
Configured billing alerts (\$0.01 threshold 🚨).

👉 Read Chunk 0 Blog

🔹 Chunk 1 - Building the Front-End

Created my résumé with Hugo (console theme for a Linux-terminal feel).
Styled with HTML/CSS/JS.
Deployed to S3, secured behind CloudFront (no public bucket access).

👉 Read Chunk 1 Blog

🔹 Chunk 2 - Building the API

Added a visitor counter using DynamoDB + Lambda + API Gateway.
Improved to track total + unique visits.
Enabled S3 bucket versioning + lifecycle policies.

👉 Read Chunk 2 Blog

🔹 Chunk 3 - Front-End & Back-End Integration

Built a GitHub Actions pipeline with OIDC (no long-term creds).
Automated: build → deploy → invalidate CloudFront cache → run Playwright smoke tests.
Pipeline permissions scoped to a single IAM role.

👉 Read Chunk 3 Blog

🔹 Chunk 4 — Building the Automation and CI

Migrated infrastructure into Terraform for IaC.
Hardened supply chain security (pinned Actions, checksum verification, minimal IAM).
Documented with architecture diagrams.

👉 Read Chunk 4 Blog

Perfect — here’s a section you can insert after Chunk 4 (or right before your “Final Architecture” section). It introduces and explains the Supply Chain Security challenge in the same polished tone and structure as your other chunks, keeping the technical depth and clarity consistent with your blog’s progression.

🔹 Securing the Software Supply Chain

The software supply chain is everything that connects your laptop to production, the code you write, the dependencies you install, and the pipelines that deploy it all.
As recent high-profile incidents have shown, a single compromised dependency or misconfigured pipeline can cascade into a massive breach. This chunk was all about building trust and verifiability into that chain.

🧠 The Goal

The objective was to extend my Cloud Resume project to add integrity checks, signed commits, automated scanning, and dependency validation, in short, to treat my résumé like production-grade software.

Here’s what I implemented:

🖋️ Signed Commits and Verified Merges

Every commit to my front-end and back-end repositories is now cryptographically signed using a GPG key.
You’ll see the “Verified” badge on each commit in GitHub, proof that code changes are truly mine.

To take it a step further, I enforced branch protection rules:
✅ Only signed commits can be merged.
✅ Status checks must pass before merging.

This ensures no unsigned or unreviewed changes slip through.

🔍 Automated Code Scanning with CodeQL

Next, I enabled GitHub’s CodeQL analysis, a static analysis engine that detects security vulnerabilities in code patterns.

My workflow now runs CodeQL scans automatically:

On every pull request merge to main
On a monthly schedule to catch dependency decay

Any “High” or “Critical” findings cause the build to fail automatically, protecting the integrity of my main branch.

🧾 Generating an SBOM (Software Bill of Materials)

An SBOM lists every dependency your project includes, like an ingredient list for your software.

During each CI/CD pipeline run, I used Syft to generate an SBOM for the Lambda back-end:

syft dir:. -o json > sbom.json

This ensures I know exactly what’s deployed, every library, its version, and its source.

🕵🏻 Automated Vulnerability Checks

To validate my SBOM, I layered in defense-in-depth vulnerability scans:

Grype — scanned the SBOM for known CVEs across multiple databases.
OSV API — queried Google’s Open Source Vulnerability database for any dependency issues.

Here’s a snippet from my GitHub Actions step:

echo "Running OSV API vulnerability scan..."
jq 'if .artifacts then .artifacts |= map(select(.name != null and .version != null and .version != "UNKNOWN")) else . end' sbom.json > sbom-clean.json
cat sbom-clean.json | jq -c '.artifacts[] | {name: .name, version: .version}' | while read -r pkg; do
  NAME=$(echo "$pkg" | jq -r '.name')
  VERSION=$(echo "$pkg" | jq -r '.version')
  RESPONSE=$(curl -s -X POST "https://api.osv.dev/v1/query" \
    -H "Content-Type: application/json" \
    -d "{\"package\": {\"name\": \"$NAME\"}, \"version\": \"$VERSION\"}")
  if echo "$RESPONSE" | jq -e '.vulns' | grep -q '.'; then
    echo "⚠️ Vulnerability found in $NAME@$VERSION"
    echo "$RESPONSE" | jq -r '.vulns[] | "• \(.id): \(.summary)"'
    exit 1
  fi
done

The job fails if any compromised dependency is detected — preventing insecure code from being deployed.

🧾 Artifact Signing

Since my API runs on AWS Lambda (not containers), I integrated AWS Lambda Code Signing directly into my Terraform definition.
If I had been using containers, I’d have used Cosign with AWS KMS to sign my images, verifying that my deployment artifacts were unaltered from build to deploy.

🧩 What This Achieved

By layering these protections, my pipeline now provides:

✅ Provenance — cryptographic verification from commit to deploy
✅ Integrity — dependencies scanned and tracked via SBOM
✅ Security Automation — no manual checks needed
✅ Trustworthiness — everything verifiable, auditable, and repeatable

This chunk transformed my project from “secure enough” to professionally hardened, aligned with real DevSecOps practices.

🏗️ Final Architecture

Here’s the big picture of the project:

Here is the front-end of the project:

Here is the back-end of the project:

Here is the S3 Lifecycle management of the project:

🌐 The Final Product

✨ Live Resume Website: https://www.trinityklein.dev/
📂 GitHub Repository: https://github.com/tlklein/portfolio-website

Both the code and live deployment are currently publicly available.

💡 Key Lessons Learned

This challenge taught me so much more than AWS commands and YAML syntax.

Security First → MFA, least privilege, no long-term creds.
Automation Wins → GitHub Actions reduced manual deployment risk.
Infrastructure as Code → Terraform makes my project reproducible.
Resilience Through Testing → Playwright ensured code stability.
Documentation Matters → Architecture diagrams simplified communication.

This was more than a résumé site, it became a mini production system.

📚 Helpful Resources

If you’re inspired to start your own Cloud Resume Challenge, here are some key references:

🙌 Final Thoughts

Completing the Cloud Resume Challenge wasn’t easy. There were plenty of moments where I thought, “Why isn’t this working?!” But those moments became the most valuable, because they forced me to dig deeper, learn faster, and think like a real cloud engineer.

This challenge proved that building cloud-native projects requires:

Technical skills 🛠️
Security awareness 🔐
Persistence 💪

And now, I have not only a working cloud résumé, but also a solid foundation for my cloud career.

🫰🏻 Let’s Connect

If you’re following this challenge, or just passing by, I’d love to connect!

I’m always happy to help if you need guidance, want to swap ideas, or just chat about tech. 🚀

I’m also open to new opportunities, so if you have any inquiries or collaborations in mind, let me know!

💼 LinkedIn
🐙 GitHub
✍️ Dev.to Blog
✉️ Email Me

Cloud Resume Challenge - Chunk 4 - Building the Automation and CI

Trinity Klein — Sun, 09 Nov 2025 20:17:22 +0000

By now, my Cloud Resume journey had already given me:

✅ A strong AWS foundation (Chunk 0)
✅ A static front-end (Chunk 1)
✅ A serverless API visitor counter (Chunk 2)
✅ Automated deployments + smoke testing (Chunk 3)

But there was still one major gap: my infrastructure wasn’t yet described in code, and my software supply chain needed extra hardening.

This chunk was all about professional-grade DevOps practices:

Use Terraform to manage AWS resources as code.
Secure the supply chain for my build + deployment pipeline.
Document the system with architecture diagrams.
Share the final product + GitHub repo for transparency.

🌍 Terraforming the Cloud Resume

ClickOps (manually clicking through the AWS console) works when learning, but in production it’s a recipe for drift and risk.
Terraform solved that.

I converted every major AWS component into modular Terraform code, covering:

S3 — hosts static assets with public access disabled, versioning enabled, and force_destroy = false to prevent accidental wipes.
CloudFront — handles global delivery via an Origin Access Control (OAC), with ACM-managed TLS certificates and custom error responses.
DynamoDB — stores visit counts and Terraform’s remote state locking.
Lambda + API Gateway — backend logic for the visitor counter API.
IAM roles & policies — fine-grained permissions following the least-privilege principle.
Route53 & ACM — DNS management and SSL provisioning for the custom domain.

Example Terraform snippet for the S3 bucket module:

resource "aws_s3_bucket" "resume_site" {
  bucket = "my-cloud-resume-site"
  acl    = "private"

  versioning {
    enabled = true
  }

  lifecycle_rule {
    id      = "expire-old-versions"
    enabled = true

    noncurrent_version_expiration {
      days = 30
    }
  }
}

With Terraform, my infrastructure is now:

Repeatable → the entire stack can be recreated in minutes.
Auditable → every change tracked via Git history.
Secure → hardening built directly into the configuration.
Modular → easily reused for staging or new environments.

🧱 Remote state is stored in S3 and locked in DynamoDB to avoid concurrent changes during CI/CD runs, the same pattern used in enterprise environments.

📖 Reference: Terraform Extension — Cloud Resume Challenge

🔐 Securing the Software Supply Chain

A DevOps pipeline is only as secure as its weakest link, so I focused on supply chain hardening this round.

Here’s how I reinforced mine:

Removed long-lived AWS credentials → replaced with OIDC for GitHub Actions (introduced in Chunk 3).
Pinned GitHub Actions versions → no @latest tags, reducing risk of malicious updates.
Checksum verification for dependencies → ensuring integrity of Hugo themes, Node modules, and Terraform providers.
IAM permissions scoped tightly → CI/CD roles can deploy only the resources they own.
Lifecycle + versioning policies → applied to S3 and artifacts for rollback and forensic traceability.

Every deployment now runs with temporary, scoped credentials and logs all actions through AWS CloudTrail.

📖 Reference: Securing Your Software Supply Chain — Cloud Resume Challenge

🏗️ Architecture Diagrams

Sometimes a visual story says more than 1,000 lines of Terraform.
These diagrams document how the system works, end to end.

🔹 High-Level Overview

Frontend: Hugo → S3 → CloudFront
Backend: API Gateway → Lambda → DynamoDB
CI/CD: GitHub Actions (OIDC) → Terraform → AWS
Monitoring: Billing alerts, versioning, and logs baked in

🔹 Front-end

Static files stored in S3 with encryption + access via CloudFront OAC
Lifecycle rules manage old versions
Cache invalidation triggered automatically on deployment

🔹 Back-end

Lambda handles visitor tracking logic
DynamoDB stores unique + total hits
API Gateway exposes secure endpoints with error fallback

🔹 S3 Lifecycle Management

Older noncurrent objects automatically transition to cheaper storage classes
Retention and cleanup policies guard against bloat and accidental deletion

🧱 AWS Account Structure & Hardening

Beyond just code, I also aligned my AWS account structure with production-grade practices:

AWS Organization with production and test OUs.
Separate accounts for isolated workloads.
MFA enforced across all users.
Root account locked and only used for billing.
Budget alerts trigger at $0.01 to catch any unintended spend early.

This structure ensures that even as the project scales, security, cost control, and governance remain intact.

🌐 View the Final Product

✨ Live Resume Website: https://www.trinityklein.dev/
📂 GitHub Repository: https://github.com/tlklein/portfolio-website/

Both the code and infrastructure are public, versioned, and reproducible.

🚀 Lessons Learned in Chunk 4

By completing this chunk, I achieved:

✅ Infrastructure as Code with Terraform
✅ Stronger software supply chain security
✅ Visual documentation via architecture diagrams
✅ Multi-account AWS setup for safety + scalability
✅ A fully public and auditable portfolio project

At this stage, the Cloud Resume Challenge evolved from a portfolio exercise into a production-ready personal platform.

📚 Helpful Resources

Resources that helped along the way:

💬 Let’s Connect

That wraps up Chunk 4 of the Cloud Resume Challenge! 🎉

Which IaC tool do you prefer for your cloud builds, Terraform, CDK, or CloudFormation?
Drop your thoughts below, I’d love to compare notes with other builders. 👇

Would you like me to turn this version into a LinkedIn article format next (optimized for publishing directly on LinkedIn with preview sections, emojis, and image layout cues)? It would pair perfectly with your series posts.

🫰🏻 Let’s Connect

If you’re following this challenge, or just passing by, I’d love to connect!

I’m always happy to help if you need guidance, want to swap ideas, or just chat about tech. 🚀

I’m also open to new opportunities, so if you have any inquiries or collaborations in mind, let me know!

💼 LinkedIn
🐙 GitHub
✍️ Dev.to Blog
✉️ Email Me

Cloud Resume Challenge - Chunk 3 - Front-End & Back-End Integration

Trinity Klein — Fri, 26 Sep 2025 14:00:00 +0000

By this stage of the Cloud Resume Challenge, you’ve got a working backend (API Gateway + Lambda + DynamoDB) and a static website hosted on S3 + CloudFront. The next step is where the pieces start to come together: connecting the frontend to the backend, automating deployments, and making sure your project doesn’t break every time you push new code.

In this blog, I’ll walk through exactly how I tackled Chunk 3:

Connecting the API to the website with JavaScript
Writing smoke tests to validate the system end-to-end
Automating deployments with GitHub Actions
Securing everything with OIDC roles

1. Connecting the API to the Website

The goal here is to display the live visitor count from DynamoDB on the website.

Writing the JavaScript Call

At its core, this is just a fetch() request to your API Gateway endpoint:

async function updateVisitorCount() {
  const response = await fetch("https://your-api-gateway-id.execute-api.region.amazonaws.com/prod/visitors");
  const data = await response.json();
  document.getElementById("visitor-count").innerText = data.count;
}
updateVisitorCount();

That’s it—just a couple of lines!

Solving CORS Issues

The biggest headache is CORS (Cross-Origin Resource Sharing). By default, browsers will block calls between your static website domain and your API Gateway domain.

To fix this:

In API Gateway, enable CORS for your routes.
Allow the domain of your CloudFront distribution (not just *) for better security.
Test again in the browser console to confirm the API call succeeds.

Once working, your static site is now dynamic, pulling in live data from AWS.

2. Writing Smoke Tests with Playwright

Manual testing is fine when you’re experimenting, but production-ready cloud apps need automation. That’s where Playwright comes in.

Playwright allows you to run end-to-end smoke tests:

import { test, expect } from '@playwright/test';

test('Visitor counter API updates correctly', async ({ request }) => {
  const response = await request.get('https://your-api-gateway-id.execute-api.region.amazonaws.com/prod/visitors');
  const body = await response.json();
  expect(body.count).toBeGreaterThan(0);
});

This test confirms:

The API is reachable.
It returns valid data.
The visitor count increments as expected.

Other smoke tests I added:

API rejects malformed requests.
Visitor count initializes correctly (no undefined/null values).
Database updates persist between calls.

These tests validate not just the Lambda code, but the entire deployed stack: API Gateway, Lambda, IAM roles, and DynamoDB.

3. Automating with GitHub Actions

Now that the site talks to the backend and tests exist, the next step is to automate deployments.

Here’s what my GitHub Actions pipeline does on every push to main:

Deploy Static Website – Syncs the Hugo build to the S3 bucket.
Invalidate CloudFront Cache – Ensures new changes show instantly worldwide.
Deploy Lambda + Infrastructure – Uses IaC (e.g., Terraform or SAM) for backend updates.
Run Smoke Tests – Executes Playwright tests against the live API endpoint.

Example deploy.yml:

name: Deploy Cloud Resume Challenge

on:
  push:
    branches: [ "main" ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy Infrastructure
        run: ./deploy_infra.sh
      - name: Run Playwright Tests
        run: npx playwright test

This workflow means no manual deployments. Every code push goes live automatically—with tests ensuring nothing breaks.

4. Securing with OIDC Roles

One of the most important lessons from this challenge: never use long-lived AWS credentials in CI/CD pipelines.

Instead, I set up OIDC (OpenID Connect) roles between GitHub Actions and AWS:

GitHub is configured as an OIDC identity provider in AWS IAM.
A dedicated IAM role allows GitHub workflows to assume permissions temporarily.
No AWS keys stored in the repo—security risks eliminated.

This is how professional teams handle authentication for CI/CD. It’s secure, scalable, and reduces human error.

Final Thoughts

Chunk 3 transformed my project from “a static site with a backend” into a production-ready cloud application:

The frontend and backend communicate securely.
Automated smoke tests validate every deployment.
CI/CD pipelines push changes with confidence.
OIDC roles keep the workflow secure. These are what connecting services, automating deployments, and securing infrastructure that make it a complete application.

Helpful Resources

Here’s what helped me in Chunk 3:

Let’s Connect

If you’re following this challenge, or just passing by, I’d love to connect! I’m always happy to help if you need guidance, want to swap ideas, or just chat about tech.

I’m also open to new opportunities, so if you have any inquiries or collaborations in mind, let me know!

💼 LinkedIn
🐙 GitHub
✍️ Dev.to Blog
✉️ Email Me

Cloud Resume Challenge - Chunk 2 - Building the API

Trinity Klein — Fri, 19 Sep 2025 14:00:00 +0000

After getting my front-end live on S3 + CloudFront in Chunk 1, it was time to give it some brains. 🧠

The goal for this stage:
👉 Add a visitor counter (hit counter → visitor counter) to my portfolio website.

This wasn’t just about displaying a number, it was about learning how to stitch together AWS Lambda, API Gateway, DynamoDB, and IAM into a working serverless backend.

🗄️ Designing the Visitor Counter

The stack I chose:

DynamoDB → store visitor data (IPs + visit counts).
Lambda → serverless compute that updates/query the table.
API Gateway → REST API to expose the Lambda function securely.
IAM Roles → restrict who/what can read/write from DynamoDB.

Here’s the flow:

Browser → API Gateway → Lambda → DynamoDB

On page load, the API Gateway calls the Lambda function, which fetches & updates the DynamoDB table. The number is then displayed in my site’s footer.

If the data can’t be fetched, the site gracefully falls back to showing "Loading...".

🔁 From Hit Counter → Visitor Counter

Originally, this was just a simple hit counter, every page refresh added +1. But I refactored it into a proper visitor counter with:

Total visits (every page load).
Unique visitors (per IP, per 24-hour window).

This required:

A new DynamoDB table to store hashed IP addresses.
A smarter Lambda function (see below).
Test data (dummy items) to validate in production.

📝 The Lambda Function (v2)

Here’s the core Lambda function I deployed (Python 3.9):

# Version 2 of lambda function
# Stores IP addresses in a one-way hash
# Only counts unique visits once per 24 hours

import json
import boto3
import os
from datetime import datetime, timedelta
import hashlib

dynamodb = boto3.client('dynamodb')
TABLE_NAME = os.environ.get('TABLE_NAME', 'VisitorCounter')
UNIQUE_VISITOR_WINDOW_HOURS = 24  # uniqueness window

def handler(event, context):
    print("Incoming event:", json.dumps(event, indent=2))

    # Extract and hash IP
    ip_address = get_ip_address(event)
    if ip_address == "0.0.0.0":
        return error_response("Unable to determine IP")

    hashed_ip = hash_ip(ip_address)
    now = datetime.utcnow()
    now_str = now.isoformat()

    try:
        response = dynamodb.get_item(
            TableName=TABLE_NAME,
            Key={'ip_address': {'S': hashed_ip}}
        )

        is_new_visitor = False

        if 'Item' in response:
            last_visit = response['Item'].get('last_visit', {}).get('S')
            last_visit_time = datetime.fromisoformat(last_visit)

            if now - last_visit_time >= timedelta(hours=UNIQUE_VISITOR_WINDOW_HOURS):
                is_new_visitor = True
                dynamodb.update_item(
                    TableName=TABLE_NAME,
                    Key={'ip_address': {'S': hashed_ip}},
                    UpdateExpression="SET visit_count = visit_count + :inc, last_visit = :now",
                    ExpressionAttributeValues={
                        ":inc": {"N": "1"},
                        ":now": {"S": now_str}
                    }
                )
        else:
            is_new_visitor = True
            dynamodb.put_item(
                TableName=TABLE_NAME,
                Item={
                    "ip_address": {"S": hashed_ip},
                    "visit_count": {"N": "1"},
                    "first_visit": {"S": now_str},
                    "last_visit": {"S": now_str}
                }
            )

        scan = dynamodb.scan(
            TableName=TABLE_NAME,
            AttributesToGet=["visit_count"]
        )
        total_visits = sum(int(item["visit_count"]["N"]) for item in scan["Items"])
        unique_visitors = len(scan["Items"])

        return {
            "statusCode": 200,
            "headers": {
                "Access-Control-Allow-Origin": "*",
                "Content-Type": "application/json"
            },
            "body": json.dumps({
                "unique_visitors": unique_visitors,
                "total_visits": total_visits,
                "is_new_visitor": is_new_visitor
            })
        }

    except Exception as e:
        print("Error:", str(e))
        return error_response("Internal server error")

def get_ip_address(event):
    headers = event.get("headers", {})
    ip_sources = [
        event.get("requestContext", {}).get("http", {}).get("sourceIp"),
        event.get("requestContext", {}).get("identity", {}).get("sourceIp"),
        headers.get("x-forwarded-for", "").split(",")[0].strip(),
        headers.get("X-Forwarded-For", "").split(",")[0].strip(),
        headers.get("x-real-ip"),
        headers.get("X-Real-IP"),
        headers.get("cf-connecting-ip"),
        headers.get("CF-Connecting-IP"),
    ]
    for ip in ip_sources:
        if ip:
            return ip
    return "0.0.0.0"

def hash_ip(ip):
    return hashlib.sha256(ip.encode()).hexdigest()

def error_response(message):
    return {
        "statusCode": 500,
        "body": json.dumps({"error": message})
    }

Key features:

🔒 Privacy-first → IP addresses are SHA-256 hashed.
🕒 Uniqueness window → Only 1 count per IP in 24 hours.
📊 Metrics returned → total visits, unique visitors, is_new_visitor.

🛡️ IAM Role Setup

To keep things secure:

The Lambda function only has dynamodb:GetItem, PutItem, UpdateItem, and Scan permissions for the specific table.
API Gateway was given permission to invoke the Lambda.
No overly broad permissions, least privilege only.

# IAM Policy Example
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["dynamodb:UpdateItem", "dynamodb:GetItem"],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/VisitorCounter"
    }
  ]
}

📦 S3 Bucket Improvements

While working on the API, I also hardened my S3 setup:

✅ Versioning enabled → recover files in case of accidental overwrite.
✅ Lifecycle policies → move old versions to cheaper storage.

This gave me resilience + cost control.

🔄 REST API vs Real-Time

I briefly considered building a real-time visitor counter using:

API Gateway (WebSockets)
DynamoDB Streams

But here’s the truth:

⚠️ It would be more expensive at scale.
⚠️ It would be much more complex to set up and optimize.
✅ And… the user experience would be basically the same.

So I stuck with a REST API, simple, reliable, and cost-effective.

🚀 Lessons Learned in Chunk 2

By the end of this chunk, I achieved:
✅ Built an API Gateway + Lambda + DynamoDB visitor counter
✅ Upgraded from hit counter → unique visitor counter
✅ Secured roles with IAM least privilege
✅ Added resilience with bucket versioning + lifecycle policies
✅ Made intentional design decisions (REST > WebSocket for this use case)

This was the first time my project felt full-stack serverless, front-end + backend working together. 💡

🌟 What’s Next?

Next up: Chunk 3, adding a CI/CD pipeline so that deployments are automated, tested, and production-ready.

That’s when the project will really level up. ⚡

Drop a comment with how you approached your visitor counter, did you try REST, WebSockets, or something else? I would love to know how you approached it.

📚 Helpful Resources

Here’s what helped me in Chunk 2:

🫰🏻 Let’s Connect

If you’re following this challenge, or just passing by, I’d love to connect!

I’m always happy to help if you need guidance, want to swap ideas, or just chat about tech. 🚀

I’m also open to new opportunities, so if you have any inquiries or collaborations in mind, let me know!

💼 LinkedIn
🐙 GitHub
✍️ Dev.to Blog
✉️ Email Me

Cloud Resume Challenge - Chunk 1 - Building the Front-End

Trinity Klein — Fri, 12 Sep 2025 14:00:00 +0000

Cloud Resume Challenge – Chunk 1: Building and Hosting the Front-End

The second step of the Cloud Resume Challenge is all about creating and hosting the front-end of your resume website. While this section may feel simple compared to the upcoming back-end work, it’s critical because it sets the stage for later integration. You’ll build a static site, host it securely on AWS S3, and distribute it globally with CloudFront.

This guide explains exactly how I approached Chunk 1, the decisions I made, and the AWS best practices I followed.

Step 1: Why the Front-End Matters

It’s tempting to think of HTML and CSS as the easy part of the challenge. In reality, this stage is more about completeness and professionalism than design. A static website:

Demonstrates end-to-end deployment skills.
Gives you something tangible to showcase in an interview.
Prepares you for the bigger challenge of front-end + back-end integration, which is where cloud engineering skills really shine.

The purpose is not to become a front-end expert, but to build a solid, secure platform that can connect with AWS services like DynamoDB, Lambda, and API Gateway later.

Step 2: Choosing a Framework

Instead of writing a single massive HTML file, I used the Hugo Console theme. Hugo is a static site generator, which makes your website more maintainable and scalable over time. Benefits of Hugo:

Extremely fast build times (~55ms load time on my site).
Modular templates for pages like Resume, Projects, Blog, and Contact.
Easy customization of text, images, and layouts.

If you prefer JavaScript frameworks, you could use Next.js, React, Vue, or Svelte, but for the purposes of this challenge, Hugo (or Eleventy) is more than enough.

Step 3: Hosting the Static Site on AWS S3

Once the site files were generated, I hosted them on an Amazon S3 bucket. The naive approach is to make the bucket public for static hosting—but that’s insecure. Instead, I followed the professional setup:

Create an S3 bucket with the same name as your domain (e.g., mydomain.com).
Block all public access. This prevents anyone from directly reaching your bucket objects.
Upload the Hugo-generated files to the S3 bucket.
Enable static website hosting to get an endpoint, though it won’t be public yet.

Step 4: Securing with CloudFront and OAC

To deliver the site securely and globally, I set up CloudFront. This provides caching, speed, and access control:

Create a CloudFront distribution pointing to the S3 bucket.
Enable Origin Access Control (OAC) so only CloudFront can fetch objects from the bucket.
Update the S3 bucket policy to grant CloudFront permission.
Configure cache behaviors to improve performance while still allowing invalidation when updates are deployed.

With this, visitors only interact with CloudFront, not the S3 bucket, which keeps the environment secure and professional.

Step 5: Testing the Setup

After configuration, I validated the site:

Verified global accessibility by testing load times from multiple locations.
Confirmed cache invalidation worked properly when I updated site content.
Checked that no direct public access to the S3 bucket was possible.

The result was a lightweight, professional-grade static site ready to integrate with AWS back-end services in future chunks.

Key Takeaways

Static sites are the foundation: This step isn’t about flashy design; it’s about creating a maintainable, secure project you can build on.
Use frameworks like Hugo: They save time and give you clean, fast-loading templates.
Follow AWS security best practices: Block public access to S3, use OAC, and route all traffic through CloudFront.
Think ahead: This site will soon interact with APIs, databases, and automation. Setting it up securely now pays dividends later.

Helpful Resources

Here are some resources that helped me through Chunk 1:

Let’s Connect

If you’re following this challenge, or just passing by, I’d love to connect! I’m always happy to help if you need guidance, want to swap ideas, or just chat about tech.

I’m also open to new opportunities, so if you have any inquiries or collaborations in mind, let me know!

Cloud Resume Challenge - Chunk 0 - Access, Credentials, and Certification Prep

Trinity Klein — Fri, 05 Sep 2025 14:00:00 +0000

The Cloud Resume Challenge starts long before you deploy your first Lambda function or wire up a DynamoDB table. The first step is creating a secure foundation—because AWS is powerful, and mistakes can lead to credential leaks, security incidents, or runaway billing. This guide walks through how I set up my environment, managed credentials professionally, and earned my AWS Certified Cloud Practitioner certification to validate my understanding of the cloud.

Step 1: Setup and Safety (Before You Begin)

Think of AWS like a power tool: misused, it can cause damage. Before provisioning anything, take these precautions:

Enable MFA on the root account. Never use the root user for daily tasks. Store its credentials in a password manager and only log in for account setup.
Create an IAM user with MFA. Use this user to manage access, but avoid attaching long-term access keys directly.
Adopt IAM roles. Instead of static credentials, assume roles with temporary credentials for each session.
Set billing alerts. Go to the AWS Billing Console and create alerts to notify you if costs exceed your expected usage.
Delete unused resources. The fastest way to eliminate unexpected charges is to remove resources once you’re done testing.

These steps prevent attackers from hijacking your account and keep costs predictable while learning.

Step 2: Access and Credentials

You’ll need two ways to access AWS:

The AWS Console – the web interface.
The CLI/SDKs – where automation and code-driven access live.

There are two approaches to configuring access:

The Original Way (if you must)

Create an IAM user with programmatic access.
Store credentials in configuration files on your local machine.
Optionally use tools like aws-vault or awsume to manage role assumptions securely.
Always enable MFA and never hardcode credentials into code or repositories.

This method works, but static credentials are a liability.

The Professional Way (recommended)

This is how cloud teams operate in production, and how I structured my environment:

Create an AWS Organization in your root account.
Add at least two Organizational Units (OUs) – one for Production, one for Development/Test.
Inside each OU, create accounts. Use + email suffixes (e.g., you+dev@gmail.com) to reuse your main email.
Set up AWS IAM Identity Center (formerly SSO). This lets you sign in securely without relying on static keys.
Configure the CLI with Identity Center for seamless login across accounts. Tools like aws-sso-util make this easier.
Always enforce MFA on SSO logins.

This setup takes longer, but once complete, you’ll have a professional-grade AWS environment with no need for long-lived credentials.

Step 3: AWS Certified Cloud Practitioner

Before diving deep into infrastructure, I prepared for and passed the AWS Certified Cloud Practitioner exam.

This entry-level certification validated my knowledge of:

Core AWS services: S3, EC2, Lambda, DynamoDB.
Global infrastructure: regions, availability zones, edge locations.
Security best practices: IAM, MFA, shared responsibility model.
Billing and pricing models: free tier, pay-as-you-go, cost optimization strategies.

The study process reinforced the importance of secure setup and gave me the vocabulary to navigate AWS documentation confidently.

📎 View my verified badge here: AWS Cloud Practitioner on Credly

Step 4: Guarding Against Costs

Even within the free tier, costs can accumulate unexpectedly. Best practices I followed:

Delete unused accounts/resources after testing.
Use billing alerts with SNS notifications for thresholds.
Regularly review the Billing Dashboard to confirm free-tier compliance.
If mistakes happen (e.g., leaving an expensive instance running), contact AWS Support—first-time errors are often forgiven.

Key Takeaways

Start with security-first principles: MFA, least privilege, temporary credentials.
Use AWS Organizations and IAM Identity Center for scalable, professional credential management.
Validate knowledge with the AWS Certified Cloud Practitioner exam.
Monitor and control billing to avoid surprises.

With this foundation, you’re ready to move into the hands-on build phases of the Cloud Resume Challenge: deploying static websites, APIs, and serverless functions with confidence.

Helpful Resources

If you’re starting, here are some resources that helped me:

Let’s Connect

If you’re following this challenge, or just passing by, I’d love to connect! I’m always happy to help if you need guidance, want to swap ideas, or just chat about tech.

I’m also open to new opportunities, so if you have any inquiries or collaborations in mind, let me know!