Apply an inbound SNS message data protection policy with the De-identify operation to mask sensitive data

SCS-C02 By islever Editorial Last updated

Design and implement controls that provide confidentiality and integrity for data in transit. Design and implement a logging solution.

Short answer

B An inbound SNS message data protection policy with the De-identify operation masks sensitive data before delivery.

Question

A company is investigating controls to protect sensitive data. The company uses Amazon Simple Notification Service (Amazon SNS) topics to publish messages from application components to custom logging services. The company is concerned that an application component might publish sensitive data that will be accidentally exposed in transaction logs and debug logs. Which solution will protect the sensitive data in these messages from accidental exposure?
  1. Use Amazon Made to scan the SNS topics for sensitive data elements in the SNS messages. Create an AWS Lambda function that masks sensitive data inside the messages when Macie records a new finding.
  2. Configure an inbound message data protection policy. In the policy, include the De-identify operation to mask the sensitive data inside the messages. Apply the policy to the SNS topics. Correct Answer
  3. Configure the SNS topics with an AWS Key Management Service (AWS KMS) customer managed key to encrypt the data elements inside the messages. Grant permissions to all message publisher IAM roles to allow access to the key to encrypt data.
  4. Create an Amazon GuardDuty finding for sensitive data that is transmitted to the SNS topics. Create an AWS Security Hub custom remediation action to block messages that contain sensitive data from being delivered to subscribers of the SNS topics.

Key Takeaways

SNS message data protection policies are purpose-built to scan messages for sensitive data and take actions like masking (De-identify) on inbound or outbound messages—exactly this requirement. Macie (A) discovers sensitive data in S3/managed stores, not live SNS messages, and a Lambda mask (A) is custom code. KMS encryption (C) protects at rest but does not mask content in logs. GuardDuty/Security Hub (D) detect, they do not mask. B is correct.

To stop sensitive data in SNS messages from leaking into transaction/debug logs, configure an inbound message data protection policy on the SNS topics that scans incoming messages and applies the De-identify operation to mask detected sensitive data before delivery. This protects the data at the messaging layer without a custom Lambda or encryption scheme.

Common mistake: Using Macie (A)—it classifies sensitive data in stored data (S3, etc.), not in-flight SNS messages, and would still need a Lambda to mask. Encrypting with KMS (C) protects confidentiality but leaves plaintext in logs. GuardDuty/Security Hub (D) are detect-and-alert, not masking. B is the native control.

Expert Analysis

Why the Answer Is Correct

An inbound SNS message data protection policy lets you define sensitive-data detectors and the De-identify operation, which masks detected sensitive elements inside messages before they are published to subscribers—directly preventing accidental exposure in downstream transaction and debug logs, with no custom code.

Why the Other Options Are Wrong

A uses Macie, which discovers sensitive data in managed data stores (not live SNS messages) and would still require a custom Lambda to mask. C encrypts messages with KMS but does not mask content, so sensitive values still appear in logs. D uses GuardDuty/Security Hub, which detect and alert but do not de-identify messages. B is the correct native solution.

Community Comment Notes

Community voted B (100). Commenters linked the AWS Compute blog introducing message data protection for SNS and noted the inbound policy with De-identify masks sensitive data inside messages. B confirmed.

Official Reference

https://docs.aws.amazon.com/sns/latest/dg/message-data-protection.html

This link opens the official vendor documentation in a new tab.

Community Votes

B
100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

  1. grekh001 👍 6
    B. https://aws.amazon.com/blogs/compute/introducing-message-data-protection-for-amazon-sns/
  2. nischal77777 👍 1 Answered B
    Data Protection: AWS introduced data protection policies for Amazon SNS to help ensure that sensitive data within messages is not exposed inadvertently. These policies can be used to define operations such as de-identifying or masking sensitive information before it's processed or logged. De-identify Operation: The de-identify operation in the data protection policy allows you to automatically mask or obfuscate sensitive information in the SNS messages. This helps prevent sensitive data from being exposed in transaction logs or debug logs.
  3. aescudero51 👍 1 Answered B
    Answer is B Inbound message data protection policy: This feature of Amazon SNS is specifically designed to scan incoming messages for sensitive data and take actions like masking or redacting it. De-identify operation: This option within the policy allows you to mask the sensitive data identified by the policy, preventing its exposure in the logs. Applied to SNS topics: By applying the policy to the SNS topics, all messages published to those topics will be scanned and protected.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Preserve EC2 forensic evidence by isolating first, then capturing memory before stopping the instance

S-grade

Grant the report Lambda Security Hub read-only access because findings are already in Security Hub

S-grade

Deny inbound MySQL 3306 and allow outbound TLS 443 with ephemeral return in a custom NACL

S-grade

Prepare a PHI/public-bucket audit with Macie, Audit Manager, and Security Hub FSBP

S-grade

← Back to SCS-C02 Study Guide