DVA-C02 Development with AWS Services Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use CloudFront signed URLs with an origin access identity (OAI) to restrict access to the S3 bucket.

  Why it's wrong here

  CloudFront signed URLs are designed to control access to content delivered through the CloudFront CDN, not for direct, temporary access to individual S3 objects. While an Origin Access Identity (OAI) or Origin Access Control (OAC) restricts direct S3 bucket access, this solution introduces unnecessary complexity and latency if the primary goal is to provide secure, time-limited direct links to private S3 documents. It's an architectural mismatch for the specific requirement of granting temporary S3 object access.

• ✓

  Create a pre-signed URL for each object using the AWS SDK with an appropriate expiration time.

  Why this is correct

  Creating a pre-signed URL for each object using the AWS SDK is the most secure and efficient method for granting temporary access to private S3 objects. This URL, generated with the developer's AWS credentials and a specified expiration time, allows any recipient to perform a specific action (e.g., GET) on the object directly from S3 without needing their own AWS credentials. It provides granular, time-limited access, perfectly aligning with the need for secure access to private user documents.

• ✗

  Set a bucket policy that allows public read access for the specific users based on their IP addresses.

  Why it's wrong here

  Setting a bucket policy to allow public read access, even when restricted by IP addresses, is generally inappropriate for private user documents. End-user IP addresses are often dynamic, making this approach unreliable and difficult to manage at scale. More critically, it grants persistent access to anyone from those IPs rather than temporary, per-object access, failing to meet the requirement for secure, time-limited access to individual private documents.

• ✗

  Provide the users with IAM user credentials that have read access to the bucket.

  Why it's wrong here

  Directly providing IAM user credentials to end-users is a severe security anti-pattern and violates fundamental security best practices. This approach grants persistent, potentially broad access to the S3 bucket, making it impossible to revoke access for individual objects or after a specific time without modifying the IAM user's policy. It creates significant credential management overhead and drastically increases the risk of credential compromise, failing to provide temporary or granular access control.

Go deeper

Related to this question