SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company uses Amazon CloudFront with an S3 origin to serve static content. They recently updated the content in S3, but users still see the old files. What is the MOST likely reason?

⚠ Common exam trap

SAP-C02 often tests whether candidates incorrectly blame S3 versioning or missing header forwarding for stale CloudFront content, when the root cause is usually the cache TTL or lack of invalidation.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The CloudFront distribution's cache TTL is too long

CloudFront caches objects at edge locations based on the cache TTL. If the TTL is set to a long duration, CloudFront continues to serve the cached old version even after the S3 origin is updated. The most likely reason users see old files is that the cached objects have not expired. To resolve, you can invalidate the objects or use versioned filenames.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
The CloudFront distribution's cache TTL is too long
Why this is correct
CloudFront serves objects from edge locations until the cached object's TTL expires, so an excessively long TTL means updated S3 content is not fetched. This satisfies the stem's scenario: users still receive stale files despite the origin being refreshed.
✗
S3 versioning is enabled and the objects are not updated
Why it's wrong here
S3 versioning preserves prior object versions but does not prevent CloudFront from serving a cached copy; overwriting an object still changes the current version. Versioning is the correct choice when you need to retain or restore previous object states, not when diagnosing stale edge content.
✗
CloudFront is not configured to forward the Cache-Control header
Why it's wrong here
Cache-Control is a response header from the origin; forwarding it as a request header does not refresh already-cached objects at edge locations. Forwarding headers is configured for dynamic, per-request content, so this would be the right lever only when origin responses vary by client-supplied header values.
✗
S3 Transfer Acceleration is disabled
Why it's wrong here
Transfer Acceleration speeds uploads to S3 over long distances; it has no bearing on what CloudFront serves or how long edge caches retain objects. It is tempting because it also sits between clients and S3, but it addresses upload throughput, not cache invalidation or expiry of stale edge copies.

Visual reference

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question