Data Protection Day 5
SCS-C03 · Domain 5 · Data Protection (18%) · Day 5 of 5

Secrets, rotation and data masking

The last Data Protection day. First, keeping credentials out of code with AWS Secrets Manager and Parameter Store, and rotating them safely. Then making sure sensitive values that slip into logs and messages are masked, and finding sensitive data in S3 with Macie. It ends with a review quiz across all five days.

Skill 5.3.1 secrets managementSkill 5.3.4 data masking and sanitizationDomain 5 review~80 min read + 30 min lab
01

AWS Secrets Manager

Skill 5.3.1 is about getting passwords, API keys and tokens out of code and config files. Secrets Manager stores them encrypted with KMS, controls who reads them with IAM and resource policies, keeps versions, replicates them across Regions and, most importantly for the exam, rotates them.

Concept profile

AWS Secrets Manager

often confused with SSM Parameter Store
?What is it?

A managed store for secrets. Each secret has versions marked with staging labels; applications call GetSecretValue at run time and get the AWSCURRENT version.

⚙How does it work?
  • Every version is encrypted with a KMS key: aws/secretsmanager by default, or a customer managed key.
  • Reading needs secretsmanager:GetSecretValue and kms:Decrypt on the key.
  • A resource policy on the secret allows other accounts; BlockPublicPolicy rejects policies that would open it widely.
  • Replicate to other Regions: rotation runs on the primary and the new value flows to replicas; each replica can use a key in its own Region.
  • Reference secrets without code: CloudFormation dynamic references, ECS task definitions, the Lambda extension, and RDS managed master user passwords.
{ }Structure
App / Lambda IAM role (caches value) GetSecretValue Secret: prod/db v3 · AWSCURRENT v2 · AWSPREVIOUS v4 · AWSPENDING (during rotation) Resource policy (cross-account, BlockPublicPolicy) · replicas AWS KMS encrypts each version reader: kms:Decrypt Rotation managed, or Lambda every 4 h to 999 days
One secret, its versions, its key and its rotation.
⇄Secrets Manager vs SSM Parameter Store
Secrets ManagerParameter Store
Built-in rotationYes (managed or Lambda)No
EncryptionAlways (KMS)Only SecureString
Cross-accountResource policyAdvanced tier sharing
Multi-RegionReplicasNo
CostPer secret per month + API callsStandard tier free
!Common mistakes the exam tests
  • Sharing a secret with another account while it uses aws/secretsmanager: the other account can’t use that key. Use a customer managed key and allow the other account in its key policy too.
  • Granting GetSecretValue but forgetting kms:Decrypt (for a customer managed key).
  • Putting secrets in Lambda environment variables or AMIs: they leak through describe calls, images and logs.
  • Fetching the secret on every request: cache it (client-side caching libraries or the Parameters and Secrets Lambda extension).
  • Deleting a secret and expecting it gone at once: there is a recovery window (7–30 days) unless you force deletion without recovery.
✓Benefits and use cases
  • Database credentials with automatic rotation.
  • Third-party API keys used by many services.
  • RDS master password created and rotated by RDS itself.
Think of it like · a hotel key desk

Guests never keep the master keys in their pockets.

AWS conceptFamiliar thing
Secret≈A key kept behind the desk
GetSecretValue≈Asking at the desk and showing your room card (IAM role)
KMS key≈The locked cabinet the keys live in; you need the cabinet key too
Staging labels≈Tags on hooks: ‘in use’, ‘previous’, ‘being cut’
Resource policy≈A note that guests from the partner hotel may collect this key
Replica≈A copy of the key board at the sister hotel, updated whenever the original changes
Real AWS example · store, read and reference a secret

Create once, then read it at run time or let CloudFormation resolve it.

$ aws secretsmanager create-secret --name prod/orders/db \
    --kms-key-id alias/secrets-prod \
    --secret-string '{"username":"app","password":"EXAMPLE-ONLY"}'

$ aws secretsmanager get-secret-value --secret-id prod/orders/db \
    --query SecretString --output text

# CloudFormation dynamic reference
MasterUserPassword: '{{resolve:secretsmanager:prod/orders/db:SecretString:password}}'

The value never appears in the template or stack outputs.

Exam-style scenario

A Lambda function in account A must read a database secret owned by account B. The secret uses the default aws/secretsmanager key. Calls fail with AccessDenied even though the secret’s resource policy allows account A’s role. What should be done?

  1. A. Add secretsmanager:* to the role in account A.
  2. B. Re-encrypt the secret with a customer managed key in account B whose key policy allows account A’s role kms:Decrypt, and keep the resource policy plus an IAM policy in account A.
  3. C. Replicate the secret to account A.
  4. D. Store the password in a Lambda environment variable.
Show the worked answer

Answer: B

Cross-account access needs three things: the secret’s resource policy, the caller’s IAM permissions, and a customer managed key that allows the caller to decrypt. AWS managed keys can’t be shared.

Why not the others

  • A: IAM in A can’t override B’s key policy.
  • C: Replication is across Regions, not accounts.
  • D: Insecure and doesn’t rotate.
How the exam tests this
  • “Remove hard-coded DB passwords”→ Secrets Manager + IAM role.
  • “Share secret cross-account”→ Resource policy + CMK key policy + IAM.
  • “Same secret in DR Region”→ Replicate the secret.
  • “Template needs a password”→ Dynamic reference.
  • “Stop policies that make secrets public”→ BlockPublicPolicy.
Must remember
  • Read = GetSecretValue + kms:Decrypt.
  • aws/secretsmanager: no cross-account.
  • Labels: AWSCURRENT · AWSPENDING · AWSPREVIOUS.
  • Replicas: rotation on primary, flows out.
  • Delete: 7–30 day recovery window.
02

Rotating secrets

Rotation is the feature that makes Secrets Manager the answer instead of Parameter Store. The exam tests the strategy (single vs alternating users), the four Lambda steps, the schedule and, very often, why rotation fails in a private subnet.

Concept profile

Rotation by Lambda function

often confused with Managed rotation
?What is it?

Secrets Manager calls a Lambda function on a schedule. The function creates a new secret value, sets it in the database or service, tests it, and moves the AWSCURRENT label to it.

⚙How does it work?
  • Pick a template (RDS MySQL, PostgreSQL, Redshift, DocumentDB…) or write your own.
  • Steps: createSecret → setSecret → testSecret → finishSecret.
  • Schedule with rate() or cron(): as often as every 4 hours, at most 999 days apart, inside a rotation window of at least one hour (UTC).
  • The function needs IAM permissions on the secret and key, and network access to the database and the Secrets Manager endpoint.
{ }Structure
createSecretNew versionlabelledAWSPENDINGsetSecretSet the newpassword in thedatabasetestSecretLog in withAWSPENDINGcredentialsfinishSecretMove AWSCURRENTto new version;old → AWSPREVIOUSThe rotation Lambda needs a network path to the database AND to Secrets Manager (VPC endpoint or NAT).Single user: one login changes in place. Alternating users: two logins take turns (needs a superuser secret).
The four steps every rotation function follows.
⇄Lambda rotation vs Managed rotation
Lambda rotationManaged rotation
Who runs itYour Lambda functionThe owning service (for example RDS, Redshift)
SetupFunction, IAM, VPC networkingTurn it on
Use forAny database or API you controlSecrets the service manages for you
CustomiseFullyLimited to schedule
Typical exam hint“third-party API key”, “custom app”“least operational overhead” for RDS master
!Common mistakes the exam tests
  • Running the rotation Lambda in a private subnet with no Secrets Manager VPC endpoint or NAT: it times out at createSecret or finishSecret.
  • Forgetting the database security group must allow the Lambda’s security group.
  • Choosing single-user when the app can’t tolerate login failures during rotation: use alternating users, which needs a separate superuser secret.
  • Apps that cache credentials forever: after rotation they keep the old password. Refresh on auth failure or use short cache TTLs.
  • Expecting Parameter Store to rotate: it can only warn you with NoChangeNotification policies (advanced tier).
✓Benefits and use cases
  • Rotate RDS passwords every 30 days for compliance.
  • Rotate third-party API keys with a custom function.
  • Immediately rotate after a suspected leak (rotate-secret).
Think of it like · changing the locks on a shared office

How to change a lock without locking people out.

AWS conceptFamiliar thing
Single user≈Changing the one front-door lock; anyone holding the old key is stuck until they get the new one
Alternating users≈Two doors: change door B while everyone uses door A, then switch next time
Superuser secret≈The locksmith’s master key, needed to cut a second door
createSecret≈Cutting the new key
testSecret≈Trying the new key before handing it out
finishSecret≈Hanging the new key on the ‘in use’ hook
Real AWS example · turn on rotation every 30 days

Using a rotation function and rotating now.

$ aws secretsmanager rotate-secret --secret-id prod/orders/db \
    --rotation-lambda-arn arn:aws:lambda:us-east-1:111122223333:function:rds-pg-rotate \
    --rotation-rules '{"ScheduleExpression":"rate(30 days)","Duration":"3h"}' \
    --rotate-immediately

$ aws secretsmanager describe-secret --secret-id prod/orders/db \
    --query '{On:RotationEnabled,Next:NextRotationDate}'

For a private-subnet function, create an interface endpoint for com.amazonaws.REGION.secretsmanager.

Exam-style scenario

A rotation function for an Aurora PostgreSQL secret runs in private subnets with no NAT gateway. Rotation fails with a timeout. The database is reachable from the function. What fixes it with the least cost?

  1. A. Add a NAT gateway in each AZ.
  2. B. Create an interface VPC endpoint for Secrets Manager with private DNS and allow the function’s security group to reach it.
  3. C. Increase the Lambda timeout to 15 minutes.
  4. D. Move the function out of the VPC.
Show the worked answer

Answer: B

The function must call the Secrets Manager API; an interface endpoint gives a private path without NAT charges.

Why not the others

  • A: Works but costs more.
  • C: It will still time out with no network path.
  • D: It then can’t reach the database in private subnets.

Three ways to rotate, and the newest one

Secrets Manager now rotates secrets in three ways. Managed rotation: the owning service rotates for you (for example RDS ManageMasterUserPassword, Redshift), with no Lambda. Lambda rotation: your function (or an AWS template) runs create, set, test, finish. Managed external secrets (since November 2025): a secret type for third-party SaaS credentials such as Salesforce, Snowflake and BigID (more partners added in 2026). Rotation is done through the partner integration, so there is no rotation function to maintain and no extra charge beyond normal secret pricing. For a third-party key from a provider that isn’t a partner, you still write a custom rotation Lambda.

“Rotate a Salesforce or Snowflake credential with the LEAST operational overhead” now points to a managed external secret, not a custom Lambda.
How the exam tests this
  • “Rotate a supported SaaS credential, no code”→ Managed external secret.
  • “Rotate DB password automatically”→ Secrets Manager rotation.
  • “App must never see failed logins”→ Alternating users.
  • “Rotation Lambda times out”→ Secrets Manager endpoint or NAT.
  • “Least overhead for RDS master password”→ Managed (RDS-managed) rotation.
  • “Most frequent schedule”→ Every 4 hours.
Must remember
  • Steps: create · set · test · finish.
  • Fastest: rate(4 hours); max 999 days.
  • Alternating users needs a superuser secret.
  • Private Lambda: VPC endpoint for Secrets Manager.
  • Parameter Store: no rotation.
  • SaaS partner credentials: managed external secrets, no Lambda.
03

Parameter Store and choosing a store

Not every value is a secret that needs rotation. Systems Manager Parameter Store holds configuration and simple secrets cheaply, with KMS encryption for SecureString. The exam usually asks you to choose between the two stores, so learn the difference rather than every detail.

Concept profile

SSM Parameter Store SecureString

often confused with Secrets Manager secret
?What is it?

A Parameter Store parameter whose value is encrypted with a KMS key (default aws/ssm or a customer managed key). Readers call GetParameter --with-decryption.

⚙How does it work?
  • Organise names as a hierarchy (/orders/prod/db/password) and grant IAM by path; read a tree with GetParametersByPath.
  • Reading needs ssm:GetParameter* and kms:Decrypt.
  • Standard tier: free, 4 KB, 10,000 per Region. Advanced: 8 KB, 100,000, parameter policies and cross-account sharing; can’t downgrade.
  • Advanced parameter policies: Expiration, ExpirationNotification, NoChangeNotification (via EventBridge).
  • Can reference a Secrets Manager secret through the /aws/reference/secretsmanager/ path.
{ }Structure
SSM Parameter Store String · StringList · SecureString (KMS) Hierarchy: /app/prod/db/host Standard: free, 4 KB, 10,000 params Advanced: 8 KB, 100,000, policies, sharing Policies: expiration, notifications No built-in rotation Config values and simple secrets AWS Secrets Manager Always encrypted with KMS Rotation: managed or Lambda Versions with staging labels Resource policy · cross-account Multi-Region replicas Charged per secret + API calls Database passwords, API keys, tokens
Two stores, two jobs.
⇄SecureString vs Secrets Manager secret
Parameter StoreSecrets Manager
Main jobConfiguration (+ simple secrets)Secrets with lifecycle
RotationNone (only reminders)Built in
Max size4 KB / 8 KB64 KB
PriceStandard freePer secret + API
Exam keyword“cheapest”, “configuration”“rotate”, “cross-Region”
!Common mistakes the exam tests
  • Choosing Parameter Store when the question says automatic rotation.
  • Choosing Secrets Manager for plain config values when the question says lowest cost.
  • Forgetting --with-decryption or kms:Decrypt for SecureString.
  • Using parameter policies on the standard tier: they need advanced.
  • Logging the decrypted value in application logs (see section 4).
✓Benefits and use cases
  • Feature flags, endpoints and AMI IDs.
  • Low-risk secrets that are rotated by another process.
  • Per-environment config trees read at start-up.
Think of it like · a company noticeboard and a safe

Where you keep different kinds of information.

AWS conceptFamiliar thing
String parameter≈A notice pinned on the board
SecureString≈A sealed envelope pinned on the board
Hierarchy path≈Sections of the board per team and environment
NoChangeNotification≈A reminder that an envelope hasn’t been replaced for 90 days
Secrets Manager≈The safe with a locksmith who changes the combination on schedule
Real AWS example · SecureString in a hierarchy

Store, then read a whole environment at start-up.

$ aws ssm put-parameter --name /orders/prod/api/key --type SecureString \
    --key-id alias/ssm-prod --value "EXAMPLE-ONLY"

$ aws ssm get-parameters-by-path --path /orders/prod --recursive \
    --with-decryption --query "Parameters[].Name"
[ "/orders/prod/api/key", "/orders/prod/db/host" ]

Grant ssm:GetParametersByPath on arn:aws:ssm:REGION:ACCOUNT:parameter/orders/prod/* only.

Exam-style scenario

A team stores 300 application settings, including a few low-risk tokens that another system rotates. They want encryption for the tokens, per-environment IAM control and the lowest cost. What should they use?

  1. A. Secrets Manager for all 300 values.
  2. B. Parameter Store standard tier with String parameters and SecureString for the tokens, organised by path.
  3. C. S3 objects with SSE-KMS.
  4. D. Lambda environment variables encrypted with KMS.
Show the worked answer

Answer: B

Standard-tier parameters are free, SecureString encrypts with KMS, and paths allow per-environment IAM.

Why not the others

  • A: Works but costs per secret per month, for features they don’t need.
  • C: Possible but clumsier and no hierarchy features.
  • D: Tied to one function and visible to anyone who can read its configuration.
How the exam tests this
  • “Rotate automatically”→ Secrets Manager.
  • “Cheapest encrypted config”→ SecureString standard tier.
  • “Alert when a value is stale”→ NoChangeNotification (advanced).
  • “Read a whole environment”→ GetParametersByPath.
  • “Value larger than 4 KB”→ Advanced tier (8 KB) or Secrets Manager.
Must remember
  • Types: String · StringList · SecureString.
  • Standard 4 KB free; advanced 8 KB.
  • Policies only on advanced.
  • Advanced can’t downgrade.
  • Parameter Store has no rotation.
04

Masking sensitive data in CloudWatch Logs

Skill 5.3.4 is about data masking and sanitization. The most common leak is not a database but a log line: a developer prints a request and suddenly card numbers, emails and access keys are in CloudWatch Logs for everyone with read access. Data protection policies find and mask them as they arrive.

Concept profile

CloudWatch Logs data protection policy

often confused with Metric filter
?What is it?

A policy on a log group (or the whole account) that uses data identifiers to find sensitive data at ingestion, audit what it found, and mask it at every egress point: console, Logs Insights, metric filters and subscription filters.

⚙How does it work?
  • Choose managed data identifiers (credentials such as AWS secret keys and private keys, credit cards, SSNs, health IDs, IP and MAC addresses) and add custom ones (regex).
  • Apply at account level (all current and future log groups) or log group level (one policy per group); both apply if both exist.
  • Audit findings go to CloudWatch Logs, S3 or Firehose, and the free metric LogEventsWithFindings can drive an alarm.
  • Only principals with logs:Unmask can see the original values.
{ }Structure
App writes log user=ana@ex.com card=4111111111111111 Data protection policy managed + custom data identifiers Everyone sees user=********** card=************ Audit Findings to CloudWatch Logs, S3 or Firehose Metric LogEventsWithFindings → alarm Unmask Only principals with logs:Unmask Events ingested before the policy: not masked
Find at ingestion, mask everywhere, unmask by permission.
⇄Logs data protection vs Metric filter
Data protection policyMetric filter
PurposeFind and mask sensitive dataCount patterns, make metrics
Changes what readers seeYes, maskedNo
Built-in PII patternsManaged data identifiersNo
Permission to see raw datalogs:Unmaskn/a
RetroactiveNo: only new eventsNo
!Common mistakes the exam tests
  • Expecting old log events to be masked: only events ingested after the policy is set.
  • Giving developers logs:*, which includes logs:Unmask.
  • Thinking masking fixes the root cause: also fix the code that logs secrets.
  • Forgetting the account-level option when the requirement says “all log groups, including future ones”.
  • Thinking it only works for the Standard log class: Infrequent Access log groups are supported too.
✓Benefits and use cases
  • PCI: card numbers never visible in logs.
  • Alert when an AWS secret key is logged.
  • Give support teams logs without personal data.
Think of it like · a newspaper archive

Old papers are public, but some details must be blacked out.

AWS conceptFamiliar thing
Data identifiers≈A list of things the editor looks for: card numbers, ID numbers
Masking at ingestion≈Black marker applied before the paper goes on the shelf
logs:Unmask≈The archivist with a key to the original, unredacted copy
Audit findings≈A daily report of how many lines were blacked out and where
Not retroactive≈Papers already on the shelf before the rule stay as printed
Real AWS example · mask emails and AWS secret keys in one log group

Audit and de-identify with managed identifiers.

$ aws logs put-data-protection-policy --log-group-identifier /app/orders \
  --policy-document '{
  "Name": "orders-dp", "Version": "2021-06-01",
  "Statement": [
   {"Sid": "audit", "DataIdentifier": [
      "arn:aws:dataprotection::aws:data-identifier/EmailAddress",
      "arn:aws:dataprotection::aws:data-identifier/AwsSecretKey"],
    "Operation": {"Audit": {"FindingsDestination": {}}}},
   {"Sid": "mask", "DataIdentifier": [
      "arn:aws:dataprotection::aws:data-identifier/EmailAddress",
      "arn:aws:dataprotection::aws:data-identifier/AwsSecretKey"],
    "Operation": {"Deidentify": {"MaskConfig": {}}}}]}'

Check identifier names in the managed data identifier list before use.

Exam-style scenario

A company must make sure that credit card numbers written by any application to any CloudWatch Logs group, including groups created next year, are hidden from engineers, while the compliance team can still see the original values. What should it do?

  1. A. Create a metric filter for card numbers in each log group.
  2. B. Create an account-level data protection policy with the CreditCardNumber managed identifier, and grant logs:Unmask only to the compliance team.
  3. C. Encrypt the log groups with a KMS key.
  4. D. Export logs to S3 and run Macie weekly.
Show the worked answer

Answer: B

Account-level policies cover existing and future log groups; masking applies at every egress point, and logs:Unmask controls who sees raw data.

Why not the others

  • A: Metric filters count; they don’t mask.
  • C: Encryption at rest doesn’t hide values from authorised readers.
  • D: Finds data later but doesn’t hide it in CloudWatch.
How the exam tests this
  • “Hide PII in logs”→ Data protection policy.
  • “All log groups, also future ones”→ Account-level policy.
  • “Some people need raw values”→ logs:Unmask.
  • “Alarm when secrets appear in logs”→ LogEventsWithFindings metric.
  • “Old events still show PII”→ Not retroactive; masking applies from now on.
Must remember
  • Masks at ingestion, shown masked everywhere.
  • Account level + log group level both apply.
  • logs:Unmask to see raw.
  • Findings → Logs · S3 · Firehose.
  • Not retroactive.
05

Masking messages and finding sensitive data

Logs are one channel. Messages between services and files in S3 are the others. The exam names SNS message data protection for messages and Amazon Macie for finding sensitive data in S3. For anything else, the answer is to sanitize in your own pipeline before the data is stored or shared.

Concept profile

SNS message data protection

often confused with CloudWatch Logs data protection
?What is it?

A data protection policy on an SNS standard topic that scans published messages with managed or custom data identifiers and can audit, de-identify (mask or redact) or deny messages that contain sensitive data.

⚙How does it work?
  • Audit: sample up to 99% of messages and send findings to CloudWatch, S3 or Firehose.
  • De-identify: mask or redact the data while still publishing and delivering.
  • Deny: block the message if sensitive data is in the payload.
  • Availability: AWS no longer offers it to new customers; it may still appear in questions, but in new designs sanitize in a Lambda before publishing.
{ }Structure
FindAmazon MacieS3 objectsmanaged + customidentifiersMask logsCloudWatch Logsdata protectionpolicy, atingestionMask messagesSNS message dataprotection: audit,de-identify, deny(existing customers)Mask in appsLambda / Glueredact or tokenizebefore storingor sharingBlockDeny publish withPII, Config rules,S3 Block PublicAccessDiscover first, then mask where data flows: logs, messages and your own pipelines.
Discover, mask and block across logs, messages and pipelines.
⇄SNS data protection vs CloudWatch Logs data protection
SNS data protectionLogs data protection
DataMessages on a topicLog events
ActionsAudit · de-identify · denyAudit · mask
Can blockYes (deny)No
Raw accessMessage is changed for subscriberslogs:Unmask
Topics / groupsStandard topics onlyAny log group, account level
!Common mistakes the exam tests
  • Using SNS data protection on a FIFO topic: standard only.
  • Recommending it for a brand-new account: it’s no longer available to new customers.
  • Using Macie to mask data: Macie finds and reports; masking is done elsewhere.
  • Expecting Macie to scan RDS or DynamoDB directly: export to S3 first.
  • Forgetting Macie must be able to use the KMS key of encrypted objects, or they are skipped.
✓Benefits and use cases
  • Stop PHI from leaving through notification topics.
  • Find buckets holding passport numbers before an audit.
  • Redact PII before sharing data sets with analysts.

Amazon Macie in one paragraph

Macie discovers sensitive data in S3. Automated sensitive data discovery samples objects across your buckets every day for broad visibility; sensitive data discovery jobs scan chosen buckets once or on a schedule for depth. It uses managed and custom data identifiers plus allow lists (values to ignore), produces sensitive data findings, and also reports bucket-level policy findings such as a bucket becoming public. Findings go to EventBridge and Security Hub for automated response.

Think of it like · a post office

How a post office handles letters that shouldn’t contain certain things.

AWS conceptFamiliar thing
Audit≈Opening a sample of letters and noting what’s inside
De-identify≈Blacking out the account number before forwarding the letter
Deny≈Returning a letter to the sender because it contains a credit card
Macie≈An inspector walking the warehouse shelves (S3) listing which boxes hold passports
Allow list≈The inspector’s note: ‘the company’s own public address is fine, ignore it’
Real AWS example · a Macie job on two buckets

Weekly scan with a custom identifier for employee IDs.

$ aws macie2 create-custom-data-identifier --name employee-id \
    --regex 'EMP-[0-9]{6}' --keywords employee staff --maximum-match-distance 30

$ aws macie2 create-classification-job --name weekly-hr --job-type SCHEDULED \
    --schedule-frequency '{"weeklySchedule":{"dayOfWeek":"MONDAY"}}' \
    --custom-data-identifier-ids cdi-1234 \
    --s3-job-definition '{"bucketDefinitions":[{"accountId":"111122223333",
       "buckets":["hr-exports","hr-archive"]}]}'

Findings appear in Macie, EventBridge and Security Hub.

Exam-style scenario

A healthcare company publishes order events to an existing SNS standard topic. A partner subscriber must not receive patient names or insurance IDs, but the events must still be delivered. The company already uses SNS message data protection. What should it configure?

  1. A. A Deny statement for the PHI data identifiers.
  2. B. A De-identify statement (mask or redact) for the PHI data identifiers, plus Audit for evidence.
  3. C. Macie on the topic.
  4. D. A CloudWatch Logs data protection policy.
Show the worked answer

Answer: B

De-identify keeps delivering messages while hiding the sensitive values; Audit records findings.

Why not the others

  • A: Deny would stop delivery, which the question forbids.
  • C: Macie scans S3, not SNS messages.
  • D: Logs policies apply to log groups, not topic messages.
How the exam tests this
  • “Find PII across S3”→ Macie.
  • “Ignore known safe values in Macie”→ Allow list.
  • “Mask PII in SNS messages, keep delivering”→ De-identify.
  • “Block messages containing PII”→ Deny operation.
  • “Sensitive data in DynamoDB”→ Export to S3, then Macie.
Must remember
  • SNS data protection: standard topics, audit / de-identify / deny.
  • Not available to new customers.
  • Macie finds, doesn’t mask.
  • Macie: automated discovery vs jobs.
  • Allow lists = ignore these.
06

Cheatsheet extras: fine-grained access to secrets, safe rotation cutover and old patterns

The cheat sheet adds three practical points: how to let a role read only some secrets or parameters (condition keys and the KMS encryption context), why turning on rotation can break applications at once, and an older “secrets in an encrypted S3 bucket” pattern you may still see in practice questions.

Concept profile

Narrowing access to specific secrets and parameters

often confused with one IAM statement for all secrets
?What is it?

Policy conditions that limit a role to the secrets or parameters it really needs: by name path, by tag, by version stage, and, for SecureString parameters, by the KMS encryption context that names the parameter.

⚙How does it work?
  • Secrets Manager: use the secret ARN with a path (secret:prod/payments/*), aws:ResourceTag/env (or secretsmanager:ResourceTag/…), and secretsmanager:VersionStage to allow only AWSCURRENT.
  • Parameter Store: SSM encrypts each SecureString with the encryption context PARAMETER_ARN = arn:aws:ssm:…:parameter/<name>. A kms:EncryptionContext:PARAMETER_ARN condition on kms:Decrypt lets a role decrypt only parameters under one path, even if many share the same key.
  • Use ssm:GetParametersByPath with a path resource like parameter/prod/app1/*.
  • Every call is logged in CloudTrail, so access to each secret is auditable on its own.
{ }Structure
1 · Which secretResource ARN pathsecret:prod/payments/*parameter/prod/app1/*or a tag: aws:ResourceTag/env2 · Which versionsecretsmanager:VersionStage= AWSCURRENT onlyRotation Lambda alone may readAWSPENDING3 · Which decryptkms:Decrypt only whenkms:EncryptionContext:PARAMETER_ARNmatches the parameter path
Name, version and key: three places to say “only this one”.
⇄Narrow access vs one statement for all secrets
Narrow accessOne broad statement
ResourcePath or tag per environment"Resource": "*"
KMS keyShared key, decrypt limited by encryption contextkms:Decrypt on the key for everything
Leak of one roleExposes one app’s secretsExposes every secret in the account
AuditPer secret in CloudTrailStill logged, but every role could read everything
!Common mistakes the exam tests
  • Turning on rotation before every application reads the secret from Secrets Manager: rotation runs immediately by default and the old password stops working for apps with the value hard-coded.
  • Giving kms:Decrypt on a shared key with no encryption-context condition: the role can decrypt every parameter that uses that key.
  • Granting ssm:GetParameter but forgetting kms:Decrypt on a customer managed key: the call fails for SecureString values.
  • Building a “secrets bucket” in S3 with SSE-KMS when Secrets Manager or Parameter Store would give versioning, rotation and per-secret audit for less work.
✓Benefits and use cases
  • Separate dev, test and prod API keys that share one KMS key safely.
  • Thousands of device credentials in Parameter Store standard tier at no extra cost, each auditable.
  • Least privilege for a rotation function versus the application.

Safe cutover when you start rotating

Order matters: (1) store the current password as a secret, (2) change every application to read it at run time (SDK, caching library or the Lambda extension), (3) only then turn on rotation. If you enable rotation and don’t want an immediate rotation, use --no-rotate-immediately; the first rotation then waits for the schedule.

Older material saysToday
“Secrets are limited to 4 KB.”A secret value can be up to 64 KB. Standard parameters are 4 KB, advanced 8 KB.
“Parameter Store: 10,000 parameters, no rotation.”Standard tier: 10,000 per Region, free. Advanced tier: 100,000, paid, with parameter policies (expiration notifications) but still no built-in rotation.
“Rotation is only for RDS, DocumentDB, Redshift.”Managed rotation for RDS, Aurora, DocumentDB, Redshift and others; any other secret via a Lambda rotation function.
“Macie classifies by theme, file extension and regex.”Macie uses managed and custom data identifiers, allow lists and automated sensitive data discovery; findings go to EventBridge and Security Hub.
“Store secrets in S3 encrypted with a customer managed key, one prefix per secret.”Works, but Secrets Manager is the exam answer for rotation and per-secret access; Parameter Store SecureString is the low-cost answer.
Think of it like · a hotel key-card system

One master system, but each card opens only certain doors.

AWS conceptFamiliar thing
Path in the ARN≈A card that opens only the rooms on floor 5
Resource tag condition≈A card that opens only rooms with a “staff” sticker
VersionStage = AWSCURRENT≈The card works only with today’s lock code, not tomorrow’s
Encryption context PARAMETER_ARN≈The room number is printed inside the lock; a card for room 501 can’t open 502
Rotating too early≈Changing every lock before guests get new cards
Real AWS example · decrypt only one app’s parameters

The role can read and decrypt parameters under /prod/app1/ only, although all parameters use the same KMS key.

{
  "Effect": "Allow",
  "Action": [ "ssm:GetParameter", "ssm:GetParametersByPath" ],
  "Resource": "arn:aws:ssm:eu-west-1:111122223333:parameter/prod/app1/*"
},
{
  "Effect": "Allow",
  "Action": "kms:Decrypt",
  "Resource": "arn:aws:kms:eu-west-1:111122223333:key/1234abcd-...",
  "Condition": { "StringLike": {
    "kms:EncryptionContext:PARAMETER_ARN":
      "arn:aws:ssm:eu-west-1:111122223333:parameter/prod/app1/*" } }
}

Even if someone widens the SSM statement by mistake, KMS still refuses to decrypt parameters outside the path.

Exam-style scenario

A developer moved an RDS password into Secrets Manager and enabled rotation every 30 days in the console. Within minutes, several older applications that still read the password from a config file fail to log in. What happened, and what should the team do next time?

  1. A. Secrets Manager blocks database connections from applications that don’t use it.
  2. B. Enabling rotation rotated the password immediately; update all applications to read the secret first, then enable rotation.
  3. C. The secret’s resource policy denies the applications.
  4. D. The KMS key used by the secret was disabled.
Show the worked answer

Answer: B

Rotation runs once right away by default, so the hard-coded password became invalid. Migrate every consumer first, or enable rotation without an immediate rotation.

Why not the others

  • A: Secrets Manager doesn’t sit in the database connection path.
  • C: These apps never call Secrets Manager.
  • D: The apps aren’t decrypting anything; they use an old password.
How the exam tests this
  • “Apps fail right after enabling rotation”→ Immediate rotation; apps still use the old value.
  • “Role may decrypt only some SecureString parameters”→ kms:EncryptionContext:PARAMETER_ARN.
  • “Only the current version of a secret”→ secretsmanager:VersionStage = AWSCURRENT.
  • “Many credentials, auditable, cheapest”→ Parameter Store SecureString (standard tier).
  • “Rotation needed”→ Secrets Manager.
Must remember
  • Enable rotation = rotates now (unless told not to).
  • Migrate apps before rotating.
  • SecureString context: PARAMETER_ARN.
  • Secret max 64 KB (old material: 4 KB).
  • GetParameter on SecureString also needs kms:Decrypt.
07

Lecture summary map

Day 5 on one screen.

1. Mind map

① Secrets ManagerGetSecretValue + DecryptCMK for cross-accountReplicas per Region② Rotationcreate·set·test·finishSingle vs alternatingPrivate: SM endpoint③ Parameter StoreSecureString via KMSStd 4 KB · Adv 8 KBNo rotation④ Logs maskingData identifiersAccount or log grouplogs:Unmask⑤ Messages + MacieSNS: audit/mask/denyMacie finds in S3Allow lists⑥ Domain 5 reviewDays 1–512 mixed questionsFix weak daysData Protection 5secrets + masking
Tap a branch to jump back to that part of the lecture. Try redrawing this map from memory on paper.

2. Match the requirement to the control

“Rotate the database password automatically”→Secrets Manager rotation“No downtime during rotation”→Alternating users strategy“Rotation times out in a private subnet”→Endpoint/NAT for Lambda“Config values, cheapest, encrypted”→Parameter Store SecureString“Another account must read the secret”→Resource policy + CMK“Hide card numbers in application logs”→Logs data protection policy“Find PII across S3 buckets”→Amazon Macie“Only auditors see unmasked logs”→logs:Unmask permission
The left column is the exam wording; the right column is the answer.

3. “If the question says… pick…”

Hard-coded DB password in codeSecrets Manager + IAM role
Rotate automatically, least effort for RDSManaged rotation (RDS-managed password)
Rotation must never break loginsAlternating users + superuser secret
Rotation Lambda times outSecrets Manager VPC endpoint or NAT
Secret read from another accountResource policy + CMK key policy + IAM
Same secret in a DR RegionReplicate the secret
Cheap encrypted configurationParameter Store SecureString
Warn when a parameter is staleNoChangeNotification (advanced tier)
PII in all log groups, now and futureAccount-level data protection policy
Auditors see raw log valueslogs:Unmask
Mask PII in SNS but still deliverDe-identify operation
Find sensitive files in S3Amazon Macie
Day 5 in one sentence

Keep secrets in a store that rotates them, keep plain config in a cheap store, and make sure sensitive values that escape into logs and messages are masked on arrival.

08

Must-remember cheat sheet

1. Read secret = GetSecretValue + kms:Decrypt.
2. Cross-account: resource policy + CMK.
3. Labels: AWSCURRENT · AWSPENDING · AWSPREVIOUS.
4. Rotation steps: create · set · test · finish.
5. Fastest schedule: every 4 hours.
6. Alternating users: needs superuser secret.
7. Private rotation Lambda: SM endpoint.
8. Replicas: rotate primary, value flows out.
9. Parameter Store: no rotation.
10. Std 4 KB free · Adv 8 KB, policies.
11. SecureString: --with-decryption.
12. Logs masking: at ingestion, not retroactive.
13. Raw logs: logs:Unmask.
14. Account-level policy covers future groups.
15. SNS: audit · de-identify · deny, standard topics.
16. Macie finds (S3); doesn’t mask.
17. Enabling rotation rotates now: move every app to Secrets Manager first.
18. Limit SecureString decrypt with kms:EncryptionContext:PARAMETER_ARN.
09

Core quiz

Check the basics first. Pick an answer, then press Check.

10

Hard quiz

Harder than most real exam questions on purpose, with one “choose two” and one matching question. Aim for 9 out of 12.

11

Domain 5 review quiz (Days 1–5)

Questions from every Data Protection day. If you miss one, reopen that day’s lecture and its “Must remember” boxes.

12

Practice test questions (from your mock exams)

These 8 questions match today’s topics. 7 come from your own mock exams (the “practice tests” folder); the wording was tidied, and where a mock answer was out of date or wrong, the explanation says so, with the mock and question number at the end. The last one is a new exam-style question (marked “New question”) written in October 2026 from the SCS-C03 exam guide and current AWS documentation, to cover recent changes.

13

Hands-on lab (30 minutes, low cost)

  1. Create a secret with a customer managed key, read it with get-secret-value, then look at list-secret-version-ids to see the staging labels.
  2. Call rotate-secret with a simple rotation Lambda (or just put a new value with put-secret-value) and watch AWSCURRENT and AWSPREVIOUS move.
  3. Create a SecureString parameter under /lab/dev/ and read it with and without --with-decryption.
  4. Create a log group, add a data protection policy for EmailAddress, write a log event containing an email with put-log-events, and view it masked. Then view it with a role that has logs:Unmask.
  5. Optional: enable Macie’s 30-day trial, run a one-time job on a bucket with a fake test file containing sample card numbers, then disable Macie.
  6. Clean up: delete the secret with --force-delete-without-recovery (lab only), the parameter, the log group and the KMS key schedule.