SOA-C02 Security and Compliance Practice Question

Exhibit

Refer to the exhibit.

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/AdminRole"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }
  ]
}
```

An S3 bucket policy is shown in the exhibit. The AdminRole attempts to upload an object to my-bucket without specifying any server-side encryption header. What will happen?

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 upload fails because the Deny statement denies PutObject without encryption.

The Deny statement denies PutObject when encryption is not aws:kms. Since the request has no encryption header, it does not equal aws:kms, so the Deny applies and the upload fails. The Allow statement allows the action only when encryption is aws:kms, so without encryption, it does not apply. Because the Deny overrides Allow, the upload is denied. Option A is wrong because the Allow does not apply. Option B is wrong because the Deny applies. Option C is wrong because the Deny does apply to the AdminRole.

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 upload fails because the Allow statement requires encryption, but the Deny statement is evaluated first.
Why it's wrong here
Option 1 is incorrect because the failure is not caused by the order of evaluation between the Allow and Deny statements. AWS IAM evaluates all policies and statements, and an explicit Deny always overrides an Allow regardless of the statement position. The operative blocking element is the Deny statement's encryption condition, not the Allow statement's requirement; even if the Allow condition were satisfied, the Deny would still apply because the request lacks aws:kms encryption.
✗
The upload succeeds because the Allow statement grants permission to the AdminRole.
Why it's wrong here
Option 2 is incorrect because it ignores the explicit Deny statement in the bucket policy. While the Allow statement does grant s3:PutObject to AdminRole, the Deny statement applies to the same action and principal without restricting to a specific role, and it unconditionally denies PutObject when the request is not encrypted with aws:kms. Since the upload does not use that encryption, the Deny overrides the Allow, so the upload fails despite the existing Allow permission.
✗
The upload succeeds because the Deny statement does not apply to the AdminRole.
Why it's wrong here
Option 3 is incorrect because the Deny statement in the policy does not specify a Principal, which means it defaults to the wildcard and applies to all principals, including AdminRole. IAM roles, even administrator roles, are subject to resource-based policies that include Deny statements unless explicitly excluded with a NotPrincipal element. The role's administrative permissions do not exempt it from S3 bucket policy Deny effects; the request still fails.
✓
The upload fails because the Deny statement denies PutObject without encryption.
Why this is correct
Option 4 is correct because the Deny statement explicitly denies the s3:PutObject action when the request is not protected with server-side encryption using AWS KMS (aws:kms). Since the upload in the scenario is performed without that encryption header, the Deny statement's condition matches the request, and an explicit Deny overrides any Allow from the same bucket policy or from the role's own IAM policies. Therefore, the upload fails with an AccessDenied error.

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