Name the contract before selecting the service
A service decision begins with required behavior. A client depends on request methods, query syntax, driver behavior and the operations it invokes. A statement that two databases store JSON describes a representation, not proof that they accept the same requests. Similarly, a managed SQL platform and a database on a virtual machine can support related engines while giving the customer different host responsibilities. Write the integration requirement and the administration requirement separately. A team that needs a custom guest-OS process must test that requirement against the platform contract rather than assume a database-administrator role includes every host permission. The objective is to identify the missing evidence before promising an unchanged application.
Worked example: identify the transaction scope
A fictional inventory container uses WarehouseId as its partition key. Records (id='reservation',WarehouseId='W1') and (id='balance',WarehouseId='W1') need one supported Cosmos DB for NoSQL transactional operation. Both have key value W1, so they share a logical partition even though their item ids differ. A supported transaction scoped to that logical partition can include both. Now consider a balance item with WarehouseId W2: the same container name does not put it inside W1's scope. Write the required update set and the partition key for each item before applying the documented in-partition guarantee. The data is fictional, and this boundary check does not establish an optimal partition key for throughput, growth or every wider business workflow. Within the container, the partition-key value together with the item id identifies an item; repeating an id in another logical partition does not make it the same item.
Version checks protect a calculation, not just a write
Suppose two editors read the same item at version V1. One editor updates it, and the server version becomes V2. The other editor's old calculation can discard the first change if sent unconditionally. In the stated single-region-write optimistic-concurrency workflow, an If-Match condition carrying V1 lets the server reject the stale replacement with a precondition failure. The client then rereads and reconciles the actual changes. Simply obtaining V2 and attaching it to an unchanged old calculation can remove the useful protection: the tag should connect the write to the state on which its calculation was based. This lesson does not generalize that simplified path into every multi-region conflict-resolution configuration.
Flexible storage still needs an application contract
A key/attribute representation can allow different property sets without declaring one fixed relational schema. That freedom does not tell the application whether a required business field exists, has a useful value or belongs to an enforced relationship. A CustomerId-looking attribute is not by itself a foreign-key declaration. List the fields a particular operation needs and decide where to validate them. This also explains why matching JSON field names is only part of a migration check: data meaning, request compatibility and business validity are related but separate questions. Each requires its own evidence and a failure condition that a reviewer can test.
Transfer check: locate two independent failures
Try a new fictional case before reading the answer. A team moves a client to a new database API because both products export JSON. It also claims an atomic two-item change spans Tenant A and Tenant B because the items are in one container. What two checks are missing? The client check must enumerate actual methods, query syntax and driver assumptions against the selected API. The transaction check must identify the configured partition-key values and the scope of the supported operation; a shared container does not establish a shared logical partition. As a changed condition, put both items in the same logical partition. That removes this particular scope objection but still does not prove API compatibility. Keep the two evidence chains separate.
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.
Microsoft Learn: rd-dp-cosmosMicrosoft Learn: rd-dp-partitionUnified AI Database - Azure Cosmos DB | Microsoft LearnWhat Is Azure SQL? - Azure SQL | Microsoft LearnIntroduction to Azure Storage - Cloud storage on Azure | Microsoft Learn