DEA-C01 Data Store Management Practice Question

Exhibit

Refer to the exhibit.

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

A data engineer created the IAM policy shown in the exhibit. The engineer then attempts to upload an object to 'my-bucket' using the AWS CLI with the command: aws s3 cp file.txt s3://my-bucket/ --sse aws:kms. The upload fails with an 'AccessDenied' error. What is the most likely cause?

⚠ Common exam trap

The trap here is that candidates may overlook the condition key in the policy and assume the error is due to a missing action or incorrect resource, rather than recognizing that the encryption header value must exactly match the policy's requirement.

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 policy requires SSE-S3 (AES256), but the command uses SSE-KMS

The IAM policy in the exhibit requires the `s3:x-amz-server-side-encryption` header to be set to `AES256`, which corresponds to SSE-S3. The AWS CLI command uses `--sse aws:kms`, which sets the header to `aws:kms` for SSE-KMS. This mismatch causes the request to fail the `s3:PutObject` condition check in the policy, resulting in an 'AccessDenied' error.

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 policy resource is incorrect
Why it's wrong here
The resource ARN in the policy already matches the target bucket and objects, so it cannot produce the AccessDenied. Bucket-level resource entries are tempting because S3 policies often scope permissions per bucket, and that would be correct if the policy referenced a different bucket name.
✓
The policy requires SSE-S3 (AES256), but the command uses SSE-KMS
Why this is correct
The policy's condition permits only AES256 (SSE-S3) encryption, but the CLI command requests aws:kms, so the encryption header mismatches the allowed value and S3 denies the upload. Aligning the command with SSE-S3 or amending the policy resolves it.
✗
The policy does not allow the s3:PutObject action
Why it's wrong here
The policy grants s3:PutObject on the bucket's objects, so the action is permitted and cannot explain the denial. It is tempting because missing PutObject is a common cause of upload failures, and that would be correct if the statement listed only s3:GetObject or similar read actions.
✗
The command is missing the --sse-customer-algorithm parameter
Why it's wrong here
SSE-KMS with aws:kms requires no customer-provided key material, so the parameter is irrelevant to authorisation. It is tempting because SSE-C does need --sse-customer-algorithm, and that flag would be correct when supplying your own encryption key rather than using KMS-managed keys.

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 Store Management Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question