SAA-C03 Design High-Performing Architectures Practice Question
Your team hosts versioned static assets (for example, /static/app-<buildHash>.js). Each build hash never changes, but you release new files on new URLs. To maximize cache hit rate and reduce origin load using CloudFront, what should you do when generating HTTP responses for these assets?
⚠ Common exam trap
It's easy for candidates to confuse 'no-cache' (which still allows caching but forces revalidation) with 'no-store' (which forbids caching entirely), or they assume that `max-age=0` is acceptable for versioned assets, not realizing it forces revalidation and reduces cache efficiency.
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
✓
Set Cache-Control: public, max-age=31536000, immutable for the versioned assets
Setting `Cache-Control: public, max-age=31536000, immutable` tells CloudFront and browsers to cache the versioned asset for one year (31536000 seconds) and never revalidate, since the URL changes with each new build. The `immutable` directive (RFC 8246) signals that the content will never change on that URL, eliminating conditional revalidation requests and maximizing cache hits, which reduces origin load.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set Cache-Control: no-cache so CloudFront always revalidates with the origin
Why it's wrong here
The no-cache directive is frequently misunderstood: it does not tell CloudFront to stop caching, but to store the response and revalidate it with the origin before every use. This means every single request for a versioned asset yields a conditional request to the origin to verify whether the cached copy is still fresh. Because the origin may return a 304 or even a 200 with the full body, the cache hit ratio drops dramatically and origin load rises, defeating the entire purpose of CloudFront for static files. In contrast to immutable, which explicitly tells clients and caches to serve the cached copy without revalidation, no-cache forces the opposite behavior and should be avoided for versioned assets.
When this WOULD be correct
This option would be correct for dynamic content that must always be fresh, such as real-time user-specific data or API responses where you want CloudFront to validate with the origin on each request to ensure the latest version is served.
- ✓
Set Cache-Control: public, max-age=31536000, immutable for the versioned assets
Why this is correct
For content-addressed/versioned URLs, a long max-age lets CloudFront treat the object as fresh for a long period. Adding the immutable directive tells clients not to revalidate while the max-age is still valid, supporting high cache hit rates and fewer origin fetches for repeat requests.
- ✗
Set Cache-Control: max-age=0 and rely on CloudFront to cache by default
Why it's wrong here
Setting max-age=0 marks the object stale immediately, so CloudFront must revalidate against the origin on every request before serving a cached copy. Even though CloudFront retains the object in its cache, each miss triggers a conditional GET (If-None-Match or If-Modified-Since), and the origin typically returns a 304 Not Modified rather than the full payload. This eliminates the benefits of a long-lived edge cache, increases origin requests and latency, and directly contradicts the goal of maximizing cache hit rate for unchanged versioned assets. Relying on 'default caching' does not help because the cache-control directive explicitly disables freshness.
When this WOULD be correct
For dynamic content that changes frequently and must always be fresh (e.g., real-time stock prices), setting max-age=0 ensures CloudFront revalidates with the origin on each request, providing the latest data.
- ✗
Disable CloudFront caching and forward all headers and query strings to the origin
Why it's wrong here
Disabling CloudFront caching and forwarding all headers and query strings to the origin strips the CDN of its core value: serving identical content from edge locations. Forwarding every header and query parameter expands the cache key, so the same versioned asset requested with different cookies, User-Agent values, or tracking parameters becomes hundreds of separate cache entries, causing fragmentation and overwhelming the origin with cache misses. This configuration forces every request to traverse the full network path to the origin, increasing latency, origin bandwidth, and cost. It also prevents any reuse of cached versions, making the static asset delivery slower and more expensive than without a CDN.
When this WOULD be correct
This option would be correct if the question involved dynamic content that must be personalized per user (e.g., based on cookies or authorization headers) and cannot be cached at the edge, requiring every request to go to the origin.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Set Cache-Control: public, max-age=31536000, immutable for the versioned assetsCorrect answer▾
Why this is correct
For content-addressed/versioned URLs, a long max-age lets CloudFront treat the object as fresh for a long period. Adding the immutable directive tells clients not to revalidate while the max-age is still valid, supporting high cache hit rates and fewer origin fetches for repeat requests.
✗Set Cache-Control: no-cache so CloudFront always revalidates with the originWrong answer — click to see why▾
Why this is wrong here
Setting Cache-Control: no-cache forces CloudFront to revalidate with the origin on every request, defeating the purpose of caching versioned static assets that never change. This increases origin load and reduces cache hit rate.
★ When this WOULD be the correct answer
This option would be correct for dynamic content that must always be fresh, such as real-time user-specific data or API responses where you want CloudFront to validate with the origin on each request to ensure the latest version is served.
Why candidates choose this
Candidates may think 'no-cache' is a safe default to avoid serving stale content, not realizing that for immutable versioned assets, it unnecessarily adds revalidation overhead and misses the opportunity to cache aggressively.
✗Set Cache-Control: max-age=0 and rely on CloudFront to cache by defaultWrong answer — click to see why▾
Why this is wrong here
Setting max-age=0 forces CloudFront to revalidate with the origin on every request, defeating the purpose of caching immutable versioned assets and increasing origin load.
★ When this WOULD be the correct answer
For dynamic content that changes frequently and must always be fresh (e.g., real-time stock prices), setting max-age=0 ensures CloudFront revalidates with the origin on each request, providing the latest data.
Why candidates choose this
Candidates may mistakenly believe that CloudFront automatically caches responses with max-age=0, or they confuse 'no-cache' behavior with 'max-age=0', thinking it still allows caching.
✗Disable CloudFront caching and forward all headers and query strings to the originWrong answer — click to see why▾
Why this is wrong here
Disabling CloudFront caching and forwarding all headers and query strings defeats the purpose of using a CDN for static assets, increasing origin load and reducing performance. Versioned assets with immutable hashes should be cached aggressively.
★ When this WOULD be the correct answer
This option would be correct if the question involved dynamic content that must be personalized per user (e.g., based on cookies or authorization headers) and cannot be cached at the edge, requiring every request to go to the origin.
Why candidates choose this
Candidates may think that forwarding all headers and query strings ensures freshness and correctness, not realizing that for versioned static assets, caching is safe and beneficial.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
About these practice questions
Courseiva writes every SAA-C03 question from scratch — 935 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.