Free PL-300 Practice Test Questions and Answers (2026)

Keeping the detailed Impressions fact table but restricting it to the last 12 months preserves the required grain while a star-schema one-to-many relationship to the Date, Ad, Campaign, and Site dimension tables (B) enables slicing by day, campaign, and Sitename without duplicating data.

Row counts are best returned through an explicit DAX measure that uses COUNTROWS (C); a measure occupies only the formula cache, so it adds virtually nothing to the in-memory model size, meeting the minimisation requirement. Creating additional aggregated or calculated tables would increase memory use and are therefore avoided.

A Grouping into a separate query/table adds another fact table; even if smaller than the raw data, it is still additional storage and not required when a measure can aggregate on demand.

D A calculated table is materialised in the VertiPaq store, duplicating columns already present and therefore increasing, not reducing, model size.

1. Microsoft Docs – “Designing a star schema in Power BI”: Relationships should be one-to-many between dimension and fact tables. (Power BI guidance

p. 3

section “Star schema overview”)

2. Microsoft Docs – “Data reduction techniques for import models”: Use measures instead of calculated tables/columns to minimize model size. (p. 2

paragraph “Prefer measures over calculated columns”)

3. Microsoft Docs – DAX Function Reference: COUNTROWS returns the number of rows in a table; used in measures without increasing model storage. (COUNTROWS article

Examples section)

4. Russo

Ferrari. “Optimizing DAX Models.” SQLBI White-paper

2020

§2.1 “Memory footprint of measures vs. tables.”

For row-level security (RLS) to function correctly across a bidirectional relationship, two conditions must be met. First, the relationship must be active to allow filters to propagate between the tables by default. Second, the "Apply security filter in both directions" option must be enabled for that relationship. This specific setting ensures that the RLS filter applied to one table is also propagated to the related table, enforcing the security rules regardless of which table is being filtered first. This is crucial when both tables in the relationship have RLS rules defined.

A. Assume referential integrity is a performance optimization setting for relationships; it does not control the direction or application of security filters.

B. An inactive relationship does not propagate filters unless explicitly invoked by a DAX function, and Assume referential integrity is irrelevant to RLS.

C. An inactive relationship prevents automatic filter propagation, which contradicts the requirement for standard bidirectional cross-filtering to work with RLS.

1. Microsoft Learn. (2023). Row-level security (RLS) with Power BI.

Section: RLS with bi-directional cross-filtering

Content: "By default

RLS filtering uses single-directional filters

whether the relationships are set to single direction or bi-directional. You can manually enable bi-directional cross-filtering with RLS by selecting the relationship and checking the Apply security filter in both directions checkbox." This directly supports enabling the specific setting on an active relationship.

2. Microsoft Learn. (2023). Model relationships in Power BI Desktop.

Section: Relationship properties

Content: The documentation describes the "Apply security filter in both directions" property

explaining that when enabled for a relationship with a "Both" cross-filter direction

it propagates the security context to the related table. This is the exact mechanism required by the question.

3. Microsoft Learn. (2023). Bidirectional cross-filtering.

Section: Row-level security

Content: "When a DAX expression for a row-level security (RLS) rule is active

it will also filter in the other direction. ... You must enable the Apply security filter in both directions property for the relationship." This confirms that for RLS to work bidirectionally

this property is mandatory.

The stated goal is to analyze events by the hour and the day of the year, while also improving dataset performance. Changing the IOT DateTime column's data type to Date removes the time component entirely. While this action reduces the column's cardinality and would improve performance, it makes the required hourly analysis impossible. Because the solution fails to meet a critical part of the analytical requirement, it does not meet the overall goal.

A. Yes: This is incorrect. The solution prevents analysis by the hour because converting the column to a Date data type discards all time-related information.

1. Microsoft Learn. (2023). Data types in Power BI Desktop. "Date - Represents just a Date (no time portion)." This official documentation confirms that the Date data type does not store time information

making hourly analysis impossible after the proposed conversion. Retrieved from https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-data-types

2. Microsoft Learn. (2023). Optimization guide for Power BI. Under the section "Data model optimization techniques

" the guidance discusses reducing column cardinality to improve performance. It states

"The VertiPaq storage engine...achieves better compression for columns with lower cardinality." A DateTime column has very high cardinality. Converting it to Date reduces cardinality

which addresses the performance goal

but it fails the analytical goal. Retrieved from https://learn.microsoft.com/en-us/power-bi/guidance/power-bi-optimization#reduce-column-cardinality

3. Microsoft Learn. (2023). Add a date or time column in Power Query. This document shows the correct procedure for this scenario

which involves adding new columns for specific date or time parts (like Hour) from an existing DateTime column

rather than changing the data type of the source column and losing information. Retrieved from https://learn.microsoft.com/en-us/power-query/add-date-time-column

Changing the cross filter direction can improve report query performance by optimizing the flow of filters through the data model. In a typical star schema, filters flow from the dimension tables (e.g., Date, Gender, AgeGroup) to the central fact table (Employee). Setting the direction to single can prevent ambiguous relationships and complex filtering paths that negatively impact query speed. The data model itself is organized as a star schema because the central Employee fact table is directly connected to multiple dimension tables. There are no cascading relationships where one dimension table links to another, which would indicate a snowflake schema.

Microsoft Docs. (n.d.). Create and manage relationships in Power BI Desktop. Retrieved from [Official vendor documentation]. Section "Cross-filter direction."

Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd ed.). John Wiley & Sons. ISBN 978-1-118-53026-6. Chapter 3, "Dimensional Modeling Fundamentals," pp. 53-56.

Chen, P. P.-S. (1976). The Entity-Relationship Model—Toward a Unified View of Data. ACM Transactions on Database Systems, 1(1), 9–36. https://doi.org/10.1145/320434.320440. Section 3.4, "Dimensional and Fact Tables."

A clustered column chart is purpose-built for comparing a single quantitative measure (profit) across a limited number of discrete categories (the 10 product categories) in one time slice (the selected quarter). It places uniform-width columns on a common baseline, making magnitude differences easy to judge and category labels easy to read—exactly the goal here.

1. Microsoft Learn – “Bar and column charts in Power BI”

section “When to use a column chart: compare values across a few categories”. https://learn.microsoft.com/power-bi/visuals/power-bi-visualization-types#bar-and-column-charts

2. Microsoft Learn – “Choose the right chart type”

subsection “Compare data across categories – Column charts”. https://learn.microsoft.com/power-bi/create-reports/desktop-choose-right-chart#compare-data-across-categories-column-charts

The requirement is to restrict data access so that users can only view data corresponding to their specific department. This is the primary use case for Row-Level Security (RLS) in Power BI. RLS is implemented by creating roles within the Power BI model. For each role, a DAX filter expression is defined on a table (in this case, the Departments table). When a user assigned to a specific role accesses the report in the Power BI service, this DAX filter is automatically applied, restricting the rows of data they can see throughout the entire model. This method enforces security at the data model level.

B. A parameter is a user-controlled input for interactive analysis, not a security feature. A user could easily change the parameter value to view data from other departments.

C. The CURRENTGROUP DAX function is used within grouping functions like SUMMARIZECOLUMNS to perform calculations on grouped data; it is not related to user-based security.

D. A slicer is a visual filter on the report canvas that users can freely interact with. It does not enforce security, as a user could modify or remove the slicer.

1. Microsoft Learn. (2024). Restrict data access with row-level security (RLS) for Power BI. Microsoft Power BI Documentation. Retrieved from https://learn.microsoft.com/en-us/power-bi/enterprise/service-admin-rls.

Reference Details: The section "Define roles and rules in Power BI Desktop" explicitly states

"You can define roles and rules within Power BI Desktop. When you publish to Power BI

it also publishes the role definitions... To define security roles

follow these steps. 1. Import data into your Power BI Desktop report

or configure a DirectQuery connection. ... 2. From the Modeling tab

select Manage Roles." This directly supports the process described in option A.

2. Microsoft Learn. (2024). Implement row-level security. PL-300: Design and build a data model in Power BI learning path. Retrieved from https://learn.microsoft.com/en-us/training/modules/design-build-tabular-model-power-bi/7-implement-row-level-security.

Reference Details: This official PL-300 courseware notes

"Row-level security (RLS) is a Power BI feature that can be used to restrict data access for given users. Filters restrict data access at the row level

and you can define filters within roles... You will implement RLS by creating one or more roles. A role has a unique name in the model

and it will typically include one or more rules."

3. Microsoft Learn. (2024). Row-level security (RLS) guidance in Power BI Desktop. Power BI Guidance Documentation. Retrieved from https://learn.microsoft.com/en-us/power-bi/guidance/rls-guidance.

Reference Details: The section "Implement RLS" details the process: "In Power BI Desktop

you can create a role by navigating to the Modeling ribbon and selecting Manage roles. In the Manage roles window

you can create

modify

or delete roles... You add a rule to a table by using a DAX expression that must return a TRUE or FALSE value." This confirms that creating roles and defining rules is the correct procedure.

To apply specific background colors based on distinct value ranges, you must use conditional formatting based on rules. The sequence begins by navigating to the column's formatting pane and opening the Background color dialog. Since the colors are based on thresholds rather than color scales or field values, you must then set the Format style to Rules. Finally, to implement the specific coloring for each required range (e.g., 0 to 1, 1 to 2, etc.), you add and configure a new rule for each value range, defining the lower bound, upper bound, and corresponding color.

Microsoft Learn: Apply conditional formatting in tables and matrix visuals. This documentation describes the workflow for applying formatting, differentiating between setting font color/background color and utilizing data bars, color scales, or rule-based formatting.

Source: https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-conditional-format-tables

Microsoft Learn: Formatting by Rules. Explains that the "Rules" option is used when needing to set a specific color based on discrete value ranges or percentages.

Source: https://learn.microsoft.com/en-us/power-bi/create-reports/desktop-conditional-format-tables#color-by-rules

The image displays the Power BI service interface. In the top navigation bar, next to the dashboard name "Customers," a tag labeled Sale is visible. This tag represents the shorthand for a data classification that has been applied to the dashboard. Tenant administrators can define these classifications to help users identify the sensitivity level of the data presented.

The main area of the screenshot shows the Power BI Q&A feature, which is being used on the "Customers" dashboard. The Q&A interface explicitly shows the heading INSURANCE above a list of data fields (e.g., insurance policies, customers, account ID). This heading indicates that "INSURANCE" is the name of the dataset the Q&A feature is currently querying to answer user questions for this dashboard.

Microsoft Power BI Documentation, "Data classification in Power BI": This document explains how administrators can set up data classification tags with a name and a shorthand. It states, "Once a classification type is selected, you'll see it displayed next to the dashboard title." This confirms that "Sale" is the shorthand for the data classification.

Microsoft Power BI Documentation, "Use Power BI Q&A to explore your data and create visuals": This source describes the Q&A feature. It clarifies that Q&A operates on the underlying dataset(s) associated with a dashboard or report. The fields and tables listed in the Q&A starting screen are pulled directly from that source dataset, which is named "INSURANCE" in the provided exhibit.

To denormalize the complex snowflake schema (Sales_Region -> Region_Manager -> Manager) into a single table, you should first create a new query. The action Merge [Sales_Region] and [Region_Manager] by using a right join as a new query... initiates this by combining the region and bridge tables; the right join ensures all defined region-manager relationships are preserved. Next, you flatten the hierarchy by performing Merge [Region_Manager] and [Manager] by using an inner join, which pulls in the Manager name details. Finally, to include the Sales_Manager data and consolidate the entire model, you perform Merge [Sales_Region] and [Sales_Manager] by using an inner join, which adds the sales manager attributes restricted to those associated with the sales regions.

Microsoft Learn: Shape and combine data in Power BI Desktop. "You can combine data from multiple sources... Merge queries creates a new query from two existing queries."

Source: https://learn.microsoft.com/en-us/power-bi/connect-data/desktop-shape-and-combine-data

Microsoft Learn: Merge queries overview. Describes how to merge tables (queries) based on matching columns and join kinds (Inner, Right, etc.) to denormalize data.

Source: https://learn.microsoft.com/en-us/power-query/merge-queries-overview

On-premises data gateway: An on-premises data gateway is only required if the data source is located within a private, on-premises network (e.g., a local SQL Server). For cloud-based data sources like Azure SQL, SharePoint Online, or public web feeds (like OData), Power BI can connect and refresh the data directly over the internet without needing a gateway. Therefore, a gateway is not always needed.

Scheduled refresh: When you publish a dataset to the Power BI service using Import mode, the data is a static copy taken at the time of publishing. To ensure the reports and dashboards reflect the latest information from the source, you must configure a scheduled refresh. This tells the Power BI service to periodically reconnect to the data source and update the dataset.

Basic authentication: Power BI supports multiple authentication methods for connecting to data sources. The available methods depend on what the specific data source supports. Basic authentication, which uses a username and password, is a common method supported by many data sources, including OData feeds, web APIs, and certain databases. Since it is a possible authentication method, the statement "You can use..." is true.

On-premises data gateway:

Microsoft Power BI Documentation, "What is an on-premises data gateway?". This document explicitly states, "The gateway is required if your dataset uses one or more on-premises data sources. The gateway isn't required if all of your dataset's data sources are in the cloud."

Data Refresh:

Microsoft Power BI Documentation, "Data refresh in Power BI", section "What can be refreshed?". This page clarifies that datasets using Import mode need to be refreshed to get updated data. It states, "When you refresh data, Power BI must query for updated data from the underlying data source and then load the updated data into the dataset."

Authentication Methods:

Microsoft Power BI Documentation, "Power Query OData feed connector", section "Connect to an OData feed from Power Query Desktop". This article lists the authentication options for the OData connector, which include Anonymous, Windows, Basic, Web API, and Organizational account. This confirms that Basic authentication is a supported option for at least one common data source type.

To provide summary statistics regarding data completeness (null counts) and value distributions (min, max, average), you should use the Table.Profile function in Power Query. First, you initiate the process by creating a blank query to house the custom script. Next, you input the M formula =Table.Profile(#"SalesDetail"), which generates a new table containing the required statistical profile for every column in the SalesDetail table. Finally, to make these insights accessible to end-users as requested, you create a visual (such as a standard table or matrix) on the report canvas using the output of the profiling query.

Microsoft Learn: Table.Profile. "Returns a description of the columns of the table... The resulting table includes the following columns: Column, Min, Max, Average, StandardDeviation, Count, NullCount, DistinctCount."

Source: https://learn.microsoft.com/en-us/powerquery-m/table-profile

Microsoft Learn: Profile data in Power BI. Discusses profiling capabilities and the underlying M logic used to assess column quality and distribution.

Source: https://learn.microsoft.com/en-us/power-bi/transform-model/data-profiling-power-bi

A line chart is the most effective visualization for showing the trend of a continuous value, such as account balances, over a period of time (quarters). Filtering to a specific category like "long-term liabilities" allows for focused analysis of how that component of the balance sheet is changing.

A ribbon chart is uniquely suited to show not only the value of different categories over time but also how their rank changes. This is ideal for a balance sheet, as it can clearly illustrate which accounts are growing or shrinking in proportion to others from one quarter to the next, providing insight into the changing financial structure.

B: A clustered column chart showing all account categories without filters would be visually cluttered and difficult to interpret, obscuring key trends.

C: While a column chart can show trends, a line chart (Option A) is generally the preferred and clearer visualization for continuous time-series data.

D: A pie chart is poor for time-series analysis and becomes unreadable with the numerous categories typical of a balance sheet, violating visualization best practices.

1. Microsoft Power BI Documentation

"Line charts in Power BI": "Line charts are a great choice... to visualize data over a long period of time." This supports using a line chart to show balances by quarter (Option A).

2. Microsoft Power BI Documentation

"Create ribbon charts in Power BI": "Ribbon charts are best for showing a category's rank change. The ribbon for the category with the highest rank (value) is always displayed on top of the other ribbons." This directly supports using a ribbon chart to analyze the changing composition and ranking of accounts over time (Option E).

3. Microsoft Power BI Documentation

"Visualization types in Power BI": This document describes the appropriate use cases for various visuals. It notes that pie charts are best with fewer than eight categories and that clustered column charts are for comparing multiple measures

which can become cluttered without filtering (supporting the rejection of Options D and B).

The proposed solution is incorrect. For semantic models using Import storage mode, the on-premises data gateway is only used during a scheduled or on-demand data refresh to pull data from the on-premises source into the Power BI service.

The dashboard cache update frequency controls how often dashboard tiles query the semantic model that is already hosted within the Power BI service. This process does not interact with the on-premises data source and therefore does not use the data gateway. To reduce data sent through the gateway, one would need to reduce the frequency of the semantic model refresh itself or reduce the volume of data being imported (e.g., by filtering rows or columns in Power Query).

A. Yes: This is incorrect because changing the dashboard cache update frequency does not affect the data transfer through the gateway for an Import mode model.

1. Microsoft Learn. (2024). Data refresh in Power BI.

Section: Semantic model refresh

Content: "When you refresh data

Power BI must query the underlying data sources... For data sources that reside on-premises in your organization's network

an on-premises data gateway is required to connect to them." This confirms the gateway's role is during the semantic model refresh.

2. Microsoft Learn. (2024). Data refresh in Power BI.

Section: Dashboard tile refresh

Content: "A dashboard tile refresh updates the cache for tile visuals on the dashboard

once data changes. This process happens about every hour... Tile refreshes don't trigger a semantic model refresh." This distinguishes dashboard updates from the semantic model refresh process that uses the gateway.

3. Microsoft Learn. (2023). Configure scheduled refresh.

Section: Gateway connection

Content: "If your semantic model connects to on-premises data sources

you must install and configure a data gateway to enable a connection to your data." This explicitly links the gateway's function to connecting to the on-premises source for the semantic model

which occurs during refresh.

The first step (#"Var1") is designed to filter out unnecessary columns. By using Table.RemovedColumns (representing the standard Table.RemoveColumns function), the query discards the Alternate Key and non-English names, ensuring that the EnglishProductCategoryName remains available for the subsequent step. The second step (#"Var2") uses a list of lists format ({{Old, New}}), which is the required syntax for Table.RenameColumns. This step renames the remaining English column to "Category" and the related table column to "Subcategory" to match the desired user-friendly model.

Microsoft Learn: Table.RemoveColumns. "Removes the specified columns from the table... Table.RemoveColumns(table as table, columns as any, optional missingField as nullable number) as table."

Source: https://learn.microsoft.com/en-us/powerquery-m/table-removecolumns

Microsoft Learn: Table.RenameColumns. "Returns a table with the columns renamed as specified... Table.RenameColumns(table as table, renames as list, ...)."

Source: https://learn.microsoft.com/en-us/powerquery-m/table-renamecolumns

The Azure DevOps (Boards only) connector in Power BI is specifically designed to connect to Azure DevOps Services (the cloud version) and leverage Analytics views. Analytics views provide a simplified way to specify and apply server-side filters to the data before it is loaded into Power BI. This directly meets the requirements to use Analytics views and filter data from the cloud, making it the most appropriate and efficient choice for creating a bug tracking dashboard.

A. OData queries: This is a method, not a specific connector. While the underlying connection uses OData, you would use a connector like 'OData feed' or the dedicated 'Azure DevOps' connector to execute them.

C. Azure DevOps Server (Boards only): This connector is for the on-premises version of Azure DevOps (formerly TFS), not the cloud service specified in the scenario.

D. OData feed: This is a generic connector. While Azure DevOps Analytics exposes an OData endpoint, the dedicated Azure DevOps (Boards only) connector is the recommended method as it simplifies authentication and is built to work directly with Analytics views.

1. Microsoft Learn. (2023). Connect to Analytics with the Power BI Data Connector.

Section: "Prerequisites" and "Connect with the Power BI Data Connector".

Content: This document explicitly states

"The Power BI Data Connector uses Analytics views." It then details the process of connecting to Azure DevOps from Power BI Desktop

showing the selection of the "Azure DevOps (Boards only)" connector to access and use pre-defined or custom Analytics views.

2. Microsoft Learn. (2023). About Power BI integration.

Section: "Supported connection options".

Content: This page compares the different methods for connecting Power BI to Azure DevOps. It highlights that the "Power BI Connector" is the preferred option for users with few or no T-SQL skills because it supports "Analytics views" which handle server-side filtering and data aggregation.

3. Microsoft Learn. (2023). What are Analytics views?.

Section: "Analytics view".

Content: This document defines Analytics views as a feature in Azure DevOps that "provides a simplified way to specify the filter criteria for a Power BI report based on Analytics data." This confirms that using Analytics views is the correct approach for server-side filtering.

To embed visualizations in a public website using the "Publish to web" feature, specific conditions must be met. The content must be a report, not a dashboard, and it must reside in an app workspace, not in "My Workspace".

Visual2 is a report in an app workspace, which is a valid configuration for public embedding.

Visual4 is also a report in an app workspace, created by a user with a Premium Per User (PPU) license, which also supports this feature.

Therefore, only Visual2 and Visual4 can be embedded into a public website.

A. Visual1: This report is in "My Workspace." The "Publish to web" feature is not available for content in "My Workspace."

C. Visual3: This is a dashboard and is in "My Workspace." "Publish to web" is not supported for dashboards or for content in "My Workspace."

E. Visual5: This is a dashboard. The "Publish to web" feature is only available for reports, not dashboards.

1. Microsoft Power BI Documentation

"Publish to web from Power BI":

Section: "How to use Publish to web" and "Limitations".

Content: The documentation explicitly states

"You can't publish to web from My Workspace." It also clarifies

"You can publish reports to the web. You can't publish dashboards or paginated reports to the web." This directly supports why Visuals 1

3

and 5 are incorrect and why Visuals 2 and 4 are correct.

2. Microsoft Learn

"Create and manage workspaces in Power BI":

Module: "Create and manage workspaces in Power BI"

Unit: "Distribute a report or dashboard"

Content: This module distinguishes between sharing methods. It details that "Publish to web" is a specific feature for reports in app workspaces intended for a public audience

contrasting it with content in "My Workspace

" which is for personal use.

3. Microsoft Power BI Documentation

"Power BI Premium Per User":

Section: "Feature comparison" table.

Content: The feature comparison table confirms that both Power BI Pro and Premium Per User (PPU) licenses have the capability for "Publishing to web (public)." This validates that the license type for Visual4 is sufficient.

The objective is to create a measure that calculates the number of deliveries based on the destination location. The provided data model shows an active relationship between Dim Location and Fact Deliveries on the origin location, and an inactive relationship on the destination location.

To perform a calculation using an inactive relationship, you must use the CALCULATE function to modify the filter context. The USERELATIONSHIP function is then used as a filter argument within CALCULATE to activate the specified inactive relationship for the duration of that specific calculation.

Therefore, the correct DAX expression is:

Deliveries by Destination = CALCULATE([Deliveries], USERELATIONSHIP('Dim Location'[Location ID], 'Fact Deliveries'[Destination Location ID]))

Microsoft Documentation, Data Analysis Expressions (DAX) Reference:

CALCULATE function: The documentation states, "Evaluates an expression in a modified filter context." This is the primary function needed to change how the [Deliveries] measure is calculated.

Source: Microsoft Docs, "CALCULATE function (DAX) - DAX".

USERELATIONSHIP function: The official documentation specifies, "USERELATIONSHIP specifies the relationship to be used in a specific calculation... It is used within functions that take a filter as an argument, such as the CALCULATE... functions." This confirms its role as the modifier inside CALCULATE to activate the inactive path.

Source: Microsoft Docs, "USERELATIONSHIP function (DAX) - DAX".

Russo, M., & Ferrari, A. (2020). Definitive Guide to DAX: Business intelligence for Microsoft Power BI, SQL Server Analysis Services, and Excel (2nd ed.). Microsoft Press.

Chapter 5, "Working with multiple tables": This chapter details the concept of active and inactive relationships. It explains that only one relationship between two tables can be active at a time and that USERELATIONSHIP must be used within a CALCULATE function to enable calculations over an inactive relationship. (Specific patterns are discussed in the "Multiple relationships between tables" section).

To meet the reporting requirement of counting the total number of sales, a measure is the correct DAX object to create. Measures are designed for aggregations and are calculated dynamically at query time based on the filter context of the report (e.g., slicers, visuals). The COUNTROWS(Sales) function is the most efficient and direct method to count the total number of rows in the 'Sales' table, where each row represents a distinct sales transaction. This approach provides an accurate, context-aware total for reporting visuals.

A. Summing an identifier column (salesid) is a meaningless calculation that does not represent a valid business metric.

B. A calculated column is inefficient for this purpose as it would store the same total count in every row, unnecessarily increasing model size.

D. This option combines two errors: performing a meaningless aggregation (SUM on an ID) and using an inefficient calculated column for a report-level aggregation.

1. Microsoft Learn. (2023). Use DAX in Power BI Desktop. In the "Tutorial: Create your own measures in Power BI Desktop" section

it is explained that measures are used for creating dynamic aggregation calculations. The example for counting order lines uses COUNTROWS('Sales')

directly supporting the chosen answer.

Reference: Module "Model data in Power BI"

Unit "Create DAX calculations in Power BI Desktop"

Section "Tutorial: Create your own measures in Power BI Desktop".

2. Microsoft Docs. (2023). COUNTROWS function (DAX). The official documentation states

"This function counts the number of rows in the specified table

or in a table defined by an expression." This confirms it is the correct function for counting transactions.

Reference: Data Analysis Expressions (DAX) reference

COUNTROWS function documentation.

3. Microsoft Learn. (2023). Calculated columns vs. measures. This documentation explicitly contrasts the two

stating

"Measures are used when you display resulting values in a report... that reflect user selections." This confirms a measure is the correct choice over a calculated column for this reporting scenario.

Reference: Module "Model data in Power BI"

Unit "Introduction to creating DAX calculations in Power BI Desktop"

Section "Calculated columns vs. measures".

Visual 1: Treemap A treemap is the ideal choice for displaying the distribution of hierarchical data. It represents data as a set of nested rectangles, where the size of each rectangle is proportional to a specific measure. This structure naturally visualizes the composition of the whole and the contribution of each hierarchical level, making it perfect for understanding distributions within a hierarchy.

Visual 2: Slicer A slicer is the standard Power BI visual used for filtering data on a report page. It allows users to select one or more values to filter other visuals. Critically, the slicer visual includes a built-in search functionality, which directly meets the requirement to "search and then filter by values."

Microsoft Learn, Power BI Documentation, "Treemaps in Power BI."

This document states, "Treemaps are charts of colored rectangles, with size representing value. They can be hierarchical, with rectangles nested within the main rectangles." This confirms their primary use for visualizing hierarchical data distribution.

Microsoft Learn, Power BI Documentation, "Slicers in Power BI."

The official documentation describes slicers as a way to filter other visuals on the page. In the section "Format slicers," it details the search option: "For some slicer types, you can format a search box... The search box is a great way to find items in a long list." This directly corresponds to the requirement for Visual 2.

The DAX functions RELATED and RELATEDTABLE are used to traverse relationships between tables to access data. Frequent use of these functions can indicate a highly normalized model, which may lead to complex DAX and potential performance issues. Merging tables in Power Query is a denormalization technique. By combining related tables into a single, wider table, the required columns become directly accessible within the same table context. This eliminates the need to use RELATED or RELATEDTABLE to navigate relationships, thereby simplifying the DAX expressions and often improving model performance.

B. Hiding columns only affects the report view for end-users. It does not change the underlying model structure or the need for DAX to traverse relationships for calculations.

C. Splitting the model into multiple models is a scalability strategy for very large datasets. It increases overall complexity and does not simplify the DAX within each model.

D. Transposing is a specific data shaping operation that swaps rows and columns. It is irrelevant to simplifying DAX expressions that depend on table relationships.

1. Microsoft Learn: Understand star schema and the importance for Power BI. In the section "Denormalize snowflake dimensions

" the documentation states

"A snowflake dimension should be denormalized into a single table... You can use Power Query to consolidate the columns... It's a process of denormalization." This directly supports merging tables to simplify the model.

2. Microsoft Learn: Merge queries (Power Query). This document describes the technical process of merging

which is the implementation of the recommended solution. It states

"a merge query joins two existing tables together based on matching values from one or multiple columns."

3. Microsoft Learn: DAX function reference: RELATED. The documentation for the RELATED function specifies that it "requires that a relationship exists... When the function follows a relationship... it examines the value... and fetches the value... from the specified column in the related table." This confirms that by merging

the need for the function is removed as the data is no longer in a "related table."