Power BI Interview Questions
and Answers (2026)

First I find where the differences are, such as different spellings, date formats or codes for the same thing. For example, the same city may appear as Pune, pune and PUNE. I fix this in Power Query by cleaning the text, correcting data types and mapping values with a lookup table. Then I check my totals against the source and share the cleaning rules, so the business agrees on how the data was handled.

A calculated column is worked out row by row when the data refreshes and is stored in the model, so it uses memory. A measure is worked out when a visual uses it and changes with the filters. Use a column when you need to slice or filter by the value, and a measure for totals, ratios and percentages.

I start with Performance Analyzer to find the slowest visual. Then I remove columns and rows the report does not need, reduce the number of visuals on a page, simplify heavy measures and check that the model is a clean star schema. If the source supports it, I also use query folding or aggregations. For example, a main page with twenty visuals often becomes much faster when it is cut down to the eight that people actually use.

I create roles in Power BI Desktop with DAX filters, for example one role per group such as Region equals North. When there are many groups, I prefer dynamic security. I keep a table that maps each user email to the data they can see, and use one role that reads the signed in user. After publishing, I add people or groups to the roles in Power BI Service and test with the View as option.

First I ask what real time means for them, seconds or a few minutes. For a few minutes, DirectQuery with automatic page refresh usually works. For true streaming data, such as sensor or app events, I would use Real-Time Intelligence in Microsoft Fabric. The older Power BI streaming and push datasets are being retired, and creating new ones will not be supported after 31 October 2027, so I would not start a new solution on them. I also explain the cost and speed trade off, because the faster the refresh, the heavier the load on the source.

Pick one real measure and explain it in this order: the business question, the formula in plain words, and what changed because of it. For example, I wrote a measure that listed customers who bought last year but not this year, using CALCULATE and a filter on the previous year. The sales team used it to contact lost customers, which gave them a clear action list every month.

I keep one fact table in the middle with numbers and keys, and connect it to small dimension tables such as date, product, customer and region. Each relationship is one to many, from the dimension to the fact, with a single filter direction. I avoid linking dimensions to each other, hide key columns and add a proper date table.

I connect to each source in its own query and clean it separately, removing extra columns, fixing data types and trimming text. For example, orders may come from SQL Server, targets from Excel and customers from a CRM export. Then I use Merge or Append to combine them. I keep steps that can fold back to the source first, name every query clearly, switch off loading for staging queries and use parameters for server names and file paths.

Import copies the data into the Power BI model. It is fast, but the data is only as fresh as the last refresh, and the model has a size limit. DirectQuery leaves the data at the source and sends a query each time, so data is fresh but reports can be slower. I choose Import by default, and DirectQuery when the data is very large or must be close to real time.

I load only the columns and rows the report needs, use the right data types and reduce columns with many unique values, for example by splitting a date time column. I use a star schema, incremental refresh and aggregation tables. When the data is in Fabric, I also look at Direct Lake.

In Power Query I create two date time parameters named RangeStart and RangeEnd and filter the date column with them. Then I set the policy in Power BI Desktop, for example store five years of data and refresh only the last seven days. After publishing, the first refresh loads everything, and later refreshes load only the recent part. The source should support query folding for this to work well.

I connect with the right connector for the warehouse, such as Azure Synapse, Snowflake, BigQuery or a Fabric warehouse. I choose Import, DirectQuery or Direct Lake based on data size and freshness. I create clean views in the warehouse for Power BI to read, keep heavy transformations inside the warehouse and use a service account for connections.

I use a layered setup. Shared and certified semantic models sit in a central place, reports connect to them, and separate workspaces are used for development, testing and production. I add Row Level Security and sensitivity labels, size the capacity for the expected load and set up monitoring so problems are seen early. For example, ten regional teams can build their own reports on one certified sales model, so every region sees the same numbers.

I set naming standards and clear owners for every workspace, and promote or certify trusted semantic models. I use tenant settings, sensitivity labels and the lineage view to track where data comes from. I also check usage reports, so unused content can be reviewed and removed.

I make sure the capacity is the right size and watch its usage metrics. I reuse shared semantic models instead of many copies, use incremental refresh and aggregations, and schedule heavy refreshes outside busy hours. I also train developers on best practices and review slow reports with Performance Analyzer.

For usability, I ask which decisions the executives make, then show five to eight key numbers at the top as cards with a comparison to target. Details go on drill through pages. For performance, I keep visuals few and the data summarised. For security, I apply Row Level Security where needed and share the report through an app with proper roles.

I first open the report myself and find the slow page. Then I use Performance Analyzer to see whether the time goes to the DAX query, the visual drawing or something else. I fix the cause: rewrite heavy measures with variables, cut extra visuals, remove unused columns, or tune the source for DirectQuery. For example, a slow card visual often turns out to be one measure that loops over the full sales table. At the end I tell the stakeholder what changed.

I pick the simplest option that meets the need. Automatic page refresh on a DirectQuery model works for data that changes every few seconds or minutes. Real-Time Intelligence in Microsoft Fabric suits event data such as sensors or app logs. The older Power BI streaming and push datasets are being retired, so I avoid them for new projects. If near real time is enough, an Import model with frequent scheduled refresh is easier and cheaper.

I update the source step in Power Query and keep the final column names the same as before, renaming new columns back to the old names if needed. If the source location changes, I use parameters so I only change it in one place. I work on a copy first, check that all measures still work, and move the update through a deployment pipeline if one is available. For example, if a column called Amt becomes Amount at the source, I rename it back to Amt in Power Query, and no visual breaks.

You can share a report directly with people who have access, or publish an app from a workspace for a wider group. You can also embed reports in Teams or SharePoint, or send exports and subscriptions as PDF or PowerPoint. Row Level Security and sensitivity labels control what each person sees. Publish to web should be used only for public data, never for private company data.

One simple way finds the highest salary first, then the highest one below it.

SELECT MAX(Salary) AS SecondHighestSalary
FROM Employees
WHERE Salary < (SELECT MAX(Salary) FROM Employees);

Another way is to use DENSE_RANK ordered by salary in descending order and pick rank two. This also works for the third or fourth highest.

SELECT DISTINCT Salary
FROM (
    SELECT Salary, DENSE_RANK() OVER (ORDER BY Salary DESC) AS rnk
    FROM Employees
) t
WHERE rnk = 2;

I read the execution plan to see where time is spent. Then I select only the columns I need instead of using SELECT *, filter early with WHERE, and add indexes on the columns used in joins and filters. I avoid wrapping indexed columns in functions, and replace repeated subqueries with a CTE or a temporary table.

I keep a security table that maps each user to the data they can access, such as regions. For DirectQuery, the database can apply Row Level Security using the signed in user. For Import mode, I bring the same mapping table into Power BI and apply the filter with Power BI Row Level Security, since the data is no longer read live from the database.

I first find missing values with IS NULL. Then I decide for each column: replace with a default using COALESCE, such as 0 or Unknown, remove the rows, or leave them as null when missing has a meaning. I avoid turning missing values into zero for things like averages, because it changes the result, and I document the choice.

I use a star schema with fact tables for events like sales and dimension tables for date, product, customer and region. Each table gets a simple key, and the date dimension is built once and reused. I create views for Power BI, use consistent names, and add summary tables for very heavy reports.

First I create a measure for last year’s sales using SAMEPERIODLASTYEAR on a proper date table. Growth is this year’s sales minus last year’s sales, divided by last year’s sales. I use DIVIDE for the last step, so the result is blank instead of an error when last year has no sales. Then I format the measure as a percentage.

Sales LY = CALCULATE([Total Sales], SAMEPERIODLASTYEAR('Date'[Date]))
YoY Growth % = DIVIDE([Total Sales] - [Sales LY], [Sales LY])

CALCULATE changes the filters under which a calculation runs. FILTER goes through the rows of a table and returns only those that meet a condition. For a simple condition, CALCULATE alone is enough. When the condition needs a measure, such as customers whose sales are above 1000, I use FILTER inside CALCULATE.

Red Sales = CALCULATE([Total Sales], Product[Colour] = "Red")
Sales From Big Customers =
CALCULATE(
    [Total Sales],
    FILTER(VALUES(Customer[CustomerID]), [Total Sales] > 1000)
)

The easiest way is TOTALYTD. It adds up sales from the start of each year to the current date and starts again when a new year begins. It needs a proper date table that is marked as the date table in the model.

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

I find the slow measure with Performance Analyzer and DAX Studio. Then I use variables so values are calculated once, avoid looping over a large table when a simple SUM works, filter columns instead of whole tables, and use DIVIDE. If the logic does not need to change with filters, I move it to Power Query or the source.

I create a security table with user emails and the values they can see, such as region, and connect it to the right dimension. Then I create one role with a filter that compares the email column to USERPRINCIPALNAME(). Every user now sees only their own rows with a single role. I test it with the View as option before publishing.

[Email] = USERPRINCIPALNAME()

SUM adds up one column. SUMX is an iterator: it goes through a table row by row, calculates an expression for each row and then adds the results. Use SUMX when the value needs a row level calculation, such as quantity multiplied by price.

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

All three remove filters. ALL removes the filters from a table or columns. ALLEXCEPT removes every filter on a table except the columns you list. REMOVEFILTERS does the same job as ALL inside CALCULATE and reads more clearly. A common use is the percentage of total.

% of Total Sales =
DIVIDE([Total Sales], CALCULATE([Total Sales], ALL(Product)))

Filter context is the set of filters applied to a calculation by slicers, visuals, relationships and CALCULATE. A measure always runs inside a filter context. Row context means “the current row”, and it exists in calculated columns and inside iterator functions such as SUMX. A row context does not filter other tables by itself. CALCULATE can turn a row context into a filter context, which is called context transition.

RELATED brings a value from the one side of a relationship into the many side, when you are working row by row. For example, in a Sales table you can pull the product category from the Product table. It needs an existing relationship. RELATEDTABLE works in the other direction.

Product Category = RELATED(Product[Category])

Variables store a value once and reuse it, so the formula is easier to read and often faster, because the value is not calculated again and again. They also make a formula easier to debug.

YoY Growth % =
VAR CurrentSales = [Total Sales]
VAR LastYearSales =
    CALCULATE([Total Sales], SAMEPERIODLASTYEAR('Date'[Date]))
RETURN
    DIVIDE(CurrentSales - LastYearSales, LastYearSales)

Time intelligence functions such as TOTALYTD and SAMEPERIODLASTYEAR need a continuous date table. I create it with CALENDAR or CALENDARAUTO in DAX, or in Power Query, then add Year, Quarter and Month columns, mark it as the date table and connect it to the date column of the fact table.

Date = CALENDAR(DATE(2020, 1, 1), DATE(2026, 12, 31))

I use Append. Power Query matches columns by name and fills the missing ones with null. Before appending, I rename columns so they match, remove extra columns and set the same data types. If I need to bring columns side by side from another table, I use Merge with a common key instead.

First I check whether the repeated rows are really duplicates. Then I select the key columns and use Remove Duplicates. If I need to keep a particular row, such as the latest one, I sort the data first so that row comes first. Table.Buffer can help keep that order stable.

I change the type to Date, and when the format is different from my system settings I use the Using Locale option, so day and month are read correctly. For messy text, I split or clean it first and then convert. I check the Errors and replace or fix those values.

A good answer names the problem, the steps and the result. For example, a sales file had extra spaces, mixed city spellings, dates stored as text and blank rows. I trimmed and capitalised the text, mapped city names with a lookup table, converted the dates, removed blank rows and fixed the data types. The report then matched the finance totals.

I create a parameter in Manage Parameters, for example a start date or region, and use it in a filter step or in the source path. In Power BI Service, the value can be changed in the semantic model settings. For DirectQuery, M query parameters can be linked to a slicer field, so the user’s choice filters data at the source.

Append stacks tables on top of each other, so it adds rows. Use it for files with the same columns, such as monthly sales files. Merge joins two tables side by side using a key column, like a SQL join, and you choose the join type, for example Left Outer or Inner. Use it to add customer details to an orders table.

Query folding means Power Query turns your steps into one query that runs at the source, for example a SQL query, so the database does the heavy work. It makes refresh faster and is needed for incremental refresh to work well. You can right click a step and check View Native Query. Some steps break folding, so I place foldable steps such as filters and column removal first.

Unpivoting turns columns into rows. Spreadsheets often have one column for each month, which is easy to read but hard to filter in Power BI. After unpivoting, you get one column for Month and one for Value, which works much better in visuals and DAX. Our Power BI query guide shows an example.

M is the language of Power Query. It prepares and cleans the data and runs when the data refreshes. DAX is the language of the data model. It creates measures and calculated columns and runs when a report uses them. A simple way to say it is: prepare with M, analyse with DAX.

Duplicate makes a full copy of a query with all its steps, and the copy is independent. Reference creates a new query that starts from the output of the original, so any change in the original flows into it. I use Reference when I want to create several tables from one cleaned source without repeating the cleaning steps.

I share dimension tables such as date, product and customer across the fact tables, and connect each fact table to those dimensions with one to many relationships. I do not connect fact tables directly to each other. I keep filters in a single direction and write separate measures for each fact table.

I choose a star schema by default because it has fewer joins and is faster and simpler for Power BI. A snowflake schema may be fine when a dimension is very large or the source is already split into many tables. Even then, I often flatten it in Power Query to keep the model simple.

A circular dependency appears when relationships form a loop, or when calculated columns depend on each other. I fix it by removing or deactivating one relationship, using USERELATIONSHIP in a measure when I need the inactive one, or reshaping the model into a star schema. I also replace calculated columns with measures or Power Query steps where possible.

I use a star schema, remove unused columns, set the correct data types and reduce columns with many unique values. I prefer measures to calculated columns, avoid two way filters unless needed, hide technical columns and use a proper date table. For very large data, I add aggregation tables.

I add a bridge table that holds the unique values of the shared column, and connect both tables to it with one to many relationships. This is cleaner and faster than a direct many to many relationship. I keep the filter direction single and test the results to confirm the numbers are correct.

Cardinality describes how rows in two tables match: one to many, many to one, one to one or many to many. Cross filter direction decides how filters flow. With a single direction, filters flow from the one side to the many side. With both directions, filters flow each way. I use single direction by default, because both directions can slow the model and create unclear results.

A hierarchy is an ordered set of related columns, such as Country, State and City, or Year, Quarter and Month. You create it in the model by dragging one field onto another. In a visual, it lets users drill down level by level.

Between two tables, only one relationship can be active at a time. The others are inactive and shown as dotted lines. You can use an inactive one inside a measure with USERELATIONSHIP. A common case is a Sales table with both an Order Date and a Ship Date linked to one Date table.

Sales by Ship Date =
CALCULATE([Total Sales], USERELATIONSHIP(Sales[ShipDate], 'Date'[Date]))

I install an on premises data gateway on a machine that can reach the SQL Server and sign in with the right account. In Power BI Service, I connect the semantic model to the gateway, enter the data source credentials and set the refresh schedule. I also turn on failure notifications, so the owners know when a refresh fails. For example, a nightly refresh at 2 AM means the team sees fresh numbers when they start work.

Free is for building reports in Power BI Desktop and for personal use. Pro lets people publish and share, and viewers also need Pro unless the content sits on a capacity. Premium Per User gives most Premium features to each user, and people who view that content usually need Premium Per User too. A Fabric capacity of F64 or above, or a Premium capacity, lets free users view content, but the authors still need Pro.

Note: Licensing rules and prices change often. Check Microsoft’s current Power BI licensing page before your interview and say in the interview that you are going by the latest documentation.

I use workspace roles to control who can edit and publish, and Row Level Security to control which rows each person sees. I can also limit access to certain tables or columns with object level security. Sensitivity labels, app audiences and build permissions on semantic models add further control.

I can invite the client as a guest user, and depending on the licence, they may need their own or may be able to view content in a workspace on a Fabric F64 or Premium capacity. I can use Power BI Embedded to place reports inside a portal, where the app handles access. Another option is to send exports or email subscriptions as PDF or PowerPoint. I do not use Publish to web for private data.

I give access to security groups from Microsoft Entra, not to individuals, and keep the number of admins small. I use the Admin, Member, Contributor and Viewer roles carefully, create separate workspaces for each team and each stage, and share finished content through apps. I also review access on a regular schedule. For example, when someone moves to another team, removing them from one group updates all their access at once.

An app is a packaged set of reports and dashboards that you publish from a workspace to a wider audience, with its own audience settings. Viewers get a clean, read only view, and changes appear only when the owner updates the app, so the author can keep working safely in the workspace. Sharing a report directly gives specific people a link and is fine for small groups, but it is harder to manage at scale.

A subscription sends a snapshot of a report page by email on a schedule, for example every Monday morning. A data alert notifies you when a value on a dashboard tile goes above or below a limit you set, such as daily sales dropping under a target.