Architect a secure draft preview system for a headless CMS

WHAT THIS TESTS: This question evaluates whether you can reconcile content management workflows with production security. Interviewers want to see that you understand the tension between giving writers a realistic preview and preventing unauthorized access to unpublished material. The core concerns are authentication, authorization, data freshness, cache invalidation, and the principle that production infrastructure should not treat drafts as publicly cacheable assets.

A GOOD ANSWER COVERS: First, an authentication layer. The writer must prove identity, usually via a session cookie or a short-lived JWT issued by your identity provider. Second, an authorization check. The system should verify that the authenticated user actually owns or has edit rights to the specific draft before fetching it. Third, a secure data path. The frontend or an API gateway requests the draft from the headless CMS using a preview token or a dedicated preview API key, not the public content API. Fourth, rendering strategy. Server-side rendering or edge middleware is ideal because it can inject draft content at request time without baking secrets into the client bundle. Fifth, cache and SEO controls. The response must carry cache-control private no-store and x-robots-tag noindex headers to stop CDNs and search engines from indexing or caching the draft. Sixth, token hygiene. Preview tokens should be short-lived, scoped to a single draft, and rotated frequently.

COMMON WRONG ANSWERS: A major red flag is proposing a static site generation approach that builds every draft into a deploy preview without access controls. Another is relying on security through obscurity, such as unguessable URLs or query parameters, which leaks when shared. Disabling authentication entirely on a preview subdomain is also unacceptable because it exposes internal content to anyone who discovers the hostname. Finally, using the production CDN cache for draft responses is dangerous because it can serve unpublished content to anonymous users.

LIKELY FOLLOW-UPS: Interviewers often ask how you would handle real-time collaborative previews if multiple editors are viewing the same draft simultaneously. They may probe how you prevent SSR performance degradation when the CMS preview API is slow, perhaps via stale-while-revalidate or circuit breakers. Another common follow-up is how to support preview across mobile apps or third-party frontends that do not share your auth session.

ONE CONCRETE EXAMPLE: Imagine a Next.js application backed by a headless CMS like Contentful or Sanity. When a writer clicks preview, the CMS redirects to yoursite.com/preview/article-id?token=xyz with a signed JWT in a secure httpOnly cookie. An edge middleware function verifies the JWT, extracts the user ID, and checks an access control list. If allowed, the middleware calls the CMS preview API with a service-account token, retrieves the draft, and passes it as props to the page. The page renders exactly like production but sets cache-control private no-store and x-robots-tag noindex. The JWT expires in fifteen minutes and the CMS preview token is single-use, ensuring that a leaked link becomes useless quickly.