How to Actually Answer the CDN Caching Question

HTTPS does not stop edge caching. It forces you to define trust boundaries and cache scope.

Interviewer: “If HTTPS encrypts everything, how does a CDN still cache content?”

That sounds like a trick question until you hear the bad answers. A lot of candidates say “CDNs only cache static files” or “APIs should never be cached” and move on. Both answers feel safe. Neither answer tells the interviewer whether you understand where TLS ends, what a shared cache is, or why one bad cache header can leak the same response to thousands of users.

The real tension is not speed. It is ownership. A CDN is a shared cache sitting between your users and your origin. Once you see the question that way, the answer stops being about buzzwords and turns into a decision model: which responses are safe to reuse, which cache key dimensions matter, and which responses should never survive the request that created them.

What the interviewer is actually testing

This question is not asking for a dictionary definition of a CDN. It is testing whether you can separate three layers that junior answers usually mash together:

• Transport security: HTTPS encrypts traffic in transit. It does not mean every intermediary is blind forever.
• Cache scope: A browser cache belongs to one user. A CDN cache is shared across many users unless you narrow it on purpose.
• Reuse rules: A response becomes cacheable or uncacheable because of method, headers and freshness rules, not because someone called it an API.

If you name those three layers early, the rest of the interview gets much easier. You stop arguing from slogans and start reasoning from boundaries.

The naive answer

The naive answer usually goes like this:

“CDNs cache images, CSS and JavaScript. They should not cache API responses because APIs are dynamic and HTTPS is encrypted.”

That answer is not ridiculous. In plenty of production systems, bypassing the CDN for /api/* is the safest default. If you do not know the data shape, the auth model, or the invalidation story, sending API traffic straight to the origin is often the least expensive mistake.

But it is still incomplete.

Public product catalogs are API responses. So are health checks, feature flags, exchange rates, public search suggestions and the static configuration blobs every mobile client downloads on boot. Those are all candidates for edge caching, which is exactly why “never cache APIs” falls apart the moment you leave a whiteboard and look at a real platform. On the other hand, a signed download URL or a “static” JSON document personalized by cookies can be dangerous in a shared cache. The real line is not static versus dynamic. It is shared versus user-specific.

Why that answer breaks down

The first mistake is assuming HTTPS and caching fight each other.

They do not. In a standard CDN setup, the client negotiates TLS with the CDN edge. If the edge already has a fresh cached object, it serves that object and sends it back over an encrypted connection. If the edge misses, it can open its own HTTPS connection to the origin, fetch the object, decrypt it at the edge, store it, then re-encrypt it for the viewer. The encryption is real, and so is the cache.

The second mistake is treating “API” as a cache policy.

HTTP does not care whether your path is /logo.png, /articles or /api/products?page=1. The cache cares about method, cache directives, freshness and the cache key. If the response is identical for many users and safe to reuse, a shared cache can help. If the response is tied to one identity, one permission set or one rapidly changing balance, a shared cache becomes a liability.

The third mistake is ignoring authenticated requests.

This is where many interview answers fall apart. Shared caches do not get to reuse responses to requests with an Authorization header just because the engineer wants lower origin load. You need explicit policy for that. If you skip that detail, you are not answering a CDN question anymore. You are describing a data leak with optimistic branding.

The full technical answer

Here is the production-grade version.

Start with the request path:

1. The viewer sends an HTTPS request to the CDN edge.
2. The edge terminates TLS for that hop and can inspect the HTTP request and response metadata.
3. The edge decides whether it can serve a stored response, whether it needs to revalidate, or whether it must go to origin.
4. If it goes to origin, it can use HTTPS on that hop too.
5. The edge returns the response to the viewer over HTTPS again.

That is why HTTPS does not disable caching. It changes who is trusted to see plaintext at each hop.

Once you establish that, move to cache scope. RFC 9111 draws a clean line:

• A shared cache stores responses for reuse by more than one user.
• A private cache is dedicated to a single user, usually the browser.

That distinction matters more than whether the payload is JSON.

The decision framework that actually helps

When I hear this question, I use a three-part filter.

1. Is the response identical for many users?

If yes, edge caching is on the table.

Good candidates:

• Public catalog pages
• Static configuration
• Public documentation endpoints
• CORS preflight responses when configured deliberately

Bad candidates:

• /api/me
• Account balances
• Permission-scoped dashboards
• Signed download responses tied to one user

2. What is the cache key?

The dangerous default is assuming the URI alone is enough.

Sometimes it is. Sometimes it is not even close, because locale, device class, compression, selected query parameters, specific headers and sometimes cookies all change whether two users should see the same stored response. CloudFront can cache multiple versions of an object based on selected headers. It can also destroy your hit ratio if you vary on too much. That trade-off is the whole job.

3. What freshness and invalidation rules apply?

Shared caches can safely help only when you can answer two questions:

• How long may this response be reused without origin contact?
• What event makes this stored copy wrong?

For truly sensitive responses, the answer is easy: do not store them. For public data, you pick a short freshness window and a revalidation plan. For money movement or permission changes, you stay conservative because stale correctness bugs are more expensive than origin CPU.

The header-level answer

This is the part interviewers remember because it proves you can turn theory into a shipping rule.

A public response that many users can share might look like this:

Cache-Control: public, max-age=60, s-maxage=300

That says browsers can keep it for 60 seconds, while a shared cache can keep it for 300 seconds under the shared-cache rules.

A user-specific response that should never land in a cache looks very different:

Cache-Control: no-store

If you want to allow only the browser’s private cache, the response moves into a third bucket:

Cache-Control: private, max-age=30

That difference is the heart of the interview answer. private means a shared cache must not store the response, while no-store means nobody should store it at all. Those are not synonyms. They express different operational bets.

The part most candidates miss

Authenticated requests are not just “dynamic.” They are policy-sensitive.

RFC 9111 says a shared cache must not store a response to a request carrying Authorization unless the response explicitly allows shared caching. That means you do not get to put a CDN in front of an authenticated endpoint and assume the provider will read your mind. You need explicit directives, a deliberate cache key, and enough confidence that one user's authorized view cannot be replayed to another user.

This is where “cache the whole API” plans usually die. Not because CDNs hate APIs. Because most teams have not done the harder work of classifying which API responses are globally shareable, which are only browser-shareable, and which must disappear after the request.

A practical rule set

Use the following mental model in the room:

• Public and repeatable: cache at the edge with explicit freshness.
• User-specific but low sensitivity: maybe allow private browser caching.
• Sensitive, personalized, or mutation-adjacent: no-store, and move on.

That is boring. It is also the answer that survives production.

Production reality

Most small teams start with a blunt rule: do not cache /api/* at the CDN. That is usually fine at the beginning. It avoids data bleed, weird invalidation bugs, and the cost of debugging a cache key you do not fully understand yet.

The problem comes later, when teams never revisit the rule.

Then every public API call hits origin. Your mobile app keeps requesting the same configuration document. Your docs search suggestions never leave the region where your app server lives. Your health endpoint becomes an origin tax. The CDN is right there, but the team turned a useful boundary into a permanent bypass because “API responses are dynamic” sounded like architecture.

The opposite failure mode is worse.

Teams decide to cache authenticated responses and vary on too little. Or they forward every header because they are nervous, which kills cache efficiency and turns the CDN into a very expensive TCP relay. CloudFront’s own guidance makes this trade-off plain: caching on extra headers creates more variants and lowers the hit ratio. In other words, you pay for precision with fragmentation.

There is also an invalidation trap that shows up in interviews less often than it should. Unsafe methods like POST, PUT, and DELETE are not cached by CloudFront, but they do change the correctness of related GET responses. If your answer talks about TTLs but never mentions invalidation or revalidation, it sounds like you know caching as a benchmark trick instead of an application contract.

How to answer it in the room

If the interviewer asks, “HTTPS encrypts everything, so how can a CDN cache content?”, this is the compact version I would give:

“HTTPS does not prevent CDN caching because TLS usually terminates at the CDN edge. The edge can decrypt traffic for that hop, apply cache policy, then re-encrypt traffic to the viewer, and it can use HTTPS to the origin on the other hop too. The real question is not whether the payload is JSON or HTML. It is whether the response is safe for a shared cache. Public GET and HEAD responses with explicit freshness can be cached at the edge. User-specific or sensitive responses should be private or no-store, and anything involving Authorization needs explicit shared-cache rules plus a careful cache key. Then I would explain how the cache key varies by headers, cookies or query parameters and how stale data gets invalidated."

That answer does three useful things fast:

1. It separates transport security from cacheability.
2. It shows you know the difference between shared and private caches.
3. It proves you think in policies and failure modes, not slogans.

That is what interviewers are trying to detect.

The one thing to keep

The CDN question is not asking whether you know caching makes things faster. It is asking whether you know who is allowed to see the same bytes.