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.

• ✗

  The Effect should be Deny for this policy to work

  Why it's wrong here

  Changing Effect to Deny would not make the policy work as intended. The existing Allow with a Condition is the correct structure: when the condition matches, the action is explicitly allowed; when it doesn't, there is no explicit allow, so AWS relies on the default implicit deny. A Deny statement with the same condition would deny only when the condition is true (and still do nothing for the false branch), while an unconditional Deny would block every PutObject regardless of the ACL, which is not the goal.

• ✗

  The resource ARN is incorrect; it should be arn:aws:s3:::my-bucket

  Why it's wrong here

  The resource ARN arn:aws:s3:::my-bucket/* is correct for object operations such as s3:PutObject. A bucket-level ARN without the /* qualifier is appropriate only for bucket-level actions like s3:ListBucket or s3:GetBucketLocation, not for actions that target individual objects. Since the policy is meant to permit uploading objects, the object ARN with the wildcard path is necessary, and the suggested alternative would actually make the policy invalid for this action.

• ✗

  The user does not have permission to list the bucket

  Why it's wrong here

  This answer misidentifies the failing action. The request is a PUT Object call, which requires only the s3:PutObject permission; s3:ListBucket is not involved in uploading an individual object. The policy does allow s3:PutObject, but the attached condition requires the x-amz-acl header to be exactly bucket-owner-full-control. Because the user failed to supply that header (or supplied a different value), the condition never became true, so the request was implicitly denied — not because of a missing list permission.

• ✓

  The policy condition requires the ACL to be bucket-owner-full-control, but the user did not specify it

  Why this is correct

  Correct — the policy's Condition uses StringEquals to require the s3:x-amz-acl value of bucket-owner-full-control on every PutObject request. When the user's PutObject request does not specify that exact ACL (either omits the x-amz-acl header or sets it to another value), the condition evaluates false. IAM authorization is deny-by-default: without an explicitly matching allow statement, the request is implicitly denied, producing the denied message. The user must include x-amz-acl: bucket-owner-full-control, or the policy must be adjusted if that enforcement is not desired.

Go deeper

Related to this question