SAA-C03 Design Cost-Optimized Architectures Practice Question
A static web application uses CloudFront with an S3 origin for assets (JavaScript, CSS, images). After deploying a new frontend build, the CloudFront cache hit ratio dropped significantly because the S3 origin receives many repeated requests for the same assets. The team notices that requests now include the Authorization header in asset requests. Which change is most likely to restore cache efficiency and reduce origin request costs?
⚠ Common exam trap
It's easy for candidates to assume increasing TTL or making the origin public solves caching issues, but the real problem is the cache key variation caused by the Authorization header, which must be explicitly excluded from the cache policy for static content.
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 the CloudFront cache policy so that Authorization is excluded from the cache key for static asset paths.
The drop in cache hit ratio is caused by the Authorization header being included in asset requests, which makes each request unique from CloudFront's perspective, preventing cache reuse. By updating the CloudFront cache policy to exclude the Authorization header from the cache key for static asset paths, CloudFront can treat identical asset requests as cache hits, restoring cache efficiency and reducing 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.
- ✗
Keep the Authorization header but increase the cache TTL to 1 year to reduce revalidation frequency.
Why it's wrong here
If Authorization values differ per user or session and Authorization is included in the cache key, the cache can still be fragmented into many unique cache entries. A larger TTL does not improve the hit ratio caused by cache key variability.
- ✓
Update the CloudFront cache policy so that Authorization is excluded from the cache key for static asset paths.
Why this is correct
When Authorization is part of the cache key, each unique token can create separate cache entries, lowering the cache hit ratio and increasing origin requests. Excluding Authorization from the cache key (and typically from the origin request policy for static assets) allows caching to be based on the URL path/query string, improving hit ratio and reducing S3 origin load.
- ✗
Remove CloudFront and serve assets directly from the S3 website endpoint to reduce CloudFront charges.
Why it's wrong here
Removing CloudFront and pointing clients directly to the S3 website endpoint does not resolve cache fragmentation; it eliminates edge caching entirely, so every request hits the S3 origin and the Authorization header still causes per-user origin fetches. S3 website endpoints also lack native HTTPS support for custom domains and offer no global edge caching, leading to higher latency and potentially higher data transfer costs for distributed users. The correct fix is to adjust the cache policy, not to abandon CloudFront.
- ✗
Switch the S3 origin from private access to public access so CloudFront can cache assets more effectively.
Why it's wrong here
Changing the S3 origin from private to public access does not affect CloudFront's cache key or caching behavior. Cache fragmentation is caused by the cache policy including the Authorization header in the cache key, not by whether the origin is publicly reachable. In fact, making the bucket public weakens security because clients could bypass CloudFront entirely and access S3 directly, losing the protection of Origin Access Control (OAC) while gaining no improvement to cache 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 935-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 →
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.