DEA-C01 Data Operations and Support Practice Question

Exhibit

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*"
    },
    {
      "Effect": "Deny",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/confidential/*"
    }
  ]
}

Refer to the exhibit. An IAM policy is attached to a user who needs to read objects from the 'example-bucket' S3 bucket. The user reports being unable to read any object under the 'confidential/' prefix. What is the reason for this access issue?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The explicit deny statement overrides the allow statement

An explicit deny statement overrides any allow statement, regardless of the order in which they appear. In this policy, there is an allow for GetObject on all objects in example-bucket, but there is an explicit deny for GetObject on the 'confidential/' prefix. Since explicit deny takes precedence, the user cannot read objects under that prefix. Option A is incorrect because the order of evaluation does not matter; explicit deny always wins. Option B is incorrect because the deny statement does not need an explicit allow; the deny itself is effective. Option D is incorrect because the resource ARN in the deny statement is correctly specified as 'arn:aws:s3:::example-bucket/confidential/*'.

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 allow statement is evaluated before the deny statement
Why it's wrong here
IAM evaluates all statements together; an explicit Deny always overrides any Allow regardless of order, so sequencing is not the cause. Ordering matters only for readability, not evaluation. The stem's deny on the confidential prefix blocks reads even though a broad Allow exists, which is the actual mechanism at fault.
✗
The deny statement is missing an explicit allow for the confidential prefix
Why it's wrong here
An explicit Deny cannot be overridden by adding an Allow; AWS always evaluates Deny first and it wins. The policy already permits s3:GetObject broadly, so the missing element is not an Allow. This option misreads how deny-and-allow interact, which is the core IAM evaluation logic tested here.
✓
The explicit deny statement overrides the allow statement
Why this is correct
An explicit Deny in an IAM policy always wins over any Allow, regardless of order or specificity. The deny statement covering the confidential/ prefix therefore blocks those read requests even though the allow statement grants s3:GetObject on the bucket.
✗
The resource ARN in the deny statement is incorrect
Why it's wrong here
If the deny statement's resource ARN were malformed, it would not match the confidential prefix and reads would succeed, contradicting the reported failure. ARN accuracy matters for scoping denies, but here the deny correctly targets confidential/* and is what blocks access. The stem's symptom confirms the ARN matches.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

DEA-C01 Data Operations and Support Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question