Protecting Secrets, Confidential Data, and Cryptographic Key Material

Both services store encrypted values under KMS, both are retrieved by IAM-authorized API calls, and both support VPC interface endpoints. The exam separates them on what happens after storage.

The selection rule: if the value is a credential that must change — database passwords, API keys with rotation mandates, anything cross-account — it belongs in Secrets Manager. If it is encrypted configuration that changes only on deploy — a license string, a webhook URL, a feature key — SecureString suffices and costs nothing at standard tier. Both require 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 adds parameter policies such as expiration notifications — a nudge toward rotation hygiene, not rotation itself.

Secrets Manager rotation is a Lambda function invoked on a schedule you set on the secret. For Amazon RDS, Amazon Redshift, and Amazon DocumentDB credentials, AWS supplies the rotation function — you configure it rather than write it. For everything else — third-party API keys, on-premises databases, OAuth client secrets — you write a custom rotation Lambda implementing the same contract.

That contract is four ordered steps, each an invocation with a step parameter:

1. createSecret — generate the new credential value and store it as a new secret version staged AWSPENDING.
2. setSecret — push the pending credential into the target service (for example, run the password change against the database).
3. testSecret — authenticate to the target using the pending credential to prove it works.
4. finishSecret — move the AWSCURRENT staging label to the new version; the old version becomes AWSPREVIOUS.

The staging labels matter for troubleshooting: a rotation stuck with a lingering AWSPENDING version means a step failed midway, and Secrets Manager will retry from where it left off rather than restarting cleanly. Two rotation strategies exist for databases: single-user (the secret's own credential changes — brief risk of in-flight connections failing) and alternating-users (two database users swap; clients always find a valid credential, at the cost of managing a second user and a separate superuser secret that performs the change). Rotation frequency, alerting on rotation failure, and verifying applications re-fetch after rotation are your responsibilities — Secrets Manager only drives the state machine.

Sharing a secret across accounts requires two policy grants, and the exam tests whether you know both. First, a resource policy on the secret allowing the external principal secretsmanager:GetSecretValue. Second, decrypt rights on the KMS key that encrypts the secret — which is why a cross-account secret must use a customer managed key: the default aws/secretsmanager AWS managed key cannot be shared outside its account, so its key policy can never authorize the foreign principal. Grant the external account kms:Decrypt (and kms:DescribeKey) in the key policy, and the consumer typically delegates both permissions to a role via IAM. Miss either half and you get AccessDenied — often surfaced as a KMS error even though the caller was staring at the secret's policy.

Multi-Region: Secrets Manager replicates a primary secret into other Regions. Replicas stay synchronized with the primary, are read-only until promoted to standalone secrets, and are encrypted under a KMS key in the destination Region — replication is the disaster-recovery and latency answer, and pairs naturally with multi-Region KMS key strategies you met in Task 5.2. Rotation runs only against the primary; replicas receive the new value.

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

A secret store only helps if the secrets are actually in it. Specialty scenarios assume credentials have already leaked into places engineers forget:

• Git history — a credential committed then "removed" persists in every clone's history; deleting the file in a new commit removes nothing.
• AMIs and EBS snapshots — baked-in config files and shell history travel with every instance launched from the image.
• EC2 user data — readable via the instance metadata service and DescribeInstanceAttribute by anyone with the API permission; never a place for credentials.
• Environment variables and container image layers — a credential passed at build time is preserved in the layer even if a later layer unsets it.

Detection tooling appears at mention level: Amazon CodeGuru-style code scanning detects hardcoded secrets in repositories and can point remediation at Secrets Manager, and the open-source git-secrets pattern blocks commits containing credential-shaped strings before they enter history at all — prevention at the hook, not forensics afterward.

The remediation order is the exam's favourite trap: rotate first, then migrate. Moving a leaked credential into Secrets Manager changes its storage location, not its validity — anyone who copied it from git history still holds a working key. The playbook is: issue or rotate to a new credential, store the new value in Secrets Manager, point applications at GetSecretValue, then invalidate the old credential and scrub the artifacts (rebuild images, rewrite or retire the repository history). Full incident execution — containment, forensics — belongs to Domain 2; here you are judged on the control design and the ordering.

Amazon Macie answers the question where is our sensitive data in S3? — and the exam expects you to configure it, not just name it. Macie ships managed data identifiers for common types (credentials, financial data, personal identifiers) and lets you add custom data identifiers — regular expressions with optional keywords and proximity rules — for organization-specific formats like internal employee IDs. Allow lists suppress known false positives.

Two discovery modes, and choosing between them is the tested skill. Classification jobs are scoped: you pick buckets, prefixes, object criteria, and sampling depth, run once or on schedule, and get exhaustive findings for that scope — the right tool when an auditor asks for a definitive answer about specific buckets. Automated sensitive data discovery continuously samples objects across all buckets in the account or organization, building a sensitivity score per bucket over time — the right tool for the "find PII across hundreds of buckets" scenario, because it gives broad, cheap, ongoing coverage rather than a one-time deep scan. Sampling is also its limitation: it can miss individual objects, so a bucket flagged interesting by automated discovery gets a targeted classification job as follow-up.

Findings flow to EventBridge and Security Hub, where the workflow becomes: finding → classify → act. A common acted-on pattern is tagging-driven handling — tag buckets or objects with a classification level, then enforce it with policy: deny untagged uploads to regulated buckets, restrict principals by tag, and scope monitoring intensity by classification. Discovery without an enforcement loop is the wrong answer at Specialty level.

Once data is classified, you constrain who can reach it and what they see. Data-perimeter conditions keep confidential data inside the organization: aws:PrincipalOrgID on resource policies rejects principals from foreign accounts, aws:ResourceOrgID in SCPs or identity policies stops your own principals writing data to buckets outside the org (the exfiltration-by-upload path), and aws:SourceVpce restricts access to requests arriving through your VPC endpoints. S3 Access Points operationalize this at concept level: each application gets its own access point with a narrow policy, and an access point can be VPC-only, so the confidential bucket never needs a single sprawling bucket policy.

When regulators demand that raw values never appear, encryption alone is insufficient — decryption reproduces the value. Know the three techniques apart: encryption is reversible by anyone holding key access; masking irreversibly redacts or obscures the value at the point of display or logging; tokenization substitutes a non-sensitive token and keeps the real value in a separate hardened vault, so downstream systems process tokens and fall out of compliance scope.

The exam guide names two managed masking controls. CloudWatch Logs data protection policies audit and mask sensitive data identifiers in log events as they are ingested; masked values display redacted, and unmasking is itself an authorized action requiring the logs:Unmask permission — masking with an audited exception path. Amazon SNS message data protection applies the same idea in motion: policies on a topic can audit, de-identify (mask or redact), or deny publication of messages containing sensitive data, protecting downstream subscribers from receiving payloads they should never see.

Task 5.3's key-material skills are about who controls the material, not encryption mechanics (that was 5.2). Read requirements as a ladder — each rung buys custody and costs operations:

Imported material carries traps: import uses a wrapping key and an import token, you may set an expiration, and rotation means importing new material into a new key and re-pointing the alias — the key ID's material cannot be silently replaced with different material. Lose your copy after deletion or expiry and AWS cannot recover it. CloudHSM direct (outside KMS) appears at the guide's level: SSL/TLS offload and Oracle TDE at mention level, with cluster HA achieved by multiple HSMs across Availability Zones and automatic cluster backups. For certificates: ACM-managed certificates keep their private keys non-exportable — ACM deploys them to integrated services and you never touch the key — while exportable certificates and AWS Private CA-issued certificates hand you the private key, and its custody becomes yours; the Private CA's own CA key stays in AWS-managed HSMs.

Scenario: a custom rotation Lambda for an RDS PostgreSQL secret has failed three consecutive rotations; separately, after one rotation succeeded, the application began throwing authentication errors. Walk it in order.

1. Can the Lambda reach Secrets Manager? The rotator runs in the database's VPC (it must, to reach the DB). Private subnets need the secretsmanager interface endpoint or a NAT path; without one, createSecret never completes and versions pile up in AWSPENDING.
2. Can it reach the database? The DB security group must allow the Lambda's security group on the DB port, or setSecret and testSecret fail after createSecret succeeded — the classic stuck-mid-rotation signature.
3. Can it use the key? If the secret is encrypted with a customer managed key, the rotation role needs kms:Decrypt and kms:GenerateDataKey in the key policy or its IAM policy. An inaccessible key fails rotation even though the Lambda's Secrets Manager permissions are perfect.
4. Why did the app break after a good rotation? It fetched the secret once at startup and cached it. The database password changed; the cache did not. The fix is client-side: re-fetch on authentication failure or use the AWS-provided secret caching libraries with a sensible TTL — and if brief dual-validity is required, the alternating-users strategy keeps a working credential live throughout.

The same both-policies discipline explains cross-account failures: GetSecretValue denied from another account means checking the secret's resource policy and the customer managed key's key policy — one grant is never enough. And a Macie job that "finds nothing" in a bucket you know holds PII is almost always scoping: excluded prefixes, object criteria filtering out the relevant types, or shallow sampling depth — or you ran automated discovery, which samples, when the question needed an exhaustive scoped job.