Structured logs for a benefits app accidentally include Authorization headers and raw SSNs. What instrumentation rule was broken?
Select an answer to reveal the explanation.
Short Explanation
Observability should not become a secret dump. Redact Authorization headers and raw SSNs—logs are not a second copy of the vault.
Full Explanation
Structured logs for a benefits app that accidentally include Authorization headers and raw SSNs broke a core instrumentation rule: do not log secrets or sensitive identifiers. Redact or omit bearer tokens, passwords, and raw SSNs from observability output. Municipal benefits data is highly sensitive; logging it expands breach scope and can violate policy even when the "debugging" intent was sincere.
Always logging full bearer tokens and SSNs so Insights can join every table is unsafe and unnecessary.
Storing secrets only in plaintext log fields instead of Secrets Manager inverts secure configuration practice.
Printing private keys in X-Ray annotations for faster filters is a severe secret-exposure anti-pattern.
Exam caveat: Observability must respect data classification—redaction is part of correct instrumentation.
Operational check: Add log scrubbing for Authorization and SSN patterns, rotate any exposed credentials, set retention appropriately, review Insights sample events for leakage, and educate the benefits team with a secure logging checklist. Keep the civic/municipal context in mind: benefits and tax workloads attract auditors; secret-bearing logs become incident zero.