PL-300 Deploy and maintain assets Practice Question
You are the Power BI administrator for a large enterprise. The company has a Power BI Premium capacity with a single dataset that is used by multiple reports and dashboards. The dataset is refreshed daily at 3:00 AM, and the refresh typically completes within 2 hours. Recently, users have reported that the dataset is not showing the most recent data until after 6:00 AM. You investigate and find that the scheduled refresh is taking 4 hours to complete, and there are no errors in the refresh history. The dataset uses import mode and connects to an on-premises SQL Server data warehouse. The data model contains several large fact tables and multiple calculated tables and measures. What should you do to reduce the refresh time and ensure data is available by 5:00 AM?
⚠ Common exam trap
Candidates often choose Option C (DirectQuery) thinking it eliminates refresh time entirely, but they overlook that DirectQuery changes the entire query model and is not a direct fix for a scheduled import refresh that is simply taking too long due to data volume.
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
✓
Implement incremental refresh on the fact tables to refresh only new and changed data
Implementing incremental refresh on the fact tables allows Power BI to refresh only new or changed data instead of the entire dataset each time. This significantly reduces the refresh window, especially for large fact tables, because only the latest partition (e.g., today's data) is processed. Since the scheduled refresh starts at 3:00 AM and must complete by 5:00 AM, incremental refresh can cut the refresh time from 4 hours to under 2 hours by avoiding reprocessing historical data.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Remove all calculated tables and measures and replace them with calculated columns in Power Query
Why it's wrong here
Replacing calculated tables and measures with calculated columns in Power Query is counterproductive because calculated columns are evaluated row-by-row during each refresh and then physically stored in the model, which increases both refresh duration and model size. Measures are computed at query time and have zero impact on refresh, so removing them changes nothing; calculated tables are also refresh-time artifacts, and moving their logic to Power Query adds an extra transformation layer that can break query folding and prolong the refresh pipeline rather than solving the underlying fact-table volume problem.
- ✓
Implement incremental refresh on the fact tables to refresh only new and changed data
Why this is correct
Implementing incremental refresh on fact tables is the correct solution because it partitions the table by date and only processes partitions that are new or changed since the last refresh, dramatically reducing the amount of data pulled from the source and the storage engine workload. This requires an import-mode dataset with a date-time watermark column, RangeStart and RangeEnd parameters, and proper policy settings for archive periods; it directly targets the root cause of a prolonged refresh cycle by limiting the refresh scope to deltas instead of reprocessing the entire fact table history.
- ✗
Change the dataset storage mode to DirectQuery to avoid the import process
Why it's wrong here
Switching the dataset to DirectQuery eliminates the import phase entirely, but it merely shifts the performance burden to query time: every visual interaction sends a native query to the source system, which can cause severe latency and overload the underlying database with live queries. DirectQuery also lacks the compression, in-memory caching, and robust DAX capabilities of import mode, and it is especially unsuitable for complex models with heavy transformations or large user concurrency, so while it changes when the work happens, it does not reduce total processing and often makes the whole solution much slower operationally.
- ✗
Install an additional on-premises data gateway and configure load balancing
Why it's wrong here
Installing an additional on-premises data gateway and configuring load balancing addresses throughput for many parallel refresh jobs by distributing connections across multiple gateways, but it has no effect on a single refresh job that is slow due to massive fact-table volumes. The refresh bottleneck in this scenario is the time spent extracting, transforming, and loading the data into the service, not the gateway's ability to transfer the data, so adding another gateway only helps if the gateway were the constraint—which it is not—and therefore this action fails to shorten the one long-running refresh that is the actual problem.
Go deeper
Related to this question
About these practice questions
This PL-300 question is part of Courseiva's 217-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.