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.

• ✗

  Use SSE-C with a customer-provided key when uploading logs to S3.

  Why it's wrong here

  SSE-C (server-side encryption with customer-provided keys) is not supported by CloudTrail for log delivery. With SSE-C, you must provide an encryption key with each individual S3 PUT request, but CloudTrail delivers logs automatically as a managed service—it has no interface for you to supply per-object keys on its behalf. Additionally, SSE-C requires you to maintain the key for every subsequent GET/decrypt operation, which is impractical for logs that are continuously written by CloudTrail and later accessed by multiple AWS services such as Athena or detective controls.

• ✗

  Enable client-side encryption before delivering logs to S3.

  Why it's wrong here

  Client-side encryption would require encrypting log files before they are ever sent to S3, but CloudTrail itself generates and delivers the log files—you never upload them, so you have no opportunity to apply client-side encryption at the point of delivery. Even if you tried to set up a process to encrypt files afterward, CloudTrail would already have stored them unencrypted in S3, violating the requirement to encrypt the delivered logs with a customer-managed key. Moreover, native CloudTrail features like the console log viewer and Athena integration rely on the raw log format, which client-side encryption would break.

• ✗

  Enable default encryption on the S3 bucket using SSE-S3.

  Why it's wrong here

  Enabling default SSE-S3 encryption on the S3 bucket does encrypt CloudTrail log files, but it uses S3-managed keys (SSE-S3), not a customer-managed key. The scenario requires the ability to control and manage the encryption key, which SSE-S3 lacks because AWS owns and manages those keys. While CloudTrail will honor the bucket's default SSE-S3 settings, doing so does not meet the customer-managed key requirement—only SSE-KMS with a customer-managed CMK satisfies that control.

• ✓

  Specify a KMS key ID in the CloudTrail trail configuration and grant CloudTrail permissions to use the key.

  Why this is correct

  CloudTrail natively supports SSE-KMS: you configure the trail by specifying a KMS key ID (e.g., arn:aws:kms:region:account:key/key-id) and you must also grant CloudTrail the required permissions via the KMS key policy—specifically kms:GenerateDataKey and kms:Decrypt on the key. This lets CloudTrail encrypt each log file with a customer-managed AWS KMS key, giving you full lifecycle control, auditability, and the ability to disable or rotate the key as needed. Unlike SSE-S3 or SSE-C, this is the only option that both supports automated delivery and uses a customer-managed key.

Go deeper

Related to this question