CloudFront Caching and Invalidation for Static Sites

SAA-C03 By islever Editorial Last updated

Determine high-performing and/or scalable network architectures.

Short answer

AE Set the CloudFront default TTL to 2 minutes and add a Cache-Control max-age directive of 24 hours to S3 objects, using CloudFront invalidation on deployment to clear edge caches.

Question

A company is hosting a high-traffic static website on Amazon S3 with an Amazon CloudFront distribution that has a default TTL of 0 seconds. The company wants to implement caching to improve performance for the website. However, the company also wants to ensure that stale content is not served for more than a few minutes after a deployment. Which combination of caching methods should a solutions architect implement to meet these requirements? (Choose two.)
  1. Set the CloudFront default TTL to 2 minutes. Correct Answer
  2. Set a default TTL of 2 minutes on the S3 bucket.
  3. Add a Cache-Control private directive to the objects in Amazon S3.
  4. Create an AWS Lambda@Edge function to add an Expires header to HTTP responses. Configure the function to run on viewer response.
  5. Add a Cache-Control max-age directive of 24 hours to the objects in Amazon S3. On deployment, create a CloudFront invalidation to clear any changed files from edge caches. Correct Answer

Key Takeaways

The core concept tested is the interaction between CloudFront's Default TTL settings and origin Cache-Control headers, specifically how to override browser caching while maintaining CDN efficiency.

This question addresses configuring Amazon CloudFront caching behavior for a static website hosted on S3 to balance performance with content freshness. It establishes that combining a short Default TTL with manual invalidation is a valid strategy to ensure stale content is not served longer than required.

Common mistake: Many learners incorrectly select Option C (Cache-Control private) because they misunderstand it as a way to prevent CDN caching; in reality, 'private' only restricts shared caches like CDNs from caching if no other directives exist, but here it conflicts with the goal of improving performance via caching.

Expert Analysis

Why the Answer Is Correct

The correct combination is A and E. Option A sets the CloudFront Default TTL to 2 minutes, which ensures that CloudFront edge locations cache the content for a very short period, satisfying the requirement that stale content is not served for more than a few minutes after deployment. Option E adds a Cache-Control max-age directive of 24 hours to the S3 objects. While this instructs browsers to cache for 24 hours, the critical part is "On deployment, create a CloudFront invalidation." This allows the CDN to serve fresh content immediately after deployment by clearing the cached versions at the edge, while still allowing end-users' browsers to benefit from longer caching. The question asks for a combination of methods; using both ensures CDN freshness via invalidation and allows for a defined caching strategy.

Why the Other Options Are Wrong

Option B is incorrect because S3 buckets do not have a native TTL setting; caching is controlled by HTTP headers or CloudFront configurations. Option C is incorrect because the Cache-Control private directive indicates that the response is intended for a single user and should not be stored by shared caches (like CloudFront). Using this would disable CloudFront caching entirely, defeating the purpose of improving performance. Option D involves a Lambda@Edge function adding an Expires header. While technically possible, it is overly complex and not the standard architectural pattern for simple static site caching requirements compared to TTL and invalidation. Furthermore, relying solely on Expires without invalidation might not guarantee the "few minutes" constraint post-deployment as reliably as explicit invalidation.

Community Comment Notes

Community discussion highlights a common confusion regarding the interaction between CloudFront TTL and Origin Cache-Control headers. As user MatAlves noted, there is a misconception that you cannot combine these approaches due to header precedence rules. However, the key insight provided by users like ug56c and Cpso is that CloudFront's Minimum/Default TTL can override origin headers for the CDN cache itself. Specifically, if the Minimum TTL is set higher than the origin's max-age, CloudFront respects its own settings for the edge cache. The invalidation in Option E handles the deployment freshness, while the 24-hour max-age in Option E helps with browser-side caching, which is distinct from CloudFront edge caching. The debate often centers on whether "stale content" refers to what the user sees (browser cache) or what the CDN serves. Since the question emphasizes the website experience and deployment frequency, the combination of short CDN TTL + Invalidation is the most robust solution for ensuring global consistency quickly.

Official Reference

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

When dealing with CloudFront caching questions, always distinguish between what CloudFront caches (edge locations) and what the browser caches. If the requirement involves rapid content updates post-deployment, look for options involving Invalidations or Object Versions. Avoid options that completely disable caching (like 'no-store' or 'private' without context) if performance improvement is a stated goal.

Frequently Asked Questions

Why isn't Cache-Control private used for caching?

Cache-Control private tells shared caches like CloudFront NOT to cache the object. Since the goal is to improve performance via caching, this option would defeat the purpose.

Does CloudFront ignore S3 Cache-Control headers?

Not entirely. CloudFront uses origin headers unless overridden by Cache Policy settings like Default TTL or Minimum TTL. Invalidation bypasses TTL logic entirely.

More SAA-C03 FAQ →

Community Votes

AE
54%
AC
46%

54% of anonymous learners picked answer AE. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 18 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 18

  1. BBR01 👍 8
    AE. By default, each file automatically expires after 24 hours, but you can change the default behavior in two ways: 1. To change the cache duration for all files that match the same path pattern, you can change the CloudFront settings for Minimum TTL, Maximum TTL, and Default TTL for a cache behavior. 2. To change the cache duration for an individual file, you can configure your origin to add a Cache-Control header with the max-age or s-maxage directive, or an Expires header to the file. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html#expiration-individual-objects
  2. MatAlves 👍 7
    You simply can't have A and E in the same approach: "Default TTL applies only when your origin does not add HTTP headers such as Cache-Control max-age, Cache-Control s-maxage, or Expires to objects." C - Cache-Control private directive specifies that the response is intended for a single user and should not be cached by shared caches - it can still be cached, but only on a client device. This combination of steps would provide the best solution for the case. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesDefaultTTL
  3. ug56c 👍 5
    If your minimum TTL is greater than 0, CloudFront uses the cache policy’s minimum TTL, even if the Cache-Control: no-cache, no-store, and/or private directives are present in the origin headers. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
  4. Scheldon 👍 4
    Answer (AC) Per table on URL https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html#expiration-individual-objects answer E is incorrect because if we will change cache-control max-age to 24h it will means that customer browser will cache web for 24h and customer want to be sure that it will be not longer then few min. Expires header (answer D) from my understanding can be used only on full folder of web not as lambda function which will reply to customer reqeusts. We are setting Default TTL for CloudFront (answer A) not on S3 (answer B) and it will say CloudFront to cache web for 2min.
  5. xBUGx 👍 4
    Add a Cache-Control Private Directive to Objects in Amazon S3 (Option C): By setting the Cache-Control header to private for objects in the S3 bucket, you control caching behavior. The private directive indicates that the content is intended for a single user and should not be cached by intermediate proxies or CDNs. This helps prevent stale content from being served to multiple users. Additionally, consider using other Cache-Control directives (e.g., max-age, no-cache, no-store) as needed.
Show 13 more comments
  1. Nm55569 👍 4
    "However, the company also wants to ensure that stale content is not served for more than a few minutes after a deployment." After a deployment
  2. 1ba9aa0 👍 3
    A-C, Because A-E is not possible following this link: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesDefaultTTL "Default TTL applies only when your origin does not add HTTP headers such as Cache-Control max-age, Cache-Control s-maxage, or Expires to objects."
  3. EdricHoang 👍 3
    If the content still keep client's cache in 24h, its wrong (answer E)
  4. LeonSauveterre 👍 2
    A - Setting the default TTL to 2 minutes allows CloudFront to cache content for a short period. B - TTL is not a concept applied directly to S3 buckets. TTL and caching behaviors are managed through Cache-Control headers and CloudFront settings. C - The private directive lets caching occur locally only, not in shared caches like CloudFront. D - Ensures content is served fresh by tightly controlling cache expiration, not even "a few minutes". E - Using a long Cache-Control max-age directive improves performance, while targeted CloudFront invalidations ensure that updated content is served immediately after deployment. This is common practice.
  5. Cpso 👍 2
    browser will always get cache-control value set by S3 not cloudfront. cloudfront will use parameter ttl override the cache-control header for decision time to cache on cloudfront. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html?utm_source=chatgpt.com#ExpirationDownloadDist
  6. Linuslin 👍 2
    https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html#expiration-individual-objects https://stackoverflow.com/questions/43343759/confused-with-minimum-maximum-and-default-ttl-in-cloudfront
  7. Cpso 👍 2
    A - make browser to cache 2 minutes. after 2 minute browser will ask cloudfront E: cloudfront would not ask S3 for 24hour . invalidation will clearing this cacheing. so A+E is most effective.
  8. robotgeek 👍 1 Answered A
    This question has gaps: B) Can not be done in relation to S3 catching, this is a CloudFront specific configuration C) Question does not make any comment in the sense of "private" objects... any asumption in that sense is your personal oppinion, not the question stating it D) Collisions with A, why would you do something like that programatically? E) Can not be because why would you put 24h when it is not requested, also why would you invalidate a deployment that is already TTL=0, everything is up to date in the caches with that config
  9. JA2018 👍 1
    #A - Set the CloudFront default TTL to 2 minutes: This directly controls how long content is cached at the CloudFront edge locations, allowing for a short caching window to meet the requirement of not serving stale content for more than a few minutes. #D - Create a Lambda@Edge function to add an Expires header: By using a Lambda@Edge function triggered on the "viewer response", you can dynamically set an Expires header with a precise expiration time on each request, ensuring fine-grained control over caching behavior.
  10. tch 👍 1
    Controlling how long Amazon S3 content is cached by Amazon CloudFront https://docs.aws.amazon.com/whitepapers/latest/build-static-websites-aws/controlling-how-long-amazon-s3-content-is-cached-by-amazon-cloudfront.html
  11. kelmryan1 👍 1
    Answer is AE , C would only be on the user browser and would not cache to the cloud front and would be useless
  12. Salilgen 👍 1
    https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html#ExpirationDownloadDist
  13. 02ffe1c 👍 1
    Since it don’t want to cache more than a minute, A cannot be an answer

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

S3 Multi-Region Access Point and Replication Strategy

S-grade

Securing NLB with Security Groups for Minimal Change

S-grade

Most Cost-Effective 7-Year Retention for EBS Snapshots?

S-grade

AWS Forecast vs SageMaker for Time-Series Prediction

S-grade

Practice All SAA-C03 Questions

Access 120 questions with complete answers and detailed explanations.

View Full SAA-C03 Practice Test →

← Back to SAA-C03 Study Guide