DOP-C02 Security and Compliance 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.

• ✗

  Server-side encryption (SSE-S3)

  Why it's wrong here

  Server-side encryption (SSE-S3) scrambles object contents at rest using S3-managed keys, which protects data confidentiality by preventing unauthorized parties from reading the logs. However, confidentiality and integrity are separate security goals: encryption provides no cryptographic hash or signature that lets you detect whether the log files have been modified, reordered, or sliced after they were written. An attacker with permission to write could still overwrite a log object with new encrypted content, and SSE-S3 would give you no way to notice that the data was replaced.

• ✓

  CloudTrail log file integrity validation

  Why this is correct

  CloudTrail log file integrity validation is purpose-built for exactly this need: it delivers signed digest files to your S3 bucket that cover the log files and link together in a hash chain. Each digest contains the SHA-256 hash of the prior digest and the current log files, and is signed with a private key by CloudTrail. You can use the corresponding public key to verify both the authenticity and the integrity of the logs, which lets you detect any modification, deletion, or forgery. Enabling this feature ensures that your audit trail itself is trustworthy, which is a key defense against attackers trying to cover their tracks by altering logs.

• ✗

  S3 Object Lock

  Why it's wrong here

  S3 Object Lock provides WORM (Write Once Read Many) protection by applying a retention mode and period that blocks object overwrite and delete requests. While this can prevent tampering after the lock is applied, it does not verify that the current object content is the same as what was originally written—there is no digest, hash, or signature generated that you can independently check. Furthermore, if an object is written without a lock or before the retention period is configured, it can still be modified, and Object Lock alone will not alert you to that change. It is a prevention control, not an integrity verification mechanism.

• ✗

  MFA delete on the S3 bucket

  Why it's wrong here

  MFA delete is an S3 versioning feature that requires a second factor of authentication before a caller can permanently delete an object version or suspend versioning on the bucket. This reduces the risk of accidental or unauthorized deletion, but it does nothing to detect or prevent modifications to the log content itself. An authorized user with valid credentials and multi-factor authentication can still overwrite an existing log object, because MFA delete only gates delete operations, not put or post operations. It provides administrative protection, but not data integrity assurance.

Go deeper

Related to this question