A column of customer emails must stay hidden from analysts but stay usable for joins. Which approach fits?
Why A is the answer
De-identify the column using Cloud DLP tokenization
Deterministic tokenization hides the value and keeps joins working.
In detail
- Tokenization hides the value and stays consistent, so joins still work.
- Masking every value the same way is what keeps joins possible.
Use case
An illustrative scenario, not a real incident.
Analysts must join orders and support tables on customer email, without reading it. The same email always becomes the same token, so joins still work.
See it in different ways
flowchart TD A["Protect data"] --> B["Cloud IAM and organization policies"] A --> C["Encryption and key management"] A --> D["Cloud DLP for personal data"] A --> E["Regional storage for sovereignty"]
mindmap
root((Governance))
Location
Regional storage
Organization policies
Protection
Cloud DLP
Data masking
Separation
Project per environment
Ownership
Federated governancemindmap
root(("Tokenized email"))
n1["Orders table"]
n2["Same token"]
n3["Support table"]
n4["Same token"]Key point: Deterministic tokens hide values and keep joins.
Why the other options are wrong
- B. Rely on a naming convention that marks the column as private
- A naming convention controls nothing.
- C. Export the table to CSV without that column for analysts
- Removing the column breaks joins.
- D. Grant analysts full table access and audit their queries
- Audit does not hide the column.