SAP-C02 Design for New Solutions Practice Question

Exhibit

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    }
  ]
}

Refer to the exhibit. A solutions architect has attached this IAM policy to an IAM role used by an application. The application is trying to upload an object to the S3 bucket example-bucket with server-side encryption using AWS KMS (SSE-KMS). What will happen?

⚠ Common exam trap

Many exam-takers assume the `s3:PutObject` action alone grants permission, overlooking the restrictive condition that requires a specific encryption header value, which is a common IAM policy nuance tested on the SAP-C02 exam.

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 policy requires SSE-S3.

The IAM policy explicitly requires the `s3:x-amz-server-side-encryption` header to be set to `AES256` (SSE-S3) via the `StringEquals` condition. Since the application is attempting to use SSE-KMS, the encryption header will be `aws:kms`, which does not match the required value. Therefore, the condition fails, and the `s3:PutObject` action is denied, causing the upload to fail.

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 succeeds because the policy allows s3:PutObject for the bucket.
Why it's wrong here
The policy grants s3:PutObject but omits kms:GenerateDataKey, which SSE-KMS requires to obtain a data key before writing the object, so the upload fails with AccessDenied. It tempts because s3:PutObject alone suffices for SSE-S3 or SSE-C uploads, where no KMS key permission is involved.
✓
The upload fails because the policy requires SSE-S3.
Why this is correct
The policy's `s3:PutObject` statement carries a condition demanding `AES256`, which is SSE-S3, not SSE-KMS. Because the application requests `aws:kms` encryption, the condition evaluates false and the request is denied, so the upload fails. The policy therefore blocks the SSE-KMS upload the stem describes.
✗
The upload fails because the bucket policy does not allow SSE-KMS.
Why it's wrong here
The upload succeeds: the identity policy grants s3:PutObject, and SSE-KMS requires no bucket-policy statement permitting it. A bucket policy denying unencrypted uploads or mandating a specific KMS key would be needed to block this. This option tempts those who conflate key-policy permissions with bucket-policy encryption conditions.
✗
The upload succeeds because the condition only applies to encryption at rest.
Why it's wrong here
The condition key aws:ServerSideEncryption applies to the upload request itself, not to data at rest, so SSE-KMS requests are denied. This option would hold only if the condition targeted a post-write attribute rather than the request header.

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