SAA-C03 Design High-Performing Architectures Practice Question
Exhibit
CloudFront behavior summary for path pattern /static/*: - Allowed methods: GET, HEAD - Cache policy: forwards all query strings - Origin request policy: forwards all cookies and the Authorization header - Average cache hit ratio: 11% Sample request log lines: GET /static/app.js?v=18&userId=123 Cookie: session=abcd GET /static/app.js?v=18&userId=987 Cookie: session=xyzt GET /static/logo.svg?v=18&locale=en Cookie: session=mnop Origin responses: - All objects are identical for every viewer - Objects are versioned only by the v query parameter
Based on the exhibit, which change will most improve the CloudFront cache hit ratio for the static assets while still serving the same files to all users?
⚠ Common exam trap
Candidates often assume increasing TTL or enabling Origin Shield will fix a low cache hit ratio, when the real issue is an overly broad cache key caused by forwarding all query strings and cookies.
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
✓
Create a custom cache policy that includes only the v query string and excludes cookies.
The CloudFront cache hit ratio for static assets is reduced when query strings and cookies are forwarded to the origin, because each unique combination creates a separate cache entry. By creating a custom cache policy that includes only the 'v' query string (used for versioning) and excludes cookies, CloudFront can cache a single object for all users regardless of other query parameters or cookie values, maximizing cache hits while still serving the same file.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create a custom cache policy that includes only the v query string and excludes cookies.
Why this is correct
This removes unnecessary cache-key fragmentation. Since all users receive identical static files, forwarding user-specific cookies and irrelevant query strings destroys cache reuse. Keeping only the version parameter preserves correct object variation while allowing many more requests to hit the same cached object at the edge.
- ✗
Enable Origin Shield and keep the current cache behavior unchanged.
Why it's wrong here
Enabling Origin Shield adds an intermediate cache layer that aggregates viewer requests from all edge locations before they reach the origin, which can reduce origin load after a cache miss. However, Origin Shield still uses the same CloudFront cache key that you define; if the cache key includes all cookies and query strings, each combination is cached separately just as it is at the edge. Because the cache key is still fragmented by irrelevant data, Origin Shield does nothing to increase the cache hit ratio—it merely preserves the same inefficient entries. To improve performance, you must change the cache key itself, not just add another storage tier.
- ✗
Move the static assets to individual presigned URLs for each viewer.
Why it's wrong here
Presigned URLs are a mechanism for granting time-limited access to private objects, typically by embedding credentials or signed query parameters in the URL. For static assets that are identical for every viewer, using per-viewer presigned URLs adds a unique signature or access token to each request, which becomes part of the cache key and forces CloudFront to cache the same object separately for each viewer. This not only destroys cache reuse but also increases origin traffic, as nearly every request results in a miss. Presigned URLs solve an access-control problem, not a caching problem, and applying them to public, identical content directly contradicts the goal of maximizing CloudFront's edge cache efficiency.
- ✗
Increase the CloudFront default TTL to 24 hours while continuing to forward all cookies and query strings.
Why it's wrong here
The default TTL determines how long an object remains in CloudFront's cache before CloudFront checks with the origin; it has no influence on how the cache key is constructed. If you continue to forward all cookies and all query strings, every distinct combination of those values creates its own object in the cache—so even a 24-hour TTL only makes each of those many fragments live longer, rather than consolidating them. Cache misses still occur for each unique viewer-specific variation, keeping the hit ratio low and forcing the origin to serve far more requests than necessary. A longer TTL is useful only after you have already reduced cache-key fragmentation, e.g., by whitelisting only the v query string and excluding cookies, which is the actual root cause.
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.