SAA-C03 Design Cost-Optimized Architectures Practice Question
A company serves versioned images from S3 through CloudFront. After a release, CloudFront origin fetches increased sharply and the monthly CloudFront bill went up. They reviewed CloudFront logs and found that many requests include a query string parameter `reqId` that is unique per request (for example, `...?v=2026-04-01&reqId=...`). The team currently forwards all query strings to the cache key. What change is most likely to reduce origin fetches and cost while keeping the versioned images correct?
⚠ Common exam trap
Many candidates think forwarding all query strings is harmless or that lowering TTL helps reduce origin fetches, but the real issue is cache key fragmentation caused by unique parameters like `reqId`.
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 to ignore `reqId` and include only the stable `v` query string parameter in the cache key.
The `reqId` query string parameter is unique per request, which forces CloudFront to treat each request as a distinct cache object when all query strings are forwarded to the cache key. By configuring the cache policy to include only the stable `v` parameter (the version identifier) and ignore `reqId`, CloudFront can serve cached responses for all requests with the same `v` value, drastically reducing origin fetches and lowering costs. This approach preserves correct versioned image delivery because the `v` parameter still differentiates between image versions.
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 to ignore `reqId` and include only the stable `v` query string parameter in the cache key.
Why this is correct
Because `reqId` is unique per request, including it in the cache key prevents cache reuse (each request maps to a different cache entry), resulting in frequent origin fetches. Excluding `reqId` and keeping only `v` allows many requests for the same version to share cached objects, reducing origin traffic and cost while preserving correct version behavior.
- ✗
Lower the CloudFront minimum TTL to 0 seconds so cached objects revalidate more often, reducing origin fetch volume.
Why it's wrong here
Lowering the minimum TTL to 0 would force CloudFront to treat objects as immediately expired, causing it to revalidate with the S3 origin on every request when the cache key still contains the unique reqId. This actually increases origin fetch traffic rather than reducing it, because revalidation requires a conditional request to the origin for each distinct cache key. Moreover, the root problem is cache key fragmentation from reqId, not staleness; adjusting TTL does not improve cache hit ratio for versioned images.
- ✗
Set the S3 bucket to use compression and enable S3 Transfer Acceleration to reduce origin fetch charges.
Why it's wrong here
The observed increase is driven by higher origin fetch *request* volume caused by poor cache key hit ratio. Compression and Transfer Acceleration may change payload size or transfer characteristics but do not fix the caching failure caused by `reqId` being part of the cache key.
- ✗
Disable forwarding of the query string to the origin, but keep using the full query string (including `reqId`) in the cache key.
Why it's wrong here
Even if CloudFront does not forward query strings to the origin, the cache key still determines cache reuse. If `reqId` remains part of the cache key, CloudFront will still create mostly unique cache entries, so origin fetches remain high.
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.