Power BI Interview Questions (2026)

Power BI is a Microsoft analytics platform for connecting data, shaping it, building semantic models, writing DAX measures, and publishing reports and dashboards.

The interview answer should go beyond visuals. Mention Power Query for preparation, semantic models for business logic, DAX for measures, the Power BI Service for sharing and refresh, and security for controlled access.

A semantic model is the shared data model behind reports. It contains tables, relationships, measures, hierarchies, security rules, and metadata used by visuals and users.

A strong semantic model gives users trusted definitions. Revenue, active users, margin, and churn should not be redefined separately in every report page.

A star schema uses fact tables for measurable events and dimension tables for filtering and grouping. It usually gives Power BI clearer relationships and faster, safer DAX.

A flat table may work for a small report, but it often creates duplicate logic, wide models, and confusing filters. In interviews, define the fact grain first, then dimensions such as date, product, customer, and region.

Fact tables store numeric events or transactions. Dimension tables store descriptive attributes used to filter, group, and label those facts.

Fact tables usually contain keys, dates, and measures such as amount or quantity. Dimension tables contain fields such as customer name, product category, region, and channel.

DAX is the formula language used to create measures, calculated columns, calculated tables, and security filters in Power BI semantic models.

DAX is strongest for calculations that respond to filters: sales year-to-date, percent of total, active customers, conversion rate, or rolling averages. It is not a replacement for all data cleaning.

Use a measure when the result must change with filters, slicers, or visual context. Use a calculated column when you need a stored row-by-row value in the model.

Measures are usually better for aggregations and business metrics. Calculated columns can increase model size, but they are useful for grouping fields, relationships, or row-level labels.

Filter context is the set of filters applied to a DAX calculation from slicers, visuals, relationships, page filters, report filters, and functions such as CALCULATE.

If a card shows total sales for 2026 and Region = West, that filter context changes the rows SUM sees. Most DAX interview problems are really filter context problems.

Row context is the current row being evaluated, usually inside a calculated column or iterator function such as SUMX, FILTER, or ADDCOLUMNS.

Row context does not automatically filter the whole model like slicers do. Context transition through CALCULATE can convert row context into filter context, which is why CALCULATE is tested often.

CALCULATE evaluates an expression in a modified filter context. It can add, remove, or replace filters and can trigger context transition.

Interviewers use CALCULATE to test whether you understand why a measure changes under slicers. Explain the base expression first, then each filter modifier.

Power Query should handle repeatable data preparation such as changing types, removing bad rows, splitting columns, merging sources, unpivoting data, and shaping tables before load.

Use Power Query when the transformation is row-level preparation that should happen once at refresh. Use DAX when the calculation depends on report filters or user interaction.

Query folding means Power Query can translate transformation steps back to the source system, so the source does filtering, joins, and calculations before data reaches Power BI.

Folding can make refresh faster and reduce memory use. Breaking folding too early can force Power BI to pull more data than needed. In interviews, mention View Native Query or query diagnostics.

Relationships define how filters move between tables. Cardinality tells Power BI whether the relationship is one-to-many, many-to-one, one-to-one, or many-to-many.

Most models should filter from dimensions to facts through one-to-many relationships. Many-to-many and bidirectional filters can be valid, but they make totals harder to reason about.

Import stores data in the Power BI model. DirectQuery sends queries to the source at interaction time. Live Connection connects to an existing semantic model or Analysis Services model.

Import is usually fastest for users. DirectQuery helps when data must stay in the source or be near current, but performance depends on the source and model design. Live Connection centralizes a shared model.

Row-level security, or RLS, restricts which rows a user can see based on DAX filters and user identity.

RLS should be designed in the model and tested as different users. Workspace access and report sharing do not automatically filter rows by region, manager, or account assignment.

Incremental refresh loads only new or changed partitions instead of refreshing the full dataset every time.

It reduces refresh time and source load for large tables. It works best when the source can filter by date and query folding is preserved for the RangeStart and RangeEnd parameters.

The on-premises data gateway lets the Power BI Service securely refresh or query data sources that are inside a private network.

the question expects you to mention credentials, gateway cluster health, data source mapping, privacy levels, and who owns gateway maintenance.

A workspace is a collaboration area for creators and admins. An app is a packaged way to distribute approved reports and dashboards to business users.

Use workspaces for building and managing content. Use apps for controlled consumption. Do not make every viewer a workspace member unless they need creator-level access.

Dataflows let teams prepare and reuse Power Query transformations in the service so multiple datasets can share cleaned entities.

They are useful when several reports repeat the same extraction and cleaning logic. The interview signal is reuse and ownership, not simply moving every query out of Desktop.

Performance Analyzer records how long visuals spend on DAX query, visual display, and other processing steps.

Use it to find the slow visual first. Then inspect DAX, model design, source mode, visual complexity, and filter interactions. It is a diagnostic tool, not the fix itself.

Drillthrough pages show detail for a selected entity. Tooltip pages show extra context on hover. Bookmarks save report states for guided navigation or storytelling.

Use these when they reduce clutter and answer natural follow-up questions. Do not use bookmarks to hide poor model design or create fragile button-heavy reports.

Use a star schema: fact_sales at order-line grain, dimensions for customer, product, date, region, and channel, with measures for sales, quantity, margin, and conversion where needed.

Avoid one wide flat table if the report will grow. The grain, mark a date table, hide raw keys, expose clean dimension fields, and keep business logic in measures.

Set data types, standardize dates, remove or flag invalid rows, trim text, dedupe on a business key, and keep a rejected-row path if users need auditability.

Do the repeatable row-level cleanup in Power Query, not in DAX measures. If the source is a database, preserve query folding as long as possible.

Create a continuous date table, mark it as a date table, relate it to fact date columns, and use it for slicers, hierarchies, and time intelligence measures.

A date table includes useful columns such as year, quarter, month, month sort, week, and fiscal period. Do not rely on auto date tables for serious models.

Use a base sales measure and a marked date table. The measure depends on a proper date relationship and the current filter context.

the question needs to hear why the date table matters. Without a clean date table and relationship, time intelligence can produce confusing results.

Use DIVIDE and remove only the filter you want to ignore. Keep other report filters intact unless the business definition says otherwise.

ALL removes filters broadly. ALLSELECTED often matches user-facing percent of selected total. The right answer depends on whether the denominator should respect slicers.

Use a date window over the date table, then average the measure inside that window. Confirm whether days with no sales should count as zero or be excluded.

The business definition matters. A rolling average over calendar days and a rolling average over days with transactions are not the same.

Use SELECTEDVALUE or CONCATENATEX in a measure and bind it to the visual title through conditional formatting.

Dynamic titles help users understand filter state. Keep the wording short and include a fallback when multiple values are selected.

Create a security mapping table with user principal name and account or team key, relate it to the model, then define an RLS rule using USERPRINCIPALNAME.

Test as role and test with real users. Also confirm build permission, export behavior, and whether users can access the underlying semantic model elsewhere.

Check credentials, gateway status, source availability, changed schema, privacy levels, timeout, refresh history, and whether the dataset exceeded limits.

A practical answer includes communication. If users depend on the report, mark the freshness issue, alert the owner, and say whether the last successful refresh is still usable.

Keep the model simple, reduce visuals per page, use aggregations where possible, push filters to dimensions, avoid complex DAX over huge tables, and make sure the source can serve interactive queries.

DirectQuery is not a shortcut around modeling. It moves pressure to the source. the question expects you to discuss source indexes, query limits, visual count, and user concurrency.

Create RangeStart and RangeEnd parameters, filter a date column in Power Query, preserve query folding, define archive and refresh windows, then publish and test refresh in the service.

The date filter must fold to the source for large tables. If folding breaks, Power BI may still pull too much data before filtering.

Use Performance Analyzer to find the slow visual, then inspect DAX query time, visual rendering time, model relationships, visual count, custom visuals, and source mode.

Fixes may include simplifying DAX, reducing high-cardinality visuals, improving model design, pre-aggregating, removing unused columns, or splitting a crowded page.

Find the grain mismatch, create a bridge table if needed, keep filters single-direction where possible, and rewrite measures only after the model is corrected.

Many-to-many is often a modeling smell. Do not hide the issue with visual-level filters. Explain why duplicates appear and how the bridge table controls filter paths.

Publish to a workspace, manage creator access through workspace roles, distribute approved content through an app, and apply RLS or model permissions where row access differs.

Do not make every viewer a workspace member. Separate content editing from consumption. Also define who owns refresh, app updates, and support questions.

Check row counts, totals against source, date ranges, duplicate keys, blank dimensions, relationship integrity, measure definitions, and refresh status.

For finance or sales reports, reconcile numeric totals against a system of record. For operational reports, check freshness and missing segments.

Inventory current logic, define trusted metrics, model the data, replace manual steps with Power Query, rewrite calculations as measures, validate against Excel, then publish with access control.

Do not copy every Excel tab into visuals. Use the migration to clean definitions and remove manual steps that caused errors.

Use a tooltip page when users need extra context on hover, such as trend, mix, rank, or metric definition, without cluttering the main page.

Tooltips should be fast and focused. Do not hide critical information only in tooltips because mobile and accessibility needs may differ.

A dedicated measures table keeps business measures organized and easier to find, especially when fact tables have many hidden numeric columns.

It does not change calculation behavior by itself. The value is model usability and governance. Group measures in folders when the model grows.

Check color contrast, keyboard order, alt text, readable labels, clear titles, focus order, and whether the report works without color-only meaning.

Accessibility is part of report quality. It also improves executive scanning because labels, contrast, and layout become clearer for everyone.

Use separate development, test, and production workspaces or deployment pipelines, validate data source bindings, test RLS, and document release changes.

The production-ready answer includes rollback, owner approval, and checking that scheduled refresh and app audience settings remain correct after deployment.

Inspect the measure definition, filter context, relationships, visual filters, slicer table, and whether the denominator should respect the slicer.

Many percent-of-total bugs come from removing too many filters or not removing the right one. Recreate the measure on a small table so the filter behavior is visible.

Check whether the columns are needed for relationships, grouping, or sorting. Move preparation to Power Query or use measures where the value is aggregate-driven.

Calculated columns are stored. High-cardinality text or row-level calculations can increase model size. Remove unused columns and keep business metrics as measures when possible.

Map the filter paths, remove unnecessary bidirectional filters, use a bridge table where needed, and keep dimensions filtering facts through clear paths.

Bidirectional filtering can solve specific problems, but it can also create ambiguous paths and unexpected totals. Explain the filter flow with the model diagram.

Check whether the new step broke query folding. Move foldable filters earlier, remove unsupported transformations before filtering, or push logic into the source query if appropriate.

Use View Native Query or diagnostics to confirm. The goal is to avoid pulling a large source table locally before filtering it down.

Test as the user, inspect role filters, security mapping tables, relationships, app permissions, build permissions, and alternate reports using the same semantic model.

RLS bugs can come from model relationships or from permissions that let a user connect to the semantic model directly. Fix both the row filter and the sharing path.

Find whether the delay is source extraction, gateway, Power Query, model processing, or service capacity. Then reduce data pulled, preserve folding, add incremental refresh, or adjust capacity.

Also tell users whether the report is stale. A freshness banner or status table can prevent people from making decisions on outdated data.

Check gateway service status, machine health, credentials, network access, gateway cluster members, data source mapping, and refresh history.

If the report is critical, fail over to another gateway cluster member where configured. After recovery, review monitoring and ownership so the issue is not found by report users first.

Reduce visual count, simplify measures, add source indexes or aggregations, filter early, avoid high-cardinality tables, and consider Import or composite models if freshness allows it.

DirectQuery performance is shared between Power BI design and source system health. If the source cannot answer interactive queries quickly, the report design must change.

Create a proper date table, mark it, relate it to fact dates, add fiscal columns if needed, and rewrite measures against the shared date table.

This improves consistency across visuals and avoids hidden date tables that are hard to manage in serious models.

The join likely matched multiple rows on the lookup side or used the wrong grain. Check uniqueness of join keys before merging.

Fix by deduplicating the lookup table at the right grain, aggregating before the merge, or modeling the relationship instead of physically merging everything.

Clarify whether they need a Power BI dashboard, a report, or an app. A dashboard is a single canvas of pinned tiles, while reports provide multi-page interactive analysis.

Use the term the business uses, but design the right artifact. For most analysis workflows, a report packaged in an app is better than a dashboard alone.

Check app audience membership, report and semantic model permissions, RLS role membership, licensing, workspace state, and whether the app was updated after changes.

Access problems are not always RLS. Separate content visibility from row visibility and from licensing.

Check the target grain. Targets may be monthly by region, while sales are daily by order. The measure must align grain before comparing actuals and targets.

Do not join target rows directly to transaction rows if it duplicates target values. Use a target fact table with date and region dimensions, then write measures at compatible grain.

Ask whether the result should change by slicer. If yes, it belongs in a measure and the issue is likely context, not the need for storage.

This follow-up tests whether the candidate knows row context, filter context, and why calculated columns are evaluated at refresh time.

Inventory is often semi-additive. It can be summed across products or locations, but not across time in the same way as sales.

Use last non-blank, average balance, or end-of-period logic depending on the business definition. Ask how the metric should behave over time before writing DAX.

Check whether customer_id is unique in the customer dimension and whether the sales table is at order, order line, or customer-day grain.

Wrong grain causes duplicate rows and wrong totals. Fix the model before fixing visuals.

Validate measures, compare against old numbers, test RLS, refresh production data, check app audiences, review performance, and document what changed.

Executive reports need boring reliability. A release checklist prevents a visual tweak from changing a trusted metric without review.

Split the page by user question, remove low-value visuals, use drillthrough or tooltips for detail, and reduce cross-filter interactions.

Many visuals mean many queries. Better report design often improves both speed and comprehension.

too many visuals changes Power BI decisions by affecting the chosen method, the failure mode, or the validation step. Reliable evidence comes from a metric, test result, query output, log, or review note.

Update the Power Query step, confirm business meaning, add source validation where possible, and communicate if historical values need conversion.

Do not only patch the immediate type error. Ask why the source changed and whether other reports depend on the same field.

Define an approved semantic model or certified dataset for shared metrics, document definitions, and migrate reports to that source where possible.

The goal is not to block every local report. It is to give shared metrics one trusted home so executives do not compare five versions of revenue.