SAA-C03 Design High-Performing Architectures Practice Question
A marketing team uses CloudFront with an S3 origin to serve a single-page web app. After a release, CloudFront cache hit ratio dropped sharply. The app requests the same static JS and CSS assets, but each request includes a unique tracking query parameter (for example, ?utm_source=campaign123, campaign456, etc.). You want CloudFront to cache those assets efficiently even when the tracking query parameter changes. What should you do?
⚠ Common exam trap
Many candidates think forwarding all query parameters (Option A) is necessary for dynamic content, but for static assets with irrelevant tracking parameters, ignoring them is the correct approach to maximize cache hits.
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 the cache key ignores the tracking query parameter, while still using the path and other essential headers.
CloudFront's cache key determines whether a request is served from the cache or forwarded to the origin. By configuring a cache policy that ignores the tracking query parameter (e.g., utm_source), CloudFront treats all requests for the same asset path as identical, regardless of the unique tracking parameter. This allows the same JS and CSS files to be cached once and served for all campaign variations, restoring the cache hit ratio.
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 cache policy that forwards the query string to the origin and varies the cache key by all query parameters.
Why it's wrong here
If the cache key varies by all query parameters, then every unique tracking value produces a different cache key. That creates cache fragmentation (many near-duplicate objects), which lowers the cache hit ratio and increases origin requests—directly opposing the goal.
- ✓
Update the CloudFront cache policy so the cache key ignores the tracking query parameter, while still using the path and other essential headers.
Why this is correct
CloudFront caching depends on the cache key (for example, path, selected headers, and selected query strings). If you configure a cache policy to exclude the tracking query parameter (or ignore specific query string parameters), CloudFront treats requests for the same asset as the same cached object. This prevents cache fragmentation caused by unique tracking values. Origin load decreases and cache hit ratio increases, while correctness is maintained because the excluded parameter does not affect the content of the static JS/CSS objects.
- ✗
Enable S3 origin access control and keep the existing default cache policy, because origin access changes caching behavior automatically.
Why it's wrong here
S3 origin access control restricts how CloudFront can access the S3 bucket (security/authorization). It does not change how CloudFront constructs the cache key. If the existing cache policy forwards or varies on the tracking query string, the hit ratio will still drop.
- ✗
Set the CloudFront Time-to-Live (TTL) to 0 seconds to ensure the origin always serves the latest asset content.
Why it's wrong here
TTL of 0 effectively disables caching for the objects, causing cache misses for most requests. That increases origin traffic and usually worsens both performance and cost. The problem here is cache key fragmentation, not stale content.
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.