Knowledge + Practice

Microsoft Power BI Data Analyst PL-300 (PL-300) — Questions 1–75

217 questions total · 3pages · All types, answers revealed

Take a mock exam Exam hub

Page 1 of 3

1

MCQeasy

You have a Power BI dataset that uses Import mode and refreshes daily. The source data includes a column 'LastModifiedDate'. You want to reduce the amount of data loaded during each refresh by only loading rows that have changed since the last refresh. Which feature should you configure?

A.Enable query folding in Power Query.

B.Use the 'Reduce data' option in Power Query Editor.

C.Change the storage mode to DirectQuery.

D.Configure incremental refresh on the table using the 'LastModifiedDate' column.

AnswerD

Incremental refresh creates named date/time range partitions on a table and, during refresh, loads only new or modified partitions (e.g., the last N days) rather than the entire table. By using a 'LastModifiedDate' column, the refresh engine can detect which rows have changed and only refresh those historical partitions, dramatically reducing refresh time and data transfer. This requires using a Refresh Policy in Power Query (e.g., RangeStart and RangeEnd parameters) and the table must have a date/time column that records when each row was last modified.

Why this answer

Incremental refresh in Power BI allows you to filter data by a date/time column (such as 'LastModifiedDate') so that only rows that have changed since the last refresh are loaded. This reduces refresh time and data volume while still using Import mode. The feature requires a date/time column and a properly configured policy in the Power Query Editor.

Exam trap

The trap here is that candidates often confuse incremental refresh with query folding or 'Reduce data' options, not realizing that incremental refresh is the only feature designed to load only changed rows in Import mode while keeping the dataset in Import mode.

How to eliminate wrong answers

Option A is wrong because query folding pushes transformations back to the source database, but it does not selectively load only changed rows; it still processes the entire dataset. Option B is wrong because 'Reduce data' is not a built-in Power Query Editor feature; the correct option for reducing loaded data is incremental refresh. Option C is wrong because changing storage mode to DirectQuery avoids importing data entirely, but the question specifies Import mode and wants to reduce data loaded during refresh, not switch to a live query mode.

Full explanation →

2

MCQeasy

A company has a fact table with sales data and multiple dimension tables. They want to create a measure that calculates the total sales amount for the current year, but the measure returns incorrect results when used in a visual with a date hierarchy. What is the most likely cause?

A.The date table is not marked as a date table in Power BI.

B.The fact table is not in a star schema; it is snowflaked.

C.The relationship between the date table and the fact table is inactive.

D.The relationship between the date table and the fact table is set to bidirectional cross-filtering.

AnswerC

If the relationship between the date table and the fact table is inactive, the date table's columns will not automatically filter the fact table because an inactive relationship is ignored during normal filter propagation. A visual that uses a date hierarchy from the date table will still display dates, but the measure values will be evaluated without that date context—often showing the grand total or a blend of all dates—so the results appear correct in shape but are numerically wrong. The only way to apply the filter is to explicitly activate the relationship in DAX using USERELATIONSHIP, which the user has evidently not done.

Why this answer

If the relationship between the date table and the fact table is inactive, measures that rely on time intelligence functions (like TOTALYTD, SAMEPERIODLASTYEAR, or a simple SUM with date filtering) will not automatically propagate filters from the date hierarchy to the fact table. In Power BI, only one active relationship can exist between two tables; inactive relationships require explicit activation via USERELATIONSHIP in DAX. Without that, the measure ignores the date filter and returns incorrect or blank results.

Exam trap

The trap here is that candidates often assume any relationship between tables will automatically filter, but Power BI requires exactly one active relationship per pair of tables, and inactive relationships are ignored unless explicitly activated in DAX.

How to eliminate wrong answers

Option A is wrong because marking a table as a date table is not required for basic time intelligence; it only enables automatic date hierarchy creation and certain time intelligence functions to work correctly, but it does not cause incorrect results in a visual with a date hierarchy if the relationship is active. Option B is wrong because a snowflake schema does not inherently break time intelligence; it may affect performance or model complexity, but it does not cause a measure to return incorrect results due to filter propagation. Option D is wrong because bidirectional cross-filtering would actually strengthen filter propagation, not cause incorrect results; it might lead to ambiguity or unexpected filtering, but it would not cause the measure to ignore the date filter entirely.

Full explanation →

3

Multi-Selectmedium

You are creating a Power BI report from a SQL Server database that contains a table Orders with columns: OrderDate, CustomerID, ProductID, Quantity, UnitPrice. You need to build a star schema. Which THREE tables should you create? (Choose three.)

Select 3 answers

A.OrderDetails table with line items.

B.Date dimension table with date attributes.

C.Product dimension table with product attributes.

D.Customer dimension table with customer attributes.

E.Sales fact table with measures.

AnswersB, C, D

A Date dimension table is essential for time intelligence in Power BI, as it provides a contiguous set of dates with attributes like year, quarter, month, and week. By marking it as the date table, DAX functions such as TOTALYTD and SAMEPERIODLASTYEAR can perform time-based calculations correctly. Without a dedicated Date dimension, filtering by fiscal periods or comparing periods across years becomes unreliable, especially if the fact table has gaps in dates.

Why this answer

In a star schema, dimension tables contain descriptive attributes (e.g., dates, products, customers) and are connected to a central fact table. For the Orders table, a Date dimension (B) is essential for time-based analysis, a Product dimension (C) provides product details, and a Customer dimension (D) stores customer attributes. These three dimensions normalize the data and enable efficient slicing and dicing in Power BI.

Exam trap

The trap here is that candidates often confuse dimension tables with fact tables or think that line-item details (Option A) should be a separate dimension, when in fact they belong in the fact table to maintain a star schema's simplicity and performance.

Full explanation →

4

MCQeasy

You have a Power BI dataset that uses data from Microsoft Excel files stored in SharePoint Online. Users report that the data is not refreshing as scheduled. You verify that the gateway is installed and running. What is the most likely cause of the refresh failure?

A.The gateway is not running.

B.The gateway does not support SharePoint Online data sources.

C.The gateway is not configured to use the on-premises data source type.

D.The data source credentials are not provided in the gateway.

AnswerD

This is the correct diagnosis: the gateway is running, but the SharePoint Online data source lacks stored credentials in the gateway's data source management settings. Without those credentials, the gateway cannot authenticate to SharePoint Online during a scheduled refresh, resulting in a failure. You need to add the data source and fill in the appropriate authentication method (e.g., OAuth2) to resolve it.

Why this answer

Even when the gateway is installed and running, it must have valid data source credentials configured for the SharePoint Online Excel files. Without these credentials, the gateway cannot authenticate to SharePoint Online to retrieve the data, causing the scheduled refresh to fail. The gateway uses the stored credentials to connect to the data source during each refresh cycle.

Exam trap

The trap here is that candidates assume a running gateway automatically handles all data sources, but the gateway requires explicit credential configuration for each data source, including cloud-based ones like SharePoint Online.

How to eliminate wrong answers

Option A is wrong because the question explicitly states that the gateway is installed and running, so this cannot be the cause. Option B is wrong because the on-premises data gateway fully supports SharePoint Online as a data source when configured correctly, as it can connect to cloud services via the gateway's cloud-to-on-premises bridging. Option C is wrong because SharePoint Online is a cloud-based data source, not an on-premises data source type; the gateway handles cloud data sources like SharePoint Online through its standard cloud connector configuration, not through an on-premises data source type.

Full explanation →

5

MCQmedium

Your Power BI model includes a calculated column that concatenates first and last name. Users report that the column shows blank for some rows. The data source has no nulls. What is the most likely cause?

A.Data type mismatch between the two columns

B.The columns are from different tables without a relationship

C.The relationship between tables is set to single direction

D.One of the columns contains only spaces

AnswerD

If one column contains only spaces (for example, a person's last name field holding `" "`), the concatenated result is a string composed entirely of whitespace. Because DAX does not automatically trim leading or trailing spaces in concatenation, the resulting column looks empty in visuals and may be treated as blank by later functions, even though it is not a true BLANK. This explains why the calculated column appears blank while actually holding a space-only value.

Why this answer

A column containing only spaces (e.g., ' ') is not null, but when concatenated with another name, the result may appear blank if the concatenation results in pure whitespace or if the column is trimmed before concatenation. Option A is incorrect because data type mismatch would typically cause an error, not a blank result. Option B is incorrect because the data source has no nulls, so missing rows are not the issue.

Option C is incorrect because relationship direction does not affect calculated columns within the same table.

Full explanation →

6

MCQeasy

A Power BI report includes a bar chart showing total sales by product category. The report designer wants to add a trend line to the chart to show the overall sales trend over time. Which type of visual should be used instead?

A.Stacked bar chart

B.Line chart

C.Scatter chart

D.Pie chart

AnswerB

A line chart encodes data points along a continuous time axis and connects them with straight lines, allowing the eye to perceive direction, rate of change, and periodicity. Because the x-axis is continuous and time-ordered, Power BI can compute and overlay a trend line using linear regression, moving average, or other built-in analytics in the Analytics pane. It is the default and recommended visual for time-series trend analysis because it preserves the sequential structure of the data.

Why this answer

A line chart is the correct visual to show a trend over time because it plots data points connected by straight lines, making it easy to see the overall direction and pattern of total sales across a continuous time axis. Bar charts, including stacked variants, are designed for comparing discrete categories, not for displaying continuous trends.

Exam trap

The trap here is that candidates may think a bar chart with a trend line added via the analytics pane is acceptable, but the question asks which visual should be used instead, implying the bar chart is not the optimal choice for showing a trend over time.

How to eliminate wrong answers

Option A is wrong because a stacked bar chart is used to show the composition of a total across categories over time or groups, not to display a single trend line for total sales. Option C is wrong because a scatter chart is used to show the relationship between two numerical variables, not to display a single metric's trend over time. Option D is wrong because a pie chart shows proportions of a whole at a single point in time and cannot represent trends over time.

Full explanation →

7

MCQhard

You are reviewing the deployment configuration for a Power BI dataset. The exhibit shows a JSON snippet of the dataset settings. You need to ensure that data is refreshed twice a day at 6:00 AM and 6:00 PM UTC. However, the refresh fails at both scheduled times. What is the most likely cause?

A.The data source uses Integrated Security (SSPI) which is not supported for scheduled refresh.

B.The refresh schedule uses UTC but the data source is in a different time zone.

C.The dataset has DirectQuery enabled, which prevents Import mode refresh.

D.The gateway ID is incorrect.

AnswerA

Integrated Security (SSPI) depends on the interactive user's Windows token to authenticate to the data source. In the Power BI service, scheduled refresh runs under a non-interactive service account, so there is no Windows identity to pass through. The service requires explicit stored credentials (e.g., SQL Server authentication or OAuth) for scheduled refresh, not SSPI. Because the data source is configured for SSPI, the refresh fails at the credential validation step.

Why this answer

Scheduled refresh in Power BI requires a gateway to connect to on-premises data sources, and when the data source uses Integrated Security (SSPI), the gateway cannot delegate credentials for scheduled refresh. SSPI relies on the user's interactive Windows authentication context, which is not available during unattended scheduled refresh operations. This causes the refresh to fail at both scheduled times.

Exam trap

The trap here is that candidates often assume time zone mismatches or DirectQuery settings cause refresh failures, but the real issue is that Integrated Security (SSPI) requires interactive user context and is not supported for unattended scheduled refresh without proper delegation configuration.

How to eliminate wrong answers

Option B is wrong because time zone differences do not cause refresh failures; the refresh schedule simply runs at the specified UTC times regardless of the data source's time zone. Option C is wrong because DirectQuery does not prevent Import mode refresh; a dataset can have both DirectQuery and Import partitions, and scheduled refresh applies only to Import mode tables. Option D is wrong because an incorrect gateway ID would cause a connection error at the time of refresh, but the question states the refresh fails at both scheduled times, which is consistent with a credential delegation issue rather than a gateway misconfiguration.

Full explanation →

8

Multi-Selectmedium

You are importing data from a SQL Server database. The source table has a column 'ModifiedDate' of type datetime2. In Power Query, you want to ensure that only rows modified within the last 7 days are loaded. Which THREE steps should you take?

Select 3 answers

A.Load all rows and then use a DAX filter in the data model.

B.Use a parameter for the date range and reference it in the filter.

C.Split the column into date and time and then filter on the date part.

D.In Power Query, add a filter step using a custom column or the filter row feature.

E.Use a native SQL query with a WHERE clause to filter at the source.

AnswersB, D, E

A Power Query parameter, such as a date range or a scalar date value, can be referenced directly in the filter row step of a query. This makes the filter dynamic and easy to update without editing M code, and when the source is a SQL database, the filter step often folds into the generated SQL statement, reducing the amount of data imported. Parameterizing the date also supports scheduled refresh scenarios, where the filter value can be changed via the API or in the service, and it avoids hard-coded values scattered across steps.

Why this answer

Using a parameter for the date range and referencing it in the filter allows for dynamic, maintainable filtering in Power Query. This approach leverages Power Query's M language to apply a filter step that can be easily updated without modifying the query logic, ensuring only rows from the last 7 days are loaded during data refresh.

Exam trap

The trap here is that candidates often think splitting a datetime column is necessary for date-based filtering, but Power Query's native filter on datetime2 works correctly and is more efficient, while loading all rows and using DAX is a common anti-pattern that wastes resources.

Full explanation →

9

MCQmedium

You have a Power BI semantic model that uses DirectQuery to an Azure Synapse Analytics dedicated SQL pool. The model is used by a real-time dashboard. Users report that the dashboard is slow. You need to improve query performance without changing the source system. Which action should you take?

A.Create aggregations on the fact table

B.Reduce the number of visuals on the dashboard and apply page-level filters

C.Enable dual storage mode for all tables

D.Disable the 'Reduce queries' option in Power BI Desktop

AnswerB

Reducing the number of visuals on a DirectQuery dashboard directly reduces the number of separate DAX queries that Power BI sends to the underlying data source, because each visual in DirectQuery mode issues its own live query when rendered. Applying page-level filters constrains the rowset returned for all visuals on that page, which lowers the data volume and speeds up each query. Together these actions are a simple, immediate way to lower query load without changing the data model.

Why this answer

Reducing the number of visuals and applying page-level filters directly reduces the number of queries sent to the Azure Synapse Analytics dedicated SQL pool via DirectQuery. Since the source system cannot be changed, the only way to improve performance is to minimize the query load from the dashboard. Page-level filters ensure that only relevant data is queried, and fewer visuals mean fewer separate queries, which collectively reduces latency.

Exam trap

The trap here is that candidates often assume performance improvements must come from data modeling changes (like aggregations or storage modes), but the question explicitly forbids changing the source system, so the only viable approach is to reduce the query load from the client side.

How to eliminate wrong answers

Option A is wrong because creating aggregations on the fact table would require modifying the source system (the Azure Synapse Analytics dedicated SQL pool), which is explicitly prohibited by the question. Option C is wrong because enabling dual storage mode for all tables would force some tables to import data into memory, which changes the storage mode and violates the constraint of not changing the source system; moreover, dual storage mode can increase complexity and may not improve performance for DirectQuery models. Option D is wrong because disabling the 'Reduce queries' option in Power BI Desktop would actually increase the number of queries sent to the source, worsening performance; this option is designed to reduce query redundancy, so disabling it is counterproductive.

Full explanation →

10

MCQhard

Refer to the exhibit. You have a DAX measure that calculates customer lifetime value (CLV) as total revenue divided by distinct customer count. When you use this measure in a visual with Product category, you notice that the CLV values are higher than expected. What is the most likely reason?

A.The measure does not filter out returns

B.The measure counts customers per category, but customers who buy multiple categories are counted in each category, reducing the denominator

C.The measure should use COUNTROWS instead of DISTINCTCOUNT

D.The measure is dividing by zero for categories with no customers

AnswerB

This inflates CLV per category.

Why this answer

The CLV measure is defined as total revenue divided by distinct customer count. When this measure is used in a visual with Product category, the context filters both the revenue and the customer count to that category. The DISTINCTCOUNT(CustomerID) returns the number of customers who purchased at least one product in that category.

If a customer buys multiple categories, they are counted in each category's distinct count. This makes the denominator per category smaller than the total distinct customer base, leading to a higher CLV value than expected. Option A is incorrect because returns would reduce revenue, not cause higher CLV.

Option C is incorrect because using COUNTROWS would count transaction rows, not distinct customers, making the denominator larger and CLV smaller. Option D is incorrect because DIVIDE handles division by zero, and the scenario does not involve zero customers.

Full explanation →

11

MCQeasy

You are connecting to an Azure SQL Database from Power BI Desktop. The database contains a view that returns thousands of rows. You only need the last 100 rows for analysis. What is the most efficient way to reduce the data loaded?

A.Write a native SQL query with a WHERE clause to limit rows

B.Use DirectQuery mode and add a filter in the report

C.Import all rows and then remove rows in Power Query

D.Use the 'Keep Top Rows' transformation in Power Query after applying a sort

AnswerD

Applying a sort step followed by Keep Top Rows in Power Query is the optimal approach because the M engine can fold these transformations into a single SELECT TOP (N) ORDER BY statement on Azure SQL. This ensures that only the top N rows are fetched from the database, drastically reducing data transfer and load time. Additionally, the transformation remains declarative and reusable, and it aligns with best practices for source-side filtering in Power BI.

Why this answer

It uses Power Query's 'Keep Top Rows' transformation after sorting the view by the desired order (e.g., descending on a date column). This approach pushes the sort and row-limiting logic to the source database via query folding, ensuring only the last 100 rows are transferred over the network, which is the most efficient method for reducing data loaded.

Exam trap

The trap here is that candidates may think a native SQL query (Option A) is always the most efficient, but they overlook that Power Query's query folding can achieve the same result with better integration and maintainability, while a poorly written SQL query without proper sorting would not correctly retrieve the 'last' rows.

How to eliminate wrong answers

Option A is wrong because writing a native SQL query with a WHERE clause to limit rows does not guarantee you get the 'last' 100 rows unless you also specify an ORDER BY clause; a WHERE clause alone cannot select the last rows without a deterministic sort order, and it may require complex subqueries that are less efficient than query folding. Option B is wrong because DirectQuery mode does not reduce the data loaded into Power BI; it sends queries to the database on demand, but the filter is applied at query time, not during data loading, and it does not minimize the initial data transfer for the view—it still requires the database to process the full view before applying the filter. Option C is wrong because importing all rows and then removing rows in Power Query is inefficient; it transfers the entire dataset (thousands of rows) over the network and into memory, defeating the purpose of reducing data loaded.

Full explanation →

12

MCQhard

You have a Power BI semantic model that uses Import mode with a SQL Server data source. The refresh takes over two hours. You need to reduce the refresh time while keeping data up-to-date. What is the best strategy?

A.Switch the data source to DirectQuery mode.

B.Remove unnecessary columns and rows from the query.

C.Configure incremental refresh policy on the fact table.

D.Reduce the scheduled refresh frequency to once a day.

AnswerC

Configuring incremental refresh on the fact table is the correct approach because it partitions data by date using RangeStart and RangeEnd parameters, so only new and updated rows are loaded during each scheduled refresh. This dramatically cuts the data processed per refresh cycle, especially for a fact table accumulating transactional data over time. It requires at least one date column and enables the 'refresh policy' capability in Power BI to manage historical and current partitions separately.

Why this answer

Incremental refresh policy allows you to refresh only the most recent data (e.g., last 5 days) while keeping historical partitions unchanged, drastically reducing the amount of data loaded during each refresh. This is the most effective way to reduce refresh time in Import mode while maintaining data freshness, as it avoids re-querying the entire fact table from SQL Server.

Exam trap

The trap here is that candidates often confuse reducing refresh frequency (Option D) with reducing refresh time, or they think DirectQuery (Option A) is a universal performance fix, when in fact it shifts the performance burden to query time and sacrifices Import mode capabilities.

How to eliminate wrong answers

Option A is wrong because switching to DirectQuery mode would eliminate the import process but would introduce query-time performance issues and remove the ability to use many Power BI features (e.g., time intelligence, calculated tables); it does not reduce refresh time but changes the data access model entirely. Option B is wrong because removing unnecessary columns and rows is a general optimization that can help, but it does not address the core issue of a large fact table that takes over two hours to refresh; the primary bottleneck is the volume of historical data, not just extraneous fields. Option D is wrong because reducing scheduled refresh frequency to once a day would not reduce the refresh time itself; it only makes the data less current, which contradicts the requirement to keep data up-to-date.

Full explanation →

13

MCQmedium

You are a Power BI administrator. A user reports that their scheduled data refresh fails with error 'The data source credentials are no longer valid.' The dataset uses a SQL Server database with Windows authentication. What should you do first to resolve the issue?

A.Reinstall the on-premises data gateway on the server.

B.Reassign the dataset to a different Premium capacity.

C.Modify the dataset to use 'Impersonate the authenticated user' for data sources.

D.Ask the user to update the data source credentials in the Power BI service dataset settings.

AnswerD

Windows credentials may expire; updating them in the service resolves the error.

Why this answer

The error 'The data source credentials are no longer valid' typically occurs when the password has changed or expired. The user can update the credentials in the dataset settings in the Power BI service. Option A is incorrect because the on-premises data gateway is not the issue; a reinstall is unnecessary.

Option B is incorrect because reassigning the dataset to a different Premium capacity does not address credential validity. Option C is incorrect because using 'Impersonate the authenticated user' still requires valid credentials and does not fix the problem.

Full explanation →

14

MCQmedium

A data analyst creates a Power BI report that uses a date table with a continuous date range. They want to calculate the running total of sales over the last 12 months, ending on the last date in the current filter context. Which DAX expression should they use?

A.CALCULATE(SUM(Sales[Amount]), DATESBETWEEN('Date'[Date], MAX('Date'[Date]) - 365, MAX('Date'[Date])))

B.CALCULATE(SUM(Sales[Amount]), DATESINPERIOD('Date'[Date], MAX('Date'[Date]), -12, MONTH))

C.TOTALMTD(SUM(Sales[Amount]), 'Date'[Date])

D.CALCULATE(SUM(Sales[Amount]), DATESYTD('Date'[Date]))

AnswerB

DATESINPERIOD is the correct time-intelligence function here because it returns a contiguous interval ending at MAX('Date'[Date]) and extending back 12 full calendar months, respecting month boundaries rather than fixed day counts. With -12 and MONTH, the filter context established by CALCULATE adjusts the Sales[Amount] summation to include exactly the trailing 12 months relative to the latest visible date, which is exactly what a rolling 12-month total requires.

Why this answer

DATESINPERIOD('Date'[Date], MAX('Date'[Date]), -12, MONTH) returns a contiguous set of dates from 12 months before the last date in the current filter context up to that last date, providing an exact 12-month window. This function handles month boundaries correctly and is the standard way to calculate rolling 12-month totals in DAX. Option A uses 365 days, which can be imprecise due to leap years.

Exam trap

Candidates often choose DATESBETWEEN with 365 days (Option A) thinking it simplifies the calculation, but they overlook the leap year issue. DATESINPERIOD (Option B) is the correct function for a precise rolling 12-month period as it uses month boundaries rather than a fixed number of days.

How to eliminate wrong answers

Option B is wrong because DATESINPERIOD with -12 and MONTH shifts the window back 12 months from the end date, but it includes the entire month of the start date, which can result in a 13-month window if the last date is not the end of a month, thus not guaranteeing exactly 12 months. Option C is wrong because TOTALMTD calculates a month-to-date total, not a running total over the last 12 months. Option D is wrong because DATESYTD calculates a year-to-date total from the start of the calendar year, not a rolling 12-month window ending on the last date in the filter context.

Full explanation →

15

MCQeasy

You have developed a Power BI report that uses a live connection to an Azure Analysis Services (AAS) model. The AAS model is deployed in a different Azure region. Users report that the report loads slowly, sometimes taking over 30 seconds to render a single visual. You need to improve performance without changing the data model or the report structure. What should you do?

A.Enable the 'Reduce data shown in visuals' option in Power BI Desktop.

B.Implement row-level security (RLS) in the Azure Analysis Services model.

C.Deploy the Azure Analysis Services model to the same region as the Power BI workspace.

D.Convert the report to import mode and schedule a refresh.

AnswerC

A live connection means each Power BI visual executes a DAX query through the network to the Analysis Services instance, so physical distance directly affects response time. By co-locating the AAS server and the Power BI workspace in the same Azure region, round-trip network latency is minimized and data can stay within a single data center, which yields the fastest live query performance. This is a low-effort architectural fix that reduces latency without adding any per-query overhead or altering data granularity.

Why this answer

Deploying the Azure Analysis Services model to the same Azure region as the Power BI workspace minimizes network latency between the live connection client (Power BI) and the tabular model server. A live connection sends DAX queries over the XMLA protocol, and cross-region traffic introduces significant round-trip delays, which directly causes slow visual rendering. By co-locating the AAS server and the Power BI service in the same region, you reduce the physical distance and network hops, improving query response time without altering the model or report.

Exam trap

The trap here is that candidates often confuse client-side optimization settings (like reducing data shown) with server-side performance fixes, or they incorrectly assume that adding RLS or switching to import mode are acceptable solutions when the question explicitly prohibits changing the data model or report structure.

How to eliminate wrong answers

Option A is wrong because 'Reduce data shown in visuals' is a Power BI Desktop setting that limits the number of data points displayed in a visual (e.g., top N), which does not reduce the underlying query workload or network latency for a live connection to AAS; it only affects client-side rendering. Option B is wrong because implementing row-level security (RLS) in the AAS model adds additional DAX evaluation overhead for each query, which would likely worsen performance rather than improve it, and it does not address the cross-region latency issue. Option D is wrong because converting the report to import mode would require changing the data model (from live to import) and would break the live connection requirement; it also introduces a scheduled refresh dependency, which contradicts the constraint of not changing the data model or report structure.

Full explanation →

16

MCQmedium

You are using Power Query to combine data from multiple Excel files stored in a SharePoint Online document library. Each file has the same structure. You need to ensure that the query automatically includes new files added to the library without manual updates. Which approach should you use?

A.Use 'Get Data from Excel' and specify each file path manually.

B.Use 'Get Data from SQL Server' and write a query to read files.

C.Use 'Get Data from SharePoint Online Folder' and then combine files using 'Combine & Transform Data'.

D.Use 'Get Data from SharePoint Online List' and then expand the file content.

AnswerC

This approach dynamically lists all files and can be refreshed to include new files.

Why this answer

The 'Get Data from SharePoint Online Folder' connector in Power Query retrieves metadata for all files in the folder, and the 'Combine & Transform Data' action automatically applies a sample file transformation to all files. When new files are added to the library, refreshing the query will include them without manual intervention, as the connector dynamically reads the folder contents.

Exam trap

The trap here is that candidates confuse 'SharePoint Online Folder' with 'SharePoint Online List', thinking that a list can also combine files, but lists store metadata and require additional expansion steps that do not automatically handle new files with the same structure.

How to eliminate wrong answers

Option A is wrong because manually specifying each file path requires updating the query whenever a new file is added, which violates the requirement for automatic inclusion. Option B is wrong because SQL Server is a relational database, not a file storage system; it cannot directly read Excel files from SharePoint Online, and writing a query to read files is not a supported approach. Option D is wrong because 'Get Data from SharePoint Online List' retrieves list items (metadata), not the actual file content; expanding file content from a list requires additional steps and does not natively support combining multiple Excel files with the same structure.

Full explanation →

17

MCQhard

You are reviewing a Power BI data source configuration in the data source settings. The exhibit shows the JSON representation of a data source. Which issue might arise from this configuration?

A.The server name contains a hyphen, which is invalid in SQL Server connection strings.

B.The CommandTimeout value is too low and may cause queries to time out.

C.The option 'CreateNavigationProperties' is set to false, which may prevent relationships from being created.

D.The authentication kind 'Key' is not supported for Azure SQL Database, causing connection failure.

AnswerD

'Key' is not a valid authentication method for SQL Server; it should be 'UsernamePassword' or 'ServicePrincipal'.

Why this answer

Azure SQL Database does not support the 'Key' authentication kind in Power BI data source settings. Azure SQL Database requires either Windows authentication, database credentials (Username/Password), or Azure AD-based authentication (such as OAuth2 or Service Principal). The 'Key' authentication kind is typically used for Azure Storage or Cosmos DB, not for Azure SQL Database, so this configuration will cause a connection failure.

Exam trap

The trap here is that candidates may assume 'Key' authentication is valid for any Azure service, but Microsoft restricts authentication methods per data source type, and Azure SQL Database explicitly does not support key-based authentication.

How to eliminate wrong answers

Option A is wrong because hyphens are perfectly valid in SQL Server connection strings; the server name can contain hyphens without any issue. Option B is wrong because the CommandTimeout value shown in the exhibit is not specified as too low; the default is 10 minutes, and the exhibit does not indicate an unusually low value that would cause timeouts. Option C is wrong because 'CreateNavigationProperties' set to false only affects whether Power BI automatically creates relationships in the data model based on foreign keys; it does not prevent relationships from being created manually, and it does not cause a connection failure.

Full explanation →

18

MCQhard

You are a Power BI analyst for a multinational retail company. The company's sales data is stored in an Azure SQL Database with tables: Sales (SalesID, Date, ProductID, Quantity, Amount), Products (ProductID, ProductName, Category), and Calendar (Date, Year, Month, Day). The Sales table contains 500 million rows. You are creating a Power BI report to analyze daily sales trends over the past 5 years. The report must allow users to drill from year to month to day using a hierarchy. The performance of the report is critical; users expect visuals to load within 5 seconds. The current model imports all tables without any optimization, and the date hierarchy visual takes over 30 seconds to render. You need to redesign the data model to meet the performance requirement. What should you do?

A.Create an aggregated table in Power Query that groups sales by date, and create a date hierarchy in the Calendar table.

B.Add calculated columns for Year, Month, and Day in the Sales table to avoid using the Calendar table.

C.Switch the import mode to DirectQuery to avoid loading all data into memory.

D.Implement incremental refresh policy on the Sales table to reduce the amount of data loaded.

AnswerA

Creating an aggregated table in Power Query reduces the 500M-row fact table to daily totals, so slicers, visuals, and DAX queries scan far fewer rows and return faster. A date hierarchy in the Calendar table then lets users drill from year to month to day without adding storage-heavy calculated columns. This preserves the star schema and enables query folding during refresh.

Why this answer

Pre-aggregating sales data by date in Power Query reduces the granularity from 500 million rows to at most 1,825 rows (one per day for 5 years), which drastically improves query performance for the date hierarchy. Creating a date hierarchy in the Calendar table allows drill-down. Option B is wrong because calculated columns do not reduce row count and still require processing all 500 million rows, so performance remains poor.

Option C is wrong because DirectQuery without aggregation still pushes large queries to the database, which can be slow. Option D is wrong because incremental refresh only reduces the amount of data loaded during refresh, but does not improve query performance on the existing data; the full model still contains 500 million rows.

Full explanation →

19

MCQeasy

You are importing data from an Excel workbook that contains multiple sheets. You only need data from the 'Sales' sheet. In Power Query Editor, what should you do to load only that sheet?

A.Load all sheets, then delete the queries for sheets you don't need.

B.In the Navigator dialog, select the 'Sales' sheet and click 'Transform Data'.

C.Use a filter transform to exclude rows from other sheets.

D.Select the entire workbook and then filter out other sheets in Power Query.

AnswerB

In the Navigator dialog, each worksheet and named table appears as a previewable source; choosing the 'Sales' sheet and clicking 'Transform Data' sends only that sheet's data into Power Query Editor as the single source for a new query. This lets you filter rows, change data types, or add custom columns before loading, while leaving every other sheet unread and out of the data model. This is the efficient, supported workflow for importing a specific worksheet.

Why this answer

In Power Query Editor, the Navigator dialog allows you to preview and select specific tables or sheets from a data source before loading. By selecting the 'Sales' sheet and clicking 'Transform Data', you load only that sheet into Power Query Editor for transformation, avoiding unnecessary data. This is the correct and efficient method to import a single sheet from a multi-sheet Excel workbook.

Exam trap

The trap here is that candidates may think they can use a filter or query folding to exclude entire sheets after loading, but Power Query treats each sheet as a separate table, not as rows within a single table, so filtering cannot remove sheets.

How to eliminate wrong answers

Option A is wrong because loading all sheets and then deleting unwanted queries is inefficient and violates the principle of early data reduction; it also consumes memory and processing time for data that will be discarded. Option C is wrong because filter transforms operate on rows within a single table, not on sheets or tables; you cannot use a row filter to exclude entire sheets from a workbook. Option D is wrong because selecting the entire workbook in the Navigator dialog loads all sheets as separate queries, and Power Query does not support filtering out other sheets after loading; you would need to manually remove or disable the unwanted queries.

Full explanation →

20

MCQeasy

You are reviewing a Power Query query that loads data from a SQL Server database. The query includes multiple steps that perform data transformation. You want to ensure that the query is optimized by pushing as many transformations as possible to the SQL Server. What should you look for?

A.View the native SQL query generated by Power Query.

B.Use the Performance Analyzer in Power BI Desktop.

C.Check for the 'Query Folding' indicators in the query editor.

D.Review the data preview for each step.

AnswerC

Correct. Query folding indicators in Power Query Editor (a table icon with a down arrow or a fold icon) show whether a step is translated into native SQL and executed on the server. This directly tells you if transformations are being pushed to SQL Server.

Why this answer

Query folding indicators in Power Query Editor show whether transformations are being pushed to the SQL Server source. When a step shows a 'folded' icon (a table with a down arrow), it means the transformation is translated into native SQL and executed on the server, reducing data transfer and improving performance. Checking these indicators directly confirms which steps are folded and which are not, allowing you to optimize the query by reordering or rewriting steps to maximize folding.

Option A is incorrect because viewing the native SQL query only shows the final aggregated SQL, not the folding status of each individual step. Option B is also incorrect as the Performance Analyzer helps measure overall report performance but does not indicate folding for each step. Option D is irrelevant because data previews do not show folding status.

Exam trap

The trap here is that candidates often confuse viewing the native SQL query (Option A) with checking query folding indicators, but the native query only shows the final aggregated SQL, not the folding status of each individual step, which is what the question specifically asks for.

How to eliminate wrong answers

Option A is wrong because viewing the native SQL query generated by Power Query only shows the final folded query, not the folding status of individual steps; it does not help identify which specific transformations are being pushed. Option B is wrong because the Performance Analyzer in Power BI Desktop measures report and visual rendering performance, not query folding or source-side optimization of Power Query transformations. Option D is wrong because reviewing the data preview for each step shows the output of transformations but gives no indication of whether those transformations are being executed on the SQL Server or locally in Power Query.

Full explanation →

21

Multi-Selectmedium

Which TWO actions are required to set up a Power BI deployment pipeline with separate data sources for Development and Production?

Select 2 answers

A.Define dataset parameters in Power BI Desktop for data source values.

B.Assign the dataset owner to each stage workspace.

C.Configure parameter rules in the deployment pipeline to map parameters to stage-specific values.

D.Re-enter data source credentials for each stage after deployment.

E.Create separate gateways for each stage.

AnswersA, C

Parameters allow you to change data source at deployment time.

Why this answer

Defining dataset parameters in Power BI Desktop for data source values allows you to make the data source connection dynamic. These parameters can then be overridden at each stage of the deployment pipeline, enabling separate data sources for Development and Production without modifying the report file.

Exam trap

The trap here is that candidates often confuse credential management (Option D) with parameter-based data source separation, or assume that separate gateways (Option E) are mandatory, when in fact parameter rules are the correct and efficient method for stage-specific data sources.

Full explanation →

22

MCQmedium

You have a table with a column 'FullName' that contains names in the format 'Last, First'. You need to split this column into 'LastName' and 'FirstName' columns. Which Power Query transformation should you use?

A.Pivot the FullName column.

B.Split Column by Delimiter using comma.

C.Group By the FullName column and aggregate.

D.Extract first characters using 'Extract' transformation.

AnswerB

In Power Query, the Split Column feature by a delimiter divides text into separate columns at each occurrence of a specified delimiter. For a FullName column containing comma-separated names, choosing comma as the delimiter splits it into two columns, with options to control the number of splits and how to handle extra delimiters. This directly achieves the goal of separating the name into distinct parts.

Why this answer

The 'Split Column by Delimiter' transformation in Power Query is specifically designed to divide a single text column into multiple columns based on a specified delimiter, such as a comma. In this case, the 'FullName' column contains names in the 'Last, First' format, so splitting by a comma delimiter will correctly separate the last name and first name into two distinct columns.

Exam trap

The trap here is that candidates might confuse 'Split Column by Delimiter' with 'Extract' or 'Pivot', thinking that extracting the first few characters or pivoting the column could achieve the same result, but only the delimiter-based split correctly handles the variable-length 'Last, First' format.

How to eliminate wrong answers

Option A is wrong because Pivot transforms unique values from a column into new columns and aggregates associated data, which is not applicable for splitting a single text column. Option C is wrong because Group By aggregates rows based on a column and computes summary statistics, not splitting text values within a cell. Option D is wrong because the 'Extract' transformation (e.g., Extract First Characters) only retrieves a fixed number of characters from the start of a string, which cannot handle variable-length names separated by a delimiter.

Full explanation →

23

MCQmedium

You are designing a data model for a report that shows sales by region and product category. The source data includes a table 'Sales' with columns: Region, Category, SalesAmount. You also have separate tables 'Regions' and 'Categories' that contain additional attributes. You need to create a star schema. What should you do with the 'Region' and 'Category' columns in the 'Sales' table?

A.Remove them from the Sales table and use foreign keys to link to the dimension tables

B.Keep them in the Sales table as attributes for simplicity

C.Merge the Regions and Categories tables into the Sales table

D.Mark the Sales table as a date table

AnswerA

This is the correct star schema approach. Remove region and category descriptive text from the Sales table and replace them with foreign key columns (e.g., RegionID, CategoryID) that reference the primary keys of dedicated dimension tables. This normalizes the fact table, eliminates redundant string storage, and enables DAX filter and slicer operations to traverse relationships efficiently. It also simplifies future updates to dimension attributes without rewriting historical sales rows.

Why this answer

In a star schema, dimension tables (Regions, Categories) contain descriptive attributes, and the fact table (Sales) stores foreign keys referencing those dimensions. Removing the Region and Category columns from the Sales table and replacing them with foreign keys (e.g., RegionID, CategoryID) normalizes the model, reduces data redundancy, and enables efficient filtering and slicing by region and category attributes. This approach aligns with best practices for Power BI data modeling, ensuring optimal query performance and maintainability.

Exam trap

The trap here is that candidates often think keeping attributes in the fact table is simpler and faster, not realizing that a normalized star schema with foreign keys actually improves performance and scalability in Power BI.

How to eliminate wrong answers

Option B is wrong because keeping Region and Category as attributes in the Sales table violates star schema principles, leading to data duplication, larger table size, and inefficient filtering when dimension attributes change. Option C is wrong because merging the Regions and Categories tables into the Sales table creates a wide, denormalized flat table, which defeats the purpose of a star schema and increases storage and refresh overhead. Option D is wrong because marking the Sales table as a date table is irrelevant; date tables are used for time intelligence functions, and Sales is a fact table, not a date dimension.

Full explanation →

24

MCQeasy

You are importing data from a CSV file that contains a column with mixed data types (numbers and text). Power BI automatically assigns the data type as Text. You need to perform numerical aggregations on this column. What should you do?

A.Split the column using a delimiter to separate numbers from text.

B.Create a relationship with a numeric table to enable aggregation.

C.Create a calculated column in DAX using VALUE() to convert the text to numbers.

D.In Power Query Editor, change the data type of the column to Whole Number or Decimal Number.

AnswerD

Changing the data type in Power Query Editor to Whole Number or Decimal Number is the proper and idiomatic remedy because it defines the column as numeric from the moment it enters the data model, immediately making it available for aggregations like SUM and AVERAGE. This transform is part of your ETL workflow, gets applied at each refresh, and is self-documenting in the query steps, ensuring downstream reports treat the column precisely as intended.

Why this answer

Changing the column's data type to Whole Number or Decimal Number in Power Query Editor will force Power BI to interpret the numeric values as numbers, enabling aggregations like SUM or AVERAGE. Power Query Editor provides a robust transformation environment where data type changes are applied during the load process, ensuring the column is treated as numeric for all downstream calculations. This approach is more efficient and reliable than using DAX conversions, as it avoids the overhead of calculated columns and leverages Power Query's native type detection and error handling.

Exam trap

The trap here is that candidates may think a DAX calculated column (Option C) is the correct approach for data type conversion, but the PL-300 exam emphasizes performing data transformations in Power Query Editor (the 'Prepare the data' domain) rather than in DAX, as Power Query is the proper tool for cleaning and shaping data before loading it into the model.

How to eliminate wrong answers

Option A is wrong because splitting the column using a delimiter does not address the mixed data types; it would separate values into multiple columns but still leave text entries that cannot be aggregated numerically. Option B is wrong because creating a relationship with a numeric table does not convert the existing text column to numbers; relationships are based on matching keys, not data type conversion, and aggregation requires numeric values in the same column. Option C is wrong because while a DAX calculated column using VALUE() can convert text to numbers, it is less efficient than changing the data type in Power Query Editor, as it adds a column to the model and may fail on non-numeric text entries, whereas Power Query can handle errors during load.

Full explanation →

25

MCQeasy

You are using Power Query to combine data from multiple CSV files in a folder. Each file has the same structure. You want to append all rows into a single table. Which Power Query function should you use?

A.Group By.

B.Append Queries.

C.Merge Queries as new.

D.Combine Files from the folder connector.

AnswerD

The folder connector with Combine Files automatically appends all CSV files.

Why this answer

The 'Combine Files' transformation in Power Query is specifically designed to import and append multiple CSV files from a folder into a single table. When you connect to a folder using the 'From Folder' connector, Power Query automatically generates a 'Combine Files' step that uses the 'Table.Combine' function under the hood, which appends all rows from identically structured files into one unified table.

Exam trap

The trap here is that candidates often confuse 'Append Queries' (which is a manual, query-level operation) with the automated 'Combine Files' feature that the folder connector provides, leading them to pick Option B instead of recognizing that the folder connector's built-in combine functionality is the correct and intended method for this scenario.

How to eliminate wrong answers

Option A is wrong because 'Group By' is an aggregation operation that groups rows based on column values and computes summaries (e.g., sum, count), not a method to append rows from multiple files. Option B is wrong because 'Append Queries' is a manual operation that combines two or more existing queries in the Power Query Editor, but it is not the direct function used when importing multiple files from a folder; the folder connector's 'Combine Files' is the automated approach. Option C is wrong because 'Merge Queries as new' performs a join (like SQL JOIN) based on matching columns, which combines columns from different tables, not appending rows.

Full explanation →

26

MCQhard

Refer to the exhibit. The Power Query M code connects to a SQL Server database and performs data transformation. However, the query is failing with a privacy level error. What is the most likely cause?

A.The SQL Server credentials are not correctly configured in the data source settings.

B.The privacy levels for the SQL Server data source are set inconsistently across the environment.

C.The query uses a CSV file from a local folder that has a privacy level set to 'Private'.

D.The query combines data from SQL Server and another data source with incompatible privacy levels.

AnswerD

This is correct because Power Query's privacy-level engine prevents data from being combined across sources that have incompatible privacy levels, such as a 'Private' CSV file from a local folder and a SQL Server source with a different level. When the query attempts to fold or merge data from these two sources, the engine raises a privacy-level error unless levels are adjusted to allow the combination or a suitable firewall level is configured. The error is specifically triggered by the act of combining the sources, not by the nature of any single source.

Why this answer

A privacy level error in Power Query occurs when combining data from multiple sources with incompatible privacy levels. The query connects to SQL Server and performs transformations, but if it also references another source (e.g., from a previous step or additional data) with a privacy level that conflicts with SQL Server's privacy level, the Power Query firewall blocks the query. In this scenario, the most likely cause is that the query combines SQL Server data with another data source (such as a CSV file or another database) that has a privacy level set to 'Private' while SQL Server is set to 'Organizational' or 'Public', causing the error.

Option D correctly identifies this. Options A and B are incorrect because a single data source cannot cause a privacy level error, and inconsistent privacy levels across environments do not trigger the firewall on a single source.

Exam trap

The trap is that candidates often think a privacy level error requires inconsistent settings on a single source or credentials issues, but the error always involves combining multiple sources. Even if only SQL Server is visible, the query may be implicitly referencing another source.

How to eliminate wrong answers

Option A is wrong because incorrect SQL Server credentials would produce a connection or authentication error (e.g., 'Cannot connect to database'), not a privacy level error. Option C is wrong because a CSV file from a local folder with a privacy level set to 'Private' alone does not cause a privacy level error; the error arises only when combining that CSV with another source that has an incompatible privacy level (e.g., 'Public'), and the question states the query connects to SQL Server, not a CSV. Option D is wrong because while combining data from SQL Server and another source with incompatible privacy levels can cause the error, the question specifically states the query 'connects to a SQL Server database and performs data transformation'—it does not mention combining with another source, so the most likely cause is the inconsistency within the SQL Server source's own privacy level settings across the environment, not a cross-source combination.

Full explanation →

27

MCQmedium

You are preparing a data model that uses a date table. You need to ensure that the date table includes all dates from January 1, 2020 to December 31, 2025. What is the most efficient way to create this date table in Power Query?

A.Import a date table from an Excel file.

B.Use the 'List.Dates' function to generate the date range.

C.Use the 'Calendar' function in Power Query M.

D.Use the 'CALENDAR' DAX function in Power Query.

AnswerB

Using the 'List.Dates' function in Power Query M is the correct approach because it dynamically generates a continuous list of dates from a specified start date, a count of dates, and a step increment, all defined as parameters. You then wrap that list with Table.FromList or convert it into a column, allowing you to create a date table that automatically adapts to your data range without manual maintenance or external file dependencies.

Why this answer

The 'List.Dates' function in Power Query M is the most efficient way to generate a contiguous range of dates directly within the query editor, without external dependencies. It creates a list of dates from a start date to an end date using a specified step (e.g., #duration(1,0,0,0) for one day), which can then be converted into a table. This approach is lightweight, fully self-contained, and avoids the overhead of importing external files or using DAX functions that are not native to Power Query.

Exam trap

The trap here is that candidates confuse DAX functions (like 'CALENDAR') with Power Query M functions, assuming they can be used interchangeably in the Power Query editor, when in fact DAX functions are only available in the data modeling layer (e.g., calculated tables) and not in Power Query.

How to eliminate wrong answers

Option A is wrong because importing a date table from an Excel file introduces an external dependency, requires manual maintenance, and is less efficient than generating the dates natively in Power Query. Option C is wrong because there is no built-in 'Calendar' function in Power Query M; the correct M function is 'List.Dates' or the 'Date' functions, and 'Calendar' is a DAX function, not an M function. Option D is wrong because 'CALENDAR' is a DAX function used in Power Pivot or Analysis Services, not in Power Query; Power Query uses M language, and DAX functions cannot be used directly in the Power Query editor.

Full explanation →

28

Multi-Selecthard

Which THREE of the following are best practices for data preparation in Power BI to improve performance and maintainability? (Select THREE.)

Select 3 answers

A.Filter out unnecessary rows as early as possible in the query

B.Avoid renaming columns in Power Query; use original names

C.Use query folding to push transformations back to the source

D.Split complex queries into multiple steps for clarity

E.Keep all columns from the source to avoid missing data

AnswersA, C, D

Early filtering reduces data volume and improves performance.

Why this answer

Filtering out unnecessary rows early in Power Query reduces the amount of data loaded into memory and processed in subsequent transformation steps. This practice, known as early filtering, minimizes the data footprint and improves both refresh performance and report responsiveness. By applying filters as the first transformation, you leverage query folding to push the filter logic to the source database, further enhancing efficiency.

Exam trap

The trap here is that candidates often confuse 'maintainability' with 'avoiding changes to source names,' but Power BI encourages renaming for clarity, and the real performance pitfall is keeping unnecessary columns, not renaming them.

Full explanation →

29

MCQhard

You have a Power BI model with a table 'Sales' that contains columns: Date, SalespersonID, and Amount. You have a 'Salespeople' table with columns: SalespersonID, Name, and Region. You need to create a measure that calculates the total sales amount for the current region, but only for salespeople who have made at least one sale in the current month. Which DAX expression achieves this?

A.CALCULATE(SUM(Sales[Amount]), Salespeople[Region] = SELECTEDVALUE(Salespeople[Region]))

B.SUMX(FILTER(Salespeople, CALCULATE(COUNTROWS(Sales), Sales[Date] >= DATE(YEAR(TODAY()), MONTH(TODAY()), 1)) > 0), CALCULATE(SUM(Sales[Amount]), Salespeople[Region] = SELECTEDVALUE(Salespeople[Region])))

C.SUMX(Salespeople, CALCULATE(SUM(Sales[Amount]), Salespeople[Region] = SELECTEDVALUE(Salespeople[Region]), Sales[Date] >= DATE(YEAR(TODAY()), MONTH(TODAY()), 1)))

D.CALCULATE(SUM(Sales[Amount]), Salespeople[Region] = SELECTEDVALUE(Salespeople[Region]), Sales[Date] >= DATE(YEAR(TODAY()), MONTH(TODAY()), 1))

AnswerB

Correctly iterates over salespeople who have at least one sale in the current month and sums their sales for the current region.

Why this answer

It first filters the Salespeople table to only those who have made at least one sale in the current month (using COUNTROWS > 0 with a date filter), then iterates over that filtered list with SUMX, and for each salesperson calculates the sum of Amount filtered to their region using CALCULATE. Option A is wrong because it sums all sales in the selected region without any filter on salespeople who have sales this month. Option C is wrong because it sums over all salespeople without first filtering to those with current month sales, so it would incorrectly include salespeople with no current month sales.

Option D is wrong because it sums sales only in the current month but does not restrict to salespeople with at least one sale in the current month; it would include all sales in that month, regardless of salesperson.

Full explanation →

30

MCQeasy

You have a Power Query query that loads data from an OData source. You need to reduce the amount of data loaded into the data model. What is the best practice?

A.Apply a filter in the data model using DAX.

B.Use 'Enable load' option to turn off loading for the query.

C.Apply a filter in Power Query before loading.

D.Load all data and then hide columns you don't need.

AnswerC

Applying a filter in Power Query before the data is loaded reduces the number of rows that are imported into the data model. For OData sources, the filter can often be folded into the native query sent to the server, so only matching rows traverse the network and are stored in VertiPaq. This lowers memory usage, improves refresh time, and shrinks the model footprint — the correct way to reduce data volume.

Why this answer

Applying filters in Power Query before loading data into the data model is the best practice for reducing data volume. Power Query pushes filters down to the OData source using OData query parameters (e.g., $filter), ensuring only the required rows are retrieved from the source. This minimizes network transfer and memory usage in the data model, aligning with the principle of early filtering in the ETL process.

Exam trap

The trap here is that candidates often confuse filtering in the data model (DAX) with filtering during data ingestion (Power Query), assuming both reduce data volume equally, but only Power Query filters reduce the actual data loaded into memory.

How to eliminate wrong answers

Option A is wrong because applying a filter in the data model using DAX does not reduce the amount of data loaded; it only restricts what is visible in reports, while the entire dataset remains in memory. Option B is wrong because disabling 'Enable load' for the query prevents the entire query from being loaded, which is not a method to reduce data volume for a query that is needed—it removes the query entirely from the model. Option D is wrong because loading all data and then hiding columns does not reduce the amount of data loaded; hidden columns still consume memory and storage in the data model.

Full explanation →

31

MCQeasy

You have a Power BI workspace that contains a report connected to an Azure Analysis Services (AAS) model. The data source uses Single Sign-On (SSO) with Microsoft Entra ID. When users access the report, they see an error that the data cannot be refreshed. What is the most likely cause?

A.Row-level security (RLS) is not configured on the AAS model.

B.The data source credentials are stored in the dataset.

C.The service principal used for authentication has expired.

D.The dataset is configured in Import mode.

AnswerD

SSO only works with DirectQuery or Live Connection.

Why this answer

The most likely cause is that the dataset is configured in Import mode. Single Sign-On (SSO) with Microsoft Entra ID is only supported when the dataset uses DirectQuery or Live Connection mode. Import mode requires stored credentials and does not pass the user's identity to the data source.

Option A is incorrect because RLS does not affect data refresh connectivity. Option B is incorrect because stored credentials are not used when SSO is enabled. Option C is incorrect because SSO uses the user's identity, not a service principal.

Exam trap

Candidates may confuse the requirement for SSO: it requires DirectQuery or Live Connection, not Import mode.

Full explanation →

32

Multi-Selecteasy

You are creating a Power BI report to analyze customer churn. You have a table with Customer ID, Churn Date, and other attributes. You want to create a measure that calculates the number of customers who churned in the last 30 days. Which THREE components do you need?

Select 3 answers

A.A measure using CALCULATE, COUNTROWS, and DATESINPERIOD

B.A calculated column for 30-day flag

C.A relationship between date table and Churn Date

D.A separate date table marked as date table

E.A disconnected table with date range

AnswersA, C, D

This is the correct pattern for a dynamic 30-day churn count: CALCULATE modifies the filter context to filter rows meeting the condition, COUNTROWS counts rows in the churn fact table, and DATESINPERIOD generates a contiguous date range from the max visible date going back 30 days. Unlike a column, this measure is evaluated at query time, so it automatically respects report-level slicers, page filters, and drill-downs, and requires no storage overhead. The key is that DATESINPERIOD works only with a properly related date table.

Why this answer

The correct components are A, C, and D. A measure using CALCULATE, COUNTROWS, and DATESINPERIOD (A) is needed to dynamically count customers who churned in the last 30 days. A relationship between the date table and Churn Date (C) is required for time intelligence functions like DATESINPERIOD to work correctly.

A separate date table marked as a date table (D) is necessary because Power BI time intelligence functions require a proper date table with continuous dates and a date type. Option B (a calculated column for 30-day flag) is not needed; the measure handles the filtering. Option E (a disconnected table with date range) is unnecessary because the regular date table relationship suffices.

Full explanation →

33

Drag & Dropmedium

Drag and drop the steps to configure a scheduled refresh for a dataset in the Power BI service into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Scheduled refresh is configured in the dataset settings, enabling automatic updates at specified intervals.

Full explanation →

34

MCQeasy

You are transforming data in Power Query. A column named 'SalesAmount' contains values as text with a dollar sign and thousands separator, e.g., "$1,234.56". You need to convert this column to a decimal number for analysis. What is the most efficient sequence of transformations?

A.Split the column by delimiter and keep the numeric part, then change data type.

B.Change data type to Decimal Number directly; Power Query will automatically clean the values.

C.Use Replace Values to remove '$' and ',', then change data type to Decimal Number.

D.Use Replace Values to remove '$' and ',' then change data type to Decimal.

AnswerC

Removing specific characters is a direct and efficient method; however, a more robust approach is to use Text.Select to keep only digits and the decimal point, but Replace Values is simplest given the known characters.

Why this answer

It explicitly removes both the dollar sign and the comma using Replace Values before changing the data type to Decimal Number, ensuring proper conversion without errors. Option A is inefficient; splitting the column is unnecessary when simple replacements work. Option B would fail because Power Query cannot automatically parse currency symbols and thousands separators from text when changing data type directly.

Option D appears similar but specifies 'Decimal' instead of 'Decimal Number', which is not a valid data type in Power Query, leading to an error or incorrect result.

Exam trap

The trap here is that candidates assume Power Query's automatic type detection or direct data type change can handle currency symbols and separators, but in reality, it requires explicit cleaning steps to avoid errors or incorrect conversions.

How to eliminate wrong answers

Option A is wrong because splitting the column by delimiter is an overly complex approach that introduces unnecessary steps and potential data loss; it is not the most efficient sequence. Option B is wrong because Power Query cannot automatically clean currency symbols and thousands separators when changing data type directly; it will either error or leave the column as text. Option D is wrong because it only removes the dollar sign but not the comma, so the thousands separator remains, causing the data type conversion to fail or produce incorrect results.

Full explanation →

35

MCQhard

You are connecting to an Azure SQL database using DirectQuery. The database has a large table with millions of rows. Users need to see aggregated data quickly. What should you implement to improve query performance?

A.Create aggregations in Power BI on the large table.

B.Increase the memory limit of the Power BI Desktop.

C.Use a composite model with a smaller imported table.

D.Add indexes to the database table.

AnswerA

Aggregations reduce the amount of data queried from the source.

Why this answer

Creating aggregations in Power BI on the large table allows the DirectQuery model to pre-aggregate data at the source or in Power BI, reducing the volume of data queried and improving response times for aggregated results. This is a key performance optimization for DirectQuery models with large tables, as it avoids scanning millions of rows for every query.

Exam trap

The trap here is that candidates often confuse database-side optimizations (like indexes) with Power BI-side optimizations (like aggregations), leading them to choose Option D, but the question explicitly asks what you should implement in Power BI, not in the database.

How to eliminate wrong answers

Option B is wrong because increasing the memory limit of Power BI Desktop does not improve query performance against an Azure SQL database via DirectQuery; memory limits affect local processing, not the database query execution. Option C is wrong because using a composite model with a smaller imported table would break the DirectQuery requirement and introduce data freshness issues, as the imported table would need to be refreshed separately and may not reflect real-time data. Option D is wrong because adding indexes to the database table is a database-side optimization that can improve query performance, but it is not a Power BI implementation; the question asks what you should implement in Power BI, and indexes are managed by the database administrator, not within Power BI.

Full explanation →

36

MCQmedium

You are reviewing the partition configuration for a Power BI Import model as shown in the exhibit. The table Sales is partitioned by year. You need to modify the model to improve incremental refresh performance. What change should you make?

A.Increase the number of partitions to monthly

B.Configure incremental refresh policy

C.Remove all partitions and load data as a single table

D.Change the storage mode to DirectQuery

AnswerB

Configuring an incremental refresh policy is the correct approach because it automatically creates and manages partitions based on a date range, typically using RangeStart and RangeEnd parameters. During each refresh, only the data that has changed or is new within the sliding window is processed, while historical partitions remain untouched, significantly reducing refresh time and resource consumption. This also enables query pruning in the Power BI service, as only relevant partitions are scanned when building visuals, making it the most efficient way to optimize refresh performance for large fact tables.

Why this answer

Configuring an incremental refresh policy (Option B) is the correct approach because it automatically manages partition creation and refresh for the Sales table based on a date/time column. This improves performance by refreshing only the most recent data (e.g., last 5 years) while keeping historical partitions unchanged, reducing refresh time and resource consumption compared to manual yearly partitions.

Exam trap

The trap here is that candidates may think increasing partition count (Option A) always improves performance, but in Power BI, too many partitions increase metadata overhead and refresh orchestration time, making incremental refresh policies the correct solution for efficient, automated partition management.

How to eliminate wrong answers

Option A is wrong because increasing partitions to monthly would create more granular partitions, which can actually degrade refresh performance due to overhead from managing many small partitions, and it does not address the need for incremental refresh logic. Option C is wrong because removing all partitions and loading data as a single table would force a full refresh of the entire Sales table every time, eliminating any performance gains from partitioning and incremental refresh. Option D is wrong because changing the storage mode to DirectQuery would bypass the Import model entirely, which is not an incremental refresh improvement and could introduce query performance issues due to live querying of the source.

Full explanation →

37

Multi-Selectmedium

You are preparing data from a SQL Server database. The table 'Sales' contains a column 'OrderDate' that includes both date and time (e.g., '2023-10-15 14:30:00'). You need to create a separate column for the time portion only. Which TWO Power Query transformations can you use?

Select 2 answers

A.Extract - Duration

B.Extract - Year

C.Merge Columns

D.Format - Trim

E.Split Column by Delimiter (space)

AnswersA, E

Extracts time as duration from midnight.

Why this answer

The 'Extract - Duration' transformation in Power Query extracts the time portion from a datetime column by calculating the duration since midnight, effectively isolating the time component. Option E is correct because splitting the column by a space delimiter separates the date and time parts into two columns, allowing you to keep only the time portion. Both methods produce a time-only value suitable for analysis.

Exam trap

The trap here is that candidates may think 'Extract - Duration' is only for calculating time differences, not for isolating the time portion, or they may overlook that splitting by a space delimiter is a valid alternative to more complex date/time functions.

Full explanation →

38

MCQhard

Refer to the exhibit. You are reviewing the configuration of a Power BI dataset with row-level security (RLS). A user named 'user@contoso.com' reports that they can see all data when they should see only data for their region. What is the most likely cause?

A.The 'effectiveIdentity' is set to the user's email, bypassing RLS.

B.The RLS roles are missing the 'SalesRole' mapping to the dataset.

C.The dataset does not have any RLS roles defined.

D.The user is not assigned to any RLS role.

AnswerA

The effective identity setting forces the dataset to use that identity, ignoring RLS for that user.

Why this answer

The 'effectiveIdentity' property in the exhibit is set to 'user@contoso.com', which overrides RLS and allows that user to see all data. In Power BI, the effective identity is used for testing purposes; in production, it should not be set for a specific user if RLS is intended. Option B is incorrect because the exhibit shows RLS roles are defined, so missing mapping is not the issue.

Option C is incorrect because roles exist. Option D is incorrect because the user is likely assigned to a role, but the effective identity overrides it.

Full explanation →

39

Multi-Selecthard

Which THREE factors should you consider when designing a star schema for a Power BI semantic model? (Select three.)

Select 3 answers

A.Fact tables should contain measures and foreign keys to dimension tables.

B.Dimension tables should contain descriptive attributes and be denormalized.

C.Fact tables should be normalized to reduce data duplication.

D.Use calculated columns in dimension tables to derive new attributes.

E.Avoid creating many-to-many relationships between dimensions.

AnswersA, B, E

This is the core of star schema design.

Why this answer

The correct factors are: Fact tables should contain measures and foreign keys to dimension tables (A). Dimension tables should contain descriptive attributes and be denormalized (B). Avoid creating many-to-many relationships between dimensions; instead, use a bridge table when necessary (E).

Option C is incorrect because fact tables should not be normalized; they should be denormalized to improve query performance. Option D is incorrect because calculated columns in dimension tables can increase model size and processing time; they are better placed as measures or in the fact table.

Full explanation →

40

Multi-Selecthard

Which TWO of the following are true about the Power BI composite model?

Select 2 answers

A.Composite models do not support many-to-many relationships.

B.All tables in a composite model must use the same storage mode.

C.A composite model can combine DirectQuery and Import tables.

D.Relationships can be created between tables from different source groups.

E.Calculated tables are not supported in composite models.

AnswersC, D

This is a key feature of composite models.

Why this answer

A composite model in Power BI allows mixing DirectQuery and Import tables within the same data model. This enables you to leverage the performance of in-memory Import storage for some tables while using DirectQuery to access large or real-time data sources without duplicating data.

Exam trap

The trap here is that candidates often assume composite models require uniform storage modes or cannot handle many-to-many relationships, but Power BI's composite model is designed to flexibly mix storage modes and supports many-to-many relationships through proper configuration.

Full explanation →

41

MCQeasy

You have a Power BI report that shows sales by region. Users report that the map visual is not displaying data for some countries. What is the most likely cause?

A.The geographic data is not categorized correctly in the Data pane.

B.The report page filter is excluding those countries.

C.The map visual is limited to 30 data points.

D.The map visual only supports US addresses.

AnswerA

The Power BI Map visual relies on Bing Maps to geocode location values, and it can only do that if each geographic field has the correct Data Category set in the Column tools (e.g., Country, State, City). If the field is left as 'Uncategorized', Bing may interpret the values as text or fail to resolve them, so entire countries can be omitted. To fix this, select the field in the Fields pane, go to the Column tools tab, and set the Data Category accordingly. This is the most common reason a country that exists in your data does not appear on the map.

Why this answer

The most likely cause is that the geographic data is not categorized correctly in the Data pane. Power BI map visuals rely on the data category (e.g., Country, State, City) assigned to each field to correctly geocode and plot locations. If a field containing country names is left as 'Text' or 'Uncategorized', Power BI may fail to recognize the values as geographic entities, resulting in missing data points on the map.

Exam trap

The trap here is that candidates often assume a filter or data limit is the cause, but the core issue is the data category metadata, which is a subtle but critical setting in Power BI for map visuals.

How to eliminate wrong answers

Option B is wrong because a report page filter would affect all visuals on the page, not just the map, and users would typically notice missing data across the report, not solely on the map. Option C is wrong because the map visual (Bing Maps) does not have a hard limit of 30 data points; the limit applies to scatter charts and other visuals, not to map visuals. Option D is wrong because Power BI map visuals support addresses globally via Bing Maps geocoding, not just US addresses.

Full explanation →

42

MCQeasy

A data model has a table 'Orders' with columns: OrderID, CustomerID, OrderDate, Amount. There is a 'Customers' table with columns: CustomerID, CustomerName. To analyze orders by customer, what is the best practice for modeling the relationship?

A.Create a one-to-many relationship from Customers to Orders with single direction.

B.Create a one-to-one relationship between Customers and Orders based on CustomerID.

C.Create an inactive relationship and use USERELATIONSHIP in measures.

D.Create a many-to-one relationship from Orders to Customers with both directions.

AnswerA

This is the correct star schema design. The Customers table is a dimension with a unique CustomerID per row, while Orders is a fact table that can contain many rows per CustomerID. A one-to-many relationship from Customers to Orders lets filters applied to customers (e.g., region, segment) automatically propagate to their orders in visualizations and measures. The single cross-filter direction ensures one-way filtering from the dimension to the fact, which is the standard, repeatable pattern that avoids ambiguity and keeps DAX calculations predictable.

Why this answer

In a star schema, the Customers table (dimension) should have a one-to-many relationship to the Orders table (fact) filtered from the dimension side. This single-direction filter propagation ensures that when a customer is selected, only their orders are shown, while preventing unwanted cross-filtering from orders back to customers. This is the standard best practice for modeling dimension-to-fact relationships in Power BI.

Exam trap

The trap here is that candidates often confuse the direction of the relationship (thinking the fact table should be on the 'one' side) or overcomplicate the model by using inactive relationships or bidirectional filtering when a simple single-direction one-to-many is the correct and efficient choice.

How to eliminate wrong answers

Option B is wrong because a one-to-one relationship between Customers and Orders would require each CustomerID to appear only once in Orders, which is unrealistic for a transactional fact table where one customer can have many orders. Option C is wrong because an inactive relationship with USERELATIONSHIP is only used when you need multiple relationships between the same two tables (e.g., OrderDate and ShipDate), not for the primary dimension-to-fact relationship which should always be active. Option D is wrong because a many-to-one relationship from Orders to Customers with both directions would create ambiguous cross-filtering and potential performance issues; bidirectional filtering is reserved for specific scenarios like many-to-many relationships, not for standard star schema modeling.

Full explanation →

43

Multi-Selecteasy

You are creating a Power BI report that uses a table named Orders with columns: OrderID, OrderDate, ShipDate, and Status. You need to create a calculated table that contains one row per month with the total number of orders shipped in that month. Which TWO steps should you take?

Select 1 answer

A.Use CALENDARAUTO in a measure

B.Use the GROUPBY function

C.Create a date table using CALENDAR or CALENDARAUTO

D.Use SUMMARIZECOLUMNS with 'Date'[Month] and COUNTROWS of Orders

E.Use the VALUES function to get unique months

AnswersD

Using SUMMARIZECOLUMNS with 'Date'[Month] and COUNTROWS of Orders correctly groups orders by month and counts them. This is the direct method to achieve the desired calculated table.

Why this answer

To create a calculated table that shows total orders shipped per month, you can directly group by the month of ShipDate using SUMMARIZECOLUMNS. Since the Orders table already contains a ShipDate column, a separate date table is not required for this aggregation. Option C (creating a date table) is unnecessary here; you can simply extract the month from ShipDate within the grouping.

Option D correctly uses SUMMARIZECOLUMNS with 'Date'[Month] and COUNTROWS of Orders. Note: If the 'Date' table is not already present, you would need to create it, but the question asks for steps to create a calculated table that contains one row per month with totals. The most direct step is to use SUMMARIZECOLUMNS with the month column from the Orders table (or a date table if available).

However, among the given options, only D is a required step.

Exam trap

Candidates may think a separate date table is always required for time-based grouping in calculated tables. In this case, you can group directly by the month of ShipDate using functions like SUMMARIZECOLUMNS or GROUPBY without a date dimension.

Full explanation →

44

MCQmedium

You have a Power BI model with a table named 'Orders' that contains columns: OrderID, CustomerID, OrderDate, and TotalAmount. You need to create a measure that calculates the total sales amount for orders placed in the last 30 days, but only for customers who have placed more than 5 orders in total. What is the most efficient DAX measure?

A.TotalSalesLast30Days = CALCULATE(SUM(Orders[TotalAmount]), FILTER(Orders, Orders[OrderDate] > TODAY() - 30), FILTER(Orders, CALCULATE(COUNTROWS(Orders), ALLEXCEPT(Orders, Orders[CustomerID])) > 5))

B.TotalSalesLast30Days = CALCULATE(SUM(Orders[TotalAmount]), KEEPFILTERS(Orders[OrderDate] > TODAY() - 30), KEEPFILTERS(CALCULATE(COUNTROWS(Orders), ALLEXCEPT(Orders, Orders[CustomerID])) > 5))

C.TotalSalesLast30Days = SUMX(FILTER(Orders, Orders[OrderDate] > TODAY() - 30 && CALCULATE(COUNTROWS(Orders), ALLEXCEPT(Orders, Orders[CustomerID])) > 5), Orders[TotalAmount])

D.TotalSalesLast30Days = CALCULATE(SUM(Orders[TotalAmount]), DATESINPERIOD(Orders[OrderDate], TODAY(), -30, DAY))

AnswerC

This is the correct answer because it uses a single SUMX iterator over a FILTERed table, where the filter expression evaluates both conditions in one row context. Inside the filter, `CALCULATE(COUNTROWS(Orders), ALLEXCEPT(Orders, Orders[CustomerID]))` correctly counts all rows for the same customer, avoiding any interference from the date filter on the outer row, and the AND ensures only customers with more than five orders and a recent order date are included. SUMX then sums the TotalAmount across those qualifying rows, directly matching the requirement while remaining efficient and maintainable.

Why this answer

It iterates over filtered rows where both conditions are met using a single FILTER and SUMX, which is syntactically valid and more efficient than multiple FILTER iterators. Option B is invalid because KEEPFILTERS expects a filter expression, not a scalar boolean result from CALCULATE(...) > 5.

Exam trap

The trap here is that candidates often choose Option B because they think KEEPFILTERS can wrap a scalar boolean condition such as CALCULATE(COUNTROWS(...)) > 5. That is invalid; KEEPFILTERS expects a filter expression, not a boolean scalar. The correct approach uses SUMX with a single FILTER to apply both row-level conditions efficiently.

How to eliminate wrong answers

Option A is wrong because it uses two separate FILTER iterators over the Orders table, which forces a nested row context and can lead to incorrect results due to context transition; the second FILTER attempts to evaluate a CALCULATE with ALLEXCEPT inside a row context, which may not correctly count orders per customer. Option C is wrong because SUMX with a FILTER that includes a CALCULATE inside the logical expression causes context transition for each row, leading to poor performance and potentially incorrect customer-level aggregation; it also applies the date filter row-by-row rather than as a filter argument. Option D is wrong because it only filters by date using DATESINPERIOD and completely omits the customer condition (more than 5 orders), so it does not meet the requirement.

Full explanation →

45

MCQhard

You are a Power BI developer at a retail company. You have a data model with a 'Sales' fact table (10 million rows) and dimension tables: 'Date', 'Customer', 'Product', 'Store'. The 'Sales' table includes columns: SalesID, DateKey, CustomerID, ProductID, StoreID, Quantity, UnitPrice, Discount, TotalAmount. The 'Product' dimension has 5,000 rows and includes columns: ProductID, ProductName, Category, SubCategory, Brand, Price. The 'Store' dimension has 200 rows and includes columns: StoreID, StoreName, Region, City, Manager. The 'Customer' dimension has 100,000 rows. The report currently has a measure 'Total Sales' = SUM(Sales[TotalAmount]) and a measure 'Total Quantity' = SUM(Sales[Quantity]). Users complain that the report is slow when filtering by multiple categories and regions simultaneously. You need to improve performance without changing the data source. Which action should you take first?

A.Create an aggregation table for the Sales table

B.Disable the auto date/time feature in Power BI

C.Change the storage mode of the Sales table to Dual

D.Reduce the number of columns in the Customer dimension by removing unused columns

AnswerD

Removing unnecessary columns reduces model size and improves performance.

Why this answer

Reducing the number of columns in the Customer dimension removes unnecessary data, which decreases model size and improves query performance. Large dimensions like Customer (100,000 rows) benefit from column reduction. Option A (aggregation table) is a valid performance technique but requires more design effort and is not the simplest first step.

Option B (disabling auto date/time) can reduce model size slightly but is not as impactful as removing unused columns. Option C (Dual storage mode) may not improve performance for this scenario and could increase complexity.

Full explanation →

46

MCQhard

Your Power BI dataset uses a SQL view that joins multiple tables. You notice that some columns have null values where you expect data. You suspect the view definition has a bug. How can you verify the view's output in Power Query?

A.Check the 'Table Preview' in the data model

B.Create a new query that runs the view's SQL directly against the source

C.Use 'View Native Query' in Power Query

D.Use 'Data Profiling' in Power Query

AnswerB

By creating a new Power Query query that executes the view's SQL statement directly against the source database, you bypass any existing transformations and fetch the exact rows and columns the view returns. This gives you an independent, unfiltered look at the view's output, allowing you to compare it against what the dataset actually uses. This is the only method listed that reliably exposes the raw view result set.

Why this answer

Creating a new query that runs the view's SQL directly against the source in Power Query allows you to isolate and execute the exact SQL statement, bypassing any transformations or folding issues. This lets you compare the raw output from the source with the view's expected results, directly verifying if the view definition itself contains a bug. It is the most straightforward method to confirm whether the null values originate from the view or from subsequent Power Query steps.

Exam trap

The trap here is that candidates confuse 'View Native Query' (which shows the folded query after transformations) with the ability to run the original view SQL directly, leading them to choose option C instead of B.

How to eliminate wrong answers

Option A is wrong because the 'Table Preview' in the data model shows data after all Power Query transformations have been applied, not the raw output of the SQL view; it cannot isolate the view's definition from subsequent data shaping steps. Option C is wrong because 'View Native Query' in Power Query displays the query that Power Query sends to the source after folding, which may include transformations and not the original view SQL; it does not let you run the view's SQL independently to verify its output. Option D is wrong because 'Data Profiling' in Power Query provides statistics like column quality and distribution, but it does not show the raw SQL output or allow you to execute the view's SQL directly to identify bugs in the view definition.

Full explanation →

47

Multi-Selecthard

Which THREE of the following are best practices for optimizing data load performance in Power BI?

Select 3 answers

A.Remove unnecessary columns and rows during the import process.

B.Split a large fact table into multiple smaller fact tables.

C.Set data types correctly in Power Query to avoid type detection overhead.

D.Use DirectQuery mode instead of Import mode to reduce data load time.

E.Use query folding to push transformations to the source database.

AnswersA, C, E

Reducing data volume improves load time.

Why this answer

Removing unnecessary columns and rows during the import process reduces the amount of data loaded into the Power BI data model, which directly decreases memory usage and refresh time. By filtering out irrelevant data early in Power Query, you minimize the data volume that must be processed and stored, leading to faster load performance.

Exam trap

The trap here is that candidates may confuse 'splitting tables' (Option B) with star schema design best practices, but splitting a fact table unnecessarily violates dimensional modeling principles and harms performance, whereas proper star schema involves splitting dimensions from facts, not splitting facts themselves.

Full explanation →

48

MCQeasy

You are preparing data for a Power BI report. The source data contains a column with values like '1,234.56' formatted as text. You need to convert this to a numeric value for calculations. What is the best approach?

A.In Power Query Editor, split the column by comma and then use the second part.

B.In DAX, create a calculated column using VALUE() after removing commas.

C.In Power Query Editor, replace the comma with an empty string, then change the data type to Decimal Number.

D.In Power Query Editor, use the 'Clean' transform to remove non-numeric characters.

AnswerC

This removes the formatting and converts to number.

Why this answer

Power Query Editor provides the most efficient and scalable method for cleaning and converting text-based numeric data. By replacing the comma with an empty string and then changing the column data type to Decimal Number, you perform the transformation directly in the data preparation layer (M language), which is optimized for performance and avoids the overhead of DAX calculated columns. This approach also ensures the data remains clean for all downstream calculations.

Exam trap

Microsoft often tests the misconception that the 'Clean' transform removes all non-numeric characters, but in reality it only removes non-printable control characters, not punctuation like commas or periods.

How to eliminate wrong answers

Option A is wrong because splitting the column by comma would separate the thousands separator from the number, leaving only the decimal part (e.g., '1' and '234.56'), which loses the integer portion and corrupts the value. Option B is wrong because using DAX with VALUE() after removing commas requires a calculated column that is evaluated row-by-row in the data model, which is less efficient than performing the transformation in Power Query and can lead to performance issues with large datasets. Option D is wrong because the 'Clean' transform in Power Query removes non-printable characters (like tabs and line breaks), not punctuation such as commas, so it would not remove the thousands separator and would leave the text value unchanged.

Full explanation →

49

Multi-Selecteasy

Which TWO of the following are valid DAX functions for time intelligence? (Select two.)

Select 2 answers

A.RANKX

B.DATEADD

C.CONCATENATEX

D.MINX

E.TOTALYTD

AnswersB, E

DATEADD shifts dates by an interval.

Why this answer

DATEADD is a valid DAX time intelligence function that shifts dates forward or backward by a specified number of intervals (days, months, quarters, years). TOTALYTD is also a valid time intelligence function that calculates the year-to-date value of an expression. Both are part of the dedicated time intelligence function set in DAX, which requires a properly marked date table with continuous dates.

Exam trap

Microsoft often tests the distinction between iterator functions (like RANKX, MINX, CONCATENATEX) and dedicated time intelligence functions (like DATEADD, TOTALYTD), causing candidates to confuse functions that perform row-by-row operations with those that manipulate date ranges.

Full explanation →

50

MCQeasy

You need to ensure that only members of the 'Sales' security group can edit reports in the 'Sales Reports' workspace. The workspace currently has four members: three from Sales and one from Marketing. What should you do?

A.Add the Sales security group as a workspace Admin and remove the Marketing user.

B.Configure the workspace to allow only specific users to edit by using the 'Restrict editing' option.

C.Publish the reports to a Power BI app and grant the Sales group 'Build' permissions.

D.Assign the Sales security group the 'Contributor' role and keep the Marketing user as 'Member'.

AnswerA

Adding the Sales group with Admin role grants edit access, and removing the Marketing user prevents their access.

Why this answer

Adding the Sales security group as a workspace Admin grants full editing capabilities to all members of that group. Removing the Marketing user from the workspace ensures that only Sales members have edit access. Workspace roles like Admin allow editing of reports and other content.

Option B is incorrect because Power BI does not have a 'Restrict editing' option at the workspace level; access is controlled through roles. Option C is incorrect because publishing reports as a Power BI app with 'Build' permissions does not control editing within the workspace; it controls how consumers interact with the app content. Option D is incorrect because keeping the Marketing user as a 'Member' still allows them to edit content in the workspace, which contradicts the requirement that only Sales members can edit.

Full explanation →

51

MCQmedium

You are building a star schema model in Power BI. You have a fact table of sales transactions and dimension tables for Date, Customer, Product, and Store. The Date table contains a column 'FiscalYear' that you want to use for time intelligence calculations. What is the best practice for handling the Date relationship?

A.Create a separate fiscal date table and relate it to the fact table using the FiscalYear column.

B.Use the built-in DATESYTD function directly on the OrderDate column from the fact table.

C.Create a composite key using FiscalYear and Quarter columns in the Date table and relate to the fact table.

D.Mark the Date table as a date table using the Calendar icon in the Table tools ribbon and set a relationship on the Date column.

AnswerD

Marking the Date table as a date table using the Calendar icon in the Table tools ribbon is the correct approach because it explicitly identifies the Date column as the continuous set of dates that Power BI uses to enable time intelligence functions like DATESYTD, TOTALYTD, and SAMEPERIODLASTYEAR. Setting a relationship on the Date column—which is unique and contiguous—ensures proper filtering from the date dimension to the fact table, following the star schema design principle. This allows DAX calculations to correctly respect the user's selected date range and fiscal calendar, making it the only option that fully supports robust time-based reporting.

Why this answer

Marking the Date table as a date table (via the Calendar icon in Table tools) and creating a relationship on the Date column is the best practice for time intelligence in Power BI. This ensures that DAX time intelligence functions (e.g., TOTALYTD, SAMEPERIODLASTYEAR) work correctly by using a single, continuous date column that aligns with the fact table's date column. It also avoids the need for composite keys or separate fiscal tables, maintaining a clean star schema.

Exam trap

The trap here is that candidates often think they need a separate fiscal table or composite keys to handle fiscal years, but Power BI's date table marking feature inherently supports fiscal calendars through the 'Mark as Date Table' option and the 'Start of Fiscal Year' setting, making those workarounds unnecessary and incorrect.

How to eliminate wrong answers

Option A is wrong because creating a separate fiscal date table related via FiscalYear would break the star schema's simplicity and prevent proper time intelligence, as DAX functions require a continuous date column, not a fiscal year column. Option B is wrong because DATESYTD requires a date column from a properly marked date table, not a direct call on a fact table column, and it would ignore the fiscal year context. Option C is wrong because a composite key using FiscalYear and Quarter would not provide a continuous date range for time intelligence, and Power BI relationships should be on a single, unique column (typically the date) to avoid ambiguity and support proper filtering.

Full explanation →

52

Multi-Selecthard

You are importing data from a folder containing multiple Excel files with the same structure. You use Power Query's 'Combine Files' feature. Which TWO statements about this process are correct?

Select 2 answers

A.It automatically removes duplicate rows across files.

B.You can change the transformation order after combining.

C.It uses the first file as a template for transformation.

D.It automatically creates relationships between files.

E.It generates a sample file query to define transformations.

AnswersC, E

The first file's transformations are applied to others.

Why this answer

When you use Power Query's 'Combine Files' feature, it uses the first file as a template to infer the schema and transformations. This sample file query defines how each subsequent file is processed, ensuring consistent column types and transformations across all files.

Exam trap

The trap here is that candidates often assume the 'Combine Files' feature automatically handles deduplication or relationship creation, when in fact it only standardizes transformations across files based on the first file's structure.

Full explanation →

53

MCQeasy

A company has a Power BI semantic model with a table named 'Sales' that contains columns: OrderDate, ShipDate, Quantity, and Revenue. The company wants to create a measure that calculates the total revenue for orders shipped within 7 days of the order date. Which DAX expression should be used?

A.CALCULATE(SUM(Sales[Revenue]), DATEDIFF(Sales[OrderDate], Sales[ShipDate], DAY) <= 7)

B.SUMX(FILTER(Sales, Sales[ShipDate] - Sales[OrderDate] <= 7), Sales[Revenue])

C.CALCULATE(SUM(Sales[Revenue]), DATEDIFF(Sales[OrderDate], Sales[ShipDate], DAY) <= 7)

D.CALCULATE(SUM(Sales[Revenue]), Sales[ShipDate] - Sales[OrderDate] <= 7)

AnswerA, C

This expression is syntactically and functionally identical to the other correct option, and its presence as a duplicate answer choice is a common exam design to test your ability to recognize a valid pattern when it appears more than once. The DATEDIFF function with DAY computes the number of day boundaries between the two dates, returning an integer that does not depend on any time portion, so the filter condition in CALCULATE correctly identifies all sales where the ship-date-to-order-date span is exactly seven days or less. Since CALCULATE applies its filter arguments as a row-level condition over the current filter context, the SUM of Revenue is computed only for that subset, yielding the desired total. Recognizing that this version is correct, despite being repeated, reinforces the key rule: use DATEDIFF for date-difference comparisons, not arithmetic subtraction on datetime columns.

Why this answer

Options A and C contain the same valid DAX expression: CALCULATE(SUM(Sales[Revenue]), DATEDIFF(Sales[OrderDate], Sales[ShipDate], DAY) <= 7). This expression correctly uses CALCULATE to modify the filter context, applying DATEDIFF to compute the day difference between OrderDate and ShipDate, and filtering for orders shipped within 7 days. Both are correct because they are identical.

Option B uses SUMX with FILTER, but direct date subtraction (Sales[ShipDate] - Sales[OrderDate]) in DAX treats dates as serial numbers with time components, which can lead to inaccurate day counts and is not recommended. Option D also uses direct date subtraction in a filter argument, which is similarly incorrect. Therefore, A and C are correct.

Exam trap

The trap here is that candidates often assume direct date subtraction works the same in DAX as in Excel or SQL, but DAX treats date subtraction as a datetime operation, not a simple day count, leading to incorrect results or errors.

How to eliminate wrong answers

Option B is wrong because it uses a direct subtraction `Sales[ShipDate] - Sales[OrderDate]`, which in DAX does not return a number of days but rather a date/time value (the difference in days as a decimal), leading to incorrect or unexpected results. Option C is wrong because it is syntactically identical to Option A but is listed as a separate answer; the question expects the correct expression, and Option C is a duplicate of A, not a distinct wrong answer. Option D is wrong because it uses direct subtraction `Sales[ShipDate] - Sales[OrderDate] <= 7`, which in DAX does not evaluate as a day count comparison; it compares a date/time value to the number 7, which is invalid and will cause an error or incorrect filtering.

Full explanation →

54

MCQmedium

You receive a Power Query error: 'Expression.Error: The key didn't match any rows in the table.' This occurs when merging two queries. What is the most likely cause?

A.The join columns have different data types.

B.The second table is empty due to a permission issue.

C.The join columns contain duplicate values.

D.The join column in the first table contains values that do not exist in the second table.

AnswerD

This is the direct reason for the error: when a value in the first table's join column is not present in the second table's join column, the merge operation cannot find a matching row for that key. If the join kind requires a match or you are using a lookup-style operation, Power Query raises 'Expression.Error: The key didn't match any rows' instead of silently inserting nulls.

Why this answer

The error 'The key didn't match any rows in the table' occurs during a merge operation when Power Query attempts to find a matching value from the first table's join column in the second table's join column, but no match exists. This is a standard behavior for inner joins or left outer joins where the lookup fails, and it typically indicates that the first table contains values absent in the second table.

Exam trap

Microsoft often tests the misconception that this error is caused by data type mismatches or duplicate values, but the actual cause is a missing key in the lookup table, which is a fundamental concept in Power Query merge operations.

How to eliminate wrong answers

Option A is wrong because different data types in join columns would cause a type mismatch error (e.g., 'We cannot convert the value...'), not a key-matching error; Power Query automatically attempts type coercion during merge, but if it fails, it raises a different error. Option B is wrong because an empty second table due to permission issues would produce a different error, such as a data source access error or a 'Table is empty' warning, not a key-matching error; the merge operation would still attempt to match keys, but if the table is empty, no rows exist to match, leading to a different behavior (e.g., no rows returned) rather than this specific error. Option C is wrong because duplicate values in join columns are allowed in Power Query merges; they result in a many-to-many or one-to-many relationship, not a key-matching error, and the merge will still succeed by creating multiple matches.

Full explanation →

55

MCQeasy

A company has a Power BI dataset that contains a date table with columns: Date, Year, Month, Quarter, Day. The data model also includes a sales fact table with a SalesDate column. To enable time intelligence functions like TOTALYTD, what is the minimum requirement for the relationship between these tables?

A.Create a calculated column in the sales table to extract the date part and relate it to the date table.

B.Create a one-to-many relationship from the date table to the sales table and mark the date table as a date table.

C.Create a many-to-many relationship between the date table and the sales table.

D.Create a one-to-many relationship from the sales table to the date table with bidirectional cross-filtering.

AnswerB

This is the correct design: Power BI time intelligence functions (e.g., DATESYTD, DATEADD) rely on a date table that is explicitly marked with the Mark as Date Table option, and a one-to-many relationship from the date table to the sales table ensures each date filters its associated sales rows unambiguously. Marking the date table lets the engine identify the date column for time-based calculations, while the one-to-many cardinality matches the logical model where each calendar day can appear in many fact records. This star-schema pattern supports reliable, accurate time-series reporting.

Why this answer

Time intelligence functions like TOTALYTD require a properly configured date table marked as a date table, with a one-to-many relationship from the date table to the sales fact table. This ensures that the date table provides a continuous, unique set of dates that Power BI can use for time-based calculations, and marking it as a date table enables the engine to recognize it as the primary date dimension for time intelligence.

Exam trap

The trap here is that candidates often think any relationship between a date table and a fact table is sufficient, but they overlook the critical step of marking the date table as a date table, which is mandatory for time intelligence functions to work correctly.

How to eliminate wrong answers

Option A is wrong because creating a calculated column in the sales table to extract the date part is unnecessary and does not establish the required relationship; time intelligence functions rely on a dedicated date table with a marked date column, not on derived columns in the fact table. Option C is wrong because a many-to-many relationship between the date table and sales table would violate the requirement that the date table must have unique dates (one side) to support time intelligence, and it would introduce ambiguity in filter propagation. Option D is wrong because a one-to-many relationship from the sales table to the date table reverses the correct direction; the date table must be on the one side and the sales table on the many side, and bidirectional cross-filtering is not required for time intelligence functions.

Full explanation →

56

MCQmedium

You are designing a Power BI semantic model that uses a large fact table from Azure SQL Database. The table includes a date column. You need to ensure that the model supports time intelligence functions like TOTALYTD and SAMEPERIODLASTYEAR. What is the recommended approach?

A.Use the 'Add Calendar' function in Power Query and rely on auto-date/time.

B.Use DirectQuery mode and rely on the SQL Server date functions.

C.Use the built-in date hierarchy from the fact table's date column.

D.Create a separate date table and mark it as a date table in the model.

AnswerD

Creating a separate date table and marking it as a date table is the correct approach because it establishes a continuous, non-blank range of dates that the DAX engine explicitly recognizes for time intelligence. Marking the table via 'Mark as Date Table' sets the ‘Date’ column as the authoritative calendar reference, which enables functions like TOTALYTD, PREVIOUSYEAR, and PARALLELPERIOD to correctly compute period boundaries and offsets. This practice also supports fiscal calendars, holidays, and custom hierarchies, making it the recommended design pattern in Power BI for any model requiring robust date analysis.

Why this answer

Time intelligence functions like TOTALYTD and SAMEPERIODLASTYEAR require a separate date table with a contiguous date range marked as the date table in the model. This ensures that DAX can correctly calculate time-based aggregations across all dates, even if the fact table has gaps or missing dates. Without a marked date table, these functions may return incorrect or blank results.

Exam trap

The trap here is that candidates often think auto-date/time or the built-in date hierarchy is sufficient, but Microsoft explicitly recommends creating and marking a separate date table for reliable time intelligence, especially when using large fact tables with non-contiguous dates.

How to eliminate wrong answers

Option A is wrong because the 'Add Calendar' function in Power Query creates a date table but does not automatically mark it as a date table in the model; you must still manually mark it, and relying on auto-date/time disables the use of explicit date tables, which is required for robust time intelligence. Option B is wrong because DirectQuery mode does not support DAX time intelligence functions like TOTALYTD and SAMEPERIODLASTYEAR; these functions require a local date table in the model, not SQL Server date functions. Option C is wrong because using the built-in date hierarchy from the fact table's date column relies on auto-date/time, which creates hidden date tables but does not allow you to mark a custom date table, leading to potential issues with non-contiguous dates and incorrect time intelligence calculations.

Full explanation →

57

MCQmedium

You publish a Power BI report to a workspace that uses an organizational app. After updating the report, you want users to see the changes immediately without having to reinstall the app. What should you do?

A.Delete and recreate the app from the workspace.

B.Republish the report from Power BI Desktop.

C.Ask users to refresh their browser cache.

D.Update the app in the workspace by selecting 'Update app'.

AnswerD

In the Power BI service, the correct way to propagate workspace changes to the audience is to open the workspace and click "Update app" (or "Update app" in the app editing screen). This action re-publishes the app's content, including the modified report, to all current app users without interrupting their access or requiring them to reinstall the app. It also ensures the app's metadata, navigation, and permissions remain intact. This is the standard lifecycle step after editing a report or dashboard in the source workspace.

Why this answer

Updating the app in the workspace by selecting 'Update app' publishes the latest version of the report (and any other content) to the existing app without requiring users to reinstall. The app is a container that points to the workspace content; updating it refreshes that pointer, making changes immediately available to users who already have the app installed.

Exam trap

The trap here is that candidates confuse updating the workspace content (e.g., republishing a report) with updating the app itself, assuming changes automatically propagate to the app without an explicit 'Update app' step.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the app forces users to reinstall the app from AppSource, causing unnecessary disruption and potential loss of app permissions or custom settings. Option B is wrong because republishing the report from Power BI Desktop only updates the report in the workspace, not the app itself; users would still see the old version until the app is updated. Option C is wrong because refreshing the browser cache does not affect the app's published content; the app is a separate deployment artifact that must be explicitly updated to reflect workspace changes.

Full explanation →

58

MCQmedium

A company has a fact table 'Sales' with a column 'SalesAmount' and a dimension table 'Date'. They want to create a measure that calculates the running total of sales over time. The Date table is marked as a date table. Which DAX expression is correct?

A.Running Total = CALCULATE(SUM(Sales[SalesAmount]), FILTER(ALL(Date), Date[Date] <= EARLIER(Date[Date])))

B.Running Total = CALCULATE(SUM(Sales[SalesAmount]), DATESYTD(Date[Date]))

C.Running Total = TOTALYTD(SUM(Sales[SalesAmount]), Date[Date])

D.Running Total = SUMX(Sales, Sales[SalesAmount])

AnswerB

DATESYTD returns a set of dates from the start of the year to the current context date, which creates a running total within the year. For a full running total across years, one would use DATESBETWEEN or a filter.

Why this answer

DATESYTD returns a set of dates from the start of the year to the latest date in the current filter context, and when wrapped in CALCULATE, it correctly computes a year-to-date running total. Since the Date table is marked as a date table, DATESYTD works seamlessly with the time intelligence functions in DAX.

Exam trap

The trap here is that candidates often confuse DATESYTD with a general running total function, but DATESYTD only works within a single year, so the question's wording 'running total over time' might mislead test-takers into thinking any time intelligence function will work, when in fact a proper running total requires a FILTER with ALL or ALLSELECTED.

How to eliminate wrong answers

Option A is wrong because EARLIER is used in calculated columns to reference an earlier row context, not in measures; in a measure, there is no row context, so EARLIER would cause an error or incorrect results. Option C is wrong because TOTALYTD is a time intelligence function that expects a date column reference as the second argument, but the syntax shown is correct; however, the question asks for a running total over time, not specifically year-to-date, and TOTALYTD would only compute YTD, not a general running total across all dates. Option D is wrong because SUMX(Sales, Sales[SalesAmount]) simply sums the SalesAmount column row by row, which is equivalent to SUM(Sales[SalesAmount]) and does not create any running total or time-based calculation.

Full explanation →

59

MCQmedium

You are modeling data from an Azure SQL Database into Power BI. The source table 'Sales' contains 10 million rows. You need to ensure that the data model supports fast query performance for a report that shows sales by month and product category. The report uses a slicer for year. What is the best practice for improving performance?

A.Disable the auto-date/time feature.

B.Increase the data load frequency to every 15 minutes.

C.Use DirectQuery mode to query the source database directly.

D.Create an aggregate table in Power BI that pre-aggregates sales by month and product category.

AnswerD

Creating an aggregate table in Power BI that pre-aggregates sales by month and product category is the correct approach because it reduces the fact table to a much coarser grain, shrinking the number of rows that report queries must scan. By configuring this aggregate table as an aggregation group in the model, Power BI can automatically route high-level visual queries to the small summary table while reserving the detailed fact table for drill-down operations. This leverages the storage engine's in-memory columnar compression and accelerates time-intelligence calculations such as year-over-year month comparisons, directly addressing the performance bottleneck caused by large transaction-level data.

Why this answer

Creating an aggregate table in Power BI that pre-aggregates sales by month and product category drastically reduces the number of rows the report must scan, from 10 million to a much smaller set of aggregated rows. This enables fast query performance for the slicer and visual-level filters, as Power BI can leverage the aggregate table via its aggregation feature, which automatically redirects queries to the pre-summarized data when possible.

Exam trap

The trap here is that candidates often confuse DirectQuery (option C) as a performance optimization for large data volumes, but in reality, DirectQuery offloads processing to the source and can be slower for aggregated reports, whereas pre-aggregating in Power BI (option D) is the correct approach for fast in-memory query performance.

How to eliminate wrong answers

Option A is wrong because disabling the auto-date/time feature reduces model size and improves load times, but it does not address the core performance bottleneck of scanning 10 million rows for every report interaction; it is a general best practice, not a solution for large-table aggregation. Option B is wrong because increasing data load frequency to every 15 minutes improves data freshness but has no impact on query performance against the existing 10 million rows; it may even degrade performance by causing more frequent refreshes. Option C is wrong because DirectQuery mode sends queries directly to the Azure SQL Database, which would still require scanning 10 million rows on each interaction, and it introduces network latency and dependency on source database performance, often resulting in slower report responsiveness compared to an in-memory aggregated model.

Full explanation →

60

MCQmedium

You connect to a large Azure SQL Database table with over 100 million rows. You need to create a report that shows sales by month for the current year only. Which data reduction technique should you use in Power Query to minimize data load?

A.Import all data and then remove columns that are not needed.

B.In Power Query, apply a date filter on the source query so only current year data is imported.

C.Load all data and filter using a visual-level filter in the report.

D.Use a calculated table in DAX to filter the data.

AnswerB

Query Folding pushes the filter to the database.

Why this answer

Applying a date filter in Power Query at the source query level ensures that only rows from the current year are imported into the Power BI data model. This reduces the data volume from over 100 million rows to a fraction, minimizing memory usage and improving refresh performance. Power Query pushes the filter down to the Azure SQL Database using a WHERE clause in the SQL query, so only the filtered data is transferred over the network.

Exam trap

The trap here is that candidates often assume visual-level filters or DAX calculated tables are sufficient for performance, but they fail to realize that data reduction must occur at the data source or during import to minimize memory and refresh time.

How to eliminate wrong answers

Option A is wrong because importing all 100 million rows and then removing columns still loads the full row count into the data model, wasting memory and bandwidth; column removal does not reduce row volume. Option C is wrong because loading all data and applying a visual-level filter only hides rows in the report, but the entire dataset remains in the model, causing unnecessary memory consumption and slower performance. Option D is wrong because a calculated table in DAX still requires the full table to be loaded first before filtering, negating any data reduction at the import stage.

Full explanation →

61

MCQhard

You are preparing data from a CSV file that has inconsistent date formats. Some rows use 'MM/dd/yyyy' and others use 'dd/MM/yyyy'. You need to parse all dates correctly. What is the best approach in Power Query?

A.Use the 'Replace Values' to standardize the date format, then change data type.

B.Use the 'Parse' -> 'Date' transformation with a specific culture.

C.Use the 'Split Column' by delimiter to separate date parts.

D.Use the 'Detect Data Type' feature to automatically identify the format.

AnswerA

This approach can standardize formats before type conversion.

Why this answer

'Replace Values' allows you to standardize the inconsistent date strings (e.g., swapping day and month parts) before Power Query attempts to parse them as dates. After replacing the delimiters or reordering parts, you can change the column type to 'Date' using a consistent culture (e.g., 'en-US' for MM/dd/yyyy), ensuring all rows parse correctly regardless of original format.

Exam trap

The trap here is that candidates assume 'Parse' with a culture or 'Detect Data Type' can handle mixed formats, but Power Query requires explicit standardization before parsing when formats are inconsistent within a single column.

How to eliminate wrong answers

Option B is wrong because the 'Parse' -> 'Date' transformation with a specific culture assumes all dates in the column follow that single culture's format; it cannot handle mixed formats like MM/dd/yyyy and dd/MM/yyyy in the same column. Option C is wrong because 'Split Column' by delimiter separates date parts into individual columns (e.g., day, month, year), but it does not resolve which part is day vs. month when the order is inconsistent, requiring additional logic to recombine correctly. Option D is wrong because 'Detect Data Type' only identifies the overall data type (e.g., text or date) and cannot distinguish between multiple date formats within the same column; it would likely fail or produce errors for rows not matching the dominant format.

Full explanation →

62

Multi-Selectmedium

You need to audit Power BI activities such as viewing reports, sharing dashboards, and exporting data. Which TWO actions should you take to enable and access audit logs? (Choose two.)

Select 2 answers

A.Configure Microsoft Defender for Cloud Apps to forward logs to Microsoft Sentinel.

B.Access the audit log from the Microsoft 365 compliance portal.

C.Enable the 'Create audit logs for Power BI activities' tenant setting in the admin portal.

D.Use the 'Export' feature in Power BI to export audit logs to a CSV file.

E.Set up a diagnostic setting in Azure Monitor to collect Power BI logs.

AnswersB, C

Audit logs are stored and accessible in the Microsoft 365 compliance portal.

Why this answer

To audit Power BI activities, you must first enable audit logging by turning on the 'Create audit logs for Power BI activities' tenant setting in the Power BI admin portal (option C). Once enabled, you can access the audit logs from the Microsoft 365 compliance portal (option B). Option A is incorrect because Microsoft Defender for Cloud Apps is not the primary location for audit logs; it can integrate but is not required.

Option D is incorrect because Power BI does not have an export feature for audit logs to CSV; you can export from the compliance portal. Option E is incorrect because Azure Monitor diagnostic settings are for Azure resources, not for Power BI audit logs.

Full explanation →

63

Multi-Selectmedium

You are connecting to an on-premises Oracle database from Power BI Service. The gateway is installed and configured. However, the scheduled refresh fails with an error indicating that the data source credentials are invalid. Which TWO steps should you take to resolve the issue? (Choose two.)

Select 2 answers

A.Re-publish the Power BI report from Power BI Desktop.

B.Update the data source credentials in the gateway settings in Power BI Service.

C.Verify that the gateway machine can connect to the Oracle server and that the Oracle client is installed.

D.Edit the data source settings in Power BI Desktop and republish.

E.Reinstall the on-premises data gateway.

AnswersB, C

Updating the data source credentials in the gateway settings in Power BI Service is the correct resolution because the service uses those stored credentials every time it refreshes data through the on-premises data gateway. If the Oracle password changed, the account was locked, or the stored credentials simply expired, the refresh fails with authentication errors. Editing the data source in the service, re-entering the username and password, and re-testing the connection re-establishes a valid identity, allowing the refresh to succeed without altering the report or gateway installation.

Why this answer

The scheduled refresh failure indicates that the stored credentials for the on-premises Oracle data source in Power BI Service are invalid. You must update the data source credentials in the gateway settings under 'Manage gateways' in Power BI Service to provide a valid username and password that the gateway can use to authenticate against the Oracle database. Option C is correct because the gateway machine requires the Oracle client software (e.g., Oracle Data Access Components or ODP.NET) to be installed and configured, and the gateway must have network connectivity to the Oracle server; verifying these ensures the gateway can reach and authenticate with the database.

Exam trap

The trap here is that candidates assume re-publishing or editing the report in Power BI Desktop will propagate credential changes to the gateway, but Power BI Service stores credentials independently for scheduled refresh, and only updating them in the gateway settings resolves the issue.

Full explanation →

64

MCQmedium

You are preparing a Power BI report that uses data from Azure SQL Database. The data includes a date column that needs to be used in time intelligence calculations. You want to ensure that the date column is recognized as a date table in the data model. What should you do?

A.Set the data type of the date column to Date.

B.Use the DAX function DATEADD to create a date table.

C.In the model view, mark the table as a date table by selecting the date column.

D.Create a calculated column using DATEVALUE to convert the date.

AnswerC

This is the correct action because marking a table as a date table explicitly tells Power BI which column represents the primary date and defines the table as the source for time intelligence functions. When a table is marked as a date table, Power BI validates that the column contains unique, continuous dates and uses it to enable functions like TOTALYTD, SAMEPERIODLASTYEAR, and RELATEDDAX date filtering. This designation ensures that relationships and calculations are aligned with the reporting date range.

Why this answer

Marking a table as a date table in the model view explicitly tells Power BI that the table contains a complete set of dates for time intelligence calculations. This ensures that DAX functions like TOTALYTD, SAMEPERIODLASTYEAR, and DATEADD work correctly by using the marked date column as the primary date reference for the model, rather than relying on auto-generated date hierarchies.

Exam trap

The trap here is that candidates often confuse setting a column's data type to Date with marking the table as a date table, assuming the data type alone is sufficient for time intelligence, but Power BI requires explicit table marking to enable proper date filtering and DAX time functions.

How to eliminate wrong answers

Option A is wrong because setting the data type to Date only ensures the column is recognized as a date value, but it does not designate the table as a date table; time intelligence functions require a marked date table with a continuous range of dates. Option B is wrong because DATEADD is a time intelligence function used to shift dates, not a function to create a date table; creating a date table requires CALENDAR or CALENDARAUTO, not DATEADD. Option D is wrong because DATEVALUE converts a text string to a date, but it does not mark the table as a date table; the table must be explicitly marked in the model view for time intelligence to function properly.

Full explanation →

65

MCQeasy

You are importing data from a folder containing multiple CSV files with identical structure. You want to automatically combine all files into one table in Power Query. Which connector should you use?

A.Excel Workbook connector

B.CSV connector

C.Web connector

D.Folder connector

AnswerD

The Folder connector is the correct solution because it connects to a local directory, lists all files, and supports the 'Combine Files' feature in Power Query. With CSV files, it samples the first file to infer the schema, then automatically applies the same transformation to every file and appends the results into a single table. This is the standard approach for importing multiple CSV files with identical structures.

Why this answer

The Folder connector is the correct choice because it is specifically designed to connect to a folder containing multiple files, and when combined with the 'Combine Files' transformation in Power Query, it automatically merges all CSV files with identical structures into a single table. This connector handles the iterative process of reading each file and appending rows without manual scripting.

Exam trap

The trap here is that candidates often choose the CSV connector because they think it can handle multiple files, but it only processes a single file per connection, while the Folder connector is the correct tool for batch combining.

How to eliminate wrong answers

Option A is wrong because the Excel Workbook connector is used for importing data from a single Excel file, not for combining multiple CSV files from a folder. Option B is wrong because the CSV connector imports only one CSV file at a time; it does not support batch processing or automatic combination of multiple files from a directory. Option C is wrong because the Web connector is designed to import data from web URLs or APIs, not from local or network folders containing CSV files.

Full explanation →

66

Multi-Selectmedium

Which TWO of the following are true about using the 'Mark as Date Table' feature in Power BI?

Select 2 answers

A.It is required for any relationship involving a date column

B.The date column can contain duplicate dates

C.The date table must have a column with unique date values

D.It automatically creates all date hierarchy columns (Year, Quarter, Month, Day)

E.It enables time intelligence functions like TOTALYTD

AnswersC, E

The date column must be unique.

Why this answer

Options C and E are correct. Option C is correct because the 'Mark as Date Table' feature requires the designated date column to contain unique, non-duplicate date values to function properly. Option E is correct because marking a date table enables time intelligence functions like TOTALYTD, which rely on a properly marked date table for accurate calculations.

Option A is wrong because the feature is not required for relationships involving a date column; relationships can exist without marking a date table. Option B is wrong because the date column must have unique dates, not duplicate ones. Option D is wrong because marking a date table does not automatically create all date hierarchy columns; it only designates the table as the date table, and hierarchies must be created manually or through other means.

Full explanation →

67

Multi-Selecteasy

Which TWO DAX functions can be used to filter data in a measure?

Select 2 answers

A.VALUES

B.SUM

C.ALL

D.FILTER

E.CALCULATE

AnswersD, E

FILTER returns a table filtered by a condition.

Why this answer

(FILTER) is correct because it is a DAX function specifically designed to return a filtered subset of a table based on a logical condition, making it a primary tool for row-level filtering within measures. Option E (CALCULATE) is correct because it modifies the filter context of a measure by applying or removing filters, effectively filtering data through its filter arguments. Both functions directly control which rows are included in calculations.

Exam trap

The trap here is that candidates confuse functions that return a table (like VALUES or ALL) with functions that actively filter data, or they mistake aggregation functions (like SUM) for filtering functions, leading them to select options that do not actually modify the filter context.

Full explanation →

68

MCQhard

You are managing a Power BI environment that uses Microsoft Purview for data governance. You need to ensure that all new datasets automatically inherit sensitivity labels from their source data. What should you configure?

A.Enable 'Sensitivity labels' in Power BI tenant settings and require labels on datasets.

B.In Microsoft Purview, set up 'Automatic labeling' policies that propagate labels from source to Power BI datasets.

C.Use Microsoft Purview Data Map to scan source data and manually apply labels.

D.Configure a Power Automate flow to apply labels based on dataset metadata.

AnswerB

Automatic labeling policies can propagate labels.

Why this answer

Microsoft Purview's automatic labeling policies can propagate sensitivity labels from source data to Power BI datasets automatically, ensuring new datasets inherit labels. Option A is incorrect because enabling sensitivity labels in Power BI tenant settings only allows manual labeling and does not enforce automatic inheritance from source data. Option C is incorrect because using Purview Data Map to scan and manually apply labels does not provide automatic propagation.

Option D is incorrect because a Power Automate flow would require custom setup and is not the native mechanism for automatic label inheritance from source to Power BI.

Full explanation →

69

MCQmedium

You have a data model with a Sales table and a Date table. You create a measure: Total Sales = SUM(Sales[Amount]). When you add a slicer for Date[Year], the measure does not filter correctly. What is the most likely cause?

A.The relationship is inactive

B.The Date table is not marked as a date table

C.The Sales table has no relationship to the Date table

D.The measure uses SUM instead of SUMX

AnswerA

A relationship marked as inactive does not automatically propagate filters during evaluation. Even though a physical relationship exists between Sales and Date, it is bypassed unless the measure explicitly invokes USERELATIONSHIP (e.g., CALCULATE(SUM(Sales[Amount]), USERELATIONSHIP(Sales[DateKey], Date[DateKey]))). Because that activation is missing, the slicer on Date does not filter the measure and every date shows the same grand-total value.

Why this answer

The most likely cause is that the relationship between the Sales table and the Date table is inactive. In Power BI, only one active relationship can exist between two tables; any additional relationships must be inactive. A slicer on Date[Year] will only filter through the active relationship.

If the active relationship is not the one intended for the measure, the slicer will not affect the measure's result. Using USERELATIONSHIP in the measure or setting the correct relationship as active would resolve this.

Exam trap

The trap here is that candidates often assume a slicer will automatically filter any measure referencing a related table, but they overlook that an inactive relationship requires explicit activation in the measure for filtering to work.

How to eliminate wrong answers

Option B is wrong because marking a table as a date table enables time intelligence functions and ensures continuous date ranges, but it does not affect whether a slicer filters a measure through a relationship. Option C is wrong because if there were no relationship between the Sales and Date tables, the slicer would have no effect at all, but the question states the measure does not filter correctly, implying some filtering occurs or a relationship exists. Option D is wrong because SUM and SUMX both aggregate values; the choice between them affects row context and calculation logic, not whether a slicer filters the measure through a relationship.

Full explanation →

70

MCQeasy

You need to deploy a Power BI report from a development workspace to a production workspace. You want to ensure that the report uses the production dataset connection string without manual changes. What should you use?

A.Manually update the data source in the production workspace after deployment.

B.Use a Power BI template (.pbit) and change the connection string before publishing.

C.Configure a deployment pipeline with parameter rules to override the data source.

D.Publish the report directly to the production workspace and update the dataset.

AnswerC

Power BI Deployment Pipelines allow you to assign parameter rules (e.g., for data source parameters like Server and Database) that override values automatically when content is deployed from dev to test to production. This is the correct choice because it is the only option that truly meets the requirement of the report automatically using the production connection string without any manual adjustment. The rules are configured once in the pipeline and then applied consistently on every deployment, making the process repeatable and governed.

Why this answer

Deployment pipelines in Power BI allow you to define parameter rules that automatically override data source connection strings when content is deployed from development to production. This ensures the report uses the production dataset without any manual post-deployment changes, maintaining consistency and reducing human error.

Exam trap

The trap here is that candidates often confuse manual post-deployment updates (options A and D) or template-based approaches (option B) with the automated, rule-based override mechanism provided by deployment pipelines, which is the only method that meets the 'no manual changes' requirement.

How to eliminate wrong answers

Option A is wrong because manually updating the data source after deployment contradicts the requirement of avoiding manual changes and introduces risk of errors. Option B is wrong because using a .pbit template still requires manual intervention to change the connection string before publishing, which does not automate the process. Option D is wrong because publishing directly to production and then updating the dataset requires manual steps and does not leverage automated deployment rules.

Full explanation →

71

MCQeasy

You have a Power BI report that uses a custom visual from AppSource. The visual is not rendering correctly. What should you check first?

A.The network connection is blocked from reaching AppSource.

B.The visual is not compatible with the report theme.

C.The dataset has row-level security applied.

D.The visual is not certified by Microsoft.

AnswerD

Certification is not required for rendering.

Why this answer

Custom visuals are embedded in the report file when published from Power BI Desktop; they do not require a network connection to AppSource to render. If a visual is not rendering, first check whether the visual is certified by Microsoft, as the Power BI service administrator might have disabled the use of uncertified visuals. Option A is incorrect because the visual does not rely on a live connection to AppSource.

Option B is incorrect because report themes only affect styling, not rendering. Option C is incorrect because RLS filters data but does not prevent visual rendering.

Full explanation →

72

MCQhard

Your organization uses Power BI Premium and wants to enforce that users can only see data relevant to their department (Sales, Marketing, Finance) using row-level security (RLS). The dataset contains a 'Department' column. You have created three RLS roles, each with a filter like [Department] = "Sales". You publish the dataset and add users to the roles. However, users in the Sales role can see all data. What is the most likely cause?

A.The RLS roles were created in the Power BI service, not in Power BI Desktop.

B.The users are members of multiple RLS roles, so they see all data.

C.The RLS filter uses a string comparison that is case-sensitive and the data contains mixed case.

D.The users are also assigned to workspace roles (e.g., Member) that grant them access to the dataset without RLS restrictions.

AnswerD

Users with edit permissions on the dataset bypass RLS.

Why this answer

In Power BI, users assigned to workspace roles (Admin, Member, Contributor) have dataset-level permissions that bypass Row-Level Security (RLS). Since these users can access the dataset directly, RLS filters are not applied. Option A is incorrect because RLS roles are typically created in Power BI Desktop before publishing.

Option B is incorrect; multiple roles combine filters using OR logic, so users in multiple roles see union of all allowed data, not all data. Option C is incorrect because RLS filters are case-insensitive by default. Option D correctly identifies that workspace roles override RLS.

Exam trap

A common trap is assuming that RLS always applies to all users, but workspace-level permissions (Admin, Member, Contributor) supersede RLS. Only users with no workspace role or the 'Viewer' role are subject to RLS.

Full explanation →

73

MCQmedium

You are designing a Power BI data model that includes a table named Sales with 10 million rows. You need to create a relationship between Sales and a Product dimension table. The Product table has 10,000 rows. Which configuration will provide the best query performance?

A.Create a many-to-one relationship from Sales to Product

B.Create a one-to-many relationship from Product to Sales

C.Do not create a relationship; use LOOKUPVALUE in measures

D.Create a relationship with cross filter direction set to Both

AnswerB

This is the standard cardinality for dimension-to-fact relationships, optimized for performance.

Why this answer

A one-to-many relationship from Product (the dimension table with unique values) to Sales (the fact table with many rows) is the standard star schema design. This configuration allows Power BI to use the smaller Product table to filter the larger Sales table efficiently, leveraging in-memory columnar storage and automatic aggregations for optimal query performance.

Exam trap

The trap here is that candidates often confuse the direction of the relationship arrow, thinking the 'many' side should be the source, but Power BI requires the dimension table (unique values) to be on the 'one' side for correct filter propagation and optimal performance.

How to eliminate wrong answers

Option A is wrong because a many-to-one relationship from Sales to Product would imply that Sales is the 'one' side, which is incorrect for a fact-to-dimension relationship; it would confuse the filter propagation direction and degrade performance. Option C is wrong because not creating a relationship and using LOOKUPVALUE in measures forces row-by-row evaluation in the fact table, which is extremely slow with 10 million rows and bypasses Power BI's optimized storage engine and relationship-based filtering. Option D is wrong because setting cross filter direction to Both on a many-to-one relationship between a large fact table and a small dimension table can cause ambiguous filter propagation and performance degradation due to unnecessary bidirectional filtering, especially in large models.

Full explanation →

74

Multi-Selectmedium

Which TWO of the following are valid reasons to use a calculated column instead of a measure in Power BI? (Select exactly two.)

Select 2 answers

A.You need to use the column in a relationship.

B.You need to create a hierarchy for drill-down.

C.You need to perform a dynamic aggregation that changes with filters.

D.You need to calculate a running total.

E.You need to use the value as a filter or slicer.

AnswersA, E

Relationships require columns, not measures.

Why this answer

Calculated columns are evaluated row by row and stored in the model, making them available for use in relationships. Measures, in contrast, are evaluated at query time and cannot be used to define relationships between tables in Power BI.

Exam trap

The trap here is that candidates often confuse the static nature of calculated columns with the dynamic behavior of measures, incorrectly assuming that calculated columns can perform dynamic aggregations or running totals that respond to slicer selections.

Full explanation →

75

MCQhard

You are a Power BI administrator. You need to audit all activities related to sharing reports and dashboards in the Power BI service. Which tool should you use?

A.Microsoft Purview compliance portal audit log

B.Azure diagnostic settings for Power BI

C.Power BI activity log (via admin API or portal)

D.Microsoft Sentinel

AnswerC

Directly logs all user actions.

Why this answer

The Power BI activity log provides a comprehensive record of all user activities within the Power BI service, including sharing reports and dashboards. Option A (Microsoft Purview compliance portal audit log) can capture some Power BI activities but is less specific and may not include all sharing events. Option B (Azure diagnostic settings) exports telemetry data to other destinations and is not designed for direct auditing of user actions.

Option D (Microsoft Sentinel) is a SIEM tool that can ingest logs but is not the primary tool for auditing Power BI activities. The Power BI activity log is the correct choice as it is purpose-built for auditing Power BI user activities.

Full explanation →

Page 1 of 3

All pages

Practice PL-300 by domain

Target a specific domain to shore up weak areas.

Prepare the data Deploy and maintain assets Model the data Visualize and analyze the data Manage and secure Power BI

See all domains with question counts →