- A
Create a nonclustered index on (CustomerID, OrderDate DESC) INCLUDE (TotalAmount)
This composite index supports the exact filter (CustomerID and OrderDate), the sort order (OrderDate DESC is included in the key), and the included TotalAmount column eliminates key lookups, making it a covering index for the query.
- B
Create a nonclustered index on (OrderDate) INCLUDE (CustomerID, TotalAmount)
Why wrong: This index puts OrderDate first, but the query filters on CustomerID first; filtering on CustomerID would require scanning many date ranges for each CustomerID, which is less efficient than having CustomerID as the leading key.
- C
Create a nonclustered index on (OrderDate DESC) INCLUDE (CustomerID, TotalAmount)
Why wrong: Similar to the previous option, the leading key is OrderDate, not CustomerID, making it suboptimal for queries that filter on CustomerID first.
- D
Create a nonclustered index on (CustomerID) INCLUDE (OrderDate, TotalAmount)
Why wrong: This index has CustomerID as the leading key, but OrderDate is only included, not a key column. The query also sorts by OrderDate, which the index cannot provide efficiently because OrderDate is not part of the key. The sort would require a separate sort operation.
Quick Answer
The answer is to create a nonclustered index on (CustomerID, OrderDate DESC) INCLUDE (TotalAmount). This composite index for equality and range queries is optimal because it directly supports the equality filter on CustomerID and the descending sort on OrderDate, while the INCLUDE clause makes it a covering index that stores TotalAmount without adding it to the key structure. On the DP-900 exam, this scenario tests your understanding of how to design indexes that satisfy both filtering and ordering requirements without costly key lookups to the clustered index. A common trap is choosing a clustered index on CustomerID and OrderDate, which would disrupt the existing OrderID clustered key; another is forgetting the INCLUDE clause, forcing extra I/O. Remember the mnemonic "E-RIC" for Equality, Range, Include, and Cover—when you see an equality filter followed by a range or sort, build a composite key in that order and include any remaining columns needed for the query.
DP-900 Practice Question: Identify considerations for relational data on Azure
This DP-900 practice question tests your understanding of identify considerations for relational data on azure. Match the stated requirement to the specific cloud service, access model, or configuration option — many options are valid in isolation but not for this scenario. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
An e-commerce company uses Azure SQL Database for order processing. The Orders table has columns: OrderID (unique, clustered index), CustomerID, OrderDate, Status, TotalAmount. A common query filters on CustomerID and OrderDate, and sorts by OrderDate descending. The query also returns TotalAmount. Which indexing strategy will produce the best query performance?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue:
"best"Why it matters: Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.
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
Create a nonclustered index on (CustomerID, OrderDate DESC) INCLUDE (TotalAmount)
Option A is correct because it creates a covering index that supports both the equality filter on CustomerID and the range/sort on OrderDate DESC. By including TotalAmount as an included column, the query can be satisfied entirely from the nonclustered index without key lookups to the clustered index, minimizing I/O and improving performance.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Create a nonclustered index on (CustomerID, OrderDate DESC) INCLUDE (TotalAmount)
Why this is correct
This composite index supports the exact filter (CustomerID and OrderDate), the sort order (OrderDate DESC is included in the key), and the included TotalAmount column eliminates key lookups, making it a covering index for the query.
Clue confirmation
The clue word "best" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
- ✗
Create a nonclustered index on (OrderDate) INCLUDE (CustomerID, TotalAmount)
Why it's wrong here
This index puts OrderDate first, but the query filters on CustomerID first; filtering on CustomerID would require scanning many date ranges for each CustomerID, which is less efficient than having CustomerID as the leading key.
- ✗
Create a nonclustered index on (OrderDate DESC) INCLUDE (CustomerID, TotalAmount)
Why it's wrong here
Similar to the previous option, the leading key is OrderDate, not CustomerID, making it suboptimal for queries that filter on CustomerID first.
- ✗
Create a nonclustered index on (CustomerID) INCLUDE (OrderDate, TotalAmount)
Why it's wrong here
This index has CustomerID as the leading key, but OrderDate is only included, not a key column. The query also sorts by OrderDate, which the index cannot provide efficiently because OrderDate is not part of the key. The sort would require a separate sort operation.
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is that candidates often focus on including all columns in the INCLUDE clause but fail to order the key columns correctly to support both the equality filter and the sort order, leading them to pick options that start with the sort column instead of the equality column.
Trap categories for this question
Similar concept trap
Similar to the previous option, the leading key is OrderDate, not CustomerID, making it suboptimal for queries that filter on CustomerID first.
Detailed technical explanation
How to think about this question
In SQL Server/Azure SQL Database, a nonclustered index with key columns (CustomerID, OrderDate DESC) allows the query optimizer to perform an index seek on CustomerID and then an ordered scan of OrderDate in descending order, avoiding a sort. The INCLUDE (TotalAmount) makes the index covering, meaning all required columns are in the leaf level, so no clustered index lookups are needed. This is especially beneficial for large tables where key lookups would cause significant random I/O.
KKey Concepts to Remember
- Read the scenario before looking for a memorised answer.
- Find the constraint that changes the correct option.
- Eliminate answers that are true in general but not in this case.
TExam Day Tips
- Watch for words such as best, first, most likely and least administrative effort.
- Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A cloud solutions architect for a retail company is evaluating services for a new workload. The correct answer here reflects best practice for the specific scenario described — not a general cloud recommendation. Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option. Cloud exam questions reward reading the constraint carefully: the same technology can be right or wrong depending on the use case.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
- →
Identify considerations for relational data on Azure — study guide chapter
Learn the concepts, then practise the questions
- →
Identify considerations for relational data on Azure practice questions
Targeted practice on this topic area only
- →
All DP-900 questions
982 questions across all exam domains
- →
Microsoft Azure Data Fundamentals DP-900 study guide
Full concept coverage aligned to exam objectives
- →
DP-900 practice test guide
How to use practice tests most effectively before exam day
Related practice questions
Related DP-900 practice-question pages
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Describe core data concepts practice questions
Practise DP-900 questions linked to Describe core data concepts.
Describe an analytics workload on Azure practice questions
Practise DP-900 questions linked to Describe an analytics workload on Azure.
Identify considerations for relational data on Azure practice questions
Practise DP-900 questions linked to Identify considerations for relational data on Azure.
Describe considerations for working with non-relational data on Azure practice questions
Practise DP-900 questions linked to Describe considerations for working with non-relational data on Azure.
DP-900 fundamentals practice questions
Practise DP-900 questions linked to DP-900 fundamentals.
DP-900 scenario practice questions
Practise DP-900 questions linked to DP-900 scenario.
DP-900 troubleshooting practice questions
Practise DP-900 questions linked to DP-900 troubleshooting.
Practice this exam
Start a free DP-900 practice session
Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.
FAQ
Questions learners often ask
What does this DP-900 question test?
Identify considerations for relational data on Azure — This question tests Identify considerations for relational data on Azure — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: Create a nonclustered index on (CustomerID, OrderDate DESC) INCLUDE (TotalAmount) — Option A is correct because it creates a covering index that supports both the equality filter on CustomerID and the range/sort on OrderDate DESC. By including TotalAmount as an included column, the query can be satisfied entirely from the nonclustered index without key lookups to the clustered index, minimizing I/O and improving performance.
What should I do if I get this DP-900 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Are there clue words in this question I should notice?
Yes — watch for: "best". Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
4 more ways this is tested on DP-900
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company uses Azure SQL Database for an e-commerce platform. The Orders table has columns: OrderID (primary key, clustered), CustomerID, OrderDate, TotalAmount. Queries frequently filter on CustomerID and a range of OrderDate, and then sort the results by OrderDate in descending order. The queries also return the TotalAmount column. Which indexing strategy will most improve query performance for these operations?
medium- ✓ A.Create a nonclustered index on (CustomerID, OrderDate DESC) with included column TotalAmount
- B.Create a nonclustered index on (OrderDate DESC, CustomerID) with included column TotalAmount
- C.Change the clustered index to be on (CustomerID, OrderDate DESC)
- D.Create a nonclustered index on (OrderDate DESC) without including TotalAmount
Why A: Option A is correct because it creates a covering index that matches the query's filter predicates (CustomerID equality, OrderDate range) and sort order (OrderDate DESC). By including TotalAmount as an included column, the index fully satisfies the query without needing to access the clustered index (key lookup), minimizing I/O and improving performance.
Variation 2. A company uses Azure SQL Database for an e-commerce platform. The 'Orders' table has millions of rows with columns OrderID (primary key), CustomerID, OrderDate, and TotalAmount. Queries often filter by CustomerID (equality) and OrderDate (range). Currently, these queries are slow. Which index should be created to improve performance?
medium- A.A nonclustered index on OrderID
- ✓ B.A nonclustered index on (CustomerID, OrderDate)
- C.A nonclustered index on OrderDate
- D.A clustered index on CustomerID
Why B: The query pattern filters by CustomerID (equality) and OrderDate (range). A composite nonclustered index on (CustomerID, OrderDate) allows SQL Database to seek directly to the matching CustomerID rows and then efficiently scan the ordered OrderDate range within that partition, avoiding a full table scan or key lookup. This index order leverages the index's B-tree structure for both equality and range predicates.
Variation 3. A company uses Azure SQL Database for an e-commerce system. The Orders table has millions of rows with a clustered index on OrderID (the primary key). Queries that filter on OrderDate and CustomerID to find recent orders for a specific customer are very slow. Which indexing strategy will most improve the performance of these queries?
medium- A.Create a nonclustered index on OrderID only
- B.Create separate nonclustered indexes on OrderDate and CustomerID
- ✓ C.Create a nonclustered composite index on (OrderDate, CustomerID)
- D.Create a clustered index on CustomerID instead of OrderID
Why C: The query filters on both OrderDate and CustomerID, so a composite nonclustered index on (OrderDate, CustomerID) allows SQL Server to perform a single index seek to locate the matching rows without touching the clustered index until the final key lookup. This dramatically reduces I/O compared to scanning the entire clustered index or using multiple separate indexes.
Variation 4. A company has an Azure SQL Database with an 'Orders' table containing millions of rows. The table has a clustered index on OrderID (primary key). Queries frequently filter by CustomerID (equality) and OrderDate (range). These queries are slow and cause high logical reads. Which index strategy will most improve performance for these specific queries?
hard- ✓ A.Create a non-clustered index on (CustomerID, OrderDate).
- B.Rebuild the clustered index on (OrderDate, CustomerID).
- C.Create a non-clustered index on OrderDate.
- D.Create a filtered index on OrderDate for recent dates.
Why A: A non-clustered index on (CustomerID, OrderDate) is a covering index for queries filtering by CustomerID (equality) and OrderDate (range). It allows SQL Server to perform an index seek on CustomerID, then a range scan on OrderDate, retrieving all needed columns without touching the clustered index (if the query is covered). This dramatically reduces logical reads compared to a full clustered index scan or a key lookup.
Last reviewed: Jun 11, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.