Secrets and credential rotation (Secrets Manager): SCS-C03 study notes and practice questions
What to know about Secrets and credential rotation (Secrets Manager) for the SCS-C03 exam, from the Data Protection domain (18% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe a database password, API key or third-party token that applications need. They ask how to store it, let only the right roles read it, and rotate it without an outage.
Core facts
AWS Secrets Manager stores secrets encrypted with KMS and keeps their versions. You pay per secret per month and per API call.
Rotation runs on a schedule. It uses a Lambda rotation function, or managed rotation for supported databases such as Amazon RDS and Amazon Redshift, where Secrets Manager changes the password for you.
Multi-user rotation keeps two database users and alternates between them, so applications keep working during the change. Single-user rotation can cause brief failures.
Staging labels mark versions. AWSCURRENT is what applications read, and AWSPREVIOUS is the version to roll back to after a bad rotation.
Resource policies on a secret allow cross-account access and can restrict it by principal, VPC endpoint or other condition.
Replication copies a secret to other Regions for disaster recovery.
Parameter Store SecureString encrypts parameters with KMS at lower cost. It has no built-in rotation, so it fits configuration values and static secrets that do not need rotation.
Environment variables, source code and config files are not secret stores. The exam treats them as traps.
How to choose
Scenario wording
Pick
Rotate an RDS database password automatically
Secrets Manager managed rotation
Rotate a custom API key on a schedule
Secrets Manager with a rotation Lambda function
Rotate without application downtime
Multi-user rotation
Let a role in another account read a secret
Secret resource policy, plus access to the customer managed KMS key
Store an encrypted configuration value that never rotates
Parameter Store SecureString
Roll back after a bad rotation
Move the AWSCURRENT label to the version labeled AWSPREVIOUS
Common traps
A secret in an environment variable or a repository file. Have the role fetch the secret from Secrets Manager at runtime.
Cross-account access with a resource policy only. A customer managed KMS key must also allow the other account to decrypt.
Choosing Parameter Store for automatic rotation. It does not rotate secrets.
Assuming rotation fixes a leak. Rotate the secret, then check CloudTrail for use of the old value since the exposure.
Forgetting Regions. A secret exists only in the Region where it was created unless it is replicated.
A retailer order service connects to an Amazon RDS for MySQL database, using credentials stored in AWS Secrets Manager. The security team must rotate the database password every 30 days without downtime, because the service handles checkout around the clock.
The team wants each rotation to create a fresh password while the old one still works, so that instances that have not yet refreshed their connection keep working. The rotation should need no manual steps each month.
Which solution meets these requirements?
Choose one answer.
AA. Use the managed alternating-users rotation strategy on a 30-day schedule. Each rotation updates the user that is not in use, so the other user's password keeps working.
BB. Use the single-user rotation template on a 30-day schedule. The rotation changes the one database user password in place, and the application reads the new value from Secrets Manager on its next call.
CC. Turn off rotation, and have an engineer change the database password by hand every quarter. Update the secret with the new value, and then restart the order service instances to pick it up.
DD. Run a cron job on an EC2 instance that holds the database admin password in its environment. The job changes the password every 30 days, writes it to Secrets Manager, and keeps old passwords in a file for rollback.
Show the answer and explanation
Answer: A
A. Right: Correct. Alternating users keep two valid credentials, and each rotation updates the idle user before the application switches to it, so connections do not break. The schedule runs every rotation without manual steps. Learn more: Rotating secrets in AWS Secrets Manager (opens in a new tab)
B. Wrong: Single-user rotation changes the only password in place, so connections that still use the old value fail until they refresh. The checkout service cannot tolerate that gap, so this option breaks the no-downtime requirement.
C. Wrong: Manual changes need a restart and an outage window, and a quarterly schedule misses the 30-day period. This option fails both the schedule and the no-downtime requirement.
D. Wrong: The job would work, but it keeps an admin credential on a server and in environment variables, and it adds a system to maintain. Secrets Manager rotation already provides the schedule and the change without that exposure.
Explanation
Secrets Manager rotation runs on a schedule, and the alternating-users strategy keeps two valid credentials so the active one never disappears during a change. Single-user rotation and manual changes cause gaps or outages, and a self-run script exposes admin credentials. The alternating-users approach meets the schedule and the no-downtime rule together.
Want more on Secrets and credential rotation (Secrets Manager)? The 5 full-length practice sets have 5 more Secrets and credential rotation (Secrets Manager) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Secrets and credential rotation (Secrets Manager)