What is PII and how to keep it out of logs

WHAT THIS TESTS The interviewer checks both a definition and engineering judgment about preventing data leakage, since logs are a notorious accidental sink for sensitive data.

A GOOD ANSWER COVERS Define PII as any information that can identify a specific individual, either directly such as name, email, government ID, or phone, or indirectly when combined, such as IP address, device identifiers, precise location, or a quasi-identifier set. Then describe a layered prevention strategy. The strongest control is at the source: do not log sensitive fields at all, and pass structured context objects through an allowlist so only approved keys are ever emitted. Add a redaction layer in the logging pipeline that masks known patterns, for example replacing values for keys like email, password, token, and ssn, and pattern-matching things like card numbers. Scrub query strings and request bodies before they reach the logger, since PII often hides in URLs. Finally, restrict log access and set retention limits so any residual data is short-lived.

COMMON WRONG ANSWERS Defining PII correctly but proposing no technical control. Logging everything and planning to scrub later, which leaves a window of exposure and often misses fields. Relying on developers to remember to redact manually, which is unreliable. Hashing PII but keeping it joinable, which may still be identifying.

LIKELY FOLLOW-UPS How do you handle PII in error stack traces. How do you test that redaction works in CI. What about third-party logging or analytics SDKs. How do retention and access control complement redaction.

ONE CONCRETE EXAMPLE A research tool logged full request bodies for debugging, capturing participants' emails. The fix added a logging middleware with a denylist of sensitive keys that replaced their values with a redacted token before serialization, an allowlist for query parameters, and a CI test asserting that a sample payload containing an email produced no email in the emitted log line.