DOP-C02 Monitoring and Logging 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 AWS CloudTrail to encrypt the log data before it is sent to CloudWatch Logs.

  Why it's wrong here

  CloudTrail is an API audit service that records who made which call, but it has no role in encrypting payloads written to CloudWatch Logs. While CloudTrail can deliver events to a CloudWatch Logs log group, the encryption of that data is entirely governed by the log group's KMS configuration, not by CloudTrail. Invoking CloudTrail to encrypt log data would neither alter the log group's encryption settings nor add an extra encryption layer, so this approach fails to meet the compliance requirement.

• ✗

  Create a KMS key and apply it to the IAM role used by the application.

  Why it's wrong here

  KMS keys are designed to be used for cryptographic operations by principals granted permission through key policies and IAM policies, but they are not 'applied to' an IAM role to encrypt data on that role's behalf. Attaching a KMS key to the application's IAM role would only authorize that role to call KMS operations such as Encrypt or Decrypt; it would not cause CloudWatch Logs to use that key for encrypting the log group. To achieve encryption at rest, the key must be explicitly associated with the log group itself, because CloudWatch Logs does not infer encryption keys from the identity of the writer.

• ✓

  Create a new KMS customer-managed key and associate it with the CloudWatch Logs log group.

  Why this is correct

  This is the correct solution because CloudWatch Logs supports server-side encryption using a customer-managed KMS key that you can associate directly with the log group. When you create a log group or call the AssociateKmsKey API, you supply the key ARN, and CloudWatch Logs uses that key to encrypt all new incoming log events. This gives you full control over key rotation, access auditing, and lifecycle management, which is exactly what a requirement for customer-managed encryption requires. Note that the key must exist in the same AWS Region as the log group and its key policy must grant CloudWatch Logs permission to generate a data key for encryption.

• ✗

  Enable server-side encryption on the log group using the default CloudWatch Logs key.

  Why it's wrong here

  CloudWatch Logs already encrypts data at rest by default using an AWS-managed key that is automatically assigned to the log group. Choosing the 'default CloudWatch Logs key' does not introduce a customer-managed key and therefore does not satisfy a requirement for customer-controlled encryption. Even if you toggle a setting labeled 'server-side encryption', the log group continues to use the system-managed key, which offers no customer visibility into key usage or the ability to rotate or disable the key independently of AWS.

Go deeper

Related to this question