Secrets Manager & Parameter Store

The plain-language idea

A secret — a database password, an API key, a third-party token — has to live somewhere a running application can fetch it, without ever sitting in source control or a plaintext environment variable that anyone with deploy access (or a misconfigured log line) can read. AWS offers two purpose-built places for this:

• Secrets Manager — stores secrets encrypted, supports automatic rotation (it can call a Lambda on a schedule to generate a new credential and update it in place, e.g. rotating an RDS password without anyone doing it by hand), and costs per secret per month.
• Systems Manager Parameter Store — stores values (plain config or, in its SecureString tier, encrypted secrets) for free at the standard tier, simpler to use, but with no built-in rotation mechanism of its own.

Both solve the same root problem: an application asks for a secret by name at runtime and gets the current value back, instead of the value being baked into code, a config file, or a container image where it's effectively permanent and exposed to anyone who can read that artifact.

See it in a real thing: a Lambda that needs exactly one database password

{
  "Effect": "Allow",
  "Action": ["secretsmanager:GetSecretValue"],
  "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/db/password-AbC123"
}

This is the same least-privilege shape from this track's IAM lesson, applied to secrets specifically: the Lambda's execution role can read exactly this one secret, by its exact ARN — not secretsmanager:*, which would let it read every secret in the account, including ones that belong to entirely unrelated services. Scoping the resource this tightly means a bug or compromise in this function's code can leak at most one credential, not the account's entire secret inventory.

What people usually miss

Watch out

• An environment variable holding a secret is not a secure storage mechanism, even though it's technically outside source control. It's visible to anything that can read the process's environment (a compromised dependency, a debug endpoint that dumps env vars, certain logging misconfigurations) — Secrets Manager and Parameter Store exist specifically so the actual value is fetched at runtime through an access-controlled call, not sitting in plaintext wherever the process happens to run.
• Parameter Store's SecureString tier is genuinely encrypted, not just "less visible." It's a real, valid choice for secrets on a budget or without rotation needs — the free tier isn't a lesser toy version, it's a legitimate tradeoff (no built-in rotation) against Secrets Manager's cost.
• Rotation only actually protects you if the application re-fetches the secret, or the rotation Lambda updates every place that uses it. A rotated database password does nothing if a long-running process cached the old value at startup and never refreshes it — rotation is a mechanism the surrounding system has to be built to cooperate with, not something that fixes itself.
• secretsmanager:* or a wildcard resource is the same anti-pattern here as anywhere else in IAM. Scoping to the exact secret ARN a function actually needs is what makes "least privilege" true in practice rather than a policy that merely gestures at it.

Why this matters in interviews

"Where would you store a database password for a Lambda function, and how would you scope access to it?" tests the same instinct as any IAM question — reaching for a purpose-built, access-controlled secret store scoped to exactly what's needed, rather than an environment variable treated as good enough because it isn't literally committed to git.