How to Improve CloudFront Cache Hit Ratio for Versioned Static Assets
Exhibit
CloudFront distribution settings excerpt: - Cache policy: custom - Headers included in cache key: Authorization, CloudFront-Viewer-Country - Query strings included in cache key: all - Cookies included in cache key: none Origin request sample: GET /app.8f3a2c1.js?v=20260428 HTTP/1.1 Host: d123.cloudfront.net Authorization: Bearer eyJhbGciOi... User-Agent: Mozilla/5.0 CloudFront analytics: - CacheHitRate: 18% - OriginFetches: spike immediately after each deploy - Origin bytes out: high for unchanged JS and CSS files
Based on the exhibit, a static asset distribution site uses Amazon CloudFront with an S3 origin. The assets are versioned by filename, but the cache hit ratio remains low after each release. Which CloudFront change is the best way to improve cache reuse without changing the origin objects?
Quick Answer
The correct answer is to remove Authorization and unnecessary query strings from the CloudFront cache key. This works because CloudFront uses the cache key—a combination of the request’s host, path, and specified headers, cookies, or query strings—to determine whether a request can be served from the edge cache. By stripping out Authorization headers and irrelevant query parameters, you ensure that all users requesting the same versioned static asset, such as style.v2.css, share a single cached object, dramatically improving the cache hit ratio without altering the origin objects. On the SAA-C03 exam, this scenario tests your understanding of CloudFront cache key customization, often appearing as a trap where candidates mistakenly try to shorten TTLs or change origin behavior. A common memory tip: think of the cache key as a locker combination—only include the numbers that matter, or everyone gets a different locker.
⚠ Common exam trap
It's easy for candidates to think increasing storage class or switching to an ALB improves caching, but the real issue is the cache key composition—specifically, unnecessary headers or query strings fragmenting the cache—which is solved by adjusting the CloudFront cache key settings.
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
✓
Remove Authorization and unnecessary query strings from the CloudFront cache key.
Removing Authorization headers and unnecessary query strings from the CloudFront cache key ensures that multiple requests for the same versioned asset (e.g., style.v2.css) share a single cached object, regardless of user-specific headers or irrelevant query parameters. This directly increases the cache hit ratio without modifying the origin objects, as CloudFront will serve the same cached response for identical cache keys.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Keep the current cache key and increase the S3 bucket's storage class.
Why it's wrong here
Changing S3 storage class does not improve CloudFront cache reuse. The problem is that the cache key is too granular and prevents reuse across requests.
- ✓
Remove Authorization and unnecessary query strings from the CloudFront cache key.
Why this is correct
Versioned static assets do not need Authorization in the cache key, and arbitrary query strings can destroy cache efficiency. Excluding those fields lets CloudFront reuse the same cached object across many viewers.
- ✗
Disable the CloudFront cache so every request is served directly from S3.
Why it's wrong here
Disabling caching guarantees more origin traffic and worse performance. It would make the origin fetch problem much worse instead of improving cache reuse.
- ✗
Switch the origin from Amazon S3 to an Application Load Balancer.
Why it's wrong here
An ALB origin is not appropriate for static versioned asset delivery. It adds cost and complexity without addressing the cache-key design issue that is hurting hit ratio.
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
This SAA-C03 question is part of Courseiva's 302-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on SAA-C03
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A media company serves versioned JavaScript and CSS files from an Amazon S3 origin through CloudFront. After each release, origin requests spike even though the files are public. Browser requests include a tracking cookie, an Authorization header, and a cache-busting query string that the site no longer needs. Which three changes will most improve the CloudFront cache hit ratio without exposing private content? Select three.
hard- ✓ A.Rename each static asset with a content hash or release version in the filename before publishing.
- ✓ B.Create a CloudFront cache policy that excludes unnecessary query strings and cookies from the cache key.
- ✓ C.Use an origin request policy that forwards only the headers and cookies the origin truly needs.
- D.Enable CloudFront compression and configure the origin to return Cache-Control: no-store for all files.
- E.Forward all viewer headers to the origin so CloudFront can personalize every request.
Why A: Renaming static assets with a content hash or version in the filename ensures that each new release creates a unique object key in S3. This allows CloudFront to treat the new file as a distinct object, avoiding cache invalidation issues and enabling long-term caching of the old version. Without this, even with cache-busting query strings, CloudFront might still serve stale content or require frequent invalidations, reducing the cache hit ratio.
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.