DOP-C02 Practice Question 30: Secrets Manager Alternating Users

Single user rotation changes the password of the one database user the secret describes. Secrets Manager documents the consequence: "there is a short period of time between when the password in the database changes and when the secret is updated," and during it the database can deny calls made with the stale credential, which is worse when the client caches for an hour. Alternating users rotation keeps two users and alternates which one is updated, so "if an application retrieves the secret during rotation, the application still gets a valid set of credentials," and after rotation both the user and the clone are valid. The docs call it out as appropriate "for applications that require high availability." Because the rotation function has to clone the user and most users cannot clone themselves, you "must provide the credentials for a superuser in another secret." No application change is needed.

Option A is the documented mitigation for single user rotation, and it does help, but it is exactly the application change the team says it cannot make this release, and it still surfaces failed connections before the retry succeeds.

Option C narrows the window without closing it. The gap is between the database password change and the secret update, so even a client that re-reads the secret every minute can fetch a value that the database has already superseded, and the extra GetSecretValue calls add cost and throttling risk.

Option D gives up managed rotation. Parameter Store has no rotation feature, so the team would own the rotation Lambda function, its staging labels, and its failure handling (more code, not less), and the same single-credential cutover would still cause the failures.

Reference: Lambda function rotation strategies