Secrets Credentials Key Management

AWS secrets, credentials, and key management is the bundle of AWS services and patterns that protect long-lived credentials, application secrets, and cryptographic key material across an AWS environment. The flagship AWS services are AWS Secrets Manager for application secrets that need automated rotation, AWS Systems Manager Parameter Store for hierarchical configuration with optional encryption, and AWS Key Management Service (AWS KMS) for the cryptographic keys that wrap every secret, every Parameter Store SecureString, every Amazon EBS volume, every Amazon S3 SSE-KMS object, and every Amazon RDS database. Together they form the AWS secrets, credentials, and key management layer that SCS-C02 Domain 5 Task Statement 5.4 expects you to design, operate, and troubleshoot under exam pressure.

The exam guide phrases Task 5.4 as "Design and implement controls to protect credentials, secrets, and cryptographic key materials," and the knowledge bullets call out Secrets Manager, Systems Manager Parameter Store, and the usage and management of symmetric and asymmetric keys via AWS KMS. The skills bullets escalate to designing rotation, designing AWS KMS key policies that limit usage to authorized users, and establishing mechanisms to import and remove customer-provided key material. This guide walks every construct end-to-end, with exam traps, plain-language analogies, and a rotation-troubleshooting playbook so AWS secrets, credentials, and key management stops being a guessing game on test day.

What Is AWS Secrets, Credentials, and Key Management?

AWS secrets, credentials, and key management is the AWS-native framework that prevents long-lived secrets and key material from leaking into source code, configuration files, and Amazon EC2 user data. Application credentials such as database passwords, API tokens, OAuth client secrets, and TLS private keys live in AWS Secrets Manager when they need automatic rotation, or in AWS Systems Manager Parameter Store when they are static configuration values. Cryptographic keys that wrap those secrets and that protect data at rest live in AWS KMS, with AWS CloudHSM as the single-tenant FIPS 140-2 Level 3 escape hatch.

Three problems define the design space. First, secrets must rotate so that a leaked credential becomes worthless quickly; AWS Secrets Manager solves this with managed rotation Lambda functions. Second, secrets must be retrievable by workloads without ever appearing in plaintext on disk; AWS Secrets Manager and AWS Systems Manager Parameter Store both expose SDK-fetched, in-memory delivery. Third, the key that protects all those secrets must itself be guarded, audited, and rotated; AWS KMS provides envelope encryption, key policies, grants, and automatic key rotation to close that gap. AWS secrets, credentials, and key management is the union of all three answers.

Why AWS secrets, credentials, and key management matters for SCS-C02

Domain 5 (Data Protection) is 18% of the SCS-C02 exam, and Task 5.4 is roughly a quarter of that domain. Question writers love scenarios that test: "rotation Lambda fails to reach the database — what's wrong?" (VPC reachability or rotation Lambda IAM), "team needs cross-account access to a customer-managed AWS KMS key — what's the minimum config?" (key policy plus identity policy), "team must use their own key material and revoke it on demand — which AWS KMS feature?" (imported key material), and "company stores OAuth client secrets that never change — Secrets Manager or Parameter Store?" (Parameter Store SecureString unless rotation is required). Get those four families right and AWS secrets, credentials, and key management becomes a high-yield study area.

Plain-Language Explanation: AWS Secrets, Credentials, and Key Management

AWS secrets, credentials, and key management is dense, so concrete analogies do most of the work. Here are four distinct analogies that together cover every construct in Task 5.4.

Analogy 1: The Hotel Concierge with Rotating Master Keys (Secrets Manager rotation)

Picture a luxury hotel. Every guest room (your application) needs a working keycard to open the database room down the hall. AWS Secrets Manager is the concierge desk that holds every keycard ever issued, and the rotation Lambda function is the night-shift bellhop who, on a fixed schedule, walks down to the database lock, programs a new keycard, hands the new card to the concierge, then deactivates the old one. While that handover happens, the concierge labels the cards AWSCURRENT (the active one), AWSPENDING (the new one being tested), and AWSPREVIOUS (the recently retired one) so guests who already had a card in hand can still get into the room until the bellhop confirms the swap. If the bellhop can't reach the database room (network blocked) or doesn't have permission to reprogram the lock (IAM), the rotation fails, the concierge raises an Amazon CloudWatch alarm, and a human operator has to investigate. AWS-managed rotation templates exist for popular AWS services like Amazon RDS and Amazon Aurora, and you can write a custom rotation Lambda for any other secret.

Analogy 2: The Library Card Catalog vs the Concierge Desk (Parameter Store vs Secrets Manager)

Imagine the same hotel also has a library in the lobby. The library card catalog is AWS Systems Manager Parameter Store — a hierarchical filing system where every drawer (/prod/db/host, /prod/db/port, /prod/db/password) holds a small index card. Most cards are public information (host, port, region) and live in plain manila folders (String parameters). A few cards hold sensitive values (an API token, a TLS key) and live in locked drawers (SecureString parameters) whose locks are controlled by AWS KMS. The library does not employ a bellhop — Parameter Store does not rotate values for you. The concierge desk is AWS Secrets Manager, more expensive but staffed 24/7 with a rotation bellhop. So the rule of thumb: rotation needed → concierge (Secrets Manager); static config that may include a few sensitive values → library (Parameter Store). The library is free for the standard tier and charges only for the advanced tier; the concierge charges roughly USD 0.40 per secret per month plus API fees.

Analogy 3: The Bank Vault with Two Kinds of Keys (KMS symmetric vs asymmetric)

Picture a bank with two key cabinets. The symmetric key cabinet holds keys that lock and unlock with the same metal key — one piece of brass for each safe deposit box. AWS KMS symmetric keys behave that way: one 256-bit AES-GCM key encrypts and decrypts, and the key material never leaves AWS KMS. The asymmetric key cabinet holds paired keys: a public key that anyone can copy and a private key that the bank guards. AWS KMS asymmetric keys behave that way: RSA or ECC pairs whose public half can be exported and distributed (so customers can encrypt or verify signatures off-platform), while the private half stays inside AWS KMS. You pick symmetric for everyday encrypt/decrypt and for AWS service integration (Amazon S3, Amazon EBS, Amazon RDS all want symmetric AWS KMS keys). You pick asymmetric for digital signing, signature verification, and for encrypt/decrypt scenarios where the encrypter must not have the decryption key.

Analogy 4: The Open-Book Exam vs the Toolbox (BYOK vs auto rotation vs manual rotation)

Think of AWS KMS rotation like an exam. Automatic key rotation is an open-book exam with a pre-loaded reference sheet — AWS KMS automatically generates new key material for a customer-managed symmetric key every 365 days (or on a configurable 90-to-2560-day schedule), keeps the old material around so prior ciphertext still decrypts, and your applications never notice because the key ID and ARN do not change. Manual rotation is a toolbox approach — you create a new AWS KMS key, point an alias from the old key to the new, and re-encrypt anything you want covered by the new material. Imported key material (BYOK) is a bring-your-own-textbook exam — you generate the key material outside AWS, wrap it with a public key AWS KMS gives you, import it, set an expiration of up to 384 days, and either re-import or roll to a new key when material expires. BYOK does not support automatic rotation. The trade-off: BYOK gives you maximum custody (you can withdraw the key material) but adds operational overhead (you must re-import or rotate manually).

AWS Secrets Manager Deep Dive

AWS Secrets Manager is the AWS service of choice when a secret needs automated rotation, audit, and integration with database engines. It stores the secret encrypted under an AWS KMS key (the AWS-managed aws/secretsmanager key by default, or any customer-managed AWS KMS key you select), versions every value, and applies staging labels (AWSCURRENT, AWSPENDING, AWSPREVIOUS) so that callers always read a known-good version while a rotation is in flight.

Native rotation for AWS-managed databases

For five AWS services, AWS Secrets Manager ships pre-built rotation Lambda templates: Amazon RDS (all supported engines), Amazon Aurora, Amazon Redshift, Amazon DocumentDB, and Amazon ElastiCache for Valkey/Redis. You enable rotation, choose a schedule (for example, every 30 days), and AWS Secrets Manager wires up the Lambda, the IAM role, and the KMS permissions. The Lambda calls the database engine's password-change API on each rotation, updates the secret, and Amazon CloudWatch records the success or failure event.

Three rotation Lambda strategies

The rotation Lambda implements one of three strategies, each suited to a different application architecture. Understanding which strategy applies is a frequent SCS-C02 exam question.

• Single-user rotation. One database user. The Lambda changes that user's password each rotation. Simplest pattern but every active connection that holds an open session keeps working until it disconnects; brand-new connections during the swap window may briefly see the wrong password if the application reconnects mid-rotation.
• Alternating-user rotation. Two database users (appuser_a and appuser_b) clone the same permissions. The Lambda rotates one user's password while the other remains usable, then flips the staging labels so the application transparently picks up the new active user on the next read. This eliminates the brief outage window of single-user rotation. Recommended for production OLTP workloads.
• Master-user rotation. A privileged "master" user (whose credentials live in a separate Secrets Manager secret) is used to change the application user's password. The application user has no privilege to change its own password, which satisfies stricter separation-of-duties requirements.

Custom rotation Lambdas for any secret

Beyond the AWS-managed five, you can write a custom rotation Lambda for any secret — third-party API tokens, SaaS keys, on-premises database passwords, or even Active Directory service account passwords. The Lambda implements four steps: createSecret, setSecret, testSecret, finishSecret. AWS Secrets Manager invokes the Lambda for each step in sequence and uses the staging labels to track progress.

Cross-account and cross-Region secret sharing

AWS Secrets Manager supports resource policies on each secret, so you can grant a principal in another AWS account the ability to call secretsmanager:GetSecretValue on the secret. For multi-Region applications, AWS Secrets Manager supports automatic cross-Region replication: the primary secret in us-east-1 continuously replicates to eu-west-1, and rotation events on the primary propagate to the replica. Cross-Region replication is unique to AWS Secrets Manager — AWS Systems Manager Parameter Store does not natively replicate.

Detecting rotation failures

A failed rotation is a security incident: the existing credential is still valid (so the application keeps working) but the rotation cadence is broken (so the credential is older than your policy allows). AWS Secrets Manager publishes the metric RotationFailed and the Amazon EventBridge event Rotation Failed whenever a rotation does not complete successfully. The recommended SCS-C02 design is an Amazon CloudWatch alarm on RotationFailed plus an Amazon EventBridge rule that forwards the event to Amazon SNS or AWS Security Hub so an on-call engineer is notified within minutes.

AWS Systems Manager Parameter Store Deep Dive

AWS Systems Manager Parameter Store is the AWS service for hierarchical configuration values. It supports three parameter types: String, StringList, and SecureString. Only SecureString invokes AWS KMS.

Standard tier vs Advanced tier

AWS Systems Manager Parameter Store has two tiers. The Standard tier is free, supports up to 10,000 parameters per AWS account per AWS Region, with a 4 KB value limit. The Advanced tier is USD 0.05 per advanced parameter per month, supports up to 100,000 parameters, with an 8 KB value limit, and adds parameter policies (TTL expiration, expiration notification, no-change notification). For most workloads the Standard tier is sufficient; you upgrade to Advanced only when you need parameter policies or larger values.

SecureString and AWS KMS

A SecureString parameter is encrypted at rest with an AWS KMS key — the AWS-managed aws/ssm key by default, or a customer-managed AWS KMS key you specify. The AWS KMS key encrypts the value with envelope encryption: AWS Systems Manager calls kms:GenerateDataKey, encrypts the value with the data key locally, and stores the encrypted data key alongside the ciphertext. Retrieval requires kms:Decrypt on the AWS KMS key plus ssm:GetParameter on the parameter, so two layers of authorization protect every read.

Hierarchical naming and IAM scoping

Parameter Store enforces a path-style naming convention: /prod/web/db/password, /prod/web/db/host, /staging/api/token. The hierarchy is the foundation of fine-grained AWS IAM policies — you can grant a principal ssm:GetParametersByPath on arn:aws:ssm:us-east-1:123456789012:parameter/prod/web/* and the principal can read every prod web parameter without you naming each one. This pattern is central to multi-environment deployments and is favored on SCS-C02 over flat-named parameter stores.

Parameter policies (Advanced tier only)

Parameter policies attached to Advanced parameters can do three things: Expiration (auto-delete the parameter at a future timestamp), ExpirationNotification (Amazon EventBridge event N days before expiration so you can rotate the value), and NoChangeNotification (Amazon EventBridge event if the parameter has not changed in N days so you can detect stale config). Parameter policies are the closest Parameter Store gets to native rotation — they alert you, but they do not change the value automatically the way an AWS Secrets Manager rotation Lambda does.

AWS KMS Symmetric Keys

Symmetric keys are the workhorse of AWS secrets, credentials, and key management. Every native AWS service integration that says "encrypted with AWS KMS" — Amazon S3 SSE-KMS, Amazon EBS encryption, Amazon RDS encryption, Amazon DynamoDB encryption, AWS Secrets Manager, AWS Systems Manager Parameter Store SecureString — is using a symmetric AWS KMS key under the hood.

Properties of symmetric AWS KMS keys

A symmetric AWS KMS key is a 256-bit AES key used in GCM mode. The key material is generated by AWS KMS inside its FIPS 140-2 validated hardware boundary, and it never leaves that boundary in plaintext. Each AWS KMS key is scoped to one AWS Region (with the special exception of Multi-Region Keys, covered below). The supported operations are Encrypt, Decrypt, GenerateDataKey, GenerateDataKeyPair, GenerateRandom, ReEncrypt, and the various administrative operations.

Key spec and origin

You choose the key spec (SYMMETRIC_DEFAULT for symmetric AES-256-GCM) and the origin:

• AWS_KMS — AWS KMS generates and owns the material; required for automatic rotation.
• EXTERNAL — you import key material; symmetric only, no automatic rotation.
• AWS_CLOUDHSM — material lives in your AWS CloudHSM custom key store; single-tenant FIPS 140-2 Level 3.
• EXTERNAL_KEY_STORE — material lives in an external HSM behind a proxy; for hybrid sovereignty workloads.

Multi-Region Keys (MRK)

A Multi-Region Key is a customer-managed AWS KMS key replicated across multiple AWS Regions while sharing the same key ID and key material. The MRK in us-east-1 and its replica in eu-west-1 can encrypt and decrypt the same ciphertext interchangeably, which simplifies cross-Region failover for AWS services that store ciphertext (Amazon DynamoDB Global Tables, Amazon S3 Cross-Region Replication). Rotation of an MRK rotates the key material in every Region in lockstep. Without MRKs, cross-Region failover requires re-encrypting the ciphertext with the destination Region's AWS KMS key.

AWS KMS Asymmetric Keys

Asymmetric AWS KMS keys exist for two specific use cases: digital signing/verification and encrypt/decrypt where the encrypter must not have the decryption key.

Key specs for asymmetric AWS KMS keys

• RSA_2048, RSA_3072, RSA_4096 — RSA key pairs for signing or encryption.
• ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521 — NIST elliptic curves for signing.
• ECC_SECG_P256K1 — the curve used by Bitcoin and other cryptocurrencies for signing.
• SM2 (China Regions only) — Chinese government-approved signing/encryption.
• HMAC_224, HMAC_256, HMAC_384, HMAC_512 — symmetric HMAC keys for message authentication codes (technically symmetric, often grouped with asymmetric in exam coverage because they are signing keys, not encryption keys).

Key usage modes

You declare each asymmetric AWS KMS key with a key usage of either SIGN_VERIFY or ENCRYPT_DECRYPT. The two modes are mutually exclusive on a single AWS KMS key — you cannot use the same RSA key for both signing and encryption. SCS-C02 traps frequently surface this: a question gives you a signing AWS KMS key and asks "why does encrypt fail?" The answer is the key's KeyUsage is SIGN_VERIFY, not ENCRYPT_DECRYPT.

Public key extraction

The public half of any asymmetric AWS KMS key can be exported via kms:GetPublicKey and distributed freely — clients can verify signatures or encrypt data that only the AWS KMS-resident private key can decrypt. This is the foundation of patterns like JWT signing where mobile clients verify a token's signature without ever seeing the private key.

AWS KMS Key Rotation — Automatic vs Manual

Rotation changes the underlying cryptographic material while preserving the AWS KMS key's identity (key ID and ARN). It is one of the most-tested single facts on SCS-C02 and is central to the Task 5.4 skill bullet "Designing management and rotation of secrets for workloads ... AWS KMS customer managed keys".

Automatic rotation

For customer-managed symmetric AWS KMS keys with Origin = AWS_KMS, you can enable automatic key rotation. AWS KMS rotates the underlying cryptographic material every 365 days by default, configurable between 90 and 2,560 days since 2024. Critically:

• The AWS KMS key ID and ARN do not change — applications keep referencing the same ARN.
• Old key material is retained so previously encrypted data can still be decrypted.
• Rotation is transparent — no re-encryption of existing data is needed.
• AWS-managed keys rotate automatically every year and you cannot turn this off (nor modify the period).
• Automatic rotation is only available for symmetric AWS KMS keys with AWS-owned material — asymmetric keys and imported-material keys cannot use it.

Manual rotation (alias-based)

For asymmetric AWS KMS keys, AWS KMS keys with imported key material, and any scenario where automatic rotation is unavailable, the rotation pattern is alias-based manual rotation:

1. Create a brand new AWS KMS key with fresh material.
2. Update the alias (alias/my-app-key) to point at the new AWS KMS key.
3. Re-encrypt any ciphertext you want covered by the new material (or accept that legacy ciphertext stays under the old key).

Applications that reference the alias rather than the underlying key ID continue to work without code changes. The old AWS KMS key remains in Enabled state so older ciphertext can still decrypt.

Multi-Region Key rotation

When you enable automatic rotation on a Multi-Region primary key, the rotation propagates to every replica in every AWS Region — they share key material by definition. You only enable rotation on the primary; the replicas inherit it. This is one of the operational reasons MRKs are favored over per-Region key duplication.

Importing Customer-Provided Key Material (BYOK)

Bring Your Own Key (BYOK) lets you generate the key bytes outside AWS, import them into an AWS KMS key, and retain a master copy so you can later revoke access by deleting the imported material. The Task 5.4 skill bullet "Establishing mechanisms to import and remove customer-provided key material" maps directly to this feature.

The BYOK workflow

1. Create an AWS KMS key with Origin = EXTERNAL and key spec SYMMETRIC_DEFAULT. The key starts in PendingImport state and cannot encrypt or decrypt yet.
2. Call kms:GetParametersForImport to retrieve a public wrapping key and a one-time-use import token. The wrapping key is RSA-2048, RSA-3072, or RSA-4096; the import token expires in 24 hours.
3. Generate a 256-bit AES key on your side (using your on-premises HSM, OpenSSL, or any FIPS-validated source).
4. Wrap your key bytes with the public wrapping key (RSA-OAEP padding) and call kms:ImportKeyMaterial with the wrapped bytes, the import token, and an optional expiration timestamp (up to 384 days from import).
5. The AWS KMS key transitions to Enabled and works for encrypt/decrypt with applications that reference its ARN.

Removing imported key material

You can call kms:DeleteImportedKeyMaterial at any time. The AWS KMS key immediately transitions to PendingImport and stops decrypting ciphertext. Any data previously encrypted with that material becomes unrecoverable until you re-import the identical key bytes (you must keep your master copy outside AWS). This is the SCS-C02 "kill switch" pattern: a regulator can demand you sever AWS access to the key material in seconds, by deleting the imported bytes from AWS KMS.

BYOK constraints

• Symmetric only. Asymmetric AWS KMS keys cannot use imported material.
• No automatic rotation. You must rotate manually by importing new key material into a new AWS KMS key and updating the alias.
• Maximum 384-day validity. Imported material expires; you set the expiration at import time. Before expiry you must re-import (the same bytes or new bytes — re-importing the same bytes resets the expiry, which AWS KMS calls "rewrapping").
• Same Region only. Imported material does not replicate to MRK replicas — each replica needs its own import.

AWS KMS Key Policies — The Primary Access Control

Every AWS KMS key has a key policy — a JSON document attached directly to the AWS KMS key. Unlike Amazon S3 or Amazon DynamoDB, AWS KMS treats the key policy as the primary access control mechanism. Without an explicit allow in the key policy, no AWS IAM policy and no grant can authorize an AWS KMS action.

The default key policy and the IAM delegation statement

When you create a customer-managed AWS KMS key in the AWS console, the default key policy contains two important statements: a root delegation statement that gives kms:* to the AWS account root (so the account owner can never lose control of the key), and the "Enable IAM policies" statement that delegates authorization to AWS IAM by allowing principals in the same AWS account to call any AWS KMS action provided their AWS IAM policy explicitly allows it. The IAM delegation statement is what makes AWS KMS feel like other AWS services — but it is opt-in. If you remove that statement, AWS IAM policies stop working on this AWS KMS key, and only principals named explicitly in the key policy can use it. This is the recommended hardening for highly sensitive AWS KMS keys.

Cross-account AWS KMS key access

For an AWS principal in Account B to use an AWS KMS key owned by Account A, two pieces must align:

1. Account A's key policy must explicitly allow the Account B principal (or the Account B account root) to call the desired AWS KMS actions. This is the gate; without it, nothing works.
2. Account B's identity policy must grant that principal the same AWS KMS actions on the Account A AWS KMS key ARN. This is a normal AWS IAM grant from the consumer side.

Both layers must allow the action; either layer's silence is a deny. This dual-policy model surfaces in cross-account Amazon S3 SSE-KMS scenarios constantly: a bucket in Account A encrypted with a customer-managed AWS KMS key in Account A, and a consumer in Account B trying to read it. If either the AWS KMS key policy or the Account B identity policy is missing the grant, the GetObject fails with AccessDeniedException referencing AWS KMS rather than Amazon S3.

AWS-managed CMK cannot be shared cross-account

A frequent SCS-C02 trap: the question proposes encrypting a shared Amazon S3 bucket with the AWS-managed key aws/s3 and granting cross-account access. This does not work. AWS-managed AWS KMS keys (aws/s3, aws/ebs, aws/rds, aws/secretsmanager) have a fixed key policy that you cannot edit, and that key policy does not grant access to other AWS accounts. The fix is to use a customer-managed AWS KMS key whose key policy you can edit to grant cross-account access.

AWS KMS Grants — Temporary Permission Delegation

A grant is a temporary, programmatic AWS KMS permission delegation from one principal to another. Grants are additive to key policies and IAM policies; they never override an explicit deny in the key policy.

When grants are used

Grants exist primarily for AWS service integrations. When you launch an Amazon EC2 instance with an encrypted Amazon EBS volume, Amazon EBS creates a grant on the AWS KMS key scoped to exactly that volume so the AWS service can decrypt it on the EC2 instance's behalf. When AWS Lambda is configured with an encrypted environment variable, Lambda creates a grant. The grants are short-lived in the sense that you can retire them with kms:RetireGrant or kms:RevokeGrant.

Grant constraints and the encryption context

A grant can be scoped to specific operations (grantee operations), specific grantee principals, and specific encryption contexts — additional authenticated data passed to encrypt/decrypt calls. Encryption context is one of the most powerful AWS KMS features: by requiring that any decrypt call against a grant include a specific encryption context (for example, tenant=acme-corp), you defend against confused-deputy attacks where a grantee tries to use the AWS KMS key for the wrong tenant's data.

ListGrants and grant lifecycle

kms:ListGrants returns every grant on an AWS KMS key, which is essential during incident response when a key has been compromised — you want to enumerate every active grant and revoke them. Service-linked roles auto-create grants, so the list often includes entries you did not create yourself; review carefully before mass-revoking.

Common Traps and Exam Patterns

SCS-C02 questions on AWS secrets, credentials, and key management cluster around a small set of distinguishing facts. Memorize these and you neutralize most distractors.

Trap 1: AWS-managed CMK cannot be customized or shared cross-account

The keys with aliases aws/s3, aws/ebs, aws/rds, aws/dynamodb, aws/secretsmanager, aws/ssm are AWS-managed. You cannot edit their key policy, you cannot share them cross-account, and you cannot disable their automatic annual rotation. If the scenario needs cross-account, custom audit, or a tailored key policy, the answer is a customer-managed AWS KMS key.

Trap 2: Symmetric vs asymmetric for AWS service integration

AWS service integrations (Amazon S3 SSE-KMS, Amazon EBS, Amazon RDS, Amazon DynamoDB, AWS Secrets Manager, AWS Systems Manager Parameter Store SecureString) require symmetric AWS KMS keys. Asymmetric AWS KMS keys are for application-level signing/verification or for encrypt/decrypt scenarios where the encrypter must not have the decryption key.

Trap 3: Imported-material keys do not auto-rotate

Imported-material AWS KMS keys (BYOK) cannot use automatic rotation. If the scenario says "we use BYOK and rotate every 90 days", the rotation is manual — alias re-pointing or re-import. Question writers like to put "enable automatic rotation on the imported key" as a distractor; reject it.

Trap 4: Parameter Store does not auto-rotate values

Parameter Store SecureString encrypts values at rest with AWS KMS, but it does not rotate the value automatically. If the scenario requires automated credential rotation, the answer is AWS Secrets Manager or a custom Lambda you write yourself; Parameter Store alone is insufficient.

Trap 5: Rotation Lambda must reach the database

Failed rotation is almost always one of two causes: (1) the rotation Lambda's IAM role lacks permissions on the secret, the AWS KMS key, or the database engine API; (2) the rotation Lambda runs outside the database's Amazon VPC and cannot reach the database port. If the question describes "rotation has not completed for 7 days", check VPC reachability first, then IAM.

Trap 6: Encryption context is part of the ciphertext

If you encrypt with EncryptionContext = {tenant=acme} you must decrypt with the exact same context. The context is not stored in the ciphertext header — your application must remember and supply it. Question writers test this by describing an application that drops the encryption context on retrieve and asking why decrypt fails.

Decision Framework: Pick the Right AWS Service

Use this decision tree to triage SCS-C02 scenarios in seconds.

1. Does the secret need automated rotation? Yes → AWS Secrets Manager. No → consider AWS Systems Manager Parameter Store SecureString first.
2. Does the secret need cross-Region replication? Yes → AWS Secrets Manager (native replication). No → either service is fine.
3. Are you storing thousands of small config values, mostly non-sensitive? Yes → AWS Systems Manager Parameter Store Standard tier (free).
4. Does the cryptographic key need to be FIPS 140-2 Level 3 single-tenant hardware? Yes → AWS CloudHSM (or AWS KMS custom key store backed by AWS CloudHSM). No → AWS KMS customer-managed key.
5. Must the customer retain a master copy of the key material outside AWS? Yes → AWS KMS imported key material (BYOK). No → AWS_KMS origin (allows automatic rotation).
6. Is the AWS KMS key being used by an AWS service integration (Amazon S3, Amazon EBS, Amazon RDS)? Yes → symmetric, SYMMETRIC_DEFAULT. No, you're calling KMS API directly for signing? → asymmetric.
7. Cross-account or cross-Region access needed? Customer-managed AWS KMS key with edited key policy plus consumer-side identity policy. AWS-managed keys cannot be shared cross-account.

FAQ

How does AWS Secrets Manager differ from AWS Systems Manager Parameter Store?

AWS Secrets Manager provides built-in automated rotation via Lambda functions, integrates natively with Amazon RDS/Aurora/DocumentDB/Redshift/ElastiCache, and supports cross-Region replication. It costs roughly USD 0.40 per secret per month plus API fees. AWS Systems Manager Parameter Store provides hierarchical configuration storage with a free Standard tier and an Advanced tier (USD 0.05 per advanced parameter) but does not rotate values automatically. Use AWS Secrets Manager when rotation is mandatory; use AWS Systems Manager Parameter Store SecureString for static credentials and configuration that change rarely.

Can I use an asymmetric AWS KMS key for Amazon S3 SSE-KMS or Amazon EBS encryption?

No. AWS service integrations like Amazon S3 SSE-KMS, Amazon EBS encryption, Amazon RDS encryption, AWS Secrets Manager, and AWS Systems Manager Parameter Store SecureString require symmetric AWS KMS keys with key spec SYMMETRIC_DEFAULT. Asymmetric AWS KMS keys (RSA, ECC) are reserved for application-level signing/verification or for encrypt/decrypt scenarios where the encrypter must not possess the private key.

Why does my rotation Lambda fail with a timeout?

Two root causes dominate. First, the rotation Lambda must run inside the same Amazon VPC as the target database (or have a route to it via VPC peering, AWS Transit Gateway, or VPC endpoints) with a security group permitted to reach the database port. Second, the rotation Lambda's execution role must have secretsmanager:UpdateSecretVersionStage, secretsmanager:DescribeSecret, secretsmanager:GetSecretValue, secretsmanager:PutSecretValue, plus kms:Decrypt and kms:GenerateDataKey on the AWS KMS key encrypting the secret. Wire up an Amazon CloudWatch alarm on the RotationFailed metric so failures surface immediately.

Can I enable automatic rotation on an AWS KMS key with imported key material?

No. Imported key material (BYOK) does not support AWS KMS automatic rotation. To rotate a BYOK key, you must either (a) re-import fresh key material into a new AWS KMS key and update the alias, or (b) re-import the same material to extend the expiration up to another 384 days (this is sometimes called "rewrapping"). Automatic rotation is only available for customer-managed symmetric AWS KMS keys with Origin = AWS_KMS.

How do I grant cross-account access to an AWS KMS key?

Two pieces must align. First, the AWS KMS key's key policy in the owning account must explicitly allow the external account principal (or the external account's root) to call the desired AWS KMS actions — without this, nothing works. Second, the identity-based policy in the consumer account must grant the same AWS KMS actions on the AWS KMS key's ARN. Both must allow the action; either's silence is a deny. AWS-managed AWS KMS keys (aws/s3, aws/ebs, etc.) cannot be shared cross-account because their key policy is fixed — use a customer-managed AWS KMS key instead.

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

AWS Secrets Manager attaches staging labels to each secret version during rotation. AWSCURRENT marks the version that applications retrieve when they call GetSecretValue without specifying a version. AWSPENDING marks a new version created by the rotation Lambda's createSecret step but not yet activated; the Lambda's setSecret and testSecret steps validate it. AWSPREVIOUS marks the version that was AWSCURRENT immediately before the most recent rotation; it remains retrievable for short windows so applications with cached connections can finish work. Once rotation completes, the labels shift atomically: the old AWSCURRENT becomes AWSPREVIOUS, and AWSPENDING becomes the new AWSCURRENT.

When should I use AWS CloudHSM instead of AWS KMS?

Pick AWS CloudHSM when (a) regulators require single-tenant FIPS 140-2 Level 3 hardware with no shared multi-tenant boundary, (b) on-premises applications need a standard PKCS #11, JCE, or Microsoft CNG API that AWS KMS does not expose, or (c) you must perform cryptographic operations AWS KMS does not support (legacy 3DES, certain custom curves). For everything else, AWS KMS is fully managed, cheaper, and integrates with every AWS service. You can also link an AWS CloudHSM cluster as an AWS KMS custom key store to get the AWS KMS API surface with single-tenant key material.

Can a Multi-Region Key be used for cross-Region Amazon S3 SSE-KMS replication?

Yes — and it is the recommended pattern. With a Multi-Region Key (MRK), the primary in us-east-1 and the replica in eu-west-1 share the same key ID and key material, so an Amazon S3 object encrypted with the primary can be replicated to the destination bucket and decrypted there with the replica without re-encryption. Without an MRK, Amazon S3 must call kms:ReEncrypt to convert ciphertext from the source-Region AWS KMS key to the destination-Region AWS KMS key, which adds latency and cost.

Summary

AWS secrets, credentials, and key management — Domain 5 Task 5.4 — bundles three AWS services that work in lockstep: AWS Secrets Manager (rotation, native database integration, cross-Region replication), AWS Systems Manager Parameter Store (hierarchical config with optional SecureString encryption), and AWS KMS (the cryptographic spine that wraps everything else, with symmetric vs asymmetric key specs, automatic vs manual rotation, BYOK imported material, key policies, grants, and Multi-Region Keys). Master the rotation Lambda failure modes, the dual-policy cross-account AWS KMS pattern, the BYOK lifecycle, and the symmetric-required AWS service integrations, and AWS secrets, credentials, and key management becomes a high-confidence area on the SCS-C02 exam.