DEV Community: Priyanka Vuddemari

Cloud Resume Challenge Week 4— Testing the Serverless Backend with Playwright and Python

Priyanka Vuddemari — Mon, 05 Oct 2026 07:02:21 +0000

Chunk 4 is complete — with my background in DevOps and Test automation, this chunk felt most natural.

The goal is straightforward: write automated tests to verify that the serverless backend works correctly. In this post I'll walk through the tests I wrote, why I chose Playwright over Cypress, and how I integrated everything into the CI/CD pipeline.

Why Playwright over Cypress?

The challenge gives you two options — Cypress (JavaScript) or Playwright (Python). I chose Playwright for one simple reason: Python.

The Lambda function is already written in Python, and writing tests in the same language keeps the project consistent. Playwright's Python API is also clean, well-documented, and fits naturally with pytest which is already a standard in the Python testing world.

What to Test?

The book recommends two types of tests:

Unit tests — test Lambda function logic in isolation, mocking DynamoDB calls. Simple but limited since you are mostly testing mocked behavior rather than real infrastructure.

Smoke tests / End-to-end tests which run after deployment against the real live API URL. These verify the full stack is working — Lambda, API Gateway, DynamoDB, and permissions ,all in one test run.

I went with smoke tests and end-to-end browser tests. They are far more valuable and generate much better interview conversation.

Setting Up Playwright

Install Playwright and its pytest plugin:

pip install pytest-playwright requests
playwright install chromium

I also updated the dev container so Playwright is installed automatically on every Codespace rebuild:

"postCreateCommand": "pip install pytest-playwright && playwright install chromium"

The Tests

I created a tests/ folder with a single test file test_resume.py.

import pytest
import requests
from playwright.sync_api import sync_playwright

API_URL = "https://YOUR_API_URL"
RESUME_URL = "https://YOUR-CLOUDFRONT-URL"

# ── API Smoke Tests ──

def test_api_returns_200():
    """API should return a 200 status code"""
    response = requests.get(API_URL)
    assert response.status_code == 200

def test_api_returns_views_key():
    """API response should contain a views key"""
    response = requests.get(API_URL)
    data = response.json()
    assert "views" in data

def test_api_views_is_integer():
    """Views count should be an integer"""
    response = requests.get(API_URL)
    data = response.json()
    assert isinstance(data["views"], int)

def test_api_views_increments():
    """Views count should increment on each call"""
    first = requests.get(API_URL).json()["views"]
    second = requests.get(API_URL).json()["views"]
    assert second == first + 1

def test_api_views_greater_than_zero():
    """Views count should be greater than zero"""
    response = requests.get(API_URL)
    data = response.json()
    assert data["views"] > 0

# ── End to End Browser Tests ──

def test_resume_page_loads():
    """Resume page should load successfully"""
    with sync_playwright() as p:
        browser = p.chromium.launch()
        page = browser.new_page()
        response = page.goto(RESUME_URL)
        assert response.status == 200
        browser.close()

def test_resume_has_title():
    """Resume page should have a title"""
    with sync_playwright() as p:
        browser = p.chromium.launch()
        page = browser.new_page()
        page.goto(RESUME_URL)
        assert page.title() != ""
        browser.close()

def test_visitor_counter_displays():
    """Visitor counter should be visible on the page"""
    with sync_playwright() as p:
        browser = p.chromium.launch()
        page = browser.new_page()
        page.goto(RESUME_URL)
        page.wait_for_selector("#views-count")
        count = page.inner_text("#views-count")
        assert count.isdigit()
        browser.close()

What Each Test Covers

API Smoke Tests:

API returns HTTP 200 — basic health check
Response contains a views key — correct response structure
Views count is an integer — correct data type
Views count increments on each call — counter logic works
Views count is greater than zero — database has been initialised

End to End Browser Tests:

Resume page loads successfully — CloudFront + S3 serving correctly
Resume page has a title — HTML is rendering properly
Visitor counter displays — JavaScript fetch and DOM update working

Running the Tests

pytest tests/ -v

All 8 tests passed on the first run locally.

Adding Tests to the CI/CD Pipeline

The real value of automated tests is running them automatically. I added two steps to the GitHub Actions workflow:

      - name: Install Python test dependencies
        run: |
          pip install pytest-playwright requests
          playwright install chromium

      - name: Run Playwright tests
        run: pytest tests/ -v

Now every push to main triggers the full pipeline:

Push to GitHub
      ↓
Sync files to S3
      ↓
Invalidate CloudFront cache
      ↓
Terraform apply
      ↓
Run Playwright tests ← new!
      ↓
All green ✅

Key Takeaways

Smoke tests beat unit tests for serverless — testing against the real live API verifies Lambda, API Gateway, DynamoDB, and IAM permissions all at once
Playwright + pytest is a natural fit — clean API, familiar tooling, easy to extend
Tests in CI/CD is non-negotiable — running tests locally is good, running them automatically on every push is better
The visitor counter test is the most valuable — it validates the entire chain from browser to database in a single assertion

What's Next

Chunk 4 wraps up the core challenge. Next up is the final post — a complete retrospective of the entire Cloud Resume Challenge journey.

*My Cloud Resume Challenge series here *

Cloud Resume Challenge Week 3— Infrastructure as Code with Terraform and CI/CD with GitHub Actions

Priyanka Vuddemari — Sun, 27 Sep 2026 13:56:34 +0000

Chunk 3 is complete — and this one pushed me the furthest outside my comfort zone. Infrastructure as Code, remote state management, and a fully automated CI/CD pipeline are all now in place.

In this post I'm documenting exactly what I built, the decisions I made, and the bugs I hit along the way.

What is Chunk 3 about?

The goal is to stop clicking through the AWS Console and start defining infrastructure as code — and then automate deployments so every push to GitHub triggers a full deploy automatically.

The tools involved:

Terraform — define all AWS resources as code
GitHub Actions — automate the deployment pipeline
S3 remote backend — store Terraform state so CI/CD and local machines share the same view of infrastructure
Dev Container — reproducible development environment in GitHub Codespaces

Why Terraform over AWS SAM?

The challenge recommends AWS SAM for IaC, but I chose Terraform instead. Here is why:

Terraform is cloud agnostic — the same skills work on AWS, Azure, and GCP
It is by far the most in-demand IaC tool in the industry right now
HCL (HashiCorp Configuration Language) is clean and readable
The Terraform ecosystem and community are excellent

Setting Up the Dev Container

Since I am working in GitHub Codespaces, the first thing I did was create a dev container so every time the environment starts, all tools are pre-installed automatically.

I created .devcontainer/devcontainer.json:

{
  "name": "Cloud Resume Challenge",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/devcontainers/features/aws-cli:1": {},
    "ghcr.io/devcontainers/features/terraform:1": {},
    "ghcr.io/devcontainers/features/python:1": {
      "version": "3.12"
    },
    "ghcr.io/devcontainers/features/github-cli:1": {}
  }
}

This installs AWS CLI, Terraform, Python, and GitHub CLI automatically on every Codespace rebuild. No more manual setup.

Terraform Project Structure

terraform/
├── main.tf        ← all AWS resources
├── variables.tf   ← input variables
├── outputs.tf     ← output values
└── providers.tf   ← AWS provider + backend config

The resources defined in Terraform:

S3 bucket with static website hosting and public access policy
DynamoDB table for the visitor counter
IAM role and policies for Lambda
Lambda function
API Gateway HTTP API with GET /count route
Lambda permission for API Gateway

Remote Backend — The Most Important Step

This is the step most beginners skip and then wonder why CI/CD fails.

By default Terraform stores its state file locally on your machine. When GitHub Actions runs Terraform it has no idea what already exists in AWS — so it tries to create everything from scratch and hits conflicts.

The fix is a remote backend — store the state file in S3 so both your local machine and GitHub Actions share the same state.

I added this to providers.tf:

backend "s3" {
  bucket = "priyanka-terraform-state"
  key    = "cloud-resume/terraform.tfstate"
  region = "ap-south-2"
}

Then ran:

terraform init -migrate-state

This moved the local state file to S3. From that point on both local and CI/CD shared the same state.

Key lesson: Always set up remote state before setting up CI/CD. If you do it the other way around you will hit resource conflict errors on every pipeline run.

Bugs I Hit Along the Way

Bug 1 — Resource conflicts on first apply
Since I had already created S3, DynamoDB, Lambda, and API Gateway manually earlier in the challenge, Terraform tried to create them again and hit 409 conflict errors.

Fix: import existing resources into Terraform state:

terraform import aws_s3_bucket.resume priyanka-cloud-resume-challenge
terraform import aws_lambda_function.counter cloud-resume-counter
terraform import aws_dynamodb_table.counter cloud-resume-counter

Bug 2 — DynamoDB table item import not supported
Terraform does not support importing aws_dynamodb_table_item resources. The item already existed from manual setup so Terraform kept trying to create it and failing.

Fix: removed the aws_dynamodb_table_item resource from main.tf entirely. The item already exists and Lambda manages the views count dynamically — Terraform does not need to manage it.

Bug 3 — GitHub Actions had no Terraform state
The pipeline kept hitting resource conflict errors because the state file was local and not shared with GitHub Actions.

Fix: set up the S3 remote backend as described above. Once state was in S3, both local and CI/CD shared the same view of infrastructure and conflicts stopped.

Bug 4 — String concatenation error in outputs.tf
Used + operator to concatenate strings in Terraform — which is a number operator, not a string operator.

Fix: use string interpolation instead:

value = "${trimsuffix(aws_apigatewayv2_stage.default.invoke_url, "/")}/count"

The GitHub Actions Pipeline

The pipeline runs automatically on every push to main and also supports manual triggers via workflow_dispatch.

name: Deploy Cloud Resume

on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ap-south-2

      - name: Sync files to S3
        run: |
          aws s3 sync . s3://priyanka-cloud-resume-challenge \
            --exclude "*" \
            --include "index.html" \
            --include "styles.css" \
            --delete

      - name: Invalidate CloudFront cache
        run: |
          aws cloudfront create-invalidation \
            --distribution-id ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }} \
            --paths "/*"

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      - name: Terraform Init
        working-directory: ./terraform
        run: terraform init

      - name: Terraform Apply
        working-directory: ./terraform
        run: terraform apply -auto-approve

      - name: Smoke test
        run: |
          response=$(curl -s https:YOUR_URL)
          if echo "$response" | grep -q "views"; then
            echo "Smoke test passed!"
          else
            echo "Smoke test failed!"
            exit 1
          fi

What the Pipeline Does

Push to GitHub
      ↓
Checkout code
      ↓
Configure AWS credentials
      ↓
Sync index.html + styles.css → S3
      ↓
Invalidate CloudFront cache
      ↓
Terraform init + apply
      ↓
Smoke test → verify API returns views count

Key Takeaways

Remote state is not optional for CI/CD — without it every pipeline run hits resource conflicts
Import existing resources before applying — if you created resources manually first, import them before letting Terraform manage them
Terraform string interpolation — use ${} not + for string concatenation
Dev containers save time — define your environment once, never set it up again
workflow_dispatch is underrated — being able to trigger the pipeline manually without a dummy commit is very useful

What's Next

Next up is writing tests for the Lambda function and then tackling the challenge mods — AI Engineer Mod and DevOps multi-stage pipeline.

Part of my Cloud Resume Challenge series. Read here

Cloud Resume Challenge Week 2 — Building the Serverless Backend with Lambda, DynamoDB & API Gateway

Priyanka Vuddemari — Thu, 24 Sep 2026 03:16:32 +0000

Chunk 2 is complete — and this was by far the most challenging and rewarding part of the challenge so far.

In this post I'm documenting exactly how I built the serverless visitor counter backend : Lambda, DynamoDB, API Gateway , and the bugs I encountered along the way. The debugging section is the most valuable part, so I've kept it honest and detailed.

What is Chunk 2 about?

The goal is to build a serverless API that:

Stores a visitor count in a database
Increments it every time someone visits the resume
Returns the count to the website to display

The AWS services involved:

DynamoDB — NoSQL database to store the view count
Lambda — Python function to read and update the count
API Gateway — exposes Lambda via a public URL
JavaScript — calls the API from the resume page

Step 1 — Creating the DynamoDB Table

DynamoDB is AWS's managed NoSQL database. For this project it stores one simple record as the visitor count.

Go to DynamoDB → Create table
Table name: cloud-resume-counter
Partition key: id → type String
Leave everything else as default → Create table

Once created, add the initial item:

id = 1 (String)
views = 0 (Number)

⚠️ Important: Make sure id is set as String type, not Number. This caused issues later. DynamoDB was creating duplicate items because of a type mismatch between String "1" and Number 1.

Step 2 — Creating the Lambda Function

Lambda is a serverless compute service that runs your code without managing any servers.

Go to Lambda → Create function
Function name: cloud-resume-counter
Runtime: Python 3.14
Leave everything else as default → Create function

Here's the Python code:

import json
import boto3
from decimal import Decimal

dynamodb = boto3.resource('dynamodb', region_name='ap-south-2')
table = dynamodb.Table('cloud-resume-counter')

def lambda_handler(event, context):

    # Get current count
    response = table.get_item(Key={'id': '1'})
    item = response.get('Item', {})
    views = item.get('views', 0)

    # Increment count
    views = int(views) + 1

    # Update the count in DynamoDB
    table.update_item(
        Key={'id': '1'},
        UpdateExpression='SET #v = :val',
        ExpressionAttributeNames={'#v': 'views'},
        ExpressionAttributeValues={':val': Decimal(views)}
    )

    # Return the new count
    return {
        'statusCode': 200,
        'headers': {
            'Access-Control-Allow-Origin': '*',
            'Access-Control-Allow-Methods': 'GET, POST, OPTIONS',
            'Access-Control-Allow-Headers': 'Content-Type'
        },
        'body': json.dumps({'views': views})
    }

Click Deploy to save the function.

Step 3 — IAM Permissions

By default Lambda has no access to DynamoDB. Permissions must be granted explicitly.

Go to Configuration tab → Permissions
Click the execution role name
In IAM → Add permissions → Attach policies
Search for AmazonDynamoDBFullAccess → attach it

Skipping this step results in an AccessDeniedException when the function runs.

Bugs I Encountered Along the Way

This section documents the real issues I ran into because the debugging process is where the actual learning happens.

Bug 1 — AccessDeniedException
Lambda could not access DynamoDB at all.
Fix: attach AmazonDynamoDBFullAccess policy to the Lambda execution role.

Bug 2 — Region Mismatch
Lambda was created in eu-north-1 and DynamoDB in ap-south-2 by mistake. Lambda was looking for the table in the wrong region and returning empty responses.

💡 Key lesson: Lambda and DynamoDB must be in the same AWS region. Always verify the region selector in the top right corner of the AWS Console before creating resources.

Bug 3 — DynamoDB Type Mismatch
The table ended up with two items: one with id as String "1" and another with id as Number 1. Lambda was creating a new item instead of updating the existing one.
Fix: delete the Number 1 item, keep only the String "1" item.

Bug 4 — KeyError: 'Item'
This error persisted because Lambda was connecting to the wrong region and could not find the item at all. Aligning Lambda and DynamoDB to the same region resolved it.

Step 4 — Setting Up API Gateway

API Gateway provides a public HTTPS URL in front of the Lambda function so the browser can call it.

Go to API Gateway → Create API → HTTP API → Build
Add integration → Lambda → select cloud-resume-counter
API name: cloud-resume-api
Route: GET /count
Stage: $default with auto-deploy enabled
Create

The invoke URL will look like:

https://abc123.execute-api.ap-south-2.amazonaws.com/count

Test it in the browser — the response should be:

{"views": 1}

Step 5 — Connecting the Resume Website

The final step — adding JavaScript to index.html to fetch and display the count.

Add this where the counter should appear:

<div class="visitor-counter">
  This resume has been viewed
  <span id="views-count">...</span> times
</div>

Add this script before </body>:

fetch('https://YOUR-API-GATEWAY-URL/count')
  .then(response => response.json())
  .then(data => {
    document.getElementById('views-count').textContent = data.views;
  })
  .catch(error => {
    console.error('Error fetching views:', error);
    document.getElementById('views-count').textContent = '-';
  });

Upload the updated index.html to S3 and the resume now displays a live visitor counter.

Final Architecture

Browser → CloudFront → S3 (HTML + CSS)
    ↓
JavaScript fetch()
    ↓
API Gateway → Lambda (Python) → DynamoDB
              increments count    stores views

Key Takeaways

AWS regions matter — services must be in the same region to communicate properly
IAM permissions are explicit — no service can access another without being granted permission
DynamoDB types are strict — String "1" and Number 1 are treated as completely different partition keys
CloudWatch logs are essential — when Lambda fails, logs show exactly what went wrong
Serverless is cost effective — the entire backend runs at essentially $0 on AWS free tier

What's Next

Next up is the CI/CD pipeline using GitHub Actions automating deployments so changes push to S3 automatically on every commit.

Cloud Resume Challenge Week 1 — What I Built and How I Did It

Priyanka Vuddemari — Tue, 15 Sep 2026 18:40:39 +0000

Week 1 is done and my resume is live on the internet! 🎉

In my last post I introduced the Cloud Resume Challenge. This time I'm documenting exactly what I did, step by step i.e. the decisions I made, the gotchas I hit, and what I learned along the way.

If you're following along or planning to do the challenge yourself, hopefully this saves you some time.

What was the goal for Week 1?

Build a resume as a static website and get it properly live on AWS. Not just thrown on a free hosting platform properly, with a CDN, HTTPS, and cloud infrastructure. Specifically:

✅ HTML & CSS resume page
✅ Code stored in GitHub
✅ Hosted on AWS S3
✅ CloudFront distribution in front of it
✅ HTTPS via SSL certificate
✅ Resume live and accessible on the internet

Step 1 — Building the Resume in HTML & CSS

I built my resume as a plain HTML page with a separate CSS file. The challenge is about cloud skills, not front-end wizardry, so I kept it clean and professional without overcomplicating it.

The files ended up being:

index.html — the resume content
styles.css — the styling

Once done I pushed both files to a GitHub repository which will be home base for the entire project going forward.

💡 *Tip: * Name your main file index.html from the start S3 static website hosting looks for this file by default when someone hits your URL.

Step 2 — Creating the S3 Bucket

I went to AWS S3 and created a General Purpose bucket in the ap-south-2 (Hyderabad) region and named it priyanka-cloud-resume-challenge.

A few things to note when creating the bucket:

Leave all default settings for now
Block all public access will be ON by default — that's fine, we'll change it shortly
Don't worry about any other settings at this stage

Step 3 — Enabling Static Website Hosting

This is what tells S3 to serve your files as a website rather than just storing them.

Click into your bucket → Properties tab
Scroll down to Static website hosting → click Edit
Select Enable
Set Index document to index.html
Save changes

At this point S3 gives you a bucket website endpoint URL — something like:

http://priyanka-cloud-resume-challenge.s3-website.ap-south-2.amazonaws.com

Hold onto this — you'll use it to test in a moment.

Step 4 — Uploading the Files

Still inside the bucket:

Go to the Objects tab
Click Upload → Add files
Select both index.html and styles.css together
Click Upload

Both files go into the same bucket — simple and clean.

Step 5 — Making the Bucket Public

By default S3 blocks all public access. Since this is a public resume website, we need to open it up.

First — turn off Block Public Access:

Go to Permissions tab
Click Edit on Block public access
Uncheck "Block all public access"
Save → type confirm when prompted

Then — add a Bucket Policy:

Still on Permissions tab → scroll to Bucket policy → Edit
Paste this policy (replace the bucket name with yours):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::priyanka-cloud-resume-challenge/*"
    }
  ]
}

Save changes

Now visit your bucket website endpoint URL — your resume should load! 🎉

Step 6 — Setting Up CloudFront

S3 hosting works but it has limitations — no HTTPS, slower for global visitors, and the URL is ugly. CloudFront fixes all of this — it's AWS's CDN (Content Delivery Network) that sits in front of S3 and serves your content from edge locations worldwide.

Here's how I set it up:

Go to CloudFront in AWS Console → Create Distribution
For Origin, select your S3 bucket
When prompted — choose "Use website endpoint" (important!)
Skip WAF or leave default basic protection
Leave all other settings as default
Click Create Distribution

CloudFront takes about 5-10 minutes to deploy globally. Once the status changes from Deploying to Enabled, you'll see your CloudFront domain name:

https://d1234abcd.cloudfront.net

💡 Why "Use website endpoint"? Because we enabled Static Website Hosting on S3, the website endpoint already knows to serve index.html by default. Using the S3 bucket directly instead can cause routing issues.

Step 7 — Testing HTTPS

This is the satisfying part. Open your CloudFront URL with https://:

https://d1234abcd.cloudfront.net

You should see:

✅ Your resume loading perfectly
✅ A 🔒 padlock in the browser address bar
✅ SSL certificate provided automatically by CloudFront

No extra SSL setup needed — CloudFront handles it automatically!

What about the custom domain?

The challenge officially requires a custom domain name registered
in Route 53. I'm skipping this for now and will add it at the end
once everything else is built.

A few reasons:

All the real learning — Lambda, DynamoDB, CI/CD — happens without needing a domain
I want to complete the full challenge end to end first
I'll add the domain as the final step to officially wrap it up

I'd rather get the full architecture working first and add the
domain at the end. I'll document it when I get there! 😊

What I actually learned this week

S3 is not just file storage — it can host entire websites without a server
Bucket policies control access — understanding the JSON structure matters
CloudFront vs direct S3 — always use CloudFront for production; direct S3 has no HTTPS and is slower
"Use website endpoint" matters — small setting, big difference in behaviour
The cloud resume is a real project — not a tutorial you follow blindly, you actually make decisions

Architecture so far

Browser → (HTTPS) → CloudFront (CDN + SSL + Cache) → S3 Bucket (index.html + styles.css)
             ↑ d1234abc.cloudfront.net        ↑ ap-south-2 (Hyderabad)

Simple but real cloud architecture. Week 2 adds Lambda, DynamoDB and API Gateway on top of this.

What's next?

Before moving to Week 2 I'm spending the rest of this week on some of the optional Mods from the challenge book:

DevOps Mod — setting up GitHub Actions CI/CD to auto-deploy on every push
AI Engineer Mod — adding an LLM resume summarizer using Amazon Bedrock

Each mod will get its own post — stay tuned! 🚀

Resources that helped

Part of my Cloud Resume Challenge series. Read Post 1 here

I'm Taking the Cloud Resume Challenge — Here's What It Is

Priyanka Vuddemari — Mon, 14 Sep 2026 17:08:07 +0000

Hey everyone! 👋

I recently decided to take on the the Cloud Resume Challenge by Forrest Brazeal, and I decided to go for it. I'll be documenting my journey here week by week — the wins, the confusion, and everything in between.

But first, what even is this challenge?

What is the Cloud Resume Challenge?

The Cloud Resume Challenge is a hands-on project designed to help you build and demonstrate real cloud skills. Instead of just reading docs or watching tutorials, you actually build something a resume website and use a whole stack of cloud services to deploy and run it properly.

It was created by Forrest Brazeal, a cloud architect and AWS Community Hero, as a way to bridge the gap between "I passed a certification" and "I can actually build things on AWS."

What does the full challenge involve?

Here's the big picture of what you end up building by the end:

☁️ A resume hosted as a static website on AWS S3
🌍 Served globally via CloudFront (AWS's CDN)
🔒 HTTPS enabled with an SSL certificate
🌐 Accessible via a custom domain registered in Route 53
👀 A visitor counter that tracks how many people view your resume
⚡ The counter powered by AWS Lambda (serverless functions)
🗄️ Visit count stored in DynamoDB (a NoSQL database)
🔗 Everything connected through an API Gateway
🧪 Tests written for your backend code
🏗️ Infrastructure defined as code using AWS SAM
🔄 A CI/CD pipeline so changes deploy automatically

Yeah — it's a lot. But that's the point. You touch almost every layer of a real cloud application.

Why am I doing this?

I was Test Automation Specialist and working as SRE for some time now and looking to level up my cloud skills. I work with CI/CD pipelines and infrastructure daily, so understanding AWS deeply just makes sense for where I want to go.

Also, honestly building something real always beats studying in isolation.

What's Week 1 about:

Week 1 is all about the frontend — building the actual resume HTML page, pushing it to GitHub, hosting it on S3, setting up CloudFront, SSL, and a custom domain.

I'll be posting a full breakdown of what I built and what I learned very soon.

If you're thinking about taking on the challenge too do it don't think about it much

This is Post 1 of my Cloud Resume Challenge series. Follow along for weekly updates!