PL-300 Visualize and analyze the data Practice Question
Which TWO actions can you take to improve the performance of a Power BI report that uses a large dataset?
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
✓
Use aggregations to pre-summarize data at higher levels.
Option B is correct because aggregations let you pre-summarize large fact tables at higher grain levels (for example, daily or monthly totals) and cache those smaller tables in memory, so most report queries hit the compact aggregation table instead of scanning billions of detail rows, dramatically reducing query time. Option D is correct because every visual on a page issues its own DAX query against the dataset, so reducing the number of visuals lowers the total number of queries and the volume of data retrieved per page render, which directly improves report responsiveness. Option A is not appropriate because adding more columns to slicers increases the cardinality of filter combinations and generates larger, more complex filter context, which typically slows queries rather than speeding them up. Option C is wrong because deeply nested calculated measures are evaluated at query time and consume CPU and memory, degrading rather than improving performance. Option E is incorrect because DirectQuery pushes queries to the source database on every interaction and generally performs worse than Import mode for large datasets, not better.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use multiple columns in slicers for more granular filtering.
Why it's wrong here
Adding multiple columns to slicers increases the number of distinct values loaded into the filter context, which raises cardinality and forces the storage engine to scan and process far more combinations for every report interaction. Each slicer column triggers its own cross-filtering overhead, and multi-column slicers can multiply the size of DAX query filters, slowing both query execution and visual rendering, especially with large fact tables.
- ✓
Use aggregations to pre-summarize data at higher levels.
Why this is correct
Aggregations are pre-built summary tables (often at month, quarter, or year level) that the Power BI storage engine transparently redirects to when a query matches the aggregation's grain. By answering from a compact, precomputed table instead of scanning every transaction row, the engine dramatically reduces I/O and CPU usage, which accelerates report performance with minimal impact on user interactivity or drill-down capability.
- ✗
Create complex calculated measures that use many nested functions.
Why it's wrong here
Calculated measures that nest many functions—especially iterators and multiple CALCULATE statements—force repeated context transitions and storage engine calls for every row in the current filter context, exponentially increasing the evaluation cost. Complex DAX often breaks block-mode execution and forces row-by-row processing, which prevents VertiPaq from using its fastest vectorized operations and can make even small visual filters consume disproportionate memory and time.
- ✓
Reduce the number of visuals on a page.
Why this is correct
Each visual on a Power BI page issues its own separate DAX query and receives its own result set from the dataset; fewer visuals mean fewer parallel queries, less data transferred over the network, and less work for the rendering engine. This reduces memory pressure and eliminates redundant cross-visual synchronisation, so the page loads and reacts to slicers or filters noticeably faster without changing the underlying data model.
- ✗
Switch from Import mode to DirectQuery mode.
Why it's wrong here
DirectQuery mode sends every visual's query to the underlying database in real time, which removes the benefits of VertiPaq compression and in-memory columnstore indexing that make Import mode fast for large datasets. Live queries add network latency, source database contention, and repeated query planning overhead, so switching from Import to DirectQuery typically worsens performance for dashboard browsing—it is intended for real-time data needs, not speed optimization.
Go deeper
Related to this question
About these practice questions
This PL-300 question is part of Courseiva's 524-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PL-300 practice question is part of Courseiva's free Microsoft 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 PL-300 exam.