Secrets Manager and rotation

Lesson 1 of 4 in Secrets, Masking, and Resilience.

A credential that never changes is a credential that will eventually leak and stay useful. AWS Secrets Manager exists to make rotation routine rather than a project, and the exam cares about the rotation mechanics more than the storage.

The storage part is quickly stated: a secret is encrypted with a KMS key — aws/secretsmanager by default, or your own customer managed key when you need the key policy as a second gate or cross-account access. Retrieval is GetSecretValue, authorized by the caller’s IAM policy and, for cross-account access, by a resource policy on the secret itself plus permission on the KMS key. Secrets can be replicated to other Regions, where each replica is encrypted with a key in that Region — the pattern for multi-Region applications and for disaster recovery, because an application in the failover Region must be able to read its database password without calling the impaired Region. And because GetSecretValue is charged per call, the AWS client-side caching libraries matter: fetch once, cache for a sensible interval, and refresh on an authentication failure rather than on every request.

Rotation is where the detail lives. You attach a rotation Lambda function and a schedule; Secrets Manager invokes it with the secret id, a client request token, and a step, and the function must implement four steps in order. createSecret generates the new credential and stores it as a new version labelled AWSPENDING. setSecret changes the credential in the actual service — this is the step that talks to the database and the one that fails if the rotation function lacks privileges. testSecret verifies the pending version actually works, typically by connecting and running a trivial query. finishSecret moves the AWSCURRENT label onto the pending version, which is the atomic cutover: the previous version becomes AWSPREVIOUS and callers of GetSecretValue begin receiving the new value.

Those staging labels are the whole trick. Applications ask for AWSCURRENT — the default when no version is specified — so the swap requires no application change, and because AWSPREVIOUS is retained, a client holding a slightly stale cached value still has a path to recover. For common database targets AWS provides managed rotation, where you do not write or operate a Lambda at all; for everything else you write the function, and the four steps are the contract.

Systems Manager Parameter Store is the alternative the exam always offers, and the distinction is not subtle once you know what to look for.

Parameter Store holds configuration values, and a SecureString parameter is encrypted with a KMS key, retrieved with GetParameter and WithDecryption, and authorized by IAM plus the key policy. Standard parameters are free, advanced parameters are cheap, there is no per-secret monthly charge, and it integrates everywhere in Systems Manager. What it does not have is built-in rotation, no cross-Region replication of values, no resource policy for cross-account sharing (cross-account sharing is done through Resource Access Manager for advanced parameters), and no concept of staging labels.

So the selection rule: if the requirement says rotation, or cross-account access via a resource policy, or multi-Region replication of the secret, or names a database credential that must change on a schedule, the answer is Secrets Manager. If it says configuration, feature flags, AMI ids, or “encrypted parameters at the lowest cost”, the answer is Parameter Store with SecureString. And the pattern that appears in well-built systems: Parameter Store for configuration, Secrets Manager for credentials — with Parameter Store able to reference a Secrets Manager secret so application code has one lookup path.

One more rule that outranks both: an AWS-to-AWS call should use an IAM role, not a stored credential. The exam will offer “store the access keys in Secrets Manager and rotate them” as a plausible-looking distractor when the correct answer is an instance profile, a task role or a service role, with no long-lived key to store at all. Secrets Manager is for the credentials that cannot be roles — database passwords, third-party API keys, certificates and private keys, OAuth client secrets.

Key terms: AWS Secrets Manager, Secret rotation, Staging label (AWSCURRENT, AWSPENDING, AWSPREVIOUS), Rotation function, Parameter Store SecureString

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.