Purging Stale CloudFront Cache After S3 Content Updates
Short answer
D Run a CloudFront invalidation for the updated objects so edge caches purge the stale copies and fetch the new content from the S3 origin.
Question
The company updates some content for the website. After the update, users report that they are encountering the previous version of the content.
The company must ensure that website users receive only the most current content.
Which solution will meet this requirement?
Key Takeaways
It tests that CloudFront edge caches serve objects for the full cache TTL, and only an invalidation (or a changed cache key/object name) forces a fresh origin fetch — the trap is confusing S3 versioning or ACLs with cache freshness.
This CloudFront caching question tests how to remove stale objects from edge locations after an S3 origin update; the correct remedy is a CloudFront invalidation, option D.
Common mistake: Option B is the tempting wrong answer: versioning the S3 bucket stores historical object versions for recovery, but CloudFront does not purge its edge caches when versioning is enabled, so users would still see the cached previous content.
Expert Analysis
The governing principle is that CloudFront edge caches serve objects for the full duration of their cache TTL, regardless of what changes at the origin. The Amazon CloudFront operating model states that invalidating an object removes it from CloudFront edge caches before its time-to-live expires, so the next viewer request is fetched from the Amazon S3 origin instead of served from cache. This is exactly the documented remedy for stale content after an update.
Applying it to the scenario, the static website is fronted by CloudFront with the S3 bucket as origin and has global users. When the company replaced content in S3, the edge locations still held the old copies, which is why users worldwide continued to see the previous version. Option D addresses this directly: running an invalidation (for example for the changed paths or /*) purges those cached copies and forces a fresh origin fetch, guaranteeing that users receive only the current content.
Why the other options fail: Option A (S3 ACLs) controls object permissions, not cache freshness, and is anyway the wrong tool for a CloudFront origin that should be accessed with bucket policies and origin access control. Option B (versioning on the S3 bucket) keeps historical object versions for recovery, but CloudFront does not automatically invalidate its caches when versioning is enabled, so the stale copies at the edge remain. Option C reflects a misunderstanding: CloudFront edge locations are distributed globally and are not tied to any single Availability Zone, and placing objects in a particular Availability Zone has no bearing on cache invalidation. If the requirement were forward-looking rather than remedial, adding short TTLs or cache-control headers with an origin cache policy could reduce staleness, but for immediately removing already-cached content, invalidation is the correct solution.
Official Reference
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html
This link opens the official vendor documentation in a new tab.
Exam Strategy
When a question reports stale or outdated content behind a CDN, immediately look for cache-control keywords: TTL, cache, invalidation, edge locations. Eliminate options that address permissions (ACLs), durability (versioning), or placement (Availability Zone), since none change what is cached. Then choose the option that explicitly removes or bypasses the cached copy, such as an invalidation or a changed object name/cache key.
Frequently Asked Questions
Why do CloudFront users still see old content after I update the S3 origin?
How does a CloudFront invalidation make users get the latest content?
Does enabling S3 versioning or using S3 ACLs fix stale CloudFront content?
Discussion 1 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 1
-
testerhelper 👍 1 Answered DAn AWS CloudFront invalidation removes cached files from edge locations before their time-to-live (TTL) expires, forcing CloudFront to fetch fresh content from your origin server on the next request
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All SOA-C03 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SOA-C03 Practice Test →