Secrets Manager and Systems Manager Parameter Store

AWS Secrets Manager and AWS Systems Manager Parameter Store are the two services every DVA-C02 candidate must be able to tell apart. Both services store strings, both encrypt at rest with AWS KMS, and both are retrieved through an SDK call from Lambda, ECS, or EC2. But only one is a true secrets management service with automatic rotation, and only one is free at the standard tier. If you cannot decide between Secrets Manager and Parameter Store in under ten seconds on exam day, this page exists to fix that.

This topic walks you through every operational detail a developer must know: how Secrets Manager rotates credentials with Lambda rotation templates, how staging labels (AWSCURRENT, AWSPREVIOUS, AWSPENDING) drive the rotation state machine, how the Secrets Manager Lambda extension caches secrets to cut cold-start latency and cost, how Parameter Store hierarchical paths organise environments, how SecureString parameters use KMS, and how ECS task definitions inject both kinds of values using the valueFrom pattern. Every section ends with a fact you can expect on DVA-C02.

What Are AWS Secrets Manager and Parameter Store?

AWS Secrets Manager is a purpose-built secrets management service. It stores secrets (database passwords, API keys, OAuth tokens, TLS private keys), encrypts them with AWS KMS, versions every update, and runs a Lambda rotation function on a schedule you define. Secrets Manager is priced per secret per month (US$0.40) plus per 10,000 API calls (US$0.05), which is higher than most AWS services — that price buys you rotation, cross-Region replication, and first-class RDS/Redshift/DocumentDB integration.

AWS Systems Manager Parameter Store is a configuration and secret store inside the Systems Manager family. It stores three value types — String, StringList, and SecureString — organises them in a hierarchical path namespace like /prod/api/db/password, and is free at the Standard tier (up to 10,000 parameters, 4 KB each). Parameter Store does not rotate secrets natively. It is the go-to service for environment-specific configuration, feature flags, and secrets that do not require rotation.

Why DVA-C02 Tests Both Services Heavily

The DVA-C02 exam guide Domain 3 (Deployment) and Domain 4 (Security) together weight configuration and secrets management at roughly 15% of the exam. Expect multiple questions asking you to pick Secrets Manager versus Parameter Store, to identify the correct staging label after a rotation, or to read an ECS task definition and choose the right valueFrom ARN format. Because developers touch these services weekly in real jobs, questions tend to be scenario-heavy rather than memorisation-heavy.

Where Secrets Manager and Parameter Store Fit in a Developer Workflow

In a typical serverless or containerised workload, Parameter Store holds non-sensitive config (log level, feature flags, third-party endpoint URLs) and Secrets Manager holds the rotating RDS master password. At cold start, a Lambda function calls GetSecretValue once, caches the result in memory (or uses the Lambda extension to cache via the runtime API), and reuses that value across invocations until the cache expires. ECS tasks inject both Parameter Store SecureString values and Secrets Manager secrets via valueFrom on the container definition, turning the service call into an environment variable the application sees.

Plain-Language Explanation: Secrets Manager and Parameter Store

Analogy 1 — The Kitchen Pantry vs the Locked Spice Safe (Kitchen Analogy)

Picture a professional restaurant kitchen. Parameter Store is the open pantry shelf. Flour, sugar, pasta, olive oil — labelled boxes in a hierarchy (/baking/flour/bread, /baking/flour/pastry). Any cook on shift can grab a box. Some boxes are locked with a shared kitchen key (SecureString uses KMS), but the whole pantry is organised by path and it is free to walk in. Secrets Manager is the locked spice safe for the truffle oil and saffron — the expensive stuff. Every bottle has a rotation schedule (the head chef replaces each bottle every thirty days before it oxidises), every bottle has a label showing the current version, the previous version (in case the new one turns out bad), and the pending version (the new bottle being prepared). Only the chef and a few senior cooks have the combination. You pay a monthly lease per bottle in the safe, but you never worry about a bottle going stale. If the item needs to rotate, it belongs in the safe. If it just needs to be organised and found quickly, it belongs on the pantry shelf.

Analogy 2 — The Hotel Key System (Hotel / Hospitality Analogy)

Imagine a hotel with two key systems. Parameter Store is the master list of room numbers, Wi-Fi SSIDs, breakfast times, and elevator codes — mostly-public operational info posted at the front desk. Some entries are behind the counter (SecureString, KMS-encrypted), but the list is organised by floor and section (hierarchical paths), and anyone with a reception badge can look up an entry. Secrets Manager is the electronic key-card system. Every staff key-card has a current chip, a previous chip (still valid for a grace window in case the new chip failed the reader), and a pending chip being provisioned for tomorrow's shift. When a staff member goes on leave the card auto-rotates, and if the new chip fails to activate the card falls back to the previous chip. The front desk clerk retrieves the active key-card from a Lambda concierge that has cached the chip ID in its pocket (Lambda extension cache) instead of running down to the key vault every time a guest checks in. Rotation is the whole point of the key-card system; if you just need a room number, use the front-desk list.

Analogy 3 — The Toolbox vs the Locksmith Van (Workbench / Toolbox Analogy)

Think of a contractor showing up to a job site. Parameter Store is the toolbox in the van — drill, hammer, tape measure, screws sorted by size in labelled compartments (hierarchical paths). Most tools are out in the open (String, StringList), a few compartments are padlocked (SecureString via KMS), and the toolbox is free — it came with the truck. Secrets Manager is the locksmith's dedicated service van next door that rekeys locks on a schedule, keeps a spare of the last key (AWSPREVIOUS) in case the new one jams, and is prepping the next key (AWSPENDING) for handover. The locksmith van costs per lock per month to keep on retainer. You use the toolbox for everyday tasks, and you call the locksmith van when you need keys that must not last forever.

Core Operating Principles — Secrets Manager and Parameter Store Fundamentals

Before comparing the two services, internalise the shared principles that show up on every DVA-C02 question.

Both Encrypt at Rest with AWS KMS

Secrets Manager always encrypts secrets with a KMS key. You can use the default aws/secretsmanager AWS-managed key or a customer-managed key for audit control and cross-account access. Parameter Store String and StringList values are stored in plaintext; only SecureString values are encrypted with KMS. The KMS key choice matters: cross-account sharing requires a customer-managed key because AWS-managed keys cannot be cross-account-shared.

Both Are Retrieved by SDK or API

Applications call secretsmanager:GetSecretValue (Secrets Manager) or ssm:GetParameter / ssm:GetParameters / ssm:GetParametersByPath (Parameter Store) to retrieve values. Retrieval is IAM-gated, scoped to the resource ARN, and logged to CloudTrail. Neither service pushes values to clients — clients pull, usually at cold start and then cache in memory.

Both Integrate with ECS, EKS, Lambda, and CloudFormation

ECS task definitions use secrets with valueFrom (the ARN) to inject either service's values as environment variables or file mounts. Lambda does not natively inject secrets into environment variables — you must call GetSecretValue inside your handler (or use the Lambda extension). CloudFormation references Parameter Store via {{resolve:ssm:/path:version}} and Secrets Manager via {{resolve:secretsmanager:arn:SecretString:key:version}}.

Neither Is a Credential Provider Replacement

Secrets Manager and Parameter Store store values. They do not replace IAM roles for AWS service access. An application should still use the IAM role of the Lambda, ECS task, or EC2 instance to call AWS APIs. Use Secrets Manager for the database password your application types into a connection string, not for AWS SDK credentials.

AWS Secrets Manager — Deep Dive

What a Secret Looks Like

A secret in Secrets Manager is a versioned object identified by an ARN. Each version carries a VersionId (UUID) and zero or more staging labels. The payload is either a SecretString (JSON or plain text, most common) or a SecretBinary (base64-encoded bytes). Typical content for an RDS secret is a JSON blob: {"username":"admin","password":"P@ssw0rd!","engine":"mysql","host":"mydb.xxxx.rds.amazonaws.com","port":3306,"dbname":"appdb"}.

Staging Labels — AWSCURRENT, AWSPREVIOUS, AWSPENDING

Every version of a Secrets Manager secret can carry one or more staging labels. Three labels are reserved:

• AWSCURRENT — points at the version applications retrieve by default. GetSecretValue without a VersionStage argument returns AWSCURRENT.
• AWSPREVIOUS — points at the version that was AWSCURRENT before the last rotation. Used for rollback.
• AWSPENDING — points at the version the rotation Lambda has just created but has not yet verified. Rotation promotes AWSPENDING to AWSCURRENT only after the Lambda successfully tests the new credential against the target (RDS, Redshift, DocumentDB).

On exam day, remember the lifecycle: createSecret makes a new version with AWSPENDING → setSecret writes the new value to the database → testSecret verifies the database accepts the new value → finishSecret moves AWSCURRENT from the old version to the new AWSPENDING version, demotes the old AWSCURRENT to AWSPREVIOUS, and removes AWSPENDING. This four-step state machine is the canonical rotation flow.

Automatic Rotation with Lambda

Secrets Manager rotation runs on a schedule (every N days, or on a cron expression for Secrets Manager rotation v2). When the schedule triggers, Secrets Manager invokes a Lambda rotation function with four phases: createSecret, setSecret, testSecret, finishSecret. AWS supplies pre-built rotation Lambda templates for the most common targets:

• RDS — MySQL, MariaDB, PostgreSQL, Oracle, SQL Server, Db2
• Aurora — MySQL-compatible, PostgreSQL-compatible
• Amazon Redshift — cluster admin and user
• Amazon DocumentDB — cluster master
• Amazon ElastiCache — Redis OSS auth tokens (requires ElastiCache ≥ 7.0)

You can also write a custom rotation Lambda for non-AWS targets (a third-party SaaS API key, an on-prem LDAP account). The Lambda needs IAM permissions to call secretsmanager:GetSecretValue, secretsmanager:PutSecretValue, secretsmanager:UpdateSecretVersionStage, plus whatever the target service requires (e.g., rds-db:connect for an IAM-authenticated RDS password change).

Single-User vs Alternating-User Rotation Strategies

Secrets Manager rotation supports two strategies. Single user rotates the same database user's password on every cycle — simple, but every rotation causes a brief connection-failure window while the password is being updated. Alternating users keeps two database users (appuser_a and appuser_b) and rotates between them on each cycle — no downtime, but your database must tolerate two users with identical permissions. For exam purposes, remember: alternating-user is the zero-downtime pattern.

Versioning and Rollback

Every PutSecretValue creates a new version with a new UUID. Old versions without staging labels are removed after 24 hours. If a rotation breaks production, you can roll back by calling UpdateSecretVersionStage to move AWSCURRENT back to the AWSPREVIOUS version. This is why AWSPREVIOUS matters — it is your rollback handle.

Cross-Account Sharing

To share a secret across AWS accounts, attach a resource-based policy to the secret that grants secretsmanager:GetSecretValue to the other account's principal, and ensure the KMS key the secret is encrypted with is a customer-managed key (not aws/secretsmanager) because the default AWS-managed key cannot be used cross-account. The receiving account then calls GetSecretValue with the full ARN.

Cross-Region Replication

Secrets Manager replication copies a secret to one or more additional Regions. Replication keeps replicas synchronised — updates in the primary propagate to replicas, and you can promote a replica to primary for disaster recovery. Each replica counts as a separate secret for billing. Useful when your application is multi-Region and needs low-latency local reads of the database password.

Retrieval in Code

The canonical SDK pattern in Python is:

import boto3, json
client = boto3.client('secretsmanager')
resp = client.get_secret_value(SecretId='prod/rds/mydb')
secret = json.loads(resp['SecretString'])
conn = psycopg2.connect(host=secret['host'], user=secret['username'], password=secret['password'])

The SDK call is a paid API request. In Lambda, call get_secret_value once outside the handler (module scope) so the cached value survives across warm invocations on the same container. On cold starts, this adds ~50-150ms. In ECS or EC2, cache the value in memory for the lifetime of the container/process and refresh on a timer or on authentication failure.

AWS Secrets Manager Lambda Extension

The Secrets Manager Lambda extension is an AWS-managed layer that runs as a sidecar process inside your Lambda execution environment and exposes an HTTP cache at http://localhost:2773/secretsmanager/get?secretId=prod/rds/mydb. Your Lambda code makes an HTTP GET to that localhost endpoint instead of calling the AWS SDK. The extension authenticates using the Lambda's IAM role (via AWS_LAMBDA_RUNTIME_API), retrieves the secret on first request, and caches it in memory for the extension's lifetime (default TTL 300 seconds, configurable).

Benefits of the extension:

• Lower latency — in-memory cache hits are sub-millisecond versus ~50-150ms for a cold SDK call.
• Lower cost — fewer Secrets Manager API calls; the extension deduplicates across concurrent invocations on the same container.
• No SDK code — your handler just calls http://localhost:2773 and parses JSON.
• Authentication inherited — the extension uses AWS_LAMBDA_RUNTIME_API to obtain the function's execution-role credentials.

Add the extension by attaching the AWS-Parameters-and-Secrets-Lambda-Extension layer ARN to your function. Configure cache TTL with the SECRETS_MANAGER_TTL environment variable. The same extension also caches Parameter Store parameters, so a single layer covers both services.

IAM Policy Patterns

Scope every IAM policy to the secret ARN rather than Resource: "*". A tight policy:

{
  "Effect": "Allow",
  "Action": ["secretsmanager:GetSecretValue"],
  "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/rds/mydb-??????"
}

The six-question-mark suffix accounts for the random suffix Secrets Manager appends to every secret ARN for disambiguation after deletion-and-recreate cycles. Grant secretsmanager:DescribeSecret if your code inspects metadata, and grant KMS kms:Decrypt on the encryption key if you used a customer-managed KMS key.

Deletion and Recovery Window

Deleting a secret is a two-step process. DeleteSecret schedules the secret for deletion with a recovery window of 7 to 30 days (default 30). During the window, RestoreSecret undoes the deletion. After the window, the secret is permanently removed. For testing, you can pass ForceDeleteWithoutRecovery=true to skip the window (not recommended for production).

AWS Systems Manager Parameter Store — Deep Dive

Parameter Types — String, StringList, SecureString

Parameter Store accepts three value types:

• String — plain text up to 4 KB (Standard tier) or 8 KB (Advanced tier). No encryption.
• StringList — comma-separated list returned as a single string. Parsed by the client.
• SecureString — plain-text value encrypted with a KMS key at rest. Retrieval requires kms:Decrypt on the key.

For SecureString you can use the default aws/ssm AWS-managed key (simple, no cross-account) or a customer-managed KMS key (cross-account sharing and explicit key rotation).

Standard Tier vs Advanced Tier

Parameter Store has two tiers per parameter:

• Standard — free, up to 10,000 parameters per Region per account, 4 KB value max, no per-parameter cost, no parameter policies.
• Advanced — US$0.05 per parameter per month, up to 100,000 parameters per Region per account, 8 KB value max, supports parameter policies (expiration, expiration notification, no-change notification).

For DVA-C02, remember: Standard is free and enough for most workloads. Advanced exists when you need more parameters, larger values, or parameter policies. Parameter policies fire EventBridge events for expiration or lack of change, useful for flagging stale secrets.

Hierarchical Paths

Parameter names are paths with / separators: /prod/web/api/db/password, /dev/web/api/db/password, /prod/web/api/feature-flags/new-checkout. The hierarchy is not a directory in the filesystem sense — it is a naming convention that GetParametersByPath exploits with a recursive flag.

aws ssm get-parameters-by-path \
  --path "/prod/web/api" \
  --recursive \
  --with-decryption

This one call pulls every parameter under /prod/web/api. In Lambda or ECS cold start, this is the efficient pattern — one API call retrieves every environment config, rather than one call per parameter. IAM policies can scope permissions to a path prefix using Resource: "arn:aws:ssm:us-east-1:123456789012:parameter/prod/web/api/*", giving you path-based authorization for free.

Parameter Versioning

Every PutParameter creates a new version (integer, monotonically increasing). You can retrieve a specific version with name:version syntax: /prod/web/api/db/password:3. Without a version, you get the latest. Parameter Store keeps the full version history for Advanced parameters; for Standard, at least the last 100 versions are retained. Useful for rollback and for pinning a Lambda to a specific parameter version with CloudFormation {{resolve:ssm:/prod/web/api/db/password:3}}.

Cross-Account Sharing via AWS RAM

Parameter Store parameters can be shared across AWS accounts using AWS Resource Access Manager (RAM). Create a resource share, add the parameter ARN to the share, and invite the target account(s). The receiving account calls GetParameter with the full ARN (not just the name). SecureString values require a customer-managed KMS key that also grants decrypt permissions to the receiving account. RAM sharing works for Advanced parameters only.

Public Parameters for AMI IDs and Service Endpoints

AWS publishes a tree of public parameters under /aws/service/* that any account can read without authentication setup. Two high-value examples:

• Latest Amazon Linux 2 AMI — /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2
• Latest ECS-optimised AMI — /aws/service/ecs/optimized-ami/amazon-linux-2/recommended

Launch configurations and CloudFormation templates reference these parameters instead of hardcoding AMI IDs, so instances automatically pick up the latest AMI without manual updates. Public parameters are free and do not count against your parameter quota.

Retrieval Patterns

SDK retrieval from Python looks like:

import boto3
ssm = boto3.client('ssm')
p = ssm.get_parameter(Name='/prod/web/api/db/password', WithDecryption=True)
password = p['Parameter']['Value']

Or for bulk:

resp = ssm.get_parameters_by_path(Path='/prod/web/api', Recursive=True, WithDecryption=True)
config = {p['Name']: p['Value'] for p in resp['Parameters']}

WithDecryption=True is required for SecureString values; without it you get ciphertext. The same Lambda extension that caches Secrets Manager also caches Parameter Store — point your HTTP GET at http://localhost:2773/systemsmanager/parameters/get?name=/prod/web/api/db/password&withDecryption=true.

IAM Policy Patterns for Parameter Store

IAM policies scope by parameter ARN with path wildcards:

{
  "Effect": "Allow",
  "Action": ["ssm:GetParameter", "ssm:GetParametersByPath"],
  "Resource": "arn:aws:ssm:us-east-1:123456789012:parameter/prod/web/api/*"
}

For SecureString, add kms:Decrypt on the encryption key. This path-prefix pattern is how you give a Lambda access to its own environment's config without leaking dev or staging parameters.

Secrets Manager vs Parameter Store — The Decision Tree

On DVA-C02 you will be handed a one-paragraph scenario and asked to pick one service. Run this decision tree in your head.

Branch 1 — Does the Value Require Automatic Rotation?

If the scenario mentions "rotate every N days," "scheduled credential rotation," or "meet a compliance requirement for password rotation," the answer is Secrets Manager. Parameter Store does not rotate natively. You could roll your own rotation with EventBridge + Lambda + Parameter Store, but it is not the AWS-recommended path and it is never the correct exam answer when rotation is required.

Branch 2 — Is Rotation Cost Acceptable?

Secrets Manager is US$0.40 per secret per month. For a workload with 500 secrets, that is US$200/month just for storage. Parameter Store Standard is free. If the scenario optimises for cost and rotation is not required, the answer is Parameter Store Standard.

Branch 3 — Does the Value Exceed 4 KB?

Standard Parameter Store caps values at 4 KB. Secrets Manager goes to 64 KB. Parameter Store Advanced goes to 8 KB. If you must store a full TLS private key chain or a large JSON config, use Secrets Manager or Parameter Store Advanced.

Branch 4 — Do You Need Hierarchical Path Retrieval?

If the scenario says "retrieve all configuration for the staging environment in one API call," the answer is Parameter Store with GetParametersByPath. Secrets Manager does not have a native hierarchical retrieval API; you would list secrets by tag or name prefix, which is less efficient.

Branch 5 — Do You Need Cross-Region Replication?

Secrets Manager has built-in ReplicateSecretToRegions. Parameter Store does not replicate automatically — you would write a CloudWatch Events → Lambda workflow. For multi-Region DR, Secrets Manager is the clean answer.

Branch 6 — Is This an AWS Public Parameter (AMI ID, Region, etc.)?

If you need the latest Amazon Linux 2 AMI ID or a list of AWS Regions, the answer is always Parameter Store public parameters under /aws/service/*. Secrets Manager does not publish public values.

Injecting Secrets into ECS Tasks — The valueFrom Pattern

ECS supports injecting both Parameter Store and Secrets Manager values as environment variables via the secrets block on a container definition. The key field is valueFrom, which takes either a Parameter Store parameter name/ARN or a Secrets Manager secret ARN with an optional JSON key selector.

Parameter Store Injection

{
  "containerDefinitions": [{
    "name": "app",
    "image": "myapp:latest",
    "secrets": [
      { "name": "DB_PASSWORD", "valueFrom": "arn:aws:ssm:us-east-1:123456789012:parameter/prod/app/db-password" },
      { "name": "LOG_LEVEL", "valueFrom": "/prod/app/log-level" }
    ]
  }]
}

The shorter form (just the parameter name) works when the parameter is in the same account and Region as the task. For SecureString values, grant the ECS task execution role ssm:GetParameters and kms:Decrypt on the KMS key.

Secrets Manager Injection

{
  "secrets": [
    { "name": "DB_PASSWORD", "valueFrom": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/rds/mydb-AbCdEf:password::" }
  ]
}

The ARN format is arn:...:secret:<name>-<suffix>:<jsonKey>:<versionStage>:<versionId>. The trailing :password:: selects the password JSON key from the AWSCURRENT version. If the secret payload is a plain string, use arn:...:secret:<name>-<suffix> without the trailing fields.

Task Execution Role Permissions

ECS fetches the secret using the task execution role, not the task role. The execution role is the role ECS uses on your behalf for pulling images and fetching secrets before the container starts. The task role is the role your application code assumes at runtime. Grant secretsmanager:GetSecretValue or ssm:GetParameters plus kms:Decrypt to the execution role so the injection works on task startup.

EKS and Kubernetes Secrets

EKS uses the AWS Secrets and Configuration Provider (ASCP) for the Kubernetes Secrets Store CSI Driver. ASCP mounts Secrets Manager secrets and Parameter Store parameters as files in the pod and can optionally sync them into native Kubernetes Secrets. This is outside DVA-C02 core but worth knowing for real work.

Cold Start vs Per-Invoke Retrieval Patterns in Lambda

A Lambda function can retrieve a secret in three places: at cold start (module scope), at every invocation (inside the handler), or via the Lambda extension cache. The pattern you pick has direct cost and latency implications.

Cold Start — Module Scope

import boto3, json
sm = boto3.client('secretsmanager')
SECRET = json.loads(sm.get_secret_value(SecretId='prod/rds/mydb')['SecretString'])

def lambda_handler(event, context):
    # SECRET is already in memory
    ...

The get_secret_value call runs once per container initialisation and the result lives for the container's lifetime (up to several hours for warm functions). Pros: minimal API cost, low per-invocation latency. Cons: cold-start latency adds ~100ms; rotation will not be picked up until the container recycles.

Per-Invoke — Handler Scope

def lambda_handler(event, context):
    SECRET = json.loads(sm.get_secret_value(SecretId='prod/rds/mydb')['SecretString'])
    ...

A GetSecretValue call on every invocation. Always picks up the latest rotated value. Pros: always fresh. Cons: expensive at high RPS and adds latency to every request. Never the right pattern for production Lambda.

Lambda Extension — Recommended

Add the AWS-Parameters-and-Secrets-Lambda-Extension layer, set SECRETS_MANAGER_TTL=300, and call http://localhost:2773/secretsmanager/get?secretId=prod/rds/mydb from the handler. The extension caches the secret for 300 seconds and refreshes on expiry. This combines cold-start caching with rotation responsiveness.

Real-World Scenarios — What DVA-C02 Asks

Scenario 1 — RDS Master Password with 30-Day Rotation

A DVA-C02 question: "A developer needs to store the master password for an RDS MySQL database and rotate it every 30 days. Which service?" Answer: Secrets Manager with the RDS MySQL rotation Lambda template and a 30-day rotation schedule. The template handles createSecret / setSecret / testSecret / finishSecret automatically.

Scenario 2 — Feature Flag for Beta Rollout

"A Lambda function reads a boolean feature flag on every invocation to decide whether to enable a beta feature. Which service minimises cost?" Answer: Parameter Store Standard, free tier, with the Lambda extension caching the value for 60 seconds. Secrets Manager would cost US$0.40/month per flag; Parameter Store is free.

Scenario 3 — Latest Amazon Linux 2 AMI in CloudFormation

"A team wants its launch templates to always use the latest Amazon Linux 2 AMI without manual updates." Answer: Reference the AWS public parameter /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 as a CloudFormation parameter of type AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>.

Scenario 4 — Cross-Account Database Credential

"Account A runs an Aurora cluster; Account B runs a Lambda that needs the cluster password." Answer: Secrets Manager in Account A with a resource-based policy granting GetSecretValue to Account B, encrypted with a customer-managed KMS key that also grants decrypt to Account B. Parameter Store Advanced with RAM is an alternative but Secrets Manager is the default for credentials.

Scenario 5 — ECS Task with Stripe API Key

"An ECS Fargate task needs a Stripe API key injected as an environment variable, rotated every 90 days." Answer: Store in Secrets Manager, reference in the task definition with valueFrom pointing at the secret ARN, grant the task execution role secretsmanager:GetSecretValue and kms:Decrypt, and write a custom rotation Lambda (since Stripe is not one of the built-in rotation templates).

Scenario 6 — High-Frequency Lambda Reading the Same Secret

"A Lambda running at 2,000 RPS reads a database password on every invocation, and the team is surprised by the Secrets Manager bill." Answer: Add the AWS Parameters and Secrets Lambda Extension, set TTL to 300 seconds, and switch the handler to HTTP GET against localhost:2773. API calls drop by ~99% (one call per container per TTL window instead of per invocation).

IAM Scope and Least Privilege

Always Scope by ARN

Never grant Resource: "*" for Secrets Manager or Parameter Store in production. Scope to the specific secret ARN (with the -?????? suffix wildcard) or the specific parameter path prefix. This prevents a compromised Lambda from reading every secret in the account.

Separate Read and Write Permissions

Application roles should only have GetSecretValue / GetParameter. Admin roles and rotation Lambdas have PutSecretValue, UpdateSecretVersionStage, PutParameter. A rotation Lambda's role is a key audit point — it must be scoped to the specific secret it rotates.

KMS Decrypt Permission

If a secret or SecureString uses a customer-managed KMS key, the reader needs kms:Decrypt on that key as well as the Secrets Manager or SSM read permission. A missing kms:Decrypt is the most common cause of "AccessDeniedException" when using customer-managed keys.

Common Exam Traps — Where Candidates Lose Points

Trap 1 — Assuming Parameter Store Has Rotation

Parameter Store does not rotate natively. If the scenario says "rotate," the answer is Secrets Manager — full stop.

Trap 2 — Confusing Task Role and Execution Role for ECS Injection

The execution role fetches the secret before the container starts. The task role is for your application code at runtime. Injection permissions go on the execution role.

Trap 3 — Ignoring the -?????? ARN Suffix

Secrets Manager appends a random six-character suffix to every ARN. An IAM policy targeting arn:...:secret:prod/rds/mydb without the wildcard suffix will break after you delete and recreate the secret.

Trap 4 — Forgetting KMS Decrypt for Customer-Managed Keys

For SecureString or Secrets Manager secrets encrypted with a customer-managed KMS key, you must grant kms:Decrypt on the key. Readers without it get AccessDenied even though the Secrets Manager policy is correct.

Trap 5 — Assuming CloudFormation Dynamic References Auto-Update

{{resolve:ssm:/path}} resolves at stack-update time, not at runtime. Rotating a secret does not retrigger a CloudFormation resolution. Use {{resolve:ssm:/path:VERSION}} to pin or rerun the stack update after rotation.

Trap 6 — Picking Secrets Manager for a Feature Flag

Feature flags do not rotate. Parameter Store Standard is free for this use case. Secrets Manager's rotation features are wasted on a boolean.

Key Numbers and Must-Memorise Facts

This is the memorisation block. Expect exam questions that hinge on exactly these numbers.

Secrets Manager Facts

• US$0.40 per secret per month, US$0.05 per 10,000 API calls.
• Maximum secret size: 64 KB.
• Three reserved staging labels: AWSCURRENT, AWSPREVIOUS, AWSPENDING.
• Rotation Lambda four phases: createSecret, setSecret, testSecret, finishSecret.
• Rotation templates for RDS (MySQL, MariaDB, PostgreSQL, Oracle, SQL Server, Db2), Aurora, Redshift, DocumentDB, ElastiCache.
• Default recovery window on delete: 30 days (minimum 7).
• Cross-Region replication is native.

Parameter Store Facts

• Standard tier: free, 10,000 parameters per Region per account, 4 KB max value.
• Advanced tier: US$0.05 per parameter per month, 100,000 parameters per Region per account, 8 KB max value, supports parameter policies.
• Three value types: String, StringList, SecureString.
• Hierarchical paths with / delimiter; GetParametersByPath with --recursive flag.
• Public parameters under /aws/service/* — free, no quota.
• Cross-account sharing via AWS RAM (Advanced tier only).

Shared Facts

• Both use KMS for encryption at rest.
• Both integrate with ECS secrets.valueFrom injection via the task execution role.
• Both are cached by the AWS Parameters and Secrets Lambda Extension layer at http://localhost:2773.
• Both use IAM resource-based policies and IAM identity-based policies for access control.

Comparison Table — Secrets Manager vs Parameter Store

Rotation

Secrets Manager rotates via Lambda on a schedule. Parameter Store does not rotate natively.

Cost

Secrets Manager US$0.40 per secret per month. Parameter Store Standard is free, Advanced is US$0.05 per parameter per month.

Maximum Value Size

Secrets Manager 64 KB. Parameter Store Standard 4 KB, Advanced 8 KB.

Versioning

Secrets Manager versions by UUID with staging labels. Parameter Store versions with monotonic integers.

Cross-Region

Secrets Manager native ReplicateSecretToRegions. Parameter Store requires a custom EventBridge + Lambda replication.

Cross-Account

Secrets Manager resource-based policy + customer-managed KMS key. Parameter Store via AWS RAM (Advanced tier).

Hierarchical Retrieval

Parameter Store has GetParametersByPath with recursion. Secrets Manager does not.

Public AWS-Published Values

Parameter Store has /aws/service/* public parameters for AMIs and Region info. Secrets Manager does not.

Integration with RDS/Redshift/DocumentDB

Secrets Manager has first-class rotation templates. Parameter Store integrates as plain config only.

Typical Use Case

Secrets Manager: rotating RDS passwords, API keys, OAuth tokens, TLS private keys. Parameter Store: feature flags, environment config, endpoint URLs, AMI IDs.

FAQ — Secrets Manager and Parameter Store Top Questions

Q1 — Can Parameter Store rotate secrets like Secrets Manager?

Not natively. You can build rotation yourself with EventBridge + Lambda writing new versions to Parameter Store, but there are no pre-built rotation templates and no RDS/Redshift/DocumentDB integration. For DVA-C02, if the scenario requires rotation, the answer is always Secrets Manager.

Q2 — What is the difference between AWSCURRENT, AWSPREVIOUS, and AWSPENDING?

AWSCURRENT is the active version that GetSecretValue returns by default. AWSPREVIOUS is the version that was AWSCURRENT before the last rotation, used for rollback. AWSPENDING is the version the rotation Lambda has just created but has not yet activated. After a successful rotation, AWSPENDING is promoted to AWSCURRENT, the old AWSCURRENT moves to AWSPREVIOUS, and the AWSPENDING label is removed.

Q3 — How does the Secrets Manager Lambda extension authenticate?

The extension uses AWS_LAMBDA_RUNTIME_API, the internal endpoint Lambda exposes to extensions, to obtain the function's execution-role credentials. It then calls Secrets Manager with those credentials on your behalf. You do not hardcode credentials — the execution role is sufficient, and the extension picks it up automatically.

Q4 — Can an ECS task inject a secret as a file instead of an environment variable?

ECS supports environment-variable injection via secrets.valueFrom natively. For file-based injection you use the AWS Secrets and Configuration Provider (ASCP) with the Kubernetes Secrets Store CSI Driver on EKS, or a sidecar pattern on ECS. The exam defaults to environment-variable injection.

Q5 — Are SecureString parameters in Parameter Store as secure as Secrets Manager secrets?

Both encrypt at rest with KMS. The cryptographic protection is equivalent. The difference is operational: Secrets Manager adds rotation, versioning with staging labels, cross-Region replication, and first-class database integration. If those features do not matter for your value, SecureString is equally secure and dramatically cheaper.

Q6 — What permissions does the ECS task execution role need to read a Secrets Manager secret?

secretsmanager:GetSecretValue on the secret ARN, and kms:Decrypt on the KMS key if the secret uses a customer-managed key. For Parameter Store SecureString: ssm:GetParameters and kms:Decrypt. These go on the execution role (used before the container starts), not the task role (used by application code at runtime).

Q7 — How do I roll back a bad rotation?

Call UpdateSecretVersionStage to move the AWSCURRENT label from the broken new version back to the old version (which now carries AWSPREVIOUS). This is an API call, seconds to execute. You may also need to revert the change on the target system (e.g., reset the database password to the previous value if the rotation already updated it).

Q8 — How do I cache a Parameter Store value in a Lambda without writing extra code?

Attach the AWS-Parameters-and-Secrets-Lambda-Extension layer ARN to your function. Set the SSM_PARAMETER_STORE_TTL environment variable. Make an HTTP GET to http://localhost:2773/systemsmanager/parameters/get?name=/prod/app/config&withDecryption=true from your handler. The extension handles caching, authentication, and decryption without any SDK code in your function.

Q9 — Can I use the same CloudFormation dynamic reference for Parameter Store and Secrets Manager?

No, they are different syntaxes. Parameter Store uses {{resolve:ssm:/path:version}} or {{resolve:ssm-secure:/path:version}} for SecureString. Secrets Manager uses {{resolve:secretsmanager:arn:SecretString:jsonKey:versionStage:versionId}}. Both resolve at stack-create or stack-update time, not at runtime — rotations do not automatically retrigger resolution.

Q10 — What happens if I delete a Secrets Manager secret by mistake?

Deletion is soft by default with a recovery window of 7 to 30 days. Call RestoreSecret within the window to undelete. After the window expires the secret is permanently gone. If you used ForceDeleteWithoutRecovery=true the secret is immediately unrecoverable — use that flag only for ephemeral test data.

Further Reading — Official AWS Documentation

The authoritative sources for DVA-C02 preparation are the AWS Secrets Manager User Guide (especially the "Rotating secrets" and "Retrieve secrets from AWS services" chapters), the Systems Manager Parameter Store chapter of the Systems Manager User Guide, the Lambda extensions reference, and the ECS Developer Guide "Specifying sensitive data" chapter. Bookmark docs.aws.amazon.com/secretsmanager/ and docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html.

The AWS Blog posts on "How to use AWS Secrets Manager Lambda extension" and "Organizing parameters using hierarchies" are worth one read each to cement the retrieval patterns that show up on the exam.

Summary — Secrets Manager and Parameter Store Cheat Sheet

On exam day, when you see a configuration-or-secrets scenario, run this decision path:

1. Does the value need automatic rotation? Yes → Secrets Manager. No → next question.
2. Does the value exceed 4 KB? Yes → Secrets Manager or Parameter Store Advanced. No → next question.
3. Is cost a primary concern and rotation is not required? Yes → Parameter Store Standard (free).
4. Do you need hierarchical retrieval of many values in one call? Yes → Parameter Store GetParametersByPath.
5. Do you need cross-Region replication? Yes → Secrets Manager native replication.
6. Are you fetching a latest AMI ID or AWS-published value? Yes → Parameter Store public parameter /aws/service/*.
7. For injection into ECS, use secrets.valueFrom with the execution role holding GetSecretValue / GetParameters plus kms:Decrypt.
8. For high-RPS Lambda reads, use the AWS Parameters and Secrets Lambda Extension with an appropriate TTL.
9. For cross-account access, use a customer-managed KMS key plus a resource-based policy (Secrets Manager) or AWS RAM (Parameter Store Advanced).

Master these nine branches and every Secrets Manager or Parameter Store question on DVA-C02 becomes a 10-second decision. The exam rewards recognition of the cue words — "rotation," "free tier," "hierarchy," "latest AMI," "cross-account," "Lambda extension" — more than memorisation of API signatures. Read each scenario for the cue, apply the branch, and pick the service.