Courseiva

Microsoft Power BI Data Analyst PL-300 (PL-300) — Questions 151–217

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

Take a mock examExam hub
Page 2

Page 3 of 3

151
MCQmedium

You are a data analyst at a retail company. You are building a Power BI report to analyze sales performance across multiple stores. The source data comes from an Azure SQL Database that contains a table 'Sales' with columns: StoreID, ProductID, SaleDate, Quantity, and Amount. The database also has a 'Stores' table with StoreID and StoreName, and a 'Products' table with ProductID, ProductName, and Category. You need to create a data model that supports filtering by store, product category, and date, and also allows calculation of year-over-year sales growth. You want to minimize the model size and ensure optimal performance. The data volume is large (millions of rows). You must design the data model. What should you do?

A.Import all tables as they are and create a single flat table by merging Sales, Stores, and Products in Power Query.
B.Import Sales, Stores, and Products tables, create a separate date table using CALENDAR, and establish relationships between Sales and dimension tables.
C.Import Sales table only and create calculated columns for StoreName and ProductName using RELATED.
D.Import Sales table and use the auto date/time feature for time intelligence.
AnswerB

Creating a star schema by importing Sales as a fact table along with Stores, Products, and a separate date table generated via CALENDAR is the optimal design. The date table must be marked as a date table in Power BI to enable time-intelligence functions like TOTALYTD and SAMEPERIODLASTYEAR to work predictably across fiscal and calendar periods. Relationships between Sales and the dimension tables filter facts efficiently, reduce model size through dimension normalization, and improve DAX query performance, making this the correct approach.

Why this answer

It follows the star schema best practice: importing dimension tables (Stores, Products, a dedicated Date table) and the fact table (Sales) separately, then creating relationships. This minimizes model size by avoiding data duplication and enables efficient filtering by store, product category, and date. The separate date table is essential for accurate year-over-year calculations using DAX time intelligence functions like SAMEPERIODLASTYEAR, which require a continuous date range.

Exam trap

The trap here is that candidates often choose Option A (flat table) thinking it simplifies the model, not realizing that star schema design is essential for performance and compression in large datasets, and that Power BI's query folding can handle joins efficiently without merging.

How to eliminate wrong answers

Option A is wrong because merging all tables into a single flat table in Power Query creates massive data duplication (repeating StoreName and ProductName for every sales row), drastically increasing model size and degrading performance with millions of rows. Option C is wrong because importing only the Sales table and using calculated columns with RELATED forces Power BI to store the dimension data within the fact table, bloating the model and losing the benefits of separate dimension tables for filtering and compression. Option D is wrong because relying on the auto date/time feature creates hidden, auto-generated date tables that are not customizable, cannot support proper year-over-year calculations with DAX time intelligence, and can increase model size unnecessarily for large datasets.

Full explanation →
152
MCQmedium

You have a Power BI report that uses a DirectQuery dataset. You need to ensure that users see only the data relevant to their department. What should you implement?

A.Q&A features to restrict natural language queries.
B.Row-level security (RLS) with DAX filter expressions.
C.Object-level security (OLS) to hide tables.
D.Data lineage view to control access.
AnswerB

RLS filters rows based on user identity.

Why this answer

Row-level security (RLS) is the correct approach because it filters data at the query level based on the user's identity. In a DirectQuery model, RLS translates DAX filter expressions into source queries, ensuring that each user only sees rows relevant to their department without duplicating reports or datasets.

Exam trap

The trap here is that candidates confuse row-level security (RLS) with object-level security (OLS), thinking OLS can filter rows when it only hides entire objects like tables or columns.

How to eliminate wrong answers

Option A is wrong because Q&A features allow natural language queries but do not restrict data visibility; they only control how users can phrase questions. Option C is wrong because object-level security (OLS) hides entire tables or columns, not rows, so it cannot filter data by department. Option D is wrong because data lineage view is a metadata visualization tool for impact analysis, not a security mechanism to control user access to data.

Full explanation →
153
MCQmedium

You manage a Power BI workspace used by the sales team. After updating a dataset with new columns, some users report that their reports show old data. You verify that the scheduled refresh completed successfully. What should you do first?

A.Open the report in Power BI Desktop, refresh the dataset, and republish.
B.Clear the users' browser cache.
C.Reconfigure the scheduled refresh to run more frequently.
D.Reset the on-premises data gateway.
AnswerA

Opening the report in Power BI Desktop and refreshing the dataset forces Power Query to re-evaluate the data source schema, including renamed, removed, or added columns. After the refresh, republishing the .pbix file overwrites the dataset in the Power BI service, replacing the stale metadata and ensuring the report's visuals and calculations bind to the current schema. This is the only option that directly updates the dataset definition, not just the data values.

Why this answer

When a dataset is updated with new columns in Power BI Desktop, the report's underlying data model must be refreshed and republished to the Power BI service. Even if the scheduled refresh completes successfully, it only refreshes the existing data structure; it does not automatically incorporate schema changes like new columns. Republishing the .pbix file ensures the service has the updated metadata and data.

Exam trap

The trap here is that candidates assume a successful scheduled refresh automatically propagates all changes, including schema modifications, when in fact it only refreshes data within the existing model structure.

How to eliminate wrong answers

Option B is wrong because clearing the users' browser cache would not resolve the issue of missing new columns; the report in the service still has the old schema. Option C is wrong because increasing the scheduled refresh frequency does not add new columns to the dataset; it only refreshes existing data. Option D is wrong because resetting the on-premises data gateway is unrelated to schema changes; the gateway handles data movement, not dataset structure updates.

Full explanation →
154
Multi-Selecthard

A Power BI administrator needs to enforce that all datasets published to the service use certified data sources only. Which two settings should be configured? (Choose two.)

Select 2 answers
A.Use Microsoft Sentinel to audit Power BI activity logs and flag non-certified data sources.
B.Enable 'Certification' for dataflows in the Power BI tenant settings.
C.Enable 'Certification' for data sources in the Power BI tenant settings.
D.Configure row-level security (RLS) on all datasets.
E.Set up B2B guest user permissions to restrict external data sources.
AnswersB, C

Enabling the 'Certification' tenant setting for dataflows activates the endorsement feature that lets authorized reviewers officially certify reusable dataflows. Once certified, those dataflows are the trusted building blocks that dataset authors can be required to use, and the tenant switch is a prerequisite for applying governance policies that mandate certified dataflows. Without this setting, dataflow certification is impossible, making it the correct control for enforcing that datasets use only certified dataflows.

Why this answer

To enforce that all datasets use certified data sources only, an administrator should enable certification for data sources (Option C) and enable certification for dataflows (Option B). Option C allows data source owners to certify data sources, and Option B allows dataflow owners to certify dataflows. Combined, these settings promote the use of certified components.

Option A (monitoring with Sentinel) only detects non-certified sources, it does not enforce. Option D (RLS) and Option E (B2B permissions) are unrelated to data source certification.

Full explanation →
155
MCQhard

A Power BI report shows a bar chart with sales by region. When users click on a region, they expect a line chart on the same page to filter to that region's sales over time. However, the line chart does not respond to the click. What is the most likely cause?

A.The interaction between the bar chart and line chart is set to 'None'.
B.The line chart uses a continuous axis that cannot be filtered.
C.The bar chart is not set as a slicer.
D.The line chart has a legend with too many items.
AnswerA

In Power BI, visual interactions control whether a selected visual acts as a source filter for other visuals. If the interaction from the bar chart to the line chart is set to 'None', then selecting a bar will not propagate a filter to the line chart, leaving the trend unchanged. To make the line chart respond to region selection, the interaction must be set to 'Filter' (or 'Highlight'), which is the default for compatible visuals. This is the most likely cause of the behavior described, as the other options do not affect cross-filtering.

Why this answer

In Power BI, visual interactions control how one visual affects another when clicked. By default, cross-filtering and cross-highlighting are enabled, but if the interaction between the bar chart and line chart is explicitly set to 'None', clicking a region on the bar chart will not filter or highlight the line chart. This is the most common cause when a visual fails to respond to clicks on another visual.

Exam trap

The trap here is that candidates may think a visual must be a slicer to filter others, but Power BI allows any visual to cross-filter or cross-highlight other visuals by default, and the interaction setting is the key control.

How to eliminate wrong answers

Option B is wrong because a continuous axis does not prevent filtering; filtering applies to the underlying data, not the axis type. Option C is wrong because a bar chart does not need to be a slicer to filter other visuals; standard visuals can cross-filter or cross-highlight other visuals via visual interactions. Option D is wrong because a legend with many items does not prevent a visual from being filtered; it only affects the display of categories.

Full explanation →
156
MCQmedium

You are building a Power BI report for a manufacturing company. You have a large fact table with 50 million rows in Azure SQL Database. You need to minimize the data refresh time and ensure that only new or changed rows are loaded. The source table has a LastModifiedDate column. What should you do?

A.Enable query folding in Power Query to push filters to the source.
B.Configure incremental refresh on the table using the LastModifiedDate column.
C.Schedule a full refresh every hour.
D.Create a Power BI dataflow that performs a full load and then use that dataflow as a source.
AnswerB

Configuring incremental refresh on the LastModifiedDate column is the correct approach because it partitions the table by date ranges and only queries partitions that contain new or changed rows since the last refresh. Power BI stores a rolling window of historical partitions and creates new partitions for each refresh period, drastically reducing the amount of data read from the source and the time required. To implement this, you must define RangeStart and RangeEnd parameters in Power Query and set the incremental refresh policy in the dataset. This directly addresses the challenge of a 50-million-row table that needs near-real-time updates without re-loading the entire table each time.

Why this answer

Incremental refresh in Power BI allows you to load only new or changed rows from a large fact table by filtering on a date/time column such as LastModifiedDate. This minimizes data refresh time by avoiding a full reload of all 50 million rows, and it leverages the source system's ability to efficiently query only the modified data. Power Query pushes the filter logic to Azure SQL Database via query folding, ensuring optimal performance.

Exam trap

The trap here is that candidates often confuse query folding with incremental refresh, thinking that enabling query folding alone will automatically load only new rows, but query folding only optimizes the pushdown of existing filters—it does not create the filtering logic needed for incremental loading.

How to eliminate wrong answers

Option A is wrong because enabling query folding alone does not limit the data loaded to only new or changed rows; it only ensures that filters are pushed to the source, but without incremental refresh, Power Query would still attempt to load the entire table on each refresh. Option C is wrong because scheduling a full refresh every hour would reload all 50 million rows each time, which is inefficient and contradicts the requirement to minimize refresh time. Option D is wrong because creating a dataflow that performs a full load and then using that dataflow as a source does not reduce the initial data volume or refresh time; it simply adds an extra layer without addressing the need for incremental loading.

Full explanation →
157
Multi-Selectmedium

You are preparing data for a Power BI report that requires a date table with continuous dates from 2020 to 2025. Which TWO methods can you use to create this date table in Power Query?

Select 2 answers
A.Use the 'Enter Data' feature and manually type dates.
B.Use the CALENDAR DAX function in a calculated table.
C.Reference another query that already has dates.
D.Use the List.Dates function to generate a list of dates.
E.Create a blank query and use #date and List.Transform to generate dates.
AnswersD, E

List.Dates generates a date list that can be converted to a table.

Why this answer

The List.Dates function in Power Query M generates a continuous list of dates by specifying a start date, a count of dates, and a step duration. This list can then be converted into a table, making it ideal for creating a date table directly in Power Query without leaving the data transformation environment.

Exam trap

The trap here is that candidates confuse DAX functions (like CALENDAR) with Power Query M functions (like List.Dates), leading them to select Option B even though the question explicitly restricts the scope to Power Query.

Full explanation →
158
Multi-Selectmedium

Which TWO are valid methods to handle null values in Power Query? (Choose two.)

Select 2 answers
A.Use the 'Fill Down' or 'Fill Up' option to propagate non-null values into null cells.
B.Remove rows that contain null values using the 'Remove Rows' > 'Remove Blank Rows' option.
C.Replace null values with a default value using the 'Replace Values' transform.
D.Merge the table with another table that has no nulls.
E.Change the data type of the column to a non-nullable type.
AnswersA, C

Fill Down and Fill Up are correct null-handling techniques in Power Query. Fill Down copies the last non-null value above into subsequent null cells until another non-null value is encountered; Fill Up works in the reverse direction. This is ideal for sparse columns where nulls represent the previous known value, such as period-end totals or grouping labels, though leading or trailing nulls may remain when there is no non-null value to propagate.

Why this answer

'Fill Down' and 'Fill Up' propagate the last non-null value into adjacent null cells. Option C is correct because 'Replace Values' can replace nulls with a default value. Option B is incorrect: 'Remove Blank Rows' removes rows where all cells are blank, not rows with nulls in specific columns.

Option D is not a direct method for handling nulls; merging may introduce new data but does not handle existing nulls. Option E is invalid because changing to a non-nullable type causes errors.

Exam trap

Candidates often mistakenly believe that 'Remove Blank Rows' handles null values, but it only removes rows that are entirely blank. To remove rows with nulls in specific columns, use filtering or 'Remove Rows' > 'Remove Duplicates' is not applicable. The correct methods are Fill, Replace, or filtering.

Full explanation →
159
Multi-Selecteasy

Which TWO data source types can be used with Power BI dataflows?

Select 3 answers
A.Exchange Online mailbox
B.PDF file
C.Power BI dataset
D.SharePoint Online list
E.Azure SQL Database
AnswersC, D, E

Power BI datasets are supported as sources in dataflows, enabling linked or computed dataflows.

Why this answer

Power BI dataflows support a wide variety of data sources, including Power BI datasets (Option C), SharePoint Online lists (Option D), and Azure SQL Database (Option E). Therefore, all three options are valid data source types for dataflows. Option A (Exchange Online mailbox) and Option B (PDF file) are not supported as direct source types for dataflows.

Exam trap

Candidates often overlook that Azure SQL Database is a valid data source for Power BI dataflows, mistakenly thinking it is not supported. Be aware that dataflows can connect to many Azure and online services, including SharePoint Online lists, Power BI datasets, and Azure SQL Database.

Full explanation →
160
MCQeasy

You need to create a calculated column in Power BI that categorizes sales amounts as 'Low', 'Medium', or 'High' based on the value. The column should be evaluated row by row. Which DAX function should you use?

A.SWITCH
B.IF
C.CALCULATE
D.FORMAT
AnswerA

SWITCH is the correct choice because it evaluates a single expression against a list of possible values and returns the corresponding result, making it ideal for creating multi-category calculated columns such as 'Low', 'Medium', or 'High'. Unlike nested IF functions, SWITCH keeps the logic linear and readable, and it can evaluate true/false conditions when used with a leading TRUE(), providing a clean row-level classification without context transition complexity.

Why this answer

SWITCH is the correct DAX function because it evaluates an expression (the sales amount) against a series of conditions and returns a corresponding result for each condition. In this scenario, you can use SWITCH(TRUE(), [Sales] < 1000, 'Low', [Sales] < 5000, 'Medium', 'High') to create a calculated column that categorizes values row by row. SWITCH is designed for multiple conditional branches, making it the most efficient and readable choice for this three-tier categorization.

Exam trap

The trap here is that candidates often choose IF because they are familiar with it from Excel, but SWITCH is the preferred DAX function for multiple conditions in Power BI, and the exam tests this distinction to see if you understand DAX-specific best practices.

How to eliminate wrong answers

Option B is wrong because IF is a nested function that becomes cumbersome and error-prone when handling more than two conditions; using IF for three categories would require nested IF statements, which is less efficient and harder to maintain than SWITCH. Option C is wrong because CALCULATE modifies filter context and evaluates an expression in a modified context, but it does not perform row-by-row conditional logic for categorizing values in a calculated column. Option D is wrong because FORMAT is used to convert a value to text based on a format string, not to evaluate logical conditions and return custom categories.

Full explanation →
161
MCQeasy

You need to grant a user the ability to manage permissions on a Power BI workspace but not to view or edit the content. What minimum role should you assign?

A.Contributor
B.Viewer
C.Member
D.Admin
AnswerD

Admin can manage permissions, but it also allows viewing and editing content; there is no role that manages permissions without content access.

Why this answer

The Admin role is the only workspace role that can manage permissions and membership, even though it also allows viewing and editing content. The minimum role required to manage permissions is Admin. Option A is incorrect because Contributor can view and edit content but cannot manage permissions.

Option B is incorrect because Viewer can only view content and cannot manage permissions. Option C is incorrect because Member can view and edit content but cannot manage permissions.

Exam trap

Note that the Admin role still allows viewing and editing content; it is not a permissions-only role. The minimum role to manage permissions is Admin, but it comes with full content access.

Full explanation →
162
MCQeasy

A company has a Power BI semantic model that uses DirectQuery to a SQL Server database. The model contains a large fact table with sales data. Users report that reports using this model are slow. Which design change would most improve query performance?

A.Remove all relationships between tables.
B.Switch the model to Import mode.
C.Remove unnecessary columns from the fact table.
D.Disable the 'Reduce queries' option in report settings.
AnswerC

Removing unnecessary columns from the fact table is correct because DirectQuery operates by pushing queries back to the source, and every extraneous column widens the SELECT statement, increasing network transfer and source-side processing. A narrower fact table means fewer columns are scanned and materialized for each visual interaction, which directly reduces query latency and memory overhead. This is a standard column-pruning practice for DirectQuery performance tuning.

Why this answer

Removing unnecessary columns from the fact table reduces the amount of data that must be transferred from SQL Server to Power BI for each query. In DirectQuery mode, every report interaction sends a query to the source database, so fewer columns mean smaller result sets and faster query execution. This directly addresses the performance bottleneck caused by a large fact table without changing the underlying storage mode.

Exam trap

The trap here is that candidates often assume switching to Import mode is always the best performance fix, but the question specifically asks for a design change that improves query performance in DirectQuery mode, where reducing column count is a more targeted and less disruptive solution.

How to eliminate wrong answers

Option A is wrong because removing all relationships between tables would break the model's ability to filter and aggregate data across tables, making reports unusable and not improving query performance. Option B is wrong because switching to Import mode would require loading the entire large fact table into memory, which could cause memory pressure and long refresh times, and it does not address the root cause of slow queries in DirectQuery mode. Option D is wrong because disabling the 'Reduce queries' option in report settings would actually increase the number of queries sent to the source, making performance worse, not better.

Full explanation →
163
MCQmedium

A data model contains a table 'Sales' with columns: Date, ProductID, Quantity, Amount. There is a 'Products' table with columns: ProductID, ProductName, CategoryID. A measure 'Total Sales' = SUM(Sales[Amount]) returns correct values. However, when a user creates a visual with CategoryID from 'Products' and 'Total Sales', some categories show blank. What is the most likely cause?

A.There are ProductID values in Sales that do not exist in Products table.
B.The 'Total Sales' measure is not properly referencing the Sales table.
C.The relationship between Sales and Products is set to many-to-one, single direction.
D.The relationship is set to both directions (bidirectional).
AnswerA

In a one-to-many relationship between Products and Sales, every ProductID in Sales must have a matching ProductID in Products for the related attribute (e.g., Category) to be populated. If Sales contains ProductID values not present in Products, those rows participate in the relationship as unmatched orphans, so the lookup column from Products is blank. As a result, any visual that slices or groups by Category shows a blank bucket that aggregates the sales from those orphaned ProductID values.

Why this answer

When ProductID values in the Sales table do not have matching entries in the Products table, the relationship between the two tables will result in blank CategoryID values for those unmatched rows. In Power BI, a many-to-one relationship (the default) filters from the 'one' side (Products) to the 'many' side (Sales), but if a Sales row has a ProductID not present in Products, it cannot be matched, and any column from Products (like CategoryID) will appear as blank in visuals. This is a classic data integrity issue where the fact table contains orphaned foreign keys.

Exam trap

The trap here is that candidates often assume the relationship direction or cross-filter setting is the culprit, but the real issue is data integrity—orphaned foreign keys in the fact table—which is a common data modeling pitfall tested in the PL-300 exam.

How to eliminate wrong answers

Option B is wrong because the measure 'Total Sales' = SUM(Sales[Amount]) explicitly references the Sales table, and the question states it returns correct values, so the measure definition is not the issue. Option C is wrong because a many-to-one, single-direction relationship is the default and correct configuration for this scenario; it does not cause blanks for unmatched rows—it simply means the filter context flows from Products to Sales, but orphaned Sales rows still produce blanks in Products columns. Option D is wrong because bidirectional cross-filtering would not fix the blank issue; it would allow filters to flow in both directions but still cannot match a Sales row with a ProductID that has no corresponding row in Products.

Full explanation →
164
MCQmedium

You have a Power BI dataset with a large fact table. You need to optimize report performance when users filter by date. What should you do?

A.Mark the date table as a date table in Power BI.
B.Hide all columns except the date column.
C.Disable cross-filtering between tables.
D.Summarize the fact table by month.
AnswerA

Marking a table as a date table in Power BI assigns a calendar semantic to a dedicated date column, which enables the VertiPaq query engine to natively optimize time-intelligence calculations such as YTD, QTD, and same-period comparisons. The engine uses the contiguous date range of the marked table to generate efficient filter predicates, avoiding fallback to the auto date/time hidden tables and reducing the overhead of date range evaluation.

Why this answer

Marking a date table as a date table enables time intelligence functions and better performance. Option B is wrong because hiding columns does not improve performance. Option C is wrong because disabling cross-filtering might affect user experience but not performance directly.

Option D is wrong because summarizing the fact table reduces granularity, which may not be desired.

Full explanation →
165
MCQmedium

You are a data analyst at a retail company. You have a Power BI semantic model that imports sales data from an Azure SQL Database. The database uses a timestamp column to track transaction time. You need to reduce the data refresh time and ensure that only the last 30 days of data are refreshed during each scheduled refresh. You have already created the necessary parameters rangeStart and rangeEnd in Power Query. What should you do next to implement incremental refresh?

A.In the Power BI service, go to the dataset settings and configure the scheduled refresh.
B.In Power Query Editor, apply the rangeStart and rangeEnd filters to the data and then close and apply.
C.In the Power BI service, create a new refresh schedule and set the incremental refresh period.
D.In Power BI Desktop, on the model view, select the table and set the incremental refresh policy.
AnswerD

In Power BI Desktop, selecting the table in Model view opens the Properties pane, where the Incremental refresh control lets you define the archive period, the incremental period, and the RangeStart/RangeEnd parameters. This policy is saved into the data model and, after publishing, the Power BI service uses it to create date-based partitions and refresh only the partitions that fall within the incremental window. This is the intended, supported way to establish incremental refresh.

Why this answer

Incremental refresh policies are defined in Power BI Desktop on the model view, not in the service or by simply filtering in Power Query. After creating the rangeStart and rangeEnd parameters, you must select the table in the Model view, open the incremental refresh policy dialog, and configure the policy to filter data based on those parameters, ensuring only the last 30 days are refreshed.

Exam trap

The trap here is that candidates confuse filtering in Power Query Editor with setting an incremental refresh policy, not realizing that only the latter creates the partitioned refresh behavior required to reduce data refresh time.

How to eliminate wrong answers

Option A is wrong because configuring scheduled refresh in the Power BI service only sets the refresh frequency; it does not implement incremental refresh filtering. Option B is wrong because applying rangeStart and rangeEnd filters in Power Query Editor without setting an incremental refresh policy will still refresh the entire dataset, not just the last 30 days. Option C is wrong because creating a new refresh schedule in the Power BI service does not define incremental refresh; the policy must be set in Power BI Desktop before publishing.

Full explanation →
166
MCQhard

You are building a Power BI semantic model that combines data from an on-premises SQL Server database and a SharePoint Online list. The SQL Server table contains 10 million rows and updates hourly. The SharePoint list contains 500 rows and updates daily. You need to minimize the data load time and ensure the model refreshes within the scheduled 30-minute window. What should you do?

A.Use DirectQuery for the SQL Server table and Import mode for the SharePoint list.
B.Set both tables to DirectQuery mode.
C.Set the SQL Server table to Dual mode and the SharePoint list to Import mode.
D.Import both tables into the model and disable incremental refresh.
AnswerA

DirectQuery for the SQL Server table is correct because it keeps the 10-million-row table out of the model's memory, avoiding a long and costly import/refresh; queries are pushed to SQL Server at report time. The SharePoint list, which is small, is well-suited to Import mode because SharePoint Online does not support DirectQuery, and importing it enables fast, in-memory performance and full modeling capabilities like calculated columns and relationships.

Why this answer

Using DirectQuery for the large SQL Server table (10M rows, hourly updates) avoids importing all rows into the model, significantly reducing data load time and memory usage. Import mode for the small SharePoint list (500 rows, daily updates) is appropriate since it loads quickly and supports full DAX functionality, while the combination keeps the total refresh within the 30-minute window.

Exam trap

The trap here is that candidates often assume Import mode is always best for performance, but for very large tables with frequent updates, DirectQuery avoids the bottleneck of importing millions of rows, while small tables are better imported to avoid live query overhead.

How to eliminate wrong answers

Option B is wrong because setting both tables to DirectQuery mode would force the SharePoint list to be queried live, which can introduce latency for each report interaction and may not support all DAX functions, plus it doesn't leverage the small size of the SharePoint data for fast import. Option C is wrong because Dual mode is designed for tables that need to serve both as a dimension table in Import mode and as a DirectQuery source, but it doesn't solve the load-time issue for the large SQL Server table—it still requires importing the data, which would exceed the 30-minute window. Option D is wrong because importing both tables, even with incremental refresh disabled, would require loading the full 10M rows from SQL Server on each refresh, which is likely to exceed the 30-minute window and consume excessive memory.

Full explanation →
167
Multi-Selecteasy

Which TWO methods can you use to share a Power BI report with external users who do not have a Power BI Pro license? (Choose two.)

Select 2 answers
A.Embed the report in a secure portal using 'Embed for your customers'.
B.Publish to a public website (Publish to web).
C.Export the report to PDF and share the file.
D.Share directly via Power BI using the user's email address.
E.Export the report to Excel and attach it to an email.
AnswersA, B

Allows users to view without a Pro license.

Why this answer

Options A and B are correct. Option A, 'Embed for your customers,' allows you to embed reports in a secure portal and share with external users without requiring them to have a Power BI Pro license (requires Premium capacity). Option B, 'Publish to a public website (Publish to web),' creates a public URL that anyone can access, including external users without a Pro license.

Option D (share directly via email) requires recipients to have a Pro license. Options C and E (export to PDF or Excel) are not interactive sharing methods and do not allow the report to be consumed as a live report.

Full explanation →
168
MCQhard

You are a data analyst for a multinational corporation. You are building a Power BI report that uses a large fact table (100 million rows) and several dimension tables. The data source is a SQL Server data warehouse. Users need to see near real-time data with a maximum latency of 15 minutes. The current import mode takes too long to refresh. You decide to use DirectQuery mode. However, queries are slow. You need to improve query performance. You consider creating aggregations in the data source. Which approach should you take in Power BI to leverage these aggregations?

A.Create a composite model with an imported aggregated table.
B.Define aggregations in Power BI on the DirectQuery tables.
C.Change the storage mode to Import for the fact table.
D.Create a SQL Server view that aggregates data and use it as the source.
AnswerB

Defining aggregations in Power BI on the DirectQuery tables is correct because Power BI can automatically redirect queries to a cached aggregation table when the query grain matches, drastically reducing load on the source and improving response times. This approach maintains the DirectQuery storage mode for detail-level queries, so users still see fresh data without a full import, and it leverages Power BI's optimization engine rather than requiring source-side changes.

Why this answer

Power BI allows you to define aggregations on DirectQuery tables, which enables the engine to route queries to pre-aggregated data at the source (e.g., SQL Server indexed views or materialized views) when possible, significantly reducing query latency. This approach leverages the existing aggregations in the data source without changing the storage mode or importing data, maintaining near real-time freshness with a 15-minute latency requirement.

Exam trap

The trap here is that candidates often think creating a SQL Server view (Option D) is the correct Power BI approach, but Power BI cannot automatically leverage such views as aggregations unless they are explicitly defined in the model; the exam tests whether you know that aggregations must be defined within Power BI on DirectQuery tables to enable query rewriting.

How to eliminate wrong answers

Option A is wrong because creating a composite model with an imported aggregated table would reintroduce import mode for that table, breaking the near real-time requirement (import mode refreshes are too slow for 15-minute latency) and adding complexity without leveraging the source aggregations directly. Option C is wrong because changing the storage mode to Import for the fact table would revert to the original slow refresh issue, as importing 100 million rows takes longer than 15 minutes, and it does not use the aggregations defined in the data source. Option D is wrong because creating a SQL Server view that aggregates data and using it as the source is a data-source-side change, not a Power BI approach to leverage aggregations; Power BI would treat the view as a regular table and still require DirectQuery or import, missing the optimization of Power BI's aggregation management.

Full explanation →
169
MCQeasy

You have a Power BI report with a matrix visual showing sales by region and product category. You want to allow users to expand and collapse groups. Which feature should you enable?

A.Page tooltips
B.Drill-down mode
C.Drill-through
D.Row and column subtotals
AnswerB

Correct. Drill-down mode provides expand/collapse buttons on hierarchical row headers, allowing users to navigate the hierarchy.

Why this answer

Drill-down mode in a matrix visual allows users to expand and collapse hierarchical levels. When a hierarchy is present, enabling drill-down mode provides expand/collapse icons on row headers, letting users interactively show or hide subcategories. Option A (page tooltips) shows tooltip pages on hover, unrelated to expand/collapse.

Option C (drill-through) navigates to another report page, not within the same visual. Option D (row and column subtotals) is a formatting feature for aggregating totals, not for expanding/collapsing groups.

Exam trap

Candidates often mistake subtotals for enabling expand/collapse, but subtotals are a separate formatting setting. Expand/collapse is inherently tied to hierarchical data and drill-down mode.

Full explanation →
170
MCQeasy

You need to ensure that a Power BI report uses the latest data from a cloud-based Azure SQL Database. The report is configured with scheduled refresh. What is the minimum required license for the dataset owner to configure a scheduled refresh?

A.Power BI Premium capacity
B.Power BI Premium Per User
C.Power BI Free
D.Power BI Pro
AnswerD

Power BI Pro is the correct minimum license because scheduled refresh in the Power BI service is a Pro-only feature. With a Pro license, you can create datasets, publish them to shared capacity, and configure a refresh schedule without needing Premium capacity or Premium Per User. A Pro license is sufficient for the standard, recurring data refresh scenario in shared capacity.

Why this answer

Power BI Pro is the minimum license required for a dataset owner to configure a scheduled refresh against a cloud-based Azure SQL Database. Scheduled refresh is a premium feature that is not available with a Power BI Free license, and while Power BI Premium capacity or Premium Per User can also support scheduled refresh, they are not the minimum requirement. The dataset owner must have a Pro license to schedule refreshes for datasets hosted in shared capacity.

Exam trap

The trap here is that candidates often assume that because Azure SQL Database is a cloud source, a Free license might suffice, but Power BI Free does not support any form of scheduled refresh, regardless of the data source being cloud or on-premises.

How to eliminate wrong answers

Option A is wrong because Power BI Premium capacity is an organizational-level licensing option that provides dedicated capacity and additional features, but it is not the minimum license required for an individual dataset owner to configure scheduled refresh. Option B is wrong because Power BI Premium Per User is a per-user license that grants premium features, but it is not the minimum requirement; a Pro license suffices for scheduled refresh in shared capacity. Option C is wrong because Power BI Free license does not allow scheduled refresh; it only permits manual refresh via Power BI Desktop or the service, and the dataset owner cannot configure automatic scheduled refresh without a Pro or higher license.

Full explanation →
171
MCQmedium

You have a Power BI model where the Sales table is filtered by a Customer dimension. Users report that when they filter a measure from the Customer table (e.g., Customer Count), it does not affect the Sales visual. What is the most likely cause?

A.The relationship is inactive
B.The relationship cardinality is many-to-many
C.The cross-filtering direction is set to one direction (Customer -> Sales), but the filter is applied on Customer
D.The security filtering behavior is set to oneDirection
AnswerA

The relationship is inactive, so no filtering occurs. This is the most likely cause.

Why this answer

When a relationship is inactive, filters do not propagate between tables by default. In this scenario, filtering a measure from the Customer table does not affect the Sales visual because the relationship is inactive. Active relationships are required for cross-filtering to work.

Options B and C would still allow filtering in specific directions, and D is not a standard setting.

Exam trap

Beware of inactive relationships—they are often the culprit when filters don't propagate.

Full explanation →
172
MCQhard

You have a measure as shown in the exhibit. The sales amount is not accumulating correctly; instead, it shows the total sales for all dates, regardless of the selected date filter. What is the problem?

A.The measure should use ALLEXCEPT instead of ALL.
B.The ALL('Date') function removes the filter context, so the calculation returns total sales for all dates.
C.The VAR SelectedDate should be MIN instead of MAX.
D.The relationship between Sales and Date is inactive.
AnswerB

ALL removes the filter on Date, so the condition 'Date'[Date] <= SelectedDate applies to all dates, but without a filter, it sums all sales.

Why this answer

Using ALL('Date') within CALCULATE removes the filter context on the Date table, causing the measure to return the total sales across all dates, not the current date context. Option A is incorrect; ALLEXCEPT would keep certain filters, but the problem here is specifically the removal of all date filters by ALL. Option C is incorrect; using MIN versus MAX in VAR SelectedDate does not cause the described behavior; the issue is the ALL function.

Option D is incorrect; an inactive relationship would prevent proper filtering but would not result in the measure returning the total for all dates; the symptom would be different.

Full explanation →
173
MCQhard

You are a Power BI administrator for a large organization. A team has published a shared dataset to a Premium workspace. They use an XMLA endpoint to programmatically refresh the dataset daily. Recently, the refresh started failing with the error: 'The operation was canceled because the session was terminated by a concurrent operation.' The dataset is not partitioned. You need to ensure the refresh completes without errors. What should you do?

A.Remove all scheduled refreshes and rely solely on the XMLA script.
B.Enable the 'Refresh conflict detection' setting on the dataset to prevent concurrent operations.
C.Change the XMLA script to run less frequently, e.g., once per week.
D.Partition the dataset and refresh partitions sequentially.
AnswerB

Enabling the 'Refresh conflict detection' setting on the dataset is the native solution for this scenario. In Power BI Premium, this setting detects when a second refresh request arrives while a refresh is already executing, and it blocks the conflicting request instead of allowing them to overlap. This eliminates the 'refresh already in progress' error while keeping both the scheduled and XMLA refresh workflows intact.

Why this answer

The error 'The operation was canceled because the session was terminated by a concurrent operation' indicates that two refresh operations are conflicting on the same dataset. Enabling 'Refresh conflict detection' on the dataset prevents concurrent refreshes by queuing or blocking overlapping operations, ensuring the XMLA-triggered refresh completes without interruption.

Exam trap

The trap here is that candidates often assume the error is caused by the XMLA script itself (e.g., frequency or scheduling) and overlook the fact that the conflict is due to concurrent operations, which is directly solved by enabling conflict detection rather than changing the script's schedule or partitioning strategy.

How to eliminate wrong answers

Option A is wrong because removing scheduled refreshes does not address conflicts that could arise from other concurrent operations, such as multiple XMLA scripts or user interactions; the error specifically points to a concurrent session, not just scheduled refreshes. Option C is wrong because reducing the frequency of the XMLA script does not prevent conflicts when the script runs; if another operation occurs at the same time, the conflict persists regardless of frequency. Option D is wrong because partitioning the dataset and refreshing partitions sequentially does not resolve the fundamental issue of concurrent sessions; the error is about session termination, not partition-level parallelism, and sequential partition refreshes can still conflict if multiple sessions attempt to refresh the same dataset.

Full explanation →
174
Drag & Dropmedium

Drag and drop the steps to create a relationship between two tables in Power BI Desktop 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

Relationships are created by dragging columns between tables in the Model view, then confirming settings like cardinality.

Full explanation →
175
Multi-Selecthard

Which TWO actions can improve performance of a Power BI DirectQuery model?

Select 2 answers
A.Switch the model to Import mode
B.Enable bidirectional cross-filtering on all relationships
C.Ensure proper indexing in the source database
D.Use calculated columns with complex logic
E.Reduce the number of columns in the query
AnswersC, E

Indexing speeds up query execution.

Why this answer

Proper indexing in the source database reduces the query execution time for DirectQuery models. DirectQuery sends queries to the source database in real-time, so efficient indexes on columns used in filters, joins, and aggregations minimize table scans and improve retrieval speed.

Exam trap

The trap here is that candidates often confuse performance improvements that apply to Import mode (like reducing columns) with those that are specific to DirectQuery, or they assume bidirectional filtering is always beneficial without considering its overhead on query generation.

Full explanation →
176
MCQmedium

You are loading data from an Excel workbook that has multiple sheets. Each sheet contains sales data for a different region. You need to combine all sheets into one table. What is the most efficient approach?

A.Use 'Append Queries' for each sheet individually.
B.Use 'Merge Queries' to join all sheets into one.
C.Load each sheet as a separate table in the model and create a calculated table to union them.
D.Use Power Query's 'From Folder' option to combine all Excel files in a folder, then select 'Combine & Transform' to use the workbook as a sample.
AnswerA

Correct. The Append Queries feature can combine multiple queries (each representing a sheet) into one table. This is the most efficient method among the given options for combining sheets from a single workbook.

Why this answer

Using 'Append Queries' in Power Query allows you to combine multiple queries (one per sheet) into a single table. You can load all sheets as queries, then use the Append Queries feature to union them all at once, which is efficient and avoids manual repetition. Power Query's Append operation is designed for this purpose and is more efficient than loading separate tables into the model (C) or using Merge (B) which performs joins, not unions. 'From Folder' (D) is intended for combining multiple files, not sheets within a single workbook.

Exam trap

The trap here is confusing 'Append Queries' (union) with 'Merge Queries' (join). Candidates may also think that the 'From Folder' option can combine sheets within a single workbook, but that feature is designed to combine multiple files from a folder, not multiple sheets in one file. The most efficient approach for combining multiple sheets from the same workbook is to load each sheet as a query and then use 'Append Queries' to union them into one table.

How to eliminate wrong answers

Option A is wrong because 'Append Queries' requires manually selecting each sheet and appending them one by one, which is inefficient and not the most efficient approach when dealing with multiple sheets in a single workbook. Option B is wrong because 'Merge Queries' performs a join operation (like SQL JOIN) based on matching columns, not a union of rows, so it would not combine all sheets into one table; it would create a combined table with duplicate or merged columns. Option C is wrong because loading each sheet as a separate table and then creating a calculated table to union them is inefficient and unnecessary, as Power Query can combine them directly without adding extra tables to the model.

Full explanation →
177
MCQhard

Your Power BI dataset uses DirectQuery to a SQL Server data warehouse. Users report that reports are slow. You need to improve performance without changing the data source. What should you do?

A.Switch the dataset to Import mode.
B.Disable the 'Enable query reduction' option in Power BI Desktop.
C.Create aggregated tables in Power BI using the Aggregations feature.
D.Increase the memory limit of the on-premises data gateway.
AnswerC

Aggregations reduce the amount of data queried from the source.

Why this answer

Creating aggregated tables in Power BI using the Aggregations feature allows you to pre-summarize data at a higher granularity while still using DirectQuery. This reduces the amount of data queried from the SQL Server data warehouse, improving report performance without changing the underlying data source or switching to Import mode.

Exam trap

The trap here is that candidates often assume performance improvements must come from switching to Import mode or tuning the gateway, but the Aggregations feature is specifically designed to optimize DirectQuery performance without altering the source system.

How to eliminate wrong answers

Option A is wrong because switching to Import mode would change the data source behavior by caching data locally, which violates the constraint of not changing the data source and may not be feasible for large datasets due to memory limits. Option B is wrong because disabling 'Enable query reduction' would actually increase the number of queries sent to the data source, making performance worse, not better. Option D is wrong because increasing the memory limit of the on-premises data gateway does not improve query performance for DirectQuery; it only helps with data throughput for gateway operations, not the speed of queries against the SQL Server.

Full explanation →
178
Multi-Selecthard

Which THREE components must be in place to enable Power BI data sensitivity labels from Microsoft Purview? (Select exactly three.)

Select 3 answers
A.Power BI admin setting to enable sensitivity labels enabled
B.Sensitivity labels published to users or groups in Microsoft Purview compliance portal
C.Power BI Premium capacity assigned to the workspace
D.Microsoft Purview Information Protection subscription (including Azure Information Protection P1/P2)
E.Power BI Pro license for all users
AnswersA, B, D

The admin must turn on the feature.

Why this answer

Options A, B, and D are correct. To enable Power BI data sensitivity labels from Microsoft Purview, three components are needed: the Power BI admin setting to enable sensitivity labels must be turned on (A), sensitivity labels must be published to users or groups in the Microsoft Purview compliance portal (B), and a Microsoft Purview Information Protection subscription (including Azure Information Protection P1/P2) is required (D). Option C is incorrect because Power BI Premium capacity is not a prerequisite; sensitivity labels work with both Power BI Pro and Premium capacities.

Option E is incorrect because a Power BI Pro license is not required for all users; the feature can be used with any license type if the admin enables it and the necessary subscriptions are in place.

Full explanation →
179
MCQmedium

You are a Power BI developer for a healthcare organization. You are building a dataset that includes patient data from an on-premises SQL Server database. The database contains a table 'PatientVisits' with columns: PatientID, VisitDate, DiagnosisCode, and Cost. The database also has a table 'DiagnosisLookup' with DiagnosisCode and Description. You need to create a star schema in Power BI. The requirements are: - The dataset must include a date dimension table that covers all dates from 2010 to 2030. - The 'PatientVisits' table should be the fact table. - Diagnosis descriptions should be in a dimension table. - You must use Power Query to create the date dimension table using M code. - The data refresh must be scheduled daily via the on-premises data gateway. You have already loaded the 'PatientVisits' and 'DiagnosisLookup' tables. What should you do next to complete the star schema?

A.Use DAX to create a date table using CALENDAR function in Power BI Desktop, then mark it as a date table.
B.Enable the 'Auto date/time' option in Power BI Desktop and hide the generated date hierarchy.
C.In the model view, create a relationship between PatientVisits[VisitDate] and DiagnosisLookup[DiagnosisCode].
D.In Power Query, create a blank query that generates a date table using the List.Dates function with a custom column for Year, Month, etc. Load it into the model and mark it as a date table.
AnswerD

This creates a proper date dimension in Power Query, which can be used for relationships.

Why this answer

The requirement explicitly states that the date dimension table must be created using M code in Power Query, and the List.Dates function is the appropriate M function to generate a continuous range of dates from 2010 to 2030. After creating the table with additional columns like Year and Month, you must load it into the model and mark it as a date table to enable time intelligence functions. This approach satisfies the need for a custom date dimension that is not dependent on DAX or auto-generated hierarchies.

Exam trap

The trap here is that candidates often default to using DAX's CALENDAR function (Option A) because it is simpler, but the question explicitly requires M code in Power Query, making DAX-based solutions incorrect even if functionally equivalent.

How to eliminate wrong answers

Option A is wrong because using DAX with the CALENDAR function violates the explicit requirement to create the date dimension table using M code in Power Query. Option B is wrong because enabling 'Auto date/time' generates hidden date hierarchies automatically, which does not create a dedicated date dimension table in Power Query and does not meet the requirement for a custom M-based date table covering 2010 to 2030. Option C is wrong because creating a relationship between PatientVisits[VisitDate] and DiagnosisLookup[DiagnosisCode] is semantically incorrect; VisitDate is a date field and DiagnosisCode is a code field, and the correct relationship should be between PatientVisits[DiagnosisCode] and DiagnosisLookup[DiagnosisCode] to link the fact table to the diagnosis dimension.

Full explanation →
180
MCQeasy

A user reports that a Power BI report is not refreshing data from a SQL Server database. The dataset uses Import mode. The gateway cluster shows all gateways are online. What is the most likely cause?

A.The report is using a scheduled refresh with a conflicting time.
B.The gateway version is incompatible with the SQL Server version.
C.The dataset uses DirectQuery mode which requires a live connection.
D.The data source credentials are incorrect or expired.
AnswerD

Incorrect or expired data source credentials are the most frequent cause of a Power BI scheduled refresh failure. When you configure a dataset for refresh, Power BI stores the authentication values—Windows credentials, database passwords, or OAuth tokens—and if those are changed or time out, the service cannot authenticate to the source and the refresh operation fails with an error. Updating the credentials in the dataset settings under 'Edit credentials' resolves the issue, and you should verify that the account still has the same permissions.

Why this answer

In Import mode, Power BI caches data and refreshes it on a schedule using stored credentials. If those credentials expire or become invalid, the refresh fails even though the gateway cluster shows as online. The gateway being online only indicates network connectivity, not that the stored credentials are still valid for the SQL Server database.

Exam trap

The trap here is that candidates see 'gateway cluster shows all gateways are online' and assume the issue must be elsewhere, but gateway online status does not validate the stored data source credentials, which are a separate authentication layer that can expire or become invalid independently.

How to eliminate wrong answers

Option A is wrong because a conflicting scheduled refresh time would cause a refresh to be skipped or queued, not a persistent failure; the report would still refresh at the next available window. Option B is wrong because gateway version incompatibility with SQL Server version is extremely rare; the gateway communicates via standard TDS protocol and is backward-compatible with most SQL Server versions. Option C is wrong because the question explicitly states the dataset uses Import mode, not DirectQuery mode, so the requirement for a live connection is irrelevant.

Full explanation →
181
Multi-Selectmedium

Which TWO actions are best practices for optimizing Power BI data models?

Select 2 answers
A.Replace text-based relationship columns with integer keys.
B.Use calculated columns instead of measures where possible.
C.Hide columns that are not used in reports.
D.Remove columns that are not used in reports.
E.Use many-to-many relationships instead of bridge tables.
AnswersA, D

Integer keys improve join performance.

Why this answer

Replacing text-based relationship columns with integer keys (surrogate keys) reduces storage size and improves join performance. Power BI's VertiPaq engine compresses integer columns far more efficiently than text columns, leading to faster query execution and smaller memory footprint.

Exam trap

The trap here is that candidates often confuse 'hiding' columns (which only affects report visibility) with 'removing' columns (which actually reduces model size and improves performance), leading them to select Option C instead of D.

Full explanation →
182
MCQmedium

A company is deploying Power BI for the entire organization. They need to prevent users from sharing reports with external email addresses. Which configuration should the Power BI admin use?

A.Disable 'Share content with external users' in the Power BI admin portal.
B.Configure a Conditional Access policy in Microsoft Entra ID.
C.Apply a Microsoft Purview sensitivity label.
D.Set the workspace sharing settings to 'Only existing users'.
AnswerA

Disabling 'Share content with external users' in the Power BI admin portal is the correct tenant-level control because it directly blocks the ability for any user's shared dashboards, reports, or apps to be accessible to email addresses outside your organization. This setting overrides per-user and per-workspace sharing permissions, acting as the only definitive switch that prevents external email invitations from being accepted or even invited. Without this disabled, users can still share to external identities even if other access policies are in place.

Why this answer

The Power BI admin portal provides a tenant-level setting 'Share content with external users' that can be disabled to prevent sharing with external email addresses. Option B is incorrect because Conditional Access policies in Microsoft Entra ID control access based on conditions but do not specifically block external sharing within Power BI. Option C is incorrect because Microsoft Purview sensitivity labels classify and protect data but do not block sharing.

Option D is incorrect because workspace sharing settings only control sharing within the workspace and do not prevent external sharing at the tenant level.

Full explanation →
183
MCQmedium

Refer to the exhibit. You are reviewing a DAX measure in Power BI. The measure is intended to calculate total sales for the year 2024. However, when used in a visual with a slicer on 'Sales[Date]', the measure does not respect the slicer selection. What is the most likely reason?

A.The FILTER function overrides the slicer filter context.
B.The CALCULATE function removes all filters by default.
C.The measure should use ALL(Sales[Date]) to respect slicers.
D.The DATE function syntax is incorrect.
AnswerA

In DAX, CALCULATE modifies the filter context by applying its filter arguments. When FILTER is used as a filter argument, it creates a new filter on the Sales table that replaces any existing filters on that table, including those from a slicer. This replacement behavior is by design: filter arguments in CALCULATE override existing filters on the same columns or tables. Therefore, the slicer's context is ignored, and the measure returns values based solely on the FILTER condition.

Why this answer

The FILTER function in the measure creates a new filter context that overrides the existing slicer filter context on 'Sales[Date]'. When CALCULATE evaluates the expression, it applies the FILTER as a table modifier, which replaces any external filters on the Date column, causing the slicer to be ignored. This is a common DAX behavior where explicit filter arguments in CALCULATE take precedence over existing filter contexts.

Exam trap

The trap here is that candidates often assume CALCULATE always respects slicers, but they miss that explicit filter arguments (like FILTER) override external filters on the same columns, leading to the slicer being ignored.

How to eliminate wrong answers

Option B is wrong because CALCULATE does not remove all filters by default; it only modifies the filter context based on its filter arguments, and without a REMOVEFILTERS or ALL function, it preserves existing filters. Option C is wrong because using ALL(Sales[Date]) would remove the slicer filter entirely, making the measure ignore the slicer even more, not respect it; to respect slicers, you should not use ALL or should use KEEPFILTERS. Option D is wrong because the DATE function syntax (DATE(2024,1,1) and DATE(2024,12,31)) is correct and would not cause the measure to ignore slicer selections.

Full explanation →
184
MCQmedium

Your organization uses Power BI to analyze sales data stored in Azure SQL Database. The data model includes a fact table with millions of rows. To improve performance, you need to reduce the amount of data loaded into the model. Which action should you take?

A.Apply row-level filters in Power Query to import only relevant rows
B.Use calculated tables in DAX to summarize data
C.Disable the Auto Date/Time feature
D.Configure incremental refresh with a date filter
AnswerA

Row-level filtering in Power Query (M) is applied before data enters the VertiPaq engine, enabling you to import only the rows that are relevant to your analysis. This reduces the number of rows materialized in the model, which directly shrinks the overall memory footprint and improves refresh time, query performance, and columnar compression ratios. Because only the necessary data is loaded, all downstream measures and reports run over a targeted dataset, making this the most effective way to reduce the initial data load size.

Why this answer

Applying row-level filters in Power Query reduces the volume of data imported into the Power BI model by only loading rows that meet specific criteria. This directly minimizes the data footprint in memory, improving query and refresh performance, especially for fact tables with millions of rows stored in Azure SQL Database.

Exam trap

The trap here is that candidates often confuse incremental refresh with reducing the initial data load, but incremental refresh only optimizes refresh cycles over time and does not limit the first full load unless combined with a date filter in Power Query.

How to eliminate wrong answers

Option B is wrong because calculated tables in DAX are created after data is loaded into the model, so they do not reduce the amount of data imported; they can even increase memory usage by duplicating or aggregating data. Option C is wrong because disabling the Auto Date/Time feature reduces the number of hidden date tables generated by Power BI, which improves model size and performance, but it does not reduce the amount of data loaded from the source. Option D is wrong because incremental refresh with a date filter partitions data for refresh scheduling and reduces the volume of data refreshed each time, but it still requires the full historical data to be loaded initially unless combined with a filter that limits the initial load; the question asks specifically about reducing the amount of data loaded into the model, and incremental refresh alone does not achieve that without additional filtering.

Full explanation →
185
MCQhard

You are merging two queries in Power Query: 'Orders' and 'Customers'. The 'Orders' table has a 'CustomerID' column, and 'Customers' has 'CustomerID' and 'Name'. You need to bring the 'Name' into 'Orders' but only for matching CustomerIDs; unmatched rows should be removed. Which join kind should you use?

A.Right Anti
B.Full Outer
C.Inner
D.Left Outer
AnswerC

Inner join retains only rows where a matching key exists in both tables—so an order is included only if it has a corresponding customer, and customers appear only if they have at least one order. This produces exactly the intersection of the two queries, which is the standard approach for combining transactional and dimensional data to analyze completed order-customer pairs.

Why this answer

The Inner join kind in Power Query returns only rows where there is a match in both tables based on the key columns. Since the requirement is to bring the 'Name' into 'Orders' only for matching CustomerIDs and to remove unmatched rows, the Inner join is the correct choice. It ensures that only orders with a corresponding customer in the 'Customers' table are retained, and the 'Name' column is added to those matching rows.

Exam trap

The trap here is that candidates often confuse Left Outer join with Inner join, thinking that 'bringing in data only for matches' means keeping all left rows, but Left Outer retains unmatched left rows with nulls, while Inner removes them entirely.

How to eliminate wrong answers

Option A is wrong because Right Anti join returns only rows from the right table that have no match in the left table, which would exclude all matching rows and is the opposite of what is needed. Option B is wrong because Full Outer join returns all rows from both tables, including unmatched rows from each side, which would keep orders without a matching customer and introduce nulls, violating the requirement to remove unmatched rows. Option D is wrong because Left Outer join returns all rows from the left table (Orders) and only matching rows from the right table (Customers), which would keep orders without a matching customer (with null in Name), not removing unmatched rows as required.

Full explanation →
186
Multi-Selectmedium

You have a Power BI report that uses a custom visual from AppSource. The visual is not rendering correctly. Which three steps should you take to troubleshoot?

Select 3 answers
A.Disable hardware acceleration in Power BI Desktop
B.Check if the visual version is compatible with your Power BI Desktop version
C.Update the visual to the latest version from AppSource
D.Clear the browser cache
E.Verify that the visual uses the correct data fields
AnswersB, C, E

Custom visuals are compiled against a specific Power BI API version, and that API version must be within the range supported by your Power BI Desktop release. When a visual was built for an older API or targets a newer API that your Desktop does not implement, the visual can fail to load, appear blank, or throw a rendering exception. Checking compatibility means verifying the minimum supported Power BI version on the visual's AppSource listing or its metadata, and confirming your Desktop is at or above that version. This is a critical diagnostic because an incompatible visual will misbehave regardless of how correctly its data fields are configured.

Why this answer

Options B, C, and E are correct. Checking compatibility (B) ensures the visual supports your version of Power BI Desktop. Updating the visual (C) can fix known bugs.

Verifying correct data fields (E) ensures the visual has the necessary input. Option A, disabling hardware acceleration, is a general troubleshooting step not specific to custom visuals. Option D, clearing browser cache, applies to Power BI Service, not Desktop.

Full explanation →
187
MCQmedium

You have a Power BI data model with a table named Employees that includes columns: EmployeeID, ManagerID, and EmployeeName. You need to create a hierarchy that shows the reporting structure. Which type of relationship is required?

A.Many-to-many relationship
B.Bidirectional cross-filtering
C.A self-referencing relationship
D.One-to-many relationship to a separate table
AnswerC

A self-referencing relationship connects EmployeeID to ManagerID within the same table, enabling a hierarchy.

Why this answer

A self-referencing relationship (Option C) is required because the Employees table contains both EmployeeID and ManagerID, where ManagerID references EmployeeID within the same table. This allows Power BI to create a parent-child hierarchy that accurately represents the reporting structure, such as an org chart. In Power BI, this is implemented by creating a relationship from ManagerID to EmployeeID within the same table.

Exam trap

The trap here is that candidates confuse a self-referencing relationship with a one-to-many relationship to a separate table, thinking a manager table is required, when Power BI can handle parent-child hierarchies directly within a single table.

How to eliminate wrong answers

Option A is wrong because a many-to-many relationship would imply multiple managers per employee or multiple employees per manager in a non-hierarchical way, which does not model a standard reporting structure. Option B is wrong because bidirectional cross-filtering is a filter direction setting, not a relationship type; it controls how filters propagate across relationships but does not define the structure needed for a hierarchy. Option D is wrong because a one-to-many relationship to a separate table would require a distinct manager table, which is unnecessary and would break the self-referencing pattern needed for a single-table hierarchy.

Full explanation →
188
MCQmedium

You have a Power BI model with a 'Date' table marked as a date table. You need to create a measure that calculates the running total of sales over the last 12 months. Which DAX function should you use?

A.PREVIOUSYEAR
B.DATESYTD
C.DATESINPERIOD
D.DATEADD
AnswerC

DATESINPERIOD is a general-purpose time intelligence function that returns a table of dates from an initial start date and moves a specified number of intervals (such as -12 months) into the past or future. When used with a start date of the current context date and an interval of -12 MONTH, it dynamically constructs the exact trailing 12-month period, including all dates from the current date going back one year. This makes it the correct choice for a last-12-months measure because it directly defines the rolling window based on the current filter context.

Why this answer

DATESINPERIOD, is correct because it allows you to define a dynamic window of dates—specifically, the last 12 months ending with the latest date in the current filter context. When used with a measure like CALCULATE(SUM(Sales[Amount]), DATESINPERIOD('Date'[Date], MAX('Date'[Date]), -12, MONTH)), it shifts the date range backward by 12 months from the last visible date, making it ideal for a rolling 12-month total. The 'Date' table being marked as a date table ensures that time intelligence functions respect the continuous date range.

Exam trap

The trap here is that candidates often confuse DATESYTD (which is for year-to-date, not rolling) with a trailing 12-month calculation, or they mistakenly think PREVIOUSYEAR can handle a dynamic window, when in fact it only returns a fixed prior calendar year.

How to eliminate wrong answers

Option A is wrong because PREVIOUSYEAR returns the entire previous calendar year (e.g., all of 2023) relative to the current context, not a rolling 12-month window that moves with each period. Option B is wrong because DATESYTD calculates a year-to-date total from the start of the calendar year to the last date in context, which is a fixed annual accumulation, not a trailing 12-month period. Option D is wrong because DATEADD shifts a set of dates by a specified interval (e.g., -1 year) but returns a set of dates shifted from the original, not a contiguous 12-month window ending at the current context; it requires additional logic to create a rolling total.

Full explanation →
189
MCQeasy

Refer to the exhibit. You are configuring a scheduled refresh for a Power BI dataset. The exhibit shows the refresh schedule settings. The dataset is in a workspace in a Premium capacity. The scheduled refresh runs at 5:00 AM UTC daily. However, the refresh is failing consistently. What is the most likely cause?

A.The notify option should be set to 'OnFailureOrSuccess' to get alerts.
B.The data source requires a gateway to be configured for refresh.
C.The refresh time is outside the allowed window for Premium capacities.
D.The dataset is in a Premium capacity, which does not support scheduled refresh.
AnswerB

On-premises data sources require a gateway for scheduled refresh, even in Premium.

Why this answer

The exhibit shows a scheduled refresh configured for a dataset in a Premium capacity workspace, but the refresh is failing consistently. The most likely cause is that the data source requires a gateway to be configured for refresh. Even in Premium capacities, if the data source is on-premises or within a private network (e.g., SQL Server, Oracle, or SharePoint on-premises), an on-premises data gateway must be installed and configured to enable the Power BI service to connect and refresh the data.

Without a gateway, the scheduled refresh will fail because the cloud service cannot directly access the local data source.

Exam trap

The trap here is that candidates often assume Premium capacities automatically resolve connectivity issues or that scheduled refresh is not supported in Premium, when in reality the gateway requirement is independent of capacity tier and depends solely on the data source location.

How to eliminate wrong answers

Option A is wrong because the notify option (set to 'OnFailureOrSuccess' or 'OnFailure') controls email notifications for refresh outcomes, but it does not affect whether the refresh succeeds or fails; it only determines if you receive alerts. Option C is wrong because Premium capacities have a larger refresh window (up to 48 refreshes per day) and 5:00 AM UTC is well within the allowed window; there is no restriction that would cause a failure at that time. Option D is wrong because Premium capacities fully support scheduled refresh; in fact, they offer more frequent refresh slots than shared capacities, so this is not a limitation.

Full explanation →
190
MCQhard

You are designing a Power BI solution that ingests data from multiple sources: Azure Blob Storage, Salesforce, and an on-premises Oracle database. The data must be combined into a single semantic model. The Oracle database contains sensitive customer information that must be masked before being loaded. Which approach should you use to prepare the data?

A.Create a Power BI dataflow that extracts, transforms, and masks data before loading into the semantic model
B.Use DirectQuery to connect to all sources and rely on database-level masking
C.Import all data into Power BI Desktop and apply transformations in the Power Query Editor
D.Stage the data in an Azure SQL Database and use SQL Server Analysis Services to mask data
AnswerA

Power BI dataflows are a native, cloud-based ETL service in the Power BI service that can connect to a wide range of sources, apply data cleansing and shaping logic through Power Query Online, and include masking steps such as hashing, replacing, or removing sensitive columns before the resulting entity is loaded into a semantic model. This centralized approach supports enterprise-scale data preparation, scheduled refresh, and reusable entities that can serve multiple reports and datasets, making it the right architecture for this scenario.

Why this answer

Power BI dataflows provide a cloud-based ETL solution that can connect to Azure Blob Storage, Salesforce, and on-premises Oracle (via an on-premises data gateway), perform transformations including data masking, and then load the prepared data into a shared semantic model. This approach centralizes data preparation, ensures sensitive data is masked before any downstream consumption, and supports scheduled refreshes without requiring additional infrastructure.

Exam trap

The trap here is that candidates often assume data masking must be done at the database level or via a separate service like SSAS, but Power BI dataflows can perform masking during the transformation phase, making them the most integrated and efficient solution for this multi-source scenario.

How to eliminate wrong answers

Option B is wrong because DirectQuery does not allow data masking within Power BI; it passes queries directly to the source, so sensitive data would remain unmasked unless the source itself applies masking, which is not guaranteed across heterogeneous sources. Option C is wrong because importing all data into Power BI Desktop and applying transformations in Power Query Editor only masks data locally in the .pbix file, not in a shared, scalable semantic model, and it does not support scheduled cloud-based refreshes for on-premises Oracle without additional gateway configuration. Option D is wrong because staging data in Azure SQL Database and using SQL Server Analysis Services (SSAS) to mask data introduces unnecessary complexity and cost, and SSAS is not required for masking; Power BI dataflows can perform masking natively without additional services.

Full explanation →
191
MCQeasy

You have a Power BI report with a page that contains a bar chart showing sales by product category. You want to allow users to click on a bar and navigate to a different report page that shows detailed sales for that category. Which feature should you use?

A.Bookmarks
B.Report page tooltips
C.Cross-filtering
D.Drillthrough
AnswerD

Drillthrough is a built-in Power BI feature that enables navigation from a data point on a source visual to a separate, binded target report page. When the user right-clicks a bar and selects the drillthrough target, the target page is automatically filtered to the clicked data point's field values (e.g., the specific category), providing a contextual detail view. This matches the requirement exactly because it is triggered by a per-data-point action and results in a page transition.

Why this answer

Drillthrough is the correct feature for navigating from a summary visual to a detail page for a specific data point. Cross-filtering only filters other visuals on the same page. Bookmarks are for saved views.

Report page tooltips are for hover details. Custom visuals are not needed.

Full explanation →
192
MCQeasy

You need to connect Power BI to an Excel file stored on a local network drive. The file is updated manually each morning. You want the Power BI report to always show the latest data when opened. Which data connectivity mode should you choose?

A.Live Connection
B.Dual
C.Import
D.DirectQuery
AnswerC

Import mode loads the contents of the Excel file into the VertiPaq in-memory engine, where data is compressed and stored for fast interactive analysis. After the initial load, you can refresh the dataset on a schedule to pick up changes in the workbook, though for files on a local machine an on-premises data gateway is needed for automated refresh. Because the data is cached, all Power BI features—including calculated columns, measures, and RLS—are fully supported, and visuals do not hit the source file on every interaction.

Why this answer

(Import) is correct because Power BI must load the Excel data into its internal VertiPaq engine to support the full range of transformations and visualizations. Since the file is on a local network drive and updated manually, Import mode allows you to refresh the dataset on demand or via a scheduled refresh, ensuring the report always shows the latest data when opened. DirectQuery and Live Connection are not applicable because they require a live queryable data source (like SQL Server or Analysis Services), not a flat file.

Exam trap

The trap here is that candidates often confuse DirectQuery with the ability to query any file-based source, but Microsoft explicitly restricts DirectQuery to SQL-based and OData sources, not Excel or CSV files.

How to eliminate wrong answers

Option A (Live Connection) is wrong because it is used only for connecting to an Analysis Services tabular model or a Power BI dataset, not to an Excel file stored on a network drive. Option B (Dual) is wrong because Dual mode is a storage mode that combines Import and DirectQuery for composite models, but it still requires a DirectQuery-capable source (like SQL Server) and cannot be used with Excel files. Option D (DirectQuery) is wrong because DirectQuery mode is designed for relational databases or other sources that support real-time querying; Excel files are not supported in DirectQuery mode in Power BI.

Full explanation →
193
Multi-Selecthard

You manage a Power BI tenant. You need to prevent users from sharing reports with external users. Which THREE actions should you take?

Select 3 answers
A.Create a Microsoft Entra ID conditional access policy to block external users.
B.Disable 'Publish to web' in the admin portal.
C.In the Power BI admin portal, disable 'Share content with external users'.
D.Disable 'Create app workspaces' for non-admins.
E.Disable 'Export to Excel' for all reports.
AnswersA, B, C

Blocks access from external accounts.

Why this answer

Options A, B, and C are correct. Creating a Microsoft Entra ID conditional access policy blocks external users from accessing resources. Disabling 'Publish to web' prevents public embedding of reports.

Disabling 'Share content with external users' in the admin portal prevents sharing with external users. Option D is wrong because disabling 'Create app workspaces' does not prevent sharing with external users; it prevents creation of workspaces. Option E is wrong because disabling 'Export to Excel' does not affect sharing.

Full explanation →
194
MCQeasy

You are importing data from a CSV file that contains a column 'Date' with values like '2026-01-15'. After loading, Power Query detects the column as type 'text'. What is the recommended step to ensure the column is treated as a date?

A.In Power Query, select the column and change the data type to 'Date' using the 'Data Type' dropdown.
B.In Power BI Desktop, use the 'Format' pane to set the column as a date.
C.Use the 'Parse' -> 'Date' transformation in Power Query.
D.Use the 'Detect Data Type' button in Power Query to automatically detect all columns.
AnswerA

This explicitly sets the data type.

Why this answer

In Power Query, the recommended method to convert a text column containing date-formatted strings (like '2026-01-15') to a proper Date type is to select the column and change its data type using the 'Data Type' dropdown in the Transform tab. This ensures the column is treated as a date for downstream calculations and modeling. Power Query automatically parses the text into a date based on the locale and format of the data.

Exam trap

The trap here is that candidates confuse the 'Format' pane in the report view (which only changes display formatting) with the Power Query data type change (which alters the column's data type in the data model), leading them to select Option B.

How to eliminate wrong answers

Option B is wrong because the 'Format' pane in Power BI Desktop is used for visual formatting (e.g., display format of a date in a report), not for changing the underlying data type of a column in the data model. Option C is wrong because there is no 'Parse' -> 'Date' transformation in Power Query; the correct transformation is 'Change Type' -> 'Date' or using the 'Data Type' dropdown. Option D is wrong because the 'Detect Data Type' button in Power Query attempts to auto-detect types for all columns, but it may not reliably convert a text column to date if the data is ambiguous or if the detection logic fails; the recommended step is to explicitly set the data type.

Full explanation →
195
MCQeasy

You have a Power BI report that uses a date table connected to a fact table. You need to ensure that all dates in the fact table are covered by the date table. Which relationship property should you configure?

A.Make this relationship active
B.Cardinality
C.Assume referential integrity
D.Cross filter direction
AnswerC

Ensures all fact table dates exist in date table.

Why this answer

The 'Assume referential integrity' property, when enabled, tells Power BI that every value in the foreign key column of the fact table exists in the primary key column of the date table. This ensures that all dates in the fact table are covered by the date table, allowing Power BI to use more efficient storage and query execution (e.g., INNER JOIN semantics) rather than a full OUTER JOIN.

Exam trap

The trap here is that candidates often confuse 'Assume referential integrity' with 'Make this relationship active' or 'Cross filter direction', thinking that activating a relationship or changing filter direction will enforce date coverage, when in fact only referential integrity guarantees that all fact table dates are present in the date table.

How to eliminate wrong answers

Option A is wrong because 'Make this relationship active' controls which relationship is used by default for filtering, not whether all fact table dates exist in the date table. Option B is wrong because 'Cardinality' defines the type of relationship (e.g., many-to-one, one-to-one) and does not enforce that every foreign key value has a matching primary key. Option D is wrong because 'Cross filter direction' determines how filters propagate between tables (single or both directions) and has no effect on referential integrity or date coverage.

Full explanation →
196
MCQmedium

You are importing data from a SQL Server view into Power BI. The view contains calculated columns that are expensive to compute. You want to minimize the load on the source database during refresh. What should you do?

A.Import the raw data and perform transformations in Power Query.
B.Enable query folding to push transformations to SQL Server.
C.Use a native SQL query in Power Query to perform calculations.
D.Create a materialized view in SQL Server with the calculations.
AnswerA

By importing raw data, you offload transformation work to Power BI's mashup engine, which leverages Power Query's in-memory and streaming capabilities. This avoids pushing compute-intensive operations to SQL Server, preserving database resources for other workloads. Additionally, Power Query's step-based transformations are highly maintainable and can be refreshed on a schedule.

Why this answer

Importing raw data and performing transformations in Power Query offloads the computational burden from the SQL Server source to Power BI's mashup engine. This minimizes load on the source database during refresh, as expensive calculated columns are not executed on SQL Server. Power Query can apply transformations after the data is extracted, reducing the need for server-side processing.

Exam trap

The trap here is that candidates often assume pushing transformations to the source (via query folding or native SQL) is always more efficient, but the question specifically asks to minimize load on the source database, making offloading to Power Query the correct choice.

How to eliminate wrong answers

Option B is wrong because enabling query folding pushes transformations back to SQL Server, which would increase the load on the source database by having it perform the expensive calculations, contradicting the goal of minimizing load. Option C is wrong because using a native SQL query in Power Query to perform calculations still executes those calculations on SQL Server, placing the computational burden on the source database. Option D is wrong because creating a materialized view in SQL Server with the calculations would require the source database to compute and store the results, increasing load during refresh rather than reducing it.

Full explanation →
197
MCQmedium

You are deploying a Power BI solution to a customer. The customer requires that all report access be controlled via Azure Active Directory (Azure AD) groups. You have a single workspace with multiple reports. What is the best practice for managing permissions?

A.Create a Power BI group and add users to it.
B.Assign each user directly to the workspace role.
C.Share each report individually with users.
D.Add an Azure AD group to the workspace role.
AnswerD

Adding an Azure AD group to the workspace role is the correct, recommended approach for scalable access management in Power BI. When you assign the group to a role such as Viewer, Contributor, Member, or Admin, all current and future members of that group automatically receive the corresponding permissions on the workspace and its content. This centralizes identity governance in Azure AD: adding or removing a user from the group instantly reflects in Power BI, with no per-workspace or per-report edits needed. It aligns with enterprise security best practices and simplifies auditing and compliance.

Why this answer

Using an Azure AD group to manage workspace roles aligns with the customer's requirement for centralized access control via Azure AD. This approach simplifies permission management by allowing group membership changes in Azure AD to automatically propagate to Power BI workspace access, ensuring consistency and reducing administrative overhead.

Exam trap

The trap here is that candidates may confuse Power BI groups (which are legacy and not Azure AD integrated) with Azure AD groups, or assume that direct user assignment or individual report sharing is simpler, missing the requirement for centralized Azure AD-based control.

How to eliminate wrong answers

Option A is wrong because creating a Power BI group (a distribution group or security group within Power BI) does not leverage Azure AD groups as required; it introduces a separate group management layer that is not integrated with the customer's Azure AD-based identity governance. Option B is wrong because assigning each user directly to the workspace role violates the requirement to control access via Azure AD groups, leading to manual, error-prone user management and lack of centralized control. Option C is wrong because sharing each report individually bypasses workspace-level permissions, creating a fragmented permission model that is harder to audit and does not scale; it also does not use Azure AD groups as specified.

Full explanation →
198
Multi-Selecthard

A company has a Power BI semantic model that uses DirectQuery to a SQL Server database. The model includes a large fact table with 100 million rows. Users are experiencing slow report performance. Which TWO actions should the developer take to improve query performance?

Select 2 answers
A.Configure incremental refresh to limit data retrieved per query.
B.Create indexes on columns used in filters and relationships.
C.Remove unused columns from the fact table.
D.Hide columns that are not needed in reports.
E.Add calculated columns to precompute aggregations.
AnswersB, C

In DirectQuery mode, Power BI sends every visual query directly to the underlying SQL Server, so query performance depends on the source engine's ability to return results quickly. Creating indexes on columns used in filters and relationship joins lets SQL Server use efficient lookup and merge operations instead of full table scans, dramatically reducing query latency. Without appropriate indexes, even simple filter operations can force the database to scan millions of rows, which directly degrades the Power BI report experience.

Why this answer

In DirectQuery mode, incremental refresh is not supported (option A is incorrect). Creating indexes on columns used in filters and relationships (option B) speeds up query execution on SQL Server. Removing unused columns from the fact table (option C) reduces the amount of data transferred per query.

Hiding columns (option D) does not affect the data retrieved by queries. Adding calculated columns (option E) increases query overhead and degrades performance.

Exam trap

Candidates often think hiding unused columns improves performance, but in DirectQuery it does not reduce query size. They also mistakenly believe calculated columns are beneficial, whereas they add overhead.

Full explanation →
199
MCQmedium

A Power BI developer has a fact table that contains sales data at the transaction level. The table includes columns: TransactionID, ProductID, CustomerID, DateKey, Quantity, UnitPrice, Discount, and SalesAmount. The developer wants to create a measure for total sales after discount. Which approach is best for performance and accuracy?

A.Create a measure: SUM(Sales[SalesAmount]) - SUM(Sales[Discount])
B.Add a calculated column in Power Query: NetAmount = Quantity * UnitPrice - Discount, then create a measure: SUM(Sales[NetAmount])
C.Create a measure: SUMX(Sales, Sales[Quantity] * Sales[UnitPrice] - Sales[Discount])
D.Create a measure: SUM(Sales[Quantity] * Sales[UnitPrice]) - SUM(Sales[Discount])
AnswerB

Creating a calculated NetAmount column in Power Query (M) evaluates Quantity * UnitPrice - Discount once at refresh time, storing the result as a static column in the data model. The subsequent measure SUM(Sales[NetAmount]) simply aggregates those pre-computed values, avoiding row-by-row evaluation at report time and improving query performance for large fact tables. Because the calculation is pushed to the query engine instead of the DAX engine, it also keeps the code simpler and avoids iterator overhead during visual rendering.

Why this answer

It performs the net amount calculation at the row level in Power Query (M), which is computed during data refresh and stored in the table. This avoids runtime row-by-row iteration in DAX, making the measure SUM(Sales[NetAmount]) a simple, highly efficient aggregation. It ensures both performance and accuracy, as the discount is applied per transaction before aggregation.

Exam trap

The trap here is that candidates often assume a DAX measure using SUMX or a simple subtraction of aggregated columns is equivalent in performance, but the exam tests the understanding that pre-calculating row-level logic in Power Query (M) is the most performant approach for large fact tables, while also ensuring mathematical accuracy.

How to eliminate wrong answers

Option A is wrong because subtracting SUM(Discount) from SUM(SalesAmount) is mathematically incorrect when discounts are stored as absolute values per row; it would only work if Discount were a total discount amount per row, but here it is a per-row value that should be subtracted from the row’s net amount, not aggregated separately. Option C is wrong because SUMX iterates over the entire table row by row at query time, which is slower than a pre-calculated column, especially for large fact tables; it also forces the calculation engine to evaluate the expression for every row during measure execution. Option D is wrong because SUM(Sales[Quantity] * Sales[UnitPrice]) is invalid syntax in DAX—SUM expects a single column reference, not an expression; this would cause a syntax error or unexpected behavior, and even if corrected, it would still suffer from the same aggregation-order issue as Option A.

Full explanation →
200
Multi-Selecteasy

Which TWO of the following are valid DAX functions for time intelligence?

Select 2 answers
A.TOTALYTD
B.RANKX
C.SUM
D.CALCULATE
E.SAMEPERIODLASTYEAR
AnswersA, E

TOTALYTD is a DAX time intelligence function that evaluates an expression over the year-to-date period based on a given date column. It returns a scalar value representing the cumulative total from the start of the year to the latest date in the current filter context. This function is specifically designed for time-based calculations, making it a valid answer.

Why this answer

TOTALYTD is a valid DAX time intelligence function that calculates the year-to-date value of an expression, typically used with a date column to aggregate data from the start of the year to the current context. It requires a properly marked date table with continuous dates to function correctly.

Exam trap

Microsoft often tests the distinction between general DAX functions (like CALCULATE and SUM) and dedicated time intelligence functions, trapping candidates who assume any function that works with dates qualifies as time intelligence.

Full explanation →
201
MCQmedium

You need to ensure that a Power BI report published to the service can be embedded in a secure internal SharePoint Online page. Only authenticated users from your Microsoft Entra ID tenant should be able to view the report. What should you do?

A.Use the 'Embed in SharePoint Online' option in Power BI service.
B.Share the report directly with all users and provide a direct link.
C.Use the 'Publish to web (public)' option and embed the iframe in SharePoint.
D.Use the 'Embed' option in Power BI service to generate a secure embed code, then add the Power BI web part in SharePoint.
AnswerA

This option also works but is essentially the same as C; however C is more generic.

Why this answer

To embed a Power BI report securely in a SharePoint Online page, use the 'Embed in SharePoint Online' option in the Power BI service. This generates a secure embed link that respects Microsoft Entra ID authentication and permissions, ensuring only authorized users can view the report. After generating the link, add the Power BI web part to a SharePoint page and paste the link.

Option B is incorrect because sharing a direct link does not embed the report; it only provides a hyperlink. Option C is incorrect because 'Publish to web' makes the report publicly accessible without authentication. Option D is also a method that generates a secure embed code, but the 'Embed in SharePoint Online' option is the most straightforward and recommended approach for SharePoint embedding, making Option A the correct choice.

Full explanation →
202
MCQmedium

You are reviewing a Power BI dataset configuration in the service. The JSON shows a data source for an Azure SQL Database. Which statement about the configuration is correct?

A.The dataset uses key-based authentication and does not use single sign-on.
B.The dataset uses single sign-on with Azure AD.
C.The dataset is configured to use a cloud gateway for direct query.
D.The dataset uses cloud-only data sources and does not require a gateway.
AnswerD

The dataset points to Azure SQL Database, a fully managed cloud PaaS service, so Power BI can connect directly over the internet without any on-premises data gateway. Neither Import mode nor DirectQuery requires a gateway for cloud-only sources, because the data source is not behind a corporate firewall and is already reachable via standard cloud endpoints. This is why the configuration correctly shows no gateway association and the dataset functions normally.

Why this answer

Azure SQL Database is a cloud-native data source in Power BI, and cloud data sources do not require a gateway, whether using DirectQuery or Import. The configuration shown in the JSON is for an Azure SQL Database, which is inherently cloud-only, so no gateway is needed. Option A is incorrect because key-based authentication is not supported for Azure SQL Database; using 'Key' credential type would cause a connection failure.

Option B is incorrect because the JSON does not indicate single sign-on (no 'SingleSignOn' property set to true). Option C is incorrect because a cloud gateway is not required for Azure SQL Database; it is only needed for on-premises or virtual-network sources.

Exam trap

The trap here is that candidates often assume any Azure SQL Database connection automatically uses Azure AD SSO or requires a gateway, but the JSON's credential type explicitly reveals the authentication method, and cloud-native sources like Azure SQL Database do not inherently need a gateway.

How to eliminate wrong answers

Option B is wrong because single sign-on (SSO) with Azure AD would require the JSON to include a 'SingleSignOn' property set to true or a credential type of 'OAuth2' with an Azure AD token, which is not present in the given configuration. Option C is wrong because a cloud gateway (e.g., on-premises data gateway) is only required for on-premises or non-cloud data sources; an Azure SQL Database is a cloud-native data source and does not need a gateway for DirectQuery or import mode. Option D is wrong because while Azure SQL Database is a cloud-only data source, the statement is too broad and ignores that the dataset could still require a gateway if the Power BI service cannot directly connect due to network restrictions (e.g., VNet integration), but the JSON does not indicate any gateway configuration, so the correct inference is about authentication, not gateway necessity.

Full explanation →
203
MCQeasy

You are preparing data for a Power BI report. The source data contains a 'CustomerName' column with values like 'John, Doe'. You need to split this column into two columns: 'FirstName' and 'LastName'. The comma is used as a delimiter, but some names have a space after the comma. Which split method should you use?

A.Split by number of characters using a fixed width
B.Split by delimiter using semicolon
C.Split by delimiter using comma, then use 'Trim' to remove extra spaces
D.Split by delimiter using comma, using 'Left-most delimiter'
AnswerC

Splitting by comma as the delimiter separates the name into two columns, typically breaking at the comma between last and first name. After the split, the resulting columns often retain leading spaces (e.g., ' Doe' or 'Jane ') that come from the source data's formatting. Applying the Trim transformation removes these extraneous spaces, yielding clean standardized name values ready for further analysis or reporting. This combination of delimiter splitting and trimming is a best practice when handling delimited text with incidental whitespace.

Why this answer

Splitting by comma and then trimming extra spaces handles the inconsistent spacing after the comma (e.g., 'John, Doe' vs 'John, Doe'). Power Query's 'Split Column by Delimiter' using comma will separate the values, and the subsequent 'Trim' step removes leading/trailing spaces from the resulting columns, ensuring clean 'FirstName' and 'LastName' values without manual cleanup.

Exam trap

The trap here is that candidates may think 'Left-most delimiter' or a simple split is sufficient, overlooking the need to trim extra spaces, which Power Query does not do automatically when splitting by delimiter.

How to eliminate wrong answers

Option A is wrong because splitting by number of characters using fixed width assumes a consistent character count for first and last names, which is not the case with variable-length names like 'John, Doe' vs 'Alexander, Hamilton'. Option B is wrong because splitting by semicolon ignores the actual delimiter in the data (comma), resulting in no split and leaving the column unchanged. Option D is wrong because using 'Left-most delimiter' would only split on the first comma if multiple commas existed, but the data has only one comma per entry; more critically, it does not address the trailing space after the comma, leaving ' Doe' with a leading space in the last name column.

Full explanation →
204
MCQmedium

You are preparing data from multiple sources for a Power BI report. You need to create a star schema with a single fact table and several dimension tables. Which of the following is a best practice when designing the data model?

A.Include calculated measures in dimension tables.
B.Normalize dimension tables into multiple related tables.
C.Ensure each dimension table has a unique key and contains descriptive attributes.
D.Use natural keys from the source system as the primary key in dimension tables.
AnswerC

This is a fundamental best practice for star schema design.

Why this answer

In a star schema, dimension tables should have a unique key (surrogate or natural) and contain descriptive attributes to enable filtering and grouping in Power BI. This ensures efficient relationships with the fact table and supports intuitive report interactions. Option C directly aligns with this best practice.

Exam trap

Microsoft often tests the misconception that normalizing dimension tables (snowflake schema) is a best practice for performance, but in Power BI, denormalized star schemas are preferred to reduce joins and leverage VertiPaq compression.

How to eliminate wrong answers

Option A is wrong because calculated measures should be defined in the fact table or as explicit measures in the data model, not in dimension tables, as dimension tables are meant for attributes and keys, not aggregations. Option B is wrong because normalizing dimension tables into multiple related tables creates a snowflake schema, which can degrade query performance in Power BI due to additional joins and is generally avoided in star schema design. Option D is wrong because natural keys from the source system can be non-unique, change over time, or be composite, making them unreliable as primary keys; surrogate keys are preferred for stability and performance in dimension tables.

Full explanation →
205
MCQeasy

A company has a dataset with a table 'Orders' containing columns: OrderDate, CustomerID, Amount. They want to create a visual that shows the total amount per month. Which of the following is the best approach?

A.Create a pie chart with OrderDate as the legend.
B.Create a line chart with OrderDate on the axis and use the date hierarchy to drill down to month.
C.Create a table visual with OrderDate and Amount, then group by month in the visual.
D.Create a bar chart with a calculated column 'Month' extracted from OrderDate and use that as the axis.
AnswerB

Using a line chart with OrderDate on the axis and the built-in date hierarchy enables drill-down from year to quarter to month without extra measures or columns. This hierarchy is auto-generated by Power BI for date columns, supports correct chronological sorting, and provides a natural, interactive way for users to explore trends at multiple granularities. The line chart's continuous axis is ideal for showing changes in Amount over time.

Why this answer

It leverages Power BI's built-in date hierarchy, which automatically groups OrderDate by year, quarter, month, and day. By placing OrderDate on the axis of a line chart and drilling down to the month level, you get an accurate monthly aggregation of Amount without needing any manual data transformation or calculated columns. This approach is efficient, maintains the underlying data model's integrity, and allows for easy drill-up/drill-down navigation.

Exam trap

The trap here is that candidates often think extracting a month column manually (Option D) is the most straightforward approach, but the exam tests whether you understand that Power BI's built-in date hierarchy is the optimal and intended method for time-based aggregations, avoiding unnecessary calculated columns.

How to eliminate wrong answers

Option A is wrong because a pie chart with OrderDate as the legend would treat each unique date as a separate slice, not aggregate by month, resulting in a cluttered and meaningless visual. Option C is wrong because table visuals in Power BI do not support grouping by month directly within the visual; you would need to create a calculated column or use a date hierarchy to achieve monthly aggregation. Option D is wrong because while a calculated column 'Month' extracted from OrderDate would work, it is not the 'best' approach—it adds unnecessary complexity, breaks the date hierarchy, and prevents easy drill-down to lower time granularities like day or quarter.

Full explanation →
206
MCQhard

You are building a Power BI model that includes a table 'Orders' with columns: OrderID, CustomerID, OrderDate, and TotalAmount. You also have a table 'Customers' with columns: CustomerID, CustomerName, and Segment. You need to create a relationship between Orders and Customers on CustomerID. Which relationship configuration should you choose to ensure that filtering Customers by Segment correctly filters Orders?

A.One-to-many relationship from Customers to Orders
B.Many-to-one relationship from Orders to Customers
C.Many-to-many relationship with a bridge table
D.One-to-one relationship
AnswerA

This is the canonical star-schema relationship. A single customer can appear in many orders, so Customers is the 'one' side and Orders is the 'many' side. By placing the relationship from Customers to Orders, customer attributes (region, segment, etc.) automatically filter and slice all related order rows, enabling correct aggregations in measures. This relationship uses the dimension table as the lookup table and the fact table as the data table, which is the preferred pattern for performance and intuitive filtering.

Why this answer

A one-to-many relationship from Customers (one side) to Orders (many side) with single-direction cross-filtering ensures that filtering Customers by Segment correctly filters Orders. Option B (many-to-one) would reverse the cardinality and, by default, would not allow filtering from Customers to Orders. Option C is unnecessary and can cause ambiguity.

Option D is inappropriate as one customer can have many orders.

Full explanation →
207
Multi-Selectmedium

Which THREE of the following are considerations when implementing row-level security (RLS) in Power BI? (Select three.)

Select 3 answers
A.RLS does not apply to data accessed via the XMLA endpoint unless using dynamic security.
B.RLS filters are applied at query time.
C.RLS can be defined using DAX filter expressions.
D.RLS is enforced only for users with the Viewer role.
E.RLS can be bypassed by using the 'Show all' option in visuals.
AnswersA, B, C

Static RLS is not enforced via XMLA; dynamic security is needed.

Why this answer

Options A, B, and C are correct. Row-level security (RLS) in Power BI ensures that users only see data they are authorized to view. Option A is correct because RLS does not apply to data accessed via the XMLA endpoint unless dynamic security is configured; static RLS filters are not applied through the endpoint.

Option B is correct because RLS filters are applied at query time, restricting data in all visuals. Option C is correct because RLS can be defined using DAX filter expressions in the Manage Roles feature. Option D is incorrect because RLS applies to all users regardless of their role (Viewer, Editor, etc.); it is not limited to the Viewer role.

Option E is incorrect because the "Show all" option in visuals does not bypass RLS; users cannot see data they are not permitted to see.

Full explanation →
208
Multi-Selectmedium

You are connecting to a data source that contains Personally Identifiable Information (PII). You need to ensure that only authorized users can view the data in Power BI reports. Which TWO actions should you take?

Select 2 answers
A.Enable encryption at rest for the dataset.
B.Use Power Query to mask PII columns by replacing values with '***'.
C.Define row-level security (RLS) roles in Power BI Desktop.
D.Apply sensitivity labels to the dataset.
E.Implement object-level security (OLS) to hide sensitive tables from certain users.
AnswersC, E

RLS filters data for users based on their role, restricting access to rows they are authorized to see.

Why this answer

Row-Level Security (RLS) allows you to restrict data access at the row level based on user roles defined in Power BI Desktop. By creating roles and using DAX filters, you can ensure that only authorized users see specific rows of PII data when the report is published to the Power BI service and users are mapped to roles.

Exam trap

The trap here is that candidates often confuse data masking (Option B) with dynamic security, not realizing that Power Query masking is irreversible and applies to all users, whereas RLS and OLS provide granular, user-specific access control without altering the underlying data.

Full explanation →
209
MCQhard

You are troubleshooting a Power Query transformation that groups sales data by ProductID. The query runs slowly and you suspect the filter is being applied after loading all rows. What change would improve performance by pushing the filter to the source?

A.Disable the 'Enable load' option for the SalesTable
B.Use CALCULATE in DAX to filter
C.Add a 'Table.Buffer' step after the filter
D.Replace the first three lines with a native SQL query that includes the WHERE clause
AnswerD

Native SQL query allows the database to apply the filter before returning data.

Why this answer

Pushing filter logic to the source database via a native SQL query with a WHERE clause reduces the amount of data loaded into Power Query. This leverages query folding, which allows the source (e.g., SQL Server) to perform the filtering before data is transferred, significantly improving performance for large datasets.

Exam trap

The trap here is that candidates often confuse in-memory buffering (Table.Buffer) or DAX filter functions with source-level query pushdown, failing to recognize that only native SQL or folding-compatible M steps can reduce data transfer from the source.

How to eliminate wrong answers

Option A is wrong because disabling 'Enable load' prevents the table from being loaded into the data model entirely, which does not address the filter pushdown issue and would remove the data needed for analysis. Option B is wrong because CALCULATE is a DAX function used in measures for filter context within the data model, not for optimizing Power Query transformation steps or pushing filters to the source. Option C is wrong because Table.Buffer caches the data in memory after the filter step, which can improve subsequent query performance but does not push the filter to the source; it still requires loading all rows before the buffer.

Full explanation →
210
MCQeasy

You have a Power BI model with a table named Orders that contains columns OrderDate, ShipDate, and CustomerID. You need to create a calculated column that computes the number of days between OrderDate and ShipDate. Which DAX expression should you use?

A.DATEDIFF(Orders[OrderDate], Orders[ShipDate], DAY)
B.DATEADD(Orders[OrderDate], 1, DAY)
C.DAY(Orders[ShipDate] - Orders[OrderDate])
D.NETWORKDAYS(Orders[OrderDate], Orders[ShipDate])
AnswerA

DATEDIFF(Orders[OrderDate], Orders[ShipDate], DAY) is correct because the DATEDIFF function in DAX returns the number of interval boundaries crossed between a start date and an end date, with the third argument specifying the interval unit. Here, DAY asks for whole calendar days, so the result is an integer representing the total days from OrderDate to ShipDate. This is the intended calculation for order-to-ship time.

Why this answer

The DATEDIFF function in DAX calculates the interval between two dates in the specified unit (DAY). This directly computes the number of days between OrderDate and ShipDate, which is the required result for the calculated column.

Exam trap

The trap here is that candidates might confuse DATEDIFF with DATEADD (which shifts dates) or incorrectly use DAY() on a date difference, thinking it extracts the number of days, when DAY() actually returns the day of the month (1–31).

How to eliminate wrong answers

Option B is wrong because DATEADD shifts a date by a specified number of intervals (e.g., adds 1 day to OrderDate), not the difference between two dates. Option C is wrong because DAY extracts the day-of-month component from a date, not the interval between dates; subtracting two dates in DAX returns a decimal representing days, but wrapping it in DAY returns an incorrect integer (the day number of the difference). Option D is wrong because NETWORKDAYS calculates the number of whole working days between two dates, excluding weekends and optionally holidays, not the total calendar days.

Full explanation →
211
MCQeasy

You are connecting to a SharePoint folder containing 100 Excel files. Each file has a similar structure but different column names. What is the best practice to combine these files into a single table while preserving the data?

A.Use Power Query's 'Combine Files' feature, selecting a sample file and promoting headers, then transforming column names to a standard set.
B.Load each file as a separate table and create relationships in the model.
C.Use Power Query's 'Merge Queries' to join all files into one table.
D.Use 'Append Queries' to stack all files, then rename columns manually.
AnswerA

This automates combining files with different structures.

Why this answer

Power Query's 'Combine Files' feature is designed specifically for this scenario: it uses a sample file to infer the transformation logic (e.g., promoting headers), then applies that logic to all files in the folder. By transforming column names to a standard set within the sample file step, you ensure consistent column names across all files, preserving data integrity while combining them into a single table.

Exam trap

The trap here is that candidates often confuse 'Combine Files' (which unions multiple files with a consistent transformation) with 'Merge Queries' (which joins tables horizontally) or 'Append Queries' (which stacks tables but lacks automated column standardization).

How to eliminate wrong answers

Option B is wrong because loading each file as a separate table and creating relationships would result in a fragmented model with many tables, making analysis cumbersome and violating the goal of combining into a single table. Option C is wrong because 'Merge Queries' performs a join (like SQL JOIN) on matching columns between two tables, not a union of multiple files; it would not stack rows from all files. Option D is wrong because 'Append Queries' can stack tables, but manually renaming columns for 100 files is impractical and error-prone; the 'Combine Files' feature automates this with a sample file transformation.

Full explanation →
212
MCQeasy

You need to create a measure that calculates the year-over-year growth percentage for sales. Which DAX function should you use?

A.DATEADD
B.PARALLELPERIOD
C.SAMEPERIODLASTYEAR
D.PREVIOUSYEAR
AnswerC

SAMEPERIODLASTYEAR is a time-intelligence function that returns a table of dates shifted exactly one year back from the current filter context, preserving the same day, month, and quarter boundaries. When used inside CALCULATE, it recalculates a measure over that prior-year date range, making it the precise foundation for a year-over-year growth calculation. Because it respects the current filter context and automatically handles leap years by shifting to the nearest valid date, it is the standard choice for comparing any arbitrary period—month, quarter, or cumulative range—to the same period in the previous year.

Why this answer

The SAMEPERIODLASTYEAR function is the correct choice for calculating year-over-year growth because it shifts the current filter context back by one year, returning a set of dates exactly one year prior. This allows you to compute the prior year's sales and then derive the growth percentage using a formula like (Current Sales - Prior Year Sales) / Prior Year Sales.

Exam trap

The trap here is that candidates often confuse SAMEPERIODLASTYEAR with PREVIOUSYEAR, mistakenly thinking PREVIOUSYEAR can be used for any period comparison, but PREVIOUSYEAR only works for full calendar year comparisons, not for partial periods like months or quarters.

How to eliminate wrong answers

Option A is wrong because DATEADD shifts dates by a specified interval (e.g., -1 year) but returns a contiguous range of dates, which can cause unexpected results when the current period is not a full month or quarter. Option B is wrong because PARALLELPERIOD returns a parallel period of the same length in the previous period (e.g., previous month, quarter, or year) but shifts the entire period, which may not align with the exact same dates as the current period. Option D is wrong because PREVIOUSYEAR returns all dates in the previous calendar year, which is not suitable for year-over-year comparisons when the current period is not the entire year (e.g., comparing a single month or quarter).

Full explanation →
213
MCQmedium

You manage a Power BI workspace that contains a dataset refreshed daily from an on-premises SQL Server. Users report that the report shows data from two days ago. You verify that the scheduled refresh ran successfully this morning. What is the most likely cause?

A.The on-premises data source is misconfigured, causing the refresh to load data from an outdated source.
B.The refresh took longer than expected and timed out.
C.The scheduled refresh is not set to refresh the dataset.
D.The on-premises data gateway is offline.
AnswerA

Correct. A misconfigured on-premises data source in the Power BI service — such as a gateway data source entry pointing to the wrong server, database, or folder, or using credentials for a different environment — can cause the refresh engine to successfully connect to and load data from an outdated or unintended location. Because the refresh completes without error, the service reports success even though the dataset is populated from the wrong source. This perfectly matches the scenario: a successful refresh that yields stale data.

Why this answer

The most likely cause is that the on-premises data source is misconfigured (e.g., pointing to a stale backup or snapshot). This results in the scheduled refresh loading data from an outdated source, making it appear successful yet yielding old data. The gateway does not cache data; the issue lies in the data source reference.

Exam trap

Candidates may assume a successful refresh guarantees current data, but misconfiguration of the data source (e.g., wrong connection string pointing to a backup) can cause the refresh to load outdated data without failure.

How to eliminate wrong answers

Option B is wrong because if the refresh took longer than expected and timed out, the refresh would not have completed successfully, but the question states the scheduled refresh ran successfully. Option C is wrong because the scheduled refresh is explicitly set to refresh the dataset daily, and the question confirms it ran successfully this morning. Option D is wrong because if the on-premises data gateway were offline, the scheduled refresh would fail entirely, not run successfully and still show stale data.

Full explanation →
214
MCQhard

A company wants to create a Power BI report that shows sales performance by region. The data contains a table 'Sales' with columns: Date, Amount, RegionID, and ProductID. They also have a 'Regions' table with RegionID and RegionName. They want to display a matrix visual with RegionName on rows and Year on columns, with the sum of Amount as values. However, the report displays only 'RegionID' instead of 'RegionName'. What is the most likely cause?

A.The relationship is configured as many-to-many.
B.The relationship direction is set to Both.
C.The RegionID column in the Sales table is hidden.
D.There is no active relationship between the Sales and Regions tables.
AnswerD

In Power BI, an active relationship is what enables automatic filter propagation between tables; without one, Power BI cannot traverse from the Sales table to the Regions table to retrieve RegionName. When a foreign key column like RegionID is placed in a visual and no active relationship links it to the Regions table, Power BI simply shows the raw ID value because it has no way to perform the lookup. The correct fix is to create or activate a relationship between Sales[RegionID] and Regions[RegionID] (typically with a single-direction filter), so that the relationship becomes active and the report can display the corresponding RegionName.

Why this answer

If there is no active relationship between the Sales and Regions tables, Power BI cannot use the RegionName from the Regions table to filter or group the Sales data. Instead, it defaults to displaying the RegionID from the Sales table, which is the only related field available in the visual. An active relationship must exist between the two tables on the RegionID columns for RegionName to appear in the matrix.

Exam trap

The trap here is that candidates often assume the RegionName column is missing due to a hidden column or relationship cardinality, but the core issue is the absence of an active relationship, which Power BI requires to combine data from different tables in a visual.

How to eliminate wrong answers

Option A is wrong because a many-to-many relationship would still allow RegionName to appear, though it might cause ambiguous aggregation; it does not cause the visual to show RegionID instead of RegionName. Option B is wrong because setting the relationship direction to Both (bidirectional cross-filtering) does not prevent RegionName from being used; it actually enables additional filtering but does not hide the RegionName column. Option C is wrong because hiding the RegionID column in the Sales table does not affect the display of RegionName from the Regions table; hiding a column only prevents it from appearing in the field list, not from being used in relationships or visuals.

Full explanation →
215
Multi-Selectmedium

You are designing a Power BI data model for a manufacturing company. Which TWO practices help optimize performance when using DirectQuery?

Select 2 answers
A.Disable relationships between tables to reduce query complexity
B.Create calculated columns in Power Query instead of in DAX
C.Reduce the number of columns in the fact query to only those needed
D.Enable bidirectional cross-filtering for all relationships
E.Use a single date dimension table for all date columns
AnswersC, E

Minimizes data transfer from the source.

Why this answer

Reducing the number of columns in the fact query minimizes data transfer and improves DirectQuery performance. Option E is correct: Using a single date dimension table for all date columns simplifies relationships and reduces the number of joins required, enhancing query efficiency. Option A is wrong because disabling relationships would break the model integrity and force manual filtering, degrading performance.

Option B is wrong because calculated columns in DirectQuery are pushed to the source, but they can still increase query complexity and resource usage; it is better to use native columns or measures. Option D is wrong because bidirectional cross-filtering can lead to ambiguous relationships and additional query overhead, harming performance.

Full explanation →
216
MCQmedium

Refer to the exhibit. You are reviewing a Power BI data source credential configuration. The Azure Blob Storage data source uses 'Anonymous' credentials. However, the refresh fails with an error indicating that the blob container is private and requires authentication. Which change should you make?

A.Change credential type to 'Service Principal' and provide the app ID and secret.
B.Change credential type to 'Account Key' and provide the storage account key.
C.Change credential type to 'Basic' and provide the storage account name and key.
D.Change credential type to 'Windows' for the Azure Blob datasource.
AnswerB

When an Azure Blob Storage container is private, Power BI's anonymous (public) access is rejected, so you must authenticate with a credential the storage service actually recognizes. The Azure Blob connector in Power BI supports Account Key authentication as the straightforward shared-key method: supplying the storage account key authorizes your request as the account owner. This grants full access to the container and resolves the 'container is private' error without needing to configure Azure RBAC roles. Use the key from the storage account's Access keys blade in the Azure portal.

Why this answer

Azure Blob Storage containers that are private require authentication. The 'Account Key' credential type in Power BI uses the storage account key to authenticate via the Azure Storage REST API, which is the correct method for accessing private blob containers. Anonymous access only works when the container is configured for public access.

Exam trap

The trap here is that candidates may confuse 'Anonymous' with a valid credential type for private containers, or incorrectly assume that 'Basic' authentication is equivalent to providing a username and password for Azure Storage.

How to eliminate wrong answers

Option A is wrong because a Service Principal requires Azure AD registration and RBAC permissions, which is unnecessary and overly complex for accessing a single storage account; the account key is the simpler and correct method. Option C is wrong because 'Basic' authentication is not a valid credential type for Azure Blob Storage in Power BI; it is used for HTTP/HTTPS endpoints that support basic auth, not Azure Storage. Option D is wrong because 'Windows' authentication is for on-premises data sources like SQL Server, not for cloud-based Azure Blob Storage.

Full explanation →
217
MCQhard

You are a data analyst for a global retail company. The company uses Power BI Premium capacity. You are building a dataset that combines sales data from three sources: 1. An Azure SQL Database that stores transactional sales data (10 million rows per day, retained for 5 years). 2. A SharePoint Online folder containing monthly Excel reports from regional offices (each report has a different structure). 3. A Dataverse table that contains customer feedback scores. Requirements: - The dataset must support near real-time reporting for the current month's sales (maximum 15-minute latency). - Historical sales data (older than current month) can be refreshed daily. - Customer feedback scores should be updated every hour. - The Excel reports from SharePoint must be combined into a single table with consistent columns. - The final dataset should be optimized for fast query performance. You need to design the data preparation strategy. What should you do?

A.Use DirectQuery for all data sources and create views in Azure SQL to transform the SharePoint and Dataverse data. Use Power Query to combine SharePoint files in a view.
B.Import all data into Power BI using Import mode. Schedule refreshes every 15 minutes for the current month and daily for historical data.
C.Use a composite model: DirectQuery for the current month's sales data from Azure SQL, and Import mode for historical sales (with incremental refresh) and for customer feedback (with hourly refresh). Combine SharePoint files using Power Query and load them into the model using Import mode. Set up a DirectQuery connection for near real-time.
D.Use Azure Data Factory to copy all data to Azure SQL Database, then connect Power BI using DirectQuery.
AnswerC

This is correct because it uses a composite model to combine DirectQuery and Import modes: DirectQuery on Azure SQL for the current month's sales queries the source directly, providing near real-time visibility without data duplication or refresh latency. Historical sales are imported with incremental refresh, which partitions the data and only loads new or changed partitions, dramatically reducing refresh time and resource use. Customer feedback is imported on an hourly schedule since it does not require sub-hour latency, and SharePoint files are combined via Power Query and imported, as they lack DirectQuery support. This design maximizes performance while meeting all stated latency and freshness requirements, and it is a recognized best practice for hybrid data scenarios in Power BI.

Why this answer

It uses a composite model to meet all requirements: DirectQuery for near real-time current-month sales (≤15-minute latency), Import mode with incremental refresh for historical sales (daily refresh), Import mode for customer feedback (hourly refresh), and Power Query to combine SharePoint Excel files into a consistent table. This approach balances real-time needs with query performance and refresh flexibility, leveraging Power BI Premium's composite model capabilities.

Exam trap

The trap here is that candidates may choose Import mode for everything (Option B) without realizing the 48-refresh-per-day limit on Power BI Premium, which prevents 15-minute refreshes, or they may overlook composite models as the only way to combine real-time and historical data efficiently.

How to eliminate wrong answers

Option A is wrong because DirectQuery for all sources would cause poor query performance due to the large volume of historical data (10M rows/day for 5 years) and cannot handle combining SharePoint files with different structures in a view without transformation. Option B is wrong because Import mode with 15-minute refreshes for current-month sales would exceed the 48 daily refresh limit on Power BI Premium (48 refreshes/day = 30-minute minimum interval) and cannot achieve near real-time latency. Option D is wrong because copying all data to Azure SQL Database via Azure Data Factory introduces additional latency and complexity, and using DirectQuery for the entire dataset would still suffer from performance issues with large historical data.

Full explanation →
Page 2

Page 3 of 3

All pages

123

Practice PL-300 by domain

Target a specific domain to shore up weak areas.

Prepare the dataDeploy and maintain assetsModel the dataVisualize and analyze the dataManage and secure Power BI
See all domains with question counts →