DP-900 Practice Question: Describe considerations for working with non-relational data on Azure
A company uses Azure Table Storage to store customer session data. Each session has a PartitionKey (CustomerId) and RowKey (SessionId). They need to retrieve all sessions for a specific customer quickly. Which query design will be most efficient?
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
✓
Query with PartitionKey equal to the specific CustomerId.
Option D is correct because in Azure Table Storage the PartitionKey defines a contiguous, indexed partition, so querying with PartitionKey equal to the specific CustomerId retrieves all of that customer's sessions in a single efficient partition scan without crossing partitions. Since CustomerId is the PartitionKey, this query targets exactly the data needed and is the fastest supported pattern. Option A is wrong because retrieving all entities and filtering client-side forces a full table scan and transfers unnecessary data. Option B is wrong because Azure Table Storage does not support secondary indexes on RowKey. Option C is wrong because querying by a specific RowKey (SessionId) returns only one session, not all sessions for the customer.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Select all entities and filter client-side.
Why it's wrong here
Selecting all entities and filtering client-side forces a full table scan, transferring every customer's session data across the network before discarding irrelevant rows. Table Storage supports server-side filtering on PartitionKey, which targets a single partition directly. Client-side filtering suits small datasets or queries spanning partitions where no key predicate exists.
- ✗
Create a secondary index on RowKey.
Why it's wrong here
Azure Table Storage has no secondary indexes; RowKey is already the sorted key within a partition, so no index can be created on it. Secondary indexing belongs to relational platforms such as Azure SQL Database, not Table Storage.
- ✗
Query with RowKey equal to a specific SessionId.
Why it's wrong here
Point queries on RowKey retrieve a single session, not every session belonging to one customer, so the result set is wrong. RowKey lookups are correct when you know the exact SessionId and need that one entity.
- ✓
Query with PartitionKey equal to the specific CustomerId.
Why this is correct
PartitionKey queries route to a single partition, so filtering on PartitionKey equal to the CustomerId avoids cross-partition fan-out and returns all that customer's sessions from one server. This satisfies the requirement to retrieve a specific customer's sessions quickly, since RowKey alone would force a full table scan.
Go deeper
Related to this question
Learn chapter
SQL Joins: INNER, LEFT, RIGHT, FULL
Key term
Data
Data is raw, unprocessed information, like numbers, words, or measurements, that can be stored, processed, and analyzed by computers.
Key term
Table
A table is a structured collection of data organized into rows and columns, used in databases and spreadsheets to store and manage information efficiently.
About these practice questions
One of 851 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.