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.

• ✓

  Enable automatic rotation in Secrets Manager with a rotation interval of 30 days.

  Why this is correct

  Secrets Manager automatically rotates the secret on a schedule you define (e.g., 30 days) using a built-in Lambda template tailored to your database engine, such as RDS for PostgreSQL or MySQL. Because the rotation orchestration—including updating the secret and testing it against the database—is handled entirely by the service, you avoid writing or maintaining custom code and scheduling components. This gives you a fully managed, auditable rotation process with no operational overhead beyond configuring the interval.

• ✗

  Store the credentials in Systems Manager Parameter Store and use a scheduled automation to update them.

  Why it's wrong here

  While Systems Manager Parameter Store can securely store secrets as SecureString parameters, it provides no native rotation mechanism; you would need to implement a periodic update via a custom Automation runbook or a scheduled Lambda, including manually changing the database account password before updating the parameter. This design tightly couples secret management to your own automation scripts, which must handle retries, validation, and rollback—unlike Secrets Manager's built-in rotation templates that address these concerns out of the box. Furthermore, Parameter Store is intended for general configuration data, so it lacks specialized lifecycle features such as automatic resource-based permissions and integration with database secrets that Secrets Manager provides.

• ✗

  Create a CloudWatch Events rule that triggers a Lambda function to rotate the secret.

  Why it's wrong here

  While CloudWatch Events can invoke a Lambda function, Secrets Manager natively supports automatic rotation with a built-in Lambda template, making an external rule unnecessary. This option is tempting because CloudWatch Events is commonly used to schedule periodic tasks, such as invoking a Lambda for custom maintenance jobs, where native rotation is unavailable.

• ✗

  Write a custom Lambda function that rotates the secret and schedule it with CloudWatch Events.

  Why it's wrong here

  A custom Lambda function with CloudWatch Events introduces unnecessary complexity and maintenance overhead when Secrets Manager’s built-in rotation capability, configured with a 30-day schedule, directly satisfies the requirement without custom code. This approach is tempting because Lambda is a general-purpose compute service often used for custom automation tasks, and it would be correct if the rotation logic required proprietary steps unsupported by Secrets Manager’s native rotation templates.

Go deeper

Related to this question