SAA-C03 Design High-Performing Architectures Practice Question
A team serves image files from S3 through CloudFront. During a performance review, they notice that CloudFront cache hit ratio is low and the S3 origin receives many repeated requests for the same images. Request URLs include a volatile query parameter called 'sessionId' that changes for each user, but the image content is identical regardless of 'sessionId'. What configuration change will most effectively increase cache hit ratio?
⚠ Common exam trap
Watch out — candidates often confuse the purpose of cache policies (which control the cache key) with origin request policies (which control what is forwarded to the origin), leading them to incorrectly choose Option B thinking that forwarding query strings will fix the issue, when in fact it does not affect the cache key.
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 'sessionId' is not included in the cache key (and only stable query parameters are used).
The low cache hit ratio is caused by the volatile 'sessionId' query parameter being included in the CloudFront cache key, which creates a unique cache entry for every user request even though the image content is identical. By updating the cache policy to exclude 'sessionId' from the cache key, CloudFront will treat all requests for the same image as the same cached object, dramatically increasing the cache hit ratio and reducing load on the S3 origin.
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 the CloudFront cache policy so that 'sessionId' is not included in the cache key (and only stable query parameters are used).
Why this is correct
Including sessionId in the cache key means CloudFront treats each session's request as a distinct object, so identical images requested with different sessionId values create separate cache entries and miss the cache. A cache policy that excludes volatile parameters like sessionId (while still allowing stable ones that affect the image) collapses those requests to a single cache key, letting edge locations serve the same object to many sessions. This directly increases the cache hit ratio without requiring any change to origin behavior, because the underlying image content has not actually changed.
- ✗
Enable origin request policy to forward all query strings to S3 so responses are always correct for every sessionId.
Why it's wrong here
An origin request policy controls what is forwarded to S3, but it does not automatically determine the cache key unless the cache policy also includes those values. Simply forwarding all query strings—including sessionId—to the origin fragments the cache when the cache policy is left at the default (which includes all query parameters), causing poor hit ratios and extra S3 calls. Even if you decouple the origin request policy from the cache policy, sending every sessionId is unnecessary for static images and does nothing to fix the underlying cache pollution; the right fix is to exclude sessionId from the cache key.
- ✗
Set the CloudFront minimum TTL to 0 seconds so cached objects expire quickly and fetch fresh content more often.
Why it's wrong here
Minimum TTL of 0 tells CloudFront it may expire objects immediately, so even popular images are force-revalidated or refetched from S3 on every new request or at best after a very short time. Cache hit ratio drops because objects spend minimal time at the edge, and the origin sees an increased number of GETs. TTL tuning addresses freshness, not cache-key fragmentation; the real problem here is volatile query parameters, not stale content.
- ✗
Disable caching by using CloudFront managed caching disabled so that every request validates with the origin.
Why it's wrong here
Using the managed 'CachingDisabled' policy (or equivalent) makes CloudFront bypass caching entirely and forward every request to S3 for validation or retrieval. This guarantees the origin receives each request, which is the exact opposite of the goal to raise the hit ratio; it also increases latency and S3 costs. The issue is not that caching is unsafe for these static images, only that the cache key is too granular.
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.