100 Power BI Interview Questions and Answers (Beginner to Advanced)

Power BI is Microsoft’s Business Intelligence (BI) and data visualization platform that helps users connect to multiple data sources, transform data, create interactive reports, build dashboards, and share insights across an organization.

𝐊𝐞𝐲 𝐏𝐨𝐢𝐧𝐭𝐬

• Developed by Microsoft
• Supports self-service analytics
• Integrates with Excel, Azure, SQL Server and many third-party applications
• Enables real-time and scheduled reporting

Power BI consists of four primary components:

• Power BI Desktop – Used for report development
• Power BI Service – Cloud platform for publishing and collaboration
• Power BI Mobile – Access reports on mobile devices
• Power BI Report Server – On-premise report hosting solution

Power Query is the ETL (Extract, Transform, Load) engine in Power BI used to clean, transform, merge, split, and reshape data before loading it into the data model.

It uses the M language behind the scenes.

DAX (Data Analysis Expressions) is the formula language used in Power BI to create:

• Measures
• Calculated Columns
• Calculated Tables

It is optimized for analytical calculations and business logic.

Visualizations represent data graphically.

Examples include:

• Bar Chart
• Column Chart
• Line Chart
• Pie Chart
• Matrix
• Table
• Card
• KPI
• Map
• Scatter Plot

A dataset is a collection of tables, relationships, measures, and metadata that serves as the foundation for reports and dashboards.

Multiple reports can use the same dataset.

Data modeling is the process of creating relationships between tables to enable accurate analysis and reporting.

A well-designed model improves performance and simplifies DAX calculations.

Star Schema is the recommended data model structure in Power BI.

It consists of:

• One Fact Table (transaction data)
• Multiple Dimension Tables (descriptive information)

Example:

Sales Fact
   |
Customer
Product
Date
Region

It improves performance and simplifies reporting.

A Fact Table stores measurable business events such as:

• Sales Amount
• Quantity Sold
• Revenue
• Profit

It typically contains foreign keys linked to dimension tables.

Dimension tables contain descriptive attributes that provide context.

Examples:

• Customer
• Product
• Employee
• Region
• Calendar

Import Mode loads data into Power BI’s in-memory storage.

Advantages:

• Faster performance
• Rich DAX functionality
• Better user experience

Disadvantage:

• Requires periodic refreshes

DirectQuery keeps data in the source database instead of importing it.

Every report interaction sends a query to the source system.

Advantages:

• Near real-time data
• No duplicate storage

Disadvantages:

• Slower performance
• DAX limitations

Live Connection connects Power BI directly to an existing Analysis Services or Power BI semantic model.

No local data model is created.

Relationships connect tables using common fields.

Common relationship types:

• One-to-One
• One-to-Many
• Many-to-One
• Many-to-Many

Cross filter direction determines how filters propagate between related tables.

Options:

• Single Direction (recommended)
• Both Directions

Using both directions unnecessarily may reduce performance and create ambiguity.

Power BI provides three filter levels:

• Visual-level Filters
• Page-level Filters
• Report-level Filters

These help users analyze specific subsets of data.

A Slicer is an interactive visual that allows users to filter report data dynamically.

Examples:

• Year
• Region
• Product Category
• Department

Power BI Gateway securely transfers data between on-premises data sources and Power BI Service.

It enables:

• Scheduled Refresh
• Live Connections
• DirectQuery

without exposing internal databases directly to the internet.

Scheduled Refresh automatically updates imported datasets at predefined intervals.

It ensures reports always display the latest available data.

Row-Level Security restricts data visibility based on user roles.

Example:

• Sales Manager (East) sees only East Region data.
• Sales Manager (West) sees only West Region data.

This enhances data governance and security.

SUM()

• Aggregates an existing column.

Example:

SUM(Sales[Amount])

SUMX()

• Iterates through each row, evaluates an expression, and then sums the results.

Example:

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

CALCULATE() is one of the most important DAX functions.

It modifies the filter context before evaluating an expression.

Example:

Total East Sales =
CALCULATE(
    SUM(Sales[Amount]),
    Region[Name] = "East"
)

Most advanced DAX measures are built using CALCULATE().

Some widely accepted best practices include:

• Use Star Schema instead of flat tables
• Prefer Measures over Calculated Columns
• Keep visualizations simple and focused
• Minimize unnecessary visuals on a page
• Use meaningful table and column names
• Optimize DAX calculations
• Remove unused columns
• Use Import Mode whenever possible
• Implement Row-Level Security when required
• Follow a consistent color palette and layout

Filter Context refers to the set of filters applied while calculating a measure.

Filters can come from:

• Slicers
• Visuals
• Report filters
• Page filters
• CALCULATE()

For example:

If a report is filtered to Year = 2025, then:

SUM(Sales[Amount])

returns only sales for 2025.

Understanding Filter Context is essential for writing accurate DAX measures.

Row Context means DAX evaluates one row at a time.

It exists naturally in:

• Calculated Columns
• Iterator functions like SUMX(), FILTER(), AVERAGEX()

Example:

Profit = Sales[Revenue] - Sales[Cost]

Each row calculates its own profit.

CALCULATE() changes the filter context before evaluating an expression.

Example:

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

Almost every advanced DAX measure relies on CALCULATE().

ALL()

Removes all filters.

CALCULATE(
SUM(Sales[Amount]),
ALL(Product)
)

ALLEXCEPT()

Removes all filters except specified columns.

ALLEXCEPT(
Sales,
Sales[Year]
)

Useful for percentage calculations.

A Calculated Table is generated using DAX instead of importing data.

Example:

TopCustomers =
FILTER(
Customers,
Customers[Sales]>10000
)

Useful for creating custom analytical tables.

Data Refresh updates imported datasets with the latest source data.

Types include:

• Manual Refresh
• Scheduled Refresh
• Incremental Refresh

Instead of reloading the entire dataset, Incremental Refresh updates only recent or changed records.

Benefits:

• Faster refresh
• Lower resource usage
• Better scalability

Especially useful for large datasets.

Query Folding pushes transformations back to the source database.

Instead of Power BI processing data locally,

SQL Server executes:

SELECT Region,
SUM(Sales)
FROM Orders
GROUP BY Region

instead of importing every row.

This significantly improves performance.

Best practices:

• Remove unnecessary columns
• Use Star Schema
• Prefer Measures over Calculated Columns
• Minimize relationships
• Reduce visual count
• Enable Query Folding
• Use Import Mode when possible
• Optimize DAX

Composite Models combine multiple storage modes:

• Import
• DirectQuery
• Dual

This provides flexibility between performance and real-time access.

Import Mode:

• Entire dataset stored in memory
• Faster

Composite Model:

• Mixes Import and DirectQuery
• Balances performance with real-time reporting

Bidirectional filtering allows filters to flow both directions between tables.

Useful in some scenarios but may:

• Reduce performance
• Create ambiguous relationships

Single-direction filtering is generally recommended.

Many-to-Many occurs when multiple rows match on both sides.

Example:

Students ↔ Courses

A student enrolls in multiple courses.

A course contains multiple students.

Power BI supports Many-to-Many relationships but they should be used carefully.

USERELATIONSHIP() activates an inactive relationship inside CALCULATE().

Example:

CALCULATE(
SUM(Sales[Amount]),
USERELATIONSHIP(
Sales[ShipDate],
Calendar[Date]
)
)

Useful when multiple date columns exist.

Time Intelligence enables calculations across dates.

Examples:

• Year-to-Date (YTD)
• Month-to-Date (MTD)
• Quarter-to-Date (QTD)
• Previous Year Sales
• Running Totals

These require a properly configured Date Table.

A Date Table contains one row per date and additional attributes like:

• Year
• Quarter
• Month
• Week
• Day

It is essential for Time Intelligence calculations.

Drill Down allows users to navigate through hierarchy levels.

Example:

Year
 ↓
Quarter
 ↓
Month
 ↓
Day

Users can explore data interactively.

Drill Through navigates to another report page using selected context.

Example:

Clicking a customer opens a detailed Customer Analysis page.

Bookmarks capture:

• Filters
• Slicers
• Visual states

They are commonly used for:

• Navigation
• Show/Hide panels
• Interactive storytelling

Tooltips provide additional information when users hover over visuals.

Power BI supports:

• Default Tooltips
• Custom Report Page Tooltips

Conditional Formatting dynamically changes:

• Background color
• Font color
• Icons
• Data bars

based on business rules.

Example:

Profit < 0 → Red

Profit > 0 → Green

Experienced interviewers often expect this answer.

Common mistakes include:

• Using Flat Tables instead of Star Schema
• Creating unnecessary Calculated Columns
• Overusing Bidirectional Relationships
• Writing inefficient DAX
• Importing unused columns
• Ignoring Query Folding
• Not creating a Date Table
• Excessive visuals on one page
• Hardcoding business logic
• Publishing reports without Row-Level Security

VertiPaq is Power BI’s in-memory columnar storage engine.

Instead of storing data row by row, it stores data column by column and applies aggressive compression techniques.

Benefits

• Faster query execution
• Reduced memory usage
• High compression ratio
• Optimized aggregations

This is one of the primary reasons Import Mode performs exceptionally well.

Power BI uses two engines:

Storage Engine

• Retrieves compressed data
• Executes scans and aggregations
• Highly optimized

Formula Engine

• Executes DAX calculations
• Applies business logic
• Coordinates Storage Engine operations

A well-written DAX measure minimizes Formula Engine workload.

Context Transition occurs when CALCULATE() converts Row Context into Filter Context.

Example:

CALCULATE(
SUM(Sales[Amount])
)

This behavior is fundamental to understanding advanced DAX calculations.

Evaluation Context consists of:

• Row Context
• Filter Context

Every DAX expression is evaluated within these contexts.

Incorrect understanding often leads to wrong business calculations.

SUMX() evaluates an expression for each row before aggregating.

Example:

SUMX(
Sales,
Sales[Quantity] * Sales[Price]
)

Unlike SUM(), SUMX() performs row-by-row calculations.

A Virtual Table exists only during query execution.

It is not physically stored.

Example:

FILTER(
Sales,
Sales[Amount] > 1000
)

Virtual tables improve flexibility while reducing storage requirements.

57. What are Variables (VAR) in DAX?

Variables improve:

• Readability
• Performance
• Debugging

Example:

VAR TotalSales =
SUM(Sales[Amount])

RETURN

TotalSales * 0.10

Using VAR avoids repeated calculations.

ALL()

Removes every filter.

ALLSELECTED()

Preserves external filters while ignoring local ones.

Useful for dynamic percentages.

REMOVEFILTERS()

Explicitly removes filters and improves code readability.

CROSSFILTER() temporarily changes relationship direction inside CALCULATE().

Useful when modifying filter propagation without changing the data model.

TREATAS() applies values from one table as filters to another unrelated table.

Useful when tables have no physical relationship.

Common enterprise use case:

Comparing Budget vs Actual data from different sources.

Best practices:

• Reduce model size
• Remove unused columns
• Use Star Schema
• Minimize Cardinality
• Optimize DAX
• Enable Query Folding
• Reduce visual interactions
• Use Aggregation Tables
• Avoid unnecessary Bidirectional relationships

Cardinality refers to the number of unique values in a column.

Example:

CustomerID

100,000 unique values

High Cardinality:

• Consumes more memory
• Reduces compression
• Slows queries

Aggregation tables store summarized data.

Instead of scanning millions of rows:

Daily Sales
↓

Monthly Sales

↓

Yearly Sales

Power BI can answer many queries from aggregated tables.

Composite Models should:

• Import frequently used tables
• DirectQuery large transactional tables
• Use Dual storage where appropriate

This balances performance and freshness.

Dynamic RLS automatically filters data based on logged-in user identity.

Example:

UserEmail =
USERPRINCIPALNAME()

Different users automatically see different records.

Returns the currently logged-in user’s email.

Example:

USERPRINCIPALNAME()

Widely used in Dynamic Row-Level Security implementations.

Deployment Pipelines provide:

Development

↓

Test

↓

Production

deployment workflow.

Benefits:

• Controlled releases
• Version management
• Reduced deployment risk

Semantic Model is the modern name for Power BI Dataset.

It includes:

• Tables
• Relationships
• Measures
• Security
• Business logic

Multiple reports can connect to one Semantic Model.

XMLA Endpoint allows external tools to connect to Power BI Semantic Models.

Used by:

• Tabular Editor
• SQL Server Management Studio
• ALM Toolkit

Important for enterprise deployments.

Instead of refreshing:

2018
2019
2020
2021
2022
2023
2024
2025

Power BI refreshes only recent partitions.

Example:

Keep 5 years

Refresh last 7 days

This dramatically reduces refresh time.

Calculation Groups reduce duplicate DAX measures.

Instead of:

Sales YTD

Sales MTD

Sales QTD

Profit YTD

Profit MTD

Profit QTD

One Calculation Group can dynamically apply different calculations.

Tabular Editor is an external modeling tool for Power BI.

Used for:

• Bulk measure creation
• Calculation Groups
• Best Practice Analyzer
• Model optimization

Widely used in enterprise BI projects.

ALM Toolkit compares and deploys Semantic Models.

Features:

• Compare metadata
• Deploy changes
• Merge models
• Preserve relationships and measures

Useful for Dev/Test/Prod environments.

Organizations implement:

• Naming standards
• Certified Semantic Models
• Workspace permissions
• Row-Level Security
• Sensitivity Labels
• Data Lineage
• Deployment Pipelines
• Source Control
• Audit Logs

These ensure consistency and compliance.

A typical architecture follows:

Source Systems
(SQL, SAP, APIs, Excel)

↓

ETL / Data Integration

↓

Data Warehouse / Lakehouse

↓

Power BI Semantic Model

↓

Measures & Business Logic

↓

Reports & Dashboards

↓

Power BI Service

↓

Row-Level Security

↓

Business Users

Best Practices

• Use Star Schema
• Centralize business logic
• Reuse Semantic Models
• Optimize DAX
• Implement Deployment Pipelines
• Enable Incremental Refresh
• Apply Governance and Security
• Monitor Performance

I would follow a structured approach:

1. Use Performance Analyzer to identify slow visuals.
2. Check DAX measures for expensive calculations.
3. Verify whether new visuals or slicers were added.
4. Analyze model size and cardinality.
5. Check relationship directions.
6. Review Query Folding in Power Query.
7. Optimize visuals and reduce unnecessary interactions.

Key Principle: Never optimize blindly—identify the bottleneck first.

Instead of importing everything:

• Use Composite Models
• Keep historical data in Import Mode
• Use DirectQuery for recent transactions
• Create Aggregation Tables
• Enable Incremental Refresh

This provides near real-time reporting while maintaining performance.

I would verify:

• Source data consistency
• Applied filters
• Relationship correctness
• DAX logic
• Duplicate records
• Date filters
• Currency conversion logic

Only after validating each layer would I conclude whether it is a business or technical issue.

Use Dynamic Row-Level Security.

Create a security table:

Apply

Region = LOOKUPVALUE(...)

or

USERPRINCIPALNAME()

Power BI automatically filters the data for each logged-in user.

I would:

• Store a Currency table
• Store Exchange Rates
• Create a Currency Selector slicer
• Build Dynamic DAX measures

Users can switch between:

USD

EUR

INR

GBP

without creating multiple reports.

Use Calculation Groups.

Instead of:

Sales MTD

Sales QTD

Sales YTD

Profit MTD

Profit QTD

Profit YTD

one Calculation Group dynamically applies the selected time intelligence calculation.

I would:

• Adopt Star Schema
• Hide technical columns
• Create display folders
• Rename measures using business terminology
• Separate fact and dimension tables
• Remove unused objects

A clean model improves usability and maintenance.

Check:

• Refresh history
• Gateway status
• Source system availability
• Credential expiration
• API limits
• Network connectivity

Always verify logs before making changes.

Implement Incremental Refresh.

Example:

Store:

5 years of history

Refresh:

Last 7 days only

This minimizes refresh duration while preserving historical analysis.

Create:

SharePoint Folder

↓

Power Query Folder Connector

↓

Automatic Refresh

↓

Power BI Dataset

Users simply upload files, and Power BI processes them automatically.

Reduce:

• Visual count
• Cross filtering
• High-cardinality visuals
• Complex DAX calculations

Split the report into multiple logical pages if necessary.

Use:

TOPN()

combined with

RANKX()

and slicers.

The Top 10 list updates automatically according to selected year, region, or category.

Connect all sources in Power Query.

Standardize:

• Data types
• Column names
• Keys

Perform transformations before loading into a unified Star Schema model.

Identify:

• Duplicate keys
• Naming inconsistencies
• Null values

Create:

Master Customer Dimension

and use surrogate keys instead of relying solely on customer names.

Not necessarily.

Questions to ask:

Does the business really need 5-minute updates?

Will source systems support that frequency?

Will frequent refreshes affect performance?

Sometimes a 30-minute refresh provides the same business value at much lower cost.

I would first understand:

• Data sources
• Relationships
• Measures
• Refresh process
• Security model
• Business purpose

Only after documenting the architecture would I start making changes.

Never assume Power BI is wrong.

Verify:

Source

↓

Transformation

↓

Relationship

↓

Measure

↓

Visual

↓

Filter

↓

User interpretation

Many issues arise from misunderstanding rather than technical errors.

Create centralized Semantic Models.

Sales

Finance

HR

Operations

Each department builds reports from certified datasets instead of duplicating logic.

Use:

Deployment Pipelines

ALM Toolkit

Version Control

Testing Environment

Approval Process

Never deploy directly into Production.

Possible optimizations:

• Reduce visuals
• Improve SQL indexes
• Push transformations to source
• Use Import Mode where possible
• Use Aggregation Tables
• Enable Dual Storage

Provide:

Certified Semantic Models

↓

Business-friendly Measures

↓

Controlled Workspace Access

↓

Documented Data Dictionary

Users gain flexibility without compromising governance.

Do not hardcode business rules.

Instead:

• Document requirements
• Parameterize logic
• Store KPI definitions in configuration tables
• Create flexible DAX measures

This reduces future maintenance.

Architecture:

Global ERP / CRM / APIs

↓

Data Lake / Warehouse

↓

ETL

↓

Semantic Model

↓

Regional Security

↓

Country Reports

↓

Executive Dashboard

Include:

• Dynamic RLS
• Currency Conversion
• Localization
• Time Zone Handling
• Deployment Pipelines

I would avoid product bias and ask:

• Existing Microsoft ecosystem?
• Budget?
• Self-service requirements?
• Governance needs?
• User skill level?
• Licensing considerations?

Then recommend the tool that best fits the business rather than personal preference.

My approach follows six steps:

1. Understand the business problem

What decisions will this dashboard support?

2. Design a scalable data model

Use Star Schema and reusable Semantic Models.

3. Optimize performance

Efficient DAX, Incremental Refresh, Aggregations, and clean relationships.

4. Implement security

Dynamic Row-Level Security, workspace permissions, and governance.

5. Build intuitive reports

Simple navigation, meaningful KPIs, and business-friendly visuals.

6. Plan for long-term maintenance

Documentation, Deployment Pipelines, version control, and reusable components.

These 100 questions cover the most frequently asked concepts from beginner to advanced levels, including Power Query, DAX, data modeling, Power BI Service, performance optimization, and real-world scenarios. While no question bank can guarantee success, mastering these topics provides a strong foundation for most Power BI interviews.

Yes. The Beginner and Intermediate sections are designed specifically for freshers, recent graduates, and professionals transitioning into Power BI roles. They focus on core concepts that interviewers commonly assess.

Yes. Many topics covered in this guide overlap with the Microsoft PL-300 Data Analyst certification syllabus, including data preparation, modeling, DAX, visualization, security, deployment, and Power BI Service.

Interviewers commonly expect knowledge of:

• Power Query
• DAX
• Data Modeling
• Relationships
• Star Schema
• Power BI Service
• Row-Level Security (RLS)
• Performance Optimization
• Incremental Refresh
• Real-world business scenarios

Instead of memorizing definitions, practice explaining how you solved real business problems. Interviewers often evaluate your thought process, data modeling approach, optimization techniques, and decision-making skills.

You should be comfortable writing common measures, understanding filter context and row context, using CALCULATE(), iterators (SUMX, FILTER), time intelligence functions, ranking functions, and performance optimization techniques.

A good portfolio should include projects such as:

• Sales Dashboard
• Financial Dashboard
• HR Analytics Dashboard
• Customer Churn Analysis
• Supply Chain Dashboard
• Executive KPI Dashboard
• Inventory Analysis
• Marketing Performance Dashboard

These demonstrate practical experience beyond theoretical knowledge.

Review the questions multiple times before your interview. Focus on understanding the concepts, practicing DAX and Power Query, and explaining answers confidently rather than memorizing them word for word.