nerdexam
Google

PROFESSIONAL-DATA-ENGINEER · Question #247

You work for a financial institution that lets customers register online. As new customers register, their user data is sent to Pub/Sub before being ingested into BigQuery. For security reasons, you…

The correct answer is D. Before loading the data into BigQuery, use Cloud Data Loss Prevention (DLP) to replace input values with a cryptographic format-preserving encryption token. Option D is correct because Cloud DLP's format-preserving encryption (FPE) tokenization is reversible - authorized users (like customer service reps) can de-tokenize the value to recover the original Government ID, while the stored value in BigQuery remains protected. FPE also…

Submitted by jaden.t· Mar 30, 2026Designing data processing systems

Question

You work for a financial institution that lets customers register online. As new customers register, their user data is sent to Pub/Sub before being ingested into BigQuery. For security reasons, you decide to redact your customers' Government issued Identification Number while allowing customer service representatives to view the original values when necessary. What should you do?

Options

  • AUse BigQuery's built-in AEAD encryption to encrypt the SSN column. Save the keys to a new table that is only viewable by permissioned users.
  • BUse BigQuery column-level security. Set the table permissions so that only members of the Customer Service user group can see the SSN column.
  • CBefore loading the data into BigQuery, use Cloud Data Loss Prevention (DLP) to replace input values with a cryptographic hash.
  • DBefore loading the data into BigQuery, use Cloud Data Loss Prevention (DLP) to replace input values with a cryptographic format-preserving encryption token.

How the community answered

(52 responses)
  • A
    2% (1)
  • B
    12% (6)
  • C
    4% (2)
  • D
    83% (43)

Explanation

Option D is correct because Cloud DLP's format-preserving encryption (FPE) tokenization is reversible - authorized users (like customer service reps) can de-tokenize the value to recover the original Government ID, while the stored value in BigQuery remains protected. FPE also maintains the original data format (same length and character type), minimizing downstream schema issues.

Option C fails on the key requirement: cryptographic hashing is a one-way operation - once hashed, the original value cannot be recovered, so customer service reps could never view the original ID, ever.

Option B fails because column-level security controls who sees the column, but doesn't actually redact the data at rest. It also gives CS reps all-or-nothing access rather than a controlled view of an otherwise masked value.

Option A fails because AEAD encryption in BigQuery is not the right tool for this pipeline pattern - it doesn't integrate with the Pub/Sub ingestion stage, and storing encryption keys in a sibling BigQuery table is a poor security practice with no access control guarantee.

Memory tip: Hash = Highway with no U-turn (irreversible). FPE Token = Reversible toll road (authorized users can go back). Whenever a question says "redact but recover," you need reversible tokenization, not hashing.

Topics

#Data Loss Prevention (DLP)#Data Security#PII Redaction#Tokenization

Community Discussion

No community discussion yet for this question.

Full PROFESSIONAL-DATA-ENGINEER Practice