SCS-C02 Security Logging and Monitoring Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Deliver logs to separate buckets per account and use S3 replication to copy them to a central bucket.

  Why it's wrong here

  Delivering logs to separate buckets per account and using S3 replication introduces a time lag and does not enforce a single, immutable write destination; replication is asynchronous, so logs can be altered or deleted in the source bucket before being copied, violating the centralised, tamper-proof logging requirement. This approach is tempting because it is commonly used for cross-region or cross-account data synchronisation when eventual consistency and source-bucket retention are acceptable, such as for backup or disaster recovery scenarios.

• ✗

  Use a single S3 bucket in the management account and have each account write logs directly without additional permissions.

  Why it's wrong here

  This is incorrect because cross-account delivery of CloudTrail logs to an S3 bucket cannot happen without explicit permission. Each source account's CloudTrail service must be granted write access via a bucket policy on the destination bucket; absent that policy, S3 returns AccessDenied. Additionally, colocating logs in the management account violates the security best practice of using a dedicated logging account, since the management account is the highest-privilege account and its compromise would also expose or tamper with logs.

• ✓

  Configure each account's CloudTrail to deliver to a centralized S3 bucket in a logging account, with a bucket policy allowing CloudTrail from source accounts.

  Why this is correct

  This is correct because CloudTrail can be configured as a single trail (or one per source account) to deliver to a centralized S3 bucket in a dedicated logging account. The logging account's S3 bucket policy must explicitly authorize cloudtrail.amazonaws.com for each source account, usually with a source account and source ARN condition, so CloudTrail can write objects to a per-source prefix. This creates an immutable, central log store that source-account administrators cannot modify or delete, and it is a standard, well-supported pattern for centralized logging.

• ✗

  Stream logs to Amazon Kinesis Data Firehose in each account and consolidate into a single S3 bucket via cross-account delivery.

  Why it's wrong here

  Streaming logs via Kinesis Data Firehose in each account with cross-account delivery to a single S3 bucket is a functional log centralisation method. However, it is not the most secure because it requires each source account's Firehose stream to be granted direct write permissions to the central S3 bucket. This approach grants individual source accounts direct access, which can be less controlled than solutions where the central account explicitly defines write permissions via S3 bucket policies, or uses services like CloudTrail or Config aggregation that inherently manage cross-account log delivery securely. Firehose is excellent for real-time data ingestion and transformation within a single account or to a central account when the focus is on throughput and processing, rather than the strictest cross-account security posture.

Go deeper

Related to this question