Bigtable stores customer order data with GC policy delete after 30 days and max versions=1, but analysts sometimes see data older than 30 days. Minimize cost/overhead and prevent readers from seeing data older than 30 days. What should you do?

The correct answer is to use a timestamp range filter in the query. Bigtable's garbage collection (GC) policy runs asynchronously in the background and does not guarantee immediate deletion of data older than the specified period. Therefore, even with a 30-day GC policy, data older than 30 days might still be physically present and readable until GC processes it. Applying a timestamp filter in the query ensures that only data within the desired 30-day window is retrieved, regardless of the GC's current state, directly addressing the requirement to prevent analysts from seeing old data. Setting the expiring values to 29 days (or 30 days with max versions=2) would still rely on the asynchronous GC, not guaranteeing immediate removal from view. Scheduling a daily job to scan and delete data would incur additional cost and operational overhead, and it's redundant given Bigtable's built-in GC, which is designed to handle this.