SAP-C02 Design for New Solutions Practice Question

Exhibit

Refer to the exhibit.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-bucket/*"
        },
        {
            "Effect": "Deny",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-bucket/confidential/*"
        }
    ]
}

Refer to the exhibit. A company has an IAM policy that allows s3:GetObject on all objects in 'my-bucket' but denies access to objects in the 'confidential' folder. A user tries to access 's3://my-bucket/confidential/report.pdf'. What will happen?

⚠ Common exam trap

SAP-C02 often tests the IAM policy evaluation logic, and candidates may incorrectly assume that an Allow statement with broader permissions can override an explicit Deny, or that Deny statements are only evaluated if no Allow exists.

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

✓

Access is denied because the Deny statement explicitly matches the resource.

In AWS IAM, an explicit Deny always overrides any Allow. The policy denies access to objects in the 'confidential' folder, and the user's request matches that resource. Therefore, access is denied regardless of the Allow statement.

Answer analysis

Option-by-option breakdown

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

✓
Access is denied because the Deny statement explicitly matches the resource.
Why this is correct
The explicit Deny statement matches the resource `arn:aws:s3:::my-bucket/confidential/*`, and AWS evaluates explicit denies before allows, so the request is refused regardless of the broader s3:GetObject Allow. This satisfies the stem's constraint that the confidential folder must remain inaccessible to the user.
✗
Access is allowed because the Deny statement is not evaluated.
Why it's wrong here
Every applicable policy statement is evaluated, and an explicit Deny matching the confidential prefix overrides the Allow, so access is refused. This is tempting because users assume Deny statements are ignored when an Allow exists, but IAM always evaluates Deny first and it wins.
✗
Access is denied only if the user is not authorized by other policies.
Why it's wrong here
An explicit Deny in an identity-based policy is absolute and unconditional, so access is denied regardless of any other policy granting s3:GetObject. This is tempting because it mirrors the default evaluation logic where absence of an Allow means denial, but that reasoning applies only when no Deny statement matches the request.
✗
Access is allowed because the Allow statement is broader.
Why it's wrong here
Explicit Deny always overrides Allow in IAM policy evaluation, so the broader s3:GetObject permission cannot grant access to the confidential prefix. This is tempting because broader permissions appear to encompass narrower paths, but the deny on the confidential folder takes precedence over any allow.

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

SAP-C02 Design for New Solutions Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question