AZ-204 Develop for Azure storage Practice Question
You are developing an application that uses Azure Table Storage to store customer data. You need to query the table to retrieve all entities where the PartitionKey is 'Customers' and the RowKey starts with 'A'. You also want to minimize the amount of data transferred. Which two actions should you perform? (Choose two.)
⚠ Common exam trap
The trap here is assuming that Table Storage supports access tiers like Blob Storage, or that client-side filtering is acceptable for minimizing data transfer.
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
✓
Use a query filter that specifies both PartitionKey eq 'Customers' and RowKey ge 'A' and RowKey lt 'B'.
To minimize data transfer when querying Table Storage, you should filter on both PartitionKey and RowKey using a range query for the prefix, and project only the needed properties. This reduces the number of entities returned and the size of each entity. Client-side filtering and pagination do not reduce total data transfer, and access tiers are not applicable to Table Storage.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use a query filter that specifies both PartitionKey eq 'Customers' and RowKey ge 'A' and RowKey lt 'B'.
Why this is correct
Azure Table Storage supports filtering on PartitionKey and RowKey. To retrieve entities where RowKey starts with 'A', you can use a range query: RowKey ge 'A' and RowKey lt 'B'. This is efficient because it leverages the sorted index on RowKey within a partition. Combining with PartitionKey eq 'Customers' restricts the query to a single partition, which is the fastest way to query Table Storage. This approach minimizes data transfer by filtering at the service side and only returning matching entities.
- ✗
Use a continuation token to paginate through the results.
Why it's wrong here
Continuation tokens are used to paginate through large result sets, but they do not reduce the amount of data transferred for the query itself. They allow the client to retrieve results in chunks, which can be useful for memory management, but the total data transferred remains the same. The scenario focuses on minimizing data transferred, not on pagination. While continuation tokens are important for handling large result sets, they are not a primary means to reduce data transfer. Therefore, this action does not directly address the requirement.
- ✗
Retrieve all entities in the 'Customers' partition and filter on the client side.
Why it's wrong here
Retrieving all entities in the partition and filtering on the client side would transfer a large amount of unnecessary data, especially if the partition contains many entities that do not start with 'A'. This increases network bandwidth, client processing time, and potentially cost. The scenario explicitly requires minimizing data transferred, so server-side filtering is essential. Client-side filtering should be avoided when the service can perform the filtering more efficiently using indexes. Therefore, this action is incorrect.
- ✓
Project only the properties you need by using the Select clause in the query.
Why this is correct
Projecting only the required properties reduces the amount of data transferred over the network and processed by the client. In Azure Table Storage, you can specify a Select clause in your query to return only specific properties. This is especially useful when entities have many properties but you only need a few. By combining a precise filter with projection, you optimize both the number of entities returned and the size of each entity, further minimizing data transfer. This is a recommended practice for performance and cost efficiency.
- ✗
Set the table's access tier to Cool to reduce storage costs.
Why it's wrong here
Azure Table Storage does not have access tiers like Blob Storage. The Cool access tier is a feature of Blob Storage, not Table Storage. Table Storage is a NoSQL key-attribute store and does not support tiering. Attempting to set an access tier on a table would fail. This option is a distractor that confuses Table Storage with Blob Storage. The scenario is about querying Table Storage efficiently, so this action is irrelevant and incorrect.
Go deeper
Related to this question
About these practice questions
Courseiva writes every AZ-204 question from scratch — 883 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
This AZ-204 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 AZ-204 exam.