CDN caching for static and dynamic content

WHAT THIS TESTS The question checks that you can configure caching differently per content type and that you understand fingerprinting as the robust answer to static asset invalidation rather than relying on purges.

A GOOD ANSWER COVERS Static assets are immutable per version and identical for every user, so cache them aggressively at the edge with long TTLs, set Cache-Control max-age high, and enable compression. Dynamic, user-specific API responses must not be cached as shared content; either bypass the cache for those paths or cache only very short-lived, non-personalized responses, and use the Vary header and authentication-aware rules so one user never receives another user's cached data. Many CDNs can still accelerate dynamic traffic by terminating TLS at the edge and reusing warm origin connections even when the response itself is not cached. For invalidation of an updated static asset, the durable pattern is cache busting through fingerprinted filenames: embed a content hash like app.9f3a2b.css so a change produces a new URL that the edge has never seen, sidestepping stale caches entirely. Explicit cache purge exists but is slower, propagates globally with delay, and should be a fallback, not the routine mechanism.

COMMON WRONG ANSWERS Caching user-specific API responses without honoring Vary or auth, leaking data between users. Relying solely on manual purges for every deploy. Applying one TTL policy to all content regardless of type.

LIKELY FOLLOW-UPS How do Cache-Control and Vary headers interact? What is stale-while-revalidate? How does the CDN handle cache keys for query strings?

ONE CONCRETE EXAMPLE CSS is served as styles.7c21.css with a one-year max-age and immutable flag, so a redeploy emits a new hash and the old file is never re-fetched. The /api/account path is set to bypass cache so each user always gets their own fresh data.