Secrets Manager stores credentials and can rotate them automatically. Rotation is what makes it valuable over a static config: credentials change on a schedule, so a leak has a bounded lifetime, and applications fetch the current value at runtime rather than embedding it.
Before you start
You should understand IAM roles and runtime configuration. This article covers storage, rotation and retrieval.
Step-by-step walkthrough
Step 1: Store the secret and grant access by role
A secret holds a value such as a database password, and access is granted through an IAM policy to a role, not stored in code. The application assumes a role and reads the secret, so no credential is baked into the image or repository.
Step 2: Rotate with the two-user pattern
For a database, rotation typically uses two users: the current one and a spare. The rotation function creates a new password for the spare, updates the secret, and the application picks it up, then the old user is rotated next time. This lets rotation happen without an outage.
Step 3: Fetch at runtime and cache briefly
The application fetches the secret at startup and refreshes it before expiry, caching for a short window so it does not call the API on every operation. Caching forever defeats rotation, because the app keeps using the old value after it changes.
Worked scenario
The app reads the secret through its role at startup.
import { SecretsManagerClient, GetSecretValueCommand } from '@aws-sdk/client-secrets-manager';
const client = new SecretsManagerClient({});
const { SecretString } = await client.send(
new GetSecretValueCommand({ SecretId: 'prod/db/password' })
);
const { password } = JSON.parse(SecretString);Walk through the example
The call uses the instance or task role’s credentials, so no key is stored, and returns the current password. A rotation updates the secret, and the app refreshes on its cache interval to pick up the new value. Because it fetches rather than embeds, rotation needs no redeploy.
Common mistake
Caching the secret for the lifetime of the process, so after rotation the app still uses the old password and fails. Another is embedding secrets in environment variables or images, which persists them outside the managed store.
Verify the behavior
Confirm the app reads the secret using its role with no stored key. Trigger a rotation and confirm the app picks up the new password within its cache window. Check that the old credential stops working after rotation.
Interview exercise
Why must the app not cache a rotated secret indefinitely?
Answer and reasoning
Because rotation changes the value; if the app holds the old one, it keeps authenticating with a credential that is being retired and will eventually fail. A short cache with periodic refresh balances API calls against freshness, so the app moves to the new value soon after rotation without hitting the API on every request.
Continue learning
Compare secret handling in Roles and temporary credentials and config in Lambda execution. Read the AWS Secrets Manager rotation documentation and try the AWS interview questions.