PL-300: Microsoft Power BI Data Analyst

To create one Products column from both tables, you must first load both Excel tables into Power Query. Next, use Append because append stacks rows from tables with the same schema; Merge is incorrect because it performs a join and is used to add columns based on matching keys. After appending, remove duplicates on the combined query so repeated values such as abc and mno appear only once. Removing errors is irrelevant because the scenario does not mention any errors, and removing duplicates before appending would not eliminate duplicates that exist across both tables.

The correct function to start this measure is CALCULATE because you need to re-calculate an existing measure ([Total Sales]) under a modified filter context (the prior-year dates). CALCULATE is the core DAX function for context transition and filter manipulation, which is exactly what time intelligence requires. Why the others are wrong: - EVALUATE is used in DAX queries (for example, in DAX Studio or SSMS) to return a table result; it is not used to define measures in Power BI. - SUM aggregates a column directly (for example, SUM(Sales[Amount])). Since you already have a measure [Total Sales], you should reuse it rather than re-summing a column. - SUMX is an iterator that evaluates an expression row-by-row over a table. It’s useful for calculated row logic, but it’s unnecessary and less efficient for a simple prior-year version of an existing measure.

SAMEPERIODLASTYEAR is the best match for “equivalent month of the previous year.” When the current filter context is a month (for example, March 2025), SAMEPERIODLASTYEAR returns the set of dates for March 2024, preserving the shape of the current period and shifting it back one year. Why the others are wrong: - DATESMTD returns dates from the start of the month to the current date in context (month-to-date), not the same month last year. - PARALLELPERIOD can shift periods (for example, -1 year), but the exam typically expects SAMEPERIODLASTYEAR for standard prior-year comparisons, and it’s more explicit for this scenario. - TOTALMTD is a wrapper that calculates a month-to-date total, which is not requested here (you want total sales for the equivalent month, not MTD).

You should pass the date column from the Date table into SAMEPERIODLASTYEAR, which is `Date`[Date]. Time intelligence functions require a column of type Date (or DateTime) from a proper date table to generate the correct set of shifted dates. Why the others are wrong: - [Date] is ambiguous because it doesn’t specify the table. In DAX, especially in models with multiple tables, you should fully qualify columns to avoid ambiguity and ensure the function uses the date dimension. - `Date`[Month] is not appropriate because it is typically a text or numeric month attribute and does not uniquely identify days. SAMEPERIODLASTYEAR operates on a contiguous set of daily dates; using a month column would break the required granularity and can produce incorrect or invalid results. Putting it together, the intended measure pattern is: Sales Previous Year = CALCULATE([Total Sales], SAMEPERIODLASTYEAR(`Date`[Date]))

Customer should be set to Dual. Customer is a dimension table that refreshes daily (so Import is feasible), but the model also contains a near real-time fact table (Sales) that must be DirectQuery. If Customer were Import only, queries that slice the DirectQuery Sales table by Customer could require cross-storage joins and may reduce performance or cause more DirectQuery activity. Dual allows Customer to act as Import for queries that can be answered from cached data (fast visuals) and as DirectQuery when it must interact with the DirectQuery Sales table, improving filter propagation and reducing query complexity. DirectQuery for Customer would meet refresh needs but would unnecessarily slow many visuals; Import alone risks poorer performance/behavior in composite scenarios.

Date should be set to Dual. Date changes extremely infrequently (once every three years), so Import would easily meet the refresh requirement and would be fast. However, because Sales is DirectQuery, Date is used to filter that DirectQuery fact table (e.g., by DueDateKey). Setting Date to Dual is a best practice in composite models: it behaves as Import for most queries (fast slicing, cached dimension) but can switch to DirectQuery behavior when needed to efficiently join/filter the DirectQuery Sales table. DirectQuery for Date would add unnecessary runtime queries for a small, stable dimension. Import-only can work, but Dual is preferred to minimize visual load times and avoid cross-storage penalties when interacting with DirectQuery facts.

Sales should be DirectQuery because it must be refreshed in near real time. Import mode cannot satisfy near real-time requirements unless you use very frequent refresh (which is limited by capacity/licensing and still not truly real time). DirectQuery queries the source at report time, reflecting the latest data with minimal delay, which aligns with the requirement. Dual is not appropriate for a large fact table that needs real-time behavior; Dual is primarily intended for dimension tables in composite models, not for the main detailed transactional fact. While DirectQuery can slow visuals, the model mitigates this by using an imported aggregation table (SalesAggregate) and Dual dimensions to accelerate common queries.

SalesAggregate should be Import. It only needs to refresh weekly, which aligns perfectly with scheduled refresh into the in-memory model. Import provides the best performance for visuals because VertiPaq can answer many queries quickly, and with the aggregations feature Power BI can hit the imported aggregate table for summarized queries instead of sending DirectQuery requests to the detailed Sales table. DirectQuery would not help because there is no near real-time requirement for the aggregate and it would reduce performance. Dual is unnecessary for a fact/aggregate table; Dual is mainly beneficial for shared dimensions. Therefore, Import best meets both requirements: weekly refresh and minimized visual load times.

A is correct because the required sequence for RLS is well-defined: 1) Import the data to Power BI Desktop (build the dataset/model). 2) Create a role definition (Modeling > Manage roles) using a DAX filter such as [Region] = "West" or a dynamic rule using USERPRINCIPALNAME() with a mapping table. 3) Publish the report (and dataset) to the Power BI service. 4) Assign users to the role in the Power BI service (Dataset > Security), ideally using Azure AD groups. The option “Add a filter to the report” is incorrect for this requirement because report filters are not security; they don’t prevent a user from accessing underlying rows if they have permissions, and they don’t enforce dataset-level restrictions. RLS roles are the correct mechanism when the question explicitly says “restrict access to individual rows… by using roles.”

Yes. SalesRowID and AuditID are technical/operational columns that do not help identify products bought together. Basket analysis requires grouping lines into a transaction (SalesOrderNumber) and identifying the products in that transaction (ProductKey), then optionally slicing by territory/date/customer. SalesRowID is a source-system row identifier (unique combination of SalesOrderNumber and SalesOrderLineNumber). Since SalesOrderNumber and SalesOrderLineNumber already exist, SalesRowID is redundant for analysis and not needed for relationships. AuditID tracks the ETL/load process that last updated the row; it is useful for data engineering troubleshooting but not for analytical grouping, filtering, or measures related to co-purchase behavior. Removing both columns reduces model size and can improve refresh/query performance without impeding the stated analysis goals.

No. Both OrderDateKey and OrderDate are not necessary for basket analysis. In a star schema, OrderDateKey is typically used to relate the Sales fact table to a Date dimension (which then provides year/quarter/month/day attributes for slicing). For basket analysis across time, that relationship is sufficient. The OrderDate (datetime) column is often redundant if you already have a proper Date dimension and do not need time-of-day granularity. Basket analysis is usually performed at the transaction level (SalesOrderNumber) and may be filtered by date, but that can be done via the Date dimension using OrderDateKey. You would keep OrderDate only if you specifically need the timestamp (hours/minutes) or if you lack a Date dimension/relationship. Given the prompt states related dimension tables are imported, OrderDateKey alone is enough.

No. TaxAmt does not need to retain the current number of decimal places to perform basket analysis. Basket analysis primarily evaluates which products co-occur in the same order; it relies on transaction identifiers and product identifiers, and sometimes quantities. Tax amount precision is not part of determining whether two products were bought together. Even if you were to include value-based metrics (e.g., total basket value), you could typically round currency values to a sensible precision (often 2 decimal places) without changing the co-occurrence results. In many basket-analysis models, TaxAmt is not required at all and could be removed to optimize the model. Therefore, retaining the exact current decimal precision is not a requirement for achieving the stated analysis goal.

At the year level, the filter context includes all dates in that year. LASTDATE('Date'[Date]) returns only the final date of that year (e.g., 31-Dec for calendar year, or the last day of the financial year if the hierarchy uses financial year boundaries). CALCULATE then evaluates DISTINCTCOUNT(Balances[AccountID]) only for that single last date. So the visual will show the number of accounts that were live on the last day of the year, not the number of accounts that were live throughout the year. “Live throughout the year” would require accounts to have Balances rows for every day in the year (or to meet a start/end date condition spanning the whole year), which this measure does not test. Therefore, the statement is false.

At the month level, the filter context includes all days in the selected month. LASTDATE returns the last day of that month in the current context. The measure then counts distinct accounts present in Balances on that last day only. That result is not “the total number of accounts that were live throughout the month.” It is “accounts live on the last day of the month.” Accounts that were active earlier in the month but closed before month-end will be excluded, and accounts opened mid-month but still active at month-end will be included (even though they were not live for the full month). To compute “throughout the month,” you’d need logic ensuring the account appears on every day of the month (or spans the full month). Hence, No.

At the day level, the filter context is already a single date (each row in the table visual corresponds to one day). In that context, LASTDATE('Date'[Date]) returns that same date. Therefore, CALCULATE applies a filter that effectively keeps the same single day. Because Balances contains a daily record for every account that is live on that day, DISTINCTCOUNT(Balances[AccountID]) for that date returns the number of accounts live that day. This matches the statement exactly. Therefore, Yes.

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.

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).