mediumMultiple Choice
DP-203 Practice Question: A company uses Azure Synapse Analytics dedicated…
A company uses Azure Synapse Analytics dedicated SQL pool. They notice that queries against a large fact table are running slower over time. The table is hash-distributed on a date key and has a clustered columnstore index. Which action should you take to improve query performance?
⚠ Common exam trap
A common mix-up: candidates assume performance degradation is always due to data skew or distribution choice, overlooking the common real-world issue of columnstore index fragmentation from ongoing DML operations.
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
✓
Rebuild the clustered columnstore index.
Over time, columnstore indexes can become fragmented due to insert, update, and delete operations, leading to compressed row groups that are not optimally sized or have deleted records. Rebuilding the clustered columnstore index reorganizes the data into fully compressed row groups, removes deleted rows, and restores the high compression and segment elimination that columnstore indexes rely on for fast query 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.
- ✗
Add a non-clustered index on frequently filtered columns.
Why it's wrong here
A non-clustered index on a clustered columnstore table adds overhead and rarely helps analytical scans. It is tempting because indexes accelerate filtered lookups in rowstore tables, but columnstore already handles scans efficiently; the degradation stems from stale statistics, which updating statistics resolves.
- ✗
Change the distribution column to a column with higher cardinality.
Why it's wrong here
A higher-cardinality column may improve distribution evenness, but the date key already distributes adequately; the real issue is stale statistics and data movement on joins. It is tempting because cardinality is a hash-distribution consideration, yet rebuilding statistics and choosing a join-frequent distribution column is what improves performance.
- ✗
Change the distribution to round-robin.
Why it's wrong here
Round-robin spreads rows evenly but forces data movement across distributions for joins and aggregations on the date key. It is tempting because it removes skew, yet hash distribution on a frequently joined column plus statistics maintenance addresses the actual cause of degrading performance.
- ✓
Rebuild the clustered columnstore index.
Why this is correct
Repeated DML creates open rowgroups and fragmented delta stores in the clustered columnstore index, degrading scan efficiency. Rebuilding reorganises data into compressed rowgroups, restoring columnstore compression and eliminating the rowgroup fragmentation that slows queries against the large fact table.
Go deeper
Related to this question
About these practice questions
This DP-203 question is part of Courseiva's 509-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-203 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-203 exam.