Exams / SCS-C03 / Study guide / Masking sensitive data (CloudWatch Logs data protection, Macie)
Masking sensitive data (CloudWatch Logs data protection, Macie): SCS-C03 study notes and practice questions
What to know about Masking sensitive data (CloudWatch Logs data protection, Macie) for the SCS-C03 exam, from the Data Protection domain (18% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe sensitive values that end up where they should not, such as application logs or messages sent to topic subscribers. They ask how to detect and mask those values while keeping the logs or messages useful.
Masking controls
CloudWatch Logs data protection policies scan log events for sensitive data. They use managed data identifiers, such as credit card numbers, AWS secret keys and national identifiers, or custom identifiers. Matching values are masked for anyone who lacks the logs:Unmask permission. Findings can be sent to a log group, S3 or Firehose for audit.
Amazon SNS message data protection policies audit, mask or block sensitive data in messages published to a topic. The feature is closed to new customers from April 30, 2026. The exam guide still covers masking in messages, so know what it does, but for a new design remove or mask the value in the publisher before it reaches the topic, and use CloudWatch Logs data protection policies for logs.
Amazon Macie discovers sensitive data in S3 buckets. It finds data that already exists. It does not mask logs or messages.
Application-side removal stops the value from being written at all. It is the only control that meets a rule that says “never store it.”
How to choose
Scenario wording
Pick
Hide card numbers in application logs from most viewers
CloudWatch Logs data protection policy
Stop SSNs from reaching subscribers of a topic
Remove or mask the value in the publisher; SNS message data protection is closed to new customers
Find sensitive data already stored in S3 buckets
Amazon Macie
Keep the raw value for a small audit group only
logs:Unmask granted only to that group
The value must never be written anywhere
Remove it in the application before logging
Common traps
SNS message data protection for a new build. It is closed to new customers, so it fits only an existing setup.
Macie for logs. Macie scans S3 objects. It does not mask CloudWatch Logs.
Confusing masking with encryption. Masking hides values from viewers. The underlying data is still stored.
Granting logs:Unmask broadly, which reveals every value to that principal.
Using a policy for a “never store” rule. Only the application change meets that rule.
Custom identifiers without testing. False positives hide useful data, and misses leave sensitive data visible.
A payments startup sends its application logs to Amazon CloudWatch Logs. The logs sometimes include full card numbers and customer email addresses, because a developer logged raw request bodies last quarter.
Developers and on-call engineers must see logs with that data masked. A small audit group must be able to see the unmasked values when an investigation needs them. Application code cannot be changed quickly, so the fix must work on the log group itself.
Which solution meets these requirements?
Choose one answer.
AA. Mask card numbers and email addresses in the application code before each log line is written. Deploy the fix to every service, and add a code review rule that blocks logging of request bodies in future.
BB. Export the log group to Amazon S3 every hour, and run Amazon Macie on the bucket to find card numbers and emails. Ask the security team to delete the matching lines from the exported files by hand.
CC. Attach a data protection policy to the log group that audits and masks card numbers and email addresses with managed data identifiers. Grant the logs:Unmask permission only to the audit role.
DD. Subscribe a Lambda function to the log group that replaces card numbers and emails in each event, and writes the redacted copy to a second log group. Give developers access only to the second group.
Show the answer and explanation
Answer: C
A. Wrong: Masking in code fixes the source, but the team cannot change every service quickly. The requirement says the fix must work on the log group itself, and code changes give the audit group no controlled way to see original values.
B. Wrong: Macie finds sensitive data after it is stored, so developers still see raw values in the live log group. Editing exported files by hand is slow and does not change what the log group shows.
C. Right: Correct. The data protection policy masks matching values as events are ingested, so developers without logs:Unmask see masked data. Unmasking is an explicit permission, so the audit group access stays narrow and can be reviewed. Learn more: Help protect sensitive log data with masking (opens in a new tab)
D. Wrong: The copy hides values from developers, but the original log group still stores unmasked data, and the function is code the team must operate. It also cannot give the audit group a controlled unmasked view.
Explanation
A CloudWatch Logs data protection policy masks matching values such as card numbers and emails as events are ingested. Only principals with logs:Unmask see the original values, so the audit group can see them while developers cannot. Code changes, after-the-fact scanning, and a redacted copy each leave raw values in place or require ongoing code.
Want more on Masking sensitive data (CloudWatch Logs data protection, Macie)? The 5 full-length practice sets have 5 more Masking sensitive data (CloudWatch Logs data protection, Macie) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Masking sensitive data (CloudWatch Logs data protection, Macie)