Top 20 Power BI Interview Questions & Answers for Data Analysts (2026

Power BI shows up in almost every data analyst interview. Not as a theoretical topic. As a practical one. Interviewers want to know if you have actually built dashboards or just dragged a few charts onto a canvas.

I have compiled twenty questions that come up repeatedly. They cover DAX, data modeling, visualization, performance, and real-world scenarios. Each answer is practical, not textbook. These are the answers of someone who has used Power BI to solve actual business problems.

Power BI is a business intelligence tool for building interactive dashboards and reports. Excel is a spreadsheet application that can also create charts and perform analysis.

The key differences. Power BI handles much larger data volumes without slowing down. Excel struggles beyond a few hundred thousand rows. Power BI is designed for sharing and collaboration through the Power BI Service. Excel files are shared as attachments. Power BI has a proper data modeling layer with relationships between tables. Excel workbooks are flat or use VLOOKUP to connect sheets. Power BI uses DAX for calculations. Excel uses spreadsheet formulas.

Power BI is for building scalable, shareable analytical reports. Excel is for ad hoc analysis and data exploration. They complement each other. They do not compete.

Power BI has five core components. Power Query for data import and transformation. Cleaning, shaping, combining data. Power Pivot for data modeling. Creating relationships, writing DAX measures. Power View for visualization.

Building charts, tables, and interactive elements. Power BI Service for sharing online. Publishing reports, setting up refreshes, creating dashboards. Power BI Mobile for viewing on phones and tablets.

A data analyst uses Power Query and Power Pivot daily. The visualization layer is what stakeholders see. The Service is where collaboration happens.

This is the most common Power BI interview question. The answer reveals whether you understand the data model.

A calculated column is computed row by row during data refresh. The result is stored in the model. It takes up memory. It does not change when you apply filters or slicers. It is static.

A measure is computed at query time. It aggregates data on the fly. It responds to filters, slicers, and the context of the visual it is placed in. It does not take up storage space.

Use a calculated column when you need a static value per row that will be used for filtering or as an axis. Example. Categorizing customers as High, Medium, or Low based on total purchases. Use a measure when you need a dynamic aggregation. Example. Total sales, year-over-year growth, average order value.

The mistake beginners make is using calculated columns for everything. Measures are more flexible and memory-efficient for aggregations.

DAX stands for Data Analysis Expressions. It is the formula language in Power BI, Power Pivot, and Analysis Services. It is designed for data modeling and business calculations. It is similar to Excel formulas in syntax but fundamentally different in behavior. DAX works with tables and columns, not individual cells.

A common measure I create. Total Sales equals SUM of Sales Amount. But a better example that shows understanding is something context-aware. Sales Year over Year Growth equals:

1Sales YoY Growth =
2VAR CurrentYearSales = [Total Sales]
3VAR PreviousYearSales = CALCULATE([Total Sales], SAMEPERIODLASTYEAR(DateTable[Date]))
4RETURN
5DIVIDE(CurrentYearSales - PreviousYearSales, PreviousYearSales, 0)

This measure calculates the percentage change in sales compared to the same period last year. It uses variables for readability. It uses CALCULATE to modify the filter context. It uses SAMEPERIODLASTYEAR for time intelligence. It uses DIVIDE for safe division with a fallback value of zero. This is a realistic measure that appears in actual business reports.

Filter context is the set of filters applied to a calculation at any given moment. Filters come from visuals, slicers, rows and columns in a matrix, and the relationships in the data model. A measure like Total Sales evaluates differently depending on the filter context. In a bar chart with Region on the axis, it evaluates separately for each region. In a card visual with no filters, it evaluates for the entire dataset.

CALCULATE modifies the filter context. It takes an expression and a set of filters. It evaluates the expression in a context where the existing filters have been replaced or added to.

Example. Total Sales West equals CALCULATE of Total Sales with Region equals West. This measure always returns sales for the West region, regardless of what filters are applied to the report. If a user selects East in a slicer, Total Sales West still shows West sales because CALCULATE overwrites the slicer filter for Region.

CALCULATE is the most powerful DAX function. Understanding filter context and CALCULATE separates Power BI users from Power BI developers.

A star schema is a data model design with a central fact table surrounded by dimension tables. The fact table contains quantitative data like sales transactions, orders, or website visits. Each row is an event. Dimension tables contain descriptive attributes like customer details, product information, date attributes, and store locations.

The structure looks like a star. The fact table is the center. Dimension tables radiate outward, connected by relationships.

It is recommended because it improves performance. Queries run faster on star schemas. It simplifies DAX. Measures are easier to write when the model is well-structured. It reduces ambiguity. Relationships are clear. Filter direction is predictable. It is the industry standard for analytical data models.

A snowflake schema is a variation where dimension tables are further normalized into sub-dimensions. It saves storage but complicates the model and slows queries. Star schema is preferred in Power BI.

Direct many-to-many relationships in Power BI are possible but should be avoided when possible. They create ambiguity in filter direction and can return incorrect results.

The recommended approach is to use a bridge table. A bridge table sits between the two many-to-many tables and breaks the relationship into two one-to-many relationships.

Example. Students can enroll in multiple courses. Courses have multiple students. This is a many-to-many relationship. Create an Enrollments bridge table with StudentID, CourseID, and any enrollment-specific attributes like EnrollmentDate. The Students table has a one-to-many relationship with Enrollments. The Courses table has a one-to-many relationship with Enrollments. Filtering from Students to Courses flows through the bridge table correctly.

If you must use a direct many-to-many relationship, use it with caution. Understand the filter direction settings. Test thoroughly with known data. Verify totals match expectations.

Power BI Desktop is the free Windows application installed on a local machine. It is where reports are built. Data import, transformation in Power Query, data modeling with relationships and DAX, and visual creation all happen in Desktop. Reports are saved as .pbix files.

Power BI Service is the cloud-based SaaS platform accessed through a browser at app.powerbi.com. It is where reports are published, shared, and consumed. Dashboards are created by pinning visuals from reports. Scheduled data refreshes are configured. Workspaces enable team collaboration. Apps package reports and dashboards for distribution.

The typical workflow. Build in Desktop. Publish to Service. Share from Service. Stakeholders view in Service or Mobile.

Performance issues usually stem from the data model or DAX, not the visuals. Diagnose before treating.

Use Performance Analyzer. Found under the Optimize tab in Desktop. It records the time taken by each visual and DAX query. Identify the bottleneck. Is one visual slow? Is the entire page slow? Is data refresh slow?

Common fixes for data model performance. Reduce data volume. Import only the columns you need. Filter rows at the source. Remove unnecessary tables. Use a star schema. Avoid bi-directional relationships unless required. Set data types correctly. Numbers stored as text slow down queries.

Common fixes for DAX performance. Avoid using CALCULATE inside iterators like SUMX or AVERAGEX unless necessary. Use variables to store intermediate results so they calculate once, not repeatedly. Avoid complex calculated columns that can be done in Power Query or as measures. Use DIVIDE instead of IF with division for cleaner and faster execution.

Common fixes for visual performance. Limit visuals per page. Aim for eight to ten per report page, not twenty. Avoid custom visuals that are poorly optimized. Reduce cross-highlighting between visuals.

Data refresh updates the data in a published report without republishing the .pbix file. It is configured in Power BI Service.

Navigate to the workspace containing the dataset. Click the dataset, then Settings. Under Scheduled Refresh, toggle it on. Set the frequency. Daily or multiple times per day depending on your license. Set the time. Choose an off-peak time if possible.

For data sources on a local network, like an on-premises SQL Server or a file on a shared drive, a data gateway is required. Download and install the Power BI Data Gateway on a machine that can access the data source. Configure the gateway in Power BI Service under Manage Gateways. Add the data source credentials.

Cloud data sources like Azure SQL Database or SharePoint Online do not need a gateway. Power BI Service connects to them directly.

The free Power BI license allows up to eight refreshes per day. The Pro license allows forty-eight refreshes per day. Shared capacity refreshes are limited to eight for free users. Premium capacity allows more frequent refreshes and incremental refresh, which updates only new or changed data instead of reloading the entire dataset.

Row-level security, RLS, restricts data access for specific users. A salesperson in the North region should see only North region data. RLS enforces this at the database query level. It cannot be bypassed by changing visuals.

Implementation steps. In Power BI Desktop, go to the Modeling tab. Click Manage Roles. Create a new role. Name it descriptively, like North Region Sales. Add a DAX expression that filters a table. For example, Region equals North. This expression returns TRUE for rows the role can see.

You can also use dynamic RLS with the USERNAME or USERPRINCIPALNAME function. Create a mapping table with user emails and the regions they can access. The DAX expression filters based on the logged-in user's email.

Test the role in Desktop. Click View As Role. Select the role. Verify data is filtered correctly.

In Power BI Service, assign users to roles. Go to the dataset, Security. Add users or groups to each role. Users see only the data their role allows. They cannot see other data even if they build their own reports on the dataset.

Visual-level filters apply to a single visual. Select a visual. Drag a field to the Filters pane under Visual level filters. Only that visual is filtered.

Page-level filters apply to all visuals on a report page. Drag a field to Page level filters. Every visual on the page respects this filter.

Report-level filters apply to all pages in the report. Drag a field to Report level filters. Useful for global filters like excluding test data or filtering to the current year.

Drillthrough filters allow a user to right-click a data point and drill through to a detailed page. The destination page is filtered to the context of the clicked data point.

Slicers are interactive filters visible on the report page. Users select values. All visuals respond.

Cross-filtering happens when a user clicks a visual element like a bar in a bar chart. Other visuals on the page filter to that selection. This is configurable under Edit Interactions.

A KPI visual shows progress toward a target. It requires three values. Actual value. The current number, like current month sales. Target value. The goal, like monthly sales target. Trend axis. A time dimension, usually month or quarter.

Create a KPI visual. Drag the Actual value, a measure like Total Sales. Drag the Target value, a measure like Monthly Target. Drag the Trend axis, like Month from the Date table.

The visual displays the actual value prominently. A small indicator shows whether the actual is above or below target, typically green or red. A mini line chart shows the trend over time.

Formatting options. Set the target color. Configure the trend axis labels. Adjust the indicator thresholds. For example, values within five percent of target might show yellow instead of green or red.

KPIs work best when the target is a single value per period. If the target varies by month or region, ensure the measure returns the correct target for the current filter context.

Bookmarks capture the current state of a report page. Filters, slicer selections, visual visibility, and navigation state are all saved. They are used for storytelling, navigation, and creating interactive experiences.

Create a bookmark. Configure the report page exactly as you want it captured. Select slicer values. Set visual visibility. Go to the View tab. Click Bookmarks. Click Add. Name the bookmark descriptively.

Use bookmarks for report navigation. Create buttons. Link each button to a different bookmark. One bookmark shows the overview page with all slicers reset. Another shows the detailed sales view with specific filters applied. Buttons act as navigation between these views.

The Selection pane controls visual visibility. Use it with bookmarks for show/hide interactions.

Power BI Pro is a per-user license. Approximately ten dollars per user per month. Required for publishing reports to shared workspaces, sharing reports with other Pro users, and collaborating in workspaces. Both the report creator and the report viewer need Pro licenses unless Premium is used.

Power BI Premium is a capacity-based license. It reserves dedicated cloud compute resources for your organization. It is significantly more expensive, starting around five thousand dollars per month. It allows sharing reports with users who do not have Pro licenses. Those users can view reports with a free license. It provides larger data limits, more frequent refreshes, and advanced features like paginated reports, AI capabilities, and deployment pipelines.

For most small to medium businesses, Pro licenses for each user are sufficient. Premium makes sense for large organizations sharing reports with hundreds or thousands of users.

Premium Per User, PPU, is a middle ground. It provides many Premium features at a per-user price around twenty dollars per month. It is a good option for teams that need Premium features but do not need organization-wide Premium capacity.

Common DAX errors and their handling. Division by zero. Use DIVIDE instead of the slash operator. DIVIDE of Sales and Quantity, zero. If Quantity is zero or blank, the function returns zero instead of an error.

Missing or unexpected results from CALCULATE. CALCULATE replaces the entire filter context for the columns specified. If you want to add a filter while keeping existing filters, use KEEPFILTERS. CALCULATE of Total Sales, KEEPFILTERS with Region equals West. This adds the West filter rather than replacing existing region filters.

Blank versus zero. DAX functions often return BLANK instead of zero. BLANK propagates in calculations. Adding a number to BLANK returns BLANK. Use COALESCE or IF with ISBLANK to convert blanks to zeros when needed. COALESCE of Sales Amount, zero.

Circular dependency errors. These occur when two calculated columns or measures reference each other. Restructure the calculation. Use variables to break the chain. Move logic to Power Query if possible.

Out of memory errors. The data model is too large. Reduce columns. Filter rows. Aggregate data before loading. Use DirectQuery instead of Import for very large datasets.

DirectQuery connects Power BI directly to the data source without importing data. Every visual interaction sends a query to the source database. The results are returned and displayed. No data is stored in Power BI.

Use DirectQuery when the dataset is too large to import into Power BI. When data needs to be real-time or near-real-time, updated continuously at the source. When security policies at the data source must be enforced dynamically rather than replicated in Power BI.

Limitations. Performance depends on the source database speed. Reports feel slower than Import mode. DAX functionality is limited. Some DAX functions are not supported. The data model cannot be as complex. Limited transformations in Power Query.

Import mode is recommended for most scenarios. It is faster. It supports the full range of DAX and Power Query features. Use DirectQuery only when Import mode is not feasible due to data size or freshness requirements.

Composite models combine Import and DirectQuery. Some tables are imported. Some use DirectQuery. This provides a balance of performance and freshness.

A drillthrough page allows users to right-click a data point and navigate to a detailed view filtered to that context.

Create a new report page. In the Format pane, under Page Information, set Page Type to Drillthrough. In the Drillthrough section, add the field that will filter this page. For example, if you want to drill through to details for a specific product, add the Product field to Drillthrough filters. Set the filter to All. Power BI will dynamically filter this page when a user drills through.

Design the drillthrough page with detailed visuals. Tables, detailed charts, specific KPIs. The page should provide the detail that does not fit on the summary page.

Add a back button. Insert a button. Set its Action to Back. This allows users to return to the previous page after drilling through.

Test it. On the main report page, right-click a data point on a visual. Select Drillthrough, then the drillthrough page name. The detailed page opens, filtered to the selected value.

Power BI has real limitations. Knowing them shows experience. Data volume. Import mode is limited by memory. The free Service has a 1 GB dataset limit. Pro has 1 GB as well, though it can be increased in Premium. DirectQuery avoids these limits but sacrifices performance.

DAX learning curve. DAX is conceptually difficult. Filter context, row context, context transition. These concepts take time to internalize. Many analysts never master advanced DAX.

Customization limits. Visual formatting options are extensive but finite. Some specific chart types or design requirements cannot be achieved with native visuals. Custom visuals fill some gaps but vary in quality.

Data transformation. Power Query is powerful but not as flexible as Python or SQL for complex transformations. Some cleaning operations are awkward in the visual interface.

Real-time limitations. DirectQuery provides near real-time. True real-time dashboards require streaming datasets and push APIs, which add complexity.

Sharing requires licenses. The free version limits sharing. Pro licenses are needed for collaboration. This creates friction in organizations reluctant to pay for licenses.

Despite these limitations, Power BI remains the best tool for most dashboard and reporting needs. The limitations are manageable with workarounds.

This behavioral question tests whether you have actually done the work. Structure your answer clearly.

Start with the business problem. "The sales team needed visibility into regional performance. They were using a static Excel report updated monthly. They could not filter by product category or drill into individual sales rep performance."

Explain the data. "Data came from the company SQL Server. The sales transactions table, product table, customer table, and regional targets table. I used Import mode because the data volume was manageable."

Describe the data preparation. "In Power Query, I cleaned the sales table. Removed test transactions. Standardized date formats. Merged in product category names from the product table. Created a date table using DAX for time intelligence."

Describe the data model. "Star schema. Fact table was sales transactions. Dimension tables were date, product, customer, and region. One-to-many relationships. Single filter direction."

Describe the key measures. "Total Sales, Total Quantity, Sales Target, Target Achievement Percentage, Month-over-Month Growth, Sales Year over Year Growth."

Describe the visuals. "Card visuals for Total Sales and Target Achievement. A bar chart for sales by product category. A line chart for monthly sales trend with a target overlay. A map for regional performance. A table for top products. Slicers for date range, region, and product category."

Describe the outcome. "The dashboard replaced the monthly Excel report. The sales team now checks it daily. Regional managers use the drillthrough to see their specific performance. The Target Achievement KPI drove a competition between regions that increased sales."

This structure shows you understand the full process. Business problem, data, preparation, modeling, DAX, visuals, impact.

Twenty questions. You will not get all of them. But understanding these concepts deeply prepares you for any Power BI conversation in an interview.

The interviewer wants to see that you have built real dashboards. That you understand data modeling and DAX. That you have solved practical problems with the tool. Your answers should reflect experience, not memorization.

If you want structured training on Power BI along with SQL, Excel, and Python, SkillsYard's Data Analytics program covers the full stack with live mentorship and real projects. A free demo class is available. No commitment. Just a session to see if the teaching style fits.