A Front Door/CDN rule caches /api/lock-status and a harbor contractor sees another operator’s payload. What cache behavior should the security engineer set?
Select an answer to reveal the explanation.
Short Explanation
Personalized or signed-in API payloads don’t belong in the CDN cookie jar. Bypass cache or honor cache-control for those routes; leave anonymous static files on the CDN.
Full Explanation
When a Front Door/CDN rule caches /api/lock-status and a harbor contractor sees another operator’s payload, authenticated or user-specific responses are being cached at the edge. Configure bypass-cache behavior or honor cache-control for those routes so personalized API payloads are not shared across users, while anonymous static assets may still use the CDN.
Caching all /api/* responses aggressively at every PoP fails by concept: it maximizes performance at the cost of cross-user data exposure for authenticated payloads. Disabling Front Door entirely and forcing static assets through Azure Bastion fails by concept: Bastion is unrelated to CDN delivery for anonymous assets. Moving cache keys to source-code Cache-Control only and forbidding Front Door caching rules as an AZ-204-only fix fails by concept: Front Door rule configuration is a Domain 2 control and must be part of the remediation.
Exam caveat: CDN caching of authenticated responses is a security finding—bypass or honor cache-control on user-specific APIs. Operational check: set bypass/honor rules for /api/lock-status, purge existing poisoned cache entries, retest as two operators and confirm payloads do not leak, and leave anonymous static caching enabled where appropriate.