DP-300 Practice Question: Monitor, configure, and optimize database resources
You are troubleshooting a performance issue on an Azure SQL Database. Query Store shows a significant increase in query duration for a specific query. The execution plan has changed from a hash join to a nested loops join. What is the most likely cause?
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
✓
Stale statistics caused the optimizer to underestimate cardinality
Stale statistics can cause the optimizer to significantly underestimate cardinality. In this scenario, the optimizer mistakenly estimated a low number of rows, leading it to choose a nested loops join (optimal for small datasets) instead of a hash join (better for larger datasets). This is a classic plan regression due to statistics staleness. Option A is incorrect: parameter sniffing typically results in a plan optimized for the initial parameter values, but it does not directly cause a cardinality underestimation that forces a switch from hash to nested loops. Option B is incorrect: dropping an index would likely cause a table scan or a different plan (e.g., clustered index scan), but the specific change from hash join to nested loops is not characteristic of a missing index; it is more indicative of a cardinality misestimate. Option C is incorrect: forced parameterization encourages plan reuse and can prevent plan changes, not cause them.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Parameter sniffing caused the optimizer to choose a plan for atypical parameter values
Why it's wrong here
Could cause a different plan but less likely than stale stats.
- ✗
An index was dropped, forcing a table scan
Why it's wrong here
Would cause scan, not nested loops join.
- ✗
Forced parameterization was enabled
Why it's wrong here
Would not typically change join type.
- ✓
Stale statistics caused the optimizer to underestimate cardinality
Why this is correct
Leads to nested loops instead of hash join due to underestimation.
Go deeper
Related to this question
Learn chapter
Overview of Azure Data Platform Options
Key term
Azure SQL Performance Tuning
Azure SQL Performance Tuning is the process of optimizing the speed and efficiency of queries and database operations in Microsoft Azure SQL Database or SQL Managed Instance to reduce latency and improve throughput.
Key term
Azure SQL Indexes
Structures in Azure SQL Database that speed up data retrieval by providing quick access paths to rows, similar to a book index.
About these practice questions
This DP-300 question is part of Courseiva's 906-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 DP-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 DP-300 exam.