PDE Maintaining and Automating Data Workloads Practice Question
You are optimizing a BigQuery query that scans 1 TB of data every day. The query joins a large fact table (partitioned by date) with a small dimension table. You notice that the query always scans the entire fact table, even though you only need the last 7 days of data. Which optimization will MOST reduce the bytes scanned?
⚠ Common exam trap
PDE often tests whether candidates know that partition pruning requires a filter on the partitioning column; candidates may choose clustering or materialized views, but the most direct reduction in bytes scanned comes from adding the WHERE clause on the partition column.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Add a WHERE clause that filters on the date column used for partitioning.
BigQuery partitioned tables allow partition pruning, where the query engine skips partitions that do not match the filter condition. Adding a WHERE clause on the partitioning column (date) restricts the scan to only the last 7 days' partitions, drastically reducing bytes scanned. This is the most direct and effective optimization for the described scenario.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a materialized view that pre-aggregates the data by day.
Why it's wrong here
A materialised view pre-aggregates results but does not prune partitions; the query still reads the full fact table unless a date filter is applied. It is tempting for repeated aggregate queries, where it would be correct, but here the requirement is restricting scanned partitions to the last seven days.
- ✓
Add a WHERE clause that filters on the date column used for partitioning.
Why this is correct
Partition pruning only activates when the query filters on the partitioning column. Adding that WHERE predicate lets BigQuery eliminate all but the last seven date partitions, cutting bytes scanned from 1 TB to roughly 7 days' worth.
- ✗
Cluster the fact table on the join key used in the query.
Why it's wrong here
Clustering on the join key speeds up join processing but does not reduce bytes scanned, since clustering prunes only on the clustered columns and the query still reads every date partition. It is tempting for join-heavy queries, where it would be correct, but partition pruning on the date column is what limits scanned bytes.
- ✗
Change the table to use time-unit column partitioning with a 1-day partition interval.
Why it's wrong here
The fact table is already partitioned by date, so redefining partitioning as a time-unit column with a 1-day interval changes nothing about pruning. It is tempting because day-level partitioning is the right pattern for date-filtered scans, but the existing setup already satisfies it; the query needs a date predicate.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PDE question from scratch — 747 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Google Cloud exam blueprint
This PDE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PDE exam.