DP-700 Monitor and Optimize an Analytics Solution Practice Question
You are troubleshooting a slow-running SQL query in a Fabric Data Warehouse. The query plan shows a high cost associated with a 'Broadcast Nested Loop Join'. What should you do to optimize this?
⚠ Common exam trap
Candidates often assume the solution is to rewrite the query or change the join type manually. They fail to realize that the optimizer is likely choosing the wrong plan due to stale metadata.
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
✓
Update the table statistics.
A Nested Loop Join is often inefficient for large datasets because it iterates through the outer table for every row in the inner table. If the optimizer chose a broadcast join on a large table, it might be due to outdated statistics. Updating statistics allows the query optimizer to make better decisions about join types, likely switching to a more efficient hash join that is better suited for large-scale data processing.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the number of compute nodes.
Why it's wrong here
While adding compute power can sometimes mask poor query performance, it does not address the underlying issue of an inefficient join algorithm chosen by the optimizer. Improving the query plan through statistics is a more cost-effective and sustainable way to optimize performance.
- ✓
Update the table statistics.
Why this is correct
Outdated statistics mislead the SQL engine into choosing sub-optimal join types. Updating them ensures the optimizer has an accurate view of table sizes and data distribution, leading to the selection of more appropriate join strategies like hash joins instead of nested loops.
- ✗
Disable the query optimizer.
Why it's wrong here
The query optimizer is fundamental to the execution of SQL statements. It cannot be disabled, and even if it could, manually managing execution plans is highly complex, error-prone, and unsustainable, especially given that Fabric handles query optimization automatically based on table metadata.
- ✗
Rewrite the query using a cursor.
Why it's wrong here
Cursors are row-based operations that are notoriously slow in analytical data warehouses. They perform poorly compared to set-based operations and should be avoided at all costs. Using a cursor would likely make the query performance even worse than the current broadcast nested loop join.
About these practice questions
This DP-700 question is part of Courseiva's 152-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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
This DP-700 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 DP-700 exam.