SAA-C03 Design Cost-Optimized Architectures Practice Question
A static marketing site is served through CloudFront from an S3 origin. After a product update, customers report a drop in CloudFront cache hit ratio and the CloudFront bill increases because the origin is receiving many more requests for the same JS/CSS assets. Asset URLs are versioned, but requests now include an Authorization header even though these assets are public. Which CloudFront change most directly improves the cache hit ratio for these assets?
⚠ Common exam trap
Watch out — candidates often think increasing origin capacity or adjusting TTLs solves the problem, but the real issue is that the Authorization header is unnecessarily varying the cache key, which is a common misconfiguration in CloudFront when public assets are served alongside authenticated content.
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
✓
Configure the CloudFront cache policy so Authorization is not included in the cache key, and use an origin request policy that does not forward Authorization to the S3 origin for this behavior
The drop in cache hit ratio is caused by the Authorization header being included in the cache key, which makes CloudFront treat each request as unique even when the asset URL is the same. By configuring the cache policy to exclude Authorization from the cache key and using an origin request policy that does not forward it to S3, CloudFront can serve cached responses for all users regardless of their Authorization header, 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.
- ✗
Increase the origin's max connections to handle more origin fetches
Why it's wrong here
Increasing the origin's max connections only raises the ceiling for concurrent fetches from CloudFront to S3. It does nothing to change the cache key or reduce the number of origin requests, so the root cause—Authorization headers fragmenting the cache and destroying cache hits—remains untouched. In fact, by enabling more parallel origin fetches, you may even increase S3 request costs and origin load.
- ✓
Configure the CloudFront cache policy so Authorization is not included in the cache key, and use an origin request policy that does not forward Authorization to the S3 origin for this behavior
Why this is correct
For public assets, Authorization should not vary the cache key. Removing it from the cache key allows CloudFront to reuse cached objects across requests, and not forwarding it to the origin avoids unnecessary origin variation and request overhead.
- ✗
Set CloudFront minimum TTL to 0 seconds so caches expire faster and origin fetches start again
Why it's wrong here
Setting the minimum TTL to 0 seconds forces CloudFront to consider objects stale immediately, prompting revalidation or a fresh origin fetch on every viewer request. This directly collapses the cache hit ratio and amplifies the volume of requests reaching S3, which is the opposite of the desired outcome. A low minimum TTL should only be used when content changes extremely frequently, not to solve a cache-key misconfiguration.
- ✗
Disable CloudFront compression because Authorization headers are not cacheable when compression is enabled
Why it's wrong here
Disabling compression would hurt performance and has no bearing on how Authorization headers affect the cache. CloudFront handles compression independently of cache-key logic; headers like Authorization are included or excluded based on the cache policy and origin request policy, not compression settings. Turning off compression merely makes every response larger and slower while leaving the cache hit ratio problem completely unaddressed.
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
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.