A multi-lingual citizen portal on CloudFront must vary cache by Accept-Language without disabling caching entirely. What should the developer configure?
Select an answer to reveal the explanation.
Short Explanation
Citizens speaking different languages need different cached pages—not a total cache blackout. Fold Accept-Language into the CloudFront cache key and keep caching on. You get the right language without throwing the CDN away.
Full Explanation
A multi-lingual citizen portal on CloudFront must vary cache by Accept-Language without disabling caching entirely, so the developer should use a cache policy that includes Accept-Language in the cache key while still caching responses. That yields separate cached variants per language without forcing every request to origin via no-store. Citizens get fast responses in their language; the city keeps edge caching benefits.
Setting all Cache-Control headers to no-store so language never matters defeats caching and raises origin load.
Forwarding and caching on every possible request header including cookies and authorization creates extreme cache fragmentation and often bypasses useful cache hits.
Disabling CloudFront and serving only from a single origin Region removes the CDN benefits the portal relies on.
Exam caveat: Include only the headers that must differentiate content in the cache key; Accept-Language is the targeted lever here.
Operational check: Attach a cache policy including Accept-Language, test en versus es responses for distinct cache entries, confirm hit ratios remain healthy, and avoid adding cookies/authorization to the cache key unless required. Keep the civic/municipal context in mind: multi-lingual city portals need correct language variants without abandoning CDN performance on peak days.