AZ-204 Develop for Azure storage Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Global distribution with multi-master writes

  Why it's wrong here

  Azure Table Storage, the standalone service, does not inherently provide global distribution with multi-master write capabilities. While data can be replicated across regions for disaster recovery or read-only access, active multi-master writes, which allow applications to write to any region and have changes automatically synchronized, are a hallmark feature of Azure Cosmos DB's Table API, not the original Table Storage.

• ✗

  Lower latency and higher throughput

  Why it's wrong here

  Azure Table Storage is designed for massive scale and cost-effectiveness but does not offer the guaranteed low latency or provisioned throughput (Request Units) that Azure Cosmos DB provides. Cosmos DB allows users to explicitly provision throughput and guarantees single-digit millisecond latencies at the 99th percentile, making it the preferred choice for applications with stringent performance requirements that Table Storage cannot meet.

• ✓

  Simpler API and no need for throughput provisioning

  Why this is correct

  Azure Table Storage offers a very straightforward and simple REST API, making it easy to integrate for basic key-value storage needs. A significant advantage is that it operates on a pay-as-you-go model for storage and transactions, completely eliminating the need for users to provision and manage throughput (Request Units), which simplifies operational overhead and cost management for many applications.

• ✓

  Lower cost for simple key-value workloads

  Why this is correct

  For applications requiring basic key-value or semi-structured data storage without strict latency guarantees or advanced features, Azure Table Storage is a significantly more cost-effective solution. Its pricing model is based primarily on storage consumed and transaction volume, making it an economical choice for large datasets with predictable access patterns, especially when compared to the provisioned throughput model of Azure Cosmos DB.

• ✗

  Support for complex queries with indexing

  Why it's wrong here

  Azure Table Storage provides very limited query capabilities, primarily supporting queries based on PartitionKey and RowKey, and simple range filters on other properties. It fundamentally lacks support for secondary indexing on arbitrary properties, complex joins, or aggregation functions. Azure Cosmos DB's Table API, conversely, offers more robust querying and indexing capabilities, including secondary indexes on all properties for richer data retrieval.

Go deeper

Related to this question