Serving user images securely from object storage

WHAT THIS TESTS The interviewer wants both the right storage choice and a secure, efficient delivery design that does not expose the bucket.

A GOOD ANSWER COVERS Choose object storage for the images: it is cheap, effectively unlimited, durable, and built to serve blobs over HTTP. For delivery, place a CDN in front so images are cached at edge locations close to users, cutting latency and offloading the origin. Critically, keep the bucket private and grant read access only to the CDN through an origin access control or origin access identity, so users can never hit the bucket directly. For publicly viewable images, serve them through the CDN's domain. For private or per-user images, generate time-limited signed URLs or signed cookies so only authorized users with a valid signature can fetch a given object, and the link expires.

COMMON WRONG ANSWERS Making the entire bucket public to make serving simple, which leaks objects and risks data exposure. Serving images straight from the origin with no CDN, hurting latency and cost. Granting the CDN access but leaving the bucket world-readable anyway. Embedding long-lived public links for content that should be access-controlled.

LIKELY FOLLOW-UPS How do signed URLs enforce expiry and authorization. What is origin access control and why does it matter. How do you handle cache invalidation when an image changes. How do you add image resizing or transformation at the edge.

ONE CONCRETE EXAMPLE A marketplace stores listing photos in a private S3 bucket. CloudFront fronts it with an origin access control so only the distribution can read objects, and the bucket policy denies all other access. Public listing images are served through the CDN domain and cached at the edge. Private documents attached to an order are delivered with five-minute signed URLs, so a buyer can view their receipt but the link cannot be shared or reused after it expires.