A parts catalog returns the same CloudFront object for two different query strings. The cache policy does not include the query string. What should change so each query string is cached separately?
Select an answer to reveal the explanation.
Short Explanation
If the filing cabinet ignores the sticky note on the folder, both notes pull the same folder. You add the query string to the cache policy so it is part of the cache key. One invalidation clears today's object only, and forwarding the query string to the origin without changing the cache key still collides.
Full Explanation
CloudFront builds the cache key from the cache policy. When the query string is not part of that key, two requests that differ only by the query string are the same object, and the second request is served from the first response. Adding the query string to the cache policy makes each value a distinct key, so each one is cached separately. An invalidation deletes what is cached now. The next pair of query strings collides again because the key still ignores them. Compression changes the encoding of a response. It does not add the query string to the cache key, so both values still share one object. An origin request policy can forward the query string to the origin, but forwarding does not change the cache key. If the key omits the query string, CloudFront can keep serving the cached object and never ask the origin for the second value. Caveat: include the query strings that actually change the response, or the cache fills with entries that do not differ. Operational check: request the path with two query string values and confirm the responses differ and both were misses at the origin.