DP-600 Implementing Analytics Solutions Using Microsoft Fabric Questions and Answers

Both a dataflow (A) and a Stored procedure activity in a pipeline (B) are capable of creating and populating a date dimension table. A dataflow can perform the transformation needed to create the date dimension, and it aligns with the preference for using low-code tools for data ingestion when possible. A Stored procedure could be written to generate the necessary date dimension data and executed within a pipeline, which also adheres to the technical requirements for the PoC.

No, the REFRESH TABLE statement does not provide information on whether maintenance tasks were performed. It only updates the metadata of a table to reflect any changes on the data files. References = The use and effects of the REFRESH TABLE command are explained in the Spark SQL documentation.

You should use CREATE VIEW to make the pricing group logic available for T-SQL queries.

The CASE statement should be used to determine the pricing group based on the list price.

The T-SQL statement should create a view that classifies products into pricing groups based on the list price. The CASE statement is the correct conditional logic to assign each product to the appropriate pricing group. This view will standardize the pricing group logic across different databases and semantic models.

The measure should use the AVERAGE function to calculate the average value.

It should reference the Response Value column from the 'Survey' table.

The 'Number of months' should be used to define the period for the average calculation.

To calculate the average overall satisfaction score using DAX, you would need to use the AVERAGE function on the response values related to satisfaction questions. The DATESINPERIOD function will help in calculating the rolling average over the last 12 months.

For the semantic model design required for the customer satisfaction report, the choices for data source authentication method and mode should be made based on security and performance considerations as per the case study provided.

Authentication method: The data should be accessed securely, and given that row-level security (RLS) is required for users executing T-SQL queries, you should use an authentication method that supports RLS. Service principal authentication is suitable for automated and secure access to the data, especially when the access needs to be controlled programmatically and is not tied to a specific user's credentials.

Mode: The report needs to show data as soon as it is updated in the data store, and it should only contain data from the current and previous year. DirectQuery mode allows for real-time reporting without importing data into the model, thus meeting the need for up-to-date data. It also allows for RLS to be implemented and enforced at the data source level, providing the necessary security measures.

Based on these considerations, the selections should be:

Authentication method: Service principal authentication

Mode: DirectQuery

Comprehensive Detailed Explanation

When assigning permissions to roles in a Fabric workspace for analytics workloads, you must align permissions with the responsibilities and tools typically used by each persona:

1. Data Engineers

Their primary tasks include building and transforming data pipelines, as well as making datasets usable by others.

The appropriate permission is Build Reports on the default dataset, because this allows them to create and manage reports using the curated semantic model while preparing data for analysts and scientists.

2. Data Analysts

Analysts work heavily with Apache Spark for exploratory analysis, cleansing, and shaping data.

The correct permission is Read All Apache Spark, as this grants them the ability to query and analyze Spark-based data directly without elevated permissions that are unnecessary for their role.

3. Data Scientists

Data scientists often use SQL analytics endpoints to run queries, train models, and integrate data into machine learning workflows.

The correct permission is Read All SQL analytics endpoint data, since it enables direct programmatic access to the SQL endpoint, which is needed for advanced modeling and experimentation.

Summary of Selections:

DataEngineers → Build Reports on the default dataset

DataAnalysts → Read All Apache Spark

DataScientists → Read All SQL analytics endpoint data

References (Microsoft Fabric – DP-600 exam scope):

Workspace roles and permissions in Microsoft Fabric

SQL analytics endpoint in Fabric

Apache Spark in Microsoft Fabric

A lakehouse (C) should be recommended for the AnalyticsPOC workspace. It combines the capabilities of a data warehouse with the flexibility of a data lake. A lakehouse supports semi-structured and unstructured data and allows for T-SQL and Python read access, fulfilling the technical requirements outlined for Litware. References = For further understanding, Microsoft's documentation on the lakehouse architecture provides insights into how it supports various data types and analytical operations.

Comprehensive Detailed Explanation

From the case study:

Research division data for Productline2 is currently in CSV format in storage2.

Requirement: “All the Research division data in the lakehouses must be presented as managed tables in Lakehouse explorer.”

In Fabric lakehouses, managed tables are stored in Delta format inside the Tables folder.

Step 1: Reading the source

df = spark.read.format("csv") \

options(header="true", inferSchema="true") \

load("abfss://storage1.dfs.core.windows.net/files/productline2")

This correctly ingests the CSV source from ADLS Gen2.

Step 2: Writing to Lakehouse as a managed table

You must write the data in Delta format to ensure it is queryable and managed within the lakehouse.

The correct path is under Tables/, because this is where Fabric automatically manages Lakehouse managed tables.

The target table should be named productline2, so the correct path is:

df.write.mode("overwrite").format("delta").save("Tables/productline2")

Why not other options?

CSV or Parquet formats would not create a managed Lakehouse table; they would just create files.

Writing to productline2 directly (without Tables/) would store unmanaged files in the Lakehouse Files area, not managed tables.

Writing to Tables/research/productline2 adds an unnecessary subdirectory and is not the standard structure for managed tables.

Correct Final Code

df.write.mode("overwrite").format("delta").save("Tables/productline2")

References

Managed tables in Microsoft Fabric Lakehouse

Delta Lake support in Fabric

Spark write to Lakehouse

You need to recommend which type of Fabric capacity SKU meets the data analytics requirements for the Research division.

Requirement: “The Research division workspaces must use a dedicated, on-demand capacity that has per-minute billing.”

Fabric capacity SKUs:

F (Fabric) = dedicated Fabric capacity, available on pay-as-you-go with per-minute billing.

P (Premium) and EM are Power BI capacities (not Fabric-native).

A refers to Azure Analysis Services capacity.

The only correct option is F SKU.

In Azure DevOps workspace (project) security settings, role assignments determine access levels for groups:

Viewer (equivalent to the Readers security group): Grants read-only access to work items, code, pipelines, and other artifacts. Ideal for review-only scenarios where users need to view but not edit content.

Contributor (equivalent to the Contributors security group): Allows full edit and contribute privileges, such as updating work items, code reviews, and pipeline runs. Suitable for active participation in reviews that may involve feedback or changes.

Based on the group names implying review-focused access, Viewer fits Group1 for passive observation, while Contributor fits Group2 for interactive review tasks. These align with default Azure DevOps permissions for secure, least-privilege access.

Comprehensive Detailed Explanation

The question asks: Which syntax should you use in a Fabric notebook to access the Research division data for Productline1?

Key Background from the Case

In Productline1ws, a lakehouse named Lakehouse1 is created.

In Lakehouse1, a shortcut is created to storage1, named ResearchProduct.

Storage1 contains the Research division data for Productline1 in Delta format.

Requirement: All data in lakehouses must be presented as managed tables in Lakehouse explorer.

Analyzing the Syntax Options

Option A:

spark.sql("SELECT * FROM Lakehouse1.ResearchProduct")

This syntax directly queries the ResearchProduct shortcut within Lakehouse1 using Spark SQL.

Since the shortcut points to Delta data, Spark can directly query it.

This is the correct way to retrieve Productline1 data from Lakehouse1.

Option B:

spark.sql("SELECT * FROM Lakehouse1.productline1.ResearchProduct")

This introduces an extra schema-like path (productline1) that is not part of the shortcut name.

Incorrect, because the shortcut was created as ResearchProduct inside Lakehouse1, not under another schema.

Option C:

external_table('Tables/ResearchProduct')

external_table is not the correct way to access a Lakehouse shortcut.

Shortcuts in Lakehouses appear as tables and can be queried using Spark SQL directly.

Option D:

spark.sql("SELECT * FROM Lakehouse1.productline1.ResearchProduct")

Same issue as Option B, includes a schema path that does not exist.

Correct Choice

Since the shortcut to ResearchProduct was created inside Lakehouse1, and Spark SQL can query it directly, the correct syntax is:

spark.sql("SELECT * FROM Lakehouse1.ResearchProduct")

That matches Option A.

References

Microsoft Fabric Lakehouse – Shortcuts

Query data in a lakehouse using Spark SQL

Delta format support in Microsoft Fabric

You need to ensure that Contoso can use version control to meet the data analytics requirements and the general requirements.

Requirement: “All the semantic models and reports for the Research division must use version control that supports branching.”

Fabric supports Git integration (Azure Repos or GitHub) for semantic models and reports.

Storing in Data Lake Gen2 or OneDrive does not provide version control with branching.

The correct action is to integrate workspaces with a Git repository.

Answer: D. Modify the settings of the Research division workspaces to use an Azure Repos repository.

Requirement: “The number of rows added to the Orders table during refreshes must be minimized.”

The Orders table has a sequential OrderID.

To minimize refresh size, you must only import new rows, not the entire table.

This requires retrieving the maximum OrderID currently loaded, then only loading rows with a greater OrderID.

So, the correct solution is to use a pipeline (ADF) with a dataflow to retrieve the maximum OrderID.

Answer: C. an Azure Data Factory pipeline that executes a dataflow to retrieve the maximum value of the OrderID column in the destination lakehouse

 Calculation groups are a Tabular Object Model (TOM) feature.

 They cannot be authored in Power BI Desktop or the service.

 They are implemented using Tabular Editor.

Comprehensive Detailed Explanation

The requirement is to logically group the Research division workspaces and support filtering in the OneLake data hub.

Why Domain?

Microsoft Fabric allows you to assign workspace domains (e.g., Finance, HR, Research).

This provides a logical grouping of workspaces within the organization.

Domains are the only supported way to enable filtering in OneLake data hub by department.

Capacity or tenant grouping would not allow filtering by department in OneLake.

Why OneLake data hub?

The OneLake data hub is the centralized interface to browse and discover data assets across the organization.

With workspace domains configured, users can filter directly in the OneLake data hub by domain (e.g., “Research”).

The Fabric Admin portal and Entra admin center are used for administration, not for workspace filtering in data discovery.

Correct Selection for the Hotspot

Grouping method: Domain

Tool: OneLake data hub

References

Workspace domains in Microsoft Fabric

Discover and filter data in OneLake data hub

Final Answer:

Grouping method = Domain

Tool = OneLake data hub

The Table.Max function should be used in a Power Query step to identify the maximum values for the numeric columns. This function is designed to calculate the maximum value across each column in a table, which suits the requirement of finding maximum values for numeric columns. References = For detailed information on Power Query functions, including Table.Max, please refer to Power Query M function reference.

The Python code and output shown in the exhibit display a histogram, which is a representation of the distribution of data. This kind of analysis is descriptive analytics, which is used to describe or summarize the features of a dataset. Descriptive analytics answers the question of "what has happened" by providing insight into past data through tools such as mean, median, mode, standard deviation, and graphical representations like histograms.

The results will form a hierarchy of folders for each partition key. - Yes

The resulting file partitions can be read in parallel across multiple nodes. - Yes

The resulting file partitions will use file compression. - No

Partitioning data by columns such as year, month, and day, as shown in the DataFrame write operation, organizes the output into a directory hierarchy that reflects the partitioning structure. This organization can improve the performance of read operations, as queries that filter by the partitioned columns can scan only the relevant directories. Moreover, partitioning facilitates parallelism because each partition can be processed independently across different nodes in a distributed system like Spark. However, the code snippet provided does not explicitly specify that file compression should be used, so we cannot assume that the output will be compressed without additional context.

References =

DataFrame write partitionBy

Apache Spark optimization with partitioning

The correct code to populate the results DataFrame with minimal data shuffling is Option A. Using the broadcast function in PySpark is a way to minimize data movement by broadcasting the smaller DataFrame (customers) to each node in the cluster. This is ideal when one DataFrame is much smaller than the other, as in this case with customers. References = You can refer to the official Apache Spark documentation for more details on joins and the broadcast hint.

The transformation you should select from the context menu of the VendorID column to transform the date columns into attribute-value pairs, where columns become rows, is Unpivot columns (B). This transformation will turn the selected columns into rows with two new columns, one for the attribute (the original column names) and one for the value (the data from the cells). References = Techniques for unpivoting columns are covered in the Power Query documentation, which explains how to use the transformation in data modeling.

To meet the requirements, developers should have Admin access to the deployment pipeline (B), Contributor access to the Development and Test workspaces (E), and Viewer access to the Production workspace (D). This setup ensures they can perform necessary actions in development and test environments without having the ability to affect production. References = The Power BI documentation on workspace access levels and deployment pipelines provides guidelines on assigning appropriate permissions.

When using XMLA endpoints to manage and update semantic models in Microsoft Fabric, the performance of write operations (such as processing, structural changes, or metadata deployments from Tabular Editor) is directly influenced by the storage format and how the model is persisted.

Why Option A is Correct

By default, Fabric semantic models use the Small semantic model storage format.

To improve write operations performance through XMLA, you must change the workspace setting to use the Large semantic model storage format.

The large format uses more efficient storage techniques, supports partitioning, and handles larger models with optimized write capabilities.

This setting is applied at the workspace level and impacts all semantic models within that workspace, including Model1.

This is explicitly documented in Microsoft’s guidance: Large semantic model storage format is required when using XMLA write operations for large or frequently updated models.

Why the Other Options Are Incorrect

B. Configure Model1 to use the Direct Lake storage format.

Direct Lake mode is designed for query performance (reading data directly from OneLake in delta format without import/duplication).

It improves query latency and freshness but does not improve XMLA write operations, which deal with model metadata and structural updates.

C. Delete any unused semantic models from Workspace1.

Deleting unused semantic models helps manage capacity and storage but does not increase the speed of XMLA endpoint write operations.

Workspace storage overhead does not directly impact the write throughput of XMLA operations.

D. Delete any unused columns from Model1.

Removing unused columns reduces the memory footprint and can improve query performance.

However, it does not directly improve the speed of XMLA write operations. The bottleneck in XMLA writes is tied to the storage format, not the model size alone.

Summary

To increase the speed of XMLA write operations on semantic models, you must enable the Large semantic model storage format at the workspace level. This setting ensures better handling of writes and metadata operations via the XMLA endpoint.

References

Large models in Power BI and Microsoft Fabric

Use the XMLA endpoint in Microsoft Fabric

Manage capacities in Microsoft Fabric

INSERT INTO … SELECT and SELECT INTO both physically copy all rows, which is heavy and not minimal.

CREATE TABLE AS SELECT (CTAS) also copies the data.

CREATE TABLE … AS CLONE OF creates a shallow clone in Fabric Warehouse, meaning it references the existing data without duplicating it, minimizing storage and copying.

Correct answer: B.

Based on the duration breakdown provided, the major contributor to the rendering duration is categorized as "Other," which is significantly higher than DAX Query and Visual display times. This suggests that the issue is less likely with the DAX calculation or visual rendering times and more likely related to model performance or the complexity of the visual. However, of the options provided, optimizing the DAX query can be a crucial step, even if "Other" factors are dominant. Using DAX Studio, you can analyze and optimize the DAX queries that power your visuals for performance improvements. Here’s how you might proceed:

Open DAX Studio and connect it to your Power BI report.

Capture the DAX query generated by the Orders By Date visual.

Use the Performance Analyzer feature within DAX Studio to analyze the query.

Look for inefficiencies or long-running operations.

Optimize the DAX query by simplifying measures, removing unnecessary calculations, or improving iterator functions.

Test the optimized query to ensure it reduces the overall duration.

Comprehensive Detailed Explanation

We need to create a computed column PriceRange based on the UnitPrice column in the dbo.Product table.

Step 1: Requirements

If UnitPrice = 0 → "Not for resale"

If UnitPrice < 50 → "Under $50"

If UnitPrice >= 50 AND UnitPrice < 250 → "Under $250"

Otherwise → "$250+"

This matches a CASE expression in T-SQL.

Step 2: CASE Expression Structure

The syntax is:

CASE

WHEN condition THEN result

WHEN condition THEN result

ELSE result

END

Step 3: Apply to Problem

SELECT

Item,

UnitPrice,

PriceRange = CASE

WHEN UnitPrice = 0 THEN 'Not for resale'

WHEN UnitPrice < 50 THEN 'Under $50'

WHEN UnitPrice >= 50 AND UnitPrice < 250 THEN 'Under $250'

ELSE '$250+'

END

FROM [Warehouse1].[dbo].[Product];

Step 4: Why This is Correct

CASE starts the conditional evaluation.

ELSE handles the default branch ($250+).

END closes the expression.

Meets all requirements exactly.

References

CASE expression in T-SQL

Computed columns in T-SQL

Step 1 – Select the required fields and count

We want to group by CustomerAltKey and count occurrences.

SELECT CustomerAltKey, COUNT(*)

Step 2 – From the table

FROM DimCustomer

Step 3 – Grouping by email

GROUP BY CustomerAltKey

Step 4 – Filtering duplicates (only values with count > 1)

HAVING COUNT(*) > 1

Step 5 – Limiting the result to 1,000 rows

LIMIT 1000

(or in T-SQL, SELECT TOP(1000) ...). Since both options are shown, we use LIMIT 1000 because Fabric Warehouse supports Synapse SQL T-SQL + ANSI SQL style.

Correct Sequence:

SELECT CustomerAltKey, COUNT(*)

FROM DimCustomer

GROUP BY CustomerAltKey

HAVING COUNT(*) > 1

LIMIT 1000

The Table.Profile function in Power Query is used to generate column statistics such as count, average, null count, distinct count, and standard deviation. You can use this function as follows:

Invoke the Power Query Editor.

Apply the Table.Profile function to your table.

The result will be a table where each row represents a column from the original table, and each column in the result represents a different statistic such as those listed in the requirement.

Lookup activity can execute a SQL query or stored procedure and retrieve a single row or dataset. The returned values can then be passed to downstream pipeline activities.

Switch is for branching logic, not executing procedures.

Append variable just adds values to a variable.

KQL activity executes Kusto queries, not SQL stored procedures.

Therefore, the correct choice is Lookup.

When creating a OneLake shortcut to Amazon S3, authentication uses the standard AWS access key ID + secret access key pair.

SAS token is for Azure Storage, not AWS.

Certificate thumbprint is not used for S3.

Access ID is incorrect naming; the correct term is access key ID.

Correct answers: B and D.

To prevent new tables added to Lakehouse1 from being automatically added to the default semantic model, you should configure the semantic model settings. There should be an option within the settings of the semantic model to include or exclude new tables by default. By adjusting these settings, you can control the automatic inclusion of new tables.