PL-300 Model the data Practice Question
Which TWO actions should you take to improve the performance of a DirectQuery model in Power BI? (Select two.)
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
✓
Limit the columns selected to only those needed in the report.
Option A is correct because a DirectQuery model translates each visual into a query against the source, so limiting the columns selected to only those needed in the report reduces the width of the generated SQL and the volume of data transferred, lowering query cost and latency. Option C is correct because pushing filters to the source database as much as possible lets the backend engine apply its own indexing and query optimization, so less data is returned to Power BI and processing is done where it is most efficient. Option B is wrong because calculated columns in a DirectQuery table are computed at query time and can force row-by-row evaluation or even prevent query folding, which typically hurts rather than helps performance. Option D is wrong because aggregations on imported tables apply to Import mode tables, not to a DirectQuery model's source tables. Option E is wrong because row-level security filters add predicates to every DirectQuery query and increase complexity and overhead rather than improving performance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Limit the columns selected to only those needed in the report.
Why this is correct
Limiting columns to only those needed reduces the amount of data loaded into the model and the size of each query. In both Import and DirectQuery modes, cutting unused columns decreases memory consumption, storage, and network transfer, which directly lowers query execution time. This is a recommended first step for any performance optimization because it has no downside other than losing access to fields that aren't used.
- ✗
Use calculated columns instead of measures to precompute values.
Why it's wrong here
Calculated columns are calculated at processing time and stored in the table, adding to model size and memory pressure. In DirectQuery, calculated columns are not persisted and are instead evaluated by the database engine on each query, causing significant overhead and potentially blocking query folding optimizations. Measures, by contrast, are evaluated at query time based on the filter context, making them far more efficient for aggregations and dynamic calculations.
- ✓
Push filters to the source database as much as possible.
Why this is correct
Pushing filters to the source database means the query filters are applied as part of the underlying SQL query (query folding) rather than after all rows are returned to Power BI. This dramatically reduces the number of rows transferred across the network and allows the source database to use its indexes and optimizations, leading to faster response times and less load on the Power BI engine. Always design import queries and DirectQuery connectors to ensure that filters are pushed down whenever possible.
- ✗
Create aggregations on the imported tables.
Why it's wrong here
Creating aggregations on imported tables is not a valid performance fix in this context because DirectQuery models cannot leverage user-defined imported aggregations; aggregation tables are only applicable to Import or Dual storage modes. Attempting to add an imported aggregation table would require switching the storage mode from DirectQuery to a mixed or import mode, which defeats the purpose of DirectQuery and adds operational complexity. The technique to improve DirectQuery performance is to prune data and push filters, not to create separate aggregate imports.
- ✗
Implement row-level security filters on the fact table.
Why it's wrong here
Implementing row-level security on the fact table adds a security predicate to every query, forcing Power BI to evaluate permissions for each row, which increases query processing time and prevents some database-side optimizations. While RLS is sometimes necessary, it is a security measure rather than a performance enhancement and can degrade performance for all users, especially with large fact tables. If RLS is required, it should be used judiciously and perhaps moved to the database view if possible, but it is never a recommended action for improving query speed.
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.