Describe considerations for working with non-relational data on Azure →hardMultiple ChoiceObjective-mapped
DP-900 Practice Question: Describe considerations for working with non-relational data on Azure
Your application stores millions of small log entries in Azure Table Storage. Queries by partition key and row key are fast, but you also need to query by timestamp across partitions. The query performance is slow. What is the best way to improve query performance?
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 new table with the timestamp as the partition key and copy data there for time-based queries.
Creating a separate table with timestamp as the partition key allows efficient range queries across all data. Option A (migrate to Azure Cosmos DB) is wrong because Cosmos DB is significantly more expensive and may be overkill for this scenario. Option B (Azure Cognitive Search) is wrong because it is designed for full-text search, not for optimizing time-based queries on Table Storage. Option C is correct as it enables partition-level queries by timestamp. Option D is wrong because Table Storage does not support secondary indexes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Migrate the data to Azure Cosmos DB and use the SQL API.
Why it's wrong here
While Azure Cosmos DB with SQL API provides rich query capabilities, low-latency indexes, and serverless throughput, migrating millions of log entries from Azure Table Storage would require data movement, application rewrites to the new SDK and API, and potentially higher costs due to RU-based consumption. The goal is specifically to improve time-based queries in the existing Azure Table Storage environment; Cosmos DB is a legitimate alternative but is neither the simplest nor the most cost-effective choice when Table Storage already supports key-based range queries. Thus it is wrong for this scenario because it doesn't leverage the existing service and introduces unnecessary architectural change.
- ✗
Use Azure Cognitive Search to index the Table Storage data.
Why it's wrong here
Azure Cognitive Search can index Azure Table Storage data with an indexer, allowing full-text and filter queries, but it is not optimized for pure time-range scans over large log volumes. You would be adding another Azure service with its own pricing tier, index refresh latencies, and configuration overhead, while the underlying Table Storage partitions remain unoptimized for timestamp filtering. This option is more complex and costly than redesigning the table's key structure, so it is not the correct answer for efficient time-based queries.
- ✓
Create a new table with the timestamp as the partition key and copy data there for time-based queries.
Why this is correct
In Azure Table Storage, the only supported primary key is the pair of PartitionKey and RowKey, and queries that filter by PartitionKey are served directly without a full scan. By creating a new table with the timestamp as the PartitionKey and copying the data there, you make time-based queries use an equality comparison on PartitionKey (e.g., a specific date or hour) and optionally a range on RowKey, which is the most performant pattern. This is the correct answer because it applies the service's native indexing model without reintroducing scanning or paying for a separate service.
- ✗
Add a secondary index on the timestamp column.
Why it's wrong here
Azure Table Storage does not support adding secondary or non-clustered indexes on arbitrary entity properties. You cannot create an index on a timestamp column; the only index is the one derived from PartitionKey and RowKey, which you design yourself. If you filter on timestamp without making it part of the key, the service performs a full partition scan across the entire table, which becomes increasingly expensive as log entries accumulate. Therefore this option is invalid because the capability does not exist in Table Storage.
Go deeper
Related to this question
Learn chapter
Data Roles and Core Concepts
Key term
Row
A row is a horizontal record in a database table that contains all the information about a single entity, like one customer or one product.
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
This DP-900 question is part of Courseiva's 820-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-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.