SCS-C02 Security Logging and Monitoring Practice Question
A company wants to centralize CloudTrail logs from multiple AWS accounts into a single S3 bucket for security analysis. The logs must be encrypted at rest and access must be logged. What is the MOST secure way to grant cross-account access to the central S3 bucket?
⚠ Common exam trap
Candidates often confuse IAM roles with service principals, thinking that cross-account access always requires an IAM role, but CloudTrail uses service principals and bucket policies for cross-account log delivery, making option B a common distractor.
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
✓
Create an S3 bucket policy that grants CloudTrail service principal permission to write objects, with a condition checking the source account ID.
It uses an S3 bucket policy that grants the CloudTrail service principal (cloudtrail.amazonaws.com) permission to write objects, with a condition that checks the source account ID. This ensures that only CloudTrail from authorized accounts can deliver logs, and the service principal approach avoids the need for IAM roles or sharing credentials. The bucket policy also allows encryption at rest via S3 default encryption or a KMS key, and access logging can be enabled separately on the bucket.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create an S3 bucket policy that grants s3:PutObject to everyone, and rely on CloudTrail to restrict access.
Why it's wrong here
A bucket policy that uses Principal: "*" with s3:PutObject authorizes any principal in any account to write or overwrite objects, which can destroy log integrity and enable data injection. CloudTrail does not "restrict" this access after the fact; the bucket policy is the enforcement point. The delivery service also identifies itself as cloudtrail.amazonaws.com, so the policy should be scoped to that service principal and include an aws:SourceAccount condition.
- ✗
Create an IAM role in the central account that each member account can assume to write logs.
Why it's wrong here
CloudTrail delivery is performed by the CloudTrail service itself using a service principal, not by an IAM role assumed from member accounts. An IAM role in the central account would grant permissions to principals in member accounts, but CloudTrail does not assume roles in the destination account to deliver logs. The correct mechanism is a bucket policy with a Principal of cloudtrail.amazonaws.com; adding an IAM role would neither satisfy CloudTrail's cross-account delivery model nor follow least privilege.
- ✓
Create an S3 bucket policy that grants CloudTrail service principal permission to write objects, with a condition checking the source account ID.
Why this is correct
This is the documented pattern for aggregating CloudTrail logs: the bucket policy grants s3:PutObject (and s3:GetBucketAcl if not using bucket owner enforcement) to the CloudTrail service principal, and the aws:SourceAccount condition restricts the service request to CloudTrail accounts explicitly allowed. The service principal cloudtrail.amazonaws.com prevents individuals or other AWS services from writing, while the condition blocks confused-deputy attacks from accounts not in the allow list. The central account then receives trail logs from all member accounts.
- ✗
Use an S3 bucket with default encryption enabled and share the KMS key with the other accounts.
Why it's wrong here
Default encryption governs how objects are encrypted at rest in S3; it does not grant or deny the ability to write objects. Even with SSE-KMS and a shared KMS key, the CloudTrail service still needs explicit s3:PutObject permission through the destination bucket policy, and the KMS key policy must allow cloudtrail.amazonaws.com to use the key. Sharing a KMS key without also creating the required bucket-policy grant would still result in CloudTrail being unable to deliver logs, and it unnecessarily broadens encryption key access across accounts.
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.