DOP-C02 Resilient Cloud Solutions 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-acl": "bucket-owner-full-control"
}
}
}
]
}
```An AWS account owner (Account A) owns an S3 bucket named my-bucket. The bucket policy shown in the exhibit is attached to the bucket. A user from Account B attempts to upload an object to the bucket without specifying the x-amz-acl 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 bucket policy requires the x-amz-acl header to be set to bucket-owner-full-control.
The condition requires the x-amz-acl header to be set to bucket-owner-full-control. If the header is not specified, the condition fails, and the request is denied. Option A is wrong because the condition is not met. Option B is wrong because the policy does not grant permission without the header. Option C is wrong because the bucket policy evaluates before the object ACL.
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 bucket policy requires the object ACL to be set, but the default ACL allows the upload anyway.
Why it's wrong here
This statement misunderstands how bucket policy conditions are evaluated. The policy's Condition element checks the x-amz-acl request header at the time of the request, not the object's ACL after S3 applies its default. Since the upload omitted the required header, the condition fails immediately, and the default ACL behavior (which would otherwise grant a private ACL) is irrelevant. An unsatisfied condition in an allow statement results in an implicit deny, so the upload fails.
- ✗
The upload succeeds because the bucket policy does not explicitly deny the request.
Why it's wrong here
In AWS S3 authorization, an action is allowed only if an applicable policy statement explicitly permits it; if no statement matches, the default result is deny. The bucket policy's only allow statement for s3:PutObject includes a condition that the request must carry the x-amz-acl header set to bucket-owner-full-control. Because the condition is not satisfied, the statement does not apply, so the request falls through to an implicit deny. The absence of an explicit Deny statement does not create an allowance when no allow statement is effective.
- ✗
The upload succeeds because the bucket policy allows s3:PutObject for any principal.
Why it's wrong here
This option incorrectly treats the Principal and Action elements as unconditional. While the policy statement may specify Principal * and s3:PutObject, it also contains a Condition element requiring the x-amz-acl header to equal bucket-owner-full-control. When a Condition is present, all conditions must be satisfied for the allow to take effect; otherwise the statement is a no-op for that request. Therefore, the policy does not permit 'any principal' without the required header, and the upload is denied rather than allowed.
- ✓
The upload fails because the bucket policy requires the x-amz-acl header to be set to bucket-owner-full-control.
Why this is correct
The bucket policy uses a condition key such as s3:x-amz-acl with a value of bucket-owner-full-control, making that header a mandatory requirement for any successful s3:PutObject call. When the requester omits the x-amz-acl header, the condition evaluates to false, so the allow statement cannot grant the action. With no other applicable allow, the request is implicitly denied and the upload fails. This design ensures the bucket owner can later manage or delete the object by forcing ownership transfer via the canned ACL.
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
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,013-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.