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.

• ✗

  Disable automatic rotation for the old secret version.

  Why it's wrong here

  In AWS Secrets Manager, rotation is a property of the secret resource itself, not of an individual secret version, so 'disabling automatic rotation for the old secret version' is not a supported operation. When a new version is created during rotation, the AWSCURRENT label automatically moves to the new version and the previous version becomes AWSPREVIOUS; you cannot selectively block that label transition for a single version. Disabling rotation on the secret entirely would leave database credentials static, defeating the entire purpose of automated rotation and exposing the environment to compromised credential risk.

• ✓

  Set up CloudWatch alarms to monitor rotation failures.

  Why this is correct

  Setting up CloudWatch alarms on the Secrets Manager rotation Lambda function's failure metrics or on the RotationFailed event (via Amazon EventBridge and CloudTrail) is essential because rotation failures can occur silently without directly impacting the application. If a failure goes unnoticed, the secret may remain stale for an extended period; more critically, the Lambda might have created and stored a new version but failed to promote it to AWSCURRENT, leaving the database and Secrets Manager in an inconsistent state. An alarm ensures administrators are notified quickly to prevent both stale credential burnout and potential data-plane outages.

• ✓

  Use a separate database user for rotation that has permissions to change passwords.

  Why this is correct

  Using a dedicated database user for rotation that has only the required privilege, such as ALTER USER or the equivalent, allows the Lambda function to change the application user's password without relying on the application user itself. This separation preserves least privilege because the rotation user never grants broad administrative rights to the application, and it avoids disrupting active sessions that are already using the old credential because the application's own user is not being altered mid-session. Without a dedicated rotation user, the function would need unnecessarily broad database permissions or would fail when trying to update the credential.

• ✗

  Configure the Lambda rotation function to use a VPC endpoint for Secrets Manager.

  Why it's wrong here

  Configuring the Lambda rotation function to use a VPC endpoint for Secrets Manager is a networking detail, not a required rotation action. The function can reach the Secrets Manager API over the public endpoint if it is not attached to a VPC, or through a NAT gateway if it is in a private subnet; a VPC endpoint merely changes the network path and does not affect rotation logic or permissions. Adding a VPC endpoint therefore neither prevents rotation failures nor improves security posture for the rotation process itself, so it is not an appropriate answer to this question.

• ✓

  Grant the Lambda rotation function IAM permissions to read and update the secret.

  Why this is correct

  The Lambda rotation function must be granted IAM permissions, typically through the service-linked role created by Secrets Manager, to call secretsmanager:GetSecretValue and secretsmanager:PutSecretValue on the target secret, along with the necessary AWS KMS permissions such as kms:Decrypt and kms:GenerateDataKey to read and encrypt the secret. Without these IAM permissions, the Lambda function will fail at the first step of rotation because it cannot retrieve the current secret or store the newly generated one, and it definitely cannot move the AWSCURRENT label to finish rotation. Granting least-privilege IAM permissions for read and update of the secret is a mandatory part of enabling automatic rotation.

Go deeper

Related to this question