An application logs the full request body to Amazon CloudWatch Logs to help with debugging. The bodies sometimes contain personally identifiable information such as email addresses and national identity numbers. A developer must stop this sensitive data from being readable in the logs while keeping the surrounding log entries useful. What is the most appropriate approach in application code and logging configuration?
- ALeave the logging as it is but restrict the log group with an IAM policy so only administrators can read it, since access control alone satisfies the requirement to protect the PII.
- BEncrypt the entire log group with a customer managed KMS key, because encryption at rest renders the personally identifiable information unreadable to anyone who later queries the logs.
- CSanitise the request body in code before logging by removing or masking the PII fields, and enable a CloudWatch Logs data protection policy to mask sensitive patterns at rest. Correct
- DLower the application log level to error so the verbose request bodies are dropped, which prevents any personally identifiable information from ever reaching the log group.
Why A is wrong: Tight access control is useful but the PII is still stored in clear text, so anyone with read access sees it and the data remains exposed, which does not meet the requirement to make it unreadable.
Why B is wrong: KMS encryption protects logs at rest but authorised readers see fully decrypted entries including the PII, so encryption alone does not redact or mask the sensitive fields in query results.
Why C is correct: Redacting PII in code before it is written plus a CloudWatch Logs data protection policy that masks known sensitive data types gives defence in depth, keeping non sensitive context while hiding PII.
Why D is wrong: Raising the log level reduces volume but error entries can still carry request bodies with PII, so it neither reliably removes the sensitive fields nor preserves useful debugging context.