DOP-C02 Security and Compliance 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.

• ✓

  Create an IAM role in the source account with read access to the bucket, and allow users in that account to assume the role.

  Why this is correct

  Creating an IAM role in the source account with read access to the bucket, and allowing users in that account to assume the role, grants cross-account access by using the role as the principal identity. This approach leverages AWS STS trusts so the bucket policy can restrict the principal to the role's ARN, ensuring only users who assume that role can list and read objects. It avoids permanent cross-account credentials and gives you central control over who may assume the role.

• ✗

  Enable S3 Block Public Access on the bucket.

  Why it's wrong here

  Enabling S3 Block Public Access on the bucket is a protective measure that prevents public exposure, but it does not restrict access to a specific AWS account. It only disables public bucket policies and ACLs; it does not evaluate the source account of IAM principals. Legitimate cross-account requests, even from an allowed account, are unaffected by Block Public Access unless the policy itself is public. Therefore, it cannot serve as an access-control mechanism to limit access to a particular account.

• ✗

  Generate pre-signed URLs for each object and distribute them only to users in the target account.

  Why it's wrong here

  Pre-signed URLs provide temporary, time-limited access to a specific S3 object, but the URL itself is the only credential—anyone who possesses it can download the object, regardless of their AWS account. The signature does not bind the request to a particular account or identity; it is based on the signer's credentials. Thus this method cannot enforce a restriction to a specific target account; it only controls the duration and scope of the URL. This makes it unsuitable for limiting access to a designated account.

• ✓

  Write a bucket policy that uses the aws:SourceAccount condition to allow access only from the specific account.

  Why this is correct

  A bucket policy using the aws:SourceAccount condition key restricts access to requests whose source account matches the specified account ID, so only IAM principals controlled by that account can pass the policy evaluation. This condition is commonly paired with aws:SourceArn to protect against the confused deputy problem, and it provides a direct, resource-based way to enforce cross-account access. Because the policy is evaluated against the requester's account, it remains an effective and auditable method for restricting the bucket to a specific account.

• ✗

  Set a bucket ACL that grants read access to the target account's canonical ID.

  Why it's wrong here

  Bucket ACLs are a legacy access-control mechanism that allow you to grant permissions to another account's canonical ID, but they lack the granularity and condition support of bucket policies. They cannot restrict based on IAM roles, IP addresses, or source account—only on the canonical ID of the account. Additionally, ACLs are non-transitive and are generally not recommended because they are harder to maintain and audit. For these reasons, using an ACL to grant read access to a target account is not a secure or scalable method to restrict access to a specific account.

Go deeper

Related to this question