Quiz: Privacy Engineering

Twelve questions. Answers with explanations follow — work through them first.

1. §31.1 reduces the major regulations to six capabilities. Which one does the chapter argue carries the other five?

  • A. Delete
  • B. Account
  • C. Find
  • D. Export

2. A salted SHA-256 hash of an email address is:

  • A. Anonymous, and outside the scope of the regulations
  • B. Pseudonymized, and still personal data
  • C. Not data about a person at all
  • D. Personal data only if the salt is known

3. pii_scan.py measured name matching at 66.7% recall with 9 false positives, and value matching at 44.4% recall with none. §31.2 argues the important comparison is not the recall totals. What is it?

  • A. That value matching is faster
  • B. That value matching finds three columns name matching cannot find at any tuning
  • C. That name matching requires no data access
  • D. That combining them reaches 100%

4. §31.2's ⚠️ callout argues that a scanning program is killed by:

  • A. The columns it misses
  • B. The columns it wrongly flags
  • C. The time it takes to run
  • D. The need for read access to production data

5. §31.3 offers one question to choose between hashing and tokenizing. What is it, and who should answer it?

  • A. "Is the column indexed?" — the DBA
  • B. "How large is the column?" — the platform team
  • C. "Will anyone ever need the original value back?" — the business owner
  • D. "Is the column classified confidential?" — legal

6. With postcode, birth year, and sex retained across 5,000 customers, --k-anon reports 446 singleton classes and 48.2% of rows in a class below five. What is the chapter's conclusion about generalization?

  • A. Two more generalization steps would reach k = 5
  • B. Generalization does not degrade gracefully — four of five steps still leave k = 1, and the step that works throws away almost everything
  • C. k-anonymity is the wrong metric for this data
  • D. The sample is too small to draw conclusions from

7. In Case Study 2, the same three quasi-identifiers gave 6.41% of rows at risk over a sample of the customer base and 48.35% over a 41,208-row segment extract. Why?

  • A. The extract was sampled badly
  • B. The extract used finer geography
  • C. Anonymity comes from crowding, and a segment spreads few people across the same number of cells
  • D. The base sample was ten times larger, so its k was ten times better

8. §31.5's coverage report sorts locations into three groups. What does the middle group — "no mechanism, but expires within the deadline" — let you avoid?

  • A. Documenting the location at all
  • B. Building a deletion path for data that will be gone before the obligation matures
  • C. Including the location in the manifest
  • D. Monitoring the retention setting

9. §31.5's 🧱 callout describes the deletion DAG. Which step does the chapter call "the only part that makes it real"?

  • A. Step 1, resolution
  • B. Step 3, the pre-deletion snapshot
  • C. Step 5, verification
  • D. Step 6, attestation

10. In Case Study 1, three erasure requests had been processed and marked complete, and had missed the clickstream entirely. Why?

  • A. The clickstream was in a different cloud region
  • B. The runbook's author was careless
  • C. The clickstream is keyed by device_id, not customer_id, and the runbook deleted by customer_id
  • D. The clickstream retention had already expired

11. §31.6 compares dynamic masking against maintaining a separate PII-free copy of a table. What is the argument that decided it at Kestrel?

  • A. Masking is faster to query
  • B. The masked copy costs more storage
  • C. The masked copy fails open — a new column in the source is visible unless someone remembers
  • D. Masking satisfies erasure requests

12. §31.12: you find a column of what look like government ID numbers in a table nobody owns. What is the chapter's first move?

  • A. Delete the column immediately
  • B. Query it to determine how many real values it contains
  • C. Revoke the grants, then investigate
  • D. Stop looking at it, and escalate within the hour without deleting it

---

Answers

1 — C. Find.

Export, delete, and correct are all "find, then do something," and restrict and account both depend on knowing what you hold about whom. A platform that can locate a person in a query does all six cheaply; one that cannot does all six as investigations, forever — which is Case Study 1's nine days. It is also the capability nobody budgets for, because it produces no visible artifact of its own.

2 — B. Pseudonymized, and still personal data.

This is the most common technical misunderstanding in the territory. Hashing replaces the direct identifier and preserves equality, so records for the same person still join — which is exactly what makes the data still about an identifiable person. Pseudonymization reduces risk and changes no obligation in §31.1. D is wrong in an interesting way: whether the salt is known affects how easily the value is reversed, not whether the column relates to an identifiable person.

3 — B. Value matching finds three columns name matching cannot find at any tuning.

customer_ref (emails), external_key (IP addresses), and legacy_col_3 (government-ID shapes). No vocabulary of column names reaches a column called external_key, so the two strategies are not competing approximations of the same thing — they fail in different directions, and that asymmetry, not the recall figure, is the reason to run both. D is simply false: combined recall is 88.9%, and the two misses are structural.

4 — B. The columns it wrongly flags.

A missed column is a gap you close later; a report with nine false positives out of 22 harmless columns is a report nobody finishes reading. At 64.0% precision against a warehouse with 400 genuinely personal columns, the scanner produces 225 false positives, and by the second run the report is triaged in bulk — along with the real findings buried in it. This is Chapter 25 Case Study 2's alert fatigue in a fourth form. The three fixes are confidence-sorting, permanent suppression, and routing only to owners.

5 — C. "Will anyone ever need the original value back?" — the business owner.

Never means hash: simpler, no vault to run, breach, or keep available, and the irreversibility is the feature. Ever, even rarely, means tokenize: a hash cannot be un-hashed eighteen months later when somebody finds a legitimate need. The reason to ask the business owner rather than the engineer is that "never" said by the person building the pipeline is routinely contradicted by someone else later — and the answer gets written down with a date so the next person knows it was decided rather than defaulted.

6 — B. Generalization does not degrade gracefully.

The ladder goes 446 singletons → 38 → 22 → 6, and all four of those rungs still have k = 1. The first rung that reaches the threshold is postcode_3 alone — no age, no sex, six groups — which is comfortably anonymous and is no longer a dataset anyone wanted. The honest conclusion is that there is rarely a comfortable middle: the choice is normally between anonymous-and-useless and useful-and-pseudonymous, and the failure is not choosing the second but calling it the first.

7 — C. Anonymity comes from crowding.

The extract spreads 41,208 people across the same 13,720 equivalence classes that the base spreads millions across, so the cells empty out. The extract had more people alone in their class than a sample ten times its size. The worse structural property: the more precisely a segment is targeted, the less anonymous it is, so the segments worth sharing are exactly the ones that cannot be shared safely at fine geography. B is wrong — both measurements used ZIP3.

8 — B. Building a deletion path for data that will be gone before the obligation matures.

Kafka tombstones and compaction were estimated at three weeks and deleted from the plan in one meeting, because a 7-day topic cannot hold data long enough for a 30-day deadline to bite. The saving is real but conditional on two things that must be checked: the retention is enforced rather than configured — the verification found a per-partition override at 30 days on a topic set to 3 — and a change to it alerts, because a topic silently moving to 90 days converts a compliant location into an undetected gap. Note that the location still belongs in the manifest and still needs documenting; what it does not need is a delete path.

9 — C. Step 5, verification.

Everything else can succeed while accomplishing nothing. Verification re-runs the find query and asserts zero rows everywhere, which is the only step that detects a location added since the last request. Kestrel's has fired twice, both times on a new table carrying customer_id that had joined the generated manifest and had no deletion mechanism. Step 1 is where the work is and step 3 is counterintuitive and necessary, but a pipeline without step 5 has been failing silently since the last schema change.

10 — C. The clickstream is keyed by device_id.

A person is not one identifier. Kestrel has five identifier spaces — customer_id, device_id, session_id, the email vendor's subscriber ID, and support ticket references — and a deletion operating in one of them misses four, including the largest dataset in the platform. The runbook's author was not careless (B): they deleted from the four places anyone would have named, and nothing in the procedure revealed that naming places from memory is the wrong method. The fix is a resolution step that runs before any deletion, uses full history rather than current state, and is shared with the export path.

11 — C. The masked copy fails open.

Both patterns require someone to act when a column is added: the copy requires someone to exclude it, the policy requires someone to attach one. Neither is automatic — but the failure directions are opposite, and only one of them leaks. Kestrel's masked copy had drifted from its source twice, once for eleven days. The storage and pipeline costs (B) were real and secondary; the measured query overhead of masking was under 2%. D is a distractor and an important one: masking is not deletion and satisfies no obligation in §31.1.

12 — D. Stop looking at it, and escalate within the hour without deleting it.

Continuing to query it creates access records and may make the situation worse. Deleting it can destroy the evidence needed to determine what was exposed, to whom, and for how long — which is precisely what a notification decision depends on, and that decision is not an engineering call. Revoking grants (C) is reasonable and comes after escalation, not instead of it. The strongest single sentence available in an interview or an incident is "I would not delete it," because it demonstrates that you know the difference between an operational problem and a legal one.