SCS-C02 Security Logging and Monitoring Practice Question
Exhibit
Refer to the exhibit.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-log-bucket/AWSLogs/123456789012/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}A security engineer is configuring a multi-account CloudTrail setup. The above bucket policy is attached to the central logging bucket. Despite the policy, CloudTrail in the member account (123456789012) cannot deliver logs. What is the MOST likely issue?
⚠ Common exam trap
It's easy for candidates to assume the condition s3:x-amz-acl is always required for CloudTrail delivery, but CloudTrail does not set this condition key by default; the policy must match the actual request attributes, and misconfiguring conditions is a common cause of silent delivery failures.
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 condition s3:x-amz-acl is not required; CloudTrail does not set that ACL.
CloudTrail does not set the s3:x-amz-acl condition key when delivering log files to S3. The bucket policy incorrectly includes this condition, which causes the S3 authorization to fail because the condition key is not present in the CloudTrail PutObject request. Removing the condition or adjusting the policy to not require it resolves the delivery failure.
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 Principal should be the CloudTrail service principal of the member account.
Why it's wrong here
CloudTrail authenticates with the same service principal `cloudtrail.amazonaws.com` from every AWS account, so there is no such thing as a member-account-specific service principal. The bucket policy must grant access to that single global principal, and if cross-account or organization-wide access is involved, you should restrict it with conditions such as `aws:SourceArn` or `aws:SourceAccount`, not by changing the Principal. Replacing the existing principal with the member account's service principal would still not fix the ACL condition mismatch.
- ✓
The condition s3:x-amz-acl is not required; CloudTrail does not set that ACL.
Why this is correct
CloudTrail delivers log files via the S3 `PutObject` API, but it does not set the `x-amz-acl` request header or the `bucket-owner-full-control` canned ACL unless the trail is explicitly configured for that behavior. If the bucket policy uses a `StringEquals` condition on `s3:x-amz-acl`, every PutObject request from CloudTrail will not match the condition and is denied before the write can occur. Removing that condition allows the PutObject action to succeed; use a condition on `aws:SourceArn` or `aws:SourceAccount` instead to scope the trust.
- ✗
The Action should be s3:PutObjectAcl instead of s3:PutObject.
Why it's wrong here
CloudTrail writes a new object using `s3:PutObject`; `s3:PutObjectAcl` is a separate S3 API that only changes the ACL on an object that already exists. The trail never issues a PutObjectAcl call during log delivery, so adding or substituting that action would not match the API call CloudTrail makes and would still fail authorization. The action in the current policy is therefore correct, and the fix lies elsewhere.
- ✗
The resource ARN must include the source account ID in the path.
Why it's wrong here
The resource ARN in the policy already contains the expected `AWSLogs/<account-id>/CloudTrail/` prefix, so the bucket owner's policy is correctly scoped to the object path CloudTrail writes to. When CloudTrail calls PutObject, it uses the service principal, not the source-account principal, and the object ARN's path prefix is matched by the Resource element, not by re-stating the account ID. Therefore this option is already satisfied and is not the reason log delivery fails.
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
One of 1,205 original SCS-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SCS-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 SCS-C02 exam.