Practice Test #2

Yes. A dashboard in Power BI is composed of tiles, and those tiles typically come from existing report visuals (or live pages) that you pin in the Power BI service. Since the requirement is to use existing reports to build a dashboard, pinning is the foundational step that actually creates the dashboard content. Without pinning items, there is nothing to arrange in the dashboard (including in the mobile layout). Why not No: If you skip pinning, you would only be editing an empty dashboard or not have a dashboard at all. Even if a dashboard already exists, you still need to pin the specific visuals you want users to see frequently on mobile. Pinning is therefore required to meet the scenario’s goal of building a mobile-consumable dashboard from existing reports.

Yes. After pinning items (which creates/populates the dashboard), you must open the dashboard to access its settings and edit experiences, including the Mobile view. The mobile layout editor is accessed from within the dashboard in the Power BI service. Why not No: You cannot edit a dashboard’s mobile view without being in the context of that dashboard. While you can pin directly from a report visual and choose an existing/new dashboard, the step of opening the dashboard is necessary to proceed to mobile-specific layout editing and to validate the final portrait phone experience.

No. Creating a phone layout for existing reports is a report-level optimization done in Power BI Desktop (View > Mobile layout). That feature controls how report pages render in the Power BI mobile app, not how a dashboard’s tiles are arranged on a phone. Why not Yes: The question is specifically about building a dashboard from existing reports and having that dashboard viewed frequently on mobile phones in portrait mode. For dashboards, the correct feature is editing the dashboard Mobile view in the Power BI service. Report phone layout could still be useful if users also open the underlying reports on mobile, but it is not required to build and optimize the dashboard itself, so it is not part of the necessary sequence.

Yes. To optimize a dashboard for portrait mode on mobile phones, you use the dashboard’s Mobile view editor in the Power BI service. This provides a dedicated canvas representing a phone screen where you choose which pinned tiles appear and how they are arranged for mobile consumption. Why not No: If you only rely on the default dashboard layout, the mobile experience may be suboptimal (tiny tiles, poor ordering, excessive scrolling). The requirement explicitly calls out frequent viewing on mobile in portrait mode, which strongly implies you should tailor the Mobile view to prioritize key KPIs and improve usability.

Yes. After entering the dashboard Mobile view editor, you must rearrange, resize, or remove items to create an effective portrait phone layout. This is the step where you implement the actual mobile-first design: placing the most important KPIs at the top, resizing tiles for readability, and removing nonessential visuals to reduce scrolling. Why not No: Simply opening Mobile view without adjusting the layout does not meet the requirement to build a dashboard that is optimized for frequent mobile viewing. The exam expects you to recognize that mobile optimization is an explicit design activity, not an automatic outcome of pinning tiles.

Answer: A (Pass). Correct sequence of actions to ensure analysts see appropriate P&L data via RLS is: 1) From Power BI Desktop, create four roles. 2) From Power BI Desktop, add a Table Filter DAX Expression to the roles. 3) From Power BI Desktop, publish the dataset to powerbi.com. 4) From powerbi.com, add role members to the roles. Why this is correct: RLS roles and their DAX filters must be authored in Desktop as part of the dataset definition. Publishing moves the secured dataset to the service. Only after publishing can you assign users/groups to those roles in the Power BI service so enforcement occurs at query time. Why the Contributor workspace role option is wrong: workspace permissions govern authoring/management, not row-level data visibility. Also, Contributors/Members can potentially bypass RLS in the workspace, which is the opposite of “ensure appropriate data visibility.”

Yes. To meet typical report requirements such as showing “Top Customers” based on order metrics, Power BI must be able to filter and aggregate Orders by customer attributes stored in the Customer Details worksheet. The standard approach is a one-to-many relationship: Customer Details[CustomerID] (dimension, unique) -> Orders[CustomerID] (fact, repeating). Without this relationship, customer-level fields (like Customer Name or Region from Customer Details) will not correctly filter the Orders table, leading to incorrect totals or requiring complex DAX (e.g., TREATAS) to simulate relationships. In exam scenarios, when you have a Customer table and an Orders table, the expected modeling step is to relate them on CustomerID to form a star schema. This improves model clarity, reduces ambiguity, and supports efficient filter propagation from dimension to fact.

No. The columns used in a relationship must have the same data type, but they do not specifically have to be Text. The correct choice depends on the nature of CustomerID in the source data. If CustomerID is numeric and has no leading zeros, Whole Number is typically preferred for performance and storage efficiency. If CustomerID can contain letters, hyphens, or leading zeros that must be preserved (e.g., “000123”), then Text is appropriate. Power BI will not allow a relationship between mismatched data types (e.g., Text to Whole Number) without conversion, but the requirement is consistency, not Text. Therefore, stating that the data type “must be set to Text” is too prescriptive and not universally true.

No. The Region field used to filter a “Top Customers” report should come from the Customer Details (dimension) table, not from the Orders (fact) table. Region is a descriptive attribute of the customer and is typically stable compared to transactional data. Storing Region in Orders would duplicate the value across many rows, increasing model size and risking inconsistencies (e.g., if a customer’s region changes or if historical orders contain different region values). Using Region from the Customer dimension aligns with star schema best practices: dimensions provide slicers/filters; facts provide measures. With the CustomerID relationship in place, filtering by Customer Details[Region] will correctly filter Orders and produce accurate “Top Customers” results.