SAA-C03 Design High-Performing Architectures Practice Question

A media company serves versioned JavaScript and CSS files from Amazon S3 through CloudFront. After each release, the cache hit ratio drops sharply because the same distribution also fronts a personalized API path, and the current cache policy forwards cookies, all query strings, and several headers to every origin request. The static assets already use content-hashed filenames. Which two changes will most directly improve cache hit ratio for the static assets without changing the application behavior? Select two.

⚠ Common exam trap

Candidates often think that content-hashed filenames alone guarantee high cache hit ratios, but they overlook that the shared cache policy forwarding cookies and query strings creates many unique cache keys for the same static file, negating the benefit of hashed filenames.

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 dedicated cache behavior for the static asset path that excludes cookies, query strings, and unneeded headers from the cache key.

Creating a dedicated cache behavior for the static asset path (e.g., /static/*) allows you to configure a cache policy that excludes cookies, query strings, and unneeded headers from the cache key. Since the static assets use content-hashed filenames, they are immutable and do not vary by user-specific attributes. By removing these variables from the cache key, CloudFront can serve the same cached object to all users, drastically improving 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 dedicated cache behavior for the static asset path that excludes cookies, query strings, and unneeded headers from the cache key.
Why this is correct
Separating the static asset behavior lets CloudFront cache those objects independently from the personalized API. Excluding cookies, query strings, and unnecessary headers prevents cache fragmentation, so many viewers can reuse the same cached object. This is the most direct way to raise hit ratio without altering how the application serves assets.
✓
Keep the content-hashed filenames and send long Cache-Control max-age and immutable headers for the versioned objects.
Why this is correct
Versioned filenames make the objects safely cacheable for a long time because a new release produces new object names. Long max-age values and immutable headers tell browsers and CloudFront that the object will not change in place, which increases reuse and reduces origin fetches. This improves performance and lowers origin load.
✗
Increase the size of the S3 bucket’s underlying storage to absorb more origin traffic.
Why it's wrong here
S3 storage capacity does not affect cache key design or CloudFront reuse. The problem is request variation, not insufficient bucket storage. Increasing storage size will not raise the cache hit ratio or reduce repeated origin requests.
✗
Add Lambda@Edge logic to append a timestamp to every asset request so updates are always fetched immediately.
Why it's wrong here
Appending a timestamp intentionally destroys cacheability by making every request unique. That approach may force freshness, but it worsens hit ratio and increases origin traffic. It is the opposite of what a high-performing static asset design should do.
✗
Disable compression so CloudFront can treat each object as a separate cache entry.
Why it's wrong here
Compression does not control cache-key fragmentation in a useful way here. Disabling compression can actually hurt transfer efficiency and does not address the excessive variation caused by headers, cookies, and query strings. The origin request pattern would remain inefficient.

Visual reference

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

SAA-C03 Design High-Performing Architectures Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question