PDE Storing the Data Practice Question
A data engineering team needs to run SQL analytics on a large BigQuery dataset from a Looker Studio dashboard. The dashboard must return results quickly, and the underlying data changes only once per day through a batch load. The team wants to minimize query cost and latency for repeated dashboard queries. What should they do?
⚠ Common exam trap
The trap here is assuming an in-memory acceleration layer replaces precomputation, when a materialized view is what actually reduces scanned bytes for repeated aggregate queries.
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
✓
Create a materialized view that aggregates the dataset and configure it to refresh on a daily schedule.
Materialized views precompute and store query results, and with a daily refresh schedule they match the batch update cadence. Repeated dashboard queries hit the stored results, cutting bytes scanned and latency. This directly targets the cost and performance goals, unlike caching layers or partitioning that do not precompute aggregations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable the BigQuery BI Engine reservation and rely on it to cache all dashboard queries automatically.
Why it's wrong here
BI Engine accelerates queries by caching data in memory, but it requires a reservation and works best for subsecond interactive queries over frequently accessed tables. It does not precompute aggregations, so complex queries still scan base tables. While it can reduce latency, it does not minimize bytes processed the way a materialized view does, so it is not the best fit alone.
- ✗
Export the dataset to Cloud Storage as CSV and have Looker Studio query the files directly.
Why it's wrong here
Looker Studio cannot efficiently query raw CSV files in Cloud Storage as a BigQuery dataset, and external data access typically scans full files without columnar pruning. This would increase latency and cost and complicate dashboard development. It does not leverage BigQuery's optimizer, so it fails the requirement to reduce query cost and latency.
- ✗
Partition the table by ingestion date and require all dashboard queries to filter on that column.
Why it's wrong here
Partitioning helps when queries filter on the partition column, but the dashboard may aggregate across dates. It does not precompute results or reduce repeated aggregation work, so each refresh still scans the same data. While partitioning is a good practice, it does not address the repeated-query cost problem as directly as a materialized view.
- ✓
Create a materialized view that aggregates the dataset and configure it to refresh on a daily schedule.
Why this is correct
A materialized view stores precomputed results and can be refreshed automatically or on a schedule. Because the dashboard queries repeat and the source data changes daily, the view serves cached results, reducing bytes scanned and latency while lowering cost. BigQuery can also use the materialized view for compatible queries, making it well suited to this batch-refresh analytics pattern.
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.