Objective and core distinction
Azure Cosmos DB offers multiple API choices. This lesson focuses on the native API for NoSQL and its documented logical-partition transaction boundary. A flexible document representation can accommodate varying attributes, but it does not remove the need to plan access patterns or client integration. API names are not decorative labels:the operations and driver behavior expected by an application form part of its contract. A common product family does not prove that every API accepts an unchanged client. Nor does document syntax make all operations across an account one transaction. State the API and data boundary before reasoning about a capability.
Worked example
Fictional case:a workshop-booking application has two related document items. The supplied design explicitly places both in the same logical partition and uses a supported transactional mechanism for their update. The retained Cosmos DB for NoSQL documentation supports ACID operations within that boundary. The conclusion is deliberately narrower than “NoSQL has no transactions” or “everything in an account is one atomic unit.” Check the proposed scope against the evidence. The number of items alone does not establish whether they share the required boundary; the stated partition relationship does. Application data choices and access permissions also require their own requirements.
Changed condition and misconception
Change the case:the two items now have different logical partition keys. The earlier in-partition guarantee does not prove a single atomic operation across the changed scope. That does not mean the service has no transaction support at all. Both categorical extremes discard the useful boundary. In another change, the client is moved from one API to another. A JSON field may keep its name while the accepted request/driver contract changes. Verify that integration explicitly. This course does not provide a tenant setup procedure, quote a consistency/SLA guarantee, or equate older MongoDB-vCore branding with every current Cosmos DB offering.
Transfer check
Transfer check:a colleague supplies only “both documents are in the same account” as evidence of a transactional update. What is the missing scope information? Check basis:identify the actual API, logical partition relationship and supported transaction mechanism before applying the retained guarantee. Then contrast a client-compatibility question:which requests does the existing client issue, and which API accepts them? Those are different questions even when they concern the same documents. State one conclusion that is supported and one that must remain unknown. Use the formal tasks to examine positive and negative boundary cases, not to infer a blanket rule about every non-relational database.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
Unified AI Database - Azure Cosmos DB | Microsoft LearnDatabase Transactions and Optimistic Concurrency Control - Azure Cosmos DB | Microsoft LearnIdentify data formats - Training | Microsoft Learn