2.4 Data Privacy, PII Handling and Sensitive Information

Google Cloud Professional Machine Learning Engineer Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

0.1 Exam Overview, Blueprint & Certification Logistics 0.2 Study Strategy, Scenario Mechanics & 8-Week Roadmap

2 Section 1: Architecting Low-Code AI Solutions (~13%)

1.1 BigQuery ML: Model Types, SQL Syntax and In-Database Evaluation 1.2 Feature Engineering and Feature Selection in BigQuery ML 1.3 Generating Predictions with BigQuery ML 1.4 AutoML on Agent Platform: Tabular, Image, Text and Video Training 1.5 Fine-Tuning Gemini Models from BigQuery 1.6 Model Garden: Evaluating and Selecting the Right Model 1.7 Industry-Specific AI APIs: Document AI, Vision, Translate and Speech 1.8 Generative Media and Models as a Service: Gemini, Imagen and Veo 1.9 Optimizing Gemini Applications for Cost, Latency and Availability

3 Section 2: Collaborating Within and Across Teams to Manage Data and Models (~16%)

2.1 Organizing and Exploring Tabular, Text, Image and Video Data 2.2 Choosing the Preprocessing Tool: BigQuery, Dataflow, Spark and In-Memory Python 2.3 Creating and Consolidating Features in Agent Platform Feature Store 2.4 Data Privacy, PII Handling and Sensitive Information 2.5 Notebook Environments: Collaboration and Security Best Practices 2.6 Prototyping in Workbench and Colab Enterprise with PyTorch, scikit-learn and JAX 2.7 Prototyping with Model Garden Foundational and Open Models in Notebooks 2.8 Choosing the Development and Experimentation Environment 2.9 Evaluating Generative Solutions: LLM-as-a-Judge and RAG Evaluation 2.10 Experiment Tracking, Artifact Lineage and Model Registry Governance

4 Section 3: Scaling Prototypes into ML Models (~21%)

3.1 Choosing the Model Type: ARIMA, DNN, LLM and Classical Baselines 3.2 Choosing the Product: AutoML, BigQuery ML, Custom Training and Pipelines 3.3 Choosing the Deployment Strategy at Design Time 3.4 Modeling Techniques for Interpretability Requirements 3.5 Organizing Training Data on Cloud Storage and BigQuery 3.6 Ingesting Structured and Unstructured Data into Training Pipelines 3.7 Training SDKs and Services: Custom Training, Kubeflow on GKE, AutoML and Tabular Workflows 3.8 Troubleshooting ML Model Training Failures 3.9 Hyperparameter Tuning, Bayesian Optimization and Vizier 3.10 Model Evaluation Metrics, Transfer Learning and Fine-Tuning 3.11 Evaluating Compute and Accelerator Options: CPU, GPU and TPU 3.12 Distributed Training Strategies, Hardware Acceleration and Performance Optimization

5 Section 4: Serving and Scaling Models (~20%)

4.1 Batch and Online Inference: Agent Platform, Model Garden, Cloud Run and GKE 4.2 Rollout Strategies: Canary, Traffic Splitting, Shadow and Blue-Green 4.3 Tuning Models for Production: Vector Search and Model Compression 4.4 Deploying Models to Public and Private Endpoints 4.5 Choosing Serving Hardware: CPU, GPU, TPU and Edge 4.6 Scaling the Serving Backend for Throughput

6 Section 5: Automating and Orchestrating ML Pipelines (~18%)

5.1 Validating Data and Models Inside Pipelines 5.2 Agent Platform Pipelines: Kubeflow Pipelines (KFP) and TFX Architecture 5.3 Reusable Pipeline Components, Artifacts and ML Metadata Lineage 5.4 Ray on Agent Platform for Distributed Python Workloads 5.5 MLOps CI/CD Automation, Retraining Triggers and Skew Prevention

7 Section 6: Monitoring AI Solutions (~13%)

6.1 Securing AI Systems: Exfiltration, Malicious Prompting and Model Armor 6.2 Responsible AI, Explainable AI, Fairness Metrics and Model Governance 6.3 Model Monitoring: Feature Skew and Drift Detection 6.4 Operational Troubleshooting, Performance Profiling and Cost Optimization 6.5 Monitoring, Testing and Evaluating Generative AI in Production

2.4 Data Privacy, PII Handling and Sensitive Information

Key Takeaways Explain This Topic AI

Sensitive Data Protection inspects data for infoType matches and can de-identify through redaction, masking, bucketing, or format-preserving tokenization.

Format-preserving encryption with a cryptographic token is the technique that keeps a join key usable across datasets while removing the raw identifier.

Generalization and k-anonymity reduce re-identification risk from quasi-identifiers such as ZIP code, birth date, and gender, which together identify most individuals.

BigQuery column-level access with policy tags and row-level access policies enforce least privilege without duplicating tables per audience.

VPC Service Controls create a data-exfiltration perimeter around ML services, and CMEK gives the organization control of the encryption keys.

Last updated: September 2026

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.

• Technique What it does Joins survive? Reversible? Use when
• Redaction Removes the value entirely No No The field has no analytical value
• Masking Replaces characters ( ****1234 ) No No Support agents need partial display

Bucketing / generalization Replaces with a range (age → 30–39) No No Aggregate analysis; reduces re-identification

Date shifting Shifts dates by a consistent per-entity offset Yes, within entity With the key Clinical timelines must stay relative

Crypto hashing HMAC to a fixed-length digest Yes No A stable pseudonym is enough

Format-preserving tokenization (FPE) Token with the same format as the original Yes Yes , with the key Downstream systems expect a 16-digit field and re-identification is authorized

Deterministic encryption Same input to same ciphertext Yes Yes Joins plus authorized reversal

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.