To meet the requirement that developers cannot view credit card numbers while the fraud detection account can , the solution must (1) ensure the sensitive data is masked at ingestion/storage in CloudWatch Logs, and (2) allow only an authorized principal to view unmasked values .

First, the developers must attach the data protection policy to the CloudWatch log group that receives the API Gateway HTTP API access logs (and/or the Lambda log group if credit card numbers can appear there). A CloudWatch Logs data protection policy is applied at the log group level and instructs CloudWatch Logs to identify sensitive data using managed data identifiers (for example, CreditCardNumber ) and then apply the configured de-identification action (here, masking). Without attaching the policy to the log group, the masking/redaction behavior will not be enforced for newly ingested log events, and developers could still see raw request parameters.

Second, to permit only the fraud detection account to reveal the masked values when necessary, the IAM role that the fraud detection account assumes must have the specific CloudWatch Logs permission to unmask protected data. Granting logs:Unmask to that role enables authorized access to view the sensitive values while keeping them masked for everyone else who lacks that permission (such as developer accounts assuming other roles).

Options A and E are not required for CloudWatch Logs data protection enforcement; the core controls are log-group policy attachment (to perform masking) and IAM authorization (to permit unmasking only for the fraud role). Therefore, the correct combination is C (apply the policy to the log group that captures the HTTP API logs) and B (grant logs:Unmask to the fraud detection role).