DEA-C01 Data Store Management Practice Question

Exhibit

Refer to the exhibit.

IamPolicyDocument:
  Version: '2012-10-17'
  Statement:
    - Effect: Allow
      Action:
        - 's3:GetObject'
        - 's3:PutObject'
      Resource: 'arn:aws:s3:::my-bucket/*'
      Condition:
        StringEquals:
          's3:x-amz-acl': 'bucket-owner-full-control'

A CloudFormation template includes this IAM policy for a cross-account S3 upload use case. What is the purpose of the condition?

⚠ Common exam trap

It's easy for candidates to confuse the `s3:x-amz-acl` condition key with account-level restrictions or encryption settings, when in fact it specifically controls the Access Control List (ACL) applied to the uploaded object.

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

✓

To ensure that uploaded objects grant full control to the bucket owner.

The condition in the IAM policy uses the `s3:x-amz-acl` key with a value of `bucket-owner-full-control`. This ensures that any object uploaded to the S3 bucket explicitly grants the bucket owner full control over the object, overriding the default behavior where the uploading account retains ownership. This is critical in cross-account uploads to prevent the uploading account from retaining exclusive access to the objects.

Answer analysis

Option-by-option breakdown

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

✗
To enforce server-side encryption with KMS.
Why it's wrong here
The condition does not reference aws:ServerSideEncryption or a KMS key ARN, so it cannot mandate SSE-KMS on uploads. It tempts administrators hardening cross-account writes, since encryption enforcement is a common S3 control, but that requires a dedicated encryption condition key rather than the one present here.
✗
To limit the size of objects that can be uploaded.
Why it's wrong here
The condition evaluates a request attribute tied to identity or encryption context, not object byte size; S3 upload size limits are enforced through bucket policy or presigned URL constraints. Size restriction is tempting because upload conditions often govern payloads, yet this statement's key targets a different request element.
✗
To restrict uploads to only a specific AWS account.
Why it's wrong here
Account restriction is expressed through the Principal element or aws:SourceAccount, not this condition key. It tempts because cross-account uploads are inherently scoped to a trusted account, yet the statement's condition inspects a different request attribute, leaving the principal as the actual account-limiting mechanism.
✓
To ensure that uploaded objects grant full control to the bucket owner.
Why this is correct
The condition checks the canned ACL on uploaded objects, ensuring the bucket owner receives full control. This satisfies the cross-account upload scenario, where objects written by another account would otherwise remain owned solely by the uploading account.

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

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