Practice Test #2

Yes. In the Power BI service, a dashboard is created within (and owned by) a specific workspace. The workspace acts as the organizational and security boundary for the dashboard, including who can view or edit it. While dashboards can be shared with users outside the workspace (depending on tenant settings, permissions, and sharing method), the dashboard itself still resides in exactly one workspace. Why “No” is wrong: there isn’t a concept of a single dashboard being simultaneously associated with multiple workspaces. If you need the same dashboard-like experience in another workspace, you typically recreate it, use an app to distribute content, or rely on shared datasets/semantic models and separate dashboards per workspace. This workspace association is important for governance and access control, which is why DP-900 expects you to recognize the workspace as the container for dashboards.

No. A Power BI dashboard can include tiles pinned from multiple reports, and those reports can be based on different datasets (semantic models). This is one of the key purposes of dashboards: to provide a consolidated view across different subject areas (for example, sales KPIs from one dataset and support ticket KPIs from another). Why “Yes” is wrong: the “single dataset” limitation applies more to certain report behaviors (a report is typically built on one dataset at a time, though it can use composite models and DirectQuery to multiple sources). Dashboards, however, are an aggregation layer of pinned visuals/tiles and are not restricted to a single dataset. On the exam, remember: dashboards = one page, many tiles, potentially many datasets.

Yes. Power BI can use Excel workbooks as a data source, and visuals built from that Excel data can be shown on a dashboard. In the Power BI service, dashboard tiles are typically pinned from reports, and those reports can be created from imported Excel data or supported workbook content. "No" is incorrect because Excel is a supported source for Power BI analytics, but the dashboard does not directly render arbitrary Excel content unless it has been brought into Power BI in a supported way.

Correct answer: D (strong consistency guarantees are required). Relational databases are the default choice when you require strong consistency and ACID transactions (Atomicity, Consistency, Isolation, Durability). These capabilities help ensure data integrity across multiple related tables and rows, enforce constraints (primary/foreign keys), and support transactional workloads where reads must reflect the latest committed writes. In Azure, services like Azure SQL Database provide strong consistency and robust transactional semantics. Why the others are wrong: A (a dynamic schema is required) typically points to non-relational/document databases (for example, Azure Cosmos DB for NoSQL) where schema can evolve without rigid table definitions. B (data will be stored as key/value pairs) is a classic key/value workload, better suited to key/value stores (for example, Cosmos DB key/value patterns, Azure Cache for Redis) rather than a relational engine. C (storing large images and videos) is best handled by object storage such as Azure Blob Storage, which is optimized for unstructured binary data and cost-effective large-scale storage.

Correct answer: A. enable the hierarchical namespace. Enabling hierarchical namespace (HNS) turns the storage account into Azure Data Lake Storage Gen2. This provides real directories and files (not just name prefixes) and supports POSIX-style ACLs that can be applied at directory (folder) and file level. It also enables atomic directory operations such as rename and move, which are important for analytics engines and data pipelines that reorganize partitions/folders. Why the others are wrong: - B (Account kind = BlobStorage): This is a legacy account type and does not provide HNS, directory objects, or ACL-based folder security. - C (Performance = Premium): Premium affects performance characteristics and pricing (e.g., for certain storage account types) but does not add hierarchical namespace or folder ACLs. - D (RA-GRS): Replication improves durability and read availability in a secondary region, but it does not change namespace semantics or enable folder-level security.

Correct answer: A. A clustered index. A clustered index is an index type where the table’s data rows are physically stored in the order of the clustered index key. Because it determines the physical organization of the table, it effectively “sorts and stores the data rows in the table based on their key values.” In Azure SQL Database and SQL Server, a table can have only one clustered index because there is only one physical ordering of the data. Why the others are wrong: - B. FileTable: A specialized feature for storing files and documents with Windows file system semantics while maintaining relational access; it does not define row ordering for a table. - C. A foreign key: A constraint that enforces referential integrity between a child table and a parent table; it does not sort or store rows. - D. A stored procedure: A programmable database object that contains SQL statements and logic; it does not control physical row storage order.

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.