A company is developing a web application that allows its employees to upload a profile...

The requirement is to keep profile pictures private in S3 while allowing the browser to display them each time an employee logs in. The standard AWS pattern is to store objects in a private bucket and provide time-limited access through S3 presigned URLs . A presigned URL grants temporary permission to perform a specific operation (such as GET) on a specific object, and it expires automatically after a configured duration. This prevents public access while still allowing simple browser retrieval.

Option D is the viable long-term solution because it stores only the S3 object key (a stable identifier) in DynamoDB and generates a fresh presigned URL at login time . This is important because presigned URLs expire; storing a presigned URL (option A) would eventually store an expired URL and force extra complexity to refresh records. Generating a new presigned URL when needed ensures the link is always valid and keeps the expiration window tight, which improves security.

Option B is not appropriate for employee browsers in general: a VPC endpoint is for traffic from resources inside a VPC (EC2, Lambda in VPC, etc.). Employee browsers on the public internet cannot use a private VPC endpoint to reach S3. Option C is not viable for “no size limit” images: DynamoDB has strict item size limits, base64 inflates data size, and storing large binary blobs in DynamoDB is inefficient and expensive compared to S3.

Therefore, D best meets the requirement: keep images private in S3, store the S3 key in DynamoDB, and generate a presigned URL on each login to provide secure, temporary access for display.