The Data Protection domain is worth roughly 18% of the AWS Certified Security – Specialty (SCS-C02) exam, and inside it “key management and secrets management” is an objective that hides one of the exam’s most reliable question patterns: You need to store a database password / API key / OAuth token securely — which service, and how do you rotate, encrypt, and share it? The two candidate services are AWS Secrets Manager and AWS Systems Manager Parameter Store, and the exam expects you to choose between them for reasons, not by habit.
This guide treats that choice mechanically. By the end you’ll be able to read a scenario, decide whether it calls for Secrets Manager or Parameter Store, and justify the decision with the three levers the exam actually tests: automatic rotation, encryption with KMS, and access control (including cross-account sharing). It’s a deep dive on the secrets portion of the Data Protection domain — pair it with the KMS and data protection guide for the encryption half, and the IAM deep dive for the policy mechanics that gate both services.
Why These Two Services Exist
Both services solve the same core problem: keep configuration and credentials out of your application code, AMIs, and environment variables, where they leak into logs, source control, and snapshots. Both encrypt data at rest, integrate with IAM, and are called by an SDK at runtime. The exam’s job is to make you articulate where they diverge.
The one-line summary to anchor everything else:
Parameter Store is a general-purpose configuration store that can also hold secrets. Secrets Manager is a purpose-built secrets store whose headline feature is built-in, managed rotation.
Everything else — cost, size limits, cross-account behavior — flows from that difference in purpose.
The Comparison the Exam Leans On
| Property | Secrets Manager | Parameter Store (SSM) |
|---|---|---|
| Primary purpose | Secrets storage + lifecycle | Configuration + secrets |
| Automatic rotation | Built-in, Lambda-backed | Not native (roll your own) |
| Encryption at rest | Always KMS-encrypted | Only for SecureString type |
| Cost | Per secret + per API call | Standard tier free; Advanced tier paid |
| Max value size | 64 KB | 4 KB (Standard) / 8 KB (Advanced) |
| Cross-account access | Resource policy on the secret | Advanced tier + resource sharing patterns |
| Native RDS/Redshift/DocumentDB integration | Yes, managed rotation | No |
| Generate random secret | get-random-password API | No |
| Hierarchical paths | Limited | Yes (/app/prod/db/password) |
Two rows decide the majority of questions:
Rotation. If a scenario mentions automatic, scheduled, or managed credential rotation — especially for an RDS, Aurora, Redshift, or DocumentDB database — the answer is Secrets Manager. It ships with rotation built in and provides ready-made Lambda rotation functions for the supported databases. Parameter Store has no native rotation; you’d have to build and schedule your own Lambda, which is exactly the “operational overhead” the exam wants you to avoid.
Cost. Parameter Store’s Standard tier is free (subject to a throughput limit and 10,000-parameter cap). Secrets Manager charges per secret per month plus per 10,000 API calls. When a question emphasizes cost-effectiveness for storing plain configuration or a secret that doesn’t need rotation, Parameter Store is usually the intended answer.
Encryption at Rest: The KMS Connection
This is Data Protection, so encryption is never far away. Both services lean on AWS KMS, but the defaults differ in an exam-relevant way.
- Secrets Manager always encrypts. Every secret is encrypted with a KMS key — either the AWS-managed
aws/secretsmanagerkey or a customer managed key (CMK) you choose. There is no “unencrypted secret.” - Parameter Store only encrypts
SecureStringparameters. AStringorStringListparameter is stored in plaintext. To encrypt, you create the parameter as typeSecureString, which uses KMS (the AWS-managedaws/ssmkey by default, or a CMK).
The exam-critical nuance: retrieving an encrypted value requires two permissions working together — the service action (secretsmanager:GetSecretValue or ssm:GetParameter) and the KMS action kms:Decrypt on the key that protects the value. A caller with GetParameter but no kms:Decrypt on the CMK gets an AccessDenied from KMS when reading a SecureString. This “the IAM policy looks right but the call still fails” scenario is a favorite distractor.
# Store an encrypted parameter with a customer managed key
aws ssm put-parameter \
--name "/app/prod/db/password" \
--value "S3cr3t!" \
--type SecureString \
--key-id alias/app-cmk
# Reading it requires ssm:GetParameter AND kms:Decrypt on alias/app-cmk
aws ssm get-parameter \
--name "/app/prod/db/password" \
--with-decryptionFor CMKs, using a customer managed key (rather than the AWS-managed one) is what lets you write a key policy that scopes exactly who can decrypt — and it’s required for cross-account decryption. If a scenario needs auditable, tightly controlled decrypt permissions, the answer includes a CMK.
Automatic Rotation: Secrets Manager’s Signature Feature
Rotation is the single biggest reason to reach for Secrets Manager, and the exam tests the mechanics, not just the name.
How managed rotation works for a supported database:
- You enable rotation on the secret and set a schedule (e.g., every 30 days).
- Secrets Manager invokes a Lambda rotation function (AWS provides these for RDS, Aurora, Redshift, DocumentDB).
- The function runs a four-step state machine:
createSecret→setSecret→testSecret→finishSecret. - New credentials are staged under the
AWSPENDINGlabel, applied to the database, tested, then promoted toAWSCURRENT.
# Enable 30-day rotation on an RDS credential secret
aws secretsmanager rotate-secret \
--secret-id prod/db/mysql \
--rotation-lambda-arn arn:aws:lambda:us-east-1:111122223333:function:SecretsManagerMySQLRotation \
--rotation-rules AutomaticallyAfterDays=30Two rotation strategies you should be able to distinguish:
- Single-user rotation — the same user’s password is changed in place. Simpler, but there’s a brief window during rotation where an in-flight connection could see the old credential.
- Alternating-users rotation — Secrets Manager alternates between two users (each rotation clones and updates the other user), which avoids downtime for high-availability workloads. This requires a “superuser” secret that has permission to manage the two application users.
If a question stresses zero-downtime rotation for a production database, alternating-users is the intended design. Applications should always fetch the secret from Secrets Manager at connect time (not cache it forever) so they pick up rotated credentials automatically.
Access Control and Cross-Account Sharing
Both services gate access with IAM identity policies. The exam’s harder questions are about cross-account access, where the two services behave differently.
Secrets Manager supports resource policies. You can attach a resource-based policy directly to a secret, granting a principal in another account permission to read it. Combined with a KMS key policy that lets the same external principal kms:Decrypt, this is the clean, managed pattern for sharing a secret across accounts:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::444455556666:role/AppRole" },
"Action": "secretsmanager:GetSecretValue",
"Resource": "*"
}]
}The rule to memorize: cross-account secret access needs both a resource policy on the secret and a grant on the CMK — and the CMK must be a customer managed key, because you cannot modify the policy of an AWS-managed key. Miss either half and the call fails.
Parameter Store cross-account is more limited. Standard-tier parameters don’t support resource policies the way Secrets Manager does; sharing across accounts typically involves the Advanced parameter tier and cross-account resource sharing patterns, or an assumed cross-account role. When an exam scenario needs straightforward, policy-based cross-account secret sharing, that requirement tilts the answer toward Secrets Manager.
For a refresher on how identity policies, resource policies, and permission boundaries evaluate together — the machinery behind both services — the IAM policy evaluation deep dive walks the full decision flow.
Auditing and Monitoring
Data Protection connects to the Security Logging and Monitoring domain, and secrets are a prime audit target.
- CloudTrail logs every access.
GetSecretValueandGetParametercalls are recorded as management/data events, so you can answer “who read this secret and when.” Alerting on unexpectedGetSecretValuefrom an unusual principal is a common detective control. - Secrets Manager emits rotation events you can route through EventBridge — for example, to alert when a rotation fails.
- Unused-secret detection. Secrets Manager reports a
LastAccessedDate, letting you find and remove stale secrets — a governance point the exam sometimes references.
When to Choose Which: A Decision Cheat Sheet
| Scenario cue | Choose |
|---|---|
| Automatic/managed rotation of DB credentials | Secrets Manager |
| Native RDS / Aurora / Redshift / DocumentDB integration | Secrets Manager |
| Cross-account secret sharing via resource policy | Secrets Manager |
| Generate a strong random password via API | Secrets Manager |
| Store plain application config (URLs, feature flags) | Parameter Store (String) |
| Store a secret cheaply, no rotation needed | Parameter Store (SecureString) |
Hierarchical config by environment (/prod/...) | Parameter Store |
| Value larger than 8 KB | Secrets Manager (64 KB limit) |
| Reference secrets/params from CloudFormation | Both (dynamic references) |
A useful integration note the exam occasionally probes: Parameter Store can reference a Secrets Manager secret. You can create an SSM parameter whose value is a secretsmanager reference, letting tools that speak Parameter Store transparently read a managed, rotated secret. This is the “best of both” pattern — Parameter Store’s simple interface, Secrets Manager’s rotation.
Common Mistakes on This Topic
| Mistake | Reality |
|---|---|
| Using Parameter Store for rotating RDS credentials | Native managed rotation is a Secrets Manager feature |
| Assuming all Parameter Store values are encrypted | Only SecureString is KMS-encrypted; String/StringList are plaintext |
Granting only GetSecretValue for an encrypted read | You also need kms:Decrypt on the protecting key |
| Sharing a secret cross-account with just a resource policy | You also need a CMK grant (AWS-managed keys can’t be shared) |
| Caching a secret forever in the app | Fetch at connect time so rotated credentials are picked up |
| Choosing Secrets Manager for cheap static config | Parameter Store Standard tier is free — better for non-rotating config |
| Thinking rotation is instant/atomic | It’s a staged AWSPENDING → AWSCURRENT state machine; design for the window |
Conclusion
The Secrets Manager vs. Parameter Store decision is one of the most predictable points on the SCS-C02 exam, and it comes down to a short list of levers. Reach for Secrets Manager when you need managed rotation, native database integration, larger values, random-secret generation, or resource-policy-based cross-account sharing. Reach for Parameter Store when you’re storing configuration or a non-rotating secret cost-effectively, want hierarchical paths, or need the free Standard tier. Layer the KMS reality on top of both — Secrets Manager always encrypts, Parameter Store encrypts only SecureString, and reads of encrypted values need kms:Decrypt in addition to the service action.
Get those distinctions cold and the questions become pattern-matching: spot the cue words (rotation, cost, cross-account, RDS), map them to the right service, and confirm the encryption and access-control details line up.
Practice Until the Choice Is Automatic
Reading a comparison table builds the model; answering timed, scenario-based questions is what makes the right service jump out on exam day. The traps in this topic — the missing kms:Decrypt, the “we need rotation” cue, the cross-account grant — only become second nature when you’ve seen them repeatedly under exam conditions.
Sailor.sh’s AWS Security Specialty mock exam bundle is built around the real SCS-C02 domain weights, so Data Protection gets the emphasis its 18% deserves — every question ships with an explanation of why an answer is right, not just which option to choose. Benchmark yourself with the free SCS-C02 practice questions, map your full prep with the SCS-C02 study plan, and see how this topic connects to the rest of the blueprint in the AWS Security Specialty domains breakdown and the complete SCS-C02 exam guide for 2026.
Frequently Asked Questions
What is the main difference between AWS Secrets Manager and Parameter Store?
Secrets Manager is a purpose-built secrets store whose signature feature is built-in automatic rotation (with managed Lambda functions for RDS, Aurora, Redshift, and DocumentDB), and it always encrypts values with KMS. Parameter Store is a general-purpose configuration store that can also hold secrets; it has no native rotation, and only SecureString parameters are encrypted. Parameter Store’s Standard tier is free, while Secrets Manager charges per secret and per API call.
When should I use Parameter Store instead of Secrets Manager?
Use Parameter Store when you’re storing application configuration (URLs, feature flags, non-rotating values) cost-effectively, want hierarchical paths like /app/prod/db/host, or need the free Standard tier. It’s the better choice whenever a scenario emphasizes cost and the secret does not require automatic rotation or native database integration.
Does Parameter Store encrypt values automatically?
No. Only parameters created with the SecureString type are encrypted with KMS. String and StringList parameters are stored in plaintext. To read a SecureString you need both ssm:GetParameter and kms:Decrypt on the protecting key, and you pass --with-decryption to get the plaintext value.
How does automatic rotation work in Secrets Manager?
You enable rotation with a schedule, and Secrets Manager invokes a Lambda rotation function that runs a four-step state machine — createSecret, setSecret, testSecret, finishSecret — staging new credentials under the AWSPENDING label and promoting them to AWSCURRENT once tested. For supported databases, AWS provides ready-made rotation functions, and alternating-users rotation enables zero-downtime credential changes for high-availability workloads.
How do I share a secret across AWS accounts?
Attach a resource-based policy to the secret in Secrets Manager granting the external principal secretsmanager:GetSecretValue, and use a customer managed KMS key with a key policy (or grant) that lets that same principal kms:Decrypt. Both halves are required — the AWS-managed key cannot be shared, so cross-account access always involves a CMK.
Is Secrets Manager or Parameter Store more likely to be the exam answer?
It depends entirely on the cue words. If the scenario mentions automatic/managed rotation, native RDS/Redshift integration, cross-account resource-policy sharing, or generating a random password, choose Secrets Manager. If it stresses cost-effectiveness for configuration or a non-rotating secret, hierarchical paths, or the free tier, choose Parameter Store. The exam rewards matching the requirement to the feature, not a blanket preference.
Ready to make Data Protection a strength? Drill realistic, explained questions with the Sailor.sh SCS-C02 mock exams, then map your full prep with the AWS Security Specialty exam guide for 2026.