SAA-C03 Design High-Performing Architectures Practice Question
Your team serves static JavaScript and CSS files from an S3 origin through CloudFront. After a release, the CloudFront cache hit ratio dropped because clients keep re-downloading the same assets. What is the best next change to improve caching performance?
⚠ Common exam trap
Watch out — candidates often think forwarding query strings (Option D) ensures freshness, but it actually fragments the cache and reduces hit ratio, whereas the real solution is to use long-lived Cache-Control headers with versioned filenames to maximize caching.
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
✓
Update origin responses to include long-lived Cache-Control headers (for example, max-age) so CloudFront can cache objects
Setting long-lived Cache-Control headers (e.g., max-age=31536000) on static assets tells CloudFront to cache them at edge locations for an extended period. This reduces the number of requests forwarded to the S3 origin, improving the cache hit ratio and preventing clients from re-downloading unchanged assets on every visit.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Update origin responses to include long-lived Cache-Control headers (for example, max-age) so CloudFront can cache objects
Why this is correct
CloudFront will only reuse cached objects when the origin response is cacheable. Adding/adjusting Cache-Control (and related directives such as public and s-maxage where appropriate) to allow long-lived caching enables edge reuse and increases cache hit ratio.
- ✗
Switch the S3 bucket to S3 Glacier so objects are not frequently accessed
Why it's wrong here
Switching the S3 bucket to S3 Glacier (or Glacier Deep Archive) changes the storage class to an archival tier designed for data that is rarely accessed and can tolerate retrieval delays of minutes to hours. For live static assets served through CloudFront, any cache miss would require CloudFront to fetch the object from Glacier, and archived objects must first be restored (typically via a restore request) before they can be read, which introduces unacceptable latency and potential 403 errors. Moreover, Glacier is not a compatible origin for real-time web traffic; this approach would degrade performance and does nothing to address the underlying missing or short Cache-Control headers that prevent CloudFront from caching the objects in the first place.
- ✗
Disable CloudFront compression to reduce CPU usage at the edge
Why it's wrong here
Disabling CloudFront compression does not affect whether the origin response is cacheable; compression only controls whether the body is transferred using gzip or Brotli to reduce network payload size. Even with compression disabled, CloudFront still evaluates the Cache-Control header from the origin and caches only if that header permits caching. Additionally, CPU usage at the edge is not a meaningful operational concern here—CloudFront handles compression transparently—and disabling it would likely increase bandwidth costs and slow downloads for clients, all without improving cache hit ratio, which is the actual metric the team needs to increase.
- ✗
Set CloudFront to forward all query strings to the origin to ensure the latest assets are returned
Why it's wrong here
Forwarding all query strings to the origin causes CloudFront to treat each unique query string combination as a separate cache key, fragmenting the cache and lowering the hit ratio because the same underlying object is cached multiple times under different URLs. If the S3 origin ignores query strings anyway, this approach simply creates multiple cache entries for identical content, increasing storage and origin requests without ensuring that clients get the latest assets. Properly handling asset updates is done through versioned filenames, cache invalidation, or managed Cache-Control headers—not by forwarding arbitrary query parameters, which does not address the core issue that the origin responses are currently uncacheable.
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
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.