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.

• ✗

  Enable S3 Versioning on the CloudTrail bucket.

  Why it's wrong here

  Enabling S3 Versioning on the CloudTrail bucket preserves overwritten and deleted log file versions, so an auditor could potentially recover prior copies after an incident. However, versioning does not validate the integrity of the current or historical objects—any version could itself be altered, and nothing detects that a log file's content differs from what CloudTrail originally delivered. It is a data-retention and availability control, not a tamper-evidence mechanism, so it cannot confirm whether the logs have been modified.

• ✗

  Enable S3 server-side encryption with SSE-S3.

  Why it's wrong here

  SSE-S3 encryption protects the confidentiality of CloudTrail logs by encrypting objects at rest with Amazon-managed keys. Encryption alone does not establish integrity: an attacker or a process with PutObject permissions can rewrite log data and the encrypted object will still decrypt successfully, leaving no cryptographic proof that the content was changed after delivery. Since the requirement is to detect tampering rather than prevent unauthorized reads, SSE-S3 is not a valid integrity-control answer.

• ✓

  Enable CloudTrail log file integrity validation.

  Why this is correct

  CloudTrail log file integrity validation is the correct choice because it provides cryptographic verification of the log files: every log file's SHA-256 hash is included in a separate, frequently issued digest file that is signed with a private key. This hash chain lets you detect whether a log file was modified, deleted, or replaced after CloudTrail delivered it, and you can verify digests using the public key that CloudTrail publishes. Because an attacker would need the private key to forge a valid digest, this feature directly satisfies the requirement to determine whether CloudTrail logs have been tampered with.

• ✗

  Enable S3 Object Lock on the CloudTrail bucket.

  Why it's wrong here

  S3 Object Lock provides write-once-read-many (WORM) protection, and when combined with a retention mode it prevents objects from being deleted or overwritten until the retention period expires. It does not, however, validate the content of those objects—it will block writes and deletes, but it will not reveal whether an object was modified before the lock was applied or produce any digest that proves current content matches the original. Object Lock is an immutability and retention control, not a cryptographic integrity-verification feature, so it fails to address the core requirement.

Go deeper

Related to this question