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.

Increase the size of the S3 bucket’s underlying storage to absorb more origin traffic.

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.

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.

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.

What does this SAA-C03 question test?

Static NAT maps one inside address to one outside address.

What is the correct answer to this question?

The correct answer is: Create a dedicated cache behavior for the static asset path that excludes cookies, query strings, and unneeded headers from the cache key. — The best improvements are to isolate the static content in its own CloudFront behavior and to make the assets explicitly immutable through long cache headers. Those two changes let CloudFront reuse the same object for many requests, even when another behavior on the distribution is personalized and less cacheable. Because the files are already versioned by filename, long caching is safe and reduces origin fetches substantially. Increasing S3 storage capacity, adding timestamp-based request rewriting, or disabling compression does not improve cache reuse. The main issue is that the cache key is too broad for static files, causing unnecessary variation. The correct architecture is to narrow what is cached for the asset path and allow the versioned files to stay in cache for a long time.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.