DP-420 key terms

A schema-agnostic unit inside a Cosmos DB database that stores a set of items and defines its own throughput, indexing, and partition key settings. Applications read and write items through containers, and containers are the main unit you scale.

A single JSON document stored in a container. Every item needs a unique id within its logical partition and must carry the partition key value that determines where Cosmos DB stores it.

A JSON property whose value Cosmos DB hashes to spread items across logical partitions. Choosing one with high cardinality and even read/write distribution prevents hot partitions and keeps requests cheap.

The set of all items in a container that share the same partition key value. Its data is stored together and can be touched by a single transactional batch or stored procedure, up to a 20 GB size limit.

A partition key built from up to three nested properties, which spreads data across a wider key range and gives better fan-out for multi-tenant workloads where one level alone would create very large logical partitions.

A normalized measure of the compute, memory, and I/O cost of a database operation. Reads, writes, and queries each consume a number of RUs, and provisioned throughput is expressed in RU/s.

An account setting that trades read freshness against latency and availability. The options are strong, bounded staleness, session, consistent prefix, and eventual, and session consistency is the default.

A value the client library tracks per logical partition so a session can read its own writes. Passing it on requests preserves session consistency even when reads are served from another region's replica.

A container setting that lists which JSON paths are indexed or excluded and which index types apply. Tuning it lowers write cost and storage while still supporting the queries the application actually runs.

An index over several properties in a defined order. Queries that filter or sort on those properties in that order can avoid a scan, and sorting on multiple fields requires one.

A persistent, ordered log of creates and updates in a container that downstream consumers can read incrementally. Each logical partition is delivered in order, and deletes are excluded unless the all-versions-and-deletes mode is used.

A client-side library that spreads change feed reading across multiple instances using a lease container. It tracks continuation points, balances load when instances start or stop, and invokes a handler for each batch of changes.

A group of item operations submitted together that succeed or fail as one atomic unit. Every operation must target the same logical partition, and a batch is limited to 100 operations and 2 MB.

JavaScript code registered on a container and executed on the server inside a single logical partition. It can run many operations atomically in one transaction and is invoked through the SDK.

A mechanism where each item carries an ETag that changes on every update. A write that supplies a stale ETag is rejected with a precondition failure, letting applications detect conflicting updates without locking.

A setting that expires items automatically a specified number of seconds after their last write. It can be turned on at container level with an optional per-item override, and expired items are purged in the background.

The throughput and billing model of an account or container: provisioned RU/s, serverless where you pay per request consumed, or autoscale which adjusts provisioned RU/s within a range as demand changes.

A provisioned throughput setting with a maximum RU/s that Cosmos DB scales between ten percent of that maximum and the maximum itself based on demand. Billing uses the highest RU/s reached in each hour.

A container setting that decides which version of an item wins when the same item is written in multiple write regions. Options are last-writer-wins using a property path or a custom stored procedure.

An account configuration that lets applications write to more than one Azure region. Writes are accepted locally for low latency, and conflicting versions are reconciled by the container's conflict resolution policy.

Storing related data together in one item instead of splitting it across containers. It reduces request count and cross-partition queries, at the cost of duplicated data that the application must keep consistent.

A query that cannot be served from a single logical partition, so the engine fans out to multiple partitions and merges the results. It costs more RUs and often improves with a better partition key or index.

Role assignments that let an identity read or write data in a Cosmos DB account using built-in roles such as Data Reader and Data Contributor. It replaces shared keys with per-identity, auditable access control.

Primary and secondary master keys that grant full access to an account's data plane. They are convenient for quick starts but must be protected and rotated, and role-based access or managed identities are preferred for applications.

A short-lived, scoped credential the account issues for a specific user and permission. It lets a client app reach only certain items or containers without ever holding the account keys.

An Azure identity assigned to a compute resource such as an app service or function, used to authenticate to Cosmos DB without storing secrets. Access is granted through Entra ID role assignments.

A network interface in a virtual network that connects to a Cosmos DB account over a private IP address. It removes public internet exposure and is paired with private DNS so SDKs resolve the account correctly.

An account-level allow list of public IP addresses or ranges permitted to reach the data plane. It is a coarse network control, often replaced or complemented by private endpoints for production workloads.

An encryption key you create and control in Azure Key Vault, used to wrap the account's service-managed keys at rest. Rotating or revoking it affects access, so operations depend on Key Vault availability.

A metric showing the percentage of provisioned throughput currently used, scaled so 100 percent means full utilization. It makes load comparable across containers with different RU/s and drives throttling alerts.

Provisioned compute inside the account that runs the gateway and integrated cache. It gives large clients a stable connection endpoint and keeps cache and request-routing work off shared infrastructure.

An in-memory cache for point reads and queries that runs in a Cosmos DB dedicated gateway. Repeated requests are served without consuming RU/s, and you configure item cache and query cache policies to use it.

Platform logs an account sends to Log Analytics, storage, or event hubs. They capture data-plane and control-plane operations, query text, and throughput usage for auditing and troubleshooting.

A column-oriented copy of container data that Cosmos DB maintains automatically. It serves large analytical queries with no impact on transactional RU/s and is queried through Azure Synapse Link.

An integration that lets Synapse run analytical queries directly against the analytical store of a Cosmos DB container without data movement or ETL. It reads near-real-time data using separate compute.

A numeric array that represents text, images, or other content in a high-dimensional space, where similar content yields similar vectors. Cosmos DB stores embeddings as item properties and compares them during vector search.

A Cosmos DB query capability that ranks items by vector distance using a built-in function such as VectorDistance plus an index definition. It enables semantic similarity, recommendations, and search experiences in the SQL API.

The container indexing setting that builds a vector index on a chosen path, specifying a type such as diskANN or quantizedFlat together with dimensions and distance metric. Efficient vector search requires it.

A pattern where relevant documents fetched from a database are passed to a large language model as grounding context. Cosmos DB acts as the vector store that supplies those retrieved passages.