PL-300 Visualize and analyze the data Practice Question
You have a Power BI dataset with a fact table containing sales transactions and a dimension table for customers. The customer dimension includes a calculated column that uses the LOOKUPVALUE function to retrieve a customer's region from another table. The report performance is slow. What should you do to improve performance?
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 the LOOKUPVALUE column and instead create a relationship between the tables.
The correct option is C: remove the LOOKUPVALUE calculated column and instead create a relationship between the tables. LOOKUPVALUE is a row-by-row DAX function that forces the formula engine to scan the target table for every row during processing and can also cause expensive query-time evaluations, whereas a proper relationship lets the VertiPaq engine resolve the lookup through the model's relationship graph, which is far more efficient. Since the customer dimension and the other table share a key, a relationship is the native, performant way to propagate the region attribute. Option A is unrelated to DAX performance and concerns Power Query folding behavior, not calculated columns. Option B (incremental refresh) only reduces refresh time and data volume loaded, not the cost of a LOOKUPVALUE column during report queries. Option D (more RAM) may mask memory pressure but does not address the inefficient row-by-row lookup logic.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable the 'Reduce queries sent to the source' option.
Why it's wrong here
Disabling the 'Reduce queries sent to the source' option in Power Query would cause the query editor to generate individual, unfiltered source queries for every select/transform step, increasing the number of round-trips to the database and lengthening data refresh time. However, this setting only affects query folding and backend load during refresh; it has no bearing on the runtime efficiency of a DAX calculated column that uses LOOKUPVALUE. Therefore, toggling this option would not reduce the expensive row-by-row lookups in your fact table.
- ✗
Enable incremental refresh on the fact table.
Why it's wrong here
Enabling incremental refresh on the fact table partitions the data into date ranges so that only changed rows are reloaded on subsequent refreshes, speeding up the load process. It does not, however, alter the DAX expression of the existing calculated column; every partition still contains a column with LOOKUPVALUE, and VertiPaq will still evaluate that expensive lookup for every row during both initial load and each partition refresh. Thus, incremental refresh addresses refresh volume and latency, but leaves the core performance issue of a row-by-row lookup completely intact.
- ✓
Remove the LOOKUPVALUE column and instead create a relationship between the tables.
Why this is correct
The LOOKUPVALUE function performs an implicit filtering scan over the target table for every row in the fact table, often resulting in an O(n×m) operation where n is the fact row count and m is the lookup table size, causing severe performance degradation in large models. Creating a relationship between the tables lets the VertiPaq engine exploit its in-memory columnstore dictionaries and B-tree-like indexes, enabling hash-based or bitmap-based lookup propagation that is dramatically faster and more memory-efficient. This is the recommended alternative because a relationship is declarative metadata that the query engine can optimize, whereas LOOKUPVALUE is a procedural row-by-row DAX function that prevents such optimization.
- ✗
Increase the amount of RAM on the Power BI service capacity.
Why it's wrong here
Adding RAM to the Power BI service capacity increases the maximum memory available for holding datasets and query results, which can help if the model exceeds the per-dataset limit or if memory pressure causes evictions. But the performance bottleneck here is CPU and query execution efficiency, not memory capacity; the same expensive LOOKUPVALUE operations will still generate identical workloads regardless of available RAM. In fact, a larger memory cache does nothing to change the cardinality of the lookup or the number of comparisons the engine must perform, so the inefficiency persists and the cost of a premium SKU increases without measurable query-time benefit.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 524 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.