Lesson 4 of 30

AWS Basics for Frontend Developers

Q: You deploy a new version of your frontend to S3 + CloudFront, but users report they still see the old version. What's the most likely cause, and what's the fix?

A strong answer covers: CloudFront caches content at edge locations; A fresh S3 upload doesn't automatically update what CloudFront is already serving until the cache expires or is invalidated; Fix: invalidate the CloudFront cache on deploy, and/or use content-hashed filenames so a new build is an entirely new URL.

Q: What does it mean that a Lambda function is 'stateless', and what bug does a developer coming from a traditional always-on server background often run into because of it?

A strong answer covers: Each invocation may run in a fresh, or a reused-but-not-guaranteed, execution environment; You can't reliably depend on an in-memory variable persisting between invocations, the way a long-running server process could; Common bug: caching something in a module-level variable that works on a warm start and silently fails on a cold one.

Not a certification — just the handful of AWS services a frontend developer actually runs into, and the caching/statelessness gotchas that trip people up.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

Why do built frontend assets typically get a content-derived hash in their filename, like main.a3f8c1.js instead of main.js?

It makes aggressive CDN caching safe — a content change always produces a new URL nothing has cached yetIt's required by S3 to prevent duplicate filenamesIt makes the JavaScript execute faster in the browser

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on AWS Basics for Frontend Developers

What interviewers actually ask about this, and what a strong answer has to cover.

You deploy a new version of your frontend to S3 + CloudFront, but users report they still see the old version. What's the most likely cause, and what's the fix?

A strong answer covers

CloudFront caches content at edge locations
A fresh S3 upload doesn't automatically update what CloudFront is already serving until the cache expires or is invalidated
Fix: invalidate the CloudFront cache on deploy, and/or use content-hashed filenames so a new build is an entirely new URL

Likely follow-ups

Why do most build tools output filenames like main.a3f8c1.js instead of just main.js?
What's the actual difference between S3 and a database — could you store your app's user records directly in S3?

What does it mean that a Lambda function is 'stateless', and what bug does a developer coming from a traditional always-on server background often run into because of it?

A strong answer covers

Each invocation may run in a fresh, or a reused-but-not-guaranteed, execution environment
You can't reliably depend on an in-memory variable persisting between invocations, the way a long-running server process could

The plain-language idea

A frontend developer doesn't need to be an AWS expert, but a handful of services come up constantly once an app is actually deployed:

S3 — object storage. Holds files (your built JS/CSS/HTML, images, uploads). Not a database, not compute.
CloudFront — a CDN. Caches your content at edge locations physically close to users, so a visitor in Mumbai isn't fetching every asset from a server in Virginia.
Route 53 — DNS. Points your domain name at the right place.
Lambda — serverless functions. Code that runs on demand, without you managing a server — "serverless" means you don't manage the server, not that there isn't one.
API Gateway — puts an HTTP endpoint in front of a Lambda function, so your frontend can call it like any other API.

See it in a real thing: deploying a React app

pnpm build produces static files — index.html, main.a3f8c1.js, styles.9b2e.css.
Those files upload to an S3 bucket.
CloudFront sits in front of the bucket, caching and serving those files from edge locations worldwide.
Route 53 points yourapp.com at the CloudFront distribution.

S3, EC2, Lambda: three different levels of hands-offStep 1 of 3

S3: stores files (static assets, uploads) — a bucket, not a server.

What people usually miss

Watch out

A fresh deploy doesn't mean users see it immediately. CloudFront caches at the edge; uploading a new file to S3 doesn't retroactively update what's already cached until it expires or you explicitly invalidate it. This is exactly why content-hashed filenames matter for correctness, not just performance — an un-hashed main.js could serve a stale cached version indefinitely.
S3 is not a database. It stores files (objects), not queryable structured data — don't reach for it to store user records or anything you need to query by field.
Lambda functions are stateless between invocations. You can't reliably rely on an in-memory variable persisting from one call to the next — a common bug is caching something in a module-level variable that "works" on a warm invocation and silently fails on a cold one.
A "cold start" is a real, noticeable delay. The first invocation after a Lambda has been idle has to spin up a fresh execution environment before running your code — subsequent (warm) invocations are fast; the first one after idle time isn't.

Why this matters in interviews

Frontend developers increasingly touch deployment, and "why isn't my change showing up" (caching) or "why did my API call time out" (cold starts) are real, common questions — even without owning the infrastructure, being fluent in this vocabulary is what separates "I can deploy an app" from "I understand what happens when I do."