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
A company stores IoT sensor data in Azure Table Storage. The data is accessed frequently for the first 30 days, then rarely. You need to minimize storage costs while ensuring data is available for queries within 24 hours of a request. What should you implement?
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
✓
Move data older than 30 days to Azure Blob Storage Cool tier and use an Azure Data Factory pipeline to copy data back to Table Storage when requested.
It addresses the requirement to minimize costs by moving older data to Azure Blob Storage Cool tier, which is cheaper, while still allowing access within 24 hours via an Azure Data Factory pipeline to copy data back to Table Storage on demand. Option A is incorrect because Azure Table Storage does not support automatic lifecycle management policies like Blob Storage does. Option B is incorrect because Azure SQL Database is a relational database and not optimized for IoT sensor data; it would be more expensive and complex. Option C is incorrect because Azure Cosmos DB is generally more expensive than Table Storage and using TTL would delete data permanently, not provide a way to restore it within 24 hours.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure a lifecycle management policy on the Table Storage account to move data to Cool tier after 30 days.
Why it's wrong here
Azure lifecycle management policies are only supported on Blob Storage, not on Azure Table Storage. Table Storage has no access tiers like Hot/Cool/Archive, so a policy cannot move table entities to a Cool tier. Even if applied to the underlying storage account, it would only affect blobs, leaving the IoT sensor data in Table Storage untouched and still incurring standard storage costs.
- ✗
Store all data in Azure SQL Database and use index maintenance to improve query performance.
Why it's wrong here
Migrating all IoT sensor data to Azure SQL Database would replace a low-cost key-value store with a full relational database, substantially raising storage and compute costs. Index maintenance improves query performance, not storage cost, and does nothing to reduce the expense of retaining large volumes of infrequently accessed sensor readings. This approach is over-provisioned and fails the cost-minimization goal.
- ✗
Migrate the data to Azure Cosmos DB and use Time-to-Live (TTL) to expire old data.
Why it's wrong here
Cosmos DB TTL deletes expired records automatically, but that removes historical data and doesn't lower the cost of keeping it; it also forfeits the ability to access old sensor readings. Cosmos DB is a multi-model database with significantly higher per-GB storage costs than Azure Table Storage, so even with TTL the solution is more expensive for largely dormant data. TTL is a data-retention feature, not a cost-tiering mechanism.
- ✓
Move data older than 30 days to Azure Blob Storage Cool tier and use an Azure Data Factory pipeline to copy data back to Table Storage when requested.
Why this is correct
This pattern uses Blob Storage's Cool tier, which is priced for infrequently accessed data, to hold IoT records older than 30 days while keeping them readily retrievable. An Azure Data Factory pipeline can copy the requested entities from the Cool-tier blobs back into Azure Table Storage on demand, restoring them for queries without requiring the data to stay in the high-priced table tier. This optimizes cost while maintaining availability, typically within the Cool tier's 24-hour retrieval-time SLA.
Quick reference
Azure Blob Storage Tier Comparison
| Tier | Storage Cost | Retrieval Cost | Latency | Use Case |
|---|---|---|---|---|
| Hot | Highest | Lowest | Immediate | Active data, frequent reads |
| Cool | Lower | Higher | Immediate | Data accessed < once / month |
| Cold | Lower still | Higher | Immediate | Data accessed < once / quarter |
| Archive | Lowest | Highest + rehydration delay | Hours | Long-term compliance retention |
Go deeper
Related to this question
Learn chapter
Data Roles and Core Concepts
Key term
Relational database
A relational database organizes data into tables with rows and columns, where each table relates to others using unique keys, allowing efficient storage, retrieval, and manipulation of structured information.
Key term
Blob storage
Blob storage is a cloud service for storing large amounts of unstructured data, such as text or binary data, like documents, images, and videos.
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.