A healthcare SaaS logs patient emails and national IDs to CloudWatch Logs and forwards alerts through SNS to an on-call topic, and compliance requires automatic masking in both places with an audit finding for each match. Which masking control satisfies both log and messaging requirements?
Select an answer to reveal the explanation.
Short Explanation
You need protection in both CloudWatch Logs and the SNS messages sent to the on-call topic. Deidentification masks matching patient data, while the CloudWatch audit records provide compliance evidence for each match.
Full Explanation
The CloudWatch Logs data protection policy with deidentify audit masks matching emails and national IDs at egress, including the console, Logs Insights, metric filters, and subscription filters, unless the caller has logs:Unmask; it also emits an audit finding for each match. The SNS message data protection policy with mask deidentification applies inline masking to payloads delivered to the on-call topic, so both destinations receive protection. The SNS policy that masks only email addresses leaves national IDs exposed in notifications, even though the CloudWatch policy protects the logs. SSE-KMS encryption protects data through encryption but does not inspect payloads, mask values, or create per-match findings, so subscribers may still receive plaintext identifiers. Logs Insights query redaction with audit history is not a supported masking control; masking and audit findings come from data protection policies, not query redaction. Exam caveat: distinguish masking with audit from encryption or query filtering, because those controls do not provide the required combination. Practical check: deploy both policies with managed identifiers for email and national ID, publish synthetic events containing both, and verify masked output in CloudWatch Logs and SNS along with the corresponding audit findings.