What is the difference between AWS Secrets Manager and Parameter Store?

AWS Secrets Manager is purpose-built for sensitive secrets that must be rotated, replicated across Regions, or shared across AWS accounts. It always encrypts values with AWS KMS and provides built-in automatic rotation for Amazon RDS, Redshift, DocumentDB, and Neptune databases. AWS Systems Manager Parameter Store is a general-purpose configuration store that can also hold secrets — but it has no native rotation capability and only encrypts values when you use the SecureString parameter type. Parameter Store's Standard tier is free; Secrets Manager costs $0.40 per secret per month.

When should I use Secrets Manager instead of Parameter Store?

Use Secrets Manager when the scenario requires: (1) automatic credential rotation — Secrets Manager has built-in Lambda rotation templates for RDS, Redshift, DocumentDB, Neptune, and MongoDB Atlas; (2) sharing a secret across multiple AWS accounts via a resource-based policy; (3) replicating a secret to multiple AWS Regions for multi-region architectures; or (4) strict compliance requiring every stored credential to be encrypted at rest without exception. If none of these apply and you just need to store an API endpoint or feature flag, Parameter Store is simpler and free.

Does AWS Parameter Store support automatic rotation?

No. AWS Systems Manager Parameter Store has no built-in rotation capability. You can rotate a SecureString parameter manually by updating its value, or you can write a custom AWS Lambda function that updates the parameter on a schedule — but you are responsible for building and maintaining that rotation logic. Secrets Manager, by contrast, ships pre-built Lambda rotation templates for the most common database engines and handles the full dual-version rotation lifecycle automatically.

Is AWS Secrets Manager free?

No. AWS Secrets Manager charges $0.40 per secret per month plus $0.05 per 10,000 API calls. The Lambda function that powers automatic rotation adds a small additional cost (typically under $0.01/month per secret at standard rotation intervals). AWS Systems Manager Parameter Store is free for Standard tier parameters (up to 10,000 parameters, 4 KB each). Advanced tier parameters cost $0.05 per parameter per month.

What is a SecureString parameter in AWS Parameter Store?

A SecureString is the encrypted variant of an AWS Systems Manager Parameter Store parameter. When you create a SecureString, Parameter Store uses AWS KMS to encrypt the value at rest and decrypt it on retrieval. The other two parameter types — String and StringList — are stored in plaintext. On the SAA-C03 and DVA-C02, whenever a scenario mentions storing a password or API key in Parameter Store, the correct parameter type is SecureString. Important: even SecureString parameters cannot be rotated automatically — that still requires a custom Lambda function.

Which service should I use for storing database passwords on the SAA-C03?

The SAA-C03 exam answer depends on whether rotation is required. If the scenario says the password must rotate automatically (every 30 days, every 90 days, on a schedule), the correct answer is always AWS Secrets Manager — it provides built-in rotation for RDS, Redshift, DocumentDB, and Neptune without any custom code. If the scenario describes storing a database password but does not mention rotation, and cost-efficiency is a concern, Parameter Store SecureString is an acceptable answer. The rotation requirement is the primary signal — it is present in roughly 70% of Secrets Manager questions on the exam.

AWS Secrets Manager vs. Parameter Store: The Security Decision the SAA-C03 and DVA-C02 Both Test

Here is an exam scenario you will see on the SAA-C03:

A company runs a web application that connects to an Amazon RDS MySQL database. The security team requires that database credentials be rotated automatically every 90 days without any application downtime or code changes. Where should the credentials be stored?

Four answer choices: AWS Systems Manager Parameter Store. AWS Secrets Manager. AWS Key Management Service. Amazon S3 with server-side encryption.

The correct answer is AWS Secrets Manager — but only because of the word "automatically." Parameter Store can store the same credentials. KMS encrypts them but doesn't store them. S3 is not a secret-management service. The rotation requirement is what eliminates Parameter Store and makes Secrets Manager the only valid choice.

AWS Secrets Manager and Systems Manager Parameter Store look identical at first glance — both store key-value pairs, both integrate with AWS KMS, both are accessed via IAM, and both appear constantly on the SAA-C03 and DVA-C02. The exam exploits exactly this surface similarity to set traps. This guide gives you the mental model, the decision rules, and the exact signal words to answer every question correctly.

What AWS Secrets Manager Does

AWS Secrets Manager is a fully managed service for storing and rotating secrets — database credentials, API keys, OAuth tokens, SSH keys, and any credential that must remain confidential and that can be compromised if it stays static for too long.

How it works:

Secrets Manager stores each secret as a JSON key-value object (for example, {"username":"admin","password":"xkJ9!mQ3"}) or a plain string. Every secret is encrypted with AWS KMS — this is not optional. You must associate a KMS key with each secret, and Secrets Manager uses that key to encrypt the secret value at rest and decrypt it on each retrieval via GetSecretValue.

Automatic rotation:

The defining feature of Secrets Manager is its built-in automatic rotation. For supported databases — Amazon RDS (MySQL, PostgreSQL, Oracle, and SQL Server), Amazon Redshift, Amazon DocumentDB, Amazon Neptune, and MongoDB Atlas — Secrets Manager deploys a pre-built Lambda rotation function and schedules it to run at the interval you specify (daily, weekly, every 90 days, etc.). The rotation function creates a new credential version, updates it in the database, validates it, and only then marks the old version inactive. Your application code calls GetSecretValue on the same secret ARN — it gets the current active credential without any changes to your application.

For non-database secrets (third-party API keys, SSH keys, custom credentials), Secrets Manager provides a Lambda function template you extend with your own rotation logic.

Pricing:

$0.40 per secret per month
$0.05 per 10,000 API calls to Secrets Manager
Lambda rotation invocations are billed separately but cost under $0.01/month at typical rotation intervals

Cross-account and multi-region:

Secrets Manager supports resource-based policies attached directly to a secret. This means you can grant an IAM role in account B permission to call GetSecretValue on a secret in account A — without any intermediate infrastructure. For multi-region architectures, Secrets Manager can replicate a primary secret to secondary Regions automatically, keeping the replica in sync when the primary rotates.

What AWS Systems Manager Parameter Store Does

AWS Systems Manager Parameter Store is a hierarchical configuration store. It was built for application configuration — feature flags, database connection strings, service endpoints, environment names, license keys — and it handles secrets as a secondary capability through its SecureString type.

The three parameter types:

String — plaintext value, unencrypted at rest. Use for non-sensitive configuration like environment names, S3 bucket names, or region identifiers.
StringList — a comma-separated list of strings, also unencrypted. Use for lists of values your application needs to iterate.
SecureString — the value is encrypted with AWS KMS before storage and decrypted on retrieval. Use for passwords, API keys, and any value that must be protected at rest. On the SAA-C03 and DVA-C02, SecureString is always the correct choice when a question asks about storing sensitive values in Parameter Store.

Tier limits:

Tier	Max parameters	Max value size	Cost
Standard	10,000	4 KB	Free
Advanced	100,000	8 KB	$0.05/parameter/month

Standard tier handles the vast majority of real-world use cases. If a scenario mentions hundreds of thousands of parameters or values larger than 4 KB, it is signaling the Advanced tier.

Hierarchical naming:

Parameter Store names are path-like: /app/prod/db/password, /app/prod/api/endpoint. You can retrieve all parameters under a path in one API call (GetParametersByPath), which is useful for loading an entire application's configuration at startup. Secrets Manager has no equivalent path structure — each secret has its own ARN.

What Parameter Store does not do:

Parameter Store has no built-in rotation. If you store a database password as a SecureString and need it to rotate, you write a Lambda function and schedule it with EventBridge yourself. The moment "automatic rotation" appears in an exam scenario, Parameter Store is eliminated.

The Decision Framework

AWS Secrets Manager vs Parameter Store decision tree for SAA-C03 — choosing based on rotation, sensitivity, cross-account access, and cost requirements

Work through these questions in order when a secret-storage scenario appears:

1. Does the scenario mention automatic rotation — on a schedule, without application changes, without custom code? → YES: Secrets Manager. No other answer is correct. Parameter Store cannot rotate automatically.

2. Is the value sensitive (a password, API key, private certificate)? → NO: Parameter Store String or StringList. Non-sensitive config belongs here — it's free, it's fast, and Secrets Manager is unnecessarily expensive for values like us-east-1 or feature-flag-enabled=true. → YES: Continue to question 3.

3. Does the scenario require cross-account access or replication to multiple AWS Regions? → YES: Secrets Manager. Only Secrets Manager supports a resource-based policy on the secret itself (cross-account) and built-in replica secrets (multi-region). → NO: Parameter Store SecureString (Standard tier, free). If the secret lives in one account, stays in one Region, and doesn't need automatic rotation, a KMS-encrypted SecureString is the correct cost-optimized answer.

The Feature Comparison

AWS Secrets Manager vs Parameter Store feature comparison matrix for SAA-C03 and DVA-C02 — automatic rotation, encryption, cost model, cross-account access, and multi-region replication

The comparison the exam tests most frequently:

	Secrets Manager	Parameter Store
Automatic rotation	✓ Built-in (RDS, Redshift, DocumentDB, Neptune)	✗ Custom Lambda only
Encryption	Always (KMS mandatory)	Optional (SecureString only)
Cost	$0.40/secret/month	Free (Standard)
Cross-account	✓ Resource-based policy	✗ Not natively supported
Multi-region	✓ Replica secrets	✗ Manual re-creation
Max value size	64 KB	4 KB (Standard) / 8 KB (Advanced)

The Rotation Deep-Dive — Where Candidates Lose Points

The rotation mechanism is the SAA-C03's most commonly tested Secrets Manager behavior, and it is more nuanced than "it rotates the password." Here is how it actually works:

The dual-version lifecycle:

When Secrets Manager triggers a rotation:

A new credential is created in the database (the new version has the AWSPENDING label).
Secrets Manager tests that the new credential works.
If the test passes, the new version gets the AWSCURRENT label and the old version gets AWSPREVIOUS.
After a grace period, the AWSPREVIOUS version is deleted.

Your application always calls GetSecretValue for the AWSCURRENT version. Because the old credential stays valid (AWSPREVIOUS) during the rotation cycle, in-flight connections using the old password continue to work until they are recycled — this is what "no application downtime" means in exam scenarios. If you hardcoded the password in your application, rotation would break you. If you retrieve it from Secrets Manager on each connection, rotation is invisible.

The exam trap: Some scenarios describe a Lambda function that reads a database password from Secrets Manager once at cold start and caches it in memory. This architecture breaks on rotation — the Lambda holds the old password until the next cold start. The correct pattern is to retrieve the secret on each invocation, or to implement a short-lived local cache with an expiry aligned to your rotation interval. The DVA-C02 tests this caching trap specifically.

Exam Scenario Drills

Scenario 1 (SAA-C03): A company stores its Amazon RDS PostgreSQL credentials in AWS Secrets Manager. A newly hired security engineer asks why the application still works immediately after a rotation event. The engineer expected the old password to stop working at rotation time. What explains this behavior?

→ Secrets Manager keeps the AWSPREVIOUS version valid for the duration of the rotation window so in-flight connections are not disrupted. The old password is only invalidated after the grace period completes. This is the dual-version rotation design.

Scenario 2 (SAA-C03): A startup is building its first AWS application. A developer needs to store the application's database hostname, environment name (production), and a plaintext feature-flag value. Cost must be minimized. Which service and parameter type should be used?

→ Parameter Store Standard tier, String type. These are non-sensitive configuration values. SecureString (KMS encryption) is unnecessary and adds API call cost. Secrets Manager at $0.40/secret/month is overkill for three plaintext config values.

Scenario 3 (DVA-C02): A developer is building a Lambda function that retrieves a third-party payment API key from AWS Secrets Manager at Lambda cold start and stores it in a global variable. The security team has configured automatic rotation every 30 days. After a rotation event, some Lambda invocations fail with an authentication error. What is the root cause?

→ The Lambda function cached the AWSPREVIOUS password in its global variable and is using it after rotation completed. The fix is to either retrieve the secret on each invocation (adding a small latency cost) or implement a cache with a TTL shorter than the rotation interval, with logic to retry GetSecretValue when an authentication error occurs.

Scenario 4 (SAA-C03): A company's security policy requires all database credentials to be stored in a way that supports automatic rotation and cross-account access, so that a central security account can audit credential usage. Which service satisfies both requirements?

→ Secrets Manager. It is the only service that supports both automatic rotation and cross-account access via resource-based policy. Parameter Store cannot satisfy the cross-account requirement.

Scenario 5 (SAA-C03): A solutions architect must store 50,000 application configuration parameters including feature flags, service URLs, and environment names. Cost is the primary constraint. No parameters are sensitive. Which service and tier should be used?

→ Parameter Store Advanced tier (the Standard tier limit is 10,000 parameters). At $0.05/parameter/month for 50,000 parameters that is $2,500/month — but this is still the correct answer because Secrets Manager at $0.40/secret/month for 50,000 items would cost $20,000/month. The exam is testing whether you know the Standard tier limit and recognize the Advanced tier as the next option before reaching for Secrets Manager.

IAM Access Pattern

Both services use IAM for access control, but the actions are different — and the exam tests them:

Secrets Manager:

secretsmanager:GetSecretValue      # retrieve the secret
secretsmanager:DescribeSecret      # read metadata (not the value)
secretsmanager:RotateSecret        # trigger a manual rotation
kms:Decrypt                        # required if using a customer-managed KMS key

Parameter Store:

ssm:GetParameter                   # retrieve one parameter
ssm:GetParameters                  # retrieve up to 10 parameters by name
ssm:GetParametersByPath            # retrieve all parameters under a path prefix
kms:Decrypt                        # required for SecureString parameters

The key difference on the exam: if a scenario says "the IAM policy must allow the Lambda function to retrieve multiple configuration values under /app/prod/ in one API call," that is a GetParametersByPath pattern — Parameter Store, not Secrets Manager. Secrets Manager has no equivalent path-query operation.

The Signal Words — Quick Reference

If you see this in a scenario	Answer
"automatically rotate" / "rotation schedule" / "rotate every N days"	Secrets Manager
"no application code changes during rotation"	Secrets Manager
"cross-account access to the secret"	Secrets Manager
"replicate the secret to another Region"	Secrets Manager
"store configuration values" / "feature flags" / "environment settings"	Parameter Store
"minimize cost" + non-sensitive values	Parameter Store String (free)
"minimize cost" + sensitive values, single account	Parameter Store SecureString (free)
"thousands of config parameters"	Parameter Store (check Standard vs Advanced tier limit)
"retrieve all parameters under a path" / "GetParametersByPath"	Parameter Store

Practice These Questions Before Your Exam

Security configuration questions — credential storage, rotation, encryption key management — appear in the SAA-C03's Design Secure Architectures domain (approximately 30% of the exam) and throughout the DVA-C02's security and configuration sections. If Secrets Manager vs. Parameter Store is a knowledge gap today, it will cost you points on exam day.

The free 10-question diagnostic shows you in 10 minutes exactly which security sub-domains need more work before exam day. If credential management is your gap, the SAA-C03 practice question set drills every rotation, cross-account, and encryption scenario across both services in the scenario-based format the real exam uses.

Working developers targeting the DVA-C02 will find the DVA-C02 practice set specifically tests the Lambda caching trap, the GetSecretValue vs GetParameter IAM action difference, and the dual-version rotation lifecycle in the exam's application-integration and security domains.

For the broader security-in-VPC picture, Security Groups vs. NACLs covers the stateful/stateless firewall pair that appears on the same domain, and VPC Endpoints — Gateway vs. Interface explains how to reach Secrets Manager and Parameter Store from a private VPC subnet without routing traffic over the public internet — a required piece of any secure application architecture.