Exception handlers in the payments API dump full HTTP bodies into CloudWatch Logs, and some bodies contain cardholder data fragments. What should developers change?
Select an answer to reveal the explanation.
Short Explanation
Logs are not a lost-and-found for PAN scraps. Scrub or drop cardholder fields before anything hits CloudWatch — debugging is not a free pass to archive payment bodies.
Full Explanation
Exception handlers in a municipal payments API must not dump full HTTP bodies into CloudWatch Logs when those bodies can contain cardholder data fragments. Developers should sanitize or redact sensitive fields before logging and never send raw cardholder fragments to CloudWatch. Secure logging is part of application-level PCI-minded design for city payment flows: keep correlation IDs and non-sensitive error classes for operators, while ensuring payment payloads are stripped on every exception path including unexpected serializer failures.
Increasing log retention to indefinite so PCI fragments remain available for every future audit fails because longer retention amplifies exposure of prohibited data rather than removing it. Mirroring the same full bodies to a public S3 debugging bucket fails conceptually—it multiplies uncontrolled copies of cardholder fragments. Disabling structured logging so redaction libraries cannot run fails because it removes the tooling needed to redact consistently on exception paths.
Exam caveat: redaction must cover nested JSON, multipart fields, and error objects that re-embed the original request; missing one serializer bypasses the control. Operational check: trigger a controlled exception with a synthetic payload containing fake PAN-like fields, query CloudWatch, confirm those fields are absent, and document that log groups retain only sanitized diagnostics.