In ads infrastructure, the data is the product — and the privacy mistakes are the ones that make the news.
Student edition · understand, apply, verify
Review data purpose, minimization, access, retention, and deletion with an explicit privacy owner.
What you should be able to do: Distinguish anonymity from pseudonymity and keep sensitive identifiers out of ordinary diagnostic logs.
A context-dependent practice guide, not a universal policy or verified personal history. Examples and numbers are illustrative. Use genuine, authorized evidence; personnel/privacy/legal decisions follow applicable organization policies and qualified review.
Concepts explained in this guide
Read these definitions first, or use the linked terms as you go. The examples and limitations are local to this guide; companion pages are optional.
Privacy, minimization, and pseudonymity
Personal data can identify or link a person directly or with other information. Minimize data to an approved purpose. Pseudonymity replaces an identifier but leaves possible linkage; anonymity requires a much stronger contextual assessment.
Example. Hashing an email preserves a stable value and may be dictionary-reversed. HMAC can reduce that attack for parties without the key, but remains linkable pseudonymous data.
Boundary. Legal basis, retention, rights/exceptions, audit access, and deletion of derived/backup copies require qualified context-specific review. Encryption or hashing alone is not compliance.
Authentication, authorization, and IDOR
Authentication establishes who is calling. Authorization determines what that principal may do to a particular object. IDOR/BOLA occurs when a caller can use an object ID to access or mutate another principal's data.
Example. A parameterized query safely treats an input as data, but still needs an owner/permission predicate from trusted authentication context.
Boundary. Never accept caller identity solely from request fields. Input validation, authentication, per-object checks, least privilege, and race-safe policy enforcement are separate controls.
Schema compatibility and semantic contracts
Backward compatibility lets new readers read old data; forward lets old readers read new data. Field identity/default rules differ by format.
Example. Milliseconds changed to seconds under an unchanged integer field is a breaking semantic change.
Boundary. Optional is not universally safe. Registry checks are configured structural rules, not business semantics; schema-ID headers are format/vendor conventions, not Kafka itself.
Ownership, accountability, and decision rights
Ownership names who drives follow-through; accountability names who answers for outcomes. Decision rights specify who chooses/approves and who is consulted.
Example. A migration has a coordinating owner, service owners, and named release authority.
Boundary. DRI/RACI/DACI are local conventions, not guarantees. Role labels do not replace authority, capacity, and follow-through.
Frameworks versus empirical evidence
A framework organizes thinking; it is not automatically a validated causal law. Evidence needs study design, uncertainty, effect size, population, and replication context.
Example. Growth-mindset practices can help in some settings without making effort alone determine outcomes. Examine structural barriers and actual results.
Boundary. Popular books simplify behavioral/neuroscience findings. Priming or a named model is not a guaranteed workplace intervention.
Keep secrets and unnecessary personal data out of ordinary logs. Classified data in an authorized audit/processing path requires explicit purpose, access, retention, and deletion policy.
The privacy lens: classify the data, enforce purpose limitation, set retention, gate access to least privilege, encrypt in transit and at rest, never log PII/secrets, verify consent and lineage (GDPR/CCPA), and keep an audit trail.
What this question is really testing
Whether privacy is a reflex for you, not a checkbox you delegate to a review bot. The signal is that you notice when a diff introduces or moves personal data, ask the right questions about legal basis and lifecycle, and know the specific failure modes — PII in logs, an over-broad access grant, a missing retention TTL, plaintext at rest, using data for a purpose it wasn't collected for. It also tests that you understand privacy as a system property (lineage, deletion, audit), not just field-level hygiene.
How to answer
Classify the data first. Before anything, ask: does this diff touch PII or sensitive data — user IDs, contact info, location, behavioral/interaction data? Data classification drives every other control. Anything unclassified that looks personal gets treated as sensitive until confirmed otherwise.
Check the documented lawful basis and compatible purpose; consent is required only where the applicable law/policy requires it. Escalate new purposes and rights/deletion questions to qualified owners.
Retention. Personal data needs a defined lifetime and a deletion path. Look for a TTL, an expiry job, or a documented retention policy — data that lives forever by default is a violation waiting to happen, and it must honor deletion requests.
Access control — least privilege. Who and what can read this data? Check for over-broad grants, a service reading more than it needs, or a new surface that exposes data to a wider audience than before. Default to least privilege.
Encryption in transit and at rest. Personal data should move over TLS and sit encrypted at rest. Flag plaintext storage, an internal call that dropped to unencrypted, or secrets/keys handled without the proper store.
Minimize/omit sensitive diagnostics by default. Hashes/HMACs remain pseudonymous and may be personal data; approved retention/access/purpose controls still apply.
Consent and legal basis (GDPR/CCPA). Confirm there's a lawful basis and, where required, consent for the processing — and that the code honors opt-outs and “do not sell/share” signals. A feature that ignores a consent flag is a compliance defect regardless of correctness.
Data lineage and audit. Know where the data came from and where it flows, so deletion and access reviews are possible downstream. Sensitive operations should leave an audit trail — who accessed or exported what, when.
What the interviewer is looking for
Privacy as a reflex — you spot personal data entering or moving in a diff without being prompted.
The concrete controls named: classification, purpose limitation, retention, least privilege, encryption.
The “never log PII/secrets” rule stated flatly, including logs, metrics labels, traces, and crash dumps.
Awareness of consent/legal basis and honoring opt-outs, not just field hygiene.
System-level thinking: lineage, deletion, and audit, so the whole lifecycle is compliant.
The most common privacy catch in review — PII leaking into a log line:
import logging
def diagnostic_event(event):
# Data minimization: bounded approved categories only.
allowed_types = {'click', 'impression'}
allowed_status = {'accepted', 'rejected'}
return {'type': event.get('type') if isinstance(event.get('type'), str) and event.get('type') in allowed_types else 'other',
'status': event.get('status') if isinstance(event.get('status'), str) and event.get('status') in allowed_status else 'unknown'}
synthetic = {'type': 'click', 'status': 'accepted', 'user_id': 'u1',
'token': 'synthetic-secret', 'payload': 'not logged'}
logging.info('event processed', extra=diagnostic_event(synthetic))
# A hash/HMAC identifier, if explicitly approved, is still pseudonymous data.
Common follow-ups
How do you know a field is PII if it isn't labeled?
How to answer
Treat the unknown as sensitive. If it could identify a person alone or in combination, handle it as PII until classification says otherwise.
Watch quasi-identifiers. IP, device ID, precise location, and rare attributes re-identify in combination even if none is PII alone.
Pull in the data-classification tooling/owner. Route to the privacy framework or reviewer rather than guessing.
A diff exports an existing dataset to a new consumer. Concerns?
How to answer
Purpose creep. Confirm the new use is within the consented purpose; a new export can silently widen it.
Lineage and deletion. The copy must inherit retention and be reachable by deletion requests.
Access scope. The new consumer should get least-privilege access, not a broad grant.
How do you handle deletion / right-to-be-forgotten in review?
How to answer
Every copy needs a delete path. New stores, caches, and derived tables must be reachable by the deletion pipeline.
Beware derived and backup data. Aggregations, backups, and logs holding PII all count.
Verify, don't assume. Ask how deletion is tested and audited for the new data.
Isn't privacy the review-bot's or privacy team's job?
How to answer
Tooling is a backstop, not the owner. Automated PII detection helps, but a human reviewer owns judgment on purpose and context.
Escalate the hard calls. Loop in the privacy/legal reviewer for novel processing or consent questions.
Encode recurring catches. Turn a repeated leak into a lint rule or checklist item.
Evidence to collect with your approved tools
A decision/review record with the problem, constraints, options, and your contribution.
Relevant tests, dashboards, or measurements with definitions, denominators, dates, and uncertainty.
Incident or delivery records showing actual outcomes and unresolved limitations.
Stakeholder agreements and follow-up actions with owners and review dates.
Only authorized, minimized, safe-to-share evidence. Do not copy confidential personnel notes into a public story.
Worked example: hashing does not remove personal-data obligations
This is an illustrative situation. The point is the reasoning and evidence, not copying the numbers or first-person story.
Sequence for this example. The table explains the evidence and decision at each step.
Step
Evidence, decision, and expected result
Classify the inputs
User ID, contact, device/location, behavioral data, and tokens can identify/link people. Secrets require strict handling.
Hash an identifier
A stable digest can remain linkable or dictionary-reversible; it is not automatically anonymous/non-PII.
Minimize diagnostic output
Log approved bounded event/outcome categories and counts, not raw payloads/tokens or unnecessary identifiers.
Review retained/audit copies
Authorized audit records may legitimately contain classified data under access/retention policy. Legal basis, consent requirements, deletion exceptions, and backup handling depend on applicable rules.
Check your understanding: Is all personal-data processing necessarily based on consent?
No. Applicable law permits different lawful bases and obligations. Have qualified privacy/legal owners validate the actual purpose and rights.
Run and change the example
Download guide_labs.py. Python 3.10+, standard library only. In its directory, run:
python3 guide_labs.py privacy
python3 guide_labs.py test
The lab uses synthetic input and a whitelist-based diagnostic projection that omits identifiers, tokens, and raw payloads.
The program tests its stated finite contracts. It is an educational model, not an implementation of the named production product or a proof of unmodeled distributed faults.
