Google ACE Practice Question: A data warehouse team queries a 10 TB BigQuery…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  BigQuery table clustering on the date column

  Why it's wrong here

  Clustering on the date column physically sorts data into blocks based on that column's values, allowing BigQuery to use block-level pruning to skip some data when filters match. But clustering does not divide the table into date-segment partitions — it only improves the likelihood that a query touches fewer blocks within a given scan region. For a query filtering a range like the last 30 days, an unpartitioned clustered table can still end up scanning most of the table because the blocks are not aligned to date boundaries. Partitioning is the mechanism that guarantees elimination of non-relevant date ranges.

• ✗

  Creating a materialized view for the last 30 days

  Why it's wrong here

  Materialized views store precomputed results for a defined query and automatically refresh as the base table changes, making them efficient for repeated dashboards or fixed-window reports. But a view built for 'the last 30 days' is a snapshot of that exact rolling window; an ad-hoc query asking for a different range, such as a specific historical month, cannot be satisfied by the view and must scan the underlying base table. BigQuery's automatic query rewriting to use materialized views is limited and doesn't handle arbitrary date-range predicates. This approach does not ensure low-cost scans for ad-hoc date-range analysis, unlike partitioning which prunes at the storage layer.

• ✓

  Date/timestamp partitioned table on the date column

  Why this is correct

  Partitioning by a DATE/TIMESTAMP column physically organizes the table into discrete segments (e.g., per day, month, or year). A query that filters on that column with a range predicate triggers partition pruning, so BigQuery scans only the segments that match the filter rather than the entire table. This directly cuts the number of bytes billed, which is the primary cost driver in BigQuery, making it the most effective solution for frequent date-range analysis.

• ✗

  Increasing BigQuery slot reservations for faster full-table scans

  Why it's wrong here

  Adding BigQuery slots (via reservations) increases the compute capacity available for query execution, which may reduce wall-clock time for large scans by parallelizing more workers. However, it does not alter the physical data that must be read; a full-table scan still processes and bills for every byte in the table. With on-demand pricing, cost is directly tied to bytes processed, so faster scans actually don't lower cost — and with reservations, you're paying a flat fee regardless of scan volume. This misses the core need to eliminate unnecessary data reads.

Go deeper

Related to this question