SAA-C03 Design High-Performing Architectures Practice Question
A team serves static assets from an S3 origin through CloudFront. Cache hit ratio is low. Analytics show that requests include an Authorization header (even though the assets are public) and the cache key currently varies on that header, causing CloudFront to treat the same asset as different cache entries. What is the best change to improve cache hit ratio without breaking access controls?
⚠ Common exam trap
It's easy for candidates to think increasing TTL or changing the origin type will fix caching, when the real issue is the cache key composition—specifically, the Authorization header fragmenting the cache.
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
✓
Modify the CloudFront cache policy so the cache key does not include the Authorization header.
The low cache hit ratio is caused by the Authorization header being included in the CloudFront cache key, which creates separate cache entries for the same object even though the assets are public. By modifying the cache policy to exclude the Authorization header, CloudFront will treat all requests for the same asset as identical, dramatically improving the cache hit ratio without affecting access controls because the assets are already public.
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 Authorization in the CloudFront cache key, but increase the origin response minimum TTL to 1 day.
Why it's wrong here
A longer TTL can reduce some re-fetches, but varying the cache key by Authorization still creates separate cache entries for different Authorization values. That fragmentation remains the primary driver of a low hit ratio, and time-to-live settings do not change cache-key uniqueness.
- ✓
Modify the CloudFront cache policy so the cache key does not include the Authorization header.
Why this is correct
CloudFront cache hit ratio depends on what constitutes a unique cache key. If Authorization is included, identical public assets requested with different Authorization values will map to different cache objects and reduce reuse. Removing Authorization from the cache key makes those requests share the same edge cache entry, improving hit ratio and reducing origin traffic. Because the scenario states the assets are public, removing Authorization from the cache key does not break access controls (access is not controlled by Authorization at the origin).
- ✗
Switch the S3 origin from the current bucket to a website endpoint to enable automatic caching headers.
Why it's wrong here
Changing the origin type (REST endpoint vs website endpoint) does not remove cache-key variation caused by the Authorization header. CloudFront cache-key behavior is controlled by CloudFront cache policy/origin request policy, not by the origin endpoint type. This change also can introduce additional differences in behavior and error handling.
- ✗
Enable CloudFront to forward all headers to S3 so origin can decide caching behavior per request.
Why it's wrong here
Forwarding all headers typically reduces caching effectiveness because many header values vary per request, leading to more unique combinations and more cache misses. In this scenario, the key issue is cache-key configuration that includes Authorization; forwarding headers does not fix the underlying cache fragmentation and can make cache reuse worse.
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 — 302 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.