SOA-C02 Security and Compliance Practice Question

Exhibit

Refer to the exhibit.

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

Refer to the exhibit. An IAM policy is attached to a user. What is the effective permission regarding the s3:DeleteObject action on the example-bucket?

⚠ Common exam trap

SOA-C02 often tests whether candidates know that explicit Deny always wins over Allow and that statement order in an IAM policy is irrelevant to evaluation.

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

✓

Denied because of the explicit Deny statement

The effective permission is Denied because of the explicit Deny statement. In AWS IAM policy evaluation, an explicit Deny always overrides any Allow, regardless of the order in which statements appear or whether the action is otherwise permitted. Since the policy contains an explicit Deny for s3:DeleteObject on example-bucket, the request is denied.

Answer analysis

Option-by-option breakdown

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

✓
Denied because of the explicit Deny statement
Why this is correct
The presence of an explicit Deny statement for the s3:DeleteObject action creates an unresolvable conflict with the Allow statement in the same policy. AWS IAM evaluates all policies and any explicit Deny always overrides every Allow, regardless of how broad or specific the Allow may be. Even though the first statement grants all S3 actions, the Deny takes precedence and the request is ultimately denied.
✗
Denied because the action is not allowed explicitly
Why it's wrong here
This response incorrectly assumes that an Allow must exist for every action to be permitted. The attached policy does contain a clear Allow statement granting all S3 actions (including DeleteObject) via the wildcard, so the action is indeed explicitly allowed in the policy. The denial is not due to a missing Allow; it is due to the explicit Deny that overrides that Allow.
✗
Allowed because the Allow statement is listed first
Why it's wrong here
This response confuses IAM evaluation order with precedence. AWS IAM evaluates all statements and decides based on the presence of an explicit Deny, not the order in which statements appear. Because the Deny statement is explicit, it nullifies the Allow even if the Allow is written first; ordering within a policy has no effect on the final decision.
✗
Allowed because the Deny statement has a typo
Why it's wrong here
This response claims the Deny statement is invalid because of a typo, but the policy syntax is correct. The Deny statement uses proper action and resource elements, and the resource ARN matches the same bucket as the Allow. There is no typo or malformation that would cause AWS to ignore the Deny; it is a valid statement and its effect is to deny the DeleteObject action.

Visual reference

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

SOA-C02 Security and Compliance Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question