PL-300 Prepare the data Practice Question
Which THREE actions in Power Query Editor can improve the performance of data refresh? (Select three.)
⚠ Common exam trap
Many exam-takers think sorting improves compression (a common misconception from database indexing), but in Power BI, compression is handled by the VertiPaq engine and is not influenced by the order of data in Power Query.
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
✓
Remove columns that are not used in the report.
Option C is correct because removing unused columns reduces the volume of data that Power Query must read, transform, and load into the model, lowering memory and refresh cost. Option D is correct because disabling 'Enable load' on intermediate queries prevents those staging tables from being materialized into the data model, so refresh avoids loading data that no report consumes. Option E is correct because applying filters as early as possible (ideally at the source or in the first steps) reduces the number of rows flowing through subsequent transformation steps, which is the most effective way to speed up refresh. Option A is not correct because sorting rows does not improve refresh performance in Power Query; compression benefits in the VertiPaq engine come from column cardinality and encoding, not from row order. Option B is not correct because merging queries before filtering typically increases the work done on larger, unfiltered datasets; filtering first reduces the rows that must be joined.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Sort data in ascending order to improve compression.
Why it's wrong here
Sorting in Power Query does not influence VertiPaq compression, which depends on column cardinality, data distribution, and data type rather than physical row order. Sorting adds processing overhead, can break query folding, and forces the engine to materialize an ordered intermediate set that is often unnecessary. As a result, it provides no meaningful performance benefit and may introduce avoidable refresh delays.
- ✗
Merge queries before filtering.
Why it's wrong here
Merging large tables before applying row filters forces the query engine to join every row from both inputs, creating a large intermediate table that consumes memory and increases processing time. Since filtering is not pushed down, many of the merged rows are later discarded, so the merge performs wasted work on rows that never appear in the final output. The correct pattern is to filter each source table independently before merging, reducing the join input sizes and keeping the merge operation lightweight.
- ✓
Remove columns that are not used in the report.
Why this is correct
Removing columns that are not used in the report reduces the data volume that must be evaluated, compressed, and stored in the VertiPaq engine, directly shrinking the model size and refresh duration. Every column, even an unused one, requires space for its dictionary and encoded segments, so eliminating irrelevant columns cuts memory overhead and can speed up query performance by reducing the number of column segments to scan. This practice also simplifies the query editor view and prevents accidental inclusion of sensitive or duplicate data in the model.
- ✓
Disable the 'Enable load' option for intermediate tables that are not needed in the model.
Why this is correct
Disabling the 'Enable load' option on intermediate or helper tables prevents them from being materialized as tables in the data model, so those columns are not stored in VertiPaq and do not consume memory or refresh time. The query still executes when referenced by other queries, but the final output of that query is not persisted, which is ideal for staging queries, mapping tables, or calculation helpers that exist solely to support other transformations. This lowers the model footprint without losing the flexibility of chaining queries together.
- ✓
Filter rows as early as possible in the query.
Why this is correct
Applying row filters as early as possible reduces the number of rows that flow through every subsequent transformation, lowering memory usage and speeding up joins, groupings, merges, and custom steps. When filters are pushed to the source through query folding, the underlying database can eliminate rows natively, drastically cutting the amount of data transferred to Power Query. Filtering later in the pipeline wastes resources on rows that will eventually be discarded, so early filtering is a fundamental optimization for both refresh performance and final model size.
Go deeper
Related to this question
About these practice questions
Courseiva writes every PL-300 question from scratch — 524 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 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.