What is AWS Secrets Manager? A plain-English explainer
AWS Secrets Manager is a managed AWS service that securely stores secrets — things like database credentials, API keys and other tokens an application needs to authenticate with — and lets applications retrieve them at runtime instead of having them hard-coded or dropped into a config file. It can also rotate those secrets on a schedule, so a credential does not sit unchanged indefinitely. Retrieval is controlled through the same permissions model that governs everything else in an AWS account, so only the applications and people you explicitly allow can read a given secret. Secrets Manager exists because “where do we put the password” is a problem every application has, and the easy answers — commit it to the repo, paste it into an environment file, email it to a teammate — are exactly how credentials leak. Here is the problem it solves, what it actually does, and how it differs from a service it is often confused with.
The problem: secrets in code are a security risk
A “secret” is any value that grants access if someone else gets hold of it — a database password, a third-party API key, a signing token. The most common way secrets go wrong is that they end up somewhere too many people or systems can see them: hard-coded in source, checked into version control, sitting in a plaintext config file on a server. Once a secret is in a code repository, it is effectively permanent — even deleting it later does not remove it from history — and once it is on a server’s disk, anyone who can read that disk can read it.
The fix is to keep secrets out of code entirely and fetch them from a dedicated store at the moment an application actually needs them. That store then becomes the one place secrets live, the one place access is controlled, and the one place rotation happens — instead of every application inventing its own answer.
What Secrets Manager actually does
Secrets Manager gives you a central place to store secrets and retrieve them by name through an API call, rather than reading them from a file or an environment variable baked into a deployment. Access to a given secret is controlled the same way access to any other AWS resource is controlled: through AWS IAM policies. Our what-is-aws-iam explainer covers how that permissions model works — the short version here is that an application only gets a secret if its IAM role explicitly allows it.
Secrets stored in Secrets Manager are encrypted, and the service handles that encryption for you rather than asking you to manage it yourself — see our what-is-encryption-in-the-cloud explainer for how encryption at rest generally works in the cloud.
Automatic rotation, conceptually
Beyond storage, Secrets Manager can automatically rotate a secret — generating a new value and updating it wherever it is used — on a schedule you configure, rather than leaving the same credential in place indefinitely. For a database password, this typically works through a small piece of rotation logic that changes the password on the database itself and updates the stored secret to match, so applications that fetch the secret each time automatically pick up the new value.
This matters because a credential that never changes is a credential that, if it ever leaks quietly, stays useful to whoever took it for as long as nobody notices. Rotation limits how long a compromised secret stays valid.
Secrets Manager versus AWS KMS
These two services are often mentioned together and easily confused, but they solve different problems. AWS KMS manages encryption keys — the cryptographic keys used to encrypt and decrypt data across AWS. Secrets Manager manages the secrets themselves — the actual credential values — and, under the hood, uses a KMS key to encrypt them. Our what-is-aws-kms explainer covers KMS in its own right.
Put simply: KMS is about the keys that lock things; Secrets Manager is about one specific thing worth locking — application credentials — plus the retrieval and rotation workflow built around it.
Common uses
Secrets Manager typically shows up wherever an application needs a credential it should never expose:
- Database credentials — applications retrieve the current password at connection time instead of storing it in config.
- Third-party API keys — payment processors, mapping services and other external APIs that need a key kept out of source code.
- Cross-service authentication — one internal service authenticating to another without a hard-coded shared secret.
- Scheduled credential rotation — automatically changing database passwords on a regular cycle without redeploying applications.
Where Secrets Manager appears in certification study
Secrets Manager is a recurring topic on AWS Certified Security – Specialty, which expects a clear grasp of secure secret storage, rotation and the IAM permissions that gate access to a secret. It also appears on AWS Certified Developer – Associate and AWS Certified Solutions Architect – Associate, where the focus is more on retrieving secrets from application code correctly rather than the deeper security design. Our /revision study library covers that depth lesson by lesson.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.