Parameter Store, Secrets Manager, and KMS Key Management

SSM Parameter Store and Secrets Manager rotation are the two AWS services that DevOps teams use to store, distribute, and rotate the secrets — database passwords, API keys, OAuth tokens, license strings — that applications need to operate without ever embedding them in code. On the DOP-C02 exam, SSM Parameter Store and Secrets Manager rotation appear all over Domain 6 Tasks 6.1 and 6.2 (and Domain 1 Task 1.1 for pipeline secrets) whenever a scenario sets "rotate database credentials every 30 days," "share an API key across 50 accounts," "ECS task needs a secret without environment-variable leakage," or "CodeBuild must fetch a license at build time without committing it." The right answer always combines the right service (Parameter Store for hierarchy + low-cost; Secrets Manager for rotation + cross-account share), the right encryption (KMS CMK for compliance), and the right consumption pattern (CloudFormation dynamic reference, ECS task secret, IAM-protected runtime fetch) into a no-secret-in-code architecture.

This Pro-depth guide walks through every SSM Parameter Store and Secrets Manager rotation primitive you will encounter on DOP-C02: Parameter Store standard vs advanced tier, SecureString with KMS, hierarchy and IAM path-based access, parameter labels and versioning, Secrets Manager automatic rotation with Lambda, RDS/Aurora multi-user rotation strategies, cross-account secret sharing via resource policies, multi-region replication, integration with ECS task definitions and CodeBuild environment variables, CloudFormation dynamic references with {{resolve:...}}, the cost differences between the two services, and the canonical Pro scenario — pipeline-driven 30-day rotation across multi-account staging/production environments — dissected step by step.

What Are SSM Parameter Store and Secrets Manager Rotation?

SSM Parameter Store is the free-tier (standard tier) hierarchical key-value store for configuration and secrets, with optional KMS encryption (SecureString) and IAM-controlled access. Secrets Manager is the higher-cost specialized secrets service with automatic credential rotation via Lambda, native RDS/Aurora/Redshift/DocumentDB integration, cross-account sharing via resource policies, multi-region replication, and 7-day soft-delete recovery window. Both can encrypt with KMS; both integrate with ECS, CodeBuild, CloudFormation, Lambda; the choice between them is driven by rotation requirements, cross-account needs, and per-secret cost.

Why SSM Parameter Store and Secrets Manager Rotation Matter for DOP-C02

DOP-C02 Task 6.1 explicitly demands "automating credential rotation for machine identities (for example, AWS Secrets Manager)" as required skill. Task 1.1 demands "managing build and deployment secrets (for example, AWS Secrets Manager, AWS Systems Manager Parameter Store)." Task 6.2 demands "data management (for example, data classification, encryption, key management, access controls)." Pro-tier scenarios test knowing the trade-offs precisely — when each service is correct, when both are needed, and how rotation interacts with applications that cache credentials.

The Six Decision Axes

Choosing between SSM Parameter Store and Secrets Manager rotation requires evaluating six axes: rotation requirement (Secrets Manager has built-in; Parameter Store does not), cost (Parameter Store standard is free; Secrets Manager is $0.40 per secret per month + $0.05 per 10k API calls), cross-account share (Secrets Manager has resource policies; Parameter Store advanced tier supports limited sharing), hierarchy (Parameter Store has rich path hierarchies; Secrets Manager is flat), multi-region (Secrets Manager has automatic replication; Parameter Store requires CloudFormation StackSets or scripting), and integration depth (RDS/Aurora native rotation only in Secrets Manager).

Plain-Language Explanation: SSM Parameter Store and Secrets Manager Rotation

SSM Parameter Store and Secrets Manager rotation sound like alphabet soup, but three everyday analogies expose their roles.

Analogy 1 — The Hotel Key Card and Master Key System (Hospitality Analogy)

Picture a hotel chain with 50 properties (your AWS accounts), one key-card management central system, and one safety-deposit-box vault. SSM Parameter Store and Secrets Manager rotation is the layered key system.

The standard guest key cards that the front desk programs at check-in and that automatically expire when the guest checks out — used for everyday access to the room — are SSM Parameter Store SecureString parameters. Cheap to make, easy to organise by floor (/floor3/room305, /floor4/room402 — hierarchical paths), encrypted with the hotel's master key system (KMS CMK), but they don't automatically rotate; you replace them when a guest changes. The safety-deposit-box keys that the bank vault automatically replaces every 30 days — issued to long-term tenants who require periodic re-keying — are Secrets Manager secrets. More expensive per key, but the vault handles the rotation: the safe automatically issues a new key on schedule, the old key is staged-and-then-retired, and the tenant's authorized devices automatically pick up the new key. The master key list at the central security office that any property manager can request access to (across hotels) is Secrets Manager's cross-account resource policy — share one key with 50 properties without creating 50 separate keys. The Las Vegas backup vault that mirrors the New York vault is Secrets Manager's multi-region replication. The CCTV reading every key-card swipe is CloudTrail logging every Parameter Store / Secrets Manager API call. Use Parameter Store for cheap, hierarchical, non-rotating configuration; use Secrets Manager for rotating, cross-shareable, multi-region credentials.

Analogy 2 — The Hospital Pharmacy and Medication Cart System (Pharmacy Analogy)

Imagine a hospital with a central pharmacy and many ward medication carts. SSM Parameter Store and Secrets Manager rotation is the layered medication-distribution system.

The medication catalogue — drug names, dosage instructions, ward-specific protocols — organized by department (/cardiology/anti-hypertensive/dosage) and accessible to ward staff via badge-scoped permission is Parameter Store with its hierarchy and IAM path-based policy. Catalogue entries are encrypted at rest (SecureString), free to store, easy to organize, but the pharmacist updates them manually when protocols change. The rotating supply of antibiotics with mandatory 30-day potency-replacement schedule that the central pharmacy auto-rotates — old vials staged-then-disposed, new vials supplied — is Secrets Manager with automatic rotation. More expensive per entry but no human has to remember to rotate. The inter-hospital sharing of a rare-drug formulation via a signed agreement letter is Secrets Manager cross-account resource policy — share a single secret across multiple AWS accounts without duplication. The regional disaster-preparedness mirror at the satellite hospital is Secrets Manager multi-region replication. The drug administration log — every dispense recorded — is CloudTrail. Pro-tier hospitals use both: catalogue (Parameter Store) for static reference data, rotation (Secrets Manager) for time-bound credential-style entries.

Analogy 3 — The Embassy Diplomatic Pouch and Code Book System (Diplomatic Analogy)

Picture an embassy network with 50 missions worldwide. SSM Parameter Store and Secrets Manager rotation is the layered cryptographic-material distribution system.

The diplomatic phone book organized by region and rank (/asia-pacific/tokyo/ambassador/email, /europe/london/consul/cell) — readable by authorized staff per their badge — is Parameter Store hierarchies with IAM path-based access. Encrypted with the embassy's master cypher (KMS), cheap to store, but updates are manual. The diplomatic cipher pads with mandatory 30-day rotation issued by HQ — old pad superseded, new pad delivered, missions automatically pick up the new pad — is Secrets Manager automatic rotation. The multi-mission shared codebook that London, Paris, and Berlin all need to read — provisioned once, accessed via cross-mission permissions — is a Secrets Manager secret with cross-account resource policy. The disaster-redundancy backup pad cached at the regional command center is Secrets Manager multi-region replication. The classified communications log kept for after-action review is CloudTrail. Static reference data → Parameter Store. Rotating cryptographic material that must auto-renew on schedule and replicate across missions → Secrets Manager.

SSM Parameter Store — Hierarchical Configuration and Cheap Secrets

Parameter Store is the workhorse for configuration values and low-cost secrets. DOP-C02 expects detail.

Standard Tier vs Advanced Tier

• Standard tier: free up to 10,000 parameters per account per region, 4 KB max value size, default rate limit of 40 transactions per second.
• Advanced tier: $0.05 per parameter per month, 8 KB max value size, supports parameter policies (expiration, expiration notification, no-change notification), higher throughput tiers.

Most secrets fit in standard tier. Use advanced when you need parameter policies (expiration, notification) or larger values.

String, StringList, SecureString

Parameter Store supports three types:

• String: plain-text key-value (max 4 KB standard / 8 KB advanced).
• StringList: comma-separated list of strings (queried as one string).
• SecureString: KMS-encrypted value. Decrypted at GetParameter time when caller passes WithDecryption=true and has KMS key permissions.

SecureString uses your specified KMS CMK or the AWS-managed aws/ssm key. For compliance, always use a customer-managed CMK; you control rotation, key policy, and audit.

Hierarchical Paths

Parameter names can be hierarchical: /myapp/prod/db/password, /myapp/staging/db/password, /myapp/prod/api/key. The hierarchy enables:

• IAM policies scoped to path prefix (Resource: arn:aws:ssm:us-east-1:123:parameter/myapp/prod/*)
• Bulk fetch via GetParametersByPath recursive
• Logical grouping mapped to environment, app, component

Parameter Versioning and Labels

Every parameter update creates a new version (1, 2, 3...). Versions are immutable; old versions remain accessible. Labels are named pointers to specific versions — LATEST, current, production-2025-04-01. Reference labels in clients to enable atomic-feeling rollback (MoveLabel current from version 5 to version 4 = instant rollback).

CloudWatch Events on Parameter Change

Parameter Store emits EventBridge events on parameter creation, update, deletion. Pattern: parameter change → EventBridge rule → Lambda updates downstream caches / triggers ECS service redeploy.

IAM Policy for Parameter Store

{
  "Effect": "Allow",
  "Action": ["ssm:GetParameter", "ssm:GetParameters", "ssm:GetParametersByPath"],
  "Resource": "arn:aws:ssm:us-east-1:123:parameter/myapp/prod/*",
  "Condition": { "StringEquals": { "ssm:RecursiveLevels": "5" } }
}

For SecureString, also grant kms:Decrypt on the encrypting key.

Secrets Manager — Built-In Rotation and Cross-Account Share

Secrets Manager is the specialized service when rotation, native RDS integration, or cross-account share matters.

Automatic Rotation Architecture

Secrets Manager rotation works via a Lambda function ("rotation function"):

1. Schedule (e.g., every 30 days) triggers the rotation Lambda.
2. Lambda runs four phases on the secret:
   • createSecret: generate a new credential (e.g., new password).
   • setSecret: update the credential at the source (e.g., RDS user password change).
   • testSecret: verify the new credential works.
   • finishSecret: mark the new version as AWSCURRENT; old version becomes AWSPREVIOUS.
3. Applications fetching the secret receive AWSCURRENT by default. Applications mid-flight with cached AWSPREVIOUS continue to work for the rotation window.

AWS-Managed Rotation Templates

For RDS MySQL/PostgreSQL/Aurora/Oracle/SQL Server, MariaDB, DocumentDB, Redshift, and Redshift Serverless, AWS publishes pre-built rotation Lambda templates. Just configure the rotation schedule and the rotation user; Secrets Manager provisions the Lambda from the template. No custom code needed for these services.

Single-User vs Multi-User Rotation

Two strategies for database credential rotation:

• Single-user: rotation Lambda updates the same user's password. Brief window where in-flight connections may fail (cached old password rejected). Simpler.
• Multi-user (alternating user): two database users (app_user_1, app_user_2). Rotation alternates which user is AWSCURRENT. Old user's connections drain naturally; new connections use new user. Zero-downtime for properly-implemented apps. Recommended for production.

DOP-C02 tests this distinction — multi-user is the correct answer for "zero-downtime rotation requirement."

Cross-Account Secret Sharing

Attach a resource policy to the secret in account A allowing principals from account B to call GetSecretValue:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222222222222:role/app-role" },
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "*"
}

KMS key must also allow account B (key policy or grant). Account B fetches the secret directly via GetSecretValue — no replication, no copy.

Multi-Region Replication

Secrets Manager replicates secrets to additional regions natively. Primary region is the writer; replicas are read-only. Rotation in primary auto-propagates to replicas. Use cases: multi-region active-active applications, DR-ready secret distribution. Pricing: $0.40 per replicated secret per month per region.

Soft Delete (7-30 Day Recovery)

Secrets Manager keeps deleted secrets in Pending Deletion state for 7-30 days (configurable). Recovery window protects against accidental deletion. Only after the window expires is the secret truly removed. KMS keys behave similarly with their 7-30 day window.

Cost Trade-Offs — When to Pay for Secrets Manager

DOP-C02 expects awareness of the cost gap.

Pricing Comparison

• Parameter Store standard: free for first 10k parameters, $0.05 per 10k API calls.
• Parameter Store advanced: $0.05 per parameter per month, $0.05 per 10k API calls.
• Secrets Manager: $0.40 per secret per month, $0.05 per 10k API calls.

For 1,000 secrets:

• Parameter Store standard: $0/month + API costs.
• Parameter Store advanced: $50/month + API costs.
• Secrets Manager: $400/month + API costs.

When the Cost Is Justified

Secrets Manager's $0.40 per secret pays for:

• Built-in rotation Lambda lifecycle.
• AWS-managed rotation templates for RDS/Aurora/Redshift.
• Resource policies for cross-account.
• Multi-region replication.
• Soft-delete recovery.

For a high-criticality production database secret, $0.40/month is trivial. For 1,000 application configuration parameters, Parameter Store at near-zero cost is correct.

Mixed Architecture

Most Pro-tier setups use both:

• Database passwords with auto-rotation: Secrets Manager.
• API keys requiring cross-account: Secrets Manager.
• Application configuration (timeouts, feature flags, endpoint URLs): Parameter Store.
• Static API endpoints, public values: Parameter Store String (no encryption).

Integration Patterns — ECS, CodeBuild, Lambda, CloudFormation

DOP-C02 expects detailed knowledge of how applications consume secrets.

ECS Task Definitions — Native Secret Reference

ECS task definitions support secrets (separate from environment):

"secrets": [
  {
    "name": "DB_PASSWORD",
    "valueFrom": "arn:aws:secretsmanager:us-east-1:123:secret:prod/db-AbCdEf"
  },
  {
    "name": "API_TIMEOUT",
    "valueFrom": "arn:aws:ssm:us-east-1:123:parameter/myapp/prod/api/timeout"
  }
]

ECS resolves the secret at task-start time and injects as environment variable in the container. The task execution role needs secretsmanager:GetSecretValue and/or ssm:GetParameters plus KMS decrypt. Secret values do not appear in task definitions or CloudTrail event details — only the ARN and resolution event.

CodeBuild — Environment Variable Reference

CodeBuild project environment variables can reference Secrets Manager and Parameter Store:

env:
  parameter-store:
    GITHUB_TOKEN: /myapp/build/github-token
  secrets-manager:
    DB_CREDENTIALS: prod/db:password

CodeBuild fetches at build start, injects as environment variables, available to buildspec phases. No secrets in repository, no secrets in build logs (CodeBuild masks them).

Lambda — Direct SDK Fetch or Layer-Cached

Lambda functions fetch secrets via SDK at cold start and cache in memory. Avoid fetching on every invocation (cost + latency). Pattern: module-scope client, fetch in init handler, cache for the lifetime of the warm container.

For deeper integration, AWS Lambda extensions can prefetch and cache secrets in a sidecar — the AWS Parameters and Secrets Lambda Extension provides local-HTTP-cache for Parameter Store and Secrets Manager values, reducing API calls 10-100x.

CloudFormation Dynamic References

CloudFormation supports inline references that resolve at stack-create/update time:

DBPassword: '{{resolve:secretsmanager:prod/db:SecretString:password}}'
ApiTimeout: '{{resolve:ssm:/myapp/prod/api/timeout:1}}'
ApiTimeoutSecure: '{{resolve:ssm-secure:/myapp/prod/api/key:2}}'

Three resolvers:

• ssm — Parameter Store String/StringList.
• ssm-secure — Parameter Store SecureString.
• secretsmanager — Secrets Manager secret (with optional JSON-key path).

The resolved value never appears in stack templates or CloudFormation events — only the reference syntax.

Rotation Strategies — Beyond the Defaults

Pro-tier rotation requires more nuance than "schedule every 30 days."

Cache-Aware Rotation

Applications often cache database credentials for connection-pool lifetime (hours). Rotation must coordinate with cache invalidation. Patterns:

• Multi-user alternating: rotation flips between two users. Old user's connections drain via natural connection-pool recycling.
• Application-aware refresh: application periodically refetches the secret (e.g., every 10 minutes). Cache invalidates faster than rotation cycle.
• Rotation-event-driven refresh: Secrets Manager rotation emits EventBridge event → triggers application service to refresh secret cache (e.g., ECS service redeploy).

Rotation Schedule Selection

• Compliance-driven: 30 days for PCI-DSS / SOC 2 / FedRAMP.
• Risk-based: 90 days for low-risk credentials.
• Automatic versus manual: most production secrets should auto-rotate; only high-impact credentials with complex coordination needs (master DB, root account) might warrant manual oversight.

Manual Rotation via API

RotateSecret triggers immediate rotation outside the schedule. Use cases: incident response (suspected compromise → immediate rotation), pre-rotation drills, compliance audit prep.

Cross-Account and Multi-Region Patterns

DOP-C02 Pro scenarios always involve multi-account or multi-region considerations.

Cross-Account Sharing via Resource Policy

Secrets Manager: attach resource policy on the secret. KMS key must also allow target account.

Parameter Store advanced tier supports limited cross-account sharing via Get* API and KMS key policy, but no native resource policy. For Pro-tier cross-account, Secrets Manager is the answer.

Multi-Region — Active-Active and DR

Secrets Manager replicates a primary secret to N additional regions. Replicas update on every primary rotation. Read-only in replica regions. Use cases: multi-region application reads from local replica; DR fail-over reads from local replica without extra steps.

Parameter Store has no native multi-region replication. Implementations use CloudFormation StackSets to deploy parameters to multiple regions, or custom Lambda to replicate on parameter change events.

Cross-Region KMS Considerations

KMS keys are regional. Multi-region secrets need:

• Multi-region KMS keys (newer feature) for one-key-many-regions, OR
• Per-region KMS key with replicated secret encrypted via that region's key.

Multi-region keys simplify the model — Secrets Manager replication handles the encryption seamlessly.

Pipeline Integration — The Canonical CI/CD Scenario

Putting it all together, the canonical DOP-C02 pipeline scenario.

Build Phase Secrets

CodeBuild project references parameter-store and secrets-manager values for:

• Source repository tokens (GitHub PAT) — Secrets Manager (rotation possible).
• Artifact-signing keys — Secrets Manager.
• License strings — Parameter Store SecureString (no rotation, low cost).
• Static config (build flags, target endpoints) — Parameter Store String.

Build role has secretsmanager:GetSecretValue on prod/build/* and ssm:GetParameters on /build/*.

Deploy Phase Secrets

CodeDeploy or CloudFormation injects secrets via:

• Dynamic references ({{resolve:secretsmanager:...}}) for resource properties.
• ECS task definitions with secrets array referencing Secrets Manager / Parameter Store.
• Lambda environment variables resolved via Lambda layer for runtime fetch.

Cross-Account Pipeline

Pipeline in tooling account deploys to staging account and production account. Each environment has its own secrets. Pipeline assumes role into target account; target account secrets accessible via the assumed role's permissions. The pipeline never holds production secret values in the tooling account.

常考陷阱 (Common Exam Traps)

DOP-C02 has predictable SSM Parameter Store and Secrets Manager rotation gotchas:

1. Picking Parameter Store when rotation is required — Parameter Store has no built-in rotation. Custom rotation via EventBridge + Lambda is operational toil. If the scenario says "rotate every 30 days," answer Secrets Manager.
2. Picking Secrets Manager for 10,000 config values — $4,000/month at full price. Use Parameter Store for non-rotating, non-cross-account, non-replicated configuration.
3. Single-user rotation on production with connection-pool apps — risk of cached-credential failures during rotation window. Multi-user alternating strategy is the correct production answer.
4. Forgetting KMS key permissions on cross-account access — secret resource policy alone is insufficient. KMS key policy must also allow the target account principal.
5. Embedding secret values in CloudFormation parameters — values appear in change sets and CloudFormation events. Use dynamic references ({{resolve:...}}) instead.
6. Reading SecureString without WithDecryption=true — returns ciphertext, not plaintext. Application breaks. Always set the parameter on the SDK call.
7. ECS task secret reference without execution role permissions — task fails to start. The task execution role (not the task role) needs secretsmanager:GetSecretValue + KMS decrypt.
8. Lambda fetching secrets on every invocation — expensive ($0.05 per 10k calls × 100M monthly invocations = $500/month). Cache at module scope or use Parameters and Secrets Lambda Extension.
9. Secrets Manager replication in regions with no KMS multi-region key — replication fails or uses default AWS-managed key. Always use multi-region CMK for replicated secrets.
10. No CloudTrail audit on secret access — all GetSecretValue and GetParameter calls are CloudTrail events. Always enable. Critical for incident-response audit.

FAQ

Q1: When should I use Parameter Store vs Secrets Manager? Parameter Store for low-cost, hierarchical, non-rotating configuration values and simple secrets. Secrets Manager for credentials requiring automatic rotation (especially RDS/Aurora), cross-account sharing via resource policy, or multi-region replication. Pro-tier setups mix both — Parameter Store for application config, Secrets Manager for credentials.

Q2: How does automatic rotation in Secrets Manager work? A Lambda function runs on a schedule (e.g., every 30 days). The Lambda performs four phases — createSecret, setSecret, testSecret, finishSecret — to generate a new credential, update the credential at the source (RDS, Aurora, etc.), verify, and promote. AWS publishes pre-built Lambda templates for RDS, Aurora, Redshift, DocumentDB. Custom Lambdas implement other services.

Q3: What's single-user vs multi-user rotation? Single-user: rotation updates the same user's password. Brief window where cached credentials may fail. Multi-user (alternating): two users, rotation alternates which is current. Old user's connections drain naturally. Multi-user is recommended for production zero-downtime requirements; DOP-C02 tests this distinction.

Q4: Can I share a Parameter Store secret across accounts? Limited. Parameter Store advanced tier supports cross-account access via GetParameters if the consumer has permissions and the KMS key allows them, but no native resource policy. For first-class cross-account sharing, use Secrets Manager which has resource policies on each secret.

Q5: How do I inject secrets into an ECS task without environment-variable leakage? Use the task definition secrets block (separate from environment) referencing Parameter Store or Secrets Manager ARNs. ECS resolves at task start, injects into the container. Values do not appear in task definitions, CloudTrail call details, or DescribeTaskDefinition output. Task execution role needs GetSecretValue / GetParameters + KMS.

Q6: How do CloudFormation dynamic references work for secrets? Three resolvers: {{resolve:ssm:<name>:<version>}} for Parameter Store String/StringList; {{resolve:ssm-secure:<name>:<version>}} for SecureString; {{resolve:secretsmanager:<name>:<json-key>:<version-stage>:<version-id>}} for Secrets Manager. Resolved at stack-create/update time. Resolved values never appear in templates, change sets, or events. Not all resource properties support dynamic references — check the property reference.

Q7: How do I handle Lambda functions calling Secrets Manager on every invocation? Cache secrets at module scope (initialised once per warm container). Even better: use the AWS Parameters and Secrets Lambda Extension, a pre-built layer that caches Parameter Store and Secrets Manager values locally and serves them via HTTP from inside the Lambda execution environment. Reduces API calls 10-100x.

Q8: Can I replicate Parameter Store across regions automatically? No native multi-region replication. Workarounds: CloudFormation StackSets deploying parameters to multiple regions, or custom Lambda triggered by parameter change EventBridge events that PutParameter in target regions. Operational overhead. For multi-region, Secrets Manager native replication is preferred.

Q9: How do I rotate a secret manually outside the schedule? Call the RotateSecret API. Triggers an immediate rotation cycle through the Lambda. Use cases: incident response (suspected credential compromise), pre-audit rotation drill, validation of rotation function after Lambda code update.

Q10: How do I audit who fetched which secret? CloudTrail records every GetSecretValue (Secrets Manager) and GetParameter (Parameter Store) call with the requesting principal, source IP, target ARN, and timestamp. Pro-tier setups deliver these events to CloudTrail Lake for SQL queries like "every access to prod/db credentials in the past 30 days, grouped by principal." Critical for incident response.

Summary — SSM Parameter Store and Secrets Manager Rotation Mental Model

SSM Parameter Store and Secrets Manager rotation cover the full spectrum from cheap hierarchical configuration to fully-rotating cross-region credentials. On DOP-C02 Tasks 6.1, 6.2, and 1.1, the right answer combines the right service (Parameter Store for cheap/hierarchical/non-rotating; Secrets Manager for rotation/cross-account/multi-region), the right encryption (customer-managed KMS CMK for compliance), and the right consumption pattern (CloudFormation dynamic reference, ECS task secret, IAM-protected SDK fetch with caching). Every Pro-tier secrets scenario blends three or more of these.

The mature DOP-C02 answer pattern is mixed and explicit: Parameter Store for the 10,000 config entries that never rotate, Secrets Manager for the 50 credentials that must rotate every 30 days; ECS task secrets block for runtime injection; CloudFormation dynamic references for IaC; Lambda Parameters and Secrets Extension for hot-cached fetch; CloudTrail for audit; cross-account resource policies on shared secrets; multi-region replication on credentials needed across regions; multi-user alternating rotation for zero-downtime. Single-service answers are Pro-tier distractors.