SCS-C02 Security Logging and Monitoring Practice Question

A company uses AWS Organizations with multiple accounts. The security team wants to centralize security logs (CloudTrail, VPC Flow Logs, AWS Config) from all accounts into a single S3 bucket for analysis. What is the MOST secure way to set up this centralized logging?

⚠ Common exam trap

A common mix-up: candidates assume the management account is the safest place for centralized logs, but AWS best practices recommend using a dedicated security account to isolate logs and avoid compromising the management account's administrative boundaries.

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 a dedicated S3 bucket in the security account with a bucket policy that grants write access to the logging services of all accounts and enforces encryption in transit and at rest.

It uses a dedicated S3 bucket in a security account (not the management account) with a bucket policy that explicitly grants write access to the logging services (CloudTrail, VPC Flow Logs, AWS Config) from all accounts, while enforcing encryption in transit (aws:SecureTransport) and at rest (default SSE-S3 or SSE-KMS). This follows the security best practice of isolating logs in a separate account and using resource-based policies to restrict access, preventing accidental deletion or modification by other accounts.

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 a dedicated S3 bucket in the management account, enable S3 default encryption, and configure service delivery for each account.
Why it's wrong here
Placing the centralized S3 bucket in the management account expands the attack surface of the root account and conflates administrative control with audit data, which is contrary to the AWS Well-Architected security guidance of separating logging into a dedicated account. S3 default encryption only encrypts objects at rest; it does not enforce encryption in transit or restrict which principals from member accounts can write to the bucket. A bucket policy with explicit allows for each account's logging service and condition statements such as aws:SecureTransport and s3:x-amz-server-side-encryption is still required, making this option incomplete.
✓
Create a dedicated S3 bucket in the security account with a bucket policy that grants write access to the logging services of all accounts and enforces encryption in transit and at rest.
Why this is correct
This approach aligns with AWS best practices by placing logs in a dedicated security account that is isolated from production workloads and the management account. The bucket policy grants write access only to the logging services of all accounts, using service principals like logging.s3.amazonaws.com, while condition keys such as aws:SecureTransport force TLS and a deny statement without s3:x-amz-server-side-encryption ensures all objects are encrypted at rest. This centralizes auditability, enforces least privilege, and provides a single source of truth for compliance and incident investigation.
✗
Configure each account to deliver logs to the same S3 bucket used for other data.
Why it's wrong here
Reusing an existing bucket that already stores operational or application data violates the principle of least privilege because the bucket policy must grant cross-account write access to logging services for a bucket that also contains sensitive non-log objects. This broadens the effective permissions of the logging service principal and makes it difficult to apply appropriate lifecycle, retention, and access-control policies that are specific to audit logs. Mixing logs with other data increases the risk of accidental deletion or modification of log evidence and complicates compliance audits.
✗
Create an S3 bucket in each account and use S3 replication to copy logs to a central bucket.
Why it's wrong here
This approach requires creating and managing a bucket in every account, duplicating storage costs and introducing asynchronous S3 replication delays, so logs do not arrive at the central bucket in near real time. S3 replication is not designed for log aggregation; it replicates objects based on source-bucket lifecycle rules and requires additional configuration for encryption, object ownership, and cross-account IAM, which scales poorly across many accounts in an organization. This also complicates data retention because replicated copies are subject to source-bucket lifecycle policies, undermining the goal of a single authoritative log archive.

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

SCS-C02 Security Logging and Monitoring Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question