How to prevent reading expired Bigtable data?

You work for a large ecommerce company. You store your customer's order data in Bigtable. You have a garbage collection policy set to delete the data after 30 days and the number of versions is set to 1. When the data analysts run a query to report total customer spending, the analysts sometimes see customer data that is older than 30 days. You need to ensure that the analysts do not see customer data older than 30 days while minimizing cost and overhead. What should you do?

Set the expiring values of the column families to 29 days and keep the number of versions to 1.
Use a timestamp range filter in the query to fetch the customer's data for a specific range. Source Reference Answer
Schedule a job daily to scan the data in the table and delete data older than 30 days.
Set the expiring values of the column families to 30 days and set the number of versions to 2.

Community Votes

100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

This question tests the understanding that Bigtable garbage collection is eventual and not immediate, creating a trap where users rely solely on GC policies for read consistency.

Bigtable garbage collection is an asynchronous process that does not immediately delete expired data, potentially leaving records visible for up to a week. The community consensus is that applying a timestamp range filter at query time is the most effective method to ensure analysts only see data within the desired 30-day window.

A common mistake is choosing to schedule a manual deletion job (Option C), which introduces unnecessary overhead and cost compared to simply filtering read requests.

Community Discussion (7 comments)

Matt_108 👍 8 Selected: B

Agree with others https://cloud.google.com/bigtable/docs/garbage-collection

cuadradobertolinisebastiancami 👍 6 Selected: B

Agree with MAtt_108 and AllenChen 123. "Garbage collection is a continuous process in which Bigtable checks the rules for each column family and deletes expired and obsolete data accordingly. In general, it can take up to a week from the time that data matches the criteria in the rules for the data to actually be deleted. You are not able to change the timing of garbage collection." "Always apply a filter to your read requests that exclude the same values as your garbage collection rules. " Ref: https://cloud.google.com/bigtable/docs/garbage-collection#data-removed

Pime13 👍 1 Selected: B

Because it can take up to a week for expired data to be deleted, you should never rely solely on garbage collection policies to ensure that read requests return the desired data. Always apply a filter to your read requests that excludes the same values as your garbage collection rules. You can filter by limiting the number of cells per column or by specifying a timestamp range.

m_a_p_s 👍 1 Selected: B

"Because it can take up to a week for expired data to be deleted, you should never rely solely on garbage collection policies to ensure that read requests return the desired data. Always apply a filter to your read requests that excludes the same values as your garbage collection rules. You can filter by limiting the number of cells per column or by specifying a timestamp range." https://cloud.google.com/bigtable/docs/garbage-collection#data-removed

Sofiia98 👍 1 Selected: B

I will go for B too

GCP001 👍 3

B. Use a timestamp range filter in the query to fetch the customer's data for a specific range. Always use query filter as garbage collectore runs on it's way - https://cloud.google.com/bigtable/docs/garbage-collection

scaenruy 👍 1 Selected: B

B. Use a timestamp range filter in the query to fetch the customer's data for a specific range.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

Option B is correct because Bigtable's garbage collection runs asynchronously and can take up to seven days to actually remove data marked for deletion. Therefore, to guarantee that a query never returns data older than 30 days, you must explicitly filter the results by timestamp during the read operation. This method enforces the business logic without incurring the cost of manual scans or changing the underlying storage policy.

Why the Other Options Are Wrong

Option A is incorrect because reducing the TTL to 29 days changes the data retention requirement rather than solving the visibility lag issue. Option C is incorrect because manually scanning and deleting data is expensive, operationally heavy, and redundant given the built-in GC mechanisms. Option D is incorrect because increasing the number of versions to 2 would actually increase the likelihood of seeing older data, contrary to the goal.

Community Comment Notes

Community members consistently cite the official Google Cloud documentation stating that GC can take up to a week to execute. Comments emphasize the best practice of mirroring GC rules in read filters to ensure data consistency, as relying solely on server-side expiration is unreliable for immediate query constraints.

Official Reference

https://cloud.google.com/bigtable/docs/garbage-collection

Exam Strategy

When encountering questions about Time-to-Live (TTL) or garbage collection in distributed databases, remember that deletion is an eventual, background process. If the scenario requires strict data exclusion at the moment of reading, always prioritize filtering the query results over modifying storage policies or manual deletion jobs.

Related Analysis

← Back to PDE Study Guide