CCNA Azure Storage Questions — Page 3 of 3

151

MCQhard

You are developing an application that stores sensitive user data in Azure Table Storage. You need to ensure that data is encrypted at rest and that only authorized users can access it. What should you implement?

A.Apply Azure Information Protection labels to the storage account.

B.Enable Azure Storage Service Encryption (SSE) and use Microsoft Entra ID for authentication.

C.Implement client-side encryption using the Azure Storage SDK and manage keys via Azure Key Vault.

D.Use shared access signatures (SAS) with a stored access policy to limit access to the data.

AnswerB

Enabling Azure Storage Service Encryption (SSE) ensures that all data written to Azure Storage is automatically encrypted at rest using Microsoft-managed keys or customer-managed keys via Azure Key Vault. Coupled with Microsoft Entra ID for authentication, this provides robust identity-based access control (RBAC) to the storage account and its contents. This combination offers a secure, scalable, and fully managed solution for protecting sensitive user data.

Why this answer

Azure Storage Service Encryption (SSE) automatically encrypts data at rest for Azure Table Storage using 256-bit AES encryption. By combining SSE with Microsoft Entra ID (formerly Azure AD) for authentication, you ensure both encryption at rest and role-based access control, meeting the requirement for authorized access without managing keys or encryption logic client-side.

Exam trap

The trap here is that candidates often confuse client-side encryption (Option C) as the only way to achieve encryption at rest, overlooking that Azure Storage Service Encryption (SSE) provides automatic, transparent server-side encryption without any code changes or key management burden.

How to eliminate wrong answers

Option A is wrong because Azure Information Protection is a classification and labeling service for documents and emails, not a mechanism for encrypting Azure Storage data at rest or controlling access to storage tables. Option C is wrong because client-side encryption, while valid for encrypting data before storage, introduces key management overhead and is not the simplest or most recommended approach for at-rest encryption in Azure Table Storage; SSE handles this automatically. Option D is wrong because shared access signatures (SAS) provide delegated access to storage resources but do not encrypt data at rest; they only control access at the request level and do not enforce encryption.

Practice this question →

152

MCQhard

An e-commerce platform writes orders to a Cosmos DB container. A downstream inventory service must process every new or updated order exactly once, even if the inventory service restarts mid-batch. The solution must scale horizontally when order volume increases. What is the recommended design?

A.Use the change feed processor library with a dedicated lease container; each worker instance claims partition leases and commits checkpoints after processing each batch

B.Poll the Cosmos DB container every 30 seconds using a _ts timestamp filter to find recently modified documents

C.Subscribe to Azure Event Grid Cosmos DB events and process them in an Azure Function

D.Enable Cosmos DB analytical store and run batch queries from an Azure Synapse Spark pool every hour

AnswerA

The lease container stores the last-processed continuation token per partition. On restart, a worker reads its leases and resumes from the checkpointed position. Adding more worker instances automatically redistributes leases across instances, providing linear horizontal scaling.

Why this answer

The change feed processor library with a dedicated lease container is the recommended design because it provides exactly-once processing semantics through checkpointing, automatic partition lease management for horizontal scaling, and resilience to worker restarts by resuming from the last committed checkpoint. This pattern is purpose-built for Cosmos DB change feed consumption in distributed systems.

Exam trap

The trap here is that candidates may choose Event Grid (Option C) because it is event-driven and seems simpler, but they overlook that Event Grid does not provide exactly-once processing or checkpoint-based restart resilience for Cosmos DB change feed scenarios.

How to eliminate wrong answers

Option B is wrong because polling with _ts timestamps cannot guarantee exactly-once processing due to clock skew, missed updates within the polling interval, and lack of checkpointing for restart resilience. Option C is wrong because Azure Event Grid provides at-least-once delivery for Cosmos DB events, not exactly-once, and does not manage partition leases or checkpoints for horizontal scaling. Option D is wrong because the analytical store and Synapse Spark pool are designed for batch analytics, not real-time event processing, and cannot guarantee exactly-once per-record processing with restart resilience.

Practice this question →

153

MCQeasy

You are developing a solution that stores large media files in Azure Blob Storage. Users access these files frequently for the first 30 days, then rarely afterwards. To optimize costs, you need to automatically move blobs to a cooler tier after 30 days of creation. Which Azure feature should you use?

A.Lifecycle management policies

B.Blob inventory

C.Change feed

D.Immutable storage

AnswerA

Lifecycle management policies are the correct solution because they automate the transition of blobs between different storage tiers (Hot, Cool, Archive) based on rules defined by age, last access time, or other criteria. This automation is crucial for optimizing storage costs for large media files, as it ensures less frequently accessed data is moved to cheaper tiers without manual intervention. By automatically moving older or less-accessed media to Cool or Archive storage, significant cost savings can be achieved.

Why this answer

Azure Blob Storage lifecycle management policies allow you to automatically transition blobs to cooler tiers (e.g., from Hot to Cool) based on age or last modification time. By defining a rule that moves blobs to the Cool tier 30 days after creation, you optimize storage costs for frequently accessed files that become rarely used. This feature is purpose-built for automating tier transitions without manual intervention or custom code.

Exam trap

The trap here is that candidates may confuse lifecycle management with Blob inventory or Change feed, thinking that reporting or event logging alone can automate tier transitions, but only lifecycle policies provide the native, rule-based automation without additional code.

How to eliminate wrong answers

Option B (Blob inventory) is wrong because it provides a report of blobs and their metadata but does not automate tier transitions; it is used for auditing and compliance, not cost optimization. Option C (Change feed) is wrong because it records creation and modification events for blobs but requires custom processing to act on those events; it is not a built-in mechanism for automatic tiering. Option D (Immutable storage) is wrong because it enforces write-once-read-many (WORM) policies to prevent deletion or modification, not to manage storage tiers based on age.

Practice this question →

154

MCQmedium

Refer to the exhibit. You are configuring access to an Azure Storage container using Azure RBAC via a custom role definition. You want to allow a user to list blobs in a container only if the request originates from the IP range 203.0.113.0/24. However, the user reports that they can list blobs from any IP. What is the issue?

A.The Principal is set to an Azure AD tenant instead of a specific user or group

B.The Resource should be the storage account resource ID, not the container resource ID

C.The Action should be 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'

D.The Condition for IP address is incorrectly formatted

AnswerD

Azure RBAC conditions support specifying source IP address ranges to restrict access, and the provided syntax for `ipAddress` is indeed correctly formatted. Conditions leverage attribute-based access control (ABAC) to add additional checks beyond role assignments, such as network location or specific blob index tags. The use of `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/sourceIp` with a CIDR range is a valid and common way to enforce network-based access restrictions within an RBAC assignment.

Why this answer

The current explanation is technically incorrect. Azure RBAC conditions are designed to add restrictions to role assignments and are evaluated for every request by any principal covered by that assignment, regardless of whether the assignment target is a specific user, group, or a broader scope like the tenant. Assigning a role to the tenant does not bypass conditions; the condition should still be enforced for all principals covered by that assignment.

A more plausible reason for the observed behavior (user can list blobs from any IP) would be that the condition for the IP address is incorrectly formatted (Option D), causing it to always evaluate to true or be ignored, or that another role assignment without the condition exists for the user.

Exam trap

The current exam trap note reinforces the incorrect premise that assigning a role to the tenant bypasses conditions. This is not how Azure RBAC conditions function. A more accurate trap might focus on common pitfalls like incorrect condition syntax, or the existence of other, unconditional role assignments that grant the same permissions.

How to eliminate wrong answers

Option B is wrong because the 'Resource' in a custom role definition for a container-level permission should be the container resource ID (e.g., /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{account}/blobServices/default/containers/{container}) to scope the role to that container; using the storage account resource ID would grant permissions across all containers, which is not the intent. Option C is wrong because the action 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read' is correct for listing blobs; the issue is not with the action but with the role assignment scope or principal. Option D is wrong because the condition for IP address is correctly formatted using the '@Resource' attribute with 'Microsoft.Storage/storageAccounts/blobServices/containers/blobs:ipAddress' in the condition expression; the problem is that the condition is not being evaluated because the role assignment is applied to the tenant, not a specific user.

Practice this question →

155

MCQeasy

You need to store small binary blobs (average 50 KB) that are accessed very frequently for a short period, then never accessed again. The total volume is high. Which storage tier is most cost-effective for the initial upload?

A.Hot

B.Cool

C.Cold

D.Archive

AnswerA

Correct. Hot tier optimizes for frequent access with lower per-operation costs.

Why this answer

The Hot tier is the most cost-effective for the initial upload because it is optimized for frequent access and low latency, and for small blobs (average 50 KB) that are accessed very frequently for a short period, the per-GB storage cost is higher than Cool or Cold, but the access cost (per-operation charges) is significantly lower. Since the blobs are never accessed again after the short period, the high access frequency during that period makes Hot the cheapest option when considering total cost (storage + access operations), as Cool/Cold tiers would incur much higher per-read operation costs that outweigh their lower storage costs.

Exam trap

The trap here is that candidates assume lower storage cost per GB (Cool/Cold) always means lower total cost, ignoring that frequent access operations and minimum duration charges can make Hot tier cheaper for short-lived, high-access workloads.

How to eliminate wrong answers

Option B (Cool) is wrong because Cool tier has a higher per-read operation cost and a minimum storage duration charge (30 days), making it more expensive for blobs that are accessed very frequently for a short period and then never accessed again. Option C (Cold) is wrong because Cold tier has even higher per-read operation costs and a 90-day minimum storage duration, which would be wasteful for blobs that are only needed briefly. Option D (Archive) is wrong because Archive tier has the highest latency (hours to rehydrate) and is designed for long-term backup, not for blobs that need immediate, frequent access; it also incurs a 180-day minimum storage duration and high retrieval costs.

Practice this question →

156

MCQmedium

A serverless app must react whenever audit documents are inserted or updated in Cosmos DB. Which trigger should the Azure Function use? The design must avoid adding custom operational scripts.

A.Queue trigger

B.Timer trigger

C.HTTP trigger

D.Cosmos DB trigger

AnswerD

The Cosmos DB trigger reads the change feed and invokes the function for inserts and updates.

Why this answer

The Azure Cosmos DB trigger is the correct choice because it natively listens to the Cosmos DB change feed, which captures inserts and updates to documents. This allows the Azure Function to react automatically without any custom scripts or polling logic, aligning with the serverless and operational simplicity requirements.

Exam trap

The trap here is that candidates may confuse the Cosmos DB trigger with other triggers that require custom polling or external invocation, overlooking that the change feed provides a built-in, event-driven mechanism for reacting to data changes.

How to eliminate wrong answers

Option A is wrong because a Queue trigger processes messages from Azure Queue Storage, not changes in Cosmos DB, and would require custom code to write audit events to the queue. Option B is wrong because a Timer trigger runs on a fixed schedule, not in response to data changes, and would need custom polling logic to detect inserts/updates. Option C is wrong because an HTTP trigger requires an explicit HTTP request to invoke the function, which is not triggered automatically by Cosmos DB document changes.

Practice this question →

157

Multi-Selecteasy

Which Azure Blob Storage access tier is optimized for infrequently accessed data with a minimum storage duration of 30 days?

Select 1 answer

A.Transactional

B.Archive

C.Premium

D.Cool

E.Hot

AnswersD

Cool is designed for infrequently accessed data and has a minimum storage duration of 30 days, making it the correct answer.

Why this answer

The Cool tier is optimized for infrequently accessed data and has a minimum storage duration of 30 days, matching both requirements. The Archive tier is for infrequently accessed data but requires a minimum storage duration of 180 days, so it does not meet the 30-day requirement. The Hot tier is for frequently accessed data.

The Premium tier is for high-performance, frequently accessed data. 'Transactional' is not a standard Azure Blob Storage access tier. Therefore, among the given options, only Cool satisfies all criteria.

Exam trap

Candidates often assume that Archive qualifies because it is for rarely accessed data, but they overlook the 180-day minimum storage duration required by Archive.

Practice this question →

158

MCQhard

You are designing a solution that writes millions of small log records (each 200 bytes) to Azure Blob Storage. The logs are written every second, always appended to a single file. The file must be read periodically by a batch process that reads the entire file. You need to maximize write throughput and minimize storage costs. Which blob type and access strategy should you choose?

A.Use Block blobs and append the data to a single blob

B.Use Append blobs and write each log entry as an append block

C.Use Page blobs and write each log entry to a page

D.Use Block blobs and create a new blob for each log entry

AnswerB

Append blobs are the optimal choice for writing millions of small log records because they are specifically engineered for sequential append operations. Each log entry can be written as an individual append block, efficiently adding data to the end of the blob without modifying existing content. This design ensures high throughput, low latency, and cost-effectiveness for continuous data streams like application logs, making them ideal for this workload.

Why this answer

Append blobs are optimized for append operations, making them ideal for writing millions of small log records sequentially to a single file. Data is written in append blocks. For millions of small log entries, these entries would typically be buffered and written together as larger append blocks (up to 4 MB each) to optimize performance and and stay within the append blob's 50,000 block limit.

This provides high throughput for append-heavy workloads and minimizes storage costs by storing data in a single blob.

Exam trap

The trap here is that candidates often choose Block blobs (Option A) thinking they can append data by adding new blocks, but they overlook the inefficiency of the block list management and the lack of native append support, which makes Append blobs the correct choice for sequential append workloads.

How to eliminate wrong answers

Option A is wrong because Block blobs are not designed for frequent append operations; appending to a block blob requires reading the existing blocks, adding a new block, and committing the block list, which is inefficient and does not maximize write throughput. Option C is wrong because Page blobs are optimized for random read/write operations on fixed-size pages (512 bytes) and are not suitable for small, sequential appends; they also incur higher costs due to minimum page size and premium storage tiers. Option D is wrong because creating a new blob for each log entry introduces significant overhead in blob creation, metadata management, and listing operations, which reduces write throughput and increases storage costs due to per-blob transaction charges.

Practice this question →

159

MCQhard

A Cosmos DB workload for telemetry events has predictable traffic during business hours and almost no traffic overnight. The team wants to reduce cost while keeping performance during peak hours. What should be configured?

A.Analytical store only

B.Autoscale throughput with an appropriate maximum RU/s

C.Manual throughput set permanently to peak RU/s

D.Disable indexing entirely

AnswerB

Autoscale throughput dynamically adjusts the provisioned Request Units per second (RU/s) for a Cosmos DB container or database within a user-defined minimum and maximum range. This feature is ideal for telemetry workloads with predictable peaks and troughs, as it automatically scales up during high demand to ensure performance and scales down during idle periods to optimize costs. It effectively eliminates the need for manual throughput adjustments, ensuring efficient resource utilization.

Why this answer

Autoscale throughput (option B) is correct because it dynamically scales the provisioned RU/s between 10% of the configured maximum and the maximum itself based on actual demand. For a workload with predictable peak traffic during business hours and near-zero traffic overnight, autoscale eliminates the cost of provisioning for peak capacity 24/7 while ensuring performance is not throttled during high-demand periods. This directly addresses the cost-reduction goal without sacrificing peak-hour performance.

Exam trap

The trap here is that candidates often confuse 'autoscale' with 'manual throughput' and assume manual throughput set to peak is the safest choice, but they overlook the cost of idle capacity; Microsoft often tests the understanding that autoscale is the only option that dynamically matches cost to actual usage while preserving peak performance.

How to eliminate wrong answers

Option A is wrong because Analytical Store is a separate columnar store for analytical queries (e.g., Synapse Link) and does not affect the transactional throughput cost or scaling behavior; it adds cost for storage and processing, not reduces it. Option C is wrong because setting manual throughput permanently to peak RU/s would incur charges for that capacity 24/7, even during overnight low-traffic periods, defeating the cost-reduction goal. Option D is wrong because disabling indexing entirely would severely impact query performance and is not a valid cost-saving mechanism for throughput; it affects storage costs and write latency but does not reduce provisioned RU/s charges, and it breaks many query patterns.

Practice this question →

160

MCQhard

You are reviewing a lifecycle management rule configured on an Azure Storage account. The rule is defined as shown in the exhibit. You notice that blobs tagged with project=temp are not being moved to the Archive tier as expected. What is the most likely cause?

A.The rule does not include a filter for blob index tags.

B.The condition uses an incorrect operator for age.

C.The Archive tier is not supported for this storage account type.

D.Block blobs cannot be moved to the Archive tier.

AnswerB

Azure Blob Storage lifecycle management rules require specific operators for defining age-based conditions. For instance, to specify a condition based on the age of a blob since its last modification, the correct operator is `daysAfterModificationGreaterThan` (or `daysAfterCreationGreaterThan`, `daysAfterLastAccessTimeGreaterThan`). Using a generic operator like `greaterThan` directly on an age property is syntactically invalid within the lifecycle rule JSON definition, leading to a rule that fails to execute as intended.

Why this answer

The lifecycle management rule uses the condition 'age > 30' which is an incorrect operator. Azure lifecycle management rules require the operator 'daysElapsedSinceModificationGreaterThan' or similar, not a generic 'age >' syntax. This invalid operator causes the rule to fail to evaluate correctly, so blobs tagged with project=temp are not moved to Archive tier.

Exam trap

The trap here is that candidates may overlook the exact operator syntax required in lifecycle management rules and assume any comparison operator like '>' is valid, when Azure requires specific predefined operators like 'daysElapsedSinceModificationGreaterThan'.

How to eliminate wrong answers

Option A is wrong because the rule does include a filter for blob index tags (project=temp), so the absence of a filter is not the issue. Option C is wrong because the Archive tier is supported on general-purpose v2 and BlobStorage accounts, and the question does not indicate an unsupported account type. Option D is wrong because block blobs can be moved to the Archive tier; only append blobs and page blobs are excluded from tiering to Archive.

Practice this question →

161

MCQmedium

You need to enable client-side encryption for data stored in Azure Blob Storage. The encryption keys must be managed by your organization using Azure Key Vault. What should you use?

A.Azure Disk Encryption

B.Azure Information Protection

C.Azure Storage service-side encryption with customer-managed keys

D.Azure Storage client-side encryption library with Key Vault

AnswerD

The Azure Storage client-side encryption library, when integrated with Azure Key Vault, provides the exact functionality required: encrypting data on the client application *before* it is uploaded to Azure Storage. This ensures that the data is encrypted in transit and remains encrypted at rest, with Azure Storage only ever receiving the ciphertext. Azure Key Vault securely stores and manages the encryption keys, allowing the client application to retrieve and use them for encryption and decryption, thereby giving customers full control over their data's encryption lifecycle and ensuring maximum confidentiality.

Why this answer

Client-side encryption requires the application to encrypt data before uploading it to Azure Blob Storage, and the Azure Storage client-side encryption library integrates with Azure Key Vault to allow your organization to manage the encryption keys. This approach ensures that the storage service never has access to the plaintext data or the keys, meeting the requirement for client-side encryption with customer-managed keys.

Exam trap

The trap here is confusing client-side encryption (where the client encrypts before sending) with service-side encryption (where the service encrypts after receiving), leading candidates to incorrectly choose service-side encryption with customer-managed keys (Option C) even though it does not meet the 'client-side' requirement.

How to eliminate wrong answers

Option A is wrong because Azure Disk Encryption uses BitLocker (Windows) or DM-Crypt (Linux) to encrypt virtual machine disks at the OS and data disk level, not client-side encryption of blob data. Option B is wrong because Azure Information Protection is a classification and labeling solution for documents and emails, not a mechanism for encrypting blob storage data at the client side. Option C is wrong because Azure Storage service-side encryption with customer-managed keys encrypts data at the storage service layer after it is received, not at the client side before transmission, so the service still handles the plaintext data.

Practice this question →

162

MCQmedium

You need to implement a shared access signature (SAS) for an Azure blob container that allows a client to list blobs and read blob contents. The SAS must be valid for one hour and should not allow write or delete operations. Which permissions should you include in the SAS token?

A.r, l, and c

B.r and l

C.r, l, and d

D.r, l, and w

AnswerB

The 'r' (Read) and 'l' (List) permissions are precisely what is required for scenarios where users need to view the contents of storage resources and enumerate items within a container or directory. 'r' enables downloading blob content and accessing metadata, while 'l' allows for browsing and discovering available resources. Together, these permissions provide comprehensive read-only access without granting any modification or deletion capabilities, adhering to the principle of least privilege.

Why this answer

The SAS token needs 'r' (read) to allow reading blob contents and 'l' (list) to allow listing blobs in the container. These two permissions together satisfy the requirement for read-only access without write or delete capabilities.

Exam trap

The trap here is that candidates may confuse 'l' (list) with 'r' (read) or include 'c' (create) thinking it's needed for listing, but 'l' alone enables listing blobs in a container without requiring create permissions.

How to eliminate wrong answers

Option A is wrong because it includes 'c' (create), which allows creating new blobs, violating the requirement to not allow write operations. Option C is wrong because it includes 'd' (delete), which allows deleting blobs, violating the requirement to not allow delete operations. Option D is wrong because it includes 'w' (write), which allows writing blob content, violating the requirement to not allow write operations.

Practice this question →

163

MCQeasy

Your application runs on Azure App Service and needs to access Azure Queue Storage. You want to avoid storing connection strings in configuration files. Which approach should you use?

A.Hardcode the connection string in the application code.

B.Use a system-assigned managed identity with RBAC role 'Storage Queue Data Contributor' on the queue.

C.Use an environment variable in the App Service configuration.

D.Store the connection string in Azure Key Vault and retrieve it at runtime using Key Vault references.

AnswerB

A system-assigned managed identity provides an automatically managed identity for the Azure App Service within Azure Active Directory. This identity can then be granted specific Azure Role-Based Access Control (RBAC) roles, such as 'Storage Queue Data Contributor', directly on the target Azure Storage Queue. This approach eliminates the need for developers to manage or store any connection strings or secrets in the application code or configuration, as Azure AD handles the authentication and authorization securely.

Why this answer

Using a system-assigned managed identity for an Azure App Service allows it to authenticate to Azure Queue Storage without any stored secrets. By assigning the 'Storage Queue Data Contributor' RBAC role, the app gains the necessary permissions to read, write, and delete queue messages, and the identity is automatically managed by Azure AD, eliminating the need for connection strings.

Exam trap

The trap here is that candidates often choose Key Vault references (Option D) thinking it's the most secure, but fail to recognize that managed identity eliminates the need for any secret at all, which is the true 'zero-trust' approach tested in AZ-204.

How to eliminate wrong answers

Option A is wrong because hardcoding a connection string in application code violates security best practices, exposes secrets in source control, and makes rotation difficult. Option C is wrong because while environment variables in App Service configuration avoid hardcoding, they still store the connection string as plaintext in the Azure portal and are not a zero-secret solution. Option D is wrong because although Key Vault references improve security by storing the connection string in a vault, they still require a connection string to be stored and retrieved, whereas managed identity eliminates the need for any secret entirely.

Practice this question →

164

MCQmedium

You need to store temperature readings from IoT devices in Azure Table Storage. Each reading includes a device ID (string), timestamp (datetime), temperature value, and location. You must optimize for the query: "Retrieve all temperature readings for a specific device ID within a given one-hour time range." Which PartitionKey and RowKey combination should you use?

A.PartitionKey = DeviceId, RowKey = Timestamp

B.PartitionKey = Location, RowKey = DeviceId

C.PartitionKey = Temperature, RowKey = Timestamp

D.PartitionKey = DeviceId + Timestamp, RowKey = empty

AnswerA

This design is optimal for IoT data. The PartitionKey, `DeviceId`, groups all temperature readings from a specific device into a single partition, enabling highly efficient point queries or range queries for that device without scanning unrelated data. Within this partition, the `RowKey`, `Timestamp`, ensures that readings are stored in chronological order, which is crucial for performing fast and cost-effective time-based range queries (e.g., retrieving all readings for a device within a specific hour or day).

Why this answer

Azure Table Storage queries are most efficient when the PartitionKey and RowKey are chosen to match the query pattern. By using DeviceId as the PartitionKey, all readings for a specific device are stored in the same partition, enabling fast partition-level scans. Using Timestamp as the RowKey allows efficient range queries within a one-hour window using RowKey comparisons, which is the optimal design for time-range queries on a single device.

Exam trap

The trap here is that candidates often choose Option D, thinking that a composite PartitionKey will improve query performance, but in Azure Table Storage, a composite key in PartitionKey actually creates unique partitions per row, which prevents efficient range queries and forces point lookups, making it worse for time-range queries.

How to eliminate wrong answers

Option B is wrong because Location as PartitionKey scatters data across partitions, requiring a full table scan to filter by DeviceId and timestamp, which is inefficient. Option C is wrong because Temperature as PartitionKey is meaningless for the query; it does not group data by device, and timestamp as RowKey still requires scanning multiple partitions for a single device. Option D is wrong because concatenating DeviceId and Timestamp into PartitionKey creates a unique partition per reading, eliminating the benefit of partition-level grouping and forcing point queries instead of efficient range scans; an empty RowKey also violates the requirement that RowKey must be unique within a partition.

Practice this question →