A European retailer receives erasure requests under data protection law and must be able to prove, within a month of each request, that the customer's rows are gone from its BigQuery warehouse. The customer table is partitioned by signup month and clustered by customer_id, a daily snapshot of it is kept for thirty days, and the dataset's time travel window is set to the maximum. The privacy team has already deleted the rows with a DML statement and considers the matter closed. What should you do?
- A.
Replace the DML deletion with a partition drop on the partition containing the customer, because dropping a partition bypasses time travel entirely.
- B.
Export the table, filter the customer out with Dataflow, and load the result into a new table, which is the only supported way to guarantee removal.
- C.
Re-run the deletion as a DELETE with FOR SYSTEM_TIME AS OF set to the current timestamp, which removes the customer's row from the historical versions held by time travel as well as from the current table.
- D.
Point out that the rows remain readable through time travel and in the snapshots, and add a step that lets those copies age out or deletes the affected snapshots before the deadline.
Show answer
Answer: D
A DML delete removes the row from the current table but leaves it readable through time travel and inside existing snapshots, so erasure is not complete until those copies are gone.
- A. Partition drops are also covered by time travel, and the partition holds every customer who signed up that month.
- B. Works but is disproportionate, and the claim that it is the only supported method is untrue.
- C. FOR SYSTEM_TIME AS OF is read-only syntax; there is no way to delete from historical versions with DML.
- D. Names the two copies that still expose the data — time travel and snapshots — and sequences the erasure against the legal deadline.