PL-300 DirectQuery Practice Question
A company has a Power BI semantic model that uses DirectQuery to a SQL Server database. The model includes a large fact table with 100 million rows. Users are experiencing slow report performance. Which TWO actions should the developer take to improve query performance?
⚠ Common exam trap
Candidates often think hiding unused columns improves performance, but in DirectQuery it does not reduce query size. They also mistakenly believe calculated columns are beneficial, whereas they add overhead.
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 indexes on columns used in filters and relationships.
In DirectQuery mode, incremental refresh is not supported (option A is incorrect). Creating indexes on columns used in filters and relationships (option B) speeds up query execution on SQL Server. Removing unused columns from the fact table (option C) reduces the amount of data transferred per query. Hiding columns (option D) does not affect the data retrieved by queries. Adding calculated columns (option E) increases query overhead and degrades 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.
- ✗
Configure incremental refresh to limit data retrieved per query.
Why it's wrong here
Incremental refresh is designed for Import mode, where data is cached in Power BI and partitioned by date or other ranges so only new or changed data is refreshed periodically. DirectQuery does not use an in-memory cache; every visual interaction triggers a live query against the data source, so there is no refresh cycle to schedule or partition. Configuring incremental refresh on a DirectQuery model either is unsupported in the traditional sense or requires a hybrid setup, and it would not limit the data retrieved per query because each visual still submits a full, on-demand SQL query to the source.
- ✓
Create indexes on columns used in filters and relationships.
Why this is correct
In DirectQuery mode, Power BI sends every visual query directly to the underlying SQL Server, so query performance depends on the source engine's ability to return results quickly. Creating indexes on columns used in filters and relationship joins lets SQL Server use efficient lookup and merge operations instead of full table scans, dramatically reducing query latency. Without appropriate indexes, even simple filter operations can force the database to scan millions of rows, which directly degrades the Power BI report experience.
- ✓
Remove unused columns from the fact table.
Why this is correct
Removing unused columns from the fact table reduces the size of the semantic model's metadata and the set of columns available for query generation. In DirectQuery, Power BI constructs SELECT statements that may include columns from fact tables when they are used in relationships, groupings, or measures; eliminating columns that no report or calculation needs ensures those columns are never referenced in generated SQL. This decreases the amount of data transferred from SQL Server to Power BI per query and simplifies the query text, easing the load on the source database.
- ✗
Hide columns that are not needed in reports.
Why it's wrong here
Hiding a column in Power BI only prevents it from appearing in the Fields list for report authors; the column remains fully part of the semantic model and its storage and query surface area are unchanged. The DirectQuery engine will still include hidden columns in generated SQL queries when they are referenced by relationships, measures, or other internal metadata structures, so the same volume of data is transferred from SQL Server. Unlike physically removing the column, hiding does nothing to reduce the cost of query generation or data retrieval, making it a governance feature, not a performance optimization.
- ✗
Add calculated columns to precompute aggregations.
Why it's wrong here
Calculated columns are evaluated during each DirectQuery request because they are not persisted in the database; the DAX expression is translated into query logic that SQL Server must compute on the fly, often over huge tables. This adds significant complexity to the generated SQL, frequently producing correlated subqueries or forcing the engine to materialize entire tables just to compute the new column. Precomputing aggregations requires storing pre-aggregated data, which calculated columns cannot do in DirectQuery—so they increase query overhead rather than reduce it.
Go deeper
Related to this question
About these practice questions
One of 217 original PL-300 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.