Practice Test #2

The correct match is table. A table is the primary database object used to store data in rows and columns, making it the persistent container for relational data. A view does not normally store the underlying data; it stores a query definition. An index helps the database find data faster, but it is not the main object used to hold the business data itself.

The correct match is view. A view is a database object whose contents are defined by a SELECT query against one or more underlying tables. It presents a virtual result set rather than acting as the primary storage location for the data. A table stores the actual rows, while an index is used to improve query performance rather than define content through a query.

The correct match is index. An index is a database object that improves the speed of data retrieval by providing an efficient structure for locating rows. This reduces the need for full table scans in many queries. A table stores the data itself, and a view defines a query-based presentation of data, so neither is the best match for retrieval optimization.

Correct answer: B. simple lookups. A key/value data store is optimized for retrieving a value when you already know the key (for example, get session:12345 or get userPref:alice). The data model is intentionally minimal: the store typically treats the value as an opaque blob (string/JSON/binary), and the primary operation is fast GET/SET by key. This design enables very low-latency access and easy horizontal scaling, which is why key/value stores are commonly used for caching, session state, and quick configuration reads. Why the other options are wrong: A. enforcing constraints is a relational database strength (primary/foreign keys, check constraints). Key/value stores generally do not enforce schema or referential integrity. C. table joins are a relational capability; key/value stores do not support joins because there are no related tables. D. transactions (especially multi-record ACID transactions) are typically associated with relational systems. Some key/value systems offer limited atomic operations, but transactions are not the primary optimization goal in the DP-900 context.

No. In Azure Cosmos DB, the API is configured at the Azure Cosmos DB account level, not separately per database. When you create a Cosmos DB account, you select the API (such as Azure Cosmos DB for NoSQL, MongoDB, Cassandra, Gremlin, or Table). All databases and containers created within that account use that same API model and endpoint/protocol. Why “Yes” is wrong: it implies you can have different APIs per database inside one account (for example, one database using NoSQL and another using MongoDB). That is not how Cosmos DB is structured for the exam: mixing APIs requires separate Cosmos DB accounts. This is an important design consideration because the API choice influences SDKs, query language/semantics, and compatibility, and it is part of the account’s foundational configuration.

Yes. Partition keys are used to optimize queries and operations in Azure Cosmos DB by enabling efficient routing and distribution. When a query includes the partition key (typically an equality predicate on the partition key value), Cosmos DB can target the specific logical partition that contains the relevant items. This avoids scanning or fanning out across multiple partitions, reducing RU consumption and improving latency. Why this matters: partitioning is primarily for scalability and performance. It distributes data and throughput across physical partitions, but it also directly impacts query efficiency. Queries that do not specify the partition key may become cross-partition queries, which generally cost more RUs and can be slower. While indexes also optimize queries, the partition key is a key mechanism for query targeting and is therefore a correct statement in the context of Cosmos DB fundamentals.

No. Items contained in the same Azure Cosmos DB logical partition cannot have different partition key values. A logical partition is defined as the set of items that share the same partition key value within a container. Therefore, if two items have different partition key values, they belong to different logical partitions. Why “Yes” is wrong: it contradicts the definition of a logical partition. Cosmos DB uses the partition key value to group items; that grouping is what enables targeted reads/writes and efficient single-partition queries/transactions (where supported). Practically, this is why choosing a good partition key is critical: it determines how items are grouped, affects data distribution (avoiding hot partitions), and influences whether common queries and operations can be served from a single logical partition versus requiring cross-partition fan-out.

Pass. Correct matches in the image are: 1) “Enables the use of SQL queries against data stored in JSON documents” → Azure Cosmos DB. Cosmos DB (Core/SQL API) stores items as JSON documents and supports SQL-like queries (SELECT, WHERE, JOIN within documents, etc.). This is a common DP-900 association: JSON document database with a SQL query language. 2) “Enables users to access data by using the Server Message Block (SMB) version 3 protocol” → Azure Files. Azure Files provides fully managed SMB file shares (SMB 3.x) that can be mounted from clients and VMs. Why others are wrong: Azure Blob storage is object storage (REST/HTTP) and not accessed via SMB as a primary interface. Azure Table storage is a NoSQL key-value store (partition/row keys) and does not provide SQL querying over JSON documents in the way Cosmos DB does.