Ilianko - User contributions [en]

Category:DP-420 Terminology

2026-10-26T15:18:01Z

Anko: Add 100-word category description for DP-420 Terminology

This category contains key terminology, concepts, and reference articles for the '''[[DP-420: Azure Cosmos DB Developer Specialty]]''' certification exam (''Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB''). It covers core NoSQL concepts, Request Units (RUs), logical and physical partitioning, data modeling strategies, provisioned and serverless throughput, global distribution, tunable consistency levels, client SDK connectivity, server-side JavaScript programming, indexing policies, Change Feed, Azure Synapse Link, Microsoft Fabric mirroring, monitoring diagnostics, backup and restore models, and data-plane security. Each article includes a concise technical overview, links to official Microsoft Learn documentation, and DP-420 style practice questions with detailed answer keys.

Azure Cosmos DB

2026-10-26T15:15:50Z

Anko:

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Core Concepts

'''Summary:''' Microsoft's globally distributed, multi-model NoSQL database service for cloud-native apps.

== Overview ==
Azure Cosmos DB is Microsoft's globally distributed, multi-model NoSQL database service designed for cloud-native applications requiring low latency, high availability, and elastic scalability. It supports multiple APIs (including the API for NoSQL, MongoDB, Cassandra, Gremlin, and Table), automatic and transparent horizontal partitioning, tunable consistency levels, and turnkey global distribution across any number of Azure regions.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/introduction Microsoft Learn: Welcome to Azure Cosmos DB]
* [https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/dp-420 Microsoft Learn: DP-420 study guide]

== DP-420 Style Practice Questions ==
'''Q1.''' What is a defining characteristic of Azure Cosmos DB compared to a traditional single-region relational database?
* A. Turnkey global distribution across multiple Azure regions with tunable consistency
* B. It only supports a single fixed consistency level
* C. It requires manual sharding scripts written by the developer
* D. It cannot scale horizontally

'''Q2.''' Which of the following APIs is NOT supported by Azure Cosmos DB?
* A. API for MySQL
* B. API for NoSQL
* C. API for MongoDB
* D. API for Cassandra

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Azure Cosmos DB):''' A. Turnkey global distribution across multiple Azure regions with tunable consistency — Azure Cosmos DB provides built-in global distribution and multiple tunable consistency levels, unlike traditional single-region databases.
* '''Q2 (Azure Cosmos DB):''' A. API for MySQL — Azure Cosmos DB supports NoSQL, MongoDB, Cassandra, Gremlin, and Table APIs, but not a dedicated 'API for MySQL'.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[:Category:DP-420 Terminology]]
[[Category:Core Concepts]]

DP-420: Azure Cosmos DB Developer Specialty

2026-10-26T15:12:09Z

Anko: /* Uncategorized */

'''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB''' — Key terminology reference for exam preparation.

__TOC__

== Core Concepts ==
; [[Azure Cosmos DB]]
: Microsoft's globally distributed, multi-model NoSQL database service for cloud-native apps.
; [[Request Unit (RU)]]
: Normalized currency measuring the cost of database operations, independent of hardware.
; [[Container]]
: Fundamental unit of scalability/storage in Cosmos DB for NoSQL, analogous to a table.
; [[Item (Document)]]
: Fundamental unit of data, stored as a self-describing JSON document within a container.
; [[API for NoSQL]]
: Cosmos DB's native API (formerly SQL API), queried with a SQL-like language; DP-420's focus.
; [[OLTP]]
: Online Transactional Processing; small, fast operations — Cosmos DB's core transactional workload type.
; [[OLAP]]
: Online Analytical Processing; large aggregations and analytical queries over historical data

== Data Modeling & Partitioning ==
; [[Partition Key]]
: Property used to distribute items across physical partitions for scalability.
; [[Logical Partition]]
: Group of items sharing the same partition key value; max 20 GB storage.
; [[Physical Partition]]
: Underlying infrastructure unit hosting one or more logical partitions.
; [[Synthetic Partition Key]]
: Concatenated/computed key combining multiple properties for better distribution.
; [[Hierarchical Partition Key]]
: Up to 3 levels of partition keys for granular, multi-tenant partitioning.
; [[Embedding (Denormalization)]]
: Nesting related data within a single document for fewer round trips.
; [[Referencing (Normalization)]]
: Storing related entities as separate documents linked by an id reference.
; [[Time to Live (TTL)]]
: Container/item setting that automatically deletes items after a set time.
; [[Unique Keys]]
: Container-level constraint enforcing uniqueness of property paths per logical partition.

== Throughput & Scaling ==
; [[Provisioned Throughput]]
: Reserved, guaranteed RU/s billed regardless of consumption; suits steady workloads.
; [[Serverless]]
: Consumption-based billing for actual RUs used; suits intermittent/unpredictable traffic.
; [[Autoscale Throughput]]
: Automatically scales RU/s between 10%-100% of a configured maximum based on demand.
; [[Database-Level Throughput]]
: Provisioned throughput shared across all containers in a database.
; [[az cosmosdb sql container update]]
: CLI: updates container config (indexing, TTL, unique keys), not throughput.
; [[az cosmosdb sql container throughput update]]
: CLI: changes a container's manual RU/s or autoscale max RU/s.
; [[az cosmosdb sql container throughput migrate]]
: CLI: switches a container between manual and autoscale throughput.
; [[az cosmosdb sql container redistribute-partition-throughput]]
: CLI: reallocates RU/s unevenly across physical partitions to relieve a hot partition.

== Data Distribution & Consistency ==
; [[Global Distribution]]
: Turnkey replication of data across any number of Azure regions, no code changes.
; [[Consistency Levels]]
: Five tunable levels (Strong, Bounded Staleness, Session, Consistent Prefix, Eventual).
; [[Automatic Failover]]
: Policy that automatically promotes a new write region during a regional outage.
; [[Multi-Region Writes]]
: Every region accepts reads and writes simultaneously (multi-master).
; [[Conflict Resolution Policy]]
: Defines how concurrent multi-region write conflicts are resolved (e.g., LWW).
; [[Session Token]]
: Value guaranteeing a client reads its own writes under session consistency.

== Client Connectivity & SDK ==
; [[Gateway Mode]]
: SDK connectivity via a single HTTPS endpoint; more firewall-friendly, higher latency.
; [[Direct Mode]]
: SDK connectivity direct to backend replicas over TCP; lower latency, more ports needed.
; [[Cosmos DB Emulator]]
: Local, offline tool emulating Cosmos DB for development/testing without Azure cost.
; [[Point Operation]]
: Single-item operation using id + partition key, more RU-efficient than a query.
; [[Patch Operation]]
: Partial update of specific item properties without replacing the whole document.
; [[Transactional Batch]]
: Groups multiple point operations on the same logical partition into one atomic transaction.
; [[Bulk Support]]
: SDK feature optimized for loading/updating large volumes of items across many partitions.
; [[Optimistic Concurrency (ETag)]]
: Uses the ETag property with if-match preconditions to detect write conflicts.
; [[Continuation Token]]
: Opaque value used to resume a paginated query/feed from where the last page left off.
; [[Cross-Partition Query]]
: Query spanning multiple physical partitions; tuned via MaxConcurrency and MaxBufferedItemCount.
; [[429 Throttling Error]]
: Error indicating a request was rate-limited due to exceeding provisioned RU/s.
; [[isTombstone]]

== Server-Side Programming ==
; [[x-ms-retry-after-ms]]
: http header value that represents in milliseconds the minimal waiting time between requests.
; [[Item response, Feed response]]
: Contains both returned data plus request charge, session token, and ETag
; [[Queries]]
: Queries
; [[Stored Procedure]]
: JavaScript logic executed server-side within a single logical partition transaction.
; [[BulkImportResponse]]
: Return object of the classic bulkImport stored procedure pattern; reports numDocsImported/continuation.
; [[Trigger]]
: Pre- or post-operation JavaScript logic, explicitly invoked by the client per request.
; [[User-Defined Function (UDF)]]
: Read-only JavaScript function extending SQL queries with custom computations.
; [[Aggregate Functions (COUNT, SUM, AVG, MIN, MAX)]]
: Built-in SQL aggregate operators (COUNT, SUM, AVG, MIN, MAX) used with GROUP BY.
; [[EXISTS & Array Functions (IS_ARRAY, ARRAY_CONTAINS)]]
: SQL subquery and array functions (EXISTS, IS_ARRAY, ARRAY_CONTAINS, ARRAY_LENGTH) for nested data.

== Integration & Analytics ==
; [[Change Feed]]
: Persistent, ordered log of item inserts/updates, consumable by apps and Azure Functions.
; [[Full-Text Query]]
: Native keyword search via FULLTEXTCONTAINS/FULLTEXTSCORE, backed by a full-text index.
; [[HTAP (Hybrid Transactional and Analytical Processing)]]
: Architecture running analytics over operational data without impacting transactional OLTP RUs, enabled via Synapse Link/analytical store.
; [[Azure Synapse Link / Analytical Store]]
: Near real-time analytics via a separate column-store, no RU impact on transactional data.
; [[Azure Cosmos DB Mirroring for Fabric]]
: Near real-time replication of Cosmos DB data into Microsoft Fabric's OneLake.
; [[OneLake]]
: Fabric's single, unified, tenant-wide data lake storing all workloads' data in Delta format.
; [[Delta Format]]
: Open-source ACID table format (Delta Lake) used for all data stored in OneLake.
; [[Apache Spark]]
: Distributed processing engine used in Synapse/Fabric notebooks to analyze Cosmos DB data.
; [[Serverless SQL Pool]]
: On-demand T-SQL query service in Azure Synapse to query Cosmos DB analytical store via OPENROWSET.
; [[Direct Lake]]
: Power BI mode reading Delta tables directly from OneLake — near-Import speed, always fresh.
; [[Azure Functions Integration]]
: Serverless compute triggered by Cosmos DB change feed for event-driven processing, denormalization, and data movement.
; [[Azure Logic Apps]]
: Low-code cloud workflow automation service integrating with Cosmos DB via connectors, triggers, and actions.
; [[Azure AI Search Integration]]
: Indexer pulls Cosmos DB data (via change feed) to enable full-text/semantic search.

== Optimization ==
; [[Indexing Policy]]
: Defines which properties are indexed, trading off query performance vs. write RU cost.
; [[Range Index]]
: Default index type for string/numeric properties; supports equality, range, and ORDER BY.
; [[Spatial Index]]
: Accelerates geospatial queries (ST_DISTANCE, ST_WITHIN) over GeoJSON properties.
; [[Composite Index]]
: Index across multiple properties to support efficient multi-property filter/sort queries.
; [[Vector Index]]
: Enables approximate nearest-neighbor similarity search over embeddings for AI/RAG scenarios.
; [[Wildcard / Included & Excluded Paths]]
: Path expressions (with optional /* wildcard) controlling exactly which properties are indexed.
; [[Integrated Cache]]
: In-memory caching layer (via dedicated gateway) reducing RU cost/latency for repeated reads.
; [[Change Feed Estimator]]
: Reports pending change feed lag to help decide when to scale out consumer instances.

== Maintenance & Security ==
; [[Alerts]]
: Cosmo DB alerts
; [[Normalized RU Consumption]]
: Azure Monitor metric showing % of provisioned throughput used; flags hot partitions.
; [[PartitionKeyRUConsumption (Diagnostic Log)]]
: Per-second RU/s consumption per partition key; pinpoints hot partitions.
; [[PartitionKeyStatistics (Diagnostic Log)]]
: Estimated storage size (KB) per logical partition key; flags storage skew.
; [[QueryRuntimeStatistics (Diagnostic Log)]]
: Logs query operations against the account for query performance analysis.
; [[ControlPlaneRequests (Diagnostic Log)]]
: Logs account control-plane operations, e.g. adding/removing replication regions.
; [[DataPlaneRequests (Diagnostic Log)]]
: Logs item-level create/read/replace/delete/query operations with RU charge and duration.
; [[KQL (Kusto Query Language)]]
: Query language used in Azure Monitor Log Analytics to analyze Cosmos DB diagnostic logs and metrics.
; [[Periodic Backup]]
: Original backup mode; scheduled snapshots, typically restored via a support request.
; [[Continuous Backup & Point-in-Time Restore]]
: Continuous backups enabling self-service restore to any timestamp in the retention window.
; [[Customer-Managed Keys]]
: Encrypt data at rest using a key you control in Azure Key Vault.
; [[Data Encryption Key (DEK)]]
: for Always Encrypted in Azure Cosmos DB, you must use the Azure Cosmos DB SDK (C#, Java, or Node.js).
; [[RBAC for Data Plane]]
: Fine-grained Microsoft Entra ID permissions for data operations, avoiding shared account keys.
; [[Cosmos DB Operator]]
: Provisions accounts, databases, and containers; cannot access data or use Data Explorer.
; [[Cosmos DB Account Reader Role]]
: Can read Azure Cosmos DB account data; cannot provision resources or make changes.
; [[Cosmos Backup Operator]]
: Submits a restore request for a periodic backup-enabled database or container.
; [[CosmosRestoreOperator]]
: Performs the restore action for an account in continuous backup mode.
; [[Always Encrypted]]
: Client-side encryption ensuring Cosmos DB never sees plaintext values of protected properties.
; [[Azure Data Factory (Data Movement)]]
: Pipeline-based ETL/ELT service for moving data into/out of Cosmos DB.
; [[ARM Templates (Infrastructure as Code)]]
: Declarative, version-controlled provisioning of Cosmos DB resources as code.
; [[log-analytics]]

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — terminology reference''

[[Category:DP-420 Terminology]]

Test

2026-10-26T15:07:46Z

Anko: Recreated DP-420 term page: test (Uncategorized)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Uncategorized

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Uncategorized]]

Log-analytics

2026-10-26T15:07:46Z

Anko: Recreated DP-420 term page: log-analytics (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

== Overview ==
It can save data in:

<pre>
| Table | Purpose | When to Use | DP-420 Keywords |
| -------------------------------- | ------------------------------------------ | ---------------------------------- | --------------------------------------------------------- |
| **CDBDataPlaneRequests** | Individual requests made against Cosmos DB | Troubleshoot specific operations | Request charge, latency, 429, point read, query |
| **CDBDataPlaneRequests5M** | Aggregated metrics over 5-minute windows | Trend analysis and dashboards | Throughput trends, average latency, request counts |
| **CDBPartitionKeyRUConsumption** | RU consumption per partition key | Find hot partitions | Hot partition, skewed workload, RU distribution |
| **CDBPartitionKeyStatistics** | Statistics about partition key usage | Analyze partitioning effectiveness | Partition cardinality, partition growth, partition design |
| **CDBQueryRuntimeStatistics** | Query execution details | Optimize queries | Index utilization, query performance, scans |

</pre>

* Send to Log Analytics workspace
* Send to storage account
* Send to event hub
* Send to another Azure Monitor log
* Send to Azure

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/log-analytics/tutorial-kql Microsoft Learn: Tutorial - Write KQL queries to monitor Azure Cosmos DB]
* [https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/ Microsoft Learn: Overview of Kusto Query Language (KQL)]
* [https://learn.microsoft.com/en-us/azure/cosmos-db/monitor-resource-logs Microsoft Learn: Monitor and troubleshoot Azure Cosmos DB using diagnostic logs]

== DP-420 Style Practice Questions ==
'''Q1.''' What is the primary role of KQL (Kusto Query Language) in Azure Cosmos DB operations and troubleshooting?
* A. Querying and analyzing diagnostic logs and metrics in Azure Monitor Log Analytics to troubleshoot issues like throttling, hot partitions, and expensive queries
* B. Defining server-side stored procedures and triggers directly in Cosmos DB containers
* C. Querying JSON documents via the Cosmos DB API for NoSQL endpoint
* D. Creating and managing Cosmos DB indexing policies declaratively

'''Q2.''' In a KQL query for Azure Cosmos DB logs, what does the pipe (|) operator represent?
* A. It pipes the tabular output of the preceding operator as the input to the next operator in a data-flow pipeline
* B. It performs a logical bitwise OR between two numeric fields
* C. It defines a primary key constraint on the diagnostic table
* D. It separates alternative partition key values in a point read

'''Q3.''' Which resource-specific table would you query using KQL to inspect RU charges and HTTP status codes for individual data operations?
* A. CDBDataPlaneRequests
* B. CDBControlPlaneRequests
* C. CDBPartitionKeyStatistics
* D. AzureMetrics

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (KQL (Kusto Query Language)):''' A. Querying and analyzing diagnostic logs and metrics in Azure Monitor Log Analytics to troubleshoot issues like throttling, hot partitions, and expensive queries — KQL is the read-only query language for Azure Monitor Log Analytics used to analyze diagnostic logs like CDBDataPlaneRequests and CDBPartitionKeyRUConsumption.
* '''Q2 (KQL (Kusto Query Language)):''' A. It pipes the tabular output of the preceding operator as the input to the next operator in a data-flow pipeline — KQL uses the pipe (|) operator to pass data sequentially from one tabular expression/operator to another (e.g., filtering with where, then aggregating with summarize).
* '''Q3 (KQL (Kusto Query Language)):''' A. CDBDataPlaneRequests — CDBDataPlaneRequests logs individual data-plane operations along with RequestCharge, StatusCode, DurationMs, and ActivityId.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

IsTombstone

2026-10-26T15:07:46Z

Anko: Recreated DP-420 term page: isTombstone (Client Connectivity & SDK)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Client Connectivity & SDK

== Overview ==
Tombstone in Azure Cosmos DB: When an item is deleted from a container, Azure Cosmos DB marks the item as a "tombstone" to ensure that the deletion is propagated correctly across all replicas in a distributed system. This ensures that the deleted item does not reappear after a replica catches up or after a period of network partition. For DP-420, if you see tombstones, think: Change Feed Delete notifications All Versions and Deletes mode CDC (similar to SQL Server Change Data Capture)

<pre>
| Mode | Creates | Updates | Deletes |
| ----------------------------- | ------- | ------- | -------------- |
| Latest Version Mode | ✅ | ✅ | ❌ |
| All Versions and Deletes Mode | ✅ | ✅ | ✅ (tombstones) |

</pre>

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/conceptual-resilient-sdk-applications Microsoft Learn: Handling rate limiting / request rate too large]

== DP-420 Style Practice Questions ==
'''Q1.''' What does a 429 error from Azure Cosmos DB typically indicate?
* A. The request was throttled because provisioned throughput (RU/s) was exceeded
* B. The requested item does not exist
* C. An authentication failure occurred
* D. A conflict occurred during multi-region writes

'''Q2.''' Which of these could help reduce the frequency of 429 errors?
* A. Improving partition key distribution to avoid hot partitions, or increasing provisioned RU/s
* B. Disabling the SDK's automatic retry policy
* C. Switching to gateway mode exclusively
* D. Reducing the number of properties indexed

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (429 Throttling Error):''' A. The request was throttled because provisioned throughput (RU/s) was exceeded — A 429 status code means the request rate exceeded the provisioned RU/s, triggering throttling.
* '''Q2 (429 Throttling Error):''' A. Improving partition key distribution to avoid hot partitions, or increasing provisioned RU/s — Better partition key distribution and/or higher provisioned throughput both help reduce 429 throttling errors.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Client Connectivity & SDK]]

ARM Templates (Infrastructure as Code)

2026-10-26T15:07:45Z

Anko: Recreated DP-420 term page: ARM Templates (Infrastructure as Code) (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Declarative, version-controlled provisioning of Cosmos DB resources as code.

== Overview ==
Azure Resource Manager (ARM) templates (and equivalents like Bicep) allow you to declaratively define and provision Azure Cosmos DB resources — accounts, databases, containers, throughput settings, and indexing policies — as code, enabling repeatable, version-controlled deployments as part of a DevOps process, as opposed to imperative, manual configuration through the Azure portal or CLI commands.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/manage-with-templates Microsoft Learn: Manage Azure Cosmos DB resources with ARM templates]

== DP-420 Style Practice Questions ==
'''Q1.''' What is the main advantage of provisioning Azure Cosmos DB resources using ARM templates instead of the Azure portal?
* A. Declarative, repeatable, and version-controlled infrastructure as code
* B. Lower RU cost for provisioned throughput
* C. Automatic point-in-time restore
* D. Elimination of the need for a partition key

'''Q2.''' Which of these can be maintained in production using ARM templates, per the DP-420 objectives?
* A. Indexing policies
* B. The account's region priority list only
* C. The change feed estimator
* D. The integrated cache

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (ARM Templates (Infrastructure as Code)):''' A. Declarative, repeatable, and version-controlled infrastructure as code — ARM templates provide declarative, repeatable infrastructure-as-code deployments suitable for DevOps pipelines.
* '''Q2 (ARM Templates (Infrastructure as Code)):''' A. Indexing policies — The DP-420 objectives specifically call out maintaining indexing policies in production using ARM templates.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

Azure Data Factory (Data Movement)

2026-10-26T15:07:45Z

Anko: Recreated DP-420 term page: Azure Data Factory (Data Movement) (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Pipeline-based ETL/ELT service for moving data into/out of Cosmos DB.

== Overview ==
Azure Data Factory is a cloud ETL/ELT service that can be used to move data into or out of Azure Cosmos DB as part of pipeline-based data movement strategies — such as bulk-loading data from other sources, or migrating/copying data between Cosmos DB accounts or containers — as an alternative to using SDK bulk operations, Kafka connectors, or Stream Analytics for data movement.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/data-factory/connector-azure-cosmos-db Microsoft Learn: Copy data to/from Azure Cosmos DB using ADF]

== DP-420 Style Practice Questions ==
'''Q1.''' Which Azure service provides pipeline-based ETL/ELT capabilities for moving data into or out of Azure Cosmos DB?
* A. Azure Data Factory
* B. Azure Bastion
* C. Azure Front Door
* D. Azure DNS

'''Q2.''' Besides Azure Data Factory, which of these is also a valid data movement option for Azure Cosmos DB mentioned in the DP-420 objectives?
* A. A Kafka connector
* B. Always Encrypted
* C. A composite index
* D. A trigger

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Azure Data Factory (Data Movement)):''' A. Azure Data Factory — Azure Data Factory (and Azure Synapse pipelines) provide pipeline-based data movement capabilities for Cosmos DB.
* '''Q2 (Azure Data Factory (Data Movement)):''' A. A Kafka connector — The DP-420 objectives list SDK bulk operations, ADF/Synapse pipelines, a Kafka connector, Stream Analytics, and the Spark connector as data movement options.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

Always Encrypted

2026-10-26T15:07:45Z

Anko: Recreated DP-420 term page: Always Encrypted (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Client-side encryption ensuring Cosmos DB never sees plaintext values of protected properties.

== Overview ==
Always Encrypted for Azure Cosmos DB is a client-side encryption feature that encrypts sensitive data (specific properties) before it leaves the client application, ensuring that even Azure Cosmos DB itself never sees the plaintext values. Encryption and decryption happen using keys managed by the client, typically backed by Azure Key Vault, providing strong protection for highly sensitive fields.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-always-encrypted Microsoft Learn: Always Encrypted for Azure Cosmos DB]

== DP-420 Style Practice Questions ==
'''Q1.''' What does Always Encrypted for Azure Cosmos DB protect against?
* A. Azure Cosmos DB (and anyone with access to the service) ever seeing plaintext values of protected properties
* B. Network-level attacks only
* C. Only attacks that occur during backup and restore
* D. Loss of the primary account key only

'''Q2.''' Where does encryption/decryption occur when using Always Encrypted?
* A. On the client side, before data leaves the application
* B. On the Cosmos DB server, before storage
* C. In transit only, using TLS
* D. Only during backup operations

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Always Encrypted):''' A. Azure Cosmos DB (and anyone with access to the service) ever seeing plaintext values of protected properties — Always Encrypted ensures the database service itself never has access to plaintext values, protecting against server-side exposure.
* '''Q2 (Always Encrypted):''' A. On the client side, before data leaves the application — Always Encrypted performs client-side encryption/decryption, so sensitive data is never exposed in plaintext to the service.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

CosmosRestoreOperator

2026-10-26T15:07:44Z

Anko: Recreated DP-420 term page: CosmosRestoreOperator (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Performs the restore action for an account in continuous backup mode.

== Overview ==
CosmosRestoreOperator is a built-in Azure RBAC (control-plane) role that can perform a restore action for an Azure Cosmos DB account in continuous backup mode, without granting broader account management or item data access permissions. This complements Cosmos Backup Operator, which instead submits restore requests for periodic backup-enabled databases/containers — the appropriate role depends on which backup mode (Periodic Backup or Continuous Backup & Point-in-Time Restore) the account uses.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/databases#cosmosrestoreoperator Microsoft Learn: Azure built-in roles for Azure Cosmos DB]

== DP-420 Style Practice Questions ==
'''Q1.''' What permission does the CosmosRestoreOperator role grant?
* A. The ability to perform a restore action for an account in continuous backup mode
* B. The ability to submit a periodic backup restore request
* C. The ability to read item data using Data Explorer
* D. The ability to provision new databases and containers

'''Q2.''' Which role would you assign to submit a restore request for a periodic backup-enabled container instead?
* A. Cosmos Backup Operator
* B. Cosmos DB Operator
* C. Cosmos DB Account Reader Role
* D. CosmosRestoreOperator

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (CosmosRestoreOperator):''' A. The ability to perform a restore action for an account in continuous backup mode — CosmosRestoreOperator specifically enables restoring an account that has continuous backup mode enabled.
* '''Q2 (CosmosRestoreOperator):''' A. Cosmos Backup Operator — Cosmos Backup Operator is used for periodic backup restore requests, while CosmosRestoreOperator applies to continuous backup mode.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

Cosmos Backup Operator

2026-10-26T15:07:44Z

Anko: Recreated DP-420 term page: Cosmos Backup Operator (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Submits a restore request for a periodic backup-enabled database or container.

== Overview ==
Cosmos Backup Operator is a built-in Azure RBAC (control-plane) role that can submit a restore request from the Azure portal for a periodic backup-enabled database or container, without granting the ability to read or write item data. This is distinct from CosmosRestoreOperator, which instead performs a restore action for an account configured in continuous backup mode — the two roles apply to the two different backup modes (Periodic Backup vs. Continuous Backup & Point-in-Time Restore).

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/databases#cosmos-backup-operator Microsoft Learn: Azure built-in roles for Azure Cosmos DB]

== DP-420 Style Practice Questions ==
'''Q1.''' What does the Cosmos Backup Operator built-in role allow?
* A. Submitting a restore request from the Azure portal for a periodic backup-enabled database or container
* B. Restoring a continuous-backup-enabled account directly
* C. Reading and writing items directly
* D. Provisioning new Azure Cosmos DB accounts

'''Q2.''' How does Cosmos Backup Operator differ from CosmosRestoreOperator?
* A. Backup Operator submits restore requests for periodic backup, while CosmosRestoreOperator performs restores for continuous backup accounts
* B. They are the same role with two names
* C. Backup Operator can read item data, but CosmosRestoreOperator cannot
* D. CosmosRestoreOperator only works with periodic backup mode

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Cosmos Backup Operator):''' A. Submitting a restore request from the Azure portal for a periodic backup-enabled database or container — Cosmos Backup Operator submits restore requests for periodic backup-enabled databases/containers, not for continuous backup accounts.
* '''Q2 (Cosmos Backup Operator):''' A. Backup Operator submits restore requests for periodic backup, while CosmosRestoreOperator performs restores for continuous backup accounts — Cosmos Backup Operator handles periodic backup restore requests, whereas CosmosRestoreOperator restores accounts in continuous backup mode.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

Cosmos DB Account Reader Role

2026-10-26T15:07:44Z

Anko: Recreated DP-420 term page: Cosmos DB Account Reader Role (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Can read Azure Cosmos DB account data; cannot provision resources or make changes.

== Overview ==
Cosmos DB Account Reader Role is a built-in Azure RBAC (control-plane) role that can read Azure Cosmos DB account data — including viewing account configuration and reading item data — without permission to make any changes to the account or its resources. It is commonly assigned to auditors, monitoring tools, or team members who need read visibility into an account without provisioning rights (contrast with Cosmos DB Operator, which can provision resources but not read data).

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/databases#cosmosdb-account-reader-role Microsoft Learn: Azure built-in roles for Azure Cosmos DB]

== DP-420 Style Practice Questions ==
'''Q1.''' What does the Cosmos DB Account Reader Role permit?
* A. Reading Azure Cosmos DB account data and configuration, without making changes
* B. Provisioning new databases and containers
* C. Restoring a deleted account from continuous backup
* D. Submitting a periodic backup restore request

'''Q2.''' How does Cosmos DB Account Reader Role differ from Cosmos DB Operator?
* A. Account Reader can read account data but cannot provision resources, while Cosmos DB Operator can provision resources but cannot access data
* B. They are identical roles with different names
* C. Account Reader can restore accounts, while Cosmos DB Operator cannot
* D. Cosmos DB Operator can read data but not provision resources

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Cosmos DB Account Reader Role):''' A. Reading Azure Cosmos DB account data and configuration, without making changes — This role provides read access to account data/configuration but no ability to modify resources or provision new ones.
* '''Q2 (Cosmos DB Account Reader Role):''' A. Account Reader can read account data but cannot provision resources, while Cosmos DB Operator can provision resources but cannot access data — Account Reader is read-focused on data/configuration, whereas Cosmos DB Operator is focused on provisioning without data access.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

Cosmos DB Operator

2026-10-26T15:07:43Z

Anko: Recreated DP-420 term page: Cosmos DB Operator (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Provisions accounts, databases, and containers; cannot access data or use Data Explorer.

== Overview ==
Cosmos DB Operator is a built-in Azure RBAC (control-plane/ARM) role that lets you provision Azure Cosmos DB accounts, databases, and containers, but cannot access any data (item reads/writes) or use Data Explorer, and cannot read account keys/connection strings. It is distinct from Cosmos DB Account Reader Role (which can read account data), Cosmos Backup Operator (which manages periodic backup restore requests), and CosmosRestoreOperator (which restores continuous-backup accounts) — Cosmos DB Operator is purely about provisioning infrastructure.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/databases#cosmos-db-operator Microsoft Learn: Azure built-in roles for Azure Cosmos DB]

== DP-420 Style Practice Questions ==
'''Q1.''' What can the Cosmos DB Operator built-in role do?
* A. Provision Azure Cosmos DB accounts, databases, and containers, without accessing data or using Data Explorer
* B. Read item data using Data Explorer
* C. Restore a deleted Azure Cosmos DB account
* D. Submit a periodic backup restore request

'''Q2.''' Why does the Cosmos DB Operator role exclude access to Data Explorer and account data?
* A. To enforce least privilege, separating infrastructure provisioning from data access
* B. Because it is a deprecated role
* C. Because it only applies to the MongoDB API
* D. Because data access is managed exclusively through Cosmos Backup Operator

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Cosmos DB Operator):''' A. Provision Azure Cosmos DB accounts, databases, and containers, without accessing data or using Data Explorer — Cosmos DB Operator can provision accounts, databases, and containers, but explicitly cannot access data or use Data Explorer.
* '''Q2 (Cosmos DB Operator):''' A. To enforce least privilege, separating infrastructure provisioning from data access — Excluding Data Explorer/data access lets an operator provision resources (control plane) without being able to read or modify the actual data (data plane).

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

RBAC for Data Plane

2026-10-26T15:07:43Z

Anko: Recreated DP-420 term page: RBAC for Data Plane (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Fine-grained Microsoft Entra ID permissions for data operations, avoiding shared account keys.

== Overview ==
Azure Cosmos DB supports Azure role-based access control (RBAC) for data plane operations, allowing you to grant fine-grained permissions (read, write, specific operations) to Microsoft Entra ID identities for accessing data within containers, as an alternative or complement to using primary/secondary account keys, improving security by avoiding shared-secret key distribution.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/security/how-to-grant-data-plane-role-based-access Microsoft Learn: Configure RBAC for data plane]

== DP-420 Style Practice Questions ==
'''Q1.''' What does data plane RBAC allow you to control in Azure Cosmos DB?
* A. Fine-grained permissions for Microsoft Entra ID identities to access and operate on data
* B. Which Azure regions data is replicated to
* C. The container's indexing policy
* D. The account's consistency level

'''Q2.''' What is an advantage of using Microsoft Entra ID-based data plane RBAC over primary/secondary account keys?
* A. It avoids distributing shared-secret keys and enables fine-grained, identity-based permissions
* B. It automatically enables multi-region writes
* C. It removes the need for TLS encryption
* D. It disables the need for a partition key

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (RBAC for Data Plane):''' A. Fine-grained permissions for Microsoft Entra ID identities to access and operate on data — Data plane RBAC controls what data operations specific Microsoft Entra ID identities are permitted to perform.
* '''Q2 (RBAC for Data Plane):''' A. It avoids distributing shared-secret keys and enables fine-grained, identity-based permissions — RBAC with Microsoft Entra ID avoids shared-secret key distribution and allows more granular, auditable access control.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

Data Encryption Key (DEK)

2026-10-26T15:07:43Z

Anko: Recreated DP-420 term page: Data Encryption Key (DEK) (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' for Always Encrypted in Azure Cosmos DB, you must use the Azure Cosmos DB SDK (C#, Java, or Node.js).

== Overview ==
Here is the sequence to create and use a Data Encryption Key (DEK):

# '''Create the Key Encryption Key (KEK):''' Before creating a DEK, you must create a master key in Azure Key Vault to protect it. Create a new RSA key in your vault, navigate to its current version, and copy the full Key Identifier (URI).
# '''Grant the Client Application Access to the KEK:''' The application running the Cosmos DB SDK needs permission to wrap and unwrap the DEK. Assign your application's Managed Identity permissions to the Key Vault to grant Get, List, Wrap Key, Unwrap Key, Verify, and Sign access.
# '''Initialize the Cosmos DB Client with a Key Resolver:''' In your application code, attach a Key Resolver to your Cosmos DB client instance so it can authenticate with Key Vault using the DefaultAzureCredential.
** '''C#:''' Use KeyResolver and .WithEncryption() when building the CosmosClient.
** '''Java:''' Use KeyEncryptionKeyClientBuilder.
** '''JavaScript/TypeScript:''' Pass an AzureKeyVaultEncryptionKeyResolver into the clientEncryptionOptions.

# '''Create the DEK via the SDK:''' Call the CreateClientEncryptionKey method on your Cosmos DB Database object, passing:
** A unique string identifier for this DEK.
** The encryption algorithm (AEAD_AES_256_CBC_HMAC_SHA256).
** The KEK URI you copied in the first step.

# '''Apply the DEK to a Container:''' When creating a new Cosmos DB container, define a ClientEncryptionPolicy. Specify which exact JSON properties should be encrypted, map them to your DEK's string identifier, and choose either Deterministic or Randomized encryption.

Once configured, your application will automatically request the wrapped DEK from Cosmos DB, decrypt it locally using Azure Key Vault, and seamlessly encrypt your properties before sending the data.

# Create DEK
<pre>
await database.CreateClientEncryptionKeyAsync(
id: "dek1",
encryptionAlgorithm:
DataEncryptionKeyEncryptionAlgorithm
.AeadAes256CbcHmacSha256,
encryptionKeyWrapMetadata: metadata);
</pre>
# Use encryption
<pre>
new CosmosClientBuilder(endpoint, credential)
.WithEncryption(keyResolver, keyStoreProvider)
.Build();
</pre>
# Create DEK
<pre>
await database.CreateClientEncryptionKeyAsync(
id: "dek1",
encryptionAlgorithm:
DataEncryptionKeyEncryptionAlgorithm
.AeadAes256CbcHmacSha256,
encryptionKeyWrapMetadata: metadata);
</pre>
# C# ClientEncryptionPolicy
<pre>
ClientEncryptionPolicy encryptionPolicy =
new ClientEncryptionPolicy(
new List
{
new ClientEncryptionIncludedPath
{
Path = "/email",
ClientEncryptionKeyId = "dek1",
EncryptionType =
ClientEncryptionEncryptionType.Deterministic,
EncryptionAlgorithm =
DataEncryptionKeyEncryptionAlgorithm
.AeadAes256CbcHmacSha256
},
new ClientEncryptionIncludedPath
{
Path = "/ssn",
ClientEncryptionKeyId = "dek1",
EncryptionType =
ClientEncryptionEncryptionType.Randomized,
EncryptionAlgorithm =
DataEncryptionKeyEncryptionAlgorithm
.AeadAes256CbcHmacSha256
}
});

ContainerProperties properties =
new ContainerProperties(
id: "Customers",
partitionKeyPath: "/customerId");

properties.ClientEncryptionPolicy = encryptionPolicy;

await database.CreateContainerAsync(properties);

//If the policy contains: Plain Text
// /email -> Deterministic
// SELECT * FROM c WHERE c.email = "john@contoso.com"
</pre>
# Create DEK
<pre>
CreateClientEncryptionKeyAsync()
</pre>

<pre>
1. Create KEK
2. Grant Key Vault permissions
3. Configure Cosmos Client
4. Create DEK
5. Create Encryption Policy
6. Create Container
7. Read/Write encrypted data
</pre>

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-setup-cmk Microsoft Learn: Customer-managed keys]

== DP-420 Style Practice Questions ==
'''Q1.''' What is the main advantage of using customer-managed keys (CMK) over platform-managed keys?
* A. Full control over encryption key management, rotation, and revocation via Azure Key Vault
* B. Lower cost than platform-managed keys
* C. Elimination of the need to configure network access control
* D. Automatic multi-region writes

'''Q2.''' Where are customer-managed keys typically stored and managed for Azure Cosmos DB?
* A. Azure Key Vault
* B. Inside the Cosmos DB container itself
* C. In the application's source code
* D. In Azure Active Directory Connect

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Customer-Managed Keys):''' A. Full control over encryption key management, rotation, and revocation via Azure Key Vault — CMK gives the customer control over key lifecycle management, useful for meeting specific compliance requirements.
* '''Q2 (Customer-Managed Keys):''' A. Azure Key Vault — Customer-managed keys are stored and managed in Azure Key Vault, which Azure Cosmos DB references for encryption operations.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

Customer-Managed Keys

2026-10-26T15:07:42Z

Anko: Recreated DP-420 term page: Customer-Managed Keys (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Encrypt data at rest using a key you control in Azure Key Vault.

== Overview ==
Customer-managed keys (CMK) allow you to encrypt Azure Cosmos DB data at rest using an encryption key that you control and manage in Azure Key Vault, rather than relying solely on Microsoft's platform-managed keys. This gives organizations control over key rotation, revocation, and compliance requirements, at the cost of additional operational responsibility for key management.

# '''Step 1: Prepare the Azure Key Vault''' Create or select an Azure Key Vault. You must ensure three specific settings are configured on the vault:
** Soft Delete and Purge Protection must be enabled (required by Cosmos DB to prevent accidental key loss).
** Permission model must be set to Azure role-based access control (RBAC) (required to grant permissions to a specific key rather than the whole vault).

# '''Step 2: Generate the Key and Assign Granular Permissions''' Inside your Key Vault, generate the encryption key and immediately lock down who can use it:
** Generate a new key (an RSA key size of 3072 or higher is recommended).
** Once generated, select that specific key, click on its Access control (IAM) menu, and add a role assignment.
** Assign the Key Vault Crypto Service Encryption User role to the Azure Cosmos DB principal.
** Before leaving the screen, copy the key's Key Identifier (URI).

# '''Step 3: Create the Azure Cosmos DB Account''' During the creation of your new Azure Cosmos DB account in the Azure portal, navigate to the Encryption tab. Select Customer-managed key and paste the Key URI you copied in Step 2. Cosmos DB will validate its access to that specific key and encrypt the new account.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-setup-cmk Microsoft Learn: Customer-managed keys]

== DP-420 Style Practice Questions ==
'''Q1.''' What is the main advantage of using customer-managed keys (CMK) over platform-managed keys?
* A. Full control over encryption key management, rotation, and revocation via Azure Key Vault
* B. Lower cost than platform-managed keys
* C. Elimination of the need to configure network access control
* D. Automatic multi-region writes

'''Q2.''' Where are customer-managed keys typically stored and managed for Azure Cosmos DB?
* A. Azure Key Vault
* B. Inside the Cosmos DB container itself
* C. In the application's source code
* D. In Azure Active Directory Connect

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Customer-Managed Keys):''' A. Full control over encryption key management, rotation, and revocation via Azure Key Vault — CMK gives the customer control over key lifecycle management, useful for meeting specific compliance requirements.
* '''Q2 (Customer-Managed Keys):''' A. Azure Key Vault — Customer-managed keys are stored and managed in Azure Key Vault, which Azure Cosmos DB references for encryption operations.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

Continuous Backup & Point-in-Time Restore

2026-10-26T15:07:42Z

Anko: Recreated DP-420 term page: Continuous Backup & Point-in-Time Restore (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Continuous backups enabling self-service restore to any timestamp in the retention window.

== Overview ==
Continuous backup mode continuously backs up Azure Cosmos DB data, enabling self-service point-in-time restore (PITR) to any timestamp within the retention period (7 or 30 days depending on tier), without needing to contact support. This is useful for recovering from accidental data deletion/corruption or application bugs with much finer granularity than periodic backup.

Azure Cosmos DB accounts with periodic mode backup policy can be migrated to continuous mode using the Azure portal, Azure CLI, Azure PowerShell, or Bicep templates. Migration from periodic to continuous mode is one-way and isn't reversible. After you migrate from periodic to continuous mode, you get the benefits of continuous mode.

<pre>
// Set the backup policy for the Azure Cosmos DB account
AccountUpdateParameters accountUpdateParameters = new AccountUpdateParameters()
{
BackupPolicy = new ContinuousBackupPolicy()
{
Type = BackupPolicyType.Continuous,
}
};

await databaseAccount.ReplaceAccountAsync(accountUpdateParameters);
</pre>

<pre>
az cosmosdb update --resource-group "" --name "" \
--backup-policy-type "Continuous" --continuous-tier "Continuous7Days"
</pre>
'''Feature / Configuration''' '''Periodic Backup (Default)''' '''Continuous Backup (Point-in-Time)''' '''Restore Mechanism''' Requires submitting an Azure support ticket. Self-service Point-in-Time Restore (PITR) via portal/CLI. '''Retention Window''' Configurable up to 1 month (720 hours). Fixed tiers: 7-day, 30-day, or 35-day. '''Backup Interval''' Configurable (minimum 1 hour). Continuous ongoing backup (no interval required). '''Storage Redundancy''' Replicated to a paired region via Geo-Redundant Storage (GRS). Stored locally in the account's existing regions (not automatically geo-resistant). '''Supported APIs''' All Azure Cosmos DB APIs. SQL, MongoDB, Gremlin, and Table (Cassandra is not supported). '''Cost Structure''' Default (2 copies) is free. Billed for additional copies/retention. 7-day storage is free. 30/35-day tiers incur storage costs. All restores incur a fee. '''Migration''' Can be migrated to Continuous mode. '''One-way only:''' Cannot revert back to Periodic.
<pre>
Restored
Data plane
Databases
Containers
Items/documents
Throughput

❌ Not restored
Control plane
Networking
Security
Regional settings
Consistency settings
Programmability objects (Sprocs, Triggers, UDFs)
External integrations
</pre>

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/continuous-backup-restore-introduction Microsoft Learn: Continuous backup and point-in-time restore]

== DP-420 Style Practice Questions ==
'''Q1.''' What capability does continuous backup mode enable that periodic backup does not?
* A. Self-service point-in-time restore to any timestamp within the retention window
* B. Multi-region writes
* C. Automatic index optimization
* D. Free throughput

'''Q2.''' Do you need to contact Microsoft support to perform a restore under continuous backup mode?
* A. No, restores can be self-service, initiated by the account owner
* B. Yes, a support ticket is always required
* C. Only for restores older than 24 hours
* D. Only when using the Cassandra API

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Continuous Backup & Point-in-Time Restore):''' A. Self-service point-in-time restore to any timestamp within the retention window — Continuous backup enables self-service point-in-time restore to virtually any moment within the retention period.
* '''Q2 (Continuous Backup & Point-in-Time Restore):''' A. No, restores can be self-service, initiated by the account owner — Continuous backup allows account owners to self-service restore without needing to open a support request.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

Periodic Backup

2026-10-26T15:07:41Z

Anko: Recreated DP-420 term page: Periodic Backup (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Original backup mode; scheduled snapshots, typically restored via a support request.

== Overview ==
Periodic backup is Azure Cosmos DB's original backup mode, which automatically takes backups of the account at a configurable interval (default every 4 hours) and retains a configurable number of backups, allowing restoration of an entire account to a previous backup point — typically requiring a support request to restore, and offering less granularity than continuous backup.

'''Exam shortcut:''' "Where are Periodic Backup backups stored by default?" → In the write region and geo-replicated to the Azure paired region (GRS).

* Periodic Backup → Contact Microsoft/Azure Support ✅
* Continuous Backup → Use self-service restore (RBAC permissions required) ✅

<pre>
| Backup type | CosmosRestoreOperator needed? |
| ----------- | ----------------------------- |
| Periodic | **No** |
| Continuous | **Yes** |
</pre>

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/periodic-backup-restore-introduction Microsoft Learn: Periodic backup mode]

== DP-420 Style Practice Questions ==
'''Q1.''' How does periodic backup mode restore data?
* A. By restoring from the most recent scheduled backup snapshot, typically via a support request
* B. Automatically, to any exact second within the retention window, without support involvement
* C. Only by exporting a manual snapshot triggered by the developer
* D. By replaying the change feed from the beginning

'''Q2.''' What is a key limitation of periodic backup compared to continuous backup?
* A. Restores are limited to the granularity of the scheduled backup interval, not an exact point in time
* B. Periodic backup cannot be configured with any retention period
* C. Periodic backup only works with the MongoDB API
* D. Periodic backup requires multi-region writes to be enabled

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Periodic Backup):''' A. By restoring from the most recent scheduled backup snapshot, typically via a support request — Periodic backup restores from scheduled backup snapshots and traditionally requires contacting support to initiate.
* '''Q2 (Periodic Backup):''' A. Restores are limited to the granularity of the scheduled backup interval, not an exact point in time — Periodic backup only allows restoring to backup snapshot points, unlike continuous backup's fine-grained point-in-time restore.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

KQL (Kusto Query Language)

2026-10-26T15:07:41Z

Anko: Recreated DP-420 term page: KQL (Kusto Query Language) (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Query language used in Azure Monitor Log Analytics to analyze Cosmos DB diagnostic logs and metrics.

== Overview ==
KQL (Kusto Query Language) is the read-only query language used to explore, analyze, and aggregate telemetry and diagnostic data in Azure Monitor Log Analytics, Azure Data Explorer, and Microsoft Fabric Real-Time Intelligence. In the context of Azure Cosmos DB and the DP-420 exam, KQL is used to query diagnostic log tables — such as CDBDataPlaneRequests, CDBQueryRuntimeStatistics, CDBPartitionKeyRUConsumption, and CDBControlPlaneRequests (or legacy AzureDiagnostics) — to analyze RU consumption patterns, troubleshoot HTTP 429 throttling errors, identify hot partitions, and pinpoint high-cost or slow queries. KQL queries are built using a pipeline model where data flows from left to right through tabular operators separated by the pipe (|) character, such as where, project, summarize, join, order by, and render.

Example 1 (KQL): Find operations throttled with HTTP 429 status code

<pre>
CDBDataPlaneRequests
| where TimeGenerated > ago(24h)
| where StatusCode == 429
| summarize Count429 = count() by bin(TimeGenerated, 5m), OperationName, PartitionKey
| order by Count429 desc
</pre>

This query identifies requests that were rate-limited (HTTP 429) across 5-minute intervals in the last 24 hours, grouping by operation and partition key to isolate hot partitions causing throttling.

Example 2 (KQL): Correlate high RU queries with query text

<pre>
CDBDataPlaneRequests
| where TimeGenerated > ago(1h) and todouble(RequestCharge) > 50.0
| project TimeGenerated, ActivityId, RequestCharge, DurationMs
| join kind=inner (
CDBQueryRuntimeStatistics
| project ActivityId, QueryText
) on $left.ActivityId == $right.ActivityId
| order by RequestCharge desc
| limit 20
</pre>

This query correlates request execution telemetry from <code>CDBDataPlaneRequests</code> with query text from <code>CDBQueryRuntimeStatistics</code> via <code>ActivityId</code> to find the top 20 most expensive queries.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/log-analytics/tutorial-kql Microsoft Learn: Tutorial - Write KQL queries to monitor Azure Cosmos DB]
* [https://learn.microsoft.com/en-us/azure/data-explorer/kusto/query/ Microsoft Learn: Overview of Kusto Query Language (KQL)]
* [https://learn.microsoft.com/en-us/azure/cosmos-db/monitor-resource-logs Microsoft Learn: Monitor and troubleshoot Azure Cosmos DB using diagnostic logs]

== DP-420 Style Practice Questions ==
'''Q1.''' What is the primary role of KQL (Kusto Query Language) in Azure Cosmos DB operations and troubleshooting?
* A. Querying and analyzing diagnostic logs and metrics in Azure Monitor Log Analytics to troubleshoot issues like throttling, hot partitions, and expensive queries
* B. Defining server-side stored procedures and triggers directly in Cosmos DB containers
* C. Querying JSON documents via the Cosmos DB API for NoSQL endpoint
* D. Creating and managing Cosmos DB indexing policies declaratively

'''Q2.''' In a KQL query for Azure Cosmos DB logs, what does the pipe (|) operator represent?
* A. It pipes the tabular output of the preceding operator as the input to the next operator in a data-flow pipeline
* B. It performs a logical bitwise OR between two numeric fields
* C. It defines a primary key constraint on the diagnostic table
* D. It separates alternative partition key values in a point read

'''Q3.''' Which resource-specific table would you query using KQL to inspect RU charges and HTTP status codes for individual data operations?
* A. CDBDataPlaneRequests
* B. CDBControlPlaneRequests
* C. CDBPartitionKeyStatistics
* D. AzureMetrics

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (KQL (Kusto Query Language)):''' A. Querying and analyzing diagnostic logs and metrics in Azure Monitor Log Analytics to troubleshoot issues like throttling, hot partitions, and expensive queries — KQL is the read-only query language for Azure Monitor Log Analytics used to analyze diagnostic logs like CDBDataPlaneRequests and CDBPartitionKeyRUConsumption.
* '''Q2 (KQL (Kusto Query Language)):''' A. It pipes the tabular output of the preceding operator as the input to the next operator in a data-flow pipeline — KQL uses the pipe (|) operator to pass data sequentially from one tabular expression/operator to another (e.g., filtering with where, then aggregating with summarize).
* '''Q3 (KQL (Kusto Query Language)):''' A. CDBDataPlaneRequests — CDBDataPlaneRequests logs individual data-plane operations along with RequestCharge, StatusCode, DurationMs, and ActivityId.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

DataPlaneRequests (Diagnostic Log)

2026-10-26T15:07:41Z

Anko: Recreated DP-420 term page: DataPlaneRequests (Diagnostic Log) (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Logs item-level create/read/replace/delete/query operations with RU charge and duration.

== Overview ==
DataPlaneRequests is a diagnostic log table that logs individual data-plane operations — such as item creates, reads, replaces, deletes, and queries — executed against an Azure Cosmos DB for NoSQL account, including details like RU charge, status code, and duration per request. It complements ControlPlaneRequests (which logs account-level administrative operations) by giving request-level visibility into the actual application traffic hitting the account, useful for deep troubleshooting of latency, throttling (429s), or unexpected RU charges. In Log Analytics, this table is exposed under the name CDBDataPlaneRequests.

Example (KQL): Find the most expensive queries and their text

<pre>
CDBDataPlaneRequests
| where todouble(RequestCharge) > 10.0
| project ActivityId, RequestCharge
| join kind=inner (
CDBQueryRuntimeStatistics
| project ActivityId, QueryText
) on $left.ActivityId == $right.ActivityId
| order by RequestCharge desc
| limit 100
</pre>

This query joins <code>CDBDataPlaneRequests</code> (RU charge per request) with <code>CDBQueryRuntimeStatistics</code> (the query text) on the shared <code>ActivityId</code>, filters for requests costing more than 10 RUs, and returns the 100 most expensive queries together with their full query text — a common first step when troubleshooting unexpectedly high RU consumption.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/monitor-resource-logs Microsoft Learn: Monitor and troubleshoot using diagnostic logs]

== DP-420 Style Practice Questions ==
'''Q1.''' What does the DataPlaneRequests diagnostic log table capture?
* A. Individual item-level operations (create, read, replace, delete, query) with details like RU charge and duration
* B. Account-level operations such as adding or removing regions
* C. Aggregated per-second RU consumption by partition key
* D. Estimated logical partition storage size

'''Q2.''' How does DataPlaneRequests differ from ControlPlaneRequests?
* A. DataPlaneRequests logs item-level operations (application traffic), while ControlPlaneRequests logs account-level administrative operations
* B. DataPlaneRequests only logs failed requests, while ControlPlaneRequests logs successful ones
* C. DataPlaneRequests is only available for the MongoDB API
* D. There is no difference; they are aliases for the same table

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (DataPlaneRequests (Diagnostic Log)):''' A. Individual item-level operations (create, read, replace, delete, query) with details like RU charge and duration — DataPlaneRequests logs per-request data-plane operation details, including RU charge, status code, and duration.
* '''Q2 (DataPlaneRequests (Diagnostic Log)):''' A. DataPlaneRequests logs item-level operations (application traffic), while ControlPlaneRequests logs account-level administrative operations — DataPlaneRequests covers item-level read/write/query operations, whereas ControlPlaneRequests covers account/administrative changes.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

ControlPlaneRequests (Diagnostic Log)

2026-10-26T15:07:40Z

Anko: Recreated DP-420 term page: ControlPlaneRequests (Diagnostic Log) (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Logs account control-plane operations, e.g. adding/removing replication regions.

== Overview ==
ControlPlaneRequests is a diagnostic log table that logs control-plane operations performed against an Azure Cosmos DB for NoSQL account — such as adding or removing regions in the replication settings, updating throughput, or changing account-level configuration — as opposed to data-plane operations (item reads/writes). It is useful for auditing administrative changes to the account over time.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/monitor-resource-logs Microsoft Learn: Monitor and troubleshoot using diagnostic logs]

== DP-420 Style Practice Questions ==
'''Q1.''' What kind of operations does the ControlPlaneRequests diagnostic log table capture?
* A. Account-level control-plane operations, such as adding or removing replication regions
* B. Item-level read and write operations
* C. Query execution statistics
* D. Change feed processor checkpoints

'''Q2.''' Why would you consult ControlPlaneRequests logs?
* A. To audit administrative changes such as region additions/removals or throughput updates over time
* B. To find which query consumed the most RUs
* C. To find which partition key is a hot partition
* D. To check TTL expiration events on items

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (ControlPlaneRequests (Diagnostic Log)):''' A. Account-level control-plane operations, such as adding or removing replication regions — ControlPlaneRequests captures control-plane (account/administrative) operations, distinct from data-plane item operations.
* '''Q2 (ControlPlaneRequests (Diagnostic Log)):''' A. To audit administrative changes such as region additions/removals or throughput updates over time — This table is used to audit account-level configuration changes, which is distinct from data-plane monitoring tables.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

QueryRuntimeStatistics (Diagnostic Log)

2026-10-26T15:07:40Z

Anko: Recreated DP-420 term page: QueryRuntimeStatistics (Diagnostic Log) (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Logs query operations against the account for query performance analysis.

== Overview ==
QueryRuntimeStatistics is a diagnostic log table that logs query operations executed against an Azure Cosmos DB for NoSQL account, including details useful for analyzing query text, RU charge, and execution performance. It is commonly used alongside query metrics to identify expensive or inefficient queries that may benefit from indexing policy or query rewrites. In Log Analytics, this table is exposed under the name CDBQueryRuntimeStatistics.

Example (KQL): Find the most expensive queries and their text

<pre>
CDBDataPlaneRequests
| where todouble(RequestCharge) > 10.0
| project ActivityId, RequestCharge
| join kind=inner (
CDBQueryRuntimeStatistics
| project ActivityId, QueryText
) on $left.ActivityId == $right.ActivityId
| order by RequestCharge desc
| limit 100
</pre>

This query joins <code>CDBDataPlaneRequests</code> (RU charge per request) with <code>CDBQueryRuntimeStatistics</code> (the query text) on the shared <code>ActivityId</code>, filters for requests costing more than 10 RUs, and returns the 100 most expensive queries together with their full query text — a common first step when troubleshooting unexpectedly high RU consumption.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/monitor-resource-logs Microsoft Learn: Monitor and troubleshoot using diagnostic logs]

== DP-420 Style Practice Questions ==
'''Q1.''' What does the QueryRuntimeStatistics diagnostic log table capture?
* A. Details of query operations run against an Azure Cosmos DB for NoSQL account
* B. Per-partition storage size in KB
* C. Control-plane operations like adding a region
* D. Change feed consumer lag

'''Q2.''' Why would you review QueryRuntimeStatistics during optimization?
* A. To identify expensive or inefficient queries that might need indexing policy changes or rewrites
* B. To determine which partition key value has the most storage
* C. To check which regions accept writes
* D. To view the account's backup retention window

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (QueryRuntimeStatistics (Diagnostic Log)):''' A. Details of query operations run against an Azure Cosmos DB for NoSQL account — QueryRuntimeStatistics logs details about queries executed against the account, useful for query performance analysis.
* '''Q2 (QueryRuntimeStatistics (Diagnostic Log)):''' A. To identify expensive or inefficient queries that might need indexing policy changes or rewrites — This table helps surface costly or slow queries so their indexing policy or query text can be optimized.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

PartitionKeyStatistics (Diagnostic Log)

2026-10-26T15:07:39Z

Anko: Recreated DP-420 term page: PartitionKeyStatistics (Diagnostic Log) (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Estimated storage size (KB) per logical partition key; flags storage skew.

== Overview ==
PartitionKeyStatistics is a diagnostic log table that logs logical partition key statistics in estimated KB, showing the approximate storage size consumed by each partition key value. It is the primary tool for troubleshooting storage skew — where one or a few partition key values approach the 20 GB logical partition storage limit while others remain nearly empty.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/monitor-resource-logs Microsoft Learn: Monitor and troubleshoot using diagnostic logs]

== DP-420 Style Practice Questions ==
'''Q1.''' What does the PartitionKeyStatistics diagnostic log table report?
* A. Estimated storage size (in KB) consumed by each logical partition key value
* B. Per-second RU/s consumption per partition key
* C. The account's consistency level history
* D. The list of regions enabled for multi-region writes

'''Q2.''' What problem is PartitionKeyStatistics most useful for troubleshooting?
* A. Storage skew, where some partition key values approach the logical partition storage limit
* B. Query RU cost estimation
* C. Change feed processor lag
* D. 429 throttling error rates

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (PartitionKeyStatistics (Diagnostic Log)):''' A. Estimated storage size (in KB) consumed by each logical partition key value — PartitionKeyStatistics reports estimated storage size per partition key, in KB.
* '''Q2 (PartitionKeyStatistics (Diagnostic Log)):''' A. Storage skew, where some partition key values approach the logical partition storage limit — This table helps identify storage skew by showing which partition key values are approaching the 20 GB logical partition limit.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

PartitionKeyRUConsumption (Diagnostic Log)

2026-10-26T15:07:39Z

Anko: Recreated DP-420 term page: PartitionKeyRUConsumption (Diagnostic Log) (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Per-second RU/s consumption per partition key; pinpoints hot partitions.

== Overview ==
PartitionKeyRUConsumption is a diagnostic log table (available through Azure Monitor resource-specific diagnostic logs) that logs every second's aggregated RU/s consumption per partition key. It is the go-to table for troubleshooting hot partitions, letting you pinpoint exactly which partition key values are consuming a disproportionate share of throughput, which the higher-level Normalized RU Consumption metric can only show at the partition level.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/monitor-resource-logs Microsoft Learn: Monitor and troubleshoot using diagnostic logs]

== DP-420 Style Practice Questions ==
'''Q1.''' What does the PartitionKeyRUConsumption diagnostic log table record?
* A. Per-second aggregated RU/s consumption for each partition key
* B. The total storage size of each logical partition
* C. The list of composite indexes defined on a container
* D. Control-plane operations such as adding a region

'''Q2.''' Which troubleshooting scenario is PartitionKeyRUConsumption best suited for?
* A. Identifying a hot partition by pinpointing which partition key values consume disproportionate RUs
* B. Identifying skewed logical partition storage size
* C. Auditing control-plane changes like region additions
* D. Estimating change feed processing lag

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (PartitionKeyRUConsumption (Diagnostic Log)):''' A. Per-second aggregated RU/s consumption for each partition key — PartitionKeyRUConsumption logs per-second RU/s consumption aggregated by partition key value.
* '''Q2 (PartitionKeyRUConsumption (Diagnostic Log)):''' A. Identifying a hot partition by pinpointing which partition key values consume disproportionate RUs — This table is specifically designed to help diagnose hot partitions by exposing per-partition-key RU consumption over time.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

Normalized RU Consumption

2026-10-26T15:07:38Z

Anko: Recreated DP-420 term page: Normalized RU Consumption (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Azure Monitor metric showing % of provisioned throughput used; flags hot partitions.

== Overview ==
Normalized RU Consumption is an Azure Monitor metric that reports the percentage of provisioned throughput being utilized by a container or partition over a given period, helping identify hot partitions (nearing 100%) or under-provisioned/over-provisioned throughput, without needing to manually calculate raw RU usage against the provisioned amount.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/monitor-normalized-request-units Microsoft Learn: Monitor Normalized RU Consumption]

== DP-420 Style Practice Questions ==
'''Q1.''' What does the Normalized RU Consumption metric represent?
* A. The percentage of provisioned throughput being consumed by a container or partition
* B. The total number of documents stored
* C. The number of regions data is replicated to
* D. The number of indexed properties

'''Q2.''' A partition consistently showing Normalized RU Consumption near 100% likely indicates what?
* A. A hot partition that may be throttling requests and could benefit from better partition key distribution
* B. The partition key is optimally distributed
* C. TTL needs to be enabled
* D. The consistency level should be lowered

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Normalized RU Consumption):''' A. The percentage of provisioned throughput being consumed by a container or partition — Normalized RU Consumption shows RU usage as a percentage of the provisioned throughput, making hot partitions easy to spot.
* '''Q2 (Normalized RU Consumption):''' A. A hot partition that may be throttling requests and could benefit from better partition key distribution — Consistently high normalized RU consumption on a partition signals a hot partition at risk of throttling (429s).

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

Alerts

2026-10-26T15:07:38Z

Anko: Recreated DP-420 term page: Alerts (Maintenance & Security)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Maintenance & Security

'''Summary:''' Cosmo DB alerts

== Overview ==
''[Image: dataUsageAlert.png (Alerts)]''

* Split by dimension: Use dimensions to monitor specific time series and provide context to the fired alert.
* Aggregate type: There are five basic aggregation types available in the metrics explorer (Sum, Count, Average, Min, and Max).
* Threshold: This is used to evaluate an alert firming condition rule and can either be Static and Dynamic.
* Unit: This specifies the threshold unit.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/conceptual-resilient-sdk-applications Microsoft Learn: Handling rate limiting / request rate too large]

== DP-420 Style Practice Questions ==
'''Q1.''' What does a 429 error from Azure Cosmos DB typically indicate?
* A. The request was throttled because provisioned throughput (RU/s) was exceeded
* B. The requested item does not exist
* C. An authentication failure occurred
* D. A conflict occurred during multi-region writes

'''Q2.''' Which of these could help reduce the frequency of 429 errors?
* A. Improving partition key distribution to avoid hot partitions, or increasing provisioned RU/s
* B. Disabling the SDK's automatic retry policy
* C. Switching to gateway mode exclusively
* D. Reducing the number of properties indexed

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (429 Throttling Error):''' A. The request was throttled because provisioned throughput (RU/s) was exceeded — A 429 status code means the request rate exceeded the provisioned RU/s, triggering throttling.
* '''Q2 (429 Throttling Error):''' A. Improving partition key distribution to avoid hot partitions, or increasing provisioned RU/s — Better partition key distribution and/or higher provisioned throughput both help reduce 429 throttling errors.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Maintenance & Security]]

Change Feed Estimator

2026-10-26T15:07:38Z

Anko: Recreated DP-420 term page: Change Feed Estimator (Optimization)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Optimization

'''Summary:''' Reports pending change feed lag to help decide when to scale out consumer instances.

== Overview ==
The change feed estimator is a tool provided by the Azure Cosmos DB SDK's change feed processor that reports how many changes are pending to be processed (the 'lag') by change feed consumers, helping you determine whether you need to scale out the number of change feed processor instances to keep up with the rate of incoming changes.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/how-to-use-change-feed-estimator Microsoft Learn: Change feed estimator]

== DP-420 Style Practice Questions ==
'''Q1.''' What does the change feed estimator help you determine?
* A. How many unprocessed changes ('lag') remain, to decide if you should scale out consumer instances
* B. The RU cost of a specific query
* C. The consistency level of the account
* D. The maximum logical partition size

'''Q2.''' What might a growing lag reported by the change feed estimator indicate?
* A. Consumers are falling behind and may need additional change feed processor instances
* B. The container's indexing policy is misconfigured
* C. The partition key needs to be changed
* D. TTL is about to expire on many items

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Change Feed Estimator):''' A. How many unprocessed changes ('lag') remain, to decide if you should scale out consumer instances — The change feed estimator reports the backlog of unprocessed changes, guiding scale-out decisions for consumers.
* '''Q2 (Change Feed Estimator):''' A. Consumers are falling behind and may need additional change feed processor instances — A growing lag suggests the current number of change feed processor instances is insufficient to keep pace with incoming changes.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Optimization]]

Integrated Cache

2026-10-26T15:07:37Z

Anko: Recreated DP-420 term page: Integrated Cache (Optimization)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Optimization

'''Summary:''' In-memory caching layer (via dedicated gateway) reducing RU cost/latency for repeated reads.

== Overview ==
The Azure Cosmos DB integrated cache is an in-memory caching layer, provisioned via a dedicated gateway, that automatically caches the results of point reads and queries to reduce RU consumption and latency for repeated read operations, without requiring changes to application query logic.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/integrated-cache Microsoft Learn: Azure Cosmos DB integrated cache]

== DP-420 Style Practice Questions ==
'''Q1.''' What is the main benefit of enabling the Azure Cosmos DB integrated cache?
* A. Reduced RU consumption and latency for repeated point reads and queries
* B. Automatic multi-region writes
* C. Stronger consistency guarantees than Strong consistency
* D. Elimination of the need for an indexing policy

'''Q2.''' What Azure Cosmos DB component is required to use the integrated cache?
* A. A dedicated gateway
* B. A stored procedure
* C. A synthetic partition key
* D. A composite index

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Integrated Cache):''' A. Reduced RU consumption and latency for repeated point reads and queries — The integrated cache reduces RU cost and latency by serving repeated reads/queries from an in-memory cache.
* '''Q2 (Integrated Cache):''' A. A dedicated gateway — The integrated cache is provisioned through a dedicated gateway deployment.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Optimization]]

Wildcard / Included & Excluded Paths

2026-10-26T15:07:37Z

Anko: Recreated DP-420 term page: Wildcard / Included & Excluded Paths (Optimization)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Optimization

'''Summary:''' Path expressions (with optional /* wildcard) controlling exactly which properties are indexed.

== Overview ==
Indexing policies use included and excluded path expressions — optionally with a wildcard (/*) — to control precisely which properties (and nested properties) are indexed. A wildcard path like /properties/*/? indexes an entire subtree, while explicit exclusions (e.g., large or rarely-queried properties) reduce write RU cost and storage without a full custom rewrite of the policy for every property.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/index-policy Microsoft Learn: Indexing policies in Azure Cosmos DB]

== DP-420 Style Practice Questions ==
'''Q1.''' What does a wildcard (/*) in an indexing policy path expression represent?
* A. The entire subtree of properties beneath that path
* B. Only the partition key property
* C. A single specific property, never nested ones
* D. A reference to a composite index

'''Q2.''' Why would you add a property to the excludedPaths of an indexing policy?
* A. To reduce write RU cost and storage by skipping indexing of that property
* B. To make the property queryable with ORDER BY
* C. To enable geospatial queries on that property
* D. To enforce a unique key constraint on that property

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Wildcard / Included & Excluded Paths):''' A. The entire subtree of properties beneath that path — A wildcard path expression like /path/* indexes every property in the subtree rooted at that path.
* '''Q2 (Wildcard / Included & Excluded Paths):''' A. To reduce write RU cost and storage by skipping indexing of that property — Excluding a path from indexing avoids the write overhead of maintaining an index for properties that aren't queried.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Optimization]]

Vector Index

2026-10-26T15:07:36Z

Anko: Recreated DP-420 term page: Vector Index (Optimization)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Optimization

'''Summary:''' Enables approximate nearest-neighbor similarity search over embeddings for AI/RAG scenarios.

== Overview ==
A vector index enables efficient approximate nearest-neighbor (ANN) similarity search over high-dimensional vector embeddings stored directly in Azure Cosmos DB items — powering AI scenarios such as retrieval-augmented generation (RAG) without needing a separate vector database. Azure Cosmos DB for NoSQL supports vector index types such as flat, quantizedFlat, and DiskANN, configured via a vector embedding policy alongside the container's indexing policy.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/vector-search Microsoft Learn: Vector search in Azure Cosmos DB for NoSQL]

== DP-420 Style Practice Questions ==
'''Q1.''' What is the primary purpose of a vector index in Azure Cosmos DB?
* A. Efficient approximate nearest-neighbor similarity search over vector embeddings for AI/RAG scenarios
* B. Enforcing uniqueness of a property across a logical partition
* C. Sorting items by their partition key
* D. Accelerating geospatial distance calculations

'''Q2.''' Which of the following is a supported vector index type in Azure Cosmos DB for NoSQL?
* A. DiskANN
* B. Composite
* C. Wildcard
* D. Hash

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Vector Index):''' A. Efficient approximate nearest-neighbor similarity search over vector embeddings for AI/RAG scenarios — Vector indexes enable fast similarity search over embeddings, supporting AI workloads like retrieval-augmented generation.
* '''Q2 (Vector Index):''' A. DiskANN — Azure Cosmos DB for NoSQL supports vector index types including flat, quantizedFlat, and DiskANN.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Optimization]]

Composite Index

2026-10-26T15:07:36Z

Anko: Recreated DP-420 term page: Composite Index (Optimization)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Optimization

'''Summary:''' Index across multiple properties to support efficient multi-property filter/sort queries.

== Overview ==
A composite index is an index defined across multiple properties (in a specified order and sort direction) to efficiently support queries that filter or sort on more than one property at once — such as an ORDER BY across two properties, or equality/range filters combined with a sort. Without an appropriate composite index, such queries may require more RUs or fail to use the index efficiently.

<pre>
{
"indexingMode": "consistent",
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": [
{
"path": "/_etag/?"
}
],
"compositeIndexes": [
[
{
"path": "/category/?",
"order": "ascending"
},
{
"path": "/timestamp/?",
"order": "descending"
}
]
]
}
</pre>

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/index-policy#composite-indexes Microsoft Learn: Composite indexes]

== DP-420 Style Practice Questions ==
'''Q1.''' When is a composite index particularly useful in Azure Cosmos DB?
* A. When a query filters or sorts (ORDER BY) on multiple properties simultaneously
* B. When a container has only one property in every document
* C. When TTL is enabled
* D. When using only point operations

'''Q2.''' What must be specified when defining a composite index?
* A. The set of properties and their sort order (ascending/descending)
* B. Only the partition key
* C. The container's throughput mode
* D. The consistency level

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Composite Index):''' A. When a query filters or sorts (ORDER BY) on multiple properties simultaneously — Composite indexes optimize queries that need efficient filtering or ordering across multiple properties at once.
* '''Q2 (Composite Index):''' A. The set of properties and their sort order (ascending/descending) — A composite index definition specifies the ordered list of properties along with ascending/descending sort order for each.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Optimization]]

Spatial Index

2026-10-26T15:07:36Z

Anko: Recreated DP-420 term page: Spatial Index (Optimization)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Optimization

'''Summary:''' Accelerates geospatial queries (ST_DISTANCE, ST_WITHIN) over GeoJSON properties.

== Overview ==
A spatial index supports efficient execution of geospatial queries — such as ST_DISTANCE, ST_WITHIN, and ST_INTERSECTS — over properties containing GeoJSON data (e.g., Point, Polygon, LineString). Spatial indexes are applied automatically to properties recognized as GeoJSON when using the default indexing policy, enabling location-based queries like 'find all items within X kilometers of a point'.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/geospatial-query Microsoft Learn: Query geospatial data]

== DP-420 Style Practice Questions ==
'''Q1.''' What kind of queries does a spatial index accelerate in Azure Cosmos DB?
* A. Geospatial queries such as proximity (ST_DISTANCE) and containment (ST_WITHIN) over GeoJSON data
* B. Full-text search queries
* C. Vector similarity search queries
* D. Aggregate queries such as COUNT and SUM

'''Q2.''' What data format must a property use to benefit from a spatial index?
* A. GeoJSON (e.g., Point, Polygon, LineString)
* B. XML
* C. A composite of two numeric properties
* D. A base64-encoded binary blob

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Spatial Index):''' A. Geospatial queries such as proximity (ST_DISTANCE) and containment (ST_WITHIN) over GeoJSON data — Spatial indexes accelerate geospatial functions like ST_DISTANCE, ST_WITHIN, and ST_INTERSECTS over GeoJSON properties.
* '''Q2 (Spatial Index):''' A. GeoJSON (e.g., Point, Polygon, LineString) — Spatial indexes apply to properties containing valid GeoJSON data types such as Point, Polygon, and LineString.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Optimization]]

Range Index

2026-10-26T15:07:35Z

Anko: Recreated DP-420 term page: Range Index (Optimization)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Optimization

'''Summary:''' Default index type for string/numeric properties; supports equality, range, and ORDER BY.

== Overview ==
A range index is the default index type Azure Cosmos DB applies to string and numeric properties, storing values in a sorted (B-tree-like) structure that efficiently supports equality (=), range (>, <,>=, <=), ORDER BY, and JOIN queries on that property. Because the default indexing policy indexes every property with a range index automatically, most queries work efficiently out of the box without any manual index tuning.

<pre>
//old way of authenticating
//new CosmosClient(endpoint, accountKey)
//new way of authenticating
-> new CosmosClient(endpoint, new DefaultAzureCredential());
</pre>

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/index-policy Microsoft Learn: Indexing policies in Azure Cosmos DB]

== DP-420 Style Practice Questions ==
'''Q1.''' What is the default index type applied to string and numeric properties in Azure Cosmos DB?
* A. Range index
* B. Spatial index
* C. Composite index
* D. Hash index

'''Q2.''' Which query types does a range index efficiently support?
* A. Equality, range comparisons, and ORDER BY on the indexed property
* B. Only geospatial proximity searches
* C. Only vector similarity searches
* D. Only queries against the partition key

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Range Index):''' A. Range index — Range indexes are applied by default to string and numeric properties and support equality, range, and ORDER BY queries.
* '''Q2 (Range Index):''' A. Equality, range comparisons, and ORDER BY on the indexed property — A range index supports equality, range (>, <,>=, <=), ORDER BY, and JOIN operations on the indexed property.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Optimization]]

Indexing Policy

2026-10-26T15:07:35Z

Anko: Recreated DP-420 term page: Indexing Policy (Optimization)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Optimization

'''Summary:''' Defines which properties are indexed, trading off query performance vs. write RU cost.

== Overview ==
An indexing policy defines which properties of items in a container are indexed and how, controlling the trade-off between query performance (read efficiency) and write RU cost/storage (since more indexed paths mean more write overhead). By default, Azure Cosmos DB automatically indexes every property, but you can customize the policy to include/exclude specific paths, favoring either a read-heavy or write-heavy workload.

<pre>
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*"
}
],
"excludedPaths": [
{
"path": "/\"_etag\"/?"
}
]
}
</pre>

<pre>
var containerDefinition = new ContainerDefinition
{
Id = "Products",
PartitionKeyPath = "/category",
IndexingPolicy = new IndexingPolicy
{
Automatic = true,
IndexingMode = IndexingMode.Consistent,
IncludedPaths =
{
new IncludedPath { Path = "/*" } // Optional when automatic is true
},
ExcludedPaths =
{
new ExcludedPath { Path = "/description/*" } // Exclude description
}
}
};
</pre>

<pre>
string sqlQueryText = "SELECT TOP 10 c.id FROM c WHERE c.Item = 'value1234' AND c.Price > 2";

QueryDefinition query = new QueryDefinition(sqlQueryText);

FeedIterator resultSetIterator = container.GetItemQueryIterator(
query, requestOptions: new QueryRequestOptions
{
PopulateIndexMetrics = true
});

FeedResponse response = null;

while (resultSetIterator.HasMoreResults)
{
response = await resultSetIterator.ReadNextAsync();
Console.WriteLine(response.IndexMetrics);
}

</pre>

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/index-policy Microsoft Learn: Indexing policies in Azure Cosmos DB]

== DP-420 Style Practice Questions ==
'''Q1.''' What is indexed by default in a new Azure Cosmos DB for NoSQL container?
* A. Every property of every item, using the default automatic indexing policy
* B. No properties, until explicitly configured
* C. Only the partition key property
* D. Only properties marked as unique keys

'''Q2.''' Why might you exclude certain paths from indexing in a write-heavy workload?
* A. To reduce the RU cost and latency of write operations by avoiding unnecessary index maintenance
* B. To increase the maximum logical partition size
* C. To enable multi-region writes
* D. To allow TTL to be configured

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Indexing Policy):''' A. Every property of every item, using the default automatic indexing policy — By default, Azure Cosmos DB automatically indexes all properties unless a custom indexing policy excludes some paths.
* '''Q2 (Indexing Policy):''' A. To reduce the RU cost and latency of write operations by avoiding unnecessary index maintenance — Excluding unused paths from indexing reduces the RU cost of writes, which is valuable for write-heavy workloads.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Optimization]]

Azure AI Search Integration

2026-10-26T15:07:35Z

Anko: Recreated DP-420 term page: Azure AI Search Integration (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' Indexer pulls Cosmos DB data (via change feed) to enable full-text/semantic search.

== Overview ==
Azure Cosmos DB integrates with Azure AI Search to enable full-text and semantic search over Cosmos DB data by configuring an Azure AI Search indexer that pulls data from a Cosmos DB container (often via the change feed for incremental indexing), so applications can perform rich search queries beyond what Cosmos DB's native query capabilities provide.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/search/search-howto-index-cosmosdb Microsoft Learn: Index data from Azure Cosmos DB with Azure AI Search]

== DP-420 Style Practice Questions ==
'''Q1.''' Why would you integrate Azure Cosmos DB with Azure AI Search?
* A. To enable rich full-text/semantic search capabilities over Cosmos DB data beyond native query features
* B. To enable multi-region writes
* C. To reduce RU consumption on point operations
* D. To enforce unique key constraints

'''Q2.''' How does an Azure AI Search indexer typically stay up to date with changes in a Cosmos DB container?
* A. By leveraging the change feed for incremental indexing
* B. By performing a full container scan on every search query
* C. By requiring manual re-indexing after every write
* D. By using a stored procedure triggered per search request

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Azure AI Search Integration):''' A. To enable rich full-text/semantic search capabilities over Cosmos DB data beyond native query features — Azure AI Search adds full-text and semantic search capabilities over data stored in Azure Cosmos DB.
* '''Q2 (Azure AI Search Integration):''' A. By leveraging the change feed for incremental indexing — Azure AI Search indexers can use the change feed to efficiently and incrementally pick up new/updated items.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

Azure Logic Apps

2026-10-26T15:07:34Z

Anko: Recreated DP-420 term page: Azure Logic Apps (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' Low-code cloud workflow automation service integrating with Cosmos DB via connectors, triggers, and actions.

== Overview ==
Azure Logic Apps is a cloud-based serverless workflow and orchestration service that enables building automated, low-code/no-code business processes and enterprise integrations. With the Azure Cosmos DB connector, Logic Apps provides managed triggers (such as 'When an item is created or modified (V2)', powered by the Cosmos DB change feed) and numerous actions (including create or update document, read document, query documents with SQL, and delete document). In the DP-420 exam, Logic Apps is contrasted with Azure Functions: choose Logic Apps for visual, declarative orchestration connecting Cosmos DB to SaaS platforms, Office 365, or multi-step enterprise workflows without writing custom code; choose Azure Functions when complex code transformations, high-throughput microservices, or custom business logic are required.

Example (Logic Apps Workflow Definition): Change Feed Trigger with Automated Action

<pre>
"triggers": {
"When_items_are_created_or_modified": {
"type": "ServiceProvider",
"inputs": {
"parameters": {
"databaseName": "ecommerce",
"containerName": "orders"
},
"serviceProviderConfiguration": {
"connectionName": "serviceProviderConnections/azureCosmosDB",
"operationId": "whenItemsAreCreatedOrModified"
}
}
}
},
"actions": {
"Send_Email_Notification": {
"type": "ApiConnection",
"inputs": {
"host": { "connection": { "referenceName": "office365" } },
"method": "post",
"path": "/v2/Mail",
"body": {
"To": "ops@example.com",
"Subject": "New High-Priority Order Received",
"Body": "Order @{triggerBody()?['id']} was placed for customer @{triggerBody()?['customerId']}."
}
}
}
}
</pre>

This workflow automatically triggers when items change in the Cosmos DB <code>orders</code> container and executes an Office 365 action to notify operations — achieving event-driven enterprise integration without maintaining custom server infrastructure or code.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/connectors/connectors-create-api-cosmos-db Microsoft Learn: Connect to Azure Cosmos DB from workflows in Azure Logic Apps]
* [https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-overview Microsoft Learn: Overview of Azure Logic Apps]
* [https://learn.microsoft.com/en-us/azure/azure-functions/functions-compare-logic-apps-ms-flow-webjobs Microsoft Learn: Compare Azure Functions and Azure Logic Apps]

== DP-420 Style Practice Questions ==
'''Q1.''' When should you choose Azure Logic Apps over Azure Functions to integrate with Azure Cosmos DB?
* A. When building low-code, visual workflow orchestrations and integrating with enterprise SaaS services like Salesforce or Office 365
* B. When sub-millisecond custom compute and high-frequency algorithms are required
* C. When you need to define custom composite indexing policies
* D. When executing JavaScript stored procedures inside a logical partition

'''Q2.''' What enables Azure Logic Apps to trigger automated workflows based on new or updated documents in Cosmos DB?
* A. The Azure Cosmos DB connector's change feed trigger ('When an item is created or modified')
* B. Continuous backup point-in-time restore log polling
* C. Cosmos DB Operator ARM role events exclusively
* D. Diagnostic log ingestion into Log Analytics workspaces

'''Q3.''' Which capability is provided by the Azure Cosmos DB connector actions within Azure Logic Apps?
* A. Reading, creating/updating, querying with SQL, and deleting documents within Cosmos DB containers
* B. Provisioning physical partition hardware and rebalancing storage manually
* C. Overriding the 20 GB logical partition storage limit
* D. Running analytical queries without enabling Azure Synapse Link

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Azure Logic Apps):''' A. When building low-code, visual workflow orchestrations and integrating with enterprise SaaS services like Salesforce or Office 365 — Azure Logic Apps is designed for visual, declarative workflow orchestrations and out-of-the-box SaaS connectors, whereas Azure Functions is designed for custom code execution.
* '''Q2 (Azure Logic Apps):''' A. The Azure Cosmos DB connector's change feed trigger ('When an item is created or modified') — The Cosmos DB connector in Logic Apps uses the change feed trigger to execute workflows whenever documents are created or updated.
* '''Q3 (Azure Logic Apps):''' A. Reading, creating/updating, querying with SQL, and deleting documents within Cosmos DB containers — The connector provides actions for standard document operations (create, replace, read, query, delete) directly within a workflow step.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

Azure Functions Integration

2026-10-26T15:07:34Z

Anko: Recreated DP-420 term page: Azure Functions Integration (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' Serverless compute triggered by Cosmos DB change feed for event-driven processing, denormalization, and data movement.

== Overview ==
Azure Functions is a serverless, event-driven compute platform that integrates natively with Azure Cosmos DB through triggers, input bindings, and output bindings. The Azure Cosmos DB trigger uses the change feed processor under the hood to automatically execute code in response to item inserts and updates across partitions, maintaining state via a leases container. Common architectural patterns tested on the DP-420 exam include using Azure Functions + Change Feed for real-time denormalization, cross-container referential integrity enforcement, materializing aggregates, event streaming to Event Hubs or Service Bus, and archiving historical data to Azure Blob Storage.

Example (C# Isolated Worker): Azure Functions Cosmos DB Trigger with Output Binding

<pre>
[Function("ProcessOrderChangeFeed")]
[CosmosDBOutput("ecommerce", "orderSummaries", Connection = "CosmosDBConnection")]
public static OrderSummary Run(
[CosmosDBTrigger(
databaseName: "ecommerce",
containerName: "orders",
Connection = "CosmosDBConnection",
LeaseContainerName: "leases",
CreateLeaseContainerIfNotExists = true)] IReadOnlyList<Order> input,
FunctionContext context)
{
var logger = context.GetLogger("ProcessOrderChangeFeed");
logger.LogInformation("Processing {Count} changed orders", input.Count);

// Compute denormalized summary to write to orderSummaries container via output binding
return new OrderSummary
{
Id = Guid.NewGuid().ToString(),
CustomerId = input[0].CustomerId,
LastProcessedUtc = DateTime.UtcNow,
TotalOrdersCount = input.Count
};
}
</pre>

This serverless function triggers on inserts/updates from the <code>orders</code> container using the change feed, processes the batch, and writes a denormalized record to <code>orderSummaries</code> via a declarative <code>CosmosDBOutput</code> binding.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-cosmosdb-v2-trigger Microsoft Learn: Azure Cosmos DB trigger for Azure Functions]
* [https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-cosmosdb-v2-input Microsoft Learn: Azure Cosmos DB input and output bindings for Azure Functions]
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/serverless-computing-database Microsoft Learn: Serverless computing with Azure Cosmos DB and Azure Functions]

== DP-420 Style Practice Questions ==
'''Q1.''' What mechanism does the Azure Functions Azure Cosmos DB trigger use to detect data changes across partitions?
* A. The Azure Cosmos DB change feed, managed via a leases container to track state and checkpoints across partitions
* B. Polling SQL API queries executed against the container every 60 seconds
* C. Continuous point-in-time restore transaction logs exported to storage
* D. Server-side JavaScript triggers that invoke an external HTTP webhook

'''Q2.''' Which scenario represents a common DP-420 design pattern combining Azure Cosmos DB change feed with Azure Functions?
* A. Materializing and denormalizing data into another container to optimize read queries
* B. Replacing the need for a partition key in large containers
* C. Converting transactional store data directly into column-oriented analytical store format
* D. Generating periodic backup snapshots on a 4-hour schedule

'''Q3.''' What happens when an Azure Functions output binding writes to an Azure Cosmos DB container?
* A. It automatically creates or upserts documents using the configured connection and container name without custom SDK boilerplate code
* B. It always forces an expensive cross-partition query before writing
* C. It bypasses RU charges by writing through the analytical store
* D. It automatically migrates the container to autoscale throughput

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Azure Functions Integration):''' A. The Azure Cosmos DB change feed, managed via a leases container to track state and checkpoints across partitions — The Azure Cosmos DB trigger is built on the Change Feed Processor, which uses a leases container to track checkpoints and distribute partition processing across function instances.
* '''Q2 (Azure Functions Integration):''' A. Materializing and denormalizing data into another container to optimize read queries — Change feed-triggered Azure Functions are standard for asynchronous denormalization, cross-container synchronization, and maintaining materialized views.
* '''Q3 (Azure Functions Integration):''' A. It automatically creates or upserts documents using the configured connection and container name without custom SDK boilerplate code — Cosmos DB output bindings allow declarative writing/upserting of documents directly from the function return value or out parameters without managing SDK clients manually.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

Direct Lake

2026-10-26T15:07:33Z

Anko: Recreated DP-420 term page: Direct Lake (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' Power BI mode reading Delta tables directly from OneLake — near-Import speed, always fresh.

== Overview ==
Direct Lake is a Power BI/Microsoft Fabric storage mode that loads Delta-format data directly from OneLake into memory for reporting, without requiring a traditional Import (full data copy) or DirectQuery (live query passthrough) step. This gives near-Import query performance while always reflecting the latest data in OneLake — including data mirrored from Azure Cosmos DB — without duplicating storage or building separate ETL/refresh pipelines.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/fabric/get-started/direct-lake-overview Microsoft Learn: Direct Lake overview]

== DP-420 Style Practice Questions ==
'''Q1.''' What problem does Direct Lake mode solve compared to traditional Import and DirectQuery modes?
* A. It provides near-Import performance while reading Delta data directly from OneLake without a full data copy
* B. It replaces the need for a partition key in Azure Cosmos DB
* C. It removes the need for Delta format entirely
* D. It requires a separate ETL pipeline for every refresh

'''Q2.''' What must the underlying data be stored as in OneLake for Direct Lake mode to read it directly?
* A. Delta format tables
* B. Raw JSON documents
* C. XML files
* D. Cosmos DB backup snapshots

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Direct Lake):''' A. It provides near-Import performance while reading Delta data directly from OneLake without a full data copy — Direct Lake reads Delta tables directly from OneLake, combining Import-like speed with DirectQuery-like freshness and no data duplication.
* '''Q2 (Direct Lake):''' A. Delta format tables — Direct Lake requires the data to be stored in OneLake as Delta format tables, such as those produced by Cosmos DB Mirroring for Fabric.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

Serverless SQL Pool

2026-10-26T15:07:33Z

Anko: Recreated DP-420 term page: Serverless SQL Pool (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' On-demand T-SQL query service in Azure Synapse to query Cosmos DB analytical store via OPENROWSET.

== Overview ==
A serverless SQL pool is an on-demand, serverless data-processing service in Azure Synapse Analytics that enables data engineers and analysts to run Transact-SQL (T-SQL) queries directly over data in external stores without provisioning or managing reserved cluster capacity. In the DP-420 exam and Azure Cosmos DB scenarios, serverless SQL pools are used to query the Cosmos DB analytical store (enabled via Azure Synapse Link) in near real time using the OPENROWSET function with provider 'CosmosDB'. This enables hybrid transactional/analytical processing (HTAP) and BI reporting (e.g. creating SQL views for Power BI) without consuming transactional Request Units (RUs) or running heavy ETL jobs.

Example 1 (T-SQL): Query Cosmos DB analytical store using OPENROWSET with automatic schema inference

<pre>
SELECT TOP 100 *
FROM OPENROWSET(
'CosmosDB',
'Account=mycosmosaccount;Database=ecommerce;Key=AccountKeyOrSecret',
Orders
) AS [orders];
</pre>

This query reads directly from the <code>Orders</code> container's analytical store without consuming operational RUs from the transactional store.

Example 2 (T-SQL): Query with explicit schema and credential using WITH clause

<pre>
SELECT
OrderId,
CustomerId,
OrderDate,
TotalAmount
FROM OPENROWSET(
'CosmosDB',
'Connection=https://mycosmosaccount.documents.azure.com;Database=ecommerce',
Orders
)
WITH (
OrderId VARCHAR(50) '$.id',
CustomerId VARCHAR(50) '$.customerId',
OrderDate DATETIME2 '$.orderDate',
TotalAmount DECIMAL(18,2) '$.total'
) AS [orders];
</pre>

Using the <code>WITH</code> clause explicitly defines column types and JSON property paths, optimizing query performance, reducing data processing charges, and enabling clean creation of relational views for Power BI reporting.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/synapse-analytics/sql/query-cosmos-db-analytical-store Microsoft Learn: Query Azure Cosmos DB data using a serverless SQL pool in Azure Synapse Link]
* [https://learn.microsoft.com/en-us/azure/synapse-analytics/sql/develop-openrowset Microsoft Learn: How to use OPENROWSET in serverless SQL pool]
* [https://learn.microsoft.com/en-us/azure/cosmos-db/synapse-link Microsoft Learn: Azure Synapse Link for Azure Cosmos DB]

== DP-420 Style Practice Questions ==
'''Q1.''' How does a serverless SQL pool access Azure Cosmos DB data in Azure Synapse Link?
* A. By executing T-SQL queries using the OPENROWSET function targeting the container's analytical store
* B. By sending SQL API queries through the Cosmos DB SDK Gateway connection mode
* C. By establishing a direct TCP socket connection to Cosmos DB physical partition replicas
* D. By triggering a Cosmos DB stored procedure to export data to CSV files

'''Q2.''' What is the RU impact on the Cosmos DB transactional store when running queries from a serverless SQL pool over the analytical store?
* A. Zero RUs consumed from the transactional store, because the analytical store is fully isolated from transactional throughput
* B. Equal RU cost to running the query via the Cosmos DB API for NoSQL
* C. It consumes half the RUs of a standard cross-partition transactional query
* D. It consumes RUs only if the query scans more than 20 GB of data

'''Q3.''' Why is specifying an explicit schema in the WITH clause of OPENROWSET recommended for serverless SQL pools querying Cosmos DB?
* A. It defines precise column types and paths, improving query performance and avoiding default wide types like VARCHAR(8000)
* B. It is mandatory because automatic schema inference is not supported for Cosmos DB
* C. It encrypts the results using Customer-Managed Keys (CMK) automatically
* D. It migrates the analytical store container directly into Delta format

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Serverless SQL Pool):''' A. By executing T-SQL queries using the OPENROWSET function targeting the container's analytical store — Serverless SQL pools use the OPENROWSET function with provider 'CosmosDB' to query the analytical store directly.
* '''Q2 (Serverless SQL Pool):''' A. Zero RUs consumed from the transactional store, because the analytical store is fully isolated from transactional throughput — The analytical store has independent column-store storage and synchronization; querying it via serverless SQL pools has no RU impact on the transactional store.
* '''Q3 (Serverless SQL Pool):''' A. It defines precise column types and paths, improving query performance and avoiding default wide types like VARCHAR(8000) — The WITH clause provides explicit typing and JSON property mapping, which optimizes query execution and prevents inefficient fallback types like VARCHAR(8000).

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

Apache Spark

2026-10-26T15:07:33Z

Anko: Recreated DP-420 term page: Apache Spark (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' Distributed processing engine used in Synapse/Fabric notebooks to analyze Cosmos DB data.

== Overview ==
Apache Spark is a distributed, in-memory data processing engine commonly used within Azure Synapse Analytics and Microsoft Fabric (via Spark notebooks/pools) to run large-scale ETL, data engineering, and analytics workloads. In the context of Azure Cosmos DB, Spark is used to query the analytical store (via the Cosmos DB Spark connector) for HTAP-style analytics, or to process Delta-format data already mirrored into OneLake.

<pre>
| Feature | Spark Connector (OLTP) | Synapse Link (Analytical Store) |
| --------------------------- | ---------------------- | ------------------------------- |
| Read data | ✅ | ✅ |
| Write data | ✅ | ❌ |
| Update data | ✅ | ❌ |
| Delete data | ✅ | ❌ |
| T-SQL queries | ❌ | ✅ (Serverless SQL Pool) |
| Analytics on large datasets | Limited | ✅ |
| Uses transactional store | ✅ | ❌ |
| Uses analytical store | ❌ | ✅ |
</pre>

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/spark-connector Microsoft Learn: Azure Cosmos DB Spark connector]

== DP-420 Style Practice Questions ==
'''Q1.''' How is Apache Spark commonly used with Azure Cosmos DB?
* A. To query the analytical store or process mirrored Delta data for large-scale analytics/ETL
* B. To provision Azure Cosmos DB throughput
* C. To define a container's partition key
* D. To manage RBAC role assignments

'''Q2.''' Where does Apache Spark typically run when working with Azure Cosmos DB analytical data?
* A. Within Azure Synapse Analytics or Microsoft Fabric Spark pools/notebooks
* B. Inside a Cosmos DB stored procedure
* C. As a Cosmos DB trigger
* D. Inside the Cosmos DB emulator

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Apache Spark):''' A. To query the analytical store or process mirrored Delta data for large-scale analytics/ETL — Apache Spark, via the Cosmos DB Spark connector or Fabric notebooks, is used for analytics and ETL over Cosmos DB's analytical/mirrored data.
* '''Q2 (Apache Spark):''' A. Within Azure Synapse Analytics or Microsoft Fabric Spark pools/notebooks — Spark workloads for Cosmos DB analytics run in Synapse Spark pools or Fabric Spark notebooks, not inside Cosmos DB itself.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

Delta Format

2026-10-26T15:07:32Z

Anko: Recreated DP-420 term page: Delta Format (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' Open-source ACID table format (Delta Lake) used for all data stored in OneLake.

== Overview ==
Delta format (Delta Lake) is an open-source storage format that adds ACID transactions, schema enforcement, and time-travel versioning on top of Parquet files. It is the standard table format used throughout Microsoft Fabric's OneLake, meaning data mirrored from Azure Cosmos DB (or processed by Apache Spark) is stored as Delta tables, enabling reliable, consistent reads across multiple engines (Spark, SQL, Power BI) without data duplication or format conversion.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/fabric/data-engineering/lakehouse-and-delta-tables Microsoft Learn: Delta Lake table format in Fabric]

== DP-420 Style Practice Questions ==
'''Q1.''' What capability does the Delta format add on top of Parquet files?
* A. ACID transactions, schema enforcement, and time-travel versioning
* B. Native support for the MongoDB query language
* C. Automatic partition key selection
* D. Built-in RU consumption metering

'''Q2.''' Why is the Delta format significant for data mirrored from Azure Cosmos DB into OneLake?
* A. It provides a consistent, open table format readable by multiple Fabric engines without conversion
* B. It encrypts the data using customer-managed keys automatically
* C. It reduces Azure Cosmos DB's transactional RU costs
* D. It enforces the container's partition key across Fabric

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Delta Format):''' A. ACID transactions, schema enforcement, and time-travel versioning — Delta Lake (Delta format) extends Parquet with ACID transactions, schema enforcement, and versioning/time travel.
* '''Q2 (Delta Format):''' A. It provides a consistent, open table format readable by multiple Fabric engines without conversion — Storing mirrored data as Delta tables lets Spark, SQL, and Power BI all read the same consistent data without separate copies or conversions.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

OneLake

2026-10-26T15:07:32Z

Anko: Recreated DP-420 term page: OneLake (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' Fabric's single, unified, tenant-wide data lake storing all workloads' data in Delta format.

== Overview ==
OneLake is Microsoft Fabric's single, unified, tenant-wide data lake (built on Azure Data Lake Storage Gen2) that automatically stores data for every Fabric workload in one open, shareable location — eliminating the need for teams to copy or duplicate data across separate lakes. When Azure Cosmos DB Mirroring for Fabric is enabled, mirrored data lands directly in OneLake in Delta format, immediately available to Spark notebooks, Direct Lake-mode Power BI reports, and other Fabric experiences without additional data movement.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview Microsoft Learn: OneLake overview]

== DP-420 Style Practice Questions ==
'''Q1.''' What is OneLake in Microsoft Fabric?
* A. A single, unified, tenant-wide data lake shared across all Fabric workloads
* B. A per-workspace cache used only by Power BI
* C. A dedicated backup store for Azure Cosmos DB
* D. A replacement for Azure Cosmos DB's transactional store

'''Q2.''' In what format does Azure Cosmos DB Mirroring for Fabric store data once it lands in OneLake?
* A. Delta format
* B. Raw JSON documents only
* C. A proprietary binary Cosmos DB format
* D. CSV files

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (OneLake):''' A. A single, unified, tenant-wide data lake shared across all Fabric workloads — OneLake is Fabric's single logical data lake for the entire tenant, shared automatically across workloads.
* '''Q2 (OneLake):''' A. Delta format — Mirrored data is stored in OneLake as open Delta format tables, making it directly queryable by Fabric engines.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

Azure Cosmos DB Mirroring for Fabric

2026-10-26T15:07:32Z

Anko: Recreated DP-420 term page: Azure Cosmos DB Mirroring for Fabric (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' Near real-time replication of Cosmos DB data into Microsoft Fabric's OneLake.

== Overview ==
Azure Cosmos DB Mirroring for Microsoft Fabric continuously replicates Azure Cosmos DB data into Microsoft Fabric's OneLake in near real time, storing it in open Delta format, and making the data available for unified analytics, reporting, and cross-workload querying within Fabric (including via Direct Lake) without a separate ETL/copy pipeline, complementing (and in newer scenarios, replacing) the older Synapse Link/Spark connector approach.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/fabric/database/mirrored-database/azure-cosmos-db Microsoft Learn: Mirroring Azure Cosmos DB in Microsoft Fabric]

== DP-420 Style Practice Questions ==
'''Q1.''' What does Azure Cosmos DB Mirroring for Microsoft Fabric provide?
* A. Near real-time replication of Cosmos DB data into Fabric's OneLake for unified analytics without a separate ETL pipeline
* B. A backup mechanism for disaster recovery only
* C. A way to enable multi-region writes
* D. A tool for managing RBAC permissions

'''Q2.''' When choosing between Azure Cosmos DB Mirroring and the Spark connector for analytics, what is a key consideration?
* A. Mirroring offers simpler, near real-time replication into Fabric OneLake without custom Spark code
* B. The Spark connector is required for any read access to Cosmos DB
* C. Mirroring only supports the MongoDB API
* D. The Spark connector cannot write data back to Cosmos DB

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Azure Cosmos DB Mirroring for Fabric):''' A. Near real-time replication of Cosmos DB data into Fabric's OneLake for unified analytics without a separate ETL pipeline — Mirroring continuously replicates data into OneLake for analytics, avoiding the need for custom ETL.
* '''Q2 (Azure Cosmos DB Mirroring for Fabric):''' A. Mirroring offers simpler, near real-time replication into Fabric OneLake without custom Spark code — Mirroring provides a low-code, near real-time path into Fabric OneLake, while the Spark connector offers more custom control via code.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

Azure Synapse Link / Analytical Store

2026-10-26T15:07:31Z

Anko: Recreated DP-420 term page: Azure Synapse Link / Analytical Store (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' Near real-time analytics via a separate column-store, no RU impact on transactional data.

== Overview ==
Azure Synapse Link for Azure Cosmos DB enables near real-time analytics over operational data by automatically syncing changes into a separate, column-oriented analytical store, without impacting the performance or consuming the RUs of the transactional (OLTP) workload. Analytical store data can then be queried from Azure Synapse Apache Spark or Synapse SQL serverless, enabling hybrid transactional/analytical processing (HTAP) without complex ETL pipelines.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/synapse-link Microsoft Learn: Azure Synapse Link for Azure Cosmos DB]

== DP-420 Style Practice Questions ==
'''Q1.''' What is the primary benefit of enabling the analytical store via Azure Synapse Link?
* A. Near real-time analytics over operational data without consuming transactional RUs or requiring ETL
* B. Reduced storage costs for the transactional store
* C. Automatic multi-region writes
* D. Stronger consistency for transactional queries

'''Q2.''' From which services can you query the Azure Cosmos DB analytical store?
* A. Azure Synapse Spark or Synapse SQL serverless
* B. Only from the Azure Cosmos DB SDK
* C. Only from Power BI directly
* D. Only from Azure Functions

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Azure Synapse Link / Analytical Store):''' A. Near real-time analytics over operational data without consuming transactional RUs or requiring ETL — Synapse Link syncs data into a separate analytical store, enabling analytics without impacting transactional RU consumption.
* '''Q2 (Azure Synapse Link / Analytical Store):''' A. Azure Synapse Spark or Synapse SQL serverless — The analytical store is designed to be queried from Azure Synapse Spark pools or Synapse SQL serverless.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

HTAP (Hybrid Transactional and Analytical Processing)

2026-10-26T15:07:31Z

Anko: Recreated DP-420 term page: HTAP (Hybrid Transactional and Analytical Processing) (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' Architecture running analytics over operational data without impacting transactional OLTP RUs, enabled via Synapse Link/analytical store.

== Overview ==
HTAP (Hybrid Transactional and Analytical Processing) is an architectural pattern that combines transactional processing (OLTP) and analytical processing (OLAP) on the same operational data in near real time, eliminating the latency, cost, and complexity of traditional Extract-Transform-Load (ETL) pipelines. In Azure Cosmos DB, HTAP is achieved through Azure Synapse Link and the analytical store — a separate, column-oriented storage layer that automatically and continuously syncs with the row-based transactional store with no impact on transactional Request Unit (RU) performance or cost. Enabling HTAP requires enabling analytical storage at the Azure Cosmos DB account level, and then configuring analytical storage Time-to-Live (TTL) when creating or updating containers.

Example 1 (Azure CLI): Enable analytical storage (HTAP / Synapse Link) on the Cosmos DB account

<pre>
# Enable analytical storage on an existing Cosmos DB account
az cosmosdb update --name mycosmosaccount --resource-group myRG --enable-analytical-storage true

# Alternatively, enable when creating a new Cosmos DB account
az cosmosdb create --name mycosmosaccount --resource-group myRG --enable-analytical-storage true
</pre>

Enabling analytical storage at the account level is a prerequisite before any container within the account can enable its analytical store.

Example 2 (Azure CLI): Create a container with analytical storage enabled

<pre>
# Create a container with analytical store enabled and infinite retention (-1)
az cosmosdb sql container create --account-name mycosmosaccount --resource-group myRG --database-name ecommerce --name orders --partition-key-path "/customerId" --throughput 400 --analytical-storage-ttl -1
</pre>

Setting <code>--analytical-storage-ttl -1</code> enables the analytical store with no expiration (data is retained indefinitely, independent of the transactional store TTL).

Example 3 (Azure CLI): Update analytical storage TTL on an existing container

<pre>
# Update an existing container's analytical storage TTL (e.g. 90 days = 7776000 seconds)
az cosmosdb sql container update --account-name mycosmosaccount --resource-group myRG --database-name ecommerce --name orders --analytical-storage-ttl 7776000

# Disable analytical store on a container (set analytical-storage-ttl to 0)
az cosmosdb sql container update --account-name mycosmosaccount --resource-group myRG --database-name ecommerce --name orders --analytical-storage-ttl 0
</pre>

Analytical storage TTL is completely separate from transactional TTL (<code>--ttl</code>). Setting <code>--analytical-storage-ttl 0</code> disables analytical sync and retention on the container.

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/synapse-link Microsoft Learn: Azure Synapse Link for Azure Cosmos DB overview]
* [https://learn.microsoft.com/en-us/azure/cosmos-db/configure-synapse-link Microsoft Learn: Configure and use Azure Synapse Link for Azure Cosmos DB]
* [https://learn.microsoft.com/en-us/azure/cosmos-db/analytical-store-introduction#analytical-ttl Microsoft Learn: Analytical store Time-to-Live (TTL)]

== DP-420 Style Practice Questions ==
'''Q1.''' What is the core benefit of HTAP (Hybrid Transactional and Analytical Processing) in Azure Cosmos DB?
* A. Running near real-time analytics over operational data without consuming transactional RUs or maintaining complex ETL pipelines
* B. Automatically partitioning transactional data across physical regions without partition keys
* C. Compressing JSON documents into XML format for client applications
* D. Restoring database accounts to any second within 30 days via self-service portal

'''Q2.''' Which Azure CLI command enables Synapse Link / HTAP analytical storage at the Cosmos DB account level?
* A. az cosmosdb update --name --resource-group --enable-analytical-storage true
* B. az cosmosdb sql container create --enable-htap true
* C. az cosmosdb throughput migrate --type analytical
* D. az cosmosdb sql database create --analytical-store on

'''Q3.''' How do you enable analytical storage on an Azure Cosmos DB container with indefinite retention using the Azure CLI?
* A. Specify --analytical-storage-ttl -1 when creating or updating the container using az cosmosdb sql container
* B. Specify --ttl -1 on the container
* C. Run az cosmosdb sql container throughput update --max-throughput 1000
* D. Add a composite index covering all paths in the indexing policy

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (HTAP (Hybrid Transactional and Analytical Processing)):''' A. Running near real-time analytics over operational data without consuming transactional RUs or maintaining complex ETL pipelines — HTAP enables near real-time analytical workloads over the column-oriented analytical store while completely protecting operational OLTP performance and RU budget.
* '''Q2 (HTAP (Hybrid Transactional and Analytical Processing)):''' A. az cosmosdb update --name --resource-group --enable-analytical-storage true — Enabling analytical storage at the account level requires 'az cosmosdb update (or create) --enable-analytical-storage true'.
* '''Q3 (HTAP (Hybrid Transactional and Analytical Processing)):''' A. Specify --analytical-storage-ttl -1 when creating or updating the container using az cosmosdb sql container — --analytical-storage-ttl controls the analytical store's retention; -1 means retain analytical data forever, independent of transactional TTL (--ttl).

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

Full-Text Query

2026-10-26T15:07:30Z

Anko: Recreated DP-420 term page: Full-Text Query (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' Native keyword search via FULLTEXTCONTAINS/FULLTEXTSCORE, backed by a full-text index.

== Overview ==
A full-text query is Azure Cosmos DB for NoSQL's native capability to search text properties directly using functions such as FULLTEXTCONTAINS and FULLTEXTSCORE (BM25 relevance ranking), backed by a full-text index defined in the container's indexing policy — without requiring a separate search service. It can also be combined with vector search results using reciprocal rank fusion (RRF) for hybrid search, offering a lighter-weight alternative to integrating a dedicated Azure AI Search Integration when only basic keyword relevance search is needed.

<pre>
using Microsoft.Azure.Cosmos;

string endpoint = "";
string key = "";

using CosmosClient client = new(endpoint, key);

Database database = await client.CreateDatabaseIfNotExistsAsync(
id: "catalog-db"
);

// Define the container
ContainerProperties containerProperties = new()
{
Id = "products",

// Partition key
PartitionKeyPath = "/category",

// Optional: automatically expire items after 30 days
DefaultTimeToLive = 60 * 60 * 24 * 30,

// Declare which properties contain searchable text
FullTextPolicy = new FullTextPolicy
{
DefaultLanguage = "en-US",

FullTextPaths =
{
new FullTextPath
{
Path = "/name",
Language = "en-US"
},
new FullTextPath
{
Path = "/description",
Language = "en-US"
}
}
},

// Configure all indexes for the container
IndexingPolicy = new IndexingPolicy
{
IndexingMode = IndexingMode.Consistent,
Automatic = true,

IncludedPaths =
{
new IncludedPath
{
Path = "/*"
}
},

// Do not use the regular range index for this property
ExcludedPaths =
{
new ExcludedPath
{
Path = "/largeMetadata/*"
}
},

// Composite index:
//
// SELECT *
// FROM c
// WHERE c.category = "laptops"
// ORDER BY c.price DESC
CompositeIndexes =
{
new Collection
{
new CompositePath
{
Path = "/category",
Order = CompositePathSortOrder.Ascending
},
new CompositePath
{
Path = "/price",
Order = CompositePathSortOrder.Descending
}
}
},

// Specialized full-text indexes
FullTextIndexes =
{
new FullTextIndexPath
{
Path = "/name"
},
new FullTextIndexPath
{
Path = "/description"
}
}
}
};

// Create the container with 400 provisioned RU/s
ContainerResponse response =
await database.CreateContainerIfNotExistsAsync(
containerProperties: containerProperties,
throughput: 400
);

Container container = response.Container;

Console.WriteLine(
$"Container '{container.Id}' is ready. " +
$"Status: {response.StatusCode}"
);
</pre>

<pre>
// Create a container with only full-text indexing
ContainerProperties containerProperties = new()
{
Id = "text-only",
PartitionKeyPath = "/id",

// Only define full-text indexes
IndexingPolicy = new IndexingPolicy
{
IndexingMode = IndexingMode.Consistent,
Automatic = true,

// Only full-text indexes
FullTextIndexes =
{
new FullTextIndexPath
{
Path = "/title"
},
new FullTextIndexPath
{
Path = "/abstract"
}
},

// No range or composite indexes
IncludedPaths = { },
ExcludedPaths = { }
}
};
</pre>

<pre>

var queryable = container.GetItemLinqQueryable(
queryText: "SELECT * FROM c WHERE FULLTEXTCONTAINS(c.description, @search)",
parameters: new[]
{
new SqlParameter("@search", "high-performance laptop")
}
);

foreach (Product product in queryable)
{
Console.WriteLine($"Name: {product.Name}");
}

</pre>

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/full-text-search Microsoft Learn: Full-text search in Azure Cosmos DB for NoSQL]

== DP-420 Style Practice Questions ==
'''Q1.''' What enables full-text query capability in Azure Cosmos DB for NoSQL?
* A. A full-text index defined in the container's indexing policy, queried with functions like FULLTEXTCONTAINS/FULLTEXTSCORE
* B. A separate Azure AI Search resource that must always be provisioned
* C. The default range index applied to every property
* D. The change feed processor

'''Q2.''' When might you choose Azure Cosmos DB's native full-text query over integrating Azure AI Search?
* A. When you need lightweight keyword relevance ranking without provisioning and maintaining a separate search service
* B. When you require a dedicated analytical store
* C. When you need multi-region write support
* D. When you need to enforce a composite index

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Full-Text Query):''' A. A full-text index defined in the container's indexing policy, queried with functions like FULLTEXTCONTAINS/FULLTEXTSCORE — Full-text query is a native Cosmos DB capability driven by a full-text index and query functions like FULLTEXTCONTAINS and FULLTEXTSCORE.
* '''Q2 (Full-Text Query):''' A. When you need lightweight keyword relevance ranking without provisioning and maintaining a separate search service — Native full-text query avoids the cost/complexity of a separate Azure AI Search service for basic BM25-style keyword relevance search.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

Change Feed

2026-10-26T15:07:30Z

Anko: Recreated DP-420 term page: Change Feed (Integration & Analytics)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Integration & Analytics

'''Summary:''' Persistent, ordered log of item inserts/updates, consumable by apps and Azure Functions.

== Overview ==
The change feed is a persistent, ordered log of changes (inserts and updates) made to items within an Azure Cosmos DB container, available for consumption by applications, Azure Functions, or other Azure services. It is a foundational building block for scenarios such as event-driven architectures, real-time analytics, denormalization, referential integrity enforcement, aggregation, and data archiving.

<pre>
Container monitoredContainer =
database.GetContainer("Orders");

Container leaseContainer =
database.GetContainer("Leases");

ChangeFeedProcessor processor =
monitoredContainer
.GetChangeFeedProcessorBuilder(
processorName: "orders-processor",
onChangesDelegate: HandleChangesAsync)
.WithLeaseContainer(leaseContainer)
.Build();
</pre>

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/change-feed Microsoft Learn: Change feed in Azure Cosmos DB]

== DP-420 Style Practice Questions ==
'''Q1.''' What does the Azure Cosmos DB change feed provide?
* A. A persistent, ordered log of insert/update operations on container items
* B. A one-time export of all data in a container
* C. A record of only delete operations
* D. A backup of the entire database account

'''Q2.''' Which of these is a common use case for the change feed?
* A. Denormalizing data or enforcing referential integrity via Azure Functions
* B. Defining the container's partition key
* C. Encrypting data at rest
* D. Configuring the consistency level

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Change Feed):''' A. A persistent, ordered log of insert/update operations on container items — The change feed captures inserts and updates (not deletes, by default) as an ordered, persistent log for downstream consumption.
* '''Q2 (Change Feed):''' A. Denormalizing data or enforcing referential integrity via Azure Functions — Change feed + Azure Functions is commonly used for denormalization, referential integrity, aggregation, and archiving.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Integration & Analytics]]

EXISTS & Array Functions (IS ARRAY, ARRAY CONTAINS)

2026-10-26T15:07:30Z

Anko: Recreated DP-420 term page: EXISTS & Array Functions (IS_ARRAY, ARRAY_CONTAINS) (Server-Side Programming)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Server-Side Programming

'''Summary:''' SQL subquery and array functions (EXISTS, IS_ARRAY, ARRAY_CONTAINS, ARRAY_LENGTH) for nested data.

== Overview ==
Azure Cosmos DB for NoSQL provides powerful query operators and built-in system functions for filtering, inspecting, and manipulating JSON arrays and variable-schema documents: '''1. EXISTS (Subquery Expression):'''

* A boolean operator that evaluates a subquery and returns <code>true</code> if the subquery returns at least one item, and <code>false</code> otherwise.
* '''EXISTS vs. JOIN:''' An intra-document <code>JOIN</code> on an array duplicates the parent document in the result set for every matching array element. In contrast, <code>WHERE EXISTS (...)</code> evaluates nested array criteria (using <code>c IN f.arrayProperty</code>) and returns each qualifying parent document ''exactly once'' without result duplication.
* '''Negation (NOT EXISTS):''' Filters for parent documents where no child array elements satisfy the subquery condition.

'''2. Built-In Array System Functions:'''
* '''ARRAY_CONTAINS(arr, expr [, bool_expr]):''' Checks whether an array contains a specific value. When searching for partial JSON objects, passing <code>true</code> as the optional third parameter enables partial/sub-object matching.
* '''ARRAY_LENGTH(arr):''' Returns the number of elements in the specified array.
* '''ARRAY_CONCAT(arr1, arr2 [, ...]):''' Concatenates two or more arrays into a single combined array.
* '''ARRAY_SLICE(arr, start_index [, length]):''' Returns a subset (slice) of an array starting at the zero-based index.
* '''ARRAY(subquery):''' Converts the output of a subquery into a JSON array within the projection.

'''3. Type Checking & Guard Functions:'''
* '''IS_ARRAY(expr):''' Returns <code>true</code> if the expression is a JSON array. Essential for guarding queries against documents with missing or non-array values.
* '''IS_OBJECT(expr):''' Returns <code>true</code> if the expression is a JSON object.
* '''IS_DEFINED(expr):''' Returns <code>true</code> if the property exists and is defined (not missing or undefined).
* '''IS_NULL(expr):''' Returns <code>true</code> if the property value is explicitly <code>null</code>.
* '''IS_PRIMITIVE(expr):''' Returns <code>true</code> if the value is a scalar type (string, number, boolean, or null).
* '''IS_STRING / IS_NUMBER / IS_BOOL:''' Type checking for specific scalar types.

Example 1 (Cosmos DB SQL): Filter parents where a nested child has multiple pets (EXISTS with ARRAY_LENGTH)

<pre>
-- Returns family IDs where at least one child in the children array has more than 1 pet
SELECT f.id
FROM f
WHERE EXISTS (
SELECT VALUE c
FROM c IN f.children
WHERE ARRAY_LENGTH(c.pets) > 1
)
</pre>

Using <code>EXISTS</code> returns each qualifying family document exactly once without cartesian product row duplication.

Example 2 (Cosmos DB SQL): ARRAY_CONTAINS (Scalar & Partial Object Matching) vs. EXISTS

<pre>
-- 1. Simple scalar check with ARRAY_CONTAINS (fast & concise)
SELECT p.id, p.name
FROM p
WHERE ARRAY_CONTAINS(p.tags, "Sale")

-- 2. Partial object matching with ARRAY_CONTAINS (3rd argument = true)
SELECT f.id
FROM f
WHERE ARRAY_CONTAINS(f.children, { "gender": "female" }, true)

-- 3. Complex multi-condition check with EXISTS (predicates that ARRAY_CONTAINS cannot express)
SELECT f.id
FROM f
WHERE EXISTS (
SELECT VALUE c
FROM c IN f.children
WHERE c.gender = "female" AND c.grade >= 10
)
</pre>

Example 3 (Cosmos DB SQL): Guarding Schema-Agnostic Queries with IS_ARRAY & IS_DEFINED

<pre>
-- Safely query items where 'tags' is defined, is a valid array, has items, and contains 'Azure'
SELECT c.id, c.title
FROM c
WHERE IS_DEFINED(c.tags)
AND IS_ARRAY(c.tags)
AND ARRAY_LENGTH(c.tags) > 0
AND ARRAY_CONTAINS(c.tags, "Azure")
</pre>

Example 4 (Cosmos DB SQL): Array Manipulation with ARRAY_SLICE and ARRAY_CONCAT

<pre>
-- Slices top 2 tags and concatenates primary & secondary color arrays
SELECT
p.id,
ARRAY_SLICE(p.tags, 0, 2) AS TopTags,
ARRAY_CONCAT(p.primaryColors, p.secondaryColors) AS AllColors
FROM p
WHERE IS_ARRAY(p.tags) AND IS_ARRAY(p.primaryColors)
</pre>

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/subqueries#exists-expression Microsoft Learn: Subqueries in Azure Cosmos DB (EXISTS expression)]
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/array-contains Microsoft Learn: ARRAY_CONTAINS in Azure Cosmos DB]
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/is-array Microsoft Learn: IS_ARRAY in Azure Cosmos DB]
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/array-functions Microsoft Learn: Array functions in Azure Cosmos DB]
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/type-checking-functions Microsoft Learn: Type checking functions in Azure Cosmos DB]
* [https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/dp-420 Microsoft Learn: DP-420 study guide]

== DP-420 Style Practice Questions ==
'''Q1.''' What is the primary advantage of using WHERE EXISTS (subquery) instead of a JOIN when filtering documents based on nested array properties?
* A. It returns each qualifying parent document exactly once without duplicating rows for multiple matching array elements
* B. It enables multi-region write replication on the container
* C. It automatically creates a spatial index over the nested array
* D. It allows modifying the nested array elements in place

'''Q2.''' When should you choose EXISTS (subquery) over ARRAY_CONTAINS when querying nested array data?
* A. When you need to evaluate complex expressions, multiple properties, or range conditions (such as ARRAY_LENGTH(c.pets) > 1) on array elements
* B. When checking if a flat array contains a simple scalar string value
* C. When you need to order documents by their partition key
* D. When the container uses gateway mode exclusively

'''Q3.''' Which Azure Cosmos DB SQL system function checks whether a property exists and is of JSON array type before executing array operations?
* A. IS_ARRAY(c.property)
* B. TYPE_OF(c.property) == 'Array'
* C. IS_LIST(c.property)
* D. CHECK_ARRAY(c.property)

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (EXISTS & Array Functions (IS_ARRAY, ARRAY_CONTAINS)):''' A. It returns each qualifying parent document exactly once without duplicating rows for multiple matching array elements — WHERE EXISTS evaluates whether at least one matching element exists and returns the parent document without duplicating it, unlike JOIN which produces cartesian product duplicates.
* '''Q2 (EXISTS & Array Functions (IS_ARRAY, ARRAY_CONTAINS)):''' A. When you need to evaluate complex expressions, multiple properties, or range conditions (such as ARRAY_LENGTH(c.pets) > 1) on array elements — ARRAY_CONTAINS is ideal for simple scalar containment or partial object equality, whereas EXISTS with a subquery is required for complex multi-condition predicates and range evaluations on array items.
* '''Q3 (EXISTS & Array Functions (IS_ARRAY, ARRAY_CONTAINS)):''' A. IS_ARRAY(c.property) — IS_ARRAY returns a boolean indicating whether the target expression is a JSON array, preventing query errors across heterogeneous document schemas.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Server-Side Programming]]

Aggregate Functions (COUNT, SUM, AVG, MIN, MAX)

2026-10-26T15:07:29Z

Anko: Recreated DP-420 term page: Aggregate Functions (COUNT, SUM, AVG, MIN, MAX) (Server-Side Programming)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Server-Side Programming

'''Summary:''' Built-in SQL aggregate operators (COUNT, SUM, AVG, MIN, MAX) used with GROUP BY.

== Overview ==
Azure Cosmos DB for NoSQL supports standard built-in aggregate functions in SQL queries, typically paired with the <code>GROUP BY</code> clause to summarize and group items across partitions:

* '''COUNT''': Returns the number of items in the group (e.g., <code>COUNT(1)</code> or <code>COUNT(*)</code> to count all items, or <code>COUNT(c.property)</code> to count items where the property is defined and not null).
* '''SUM''': Returns the arithmetic sum of numeric values in the expression across the group (ignores non-numeric and undefined values).
* '''AVG''': Returns the arithmetic average (mean) of numeric values in the expression across the group.
* '''MIN''': Returns the minimum scalar value (numeric, string, boolean, etc.) in the expression across the group.
* '''MAX''': Returns the maximum scalar value (numeric, string, boolean, etc.) in the expression across the group.

'''Key DP-420 Rules & Behaviors:'''
* '''GROUP BY Rule:''' Any property projected in the <code>SELECT</code> clause that is not wrapped inside an aggregate function MUST be explicitly included in the <code>GROUP BY</code> clause.
* '''Exact Function Names:''' Only <code>COUNT</code>, <code>SUM</code>, <code>AVG</code>, <code>MIN</code>, and <code>MAX</code> are supported out of the box in the NoSQL query language. Functions such as <code>MEDIAN</code>, <code>STDEV</code>, or <code>VAR</code> are NOT natively supported.
* '''VALUE Keyword:''' You can use <code>SELECT VALUE COUNT(1) FROM c</code> to project a single scalar value rather than a JSON object.
* '''Performance & Indexing:''' Queries with <code>GROUP BY</code> and aggregate functions benefit significantly from composite indexes on the grouped/filtered properties and execute efficient per-partition aggregations that the query engine merges.

Example 1 (Cosmos DB SQL): Comprehensive GROUP BY with all 5 standard aggregate functions

<pre>
-- Groups products by category and calculates count, sum, average, min, and max price
SELECT
c.category,
COUNT(1) AS TotalProducts,
SUM(c.price) AS TotalInventoryValue,
AVG(c.price) AS AveragePrice,
MIN(c.price) AS LowestPrice,
MAX(c.price) AS HighestPrice
FROM c
WHERE c.isAvailable = true
GROUP BY c.category
</pre>

Every scalar property in the <code>SELECT</code> list (<code>c.category</code>) is present in the <code>GROUP BY</code> clause, and all 5 standard aggregates are computed per group.

Example 2 (Cosmos DB SQL): Multi-Property GROUP BY with WHERE and ORDER BY

<pre>
-- Groups items by multiple properties (manufacturer and category) with an average rating
SELECT
c.manufacturer,
c.category,
COUNT(1) AS ItemCount,
AVG(c.rating) AS AverageRating,
SUM(c.inventoryCount) AS TotalInventory
FROM c
WHERE c.discontinued = false
GROUP BY c.manufacturer, c.category
ORDER BY c.manufacturer ASC
</pre>

Example 3 (Cosmos DB SQL): Scalar Aggregate with the VALUE keyword (No GROUP BY)

<pre>
-- Returns a raw scalar number (e.g. 42) instead of a JSON object ({"$1": 42})
SELECT VALUE COUNT(1)
FROM c
WHERE c.status = "Pending"
</pre>

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/aggregate-functions Microsoft Learn: Aggregate functions in Azure Cosmos DB SQL query language]
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/query/group-by Microsoft Learn: GROUP BY clause in Azure Cosmos DB]
* [https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/dp-420 Microsoft Learn: DP-420 study guide]

== DP-420 Style Practice Questions ==
'''Q1.''' Which set of aggregate functions is natively supported in Azure Cosmos DB for NoSQL with the GROUP BY clause?
* A. COUNT, SUM, AVG, MIN, and MAX
* B. COUNT, MEDIAN, STDEV, VAR, and MODE
* C. SUM, AVERAGE, MINIMUM, MAXIMUM, and TOTAL
* D. COUNT, FIRST, LAST, SUM, and AGGREGATE

'''Q2.''' When executing a SQL query with GROUP BY in Azure Cosmos DB, what is required for properties in the SELECT projection?
* A. Any scalar property in the SELECT list that is not wrapped in an aggregate function must appear in the GROUP BY clause
* B. The query can only project a single aggregate function with no category or group keys
* C. The container's partition key must always be the first item in the GROUP BY list
* D. Aliasing with the AS keyword is prohibited when using GROUP BY

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (Aggregate Functions (COUNT, SUM, AVG, MIN, MAX)):''' A. COUNT, SUM, AVG, MIN, and MAX — Azure Cosmos DB for NoSQL supports five exact built-in aggregate functions: COUNT, SUM, AVG, MIN, and MAX. Other statistical functions like MEDIAN or STDEV are not natively built-in.
* '''Q2 (Aggregate Functions (COUNT, SUM, AVG, MIN, MAX)):''' A. Any scalar property in the SELECT list that is not wrapped in an aggregate function must appear in the GROUP BY clause — In Azure Cosmos DB SQL, any non-aggregate property in the SELECT clause must be explicitly declared in the GROUP BY clause.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Server-Side Programming]]

User-Defined Function (UDF)

2026-10-26T15:07:29Z

Anko: Recreated DP-420 term page: User-Defined Function (UDF) (Server-Side Programming)

← Back to [[DP-420: Azure Cosmos DB Developer Specialty|DP-420 Terminology Reference]]

'''Category:''' Server-Side Programming

'''Summary:''' Read-only JavaScript function extending SQL queries with custom computations.

== Overview ==
A user-defined function (UDF) is server-side JavaScript logic in Azure Cosmos DB for NoSQL that extends the SQL query language with custom scalar computations (e.g., custom string formatting or calculations), callable from within a SQL query. Unlike stored procedures and triggers, UDFs are read-only and cannot modify data.

''[Image: udf.png (User-Defined Function)]''

== More Info & Links ==
* [https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/how-to-write-stored-procedures-triggers-udfs#udfs Microsoft Learn: How to write user-defined functions]

== DP-420 Style Practice Questions ==
'''Q1.''' What is the primary purpose of a user-defined function (UDF) in Azure Cosmos DB for NoSQL?
* A. Extending SQL queries with custom, read-only scalar computations
* B. Performing multi-item transactional writes
* C. Automatically triggering on every item creation
* D. Managing container-level throughput

'''Q2.''' Can a UDF modify data in Azure Cosmos DB?
* A. No, UDFs are read-only and cannot modify data
* B. Yes, UDFs can perform inserts, updates, and deletes
* C. Only if invoked from a stored procedure
* D. Only for items within the same partition

== Answer Key ==
''Answers are listed at the very end so you can attempt the questions first.''

* '''Q1 (User-Defined Function (UDF)):''' A. Extending SQL queries with custom, read-only scalar computations — UDFs add custom computational logic callable from SQL queries, but unlike stored procedures/triggers, they cannot write data.
* '''Q2 (User-Defined Function (UDF)):''' A. No, UDFs are read-only and cannot modify data — UDFs are restricted to read-only scalar computation and cannot write or modify data.

----
''DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB — term detail page''

[[Category:DP-420 Terminology]]
[[Category:Server-Side Programming]]