Power BI is Microsoft's business intelligence tool and one of the most requested skills for data analyst and MIS jobs. These Power BI interview questions cover components, data loading and visuals for freshers, then data modelling, DAX, row-level security, performance and deployment for experienced Power BI developers.
30 questions · Updated
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
Power BI Desktop is the free Windows app for connecting to data, modelling and building reports.
Power BI Service is the cloud platform for publishing, sharing, dashboards, scheduled refresh and collaboration in workspaces.
Power BI Mobile shows reports on phones.
Inside Desktop, Power Query transforms data, the data model stores it, and DAX creates calculations.
A report is a multi-page, interactive view built from one semantic model (dataset), with filters, slicers and drill-down.
A dashboard exists only in the Power BI Service and is a single page of tiles pinned from one or more reports, used as a high-level overview.
Clicking a dashboard tile opens the underlying report.
Import loads a copy of the data into Power BI's in-memory engine, giving the fastest performance and full DAX features, but data is only as fresh as the last refresh.
DirectQuery sends queries to the source each time a visual loads, so data is current but performance depends on the source.
Live Connection connects to an existing Analysis Services or Power BI semantic model.
Composite models combine methods.
Power BI connects to files (Excel, CSV, JSON, PDF), folders, databases (SQL Server, PostgreSQL, MySQL, Oracle), cloud warehouses (Azure Synapse, Snowflake, BigQuery, Databricks), online services (SharePoint, Dynamics 365, Salesforce, Google Analytics) and web APIs, through Get Data. Custom connectors and ODBC cover the rest.
Removing and renaming columns, changing data types, filtering rows, removing duplicates, splitting and merging columns, replacing values, unpivoting columns into rows, grouping and aggregating, merging queries (like joins) and appending queries (stacking tables), and adding custom or conditional columns. Each step is recorded and repeats on every refresh.
Cardinality describes how rows match between tables: one-to-many (one product, many sales, the most common), one-to-one or many-to-many.
Cross-filter direction sets which way filters flow; single direction from the dimension (one side) to the fact table (many side) is recommended.
Bi-directional filtering can cause ambiguous results and slow performance, so it is used only when needed.
Use bar or column charts to compare categories, line charts for trends over time, cards and KPI visuals for single numbers, tables and matrices for detail, maps for geographic data, scatter charts for relationships, and waterfall charts to explain changes. Avoid too many pie charts and 3D effects, keep a consistent colour scheme, and give every visual a clear title.
Slicers are visuals on the report canvas that users click to filter other visuals, which makes filtering obvious and easy.
The Filters pane provides filters at visual, page and report level, which can be visible, locked or hidden.
Slicers can be synced across pages, and edit interactions controls which visuals each slicer or chart affects.
Drill-down moves through levels of a hierarchy within the same visual, such as year to quarter to month or country to state to city.
Drill-through opens a separate detail page filtered to the selected item, such as right-clicking a customer on a summary page to see a customer detail page.
Both let users explore details without cluttering summary pages.
Publish from Power BI Desktop to a workspace in the Power BI Service.
Share through apps, which package reports and dashboards for an audience, through workspace roles, or direct sharing links.
Sharing usually requires Power BI Pro or Premium Per User licences, or content in a Premium or Fabric capacity, where free users can view.
Publish to web makes a report public, so it must never be used for sensitive data.
Bookmarks save the current state of a report page, such as filters, slicers, sorting and which visuals are visible. Combined with buttons, they create interactive experiences: switching between a chart and a table view, showing and hiding filter panels, guided storytelling and navigation between pages, making reports feel like apps.
Applied problems, trade-offs and questions about your own projects.
A star schema has central fact tables with numeric events such as sales transactions, linked to dimension tables that describe them, such as date, product, customer and region, with one-to-many relationships. Power BI's engine is designed for this shape: it makes DAX simpler, filters behave predictably, and reports run faster than with one wide flat table or many-to-many relationships.
A calculated column is computed row by row when the data is refreshed and stored in the model, so it uses memory and can be used in slicers and rows.
A measure is calculated at query time based on the current filter context, such as Total Sales = SUM(Sales[Amount]), and does not store values.
I use measures for aggregations and keep calculated columns for row-level attributes needed for filtering.
CALCULATE evaluates an expression in a modified filter context, which is the most important concept in DAX.
For example, North Sales = CALCULATE([Total Sales], Region[Name] = "North") always shows North sales regardless of the region slicer.
It is combined with functions such as ALL, REMOVEFILTERS, FILTER and time intelligence functions like DATESYTD and SAMEPERIODLASTYEAR.
I create a dedicated date table covering all dates, mark it as a date table, and relate it to the fact tables.
Then I write measures such as YTD Sales = TOTALYTD([Total Sales], 'Date'[Date]), Last Year Sales = CALCULATE([Total Sales], SAMEPERIODLASTYEAR('Date'[Date])) and growth percentage with DIVIDE to avoid division-by-zero errors.
Relying on auto date/time creates hidden tables and is less flexible.
Row context means a formula is evaluated row by row, as in calculated columns and iterator functions such as SUMX, where you can refer to values in the current row.
Filter context is the set of filters applied to a calculation, from slicers, rows and columns of a visual and CALCULATE.
Context transition, which happens when CALCULATE is used inside row context, turns the current row into a filter.
Iterators evaluate an expression for each row of a table and then aggregate the results.
SUMX(Sales, Sales[Quantity] * Sales[Price]) multiplies quantity and price per row before summing, which SUM alone cannot do.
AVERAGEX, MINX, MAXX, COUNTX and RANKX work the same way.
Iterating over large tables can be slow, so iterate over the smallest table possible.
ALL removes filters from a table or columns and can also return all rows as a table, used for calculations such as percentage of total: DIVIDE([Sales], CALCULATE([Sales], ALL(Product))).
ALLEXCEPT removes all filters from a table except on the columns listed.
REMOVEFILTERS only removes filters inside CALCULATE and makes the intention clearer.
ALLSELECTED keeps filters from outside the visual, such as slicers.
RELATED follows a relationship from the many side to the one side to fetch a single value, such as getting the product category into the sales table in a calculated column. RELATEDTABLE goes from the one side to the many side and returns a table of related rows, such as counting the sales rows for each product with COUNTROWS(RELATEDTABLE(Sales)).
Variables, declared with VAR and returned with RETURN, store intermediate results so a formula is easier to read and debug, and each value is calculated only once, which improves performance.
For example, a growth measure can store current sales and last year's sales in variables and then return DIVIDE(current - previous, previous).
Variables are evaluated in the context where they are defined.
What-if parameters create a slider and a table of values that measures can use, such as testing how profit changes with different discount percentages. Field parameters let users switch which measure or dimension a visual shows, for example choosing between sales, profit and quantity, or between region and product, with one slicer instead of building several visuals.
Calculation groups apply the same logic to many measures without duplicating them.
For example, one calculation group with items such as Current, MTD, YTD, Previous Year and YoY % can be applied to sales, profit, quantity and every other measure, instead of writing five versions of each.
They can be created in Power BI Desktop's model view or with Tabular Editor.
System design, deep internals, leadership and tough follow-ups.
Row-level security restricts which rows a user can see in the same report.
In Desktop I create roles with DAX filters, for example [Region] = "North", or dynamic RLS using USERPRINCIPALNAME() matched against a user-to-region mapping table.
In the Service I assign users or groups to roles and test with "View as".
Workspace admins and members bypass RLS, so viewers should get the Viewer role.
I use Performance Analyzer to find slow visuals and DAX Studio to examine queries.
I reduce the model by removing unused columns and rows, use a star schema, avoid high-cardinality columns and bi-directional relationships, replace calculated columns with measures or Power Query steps, and optimise DAX with variables.
I reduce the number of visuals per page and use aggregations or incremental refresh for large tables.
I publish reports to workspaces with clear roles, use deployment pipelines to move content from development to test to production, and share through apps for end users.
Gateways allow scheduled refresh from on-premises sources, and incremental refresh handles large tables.
I use parameters for environment settings, certified semantic models for a single source of truth, and sensitivity labels for governance.
Microsoft Fabric is an end-to-end analytics platform that brings data engineering, data warehousing, data science, real-time analytics and Power BI together on one storage layer, OneLake, using open Delta Parquet format.
Direct Lake mode lets Power BI semantic models read data straight from OneLake with near-import performance without scheduled refreshes.
Power BI Premium capacities have moved to Fabric capacities.
Composite models combine import and DirectQuery tables, or connect to other semantic models and extend them, in one model. Aggregation tables store pre-summarised data, such as sales by day and product, in import mode, while detailed data stays in DirectQuery; Power BI automatically uses the aggregation when a visual's query can be answered from it, giving fast reports over very large data.
Use Performance Analyzer to find slow visuals, then copy the query into DAX Studio and check server timings to see how much time is spent in the storage engine (fast, parallel data scans) versus the formula engine (single-threaded logic). Reduce formula engine work by using variables, avoiding complex iterators over large tables, filtering columns rather than whole tables in CALCULATE, and simplifying the model.
One huge flat table instead of a star schema, unnecessary bi-directional relationships, many-to-many relationships without care, snowflaked dimensions with long chains of relationships, missing date tables, high-cardinality text columns, calculated columns where measures or Power Query would be better, and inactive relationships used without USERELATIONSHIP. These cause wrong numbers and slow reports.
Power BI Embedded lets developers embed reports in their own applications using the JavaScript client library and the REST API, either for the organisation's users (user owns data) or for external customers (app owns data, with a service principal and capacity).
Row-level security uses effective identities to show each customer only their data.
Paginated reports handle printable, pixel-perfect documents such as invoices.
See all Data Scientist interview questions, covering Python, Pandas, NumPy, Statistics, Machine Learning and more.