70+ Power BI Interview Questions and Answers [ 2026 ]

Power BI interview questions assess how well candidates can turn business data into reliable reports, meaningful metrics and decisions. A data analyst may be asked to explain data cleaning and visualisation, while a Power BI developer may face detailed questions about DAX, semantic models, relationships, performance and security.

For freshers, preparation starts with Power BI Desktop, Power Query, common visuals and basic data modelling. Experienced candidates are more likely to discuss query performance, enterprise reporting, access controls and problems encountered in actual projects. Interview requirements vary by employer and position, so no single question list represents every hiring process.

This collection of 75 Power BI interview questions and answers for 2026 progresses from fundamental concepts to advanced modelling and workplace scenarios. The answers explain technical distinctions, provide DAX and Power Query examples where useful, and identify mistakes that can affect report accuracy.

Basic Power BI Interview Questions and Answers for Freshers

These foundational questions cover the main components of Microsoft Power BI, how data reaches a report, and the differences between data preparation, modelling and visualisation. They are particularly relevant to entry-level reporting and business intelligence positions.

1. What Is Power BI?

Answer: Power BI is Microsoft’s business intelligence and data visualisation platform. It helps users connect to data sources, transform data, build semantic models, create interactive reports and share insights through supported Microsoft services.

A typical reporting workflow brings together data from operational systems, spreadsheets or databases, prepares it for analysis and presents relevant business metrics through charts, tables and other visuals.

Example: A retail analyst can combine sales transactions and product information to create a report showing monthly revenue, product performance and regional sales trends.

Power BI is not simply a chart-building application. Its reporting capabilities depend on data preparation, relationships, business calculations, permissions and refresh or query behaviour.

2. What Are the Main Components of Power BI?

Answer: The Power BI ecosystem includes tools and services for developing reports, managing data, publishing content and enabling access to information.

Practical distinction: An analyst may create a report in Power BI Desktop and publish it to the Power BI service, where authorised users can access the report. The semantic model supplies the data and calculations used by the visuals.

Microsoft Fabric also provides integrated data and analytics capabilities that can work with Power BI. The features available to an organisation depend on its configuration, licensing and capacity.

3. What Is the Difference Between Power BI Desktop and Power BI Service?

Answer: Power BI Desktop is principally used to develop reports and semantic models on a Windows computer. The Power BI service is the cloud environment where supported reports, semantic models and dashboards can be managed, published and accessed.

Example: A developer creates a sales report in Power BI Desktop, publishes it to a workspace and configures the appropriate access and refresh settings through the Power BI service.

Interview distinction: The service is not limited to viewing reports. It also supports various management, authoring and modelling features. The exact capabilities depend on the content type and environment.

4. What Is Power Query in Power BI?

Answer: Power Query is a data connectivity and transformation technology used to prepare information before it is loaded into or otherwise used by a reporting solution. In Power BI Desktop, it is commonly accessed through the Transform Data interface.

Power Query uses the M formula language to describe transformations. Common operations include removing columns, changing data types, filtering rows, merging queries and standardising inconsistent values.

Example: A sales file contains a date column stored as text, inconsistent region names and rows with missing transaction identifiers. Power Query can help convert the date type, standardise the names and apply appropriate validation or filtering rules.

Illustrative M expression:

Table.SelectRows(
    Source,
    each [SalesAmount] > 0
)

This expression retains rows where SalesAmount is greater than zero, assuming the column exists and its data type supports the comparison.

Interview consideration: Data preparation rules should reflect business requirements. Removing all zero-value sales may be incorrect if those transactions represent legitimate activity.

5. What Is DAX in Power BI?

Answer: Data Analysis Expressions (DAX) is a formula language used in Power BI semantic models and related Microsoft analytical technologies. It supports measures, calculated columns, calculated tables and other model calculations.

DAX calculations operate within a data model and are affected by concepts such as row context, filter context and relationships.

Example measure:

Total Sales =
SUM(Sales[SalesAmount])

This measure returns the sum of SalesAmount for the rows included in the current filter context. A region slicer or a product category shown in a matrix may change the result.

Important distinction: DAX is not the same as Power Query M. Power Query primarily defines data preparation transformations, while DAX expresses calculations within the analytical model.

6. What Is the Difference Between Power Query and DAX?

Answer: Power Query and DAX serve different purposes in a Power BI solution. Power Query is commonly used to acquire and transform data, while DAX defines analytical calculations that operate within a semantic model.

Practical example: Use Power Query to standardise the format of a product category field. Use a DAX measure to calculate sales for whichever product category a report user selects.

Some transformations can be implemented in either technology, but the choice can affect model size, refresh processing, calculation behaviour and maintainability.

7. What Is a Semantic Model in Power BI?

Answer: A Power BI semantic model is the analytical data model used by reports and other supported experiences. It can define tables, relationships, measures, hierarchies, formatting and applicable security rules.

Microsoft previously used the term dataset for what is now generally called a semantic model. The newer terminology emphasises that the model contains business definitions and analytical logic, rather than simply a collection of imported records.

Example: A retail semantic model may contain Sales, Products, Customers and Date tables, relationships connecting them and measures such as Total Sales, Gross Margin and Order Count.

Several reports can connect to the same shared semantic model, helping teams use consistent business calculations instead of independently recreating definitions.

Interview tip: Be able to describe the difference between a raw data source, a semantic model and a report. A report can present information from a model, while the model contains the analytical definitions used to calculate that information.

8. Which Data Sources Can Power BI Connect To?

Answer: Power BI supports connectors for numerous file formats, databases, cloud services and other data sources. Availability and connection behaviour depend on the connector and the Power BI environment.

Example: A finance team may combine a SQL Server transaction table with a maintained Excel target file. The model can then compare actual revenue against approved targets, provided the data is correctly aligned by date and organisational dimensions.

Not every connector supports every connectivity mode. Some connections require a gateway, while others use supported cloud authentication mechanisms.

Interview tip: When describing a source connection, explain the authentication method, refresh requirements, data volume and whether Import or another supported mode is appropriate.

9. What Is Import Mode in Power BI?

Answer: Import mode loads a copy of selected source data into the Power BI semantic model. Queries against imported tables generally use the data stored in that model rather than fetching every result directly from the original source.

This can provide efficient interactive analysis when the model is appropriately designed and within applicable resource limits.

Example: A reporting team imports historical sales records from a database and refreshes the model according to its reporting requirements. Users interact with the imported data between refreshes.

Important limitation: Changes in the underlying source are not automatically reflected in an imported model. Data must be refreshed through a supported process to incorporate source updates.

Import mode may also increase storage and processing requirements, particularly for large tables containing unnecessary columns or high-cardinality values.

10. What Is DirectQuery in Power BI?

Answer: DirectQuery is a connectivity mode in which Power BI sends queries to a supported underlying data source as users interact with reports, rather than relying on a fully imported copy of the source table.

DirectQuery can be useful when source data changes frequently, importing the necessary data is impractical or requirements favour leaving detailed records in the underlying system.

Example: An operational report may query a supported SQL database to retrieve sales transactions based on the selected date range and region.

Performance consideration: Report responsiveness depends partly on the source database, generated queries, network conditions, concurrency and model design. DirectQuery can have feature limitations compared with Import mode.

DirectQuery should not automatically be described as real-time reporting. Source changes, caching, query timing and report refresh behaviour determine when updated information becomes visible.

11. What Is the Difference Between Import, DirectQuery and Direct Lake?

Answer: Import, DirectQuery and Direct Lake are different approaches to accessing data in supported Power BI semantic models. They differ in how data is stored, queried and updated.

Scenario: A small sales reporting model with scheduled updates may be well suited to Import mode. A large operational database with frequently changing information may justify evaluating DirectQuery. A supported Microsoft Fabric solution using OneLake data may make Direct Lake relevant.

No single mode is optimal for every workload. Data size, latency requirements, cost, feature support, resource constraints and operational complexity should inform the decision.

Interview tip: Mention that composite models can combine supported storage modes. However, the permitted combinations and modelling capabilities depend on the product environment.

12. What Is an On-Premises Data Gateway in Power BI?

Answer: An on-premises data gateway enables supported Microsoft cloud services to communicate securely with data sources located in private or on-premises environments.

It is useful when a Power BI semantic model needs to access a database or other supported source that is not directly reachable through the cloud connection configuration.

Example: A company stores sales records in a SQL Server database within its internal network. A properly configured gateway can enable supported refresh or query operations from Power BI services without making the database publicly accessible.

Gateway operation requires appropriate network connectivity, source credentials, permissions and ongoing administration. Availability requirements may also justify configuring more than one gateway instance in a supported cluster.

Important distinction: Not every cloud source requires an on-premises gateway. Whether a gateway is needed depends on the source type, connection method and network architecture.

Interview tip: Be prepared to explain how a gateway differs from a data source and a semantic model. The gateway facilitates supported connectivity; it does not itself define the report’s business calculations.

Technical reference: Microsoft provides current Power BI documentation through Microsoft Learn, including guidance on data connectivity, modelling, reports and service administration.

Power BI Data Modelling and DAX Interview Questions

Power BI data modelling and DAX questions test whether candidates can build reports that produce accurate results under different filters, selections and business conditions. These skills matter because a visually appealing report can still be misleading if relationships, calculation logic or data granularity are incorrect.

The following questions focus on the concepts used to create reliable semantic models, write reusable calculations and prepare data for analysis. The examples assume appropriately configured tables and columns; actual implementations depend on the business requirements and underlying data.

13. What Is a Star Schema in Power BI?

Answer: A star schema is a dimensional modelling approach in which a central fact table connects to related dimension tables. It helps organise analytical data into business events or measurements and the descriptive attributes used to analyse them.

Fact tables typically contain measurable business activity, such as sales transactions, quantities and monetary amounts. Dimension tables contain descriptive attributes, such as product names, customer categories, dates and regions.

Example: A sales report needs revenue by product category and month. The Sales fact table stores transaction amounts, while Product and Date dimensions supply the categories and reporting periods.

This structure supports reusable measures and usually simplifies relationship management. It can also improve query efficiency when appropriately designed, although performance still depends on model size, relationships, storage mode and report queries.

Interview consideration: A star schema is not automatically suitable for every source or analytical requirement. Candidates should be able to explain how they identify facts, dimensions and the required level of detail.

14. What Is Granularity in a Power BI Data Model?

Answer: Granularity, also called grain, describes what one row represents in a table. Defining the grain of a fact table is a fundamental modelling decision because it determines which measurements can be aggregated and how they relate to dimensions.

For example, a sales table might store one row per individual order line, one row per completed order or one row per product per month. These are different grains and support different analytical capabilities.

Practical problem: Suppose a model joins monthly sales targets to individual sales transactions using only the month. A target value can then repeat across multiple transaction rows, producing inflated totals if the relationship and calculations are not designed correctly.

A safer approach is to identify the grain of both datasets, use suitable shared dimensions and define measures that aggregate values at the intended level.

Interview tip: Before creating relationships or DAX measures, explain exactly what one row means in each relevant table. Many apparently complicated reporting errors originate from mismatched granularity.

15. What Are Relationships in Power BI, and What Are Their Types?

Answer: Relationships connect tables within a Power BI semantic model so that filters and calculations can operate across related data. A relationship identifies the participating columns, cardinality and applicable filter direction.

Power BI supports relationship cardinalities such as one-to-many, many-to-one, one-to-one and many-to-many, subject to model and storage-mode requirements.

Example: A Product dimension has one row per product identifier, while a Sales fact table contains multiple transactions for each product. A one-to-many relationship allows the Product dimension to filter the relevant sales records.

Relationships can also be active or inactive. Only the appropriate active relationship normally propagates filters automatically along that path, while DAX functions such as USERELATIONSHIP() can enable an existing relationship for the duration of a particular calculation.

Interview tip: When discussing many-to-many relationships, explain why the underlying business relationship and table grain matter. A bridge table may be appropriate, but simply changing a relationship’s cardinality does not resolve every duplication or ambiguity problem.

16. What Is Cross-Filter Direction in Power BI?

Answer: Cross-filter direction determines how filters propagate between related tables in a Power BI semantic model. Depending on the relationship, Power BI may support single-direction or bidirectional filtering.

With a conventional one-to-many relationship, filtering from the dimension’s one-side towards the fact table’s many-side is a common approach. This supports star schema models in which dimensions filter the associated business activity.

Example: Selecting a product category in the Product dimension filters the related rows in the Sales fact table. A Total Sales measure then reflects the selected category.

Bidirectional filtering can be useful for specific modelling requirements, but enabling it unnecessarily may introduce ambiguous filter paths, harder-to-explain results or additional performance costs.

Important distinction: Bidirectional filtering is a modelling choice, not a universal performance or accuracy improvement. Use the simplest relationship configuration that supports the reporting requirement.

Interview tip: Be prepared to explain why single-direction filtering is commonly preferred in star schemas and give an example where a more specialised filter configuration might be required.

17. What Is the Difference Between a Calculated Column and a Measure in Power BI?

Answer: Calculated columns and measures both use DAX, but they serve different analytical purposes and have different evaluation and storage behaviour.

Calculated column example:

Sales[LineAmount] =
Sales[Quantity] * Sales[UnitPrice]

This example creates a row-level amount from quantity and unit price, assuming those columns contain appropriate numeric values.

Measure example:

Total Sales =
SUM(Sales[LineAmount])

The measure returns a total based on the current filters, such as the selected year, region or product category.

Interview tip: Do not assume that every calculated column should be replaced by a measure. Measures are generally suitable for dynamic aggregations, while columns may be necessary for particular row attributes, grouping or model relationships. Evaluate the requirement and storage mode before choosing.

18. What Is the Difference Between Row Context and Filter Context in DAX?

Answer: Row context provides access to values associated with the current row during certain DAX evaluations. Filter context determines which data is visible to a calculation through report selections, relationships and explicitly applied filters.

Row context is commonly introduced by calculated columns and iterator functions. Filter context is central to the evaluation of measures.

Row context example:

Total Revenue =
SUMX(
    Sales,
    Sales[Quantity] * Sales[UnitPrice]
)

The SUMX() iterator evaluates the expression for each row of the Sales table visible in the applicable filter context and sums the resulting values.

Filter context example: When a report user selects the South region, a Total Revenue measure may calculate only the transactions associated with that region, depending on the model’s relationships and filters.

These contexts can interact. For example, CALCULATE() can perform context transition when a row context exists, creating filter context from the current row in accordance with DAX rules.

Interview tip: Avoid defining row context as simply selecting a row in a visual. It is an evaluation concept in DAX and is not the same as the filters applied by a table or matrix visual.

19. What Does the CALCULATE Function Do in DAX?

Answer: CALCULATE() evaluates a DAX expression in a modified filter context. It is one of the most important functions for writing measures that apply, replace or remove particular filters.

Consider a semantic model with a Sales table containing a Region column and a SalesAmount column.

West Region Sales =
CALCULATE(
    SUM(Sales[SalesAmount]),
    Sales[Region] = "West"
)

This measure calculates sales for the West region. A filter argument on the same column generally replaces an existing filter on that column unless behaviour is modified using a function such as KEEPFILTERS().

Another example:

All Region Sales =
CALCULATE(
    SUM(Sales[SalesAmount]),
    REMOVEFILTERS(Sales[Region])
)

This calculation removes filters from the specified Region column while retaining other applicable filters. Its result is therefore not necessarily the total for the entire model.

Important distinction: CALCULATE() is not merely a function for adding conditions to a sum. It can also modify existing filters and perform context transition under applicable conditions.

Interview tip: Practise explaining why two measures with the same aggregation can return different values when their filter contexts differ.

20. What Is the Difference Between SUM and SUMX in DAX?

Answer: SUM() adds the numeric values in a column. SUMX() is an iterator that evaluates an expression for each row of a table and sums the results.

SUM example:

Total Amount =
SUM(Sales[Amount])

This is suitable when the amount to aggregate already exists as a numeric column.

SUMX example:

Total Sales Value =
SUMX(
    Sales,
    Sales[Quantity] * Sales[UnitPrice]
)

Here, Power BI evaluates quantity multiplied by unit price for each relevant row before summing those results. A separate calculated column is not required for this expression.

Business example: If two transactions have quantities of 2 and 3 and unit prices of ₹100 and ₹150 respectively, their combined sales value is ₹650. An iterator can calculate each transaction’s amount before aggregation.

Interview tip: Explain why multiplying SUM(Sales[Quantity]) by SUM(Sales[UnitPrice]) would generally not produce the same result as summing each transaction’s quantity-times-price calculation.

21. What Is the Difference Between RELATED and LOOKUPVALUE in DAX?

Answer: RELATED() retrieves a value from a related table using an existing relationship, subject to the applicable evaluation context. LOOKUPVALUE() returns a value based on one or more search conditions.

RELATED example: Suppose a Sales fact table has a many-to-one relationship with a Product dimension through ProductID.

Sales[ProductCategory] =
RELATED(Product[Category])

When used as a calculated column in an appropriate relationship context, this expression retrieves the category from the related Product table.

LOOKUPVALUE example:

Sales[ProductCategory] =
LOOKUPVALUE(
    Product[Category],
    Product[ProductID],
    Sales[ProductID]
)

The expression searches for a matching ProductID and returns the associated category, assuming the matching result satisfies LOOKUPVALUE() requirements.

Important distinction: LOOKUPVALUE() is not an unrestricted replacement for a relationship. Multiple matching rows with conflicting result values can produce an error unless an appropriate alternate result is supplied. Where a suitable relationship exists, RELATED() is often simpler.

Interview tip: Discuss whether a lookup should be implemented through the model relationship, Power Query or DAX. The most appropriate choice depends on model design and how the retrieved attribute will be used.

22. What Is the Difference Between ALL, ALLSELECTED and REMOVEFILTERS in DAX?

Answer: These functions are used in calculations involving filter context, but they have different semantics and should not be treated as interchangeable.

Example: Suppose a report displays revenue by product category.

Category Share =
DIVIDE(
    [Total Sales],
    CALCULATE(
        [Total Sales],
        REMOVEFILTERS(Product[Category])
    )
)

This measure divides the current sales value by sales calculated without the Product Category column filter, while other relevant filters may remain in effect.

For a visual-total calculation, ALLSELECTED() may be appropriate when the desired denominator should reflect the query’s outer selections. However, its exact behaviour should be tested in the intended visual and measure context.

Interview tip: Do not describe ALLSELECTED() simply as a function that keeps slicers and removes visual filters in every situation. Explain what total the business requires and verify the measure’s behaviour in the actual report.

23. How Do You Calculate Year-to-Date Sales in Power BI?

Answer: Year-to-date (YTD) sales accumulate revenue from the beginning of the defined reporting year through the current date or date context. DAX provides time-intelligence functions that support these calculations when the model’s date configuration meets the applicable requirements.

For conventional date-table time intelligence, establish a suitable Date table containing the required continuous range of dates, configure the relevant relationships and meet the date-table requirements for the selected DAX functions.

Base measure:

Total Sales =
SUM(Sales[SalesAmount])

Calendar-year YTD measure:

Sales YTD =
TOTALYTD(
    [Total Sales],
    'Date'[Date]
)

For a financial year ending on 31 March, a traditional date-column calculation can be written as follows:

Fiscal Sales YTD =
TOTALYTD(
    [Total Sales],
    'Date'[Date],
    "03/31"
)

This example specifies 31 March as the financial year-end for the applicable date-column syntax. The interpretation of formatted date strings can depend on the model’s locale, so the implementation should be tested with the configured date table.

Practical validation: Compare the measure with known monthly totals and check behaviour at the financial year boundary, across missing transaction dates and under relevant report filters.

Interview tip: Be prepared to explain the difference between a calendar year and a financial year, and distinguish year-to-date calculations from rolling 12-month totals. These answer different business questions.

24. What Is the Difference Between Merge and Append in Power Query?

Answer: Merge combines information from two queries using matching column values and a selected join operation. Append combines the rows from two or more queries into a single result.

Merge example: A Sales query contains CustomerID and transaction amounts. A Customers query contains CustomerID and customer segments. A merge can match the two queries by CustomerID and make selected customer details available.

Append example: Twelve monthly transaction files have the same intended structure. Appending them can create one combined transaction query, provided column names and data types are handled appropriately.

Illustrative Power Query M for appending:

Table.Combine( )

This expression combines rows from the listed queries. If their columns differ, the resulting table may contain missing values for columns not present in every input.

Interview tip: Explain how duplicate keys in a merge can multiply rows. Matching data does not necessarily imply a one-to-one join, so verify the grain and uniqueness of the join columns.

25. What Is Query Folding in Power Query, and Why Does It Matter?

Answer: Query folding occurs when Power Query can delegate supported transformations to the underlying data source through its native query capabilities. Instead of processing every transformation locally, the source can execute part or all of the required work.

For a supported relational database, a filter or column-selection step may be translated into operations performed by the source database. Query folding is not limited to generating SQL; its behaviour depends on the connector and source technology.

Illustrative example: Suppose a SQL Server table contains several years of transactions, but a report requires only records after a specified date.

Table.SelectRows(
    Source,
    each [OrderDate] >= #date(2026, 1, 1)
)

If the connector and transformation support folding, Power Query may delegate the filtering operation to the source, reducing the amount of data transferred or processed elsewhere.

Why it matters: Delegating selective filters and compatible operations can reduce resource usage and improve refresh or query performance. It is particularly important in certain DirectQuery and incremental refresh designs, where source query behaviour can materially affect the solution.

How to check: Power Query provides facilities such as query folding indicators and, for applicable steps, a View Native Query option. Availability depends on the connector and transformation context; a disabled menu option alone does not establish that no upstream folding occurs.

Interview tip: Do not claim that every transformation before a non-folding step will always execute at the source. Explain that folding depends on the sequence of transformations, connector capabilities and the final query plan.

Power BI Visualisation and Reporting Interview Questions

Questions about Power BI visuals often begin with chart selection but quickly move into report interaction, usability and how results are interpreted. A reporting developer should be able to explain not only how to create a visual but also whether that visual communicates the intended business information accurately.

26. What Are Power BI Visualisations, and How Do You Choose the Right One?

Power BI visualisations present model data through charts, tables, cards, maps and other graphical or tabular formats. Different visuals answer different analytical questions, so selecting one should begin with the information users need to understand.

A pie chart may work for a small number of distinct proportions, but it becomes harder to interpret when many categories have similar values. For detailed comparisons, a sorted bar chart is often more readable.

Practical consideration: A revenue chart should identify its currency, reporting period and measure definition. A visually impressive chart is not useful if readers cannot determine what its values represent.

27. What Is the Difference Between Slicers and Filters in Power BI?

A slicer is an interactive report visual that allows users to select values and filter applicable report visuals. Filters provide a broader filtering mechanism and can be configured at different scopes, including visual, page and report levels.

Consider a regional sales report. A visible Region slicer allows readers to switch between regions. A report-level filter might exclude test transactions across every report page. A visual-level filter could restrict one particular chart to the ten highest-selling products.

The two mechanisms are not mutually exclusive. Slicers contribute to report filtering, while filters may also be applied through other report interactions and model behaviour.

Common mistake: Describing filters as merely a hidden backend feature. The Power BI Filters pane can be visible to report users, depending on report configuration and permissions.

28. What Are Custom Visuals in Power BI?

Custom visuals extend the visualisation capabilities available in Power BI. They may be obtained through supported marketplaces such as Microsoft AppSource, developed for an organisation or distributed through approved internal processes.

Suppose a business needs a specialised chart that is not adequately supported by its available built-in visuals. A custom visual may provide the required layout or interaction, but its selection should include technical and governance checks.

• Data access: Understand what information the visual processes and whether external services are involved.
• Compatibility: Check support for the organisation’s reporting and export requirements.
• Accessibility: Verify labels, keyboard support and readability where relevant.
• Maintenance: Assess updates, vendor support and organisational approval.

Funnel charts and some other specialised visual types are already available as built-in options, so they should not automatically be presented as examples that require third-party installation.

29. What Is a Dashboard in Power BI?

A Power BI dashboard is a single-page canvas in the Power BI service that presents selected information through tiles. Those tiles may originate from different reports and semantic models.

For example, a business dashboard might display total revenue, open support requests and customer satisfaction measures gathered from separate reporting solutions. Each tile communicates an important metric without requiring users to open every underlying report.

Dashboards are created in the Power BI service, not in Power BI Desktop. Their filtering capabilities also differ from those of interactive reports: standard dashboard tiles do not provide the same page-wide slicer experience as report visuals.

Source: Microsoft explains these characteristics in its Power BI dashboard documentation.

30. How Is a Power BI Report Different From a Dashboard?

Reports are intended for analysing and exploring data, while dashboards typically provide a consolidated monitoring view. The distinction affects authoring, interactivity and the way people navigate information.

Business example: A regional sales manager uses a report to investigate falling revenue by product and customer segment. An executive dashboard shows a smaller set of headline indicators and links users to the reports when deeper investigation is required.

31. How Do You Build an Effective KPI Visual in Power BI?

A key performance indicator compares a business measure against a defined objective, previous result or threshold. Before creating the visual, establish what the metric means, which period it covers and how success is evaluated.

Consider a sales team with actual revenue and an approved revenue target. Two basic measures might be:

Revenue =
SUM(Sales[Amount])

Target Revenue =
SUM(Targets[TargetAmount])

A further measure calculates performance relative to the target:

Target Achievement % =
DIVIDE(
    [Revenue],
    [Target Revenue]
)

These measures assume that the Sales and Targets tables respond correctly to the intended reporting dimensions. Format the ratio as a percentage and define how the business handles missing or zero targets.

An effective KPI visual should make the reporting period and comparison clear. A green status indicator without an understandable threshold can mislead users, even when the underlying DAX measure is mathematically correct.

32. What Is Drillthrough in Power BI, and When Should You Use It?

Drillthrough allows a report user to navigate from a summary visual to a designated report page containing details relevant to the selected data context.

Imagine a report showing revenue by region. A user selects the South region and drills through to a detail page displaying its customers, products and transactions. The drillthrough page receives the relevant filter context according to the configured fields and settings.

Typical implementation: Create a detail page, add the appropriate field to its drillthrough configuration, design the supporting visuals and test navigation from eligible source visuals.

Drillthrough differs from drill down. Drill down moves through levels of a hierarchy within a visual, such as Year to Quarter to Month. Drillthrough navigates to another report page for contextual analysis.

Include a clear return path and check that report filters do not accidentally hide important detail records.

33. What Are Bookmarks in Power BI?

A bookmark records selected aspects of a report page’s state, such as filters, slicers, visual visibility and display configuration. Report authors use bookmarks to create navigation patterns or save presentation states.

Worked example: A business report has two alternative views of performance. One presents monthly revenue; the other presents revenue by product category. Bookmarks and buttons can switch between the views without requiring a separate report for each.

Bookmark options influence whether data-related selections, display settings and the current page are captured. If a bookmark unexpectedly resets a user’s slicer selection, inspect its Data option and the visuals affected.

For maintainable reports, give bookmarks descriptive names and test them after changing report layouts or interactions.

34. How Does Conditional Formatting Work in Power BI?

Conditional formatting changes supported visual properties according to values, rules or measures. It is commonly used to highlight unusually high or low results, identify missing targets or distinguish categories requiring attention.

For example, a performance matrix could show negative variance in red and positive variance in green. A measure can provide the value used for the formatting rule:

Revenue Variance =
[Revenue] - [Target Revenue]

The report author can then configure a supported visual to apply formatting based on this measure.

Design consideration: Colour alone should not communicate a critical status. Include readable numbers, labels or icons where appropriate, especially when reports are used by people with colour-vision differences.

35. When Should You Use a Table Instead of a Matrix in Power BI?

Use a table when readers need a list of records or fields in straightforward columns. Choose a matrix when the analytical task requires row and column groupings, hierarchical exploration or subtotals.

A customer support report listing Ticket ID, Assigned Agent, Priority and Resolution Date is a natural table use case. A report comparing ticket volume by Department and Month is more suitable for a matrix.

Matrix visuals can show totals and subtotals at different hierarchy levels. Those totals evaluate measures in their own filter context, which is important when calculations involve ratios or non-additive metrics.

A frequent reporting problem occurs when users expect a matrix grand total to be the arithmetic sum of every displayed percentage. The correct calculation depends on the metric’s business definition, not merely the visual format.

36. What Are Power BI Report Themes?

A report theme provides a reusable set of formatting choices, including supported colours, typography and visual styling. Themes help teams maintain consistent presentation across report pages.

For instance, an organisation may define its corporate colour palette, standard report fonts and default visual formatting through a theme file. Report authors can apply that theme instead of configuring every supported formatting property independently.

Power BI supports importing and customising themes, including supported JSON-based theme definitions. Individual visual settings may override theme defaults, so applying a new theme does not guarantee that every previously customised visual will change.

Theme consistency is valuable, but accessibility takes priority over brand decoration. Verify text contrast, label size and distinguishability of chart series before publishing.

37. What Is a Report Page Tooltip in Power BI?

Tooltips display additional information when users interact with supported visuals, often through hovering. Power BI can show default tooltip values or use specially configured report pages for richer detail.

Consider a bar chart showing revenue by product category. A report page tooltip could add gross margin, order count and a small monthly trend chart for the hovered category.

Tooltips are useful when extra context helps interpretation but does not need to occupy permanent space on the main report canvas.

Usability limitation: Important information should not be available only through hover interactions. Report consumers using touch devices or accessibility technologies may interact with tooltips differently.

38. What Is the Power BI Q&A Feature?

Power BI Q&A is a natural-language querying capability that allows supported users to ask questions about data and receive answers through appropriate visual representations.

A question such as total revenue by region may generate a chart when the semantic model contains clear field names, suitable relationships and measures that Power BI can interpret.

Results depend on model quality, supported language behaviour, the availability of the feature and the way ambiguous terms are interpreted. Q&A does not independently verify whether a business metric has been defined correctly.

Important 2026 update: Microsoft has announced the retirement of Power BI Q&A and recommends Copilot for Power BI as an alternative for supported natural-language analysis. Candidates should understand how the existing Q&A feature works, but organisations planning new reporting solutions should review Microsoft’s current deprecation timeline, Copilot requirements and available alternatives before adopting it.

Official reference: Microsoft’s Power BI Q&A documentation includes the retirement notice and references to recommended alternatives.

39. How Would You Improve the Performance of a Slow Power BI Report?

Begin by identifying the bottleneck rather than immediately removing visuals or switching storage modes. Slow report performance can originate from the semantic model, DAX expressions, source queries, network conditions or visual rendering.

A practical investigation sequence:

1. Reproduce the slowdown using representative filters and report pages.
2. Use Performance Analyzer to identify visuals with unusually long query or rendering times.
3. Review expensive DAX expressions and relationship behaviour.
4. Check table size, unnecessary columns, data types and model design.
5. For DirectQuery models, inspect source-query performance and concurrency limits.
6. Make one meaningful change at a time and compare the results under similar conditions.

A star schema, efficient measures, suitable aggregations and less crowded report pages can help in the right circumstances. However, no fixed number of visuals guarantees good performance, and replacing calculated columns with measures is not automatically beneficial.

40. What Is the Difference Between Import Mode and a Live Connection?

Import mode stores a copy of selected source data within the semantic model. A live connection generally allows a report to connect to an existing analytical model rather than creating a separate full import of the underlying data for that connection.

For example, an organisation may maintain a shared Power BI semantic model containing governed sales measures. Report authors can connect to that model and develop reports without recreating the entire data preparation and modelling process.

Import, DirectQuery and live connection are not synonymous terms. A live connection to a semantic model is different from a DirectQuery connection to a relational database, although supported composite modelling scenarios can introduce additional arrangements.

The freshness of a live-connected report depends on the underlying model and its data connectivity or refresh behaviour. A live connection does not mean every value is continuously updated from the original transactional system.

Advanced Power BI Interview Questions for Experienced Professionals

Advanced Power BI interviews often explore decisions that affect multiple reports, large semantic models or enterprise environments. Questions may involve performance, refresh design, deployment and security. Strong answers make the constraints explicit and explain why a particular approach is suitable.

41. What Is a Composite Model in Power BI?

A composite model combines supported data connectivity or storage arrangements within one semantic model. It can help meet reporting requirements that cannot be addressed effectively using a single storage approach.

Consider a retail reporting system with a large operational sales table and a relatively small Product dimension. A supported composite model may use DirectQuery for detailed sales records and Import storage for selected dimension data.

This is a design option rather than an automatic optimisation. Relationships that cross storage groups, source-query performance and modelling restrictions can affect the result.

Decision point: Before using a composite model, establish the required data freshness, query response time, source capacity and any limitations affecting DAX or relationships.

42. How Do You Optimise a Power BI Semantic Model With Millions of Rows?

The number of rows matters, but it is not enough to predict model performance. Column cardinality, data types, relationships, compression, storage mode and query behaviour can be just as important.

Start by checking which columns and records are genuinely required. A transaction identifier with a unique value on every row may consume considerable storage, whereas a low-cardinality category field can compress more efficiently.

For a large Import model, useful actions may include removing unused columns, selecting appropriate data types, reducing unnecessary calculated columns, improving dimensional modelling and evaluating refresh partitions.

For DirectQuery, source indexing, query folding, database execution plans and concurrency may deserve greater attention.

Worked example: A daily revenue report does not necessarily need every free-text customer note from the transaction system. Excluding unused text fields can reduce model size without removing the records required for revenue reporting.

Assess optimisation with actual model statistics and representative report queries. Reducing storage without checking calculation accuracy can create a different problem.

43. What Are Aggregation Tables in Power BI?

Aggregation tables store summarised information at a higher grain than the underlying detailed data. They can reduce the amount of processing needed for queries that only require summary results.

Suppose a transaction table contains individual sales records, but executives frequently request monthly revenue by region. An aggregation table could store one row per month and region rather than requiring those summaries to be recomputed from all detailed transactions for every eligible query.

Power BI provides supported aggregation features that can route eligible queries to appropriate aggregation tables when their configuration and matching conditions are satisfied.

Important trade-off: An aggregation at monthly level cannot answer every day-level or transaction-level question. The aggregation design must reflect the dimensions and measures users actually query.

44. How Does Incremental Refresh Work in Power BI?

Incremental refresh manages data refresh across partitions so that qualifying recent periods can be refreshed without reprocessing all historical data on every refresh.

Typical setup: Define Power Query parameters named RangeStart and RangeEnd, apply an appropriate date/time filter to the relevant table, configure the incremental refresh policy and publish the semantic model to a supported environment.

An illustrative policy might retain five years of records while refreshing the most recent two months. The actual result depends on the model configuration, partition policies and supported service features.

For relational sources, confirm that the relevant transformations can fold efficiently. A poorly configured query may still place substantial load on the source or make the intended refresh approach ineffective.

Common misconception: Incremental refresh does not guarantee that every changed historical record will be detected. The refresh window and any configured change-detection mechanism determine which records are reconsidered.

45. What Are Calculation Groups in Power BI?

Calculation groups allow model authors to define reusable calculation transformations that can apply to selected measures. They can reduce repetition when many measures require comparable calculations, such as year-to-date results or previous-period comparisons.

Without calculation groups, a model containing Revenue, Cost and Units measures might require separate YTD and previous-year measures for every metric. A calculation group can centralise suitable transformations.

A calculation item can use SELECTEDMEASURE() to refer to the measure being evaluated.

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD('Date'[Date])
)

This illustrative calculation item applies a calendar-year YTD date filter to the selected measure, assuming an appropriate date model and supported calculation group configuration.

Calculation groups also require attention to precedence, format strings and interactions with existing measures. They simplify some models but can make debugging harder if applied without clear conventions.

46. How Can Power BI Support Analysis of Billions of Records?

There is no single architecture that guarantees good performance for billions of source records. The design depends on data size, analytical grain, query frequency, freshness requirements and available capacity.

Possible approaches include querying an appropriately designed source through DirectQuery, using supported Direct Lake capabilities for data in OneLake, maintaining carefully designed Import models or combining detail access with aggregation tables.

Example architecture: A telecommunications business retains detailed usage records in a large analytical data platform. Most management reports query daily summaries, while authorised analysts use a separate detailed reporting path for investigation.

This separates routine summary workloads from costly detailed queries. It also makes the reporting requirements easier to match to suitable storage and capacity choices.

Key constraint: Billions of records in a source system do not necessarily mean billions of rows must be loaded into a single semantic model. Define what users need to analyse before deciding what data to import or query.

47. How Do You Diagnose Query Folding Problems in Power Query?

Query folding problems arise when Power Query cannot delegate an expected transformation to the underlying source. The result may be additional local processing, increased data transfer or longer refresh times.

For example, filtering a large SQL table by date may fold successfully, while a later custom transformation using an unsupported operation may prevent further transformations from being delegated.

To investigate, inspect the applied steps, relevant folding indicators, available native-query views and source execution behaviour. Where suitable, move selective compatible operations earlier in the transformation process and evaluate whether the source can perform them.

Do not assume that every source supports SQL-style folding or that all transformations before one unsupported step necessarily fold. Connectors can differ, and Power Query may optimise transformations rather than execute them strictly in the displayed step order.

48. How Would You Govern Power BI Workspaces in a Large Organisation?

Workspace governance starts with ownership, access and the intended lifecycle of analytical content. A report used by one team has different requirements from a certified financial model shared across an organisation.

Power BI workspace roles include Admin, Member, Contributor and Viewer. Assign access according to responsibilities, but review permissions beyond the workspace itself, including sharing, apps, semantic model access and relevant organisational settings.

A practical governance model can establish naming conventions, accountable owners, approved publishing processes, sensitivity classifications and procedures for reviewing access when employees change teams.

Security distinction: Workspace permissions and row-level security solve different problems. RLS controls which rows eligible viewers can query; workspace roles and other permissions control what people can do with analytical content. RLS does not restrict every privileged workspace role in the same way.

Audit access using test accounts that reflect real consumer permissions, not only an administrator’s account.

49. What Is a Paginated Report in Power BI?

Paginated reports are designed for carefully controlled, page-oriented output. They are useful when the report must preserve a detailed layout for printing, exporting or distributing structured records.

Power BI Report Builder is a supported authoring tool for paginated reports. Common applications include invoices, financial statements, operational extracts and formal reports with repeated headers or page numbers.

Comparison: An interactive Power BI report is usually more suitable for exploring sales trends and selecting filters. A paginated report may be preferable when a business must generate a consistent invoice or long tabular document for each customer.

Paginated reports can also support parameters and other interactive capabilities. They should not be described as entirely static or limited to PDF output.

50. How Do You Optimise a Slow DAX Measure?

First establish whether the measure is slow under the intended report filters and identify which part of its evaluation is expensive. A shorter DAX expression is not necessarily a faster one.

Suppose a measure calculates sales for a specific region using an explicit row filter:

APAC Sales =
SUMX(
    FILTER(
        Sales,
        Sales[Region] = "APAC"
    ),
    Sales[Amount]
)

When the requirement is simply to sum an existing numeric column for a region, an alternative is:

APAC Sales =
CALCULATE(
    SUM(Sales[Amount]),
    Sales[Region] = "APAC"
)

The second formulation expresses the aggregation with a Boolean filter argument. It may be more efficient in appropriate models, but the expressions can differ when existing filters on the Region column must be preserved.

Other useful techniques include avoiding unnecessary iteration, using variables where they improve clarity or evaluation behaviour, checking relationship design and reviewing model cardinality.

Tools such as Performance Analyzer and DAX Studio can help identify expensive queries. Benchmark changes rather than assuming that replacing one DAX function with another guarantees faster performance.

51. What Are Deployment Pipelines in Power BI?

Deployment pipelines support controlled promotion of supported analytical content between development stages. They help teams manage changes before making reports and semantic models available to production users.

A common process uses Development, Test and Production stages. Developers validate changes in a development workspace, move eligible content to testing, and then deploy approved changes into production.

Deployment rules can help configure supported environment-specific connections or parameters. However, teams still need appropriate testing, permissions, source-control practices and change-management procedures.

Important distinction: A deployment pipeline is not the same as a Git version-control system. It assists with deployment across environments but does not independently provide every feature of source control, code review or rollback.

52. What Is an XMLA Endpoint in Power BI?

An XMLA endpoint provides supported client tools with access to the analytical model interface of eligible Power BI semantic models. It enables enterprise administration and development workflows using compatible Analysis Services tools and protocols.

Depending on capacity, permissions and endpoint configuration, supported scenarios include querying model metadata, running analytical queries and performing advanced model-management operations.

For example, a BI engineering team may use compatible tooling to inspect a semantic model or automate supported metadata changes. Read/write capabilities depend on the environment’s configuration and licensing.

Technical distinction: XMLA endpoints relate to semantic model connectivity and management. They are not general-purpose interfaces for directly editing every underlying transactional data source.

53. What Is the Difference Between a Dataflow and a Semantic Model?

A dataflow is used for supported data ingestion and transformation workflows, helping organisations prepare information for downstream analytical use. A semantic model defines the tables, relationships, measures and other analytical elements through which reports query and interpret data.

For example, a central data preparation process could clean customer records and standardise identifiers. A sales semantic model could then use those prepared records together with transaction data to calculate revenue by customer segment.

Microsoft offers different dataflow capabilities within its Power BI and Fabric ecosystems. Features, destinations and lifecycle behaviour depend on the specific dataflow experience being used.

54. How Does Dynamic Row-Level Security Work in Power BI?

Dynamic row-level security (RLS) uses the identity of the current viewer, together with model rules or mapping data, to determine which records that person may query.

Consider a sales model where regional managers should see data only for their assigned territories. Rather than maintaining a separate role for every manager, the organisation can use a security mapping table associating users with permitted regions.

A simple security filter on an appropriately structured user mapping table might be:

UserRegion[Email] = USERPRINCIPALNAME()

The model relationships must propagate the permitted regions to the intended data, using an appropriately validated security design. The expression alone does not establish correct filtering across every possible many-to-many arrangement.

Where a manager belongs to multiple regions, a mapping table with multiple authorised rows can support that relationship more naturally than assuming every user has exactly one assigned region.

Security testing: Validate RLS with representative user identities and applicable consumer permissions. Do not assume that RLS protects against people who hold roles or permissions that bypass its intended restrictions.

55. What Makes a Power BI Semantic Model Maintainable at Enterprise Scale?

Enterprise modelling quality is measured by whether teams can understand, reuse, secure and change the model without producing inconsistent business results.

A maintainable model starts with agreed definitions for metrics such as revenue, active customers and gross margin. It then expresses those definitions through appropriate fact and dimension structures, named measures and documented calculation logic.

Useful design practices include:

• Clear table grain: Document what each fact table row represents.
• Consistent business measures: Reuse approved metric definitions rather than duplicating calculations in every report.
• Understandable relationships: Avoid unnecessary ambiguous paths and bidirectional filtering.
• Appropriate security: Test RLS, permissions and access to sensitive analytical data.
• Controlled releases: Validate changes before deployment to production workspaces.
• Performance monitoring: Review model size, expensive queries and refresh reliability using representative workloads.

Example: Two departments should not calculate customer retention differently merely because their reports were developed independently. A shared, documented retention measure can improve consistency, provided both departments actually use the same approved business definition.

The objective is not to apply every advanced feature. A smaller, well-structured model with clear ownership may be more reliable than a complex architecture containing unnecessary calculation groups, relationships or storage modes.

Scenario-Based Power BI Interview Questions and Answers

Scenario-based Power BI interview questions assess how candidates investigate reporting problems and make technical decisions under business constraints. A useful response identifies the requirement, checks the available data, explains the proposed implementation and considers how the result will be validated.

The following 20 scenarios cover issues that arise in real reporting environments, including data security, incorrect totals, performance, refresh frequency, currency conversion and stakeholder requirements. These are illustrative exercises rather than verified questions asked by a particular employer.

56. Regional Managers Must Only See Sales From Their Assigned Regions. How Would You Implement This?

The requirement is a data-access restriction, not simply a report-filtering preference. A slicer is insufficient because users can potentially change or remove report filters. Row-level security (RLS) should be evaluated to enforce the appropriate row restrictions for eligible report consumers.

For a simple model with one permitted region per manager, a security rule could use a user-to-region mapping table. For managers responsible for multiple regions, the mapping table should support multiple authorised assignments.

The implementation involves establishing the mapping, configuring the relevant model relationships and roles, assigning users or groups appropriately, and testing how security filters reach the sales data.

Validation: Test with identities representing a single-region manager, a multi-region manager and a person with no authorised assignment. Verify permissions outside RLS as well, since elevated workspace access can affect security behaviour.

57. A Power BI Report With 50 Million Transaction Rows Loads Slowly. What Would You Investigate?

I would first identify whether the delay comes from opening the report, executing DAX queries, retrieving source data or rendering visuals. The fact table’s row count is relevant, but it does not identify the cause by itself.

Investigation sequence: Use Performance Analyzer to identify slow visuals, inspect expensive calculations, examine the semantic model’s relationships and column cardinality, and check whether the selected storage mode matches the reporting workload.

If the model uses Import, removing unnecessary high-cardinality columns or reducing data granularity where business requirements permit may help. For DirectQuery, examine source execution plans, query folding and database capacity. Summary-level reporting may also benefit from suitable aggregation tables.

Decision: I would not automatically convert the entire report to Import or DirectQuery. The recommended change should follow measurements, data-freshness requirements and tests showing that the revised design preserves report accuracy.

58. A DAX Measure Shows an Unexpected Grand Total in a Matrix. How Would You Debug It?

A matrix grand total does not necessarily add the displayed row results. Power BI generally evaluates the measure again in the grand total’s filter context. This becomes noticeable with percentages, averages, distinct counts and other non-additive calculations.

Suppose a measure calculates profit margin:

Profit Margin % =
DIVIDE(
    [Total Profit],
    [Total Sales]
)

When the matrix shows individual departments, each department’s percentage is calculated from its own profit and sales. The grand total should normally calculate total profit divided by total sales, not add the department percentages.

Debugging approach: Check the base measures, relationships, filters and expected aggregation. Use a simpler table showing numerator and denominator values before modifying the DAX.

Functions such as VALUES(), SELECTEDVALUE() and ISINSCOPE() may help inspect or respond to the current context. However, adding CALCULATE() or removing filters indiscriminately can conceal the real issue.

The correct grand total depends on what the business metric is supposed to represent.

59. How Would You Calculate Year-to-Date Sales for a Financial Year Starting in April?

For an April-to-March financial year, the YTD calculation must reset after 31 March rather than at the end of December. The semantic model should contain a suitable Date table connected to the relevant sales dates.

With conventional date-column time intelligence, the calculation can be written as:

Fiscal Sales YTD =
TOTALYTD(
    [Total Sales],
    'Date'[Date],
    "03/31"
)

Here, [Total Sales] is an existing measure. The year-end argument identifies 31 March, although date-string interpretation should be validated against the model’s locale and applicable DAX syntax.

Test case: Compare the result for March and April using known transaction totals. The April result should begin a new financial-year accumulation, rather than carrying forward the previous financial year’s sales.

For fiscal calendars with non-standard period structures, a custom calendar design and appropriately selected time-intelligence approach may be needed.

60. A Stakeholder Wants SQL Server Data Updated Every 15 Minutes. How Would You Design the Report?

The first question is what updated every 15 minutes means. Does the stakeholder require source data to be available within 15 minutes, or must an unattended display visibly update at that interval? These requirements can lead to different solutions.

For Import mode, evaluate scheduled or automated refresh options against the current workspace licensing, capacity and refresh limits. A 15-minute schedule requires 96 refreshes per day, so it should not be assumed to fit ordinary scheduled-refresh allowances.

DirectQuery may be suitable when queries need to retrieve more recent data from SQL Server without importing the entire dataset. However, source-query execution, caching and visual refresh behaviour still affect what users see.

If automatic page refresh is required, check whether the applicable Power BI configuration, capacity and report type support the desired interval.

Proposed test: Update a controlled source record, measure when the report reflects the change, and assess responsiveness under expected concurrent usage. This is more meaningful than labelling the design real-time without measuring its actual latency.

61. A Report Shows an Incorrect Average Sales Value. How Would You Fix It?

Before rewriting the measure, determine what the stakeholder means by average. Average transaction value, average sales per customer and average monthly revenue are different metrics.

Suppose the required measure is average revenue per distinct customer in the current reporting context:

Average Revenue per Customer =
DIVIDE(
    [Total Sales],
    DISTINCTCOUNT(Sales[CustomerID])
)

This expression divides sales by the number of distinct customer identifiers present in the filtered Sales table. It is not necessarily the correct definition of average customer revenue if customers without transactions must be included.

For average transaction amount, the denominator should instead represent transactions, using the appropriate unique transaction identifier and treatment of returns or adjustments.

Why the distinction matters: Replacing AVERAGE() with SUM() / COUNTROWS() does not automatically correct a metric. The denominator must correspond to the business entity being averaged.

62. Products and Promotions Have a Many-to-Many Relationship. How Would You Model It?

First identify the relationship: a product may belong to several promotions, and a promotion may apply to several products. A bridge table containing valid product-promotion combinations can represent these assignments.

The bridge provides a way to represent the assignments, but the measure design still matters. If a product participates in three promotions, its total sales must not automatically be counted three times merely because the model contains three assignments.

The solution should define whether sales are associated with a specific promotion at transaction level or whether users merely need to identify products eligible for a promotion.

Validation: Check product counts, eligible sales totals and filter propagation before enabling bidirectional filtering or relying on many-to-many cardinality as a shortcut.

63. How Would You Secure Sensitive Data in Power BI Beyond Row-Level Security?

RLS restricts access to rows under applicable permissions, but it does not address every form of sensitive-data exposure.

For confidential finance or personnel data, evaluate multiple layers of protection:

• Object-level security: Restrict access to supported tables or columns where required.
• Workspace and sharing permissions: Limit who can view, modify, redistribute or administer content.
• Data minimisation: Avoid importing personal or confidential fields that are unnecessary for the reporting purpose.
• Sensitivity labels: Apply supported information-protection classifications and controls.
• Identity and access policies: Use appropriate organisational authentication, group management and conditional access settings.
• Export and downstream access: Review how data can be obtained through exports, underlying-model permissions or other supported interfaces.

Example: A report may show aggregated payroll costs by department without giving ordinary viewers access to employee-level salary fields. The design must protect the underlying data, not merely hide sensitive columns from a visible table.

Security controls should be tested with representative permissions, including scenarios involving report sharing and access to the semantic model.

64. How Would You Compare Current-Year Sales With Previous-Year Sales?

A standard approach uses a properly configured Date table and a prior-year measure that shifts the reporting date context.

Sales Previous Year =
CALCULATE(
    [Total Sales],
    SAMEPERIODLASTYEAR('Date'[Date])
)

Then create measures for the absolute and percentage changes:

Sales YoY Change =
[Total Sales] - [Sales Previous Year]

Sales YoY Change % =
DIVIDE(
    [Sales YoY Change],
    [Sales Previous Year]
)

A line chart can compare the measures across months, while a matrix can show year-over-year changes by product category or region.

Before publishing, decide whether the comparison is based on matching calendar dates, completed months, financial periods or another business calendar. Partial periods and leap years can affect interpretation.

65. Report Users Complain That There Are Too Many Slicers. How Would You Improve the Experience?

I would review how users actually navigate the report before replacing the slicers. Frequently used selections should be easy to reach, while specialised controls may belong on separate detail pages or in a collapsible filter area.

For example, a sales report with filters for Country, State, City, Product, Category, Channel, Salesperson and Date may overwhelm users who usually need only Date, Region and Category.

A revised design might retain the three common slicers, place additional controls in a dedicated filter panel, use supported hierarchy or search capabilities and provide drillthrough pages for detailed investigation.

Bookmarks can help show or hide a custom filter panel, but their data and display settings must be configured carefully to avoid unexpectedly resetting report selections.

Success criterion: Test whether users can complete common tasks more quickly and interpret the active filters accurately. Fewer slicers are useful only when they do not remove necessary analytical control.

66. An Executive Wants a One-Page KPI Summary. What Would You Include?

The page should focus on business decisions rather than displaying every available metric. I would first confirm the executive’s responsibilities and the measures used to assess performance.

A sales leadership summary might include revenue, revenue growth, gross margin, performance against target and one or two important operational indicators.

Each measure should have a clearly defined reporting period and business calculation. A revenue growth figure without the comparison period or an achievement percentage without its target can create confusion.

Use cards for headline values, an appropriate trend chart for changes over time and limited category comparisons where they explain performance. Provide navigation to detailed reports when further investigation is needed.

Design constraint: Executive reporting should remain readable on the devices and displays actually used. The objective is a decision-oriented summary, not a fixed maximum number of visuals.

67. A Power BI Report Is Difficult to Read on Mobile. How Would You Fix It?

Power BI supports mobile-oriented report layouts that allow authors to arrange supported visuals for smaller screens. The first step is to inspect the report in its intended mobile experience rather than assuming the desktop canvas will scale effectively.

I would prioritise the most important KPIs, simplify long tables, adjust chart dimensions and review label readability. Visuals that require extensive horizontal scrolling may need a different representation.

For example, a wide table containing 15 measures might be replaced on the mobile layout by a concise KPI summary with navigation to additional detail.

Testing: Check the layout on representative devices, verify slicer usability and confirm that touch interactions do not hide important content. Mobile optimisation should improve access without changing the definitions of the underlying measures.

68. Power BI and Excel Show Different Totals for the Same Data. How Would You Reconcile Them?

I would not assume that the discrepancy comes from DAX or that Excel always calculates values differently. Excel PivotTables can also use the Data Model and DAX, depending on their configuration.

The investigation should compare the source data, refresh time, applied filters, calculation definitions, joins, duplicate handling, data types and treatment of blanks.

Example: Excel calculates a simple average of transaction amounts, while Power BI displays average revenue per distinct customer. Both calculations may be mathematically valid, but they answer different questions.

To reconcile the result, construct a small comparison dataset and establish which business definition should be used. Then apply matching filters and calculations in both tools and compare the output.

A trustworthy reporting solution requires agreement on metric definitions, not simply forcing two numbers to match without understanding them.

69. How Would You Display a Power BI Report in SharePoint Online?

For supported SharePoint Online pages, the Power BI web part can display a Power BI report. The report must be published and appropriately accessible to its intended audience.

A typical process involves selecting the relevant report in the Power BI service, obtaining the supported SharePoint embedding link, adding a Power BI web part to the SharePoint page and configuring the report reference.

Access consideration: Embedding a report in SharePoint does not automatically grant permission to everyone who can open the SharePoint page. Users still need appropriate Power BI access and licensing or capacity arrangements.

Test with an ordinary intended user instead of only checking the page using the report author’s account.

70. How Can You Share a Power BI Report Securely With an External Client?

The sharing approach depends on whether the client should interact with the report, whether the data is confidential, and which licensing and capacity arrangements are available.

For interactive access, consider supported external-user sharing through Microsoft Entra B2B or another approved embedding arrangement. Review guest access policies, tenant settings, report permissions, semantic model permissions and the applicable licensing requirements.

Important security warning: Power BI’s Publish to web capability makes supported content publicly accessible. It is not an appropriate method for sharing confidential customer, employee or financial information.

Capacity-based access rules also require care. Do not assume that every paid capacity or workspace allows all external users to view content without individual licences. The actual requirements depend on the capacity type, licensing and sharing configuration.

If the client only needs a static deliverable, an approved export workflow may be simpler, provided the organisation’s information-handling policies permit it.

71. How Would You Handle Currency Conversion in a Multi-Country Sales Report?

Currency conversion requires an agreed business rule before any DAX expression is written. The organisation must define the reporting currency, applicable rate source, conversion direction and whether transactions use daily, monthly or another approved exchange rate.

A suitable exchange-rate table might include RateDate, SourceCurrency, TargetCurrency and ConversionRate, with one valid rate for each required combination.

Illustrative DAX measure:

Sales in USD =
SUMX(
    Sales,
    VAR Rate =
        LOOKUPVALUE(
            ExchangeRate[RateToUSD],
            ExchangeRate[RateDate], Sales[OrderDate],
            ExchangeRate[Currency], Sales[Currency]
        )
    RETURN
        IF(
            ISBLANK(Rate),
            BLANK(),
            Sales[Amount] * Rate
        )
)

This assumes that RateToUSD converts one unit of the source currency into USD, the dates and currency codes match, and each lookup resolves to a suitable unambiguous rate. The model must handle missing or conflicting rates explicitly.

For large datasets, repeated lookup operations may warrant a different data-preparation or modelling design. Where the business permits, a governed conversion table and precomputed converted amounts may simplify reporting.

Reconciliation: Check a small set of known transactions against the organisation’s approved rates. Incorrect rate direction, dates or rounding can produce substantial reporting errors.

72. How Would You Build a What-If Analysis for Price Changes?

What-if analysis allows users to explore how changing an assumption might affect a calculated result. Power BI supports numeric parameters and DAX measures for suitable interactive scenarios.

Suppose a retailer wants to explore hypothetical price adjustments from a 10% decrease to a 10% increase. A numeric parameter can capture the selected percentage change.

Assuming a parameter table named Price Change with a numeric column named Price Change, a measure could be:

Simulated Revenue =
[Total Sales] *
(
    1 +
    SELECTEDVALUE(
        'Price Change'[Price Change],
        0
    )
)

This calculation assumes sales volume remains unchanged when the price changes. It therefore models a simplified revenue scenario, not an actual forecast of customer purchasing behaviour.

A more realistic model might account for demand elasticity, discounts, taxes or product-specific assumptions, using an approach appropriate to the available data.

Interpretation: Label the result as simulated revenue so stakeholders do not confuse a hypothetical calculation with actual or forecast revenue.

73. How Would You Compare Actual Sales Against Targets Across Products and Regions?

First establish the grain of the target data. A monthly regional target cannot necessarily be allocated to individual products unless the business has defined a product-level allocation rule.

For a model where actual and target tables are correctly associated with shared reporting dimensions, measures might include:

Actual Sales =
SUM(Sales[Amount])

Sales Target =
SUM(Targets[TargetAmount])

Sales Variance =
[Actual Sales] - [Sales Target]

Sales Achievement % =
DIVIDE(
    [Actual Sales],
    [Sales Target]
)

The Date, Product and Region dimensions should filter the appropriate data in a way that respects the grain of each table.

Example: If the target table contains monthly values by region but no product field, displaying that target against every individual product could create misleading results. The report should either restrict the comparison to the supported grain or use an approved allocation rule.

Choose a matrix, bar chart or combination chart according to whether readers need precise values, category comparisons or trends. Validate totals against approved business reports before distribution.

74. What Would You Include in a Power BI HR Attrition Report?

An attrition report should answer specific workforce questions while protecting employee information. The appropriate metrics depend on how the organisation defines departures, headcount and the reporting population.

Useful measures may include starting headcount, ending headcount, average headcount, employee departures and an attrition rate for the reporting period.

One possible business definition is:

Attrition Rate % =
DIVIDE(
    [Employee Departures],
    [Average Headcount]
)

The numerator and denominator must follow the employer’s agreed methodology. Some organisations distinguish voluntary, involuntary, regretted or other departure categories.

For analysis, suitable views may show trends over time, department-level rates and attrition by tenure band where these breakdowns are sufficiently reliable and appropriate for the intended audience.

Privacy consideration: Small groups can make individual employees identifiable even when names are removed. Restrict sensitive employee-level details, apply suitable permissions and evaluate whether aggregation or suppression is needed.

The report should help authorised HR users investigate patterns rather than imply that correlation between a demographic or employment attribute and departure rate proves causation.

75. A Company Wants to Replace Multiple Excel Reports With One Power BI Reporting Solution. How Would You Approach It?

I would begin with the existing business processes rather than immediately combining all the Excel files. Different teams may use similar-looking reports with different calculation rules, reporting periods or definitions.

Phase 1: Discover the reporting requirements. Identify report owners, source systems, key metrics, update frequency, permissions and recurring reporting problems. Document any conflicts in metric definitions.

Phase 2: Assess data quality. Review column structures, duplicate records, inconsistent identifiers, missing values and historical changes. Determine whether the Excel files are authoritative sources or outputs of other systems.

Phase 3: Build a suitable data model. Where the analytical requirements justify it, create shared dimensions and fact tables with clear granularity. Define governed measures instead of separately recreating every spreadsheet formula.

Phase 4: Validate and release. Reconcile important metrics with approved source reports, test refresh behaviour and permissions, conduct user acceptance testing and establish a controlled publishing process.

Phase 5: Maintain ownership. Document the solution, assign responsibility for failures or metric changes and train report consumers on the new reporting workflow.

A unified Power BI solution can reduce repeated manual reporting, but it does not automatically create a single source of truth. Consistency depends on agreed business definitions, trustworthy sources and ongoing governance.

What to Review Before a Power BI Interview

The most useful preparation depends on the advertised responsibilities. A reporting analyst may need to explain how they work with business stakeholders, while a Power BI developer may be expected to demonstrate DAX, modelling and deployment experience. Use the following checklist to identify gaps rather than treating every topic as equally important.

How to Discuss a Power BI Project You Have Worked On

An interviewer may ask about a dashboard or semantic model listed on your resume. A convincing explanation should distinguish your actual work from what the wider team delivered.

Start with the business question, identify the data sources and describe any important quality issues. Then explain the model, the calculations used for the main metrics, the reporting interface and how you checked the results.

For example, someone who built a sales performance report could explain why they used shared Date and Product dimensions, how revenue and target measures were calculated, and what checks established that totals matched the source records.

Be prepared to discuss limitations. If the project used manually updated Excel data, explain that dependency accurately rather than presenting the report as a fully automated enterprise platform.

Power BI vs Tableau vs Excel: Key Differences for Interviews

Power BI, Tableau and Excel can all be used for data analysis, but they differ in their modelling environments, workflows and typical organisational uses. An interview comparison should consider the actual requirements rather than declaring one product universally better.

Which Tool Is Better for Business Intelligence?

The appropriate choice depends on data sources, existing technical skills, required analytical features, governance, integration needs and total cost. Power BI may fit organisations using Microsoft data and productivity services, while Tableau may suit teams with particular visual analysis requirements. Excel remains useful for spreadsheet-based modelling, ad hoc analysis and established business workflows.

These tools can also complement one another. A team may use Excel for selected data preparation or planning activities and Power BI for governed reporting. The final decision should be based on tested requirements and available capabilities, not broad assumptions about which platform always handles more data or produces better visuals.

A Final Power BI Interview Exercise

Imagine receiving three datasets: sales transactions, product details and monthly regional targets. Before building a report, identify what each row represents, how the tables relate, whether the targets can be compared at product level, and which calculations should respond to report filters.

Then explain how you would validate revenue totals, handle missing data, restrict access to sensitive information and select visuals for an executive summary. Being able to work through these decisions demonstrates a broader understanding of Power BI than memorising feature definitions alone.

FAQs

What Power BI topics should freshers prepare for interviews?

Freshers should focus on Power BI Desktop, Power Query, basic DAX functions, data modelling, relationships, slicers, filters and common visualisations. They should also understand the difference between Import and DirectQuery modes. Employers may ask candidates to explain a simple dashboard project, including how they cleaned data, created measures and checked the accuracy of their reports.

Which DAX functions are commonly asked in Power BI interviews?

Frequently discussed DAX functions include SUM, SUMX, CALCULATE, FILTER, RELATED, LOOKUPVALUE, DIVIDE and TOTALYTD. For experienced roles, questions may also cover ALL, ALLSELECTED, REMOVEFILTERS and time-intelligence functions. Understanding row context, filter context and how measures behave under different filters is more important than memorising function names.

Is SQL knowledge necessary for a Power BI developer interview?

SQL knowledge is valuable for many Power BI developer positions, particularly those involving relational databases. Interviewers may assess joins, aggregations, filtering, subqueries and query optimisation. However, SQL requirements vary by employer and role. Candidates should check the job description to determine whether advanced SQL skills are expected alongside Power BI and DAX.

How should experienced candidates prepare for scenario-based Power BI interview questions?

Experienced candidates should practise explaining real reporting problems and their solutions. Important scenarios include slow reports, incorrect DAX totals, row-level security, incremental refresh, many-to-many relationships and data-quality issues. A strong response explains the business requirement, investigation process, technical decisions, trade-offs and how the final result was validated.

Can I clear a Power BI interview without professional project experience?

Candidates applying for entry-level positions may be considered without professional Power BI experience, depending on the employer's requirements. Building an independent project using realistic sample data can help demonstrate relevant skills. Be prepared to explain the data sources, Power Query transformations, model relationships, DAX measures, report design and validation methods. Present personal or academic projects accurately rather than describing them as professional assignments.

Kishan Mohan

Kishan is a digital content strategist passionate about helping professionals land their next great role. With extensive experience in SEO and career-focused content, Kishan creates actionable resources that guide job seekers through every stage of their career journey.