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.

• ✗

  Enable CloudWatch Logs data protection and configure a log group policy that blocks retention changes.

  Why it's wrong here

  Data protection policies mask sensitive data in log events; they do not govern retention settings. CloudWatch Logs resource policies control cross-account access, not the ability to call PutRetentionPolicy. Neither mechanism prevents a developer with logs permissions from shortening retention, so this does not meet the requirement.

• ✗

  Set retention on each log group to 400 days using a script, and rely on IAM policies in each account to deny logs:PutRetentionPolicy.

  Why it's wrong here

  A script can set retention, but relying on per-account IAM policies is fragile because new accounts and new roles can be created without the deny. It also does not prevent an administrator in a member account from changing the policy. This lacks the centralized, tamper-resistant enforcement the security team requires.

• ✗

  Create an AWS Lambda function in each account that runs hourly, detects retention changes, and restores 400 days, and subscribe the function to an Amazon SNS topic.

  Why it's wrong here

  A reactive Lambda can correct drift after the fact, but there is a window in which logs could be deleted, and the function itself needs permissions that could be abused. It also must be deployed and maintained per account and does not prevent the change. Preventive controls are required for this compliance scenario.

• ✓

  Apply a service control policy in AWS Organizations that denies logs:PutRetentionPolicy and logs:DeleteRetentionPolicy unless the request comes from a designated governance role, and enforce a baseline retention with AWS Config or a CloudFormation StackSet.

  Why this is correct

  SCPs set the maximum permissions for member accounts, so denying retention changes except for a governance role prevents developers from shortening retention. Combined with a StackSet or Config rule that establishes the 400-day baseline, this gives centralized, drift-resistant enforcement across all accounts, including future ones, which matches the requirement.

Go deeper

Related to this question