DP-900 Practice Question: Identify considerations for relational data on Azure
A company uses Azure SQL Database for its order management system. The database has a table named Orders with columns OrderID (INT, PRIMARY KEY), CustomerID (INT), OrderDate (DATE), TotalAmount (DECIMAL). Queries that filter by OrderDate are slow. The database administrator observes that the nonclustered index on OrderDate has high fragmentation and many page splits. Which action will most likely improve query performance for these date-based queries?
⚠ Common exam trap
A common mix-up: candidates think changing the clustered index to OrderDate (Option C) is the best solution, but they overlook that this would disrupt the primary key and cause even more fragmentation for a table with frequent inserts, whereas rebuilding with a lower fill factor directly addresses page splits without altering the table's physical design.
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 nonclustered index on OrderDate with a FILLFACTOR of 80.
Rebuilding the nonclustered index on OrderDate with a FILLFACTOR of 80 reduces page splits by leaving free space in each leaf-level page. This accommodates future insertions and updates that modify the OrderDate values, lowering fragmentation and improving query performance for date-based filters.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Rebuild the nonclustered index on OrderDate with a FILLFACTOR of 80.
Why this is correct
Rebuilding the nonclustered index on OrderDate with a FILLFACTOR of 80 is correct because it compacts the index while reserving 20 percent free space in each leaf-level page. This free space accommodates the page splits that frequently occur when new orders are inserted with OrderDate values that fall between existing rows. By reducing page splits, you also reduce logical and extent fragmentation, which lowers I/O for range scans and keeps index performance predictable as new orders accumulate.
- ✗
Change the data type of TotalAmount from DECIMAL to FLOAT.
Why it's wrong here
Changing TotalAmount from DECIMAL to FLOAT does nothing to address the fragmentation or page splits that are causing the performance degradation, so it leaves the actual problem untouched. Worse, FLOAT is an approximate numeric type, so large or fractional monetary values can be rounded or stored with tiny precision errors compared with DECIMAL. Introducing approximate types for order totals also breaks the principle of exact numeric storage for financial data, creating a correctness risk without any indexing benefit.
- ✗
Remove the clustered index on OrderID and create a clustered index on OrderDate.
Why it's wrong here
Removing the clustered index on OrderID and replacing it with a clustered index on OrderDate would force Azure SQL Database to rewrite the entire table to reorder rows by date, a heavy and often long-running operation that also requires all nonclustered indexes to be rebuilt. Because many new orders tend to share the same date, inserts would be concentrated on the last page of the clustered index, creating a hot spot with high latch contention and page-split pressure. In addition, OrderID is the natural primary key, and a unique clustered index on it is efficient for key lookups; an OrderDate clustered index would still need an additional uniqueifier for duplicate dates, increasing storage overhead.
- ✗
Add a columnstore index on the OrderDate column.
Why it's wrong here
Adding a columnstore index on OrderDate is ineffective because columnstore indexes are designed for analytical scans of large, mostly read-only tables, not for servicing point lookups or limited range predicates against a transactional order-management table. A columnstore index must be incrementally maintained as INSERT, UPDATE, and DELETE operations occur, adding overhead to the order-management workload and potentially causing background rowgroup compression and reorg processes. The existing nonclustered index on OrderDate is already the right structure for the ordering-related queries, so a columnstore would consume storage and CPU without meaningfully reducing page splits.
Go deeper
Related to this question
Learn chapter
Azure SQL Services
Key term
Azure SQL Database
Azure SQL Database is a fully managed relational database-as-a-service (DBaaS) in Microsoft Azure, based on the SQL Server engine, that handles scaling, backups, patching, and high availability automatically.
Key term
Index
An index is a data structure that speeds up data retrieval operations on a database table or file, much like a book index helps you find topics quickly.
About these practice questions
One of 820 original DP-900 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 DP-900 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-900 exam.