Each test is 5 questions with varying difficulty.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.
Azure Cosmos DB is a globally distributed, multi-model database service offered by Microsoft Azure. It provides turn-key global distribution, elastic scaling of throughput and storage, and guaranteed low-latency access, making it a critical component for modern, highly available, and scalable applications. In 2026, its relevance continues to grow, especially with the increasing demand for real-time data processing, AI-driven applications, and global microservices architectures that require data locality and high availability. Interviewers frequently assess candidates on Cosmos DB to gauge their understanding of distributed systems, NoSQL data modeling, performance optimization, and cloud-native architecture. Roles such as Software Engineers, Data Engineers, DevOps Engineers, and Cloud Architects are expected to possess varying depths of knowledge. Junior candidates might be tested on core concepts like consistency levels and basic partitioning, while senior candidates will face questions on advanced data modeling, performance tuning, cost optimization, disaster recovery strategies, and complex system design involving Cosmos DB.
Azure Cosmos DB is a cornerstone for building resilient, globally scalable applications in 2026. Its ability to provide single-digit millisecond latency at the 99th percentile, backed by comprehensive SLAs, is crucial for user experiences in real-time applications like e-commerce, IoT, and gaming. For instance, a global e-commerce platform can use Cosmos DB to store user profiles and shopping carts, ensuring customers in different geographies experience consistent, fast access to their data, significantly improving conversion rates and user satisfaction. Its multi-model API support (SQL, MongoDB, Cassandra, Gremlin, Table) allows developers to leverage existing skill sets and migrate diverse workloads without extensive refactoring, accelerating time-to-market. A strong understanding of Cosmos DB reveals a candidate's proficiency in designing and operating high-performance, globally distributed systems. A candidate who can articulate the nuances of partition key selection or consistency models demonstrates an ability to prevent costly performance bottlenecks and ensure data integrity, distinguishing them from those who only grasp surface-level concepts. In 2026, with the proliferation of AI and real-time analytics, Cosmos DB's change feed capabilities are increasingly vital for triggering downstream processes, such as feeding data to ML models or real-time dashboards, making it a high-signal topic for modern engineering roles.
Azure Cosmos DB operates as a fully managed, globally distributed, multi-model database service. Its architecture is built on a foundational set of distributed systems principles, providing elastic scalability, guaranteed performance, and high availability. At its core, Cosmos DB is a schema-agnostic database engine that transparently indexes all data. It uses a resource governance model based on Request Units (RUs) to abstract away the underlying compute and storage resources. Data is horizontally partitioned (sharded) across physical partitions, with logical partitions determined by a user-defined partition key. Each physical partition is a highly available and durable replica set, ensuring data redundancy and fault tolerance. The service employs a write-optimized, schema-agnostic indexing engine and a multi-homed API gateway that routes requests to the nearest available replica.
Client applications connect via SDKs to the nearest Azure region's API Gateway. The Gateway routes requests to the appropriate Front-End Service, which handles authentication, authorization, and request parsing. The Partitioning Layer uses the partition key to identify the correct physical partition. Requests are then routed to the Storage Engine responsible for that partition. Data is written to the primary replica and then asynchronously replicated to secondary replicas within the same region and across globally distributed regions according to the chosen consistency model. The Indexing Engine continuously indexes all data, making it queryable without schema definition. Reads can be served from any replica based on the consistency level.
Client Application
↓
[Cosmos DB SDK]
↓
[API Gateway (Multi-Homed)]
↓ (Routes to nearest region)
[Front-End Service]
↓
[Partitioning Layer]
(Partition Key Logic)
↓
[Physical Partition P1] [Physical Partition P2] ...
↓ (Primary Replica) ↓ (Primary Replica)
[Storage Engine] --------> [Storage Engine]
↓ (Replication) ↓ (Replication)
[Secondary Replicas] <-----> [Secondary Replicas]
↑ ↑
[Indexing Engine] -------------
(Schema-agnostic indexing)
↑
[Consistency Protocol]
(Ensures data integrity across replicas)Instead of creating multiple containers (tables) for different entity types, store all related entities within a single container. Distinguish entity types using a 'type' property and leverage the partition key to co-locate related data. This optimizes queries that retrieve multiple related entities.
Trade-offs: Benefits from fewer cross-partition queries and reduced RU consumption. Can lead to more complex queries and data access patterns, requiring careful index management and potentially larger document sizes. Requires a well-chosen partition key to avoid hot partitions.
Utilize Cosmos DB's Change Feed to capture all data modifications (inserts, updates, deletes) in real-time. The Change Feed Processor library (or Azure Functions trigger) manages leases and distributes processing across multiple instances, enabling event-driven architectures.
Trade-offs: Enables real-time analytics, materialized views, and integration with other services (e.g., Kafka, search engines). Adds operational overhead for managing the processor instances and ensuring exactly-once processing semantics if required. Requires careful error handling.
Configure Cosmos DB for multi-region writes, allowing applications to write data to any replica. Implement a custom conflict resolution policy (e.g., Last Write Wins, custom merge logic) to handle concurrent updates to the same item across different regions.
Trade-offs: Provides maximum write availability and lowest write latency for globally distributed users. Introduces complexity in managing potential write conflicts and requires careful design of conflict resolution logic to maintain data integrity. Higher cost due to replication.
For complex or frequently executed cross-partition queries, pre-aggregate or transform data into a separate, optimized container (a 'materialized view'). Use the Change Feed to update this view whenever source data changes.
Trade-offs: Significantly improves read performance and reduces RU consumption for complex queries. Adds storage cost for the materialized view and introduces eventual consistency between the source data and the view. Requires managing the update process (e.g., with Azure Functions).
| Reliability | Cosmos DB offers 99.999% availability for multi-region accounts with Strong consistency and 99.99% for single-region accounts. Failure modes include regional outages (handled by global distribution and automatic failover) and localized partition failures (handled by replica sets within physical partitions). Ensure multi-region writes are configured with appropriate conflict resolution for active-active scenarios. Monitor for throttling (429 errors) as an indicator of insufficient RUs, which can impact application reliability. |
| Scalability | Cosmos DB scales elastically in both storage and throughput. Storage scales automatically as data grows. Throughput (RUs) can be provisioned manually or automatically with autoscale. Horizontal scaling is achieved through partitioning. To scale effectively, choose a partition key that distributes data and request volume evenly across logical partitions. Avoid hot partitions by designing for high cardinality and uniform access patterns. |
| Performance | Guaranteed single-digit millisecond latency at the 99th percentile. Performance bottlenecks often arise from inefficient queries (e.g., cross-partition queries without a filter on the partition key), suboptimal indexing, or insufficient RUs. Optimize queries by selecting specific fields, filtering on indexed properties, and using the partition key. Monitor RU consumption and latency metrics in Azure Monitor. For critical workloads, place data geographically close to users. |
| Cost | Cost is primarily driven by provisioned throughput (RU/s) and consumed storage. Data replication across regions also adds cost. To reduce cost, right-size RUs using autoscale, optimize queries to reduce RU consumption, and prune unnecessary indexes. Evaluate the need for multi-region writes versus read replicas. Use the free tier for development and testing. Consider reserved capacity for predictable workloads. |
| Security | Cosmos DB supports role-based access control (RBAC) for management operations and resource tokens for granular data access. Data is encrypted at rest and in transit. Implement network security using Azure Private Link or IP firewall rules to restrict access to Cosmos DB endpoints. Use managed identities for Azure resources to authenticate applications without managing secrets. Regularly rotate access keys. |
| Monitoring | Azure Monitor provides comprehensive metrics for Cosmos DB, including RU consumption, throttled requests (429s), latency, storage usage, and availability. Set up alerts for high RU consumption, throttling, and latency spikes. Monitor Change Feed lag if used. Utilize Cosmos DB's built-in diagnostics logs for detailed operation insights. Integrate with Azure Application Insights for end-to-end application monitoring. |
A logical partition is a conceptual unit grouping items with the same partition key value, while a physical partition is the actual underlying storage and compute resource. Multiple logical partitions can reside on a single physical partition, and Cosmos DB automatically manages the mapping and distribution of logical partitions across physical ones.
Cosmos DB offers five tunable consistency models (Strong, Bounded Staleness, Session, Consistent Prefix, Eventual). These models allow developers to choose the desired tradeoff between consistency, availability, and latency, with Strong consistency providing the highest data freshness and Eventual offering the lowest latency.
No, the partition key for a container cannot be changed after creation. If a different partition key is required, you must create a new container with the desired key and migrate your data from the old container to the new one.
Request Units (RUs) are a normalized measure of throughput in Cosmos DB. Every database operation consumes RUs. They are crucial because they determine the cost of your Cosmos DB account and directly impact the performance and scalability of your application by defining the available throughput.
Use the SQL API (Core API) for new applications requiring a flexible document model and native JSON querying. Use the MongoDB API when migrating existing MongoDB applications to leverage existing codebases, tools, and developer skills, or if your team is already proficient in MongoDB.
A hot partition occurs when a single logical partition receives a disproportionately high volume of requests or stores a large amount of data, leading to throttling. Avoid it by choosing a partition key with high cardinality and uniform distribution of access patterns across logical partitions, ensuring even workload distribution.
Cosmos DB ensures high availability through automatic replication of data across multiple physical partitions within a region and across multiple Azure regions. It provides automatic failover capabilities and financially-backed SLAs for availability, especially with multi-region configurations.
While Cosmos DB can store relational-like data, it's a NoSQL database, and highly normalized relational models are generally not optimal. Denormalization and embedding related data within documents or using a single-table design are often preferred to optimize for read performance and reduce cross-partition queries.
The Change Feed provides a persistent, ordered log of all changes to your data. Benefits include enabling real-time data processing, building materialized views, integrating with other services, and triggering serverless functions for event-driven architectures without complex polling.
Optimize queries by selecting specific fields, filtering on indexed properties, using the partition key in `WHERE` clauses, and avoiding cross-partition queries where possible. Customize indexing policies, denormalize data for common read patterns, and consider materialized views for complex aggregations.
TTL allows you to automatically delete items from a container after a specified period. This is useful for managing data lifecycle, reducing storage costs for transient data, and complying with data retention policies without manual cleanup.
Yes, Cosmos DB supports transactional operations within a single logical partition using stored procedures and triggers. These operations are ACID-compliant and guarantee atomicity, consistency, isolation, and durability for operations within that partition.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.