Azure Cosmos DB & its APIs

What kind of Azure service is Azure Cosmos DB?

• AA relational database requiring manual server patching
• BAn infrastructure-as-a-service virtual machine cluster
• CA fully managed, platform-as-a-service NoSQL database✓
• DAn on-premises data warehouse appliance

Answer: Azure Cosmos DB is a fully managed NoSQL database service on Azure, delivered as a platform-as-a-service offering where Microsoft handles server provisioning, patching, updates, and backups. It isn't an infrastructure-as-a-service virtual machine cluster, a relational database needing manual patching, or an on-premises appliance.

In Azure Cosmos DB's resource hierarchy, what sits directly beneath a database and is where you configure the partition key, throughput, and indexing policy?

• AA container✓
• BA region
• CAn account
• DAn item

Answer: A container is the primary unit of storage and scaling in Cosmos DB, and it's where you configure the partition key, throughput, indexing policy, and an optional time-to-live. Items are the individual entities stored inside a container, the account is the top-level resource above databases, and a region is a geographic location Cosmos DB can replicate to, not a level in the resource hierarchy.

In Azure Cosmos DB, how much data can a single logical partition hold?

• AUp to 20 GB✓
• BUp to 4 TiB
• CUp to 190.7 TiB
• DUp to 256 TiB

Answer: Each logical partition in Azure Cosmos DB can hold up to 20 GB of data, which is why choosing a partition key with many distinct values and an even data spread matters as a database grows. The other figures describe limits for a single file in Azure Files, a block blob, and total data in an Azure Files storage account, not a Cosmos DB logical partition.

Which Azure Cosmos DB consistency level guarantees that every read reflects the most recent write?

• AConsistent prefix
• BStrong✓
• CEventual
• DSession

Answer: Strong consistency guarantees that every read reflects the most recent write, making it the strictest of Cosmos DB's five consistency levels. Session consistency only guarantees this within a single client session, eventual consistency offers the weakest guarantee as replicas converge over time, and consistent prefix only ensures reads never see out-of-order writes.

Which Azure Cosmos DB consistency level does the unit describe as the most widely used and the recommended starting point for most transactional applications?

• AEventual
• BSession✓
• CStrong
• DBounded staleness

Answer: Session consistency guarantees consistency within a single client session and is described as the most widely used level and the recommended starting point for most transactional applications. Strong consistency is stricter but comes at a greater performance cost, bounded staleness allows reads to lag by a configurable interval, and eventual consistency offers the weakest guarantee.

What does one Request Unit per second (RU/s) in Azure Cosmos DB roughly represent?

• AThe cost of reading a 1-KB item✓
• BThe cost of provisioning one container
• CThe cost of running one Gremlin traversal
• DThe cost of writing a 1-MB document

Answer: One RU/s roughly equals the cost of reading a 1-KB item, giving Cosmos DB a single metric for reasoning about both performance and cost across reads, writes, queries, and deletes. It doesn't specifically represent the cost of a 1-MB write, a Gremlin traversal, or provisioning a container.

A team chooses the Serverless throughput mode for their Azure Cosmos DB account because their workload has low, unpredictable traffic. What limitation does this choice bring?

• AThe account cannot use the NoSQL API
• BThe account cannot use automatic indexing
• CThe account is limited to a single container per database
• DThe account is limited to a single Azure region✓

Answer: Serverless accounts are limited to a single Azure region, so an application that requires global distribution across multiple regions needs a provisioned throughput account instead. Serverless accounts still get automatic indexing, aren't limited to one container per database, and can use any of Cosmos DB's APIs.

Which Azure Cosmos DB API stores data as JSON documents, uses a SQL-like query syntax, and is recommended for new applications?

• AThe MongoDB API
• BThe Gremlin API
• CThe Table API
• DThe NoSQL API✓

Answer: The NoSQL API is the native Cosmos DB API, storing data as JSON documents and letting you query with a SQL-like syntax; it's recommended for new applications and was previously called the SQL API before being renamed in 2023. The MongoDB API uses BSON with MongoDB Query Language, the Table API stores key-value pairs, and the Gremlin API is for graph data.

A team is migrating an existing MongoDB application to Azure Cosmos DB with minimal code changes. Which API should they choose, and what data format does it use?

• AThe Cassandra API, which stores data in CQL format
• BThe NoSQL API, which stores data in BSON format
• CThe Table API, which stores data in BSON format
• DThe MongoDB API, which stores data in BSON format✓

Answer: Azure Cosmos DB for MongoDB is compatible with MongoDB drivers and client libraries, so an existing MongoDB application can connect with minimal code changes, and it stores data in BSON (Binary JSON) format while querying with the MongoDB Query Language. The NoSQL API stores JSON documents rather than BSON, the Table API stores key-value pairs, and CQL is a query language, not a Cassandra storage format.

A team already has an Azure Table Storage application and wants to move to Azure Cosmos DB for Table with minimal code changes. What do they gain by doing so?

• ACompatibility with the Gremlin graph query language
• BSupport for foreign keys, multi-table joins, and stored procedures
• CA hierarchical namespace with POSIX-compliant access control lists
• DGreater scalability, global distribution, automatic secondary indexes, and instant autoscale✓

Answer: Azure Cosmos DB for Table uses the same programming model as Azure Table Storage but adds greater scalability, global distribution, automatic secondary indexes, and instant autoscale. It doesn't add relational features such as foreign keys and joins, a hierarchical namespace, or Gremlin graph query compatibility.

Which Azure Cosmos DB API is compatible with an open-source column-family database and lets rows in the same table have different columns, queried using CQL?

• AThe Table API
• BThe native NoSQL API
• CThe Cassandra API✓
• DThe MongoDB API

Answer: Azure Cosmos DB for Apache Cassandra is compatible with Apache Cassandra's column-family storage model, where rows don't have to contain the same columns, and it's queried using CQL (Cassandra Query Language). The MongoDB API uses BSON and MQL, the NoSQL API uses SQL-like syntax over JSON documents, and the Table API stores fixed key-value pairs rather than variable columns.

A team is building a fraud-detection application where the connections between entities matter as much as the entities themselves. Which Azure Cosmos DB API, and which query language, best fits this scenario?

• AThe NoSQL API, queried using SQL-like syntax
• BThe MongoDB API, queried using MQL
• CThe Gremlin API, queried using Gremlin✓
• DThe Cassandra API, queried using CQL

Answer: Azure Cosmos DB for Apache Gremlin is designed for graph data, representing entities as vertices and relationships as edges, which suits use cases like fraud detection, social networks, and recommendation engines where connections matter as much as the data itself; it's traversed using the Gremlin query language. The Cassandra, MongoDB, and NoSQL APIs use column-family, document, and JSON-document models respectively, none of which are built around graph traversal.