DOP-C02 Security and Compliance Practice Question
A company uses AWS Secrets Manager to store database credentials for a legacy application running on an on-premises server. The application retrieves the secret via the AWS SDK. Recently, the database password was rotated in Secrets Manager, but the application continued to use the old password and failed to connect. The application code is correct and uses the latest SDK. The IAM role attached to the server has the secretsmanager:GetSecretValue permission. What is the MOST likely cause?
⚠ Common exam trap
The trap here is assuming that because the SDK is 'latest' and IAM is correct, the problem must be server-side (rotation Lambda or secret ID) — DOP-C02 often tests the client-side caching behaviour of Secrets Manager consumers.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The application is caching the secret and not refreshing it after rotation
The AWS SDK does not automatically re-fetch a secret on every call unless the application explicitly calls GetSecretValue again. Many applications cache the secret in memory (or in a local config) at startup for performance, so after Secrets Manager rotates the credential, the app keeps using the stale value. Since the IAM permission and SDK are correct, the most likely cause is client-side caching without a refresh mechanism.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The IAM role does not have permission to list secrets
Why it's wrong here
The IAM role's permissions are not the issue here. The GetSecretValue API alone is sufficient to retrieve the current secret value and its Stage versions; ListSecrets is only needed for listing metadata across secrets via the console or CLI. If the role were missing GetSecretValue, the application would have failed initial authentication before rotation ever occurred. Because the application functioned before rotation, IAM permissions cannot explain why the old password is still being used after rotation.
- ✗
The application is using the wrong secret ID
Why it's wrong here
If the application were using the wrong secret ID, the very first GetSecretValue call would have failed with a ResourceNotFoundException, and the application would never have connected. Since the application was working before the rotation event, the secret ID is correct and the issue must be temporal—the application is using a previously retrieved secret version. A wrong secret ID would produce a hard failure, not a stale-credential symptom where old credentials still authenticate until rotation invalidates them.
- ✗
The secret rotation Lambda function is failing
Why it's wrong here
If the rotation Lambda function had failed, the secret would retain its previous version with the old password as the current AWSCURRENT version, so the application's existing credentials would continue to work. The observed failure is that the new password is not being used, which implies rotation succeeded and generated a new AWSCURRENT version—otherwise the old password would still be valid. Therefore the problem is not the rotation function itself, but the application's client-side caching of the secret value across the rotation boundary.
- ✓
The application is caching the secret and not refreshing it after rotation
Why this is correct
The AWS SDK and AWS Secrets Manager client-side caching libraries cache secret values in memory with a default TTL (e.g., 1 hour in Java) to reduce API calls. After rotation, the cached entry still holds the old AWSCURRENT value, and the application will keep using it until the cache expires or an explicit cache refresh is triggered. To fix this, the application must implement rotation-aware behavior, such as forcing a cache reload on authentication failure, shortening the TTL, or using the cached secret's version ID and comparing it to the newly fetched AWSCURRENT version. Without refreshing, the application is pinned to the pre-rotation secret indefinitely within the cache window.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company uses AWS Secrets Manager to store database credentials. The security team wants to automatically rotate secrets every 30 days. The database is an Amazon RDS for PostgreSQL instance. The team has configured automatic rotation with a Lambda function that updates the password in RDS and Secrets Manager. However, after the first rotation, the application starts getting database connection errors. The application uses a connection string with the secret ARN and retrieves the secret from Secrets Manager at startup using the AWS SDK. Which of the following is the most likely cause of the connection errors?
easy- A.The Lambda function is not configured with a sufficient timeout and is being throttled.
- ✓ B.The application caches the secret at startup and does not refresh it after rotation.
- C.The Lambda function does not have permission to update the secret in Secrets Manager.
- D.The RDS instance has automatic password rotation enabled, which conflicts with Secrets Manager rotation.
Why B: If the application caches the secret at startup, it will not retrieve the updated password after rotation, causing connection errors. Option A is incorrect because a Lambda timeout or throttling would prevent the rotation from completing, but the rotation succeeded (new password set), so the issue is on the application side. Option C is incorrect because if the Lambda lacked permissions to update the secret, the rotation would have failed entirely, not just after the first rotation. Option D is incorrect because Amazon RDS does not have built-in automatic password rotation; Secrets Manager manages the rotation, so there is no conflict.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.