2.4 Data Privacy, PII Handling and Sensitive Information

2.4 Data Privacy, PII Handling and Sensitive Information

Blueprint reference: Section 2.1, "Ensuring data privacy and handling sensitive information (e.g., personally identifiable information [PII])."

Privacy questions on this exam are rarely about whether to protect data. They present a scenario where a naive protection technique would break a downstream requirement, and ask for the technique that satisfies both.

Finding Sensitive Data: Inspection

Sensitive Data Protection (the service formerly branded Cloud DLP) scans structured and unstructured data for infoTypes — built-in detectors for email addresses, phone numbers, credit card numbers, national identifiers, medical record numbers, and hundreds more, plus custom detectors defined by regex or dictionary.

Two operating modes matter:

• Discovery / profiling runs continuously across BigQuery and Cloud Storage, producing data profiles that show which tables and columns contain which infoTypes at what confidence. This is the answer to "we do not know where PII lives in our warehouse."
• On-demand inspection scans a specific resource or a stream of content, returning findings with likelihood scores. This is what a pipeline calls before ingesting data into a training set.

De-identification: Choosing the Right Transformation

This is the exam's real content. Each technique destroys something different.

The distinguishing scenario appears constantly: "analysts must be able to join customer records across two datasets, but must never see the raw identifier." Redaction and masking both destroy the join. Hashing preserves it but cannot be reversed. Deterministic or format-preserving tokenization preserves the join and allows an authorized re-identification path — the answer whenever the scenario also mentions fraud investigation, regulatory disclosure, or customer service lookup.

Quasi-Identifiers and k-Anonymity

Removing direct identifiers is not sufficient. The combination of ZIP code, date of birth, and gender uniquely identifies the large majority of a population. Sensitive Data Protection computes risk metrics over these quasi-identifiers:

• k-anonymity — every record is indistinguishable from at least k−1 others on the quasi-identifier set.
• l-diversity — each equivalence class contains at least l distinct values of the sensitive attribute, preventing inference even when the class is large.
• Re-identification risk analysis — estimates the probability of matching a record against a population dataset.

The mitigations are generalization (ZIP 94107 → 941**, exact birth date → birth year) and suppression (dropping records in classes below the threshold). When a scenario says an anonymized dataset was re-identified despite names being removed, quasi-identifiers are the answer.

Access Control Inside BigQuery

Duplicating tables per audience is a maintenance disaster and a recognisable wrong answer. BigQuery has native controls:

• Column-level security via policy tags. Tag a column with a Data Catalog policy tag; only principals holding Fine-Grained Reader on that tag can read it. Everyone else sees the table without that column rather than being denied the table.
• Row-level access policies. A predicate attached to the table restricts which rows a principal sees — for example, a regional analyst seeing only their region.
• Authorized views and datasets. A view can expose derived columns from a source the caller cannot read directly.
• Dynamic data masking. Masked values returned to lower-privileged readers based on policy tag, without a separate table.

For ML specifically, the pattern is: raw PII in a restricted dataset, a de-identified or aggregated feature dataset that data scientists can read, and Feature Store registration pointing at the de-identified side.

Perimeter and Key Controls

• VPC Service Controls define a service perimeter around BigQuery, Cloud Storage, and Agent Platform, so even a principal with valid IAM credentials cannot copy data out of the perimeter. This is the control for exfiltration, including the "an insider with legitimate access downloaded the training set" scenario.
• CMEK (customer-managed encryption keys) puts encryption keys in Cloud KMS under the organization's control, allowing key rotation and revocation. Required by many regulated workloads.
• Private Service Connect / private endpoints keep inference and training traffic off public IP paths.
• Data residency is enforced by choosing regional resources; a multi-region dataset does not satisfy a single-country residency requirement.

PII and Generative AI

Two additional considerations, because Section 6 will return to them:

• Do not send raw PII to a model unless the architecture requires it and the flow is approved. De-identify before the prompt where possible.
• Prompts and responses can leak. Sensitive Data Protection can inspect both directions, and Model Armor screens prompts and responses for sensitive-data disclosure alongside prompt-injection and jailbreak attempts.

Exam Traps

• Hashing when reversal is required. Hashing is one-way; tokenization is not.
• Masking when a join is required. Masking breaks the key.
• Assuming removing names anonymizes a dataset. Quasi-identifiers remain.
• Duplicating tables per audience instead of using policy tags and row-level policies.
• Confusing IAM with VPC Service Controls. IAM decides who may access; VPC-SC decides where data may go.