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?

Create a cache policy that forwards the query string to the origin and varies the cache key by all query parameters.

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.

Enable S3 origin access control and keep the existing default cache policy, because origin access changes caching behavior automatically.

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.

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.

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: 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 hit ratio depends on what CloudFront considers a unique request via the cache key. Unique tracking query parameter values cause different URLs, which can lead CloudFront to treat each request as a different cache entry. The best fix is to update the CloudFront cache policy so the cache key ignores the specific tracking query parameter. Then CloudFront caches the static JS/CSS assets by path (and any other content-relevant factors) and serves the same cached object regardless of the campaign tracking value, improving hit ratio and reducing origin requests. A keeps the fragmentation problem by varying cache entries by the tracking query string. C improves access security but does not change cache-key behavior. D forces cache misses by design and does not address the root cause.

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.