Practice Test #3

Pass is appropriate because the transformation sequence is determinable from the scenario and the listed actions. The required end state is a long table with columns like Department, Product, Year, Revenue. To get there, you must (1) promote the first row to headers so the year columns are correctly named (2016, 2017, 2018, 2019) rather than Column1–Column6; (2) select Department and Product and use Unpivot Other Columns to convert all year columns into rows (this is preferred over Unpivot Columns because it automatically includes any additional year columns that may appear later); and (3) rename Attribute to Year and Value to Revenue so the columns are semantically correct for modeling and visuals. Therefore, the correct response is that you know the answer (Pass).

The calculated column must first capture the current row's Sales value, then identify the matching row in the Transaction Size table where the amount falls between Min and Max. FILTER is required to return the matching range row(s), and AND is required so both boundary conditions are true at the same time. CALCULATE then evaluates DISTINCT('Transaction Size'[Transaction Size]) in the context of that filtered row, returning Small, Medium, or Large. ALL is incorrect because it removes filters rather than applying the range match, OR would match too many rows, and SUM is unnecessary because this is a row-by-row calculated column using the current Sales value.

Use Merge because you need to combine columns from Categories into Products by matching rows on a key (CategoryID). In Power Query, Merge performs a join (typically Left Outer from Products to Categories) and returns a new column containing a nested table of matching category rows, which you then expand to bring in CategoryName and CategoryDescription. Append is incorrect because it stacks rows from two queries with similar schemas; it does not match on keys and would produce more rows rather than add category attributes to each product. Transpose is unrelated; it swaps rows and columns and is used for reshaping data orientation, not relational combination. Therefore, Merge is the only option that produces a single Product table with the required additional category columns based on CategoryID.

Disable the query load for Categories. You still need the Categories query to exist in Power Query so the Products query can merge against it during refresh, but you do not want Categories to appear as a separate table in the dataset because the requirement is a single table named Product. Deleting the query would break the merge (or require embedding the logic elsewhere), making it harder to maintain and potentially invalidating the transformation steps. Excluding the query from report refresh is not appropriate because the merge depends on Categories being evaluated during refresh; if it does not refresh, the Product table could become stale or the transformation could fail. Disabling load is the standard staging-query pattern: keep it for transformations, don’t load it to the model.

Yes. You must update the *Dashboard mobile layout* because the requirement is explicitly about how the dashboard renders on a mobile device. In Power BI, dashboards have a dedicated mobile layout editor in the Power BI service that lets you choose which tiles appear on mobile and how they are arranged. Without editing the dashboard mobile layout, the mobile app will either use an automatic/default tile flow or an existing mobile layout that may not match the desired design. The Mobile exhibit shows a deliberate arrangement (two KPI tiles side-by-side, then the bar chart, then the map), which is exactly what the dashboard mobile layout is intended to control.

No. You do not need to update the *Dashboard web layout* because the goal is only to control the appearance on mobile devices. The web layout is what users see in a browser and is independent of the dashboard mobile layout. Power BI allows you to keep the web layout optimized for large screens (as shown in the Dashboard exhibit) while separately designing a mobile-friendly layout. Changing the web layout would be unnecessary and could negatively impact the desktop/browser experience without providing additional benefit for the mobile requirement.

No. You do not need to update the *Report mobile layout* because the visuals shown are on a *dashboard* (tiles pinned from reports), not a report page being viewed directly. Report mobile layout is configured in Power BI Desktop for report pages and affects how a report page renders in the mobile app when users open the report. However, when users open a dashboard in the mobile app, the dashboard’s own mobile layout rules apply. Therefore, editing report mobile layout would not ensure the dashboard appears like the Mobile exhibit.

Yes. The SubTotal map tile must be resized and moved in the dashboard mobile layout to match the Mobile exhibit. On the web dashboard, the map is wide and placed across the bottom. On mobile, the available width is limited, and the exhibit shows the map positioned below other tiles in a vertical flow. To achieve that exact placement and sizing, you must explicitly drag and resize the map tile within the dashboard mobile layout editor. If you don’t, the map may appear too large, too small, or in an unintended order relative to the KPI and bar chart tiles.

Yes. The Total Sales and Total Quantity tiles must be resized and moved in the dashboard mobile layout. The Mobile exhibit shows these two KPI tiles aligned side-by-side at the top, each occupying roughly half the screen width. This is not guaranteed by default behavior; it requires manual placement and sizing in the mobile layout grid. If you leave them unmodified, they may stack vertically or appear in a different order/size, which would not match the required mobile appearance.

Yes. The Total Sales by Parent Category tile must be resized and moved in the dashboard mobile layout. In the web layout, it appears to the right of the KPI cards. In the Mobile exhibit, it is placed below the KPI cards and resized to fit the narrower mobile canvas. Achieving that specific arrangement requires editing the dashboard mobile layout and adjusting the tile’s position and dimensions. Without resizing/moving it, the chart could be truncated, appear in the wrong sequence, or consume an inappropriate amount of vertical space.