Question 27
Domain 4: Monitoring and LoggingA DevOps administrator is responsible for managing the security of a company's Amazon CloudWatch Logs log groups. The company's security policy states that employee IDs must not be visible in logs except by authorized personnel. Employee IDs follow the pattern of Emp-XXXXXX, where each X is a digit. An audit discovered that employee IDs are found in a single log file. The log file is available to engineers, but the engineers are not authorized to view employee IDs. Engineers currently have an AWS IAM Identity Center permission that allows logs:* on all resources in the account. The administrator must mask the employee ID so that new log entries that contain the employee ID are not visible to unauthorized personnel. Which solution will meet these requirements with the MOST operational efficiency?
Correct answer: A
Explanation
CloudWatch Logs data protection policies can “mask sensitive data” in log events, and a custom data identifier lets you match the employee ID pattern “Emp-\d{6}” so new entries are hidden automatically. Access to reveal masked values is controlled by the “logs:Unmask” permission, so an IAM Deny on that action prevents engineers from viewing employee IDs while keeping the solution centralized and operationally efficient.
Why each option is right or wrong
A. Create a new data protection policy on the log group. Add an Emp-\d{6} custom data identifier configuration. Create an IAM policy that has a Deny action for the Action":"logs:Unmask" permission on the resource. Attach the policy to the engineering accounts.
CloudWatch Logs data protection policies are the native control for masking sensitive fields in log events, and they can be attached at the log-group level so new ingested events are automatically redacted without changing the application or log pipeline. The custom data identifier can match the exact employee-ID format with a regex such as `Emp-\d{6}`, and the reveal action is governed by `logs:Unmask`; an explicit IAM `Deny` on `logs:Unmask` ensures engineers with broad `logs:*` access still cannot view the masked values.
B. Create a new data protection policy on the log group. Add managed data identifiers for the personal data category. Create an IAM policy that has a Deny action for the "NotAction":"logs:Unmask" permission on the resource. Attach the policy to the engineering accounts.
Managed personal-data identifiers are broader and NotAction with Deny would block nearly everything except unmasking.
C. Create an AWS Lambda function to parse a log file entry, remove the employee ID, and write the results to a new log file. Create a Lambda subscription filter on the log group and select the Lambda function. Grant the lambda:InvokeFunction permission to the log group.
Lambda redaction adds custom processing and maintenance when CloudWatch Logs can mask natively.
D. Create an Amazon Data Firehose delivery stream that has an Amazon S3 bucket as the destination. Create a Firehose subscription filter on the log group that uses the Firehose delivery stream. Remove the "logs:*" permission on the engineering accounts. Create an Amazon Macie job on the S3 bucket that has an Emp-\d{6} custom identifier.
Firehose, S3, and Macie analyze exported data, not efficiently mask new log entries in CloudWatch Logs.