Protecting Secrets, Confidential Data, and Cryptographic Key Material

Secrets Manager is the store for credentials that must rotate, be shared across accounts or replicate across Regions; Parameter Store SecureString is the store for encrypted configuration that changes only on deploy. Both encrypt values under KMS, both are read by IAM-authorized API calls, and both support VPC interface endpoints. They differ in what happens after storage.

The selection rule: if the value is a credential that must change (database passwords, API keys with a rotation mandate, anything read across accounts), it belongs in Secrets Manager. If it is encrypted configuration that changes only on deploy (a license string, a webhook URL), a standard-tier SecureString is enough and costs nothing. Both need kms:Decrypt on the encrypting key at read time: a caller can hold secretsmanager:GetSecretValue or ssm:GetParameter and still be denied by the key policy. Parameter Store advanced-tier parameter policies (such as expiration notifications) remind you to rotate; they do not rotate anything.

Secrets Manager rotation changes a credential on a schedule in one of four ways, and the difference is who owns the code:

A function (template or custom) is invoked once per step, in order, and starts each step by calling DescribeSecret:

1. createSecret generates the new value (usually with GetRandomPassword, which has no resource-level permissions, so it needs Resource: "*") and stores it with PutSecretValue as a new version labelled AWSPENDING. A function in another account, or one running under an assumed role, must pass the event's RotationToken to PutSecretValue; without it, rotation fails with a RotationFailed event saying the pending version was not created by Lambda.
2. setSecret applies the pending value to the target, for example by changing the database password. It is the first step that connects to the database.
3. testSecret signs in to the target with the AWSPENDING version. If this fails, rotation stops: finishSecret never runs and AWSCURRENT stays on the old version.
4. finishSecret calls UpdateSecretVersionStage to move AWSCURRENT to the new version; the old version gets AWSPREVIOUS.

A staging label sits on one version at a time, so moving it is always a move, never a copy. A failed rotation does not pile up pending versions: while AWSPENDING sits on a version other than AWSCURRENT, Secrets Manager treats rotation as still in progress, and later rotations fail immediately. After fixing the cause, remove the stale AWSPENDING label and rotate again. Schedules, alarms on rotation failure and making sure clients pick up new values remain your job.

The strategy decides whether clients ever hold a password the database no longer accepts. Single-user rotation changes the password of the one user the secret describes; the old password stops working the moment setSecret changes it, so clients still holding the old value fail until they refresh. Alternating-users rotation keeps two users (the original and a clone, named with a _clone suffix) and changes the one that is not current, so the previous user's password stays valid while clients catch up.

Two operational facts about alternating users. The clone is created at the first rotation with the original user's permissions as they were then; grants added later to one user are not copied, so every permission change must be applied to both users or the application fails each time rotation switches to the other one. And when the superuser secret is an RDS-managed master user secret, the rotation function reads that superuser secret from Secrets Manager and also calls read-only RDS APIs to look up the database connection details, so it needs a network path to RDS as well as to Secrets Manager.

Sharing a secret with another account takes two grants. First, a resource policy on the secret that allows the external principal secretsmanager:GetSecretValue. Second, decrypt rights on the KMS key that encrypts it, which is why a shared secret must use a customer managed key: the default aws/secretsmanager key is an AWS managed key and cannot be used from another account. Allow the external principal kms:Decrypt (and kms:DescribeKey) in the key policy, and give the consuming role matching IAM permissions. Miss either half and the caller gets AccessDenied. To share with a whole organization whose accounts come and go, put an aws:PrincipalOrgID condition in both the secret's resource policy and the customer managed key's policy, so new accounts need no policy edit.

Multi-Region replication. Secrets Manager replicates a primary secret to other Regions one way, from the primary. What travels and what does not:

• The secret value, its resource policy and its tags replicate; rotation runs only on the primary and the new value flows to the replicas.
• The KMS key does not. Each replica is encrypted with a key in its own Region: aws/secretsmanager there by default, or a customer managed key you name. A default replica therefore breaks cross-account readers even though the replicated resource policy allows them; give the replica a Regional customer managed key whose policy allows them.
• Replicas are read-only. To change the value or rotate in a replica's Region (for example during a long outage of the primary Region), promote the replica first; promotion makes it a standalone secret that no longer receives updates from the old primary.

Private access. Workloads in subnets without internet routes reach the service through the com.amazonaws.<region>.secretsmanager interface VPC endpoint. You can pin reads to your network with an aws:SourceVpce or aws:SourceVpc condition in the secret's resource policy, so a stolen credential cannot read the secret from outside it.

A secret store only helps if the secrets are actually in it, and leaked credentials persist in more places than the file you fixed:

• Git history: a credential committed and later deleted still sits in every clone's history.
• EC2 user data: readable from the instance metadata service and through DescribeInstanceAttribute. Removing a password from a bootstrap script changes nothing for running instances, and every older launch template version still carries the old user data.
• AMIs and EBS snapshots: baked-in config files and shell history travel with every instance launched from them.
• Environment variables and container image layers: a value passed at build time stays in its layer even if a later layer unsets it.

Prevention belongs before the commit (pre-commit hooks such as the open-source git-secrets, and repository secret scanning); after that, it is forensics. Moving to Secrets Manager also improves the audit trail: CloudTrail records every GetSecretValue call (who, when, which secret) but never the secret value itself.

The remediation order matters: rotate first, then migrate. Moving a leaked credential into Secrets Manager changes where it is stored, not whether it works, and anyone who copied it still holds a valid key. Issue a new credential, store it in Secrets Manager, point applications at GetSecretValue, invalidate the old credential, then scrub the artifacts: user data, old launch template versions, images, repository history. Containment and forensics belong to Domain 2.

Masking hides sensitive values from people and systems that should not see them while keeping the rest of the record usable; encryption alone does not do this, because anyone allowed to decrypt sees the raw value. Skill 5.3.4 names two managed masking controls. (Finding sensitive data in S3 with Amazon Macie is a detection skill covered in the Task 1.1 monitoring lesson, and organization data-perimeter conditions belong to the authorization lessons in Domains 4 and 6.)

CloudWatch Logs data protection policies

A data protection policy has an audit statement (report matches, optionally to CloudWatch Logs, Amazon S3 or Firehose) and a deidentify statement (mask matches). Both reference data identifiers:

• Managed data identifiers cover common types such as credit card numbers, email addresses and credentials. You select them; you cannot edit their patterns.
• Custom data identifiers cover your own formats. Each has a name and a regular expression and is referenced by name in the audit and deidentify statements, like a managed one.

Policies exist at two levels. An account-level policy applies to every log group in the account, including groups created later; a log-group policy applies to one group. When both exist, both apply to that group, so scope follows placement: the account policy is for identifiers that matter everywhere, and a log-group policy is for identifiers that matter in one place. Masking happens at ingestion and is not retroactive; a policy affects only events that arrive after it exists. Principals with logs:Unmask can view the original values, which makes unmasking an authorized, auditable exception.

Amazon SNS message data protection

Amazon SNS message data protection closed to new customers on 30 April 2026: accounts that already use it keep it, and AWS points new users to a pattern built on AWS Lambda and Amazon Bedrock Guardrails. It remains in the exam guide, so know how it works. A data protection policy on a topic has statements that combine a direction, a principal and an operation:

The direction decides whose traffic a statement acts on, and the operation decides what happens to it: Inbound statements act once for everyone, Outbound statements act per subscription.

Task 5.3's key-material skills are about who controls the material and where it physically lives, not encryption mechanics (Task 5.2). Each rung buys custody and costs operations:

Only the external key store keeps material out of AWS: imported material and CloudHSM both live in AWS infrastructure. Both kinds of custom key store (CloudHSM and external) give up KMS features: no multi-Region keys, no imported material, and no automatic or on-demand rotation. With an external key store, rotation happens in the external key manager (new material behind the same external key ID), and disaster recovery across Regions means a separate external key store and KMS key in each Region, with data re-encrypted under the second Region's key. Using CloudHSM directly, outside KMS (for example SSL/TLS offload or Oracle TDE), appears only at mention level.

Imported key material is key material you generate outside AWS and upload into a KMS key whose origin is EXTERNAL; the key then works like any other symmetric KMS key, but its lifecycle is yours. The import flow is fixed: CreateKey with origin EXTERNAL (the key waits in PendingImport), GetParametersForImport (returns a wrapping public key and an import token, both valid for 24 hours), wrap the material with that public key in your own HSM, then ImportKeyMaterial with the token and an optional expiration date.

Lifecycle rules worth knowing:

• DeleteImportedKeyMaterial or expiry removes material at once and puts the key in PendingImport. Reimporting the same material from your copy restores it; AWS cannot recover material you have lost.
• Rotation is on demand only. Import new material into the same key as NEW_KEY_MATERIAL, then call RotateKeyOnDemand. The key ID and ARN stay the same, new encryption uses the new material, and older material stays associated so old ciphertext still decrypts. (Creating a new key and repointing an alias is only needed for asymmetric, HMAC and custom key store keys.)
• KMS treats the key as a whole: if any associated material expires or is deleted, the whole key goes to PendingImport and every operation fails, including new encryption with the current material. Track the expiry of old material after a rotation.
• Multi-Region keys can use imported material. Import the same material into the primary and each replica. To rotate, import the new material into the primary as NEW_KEY_MATERIAL, import that same material into every replica as EXISTING_KEY_MATERIAL, and only then call RotateKeyOnDemand on the primary. KMS refuses the rotation until every replica holds the new material.

Choose imported material only for a provenance or revocation requirement; without one, AWS-generated material is simpler and rotates itself.

Skill 5.3.5 asks how keys and certificates work when a workload spans Regions or accounts. KMS keys and private CAs are Regional resources, so cross-Region designs either replicate them or build one per Region.

Multi-Region KMS keys. A multi-Region primary key and its replicas share key material and key ID, so ciphertext from one Region decrypts in another without a cross-Region call or re-encryption. That pays off for client-side encryption (the AWS Encryption SDK, the DynamoDB encryption client) where ciphertext itself travels between Regions. Server-side services such as S3 Cross-Region Replication treat them as single-Region keys and re-encrypt on arrival anyway. Which properties are shared and which are set per Region:

So an alias created in one Region does not exist in another, and a replica created without a key policy gets the default key policy: application roles must be added to each replica's policy. A single-Region key can never be converted into a multi-Region key; to make existing data decryptable elsewhere, create a new multi-Region key and re-encrypt under it.

ACM certificates and private keys. A standard ACM certificate's private key is never exportable: ACM deploys it to integrated services (Elastic Load Balancing, CloudFront, API Gateway), and you cannot load it onto an EC2 server by ARN. The exception is ACM for Nitro Enclaves, which lets NGINX or Apache on EC2 use an ACM certificate while the private key stays inside the enclave. When the private key must sit on the server itself, use an exportable ACM public certificate (available since 2025, at extra charge) or a certificate issued by AWS Private CA; either way the private key's custody becomes yours. Private CA certificates are trusted only by clients you configure, never by public browsers. The CA's own signing key is different: AWS Private CA generates and keeps it in AWS-managed HSMs, and it is never exported.

AWS Private CA across accounts and Regions. A CA lives in one Region and one account. Share it with other accounts or the whole organization through AWS RAM; those accounts then request certificates through ACM (RequestCertificate with the shared CA), which makes them managed certificates: ACM attempts renewal 60 days before expiry whether or not the certificate is associated with an integrated service, provided ACM's service principal has been granted permission on the CA. A renewed certificate that is not attached to an integrated service must be exported and reinstalled wherever it is used. Certificates issued directly with IssueCertificate are unmanaged, so you renew and deploy them yourself. For Regional resilience, a single issuing CA is a single point of failure wherever it sits. The two documented hierarchies:

• One root, a subordinate (issuing) CA in each Region: issuance survives a Region outage and clients trust a single root; the root itself is not redundant, which matters only when you need a new subordinate CA.
• Redundant roots in several Regions: no single root to lose, but clients must trust every root.

A failing rotation is diagnosed by the step that failed and the kind of failure: a timeout means a missing network path, an access error means a policy. Work through it in order.

1. Can the function reach Secrets Manager? A function in VPC subnets with no NAT and no Secrets Manager interface endpoint logs "Found credentials in environment variables" and then nothing until it times out, before createSecret finishes. Add the endpoint (and allow the function in its security group) or a NAT path.
2. Can it use the key? KMS problems fail fast, not with a timeout: an error such as "Access to KMS is not allowed" means the rotation role lacks kms:Decrypt or kms:GenerateDataKey on a customer managed key.
3. Can it reach the database? If createSecret succeeded, the Secrets Manager endpoint, PutSecretValue and the KMS key all work. A timeout in setSecret, the first step that connects to the database, means the database security group does not allow the function's security group on the database port. For alternating users with an RDS-managed superuser secret, a stall after createSecret can also mean no path to the RDS API.
4. Is a stale label blocking it? After any failure, an AWSPENDING version left behind makes later rotations fail immediately until you remove the label.
5. Cross-account function? A RotationFailed event saying the pending version was not created by Lambda means createSecret did not pass the RotationToken.
6. Why did the app break after a good rotation? Rotation changes the value in Secrets Manager, not in a client's memory: any process that read the secret once and kept it will hold a dead credential under single-user rotation. Re-fetch on authentication failure or use the AWS secret caching libraries with a short TTL; if clients cannot be changed, switch to alternating-users rotation.

The same two-grant rule explains cross-account failures: GetSecretValue denied from another account means checking the secret's resource policy and the customer managed key's policy, and for a replica, which key encrypts it in that Region.