Are you looking for your next Power BI role?
Perhaps you are looking to benchmark a candidate?
Or maybe you are looking for a resource to deepen your Power BI and DAX knowledge?
Then look no further! This is your ultimate guide which covers the top questions that come up time and time again in Power BI interviews – answers included.
Everything from the foundational concepts to enterprise-level security and deployment are covered – so make sure to save this one in your bookmarks bar!
As a data and web development consultant based in South Wales (UK), I’ve worked across a wide range of Power BI engagements. This has involved everything from building reporting suites for SMEs to designing enterprise data models for large organisations.
The questions below reflect what I’ve seen asked in real hiring processes, and the answers reflect how I’d approach them in practice.
Note: A companion post covering the 39 most common DAX interview questions goes significantly deeper on DAX specifically — this post links to it wherever relevant.
How to Use This Guide
This post is structured into six key topic areas. If you’re prepping for an interview, work through each section in order — later sections build on earlier ones.
If you’re on the recruitment side of things, the difficulty indicators next to each question (🟢 Beginner / 🟡 Intermediate / 🔴 Advanced) should help you calibrate which questions to ask based on the seniority of the role.
If you are just looking to sharpen your skills, either work through each section, or just pick the ones where you feel your knowledge is the weakest. Whatever works for you.
Section 1 — Core Concepts & Fundamentals
Q1. What is Power BI and what are its main components? 🟢
Power BI is Microsoft’s business intelligence and data visualisation platform.
It allows users to connect to a wide variety of data sources, transform and model that data, and then create interactive reports and dashboards that can be shared across an organisation. It’s essentially Microsoft Excel on steroids!
Power BI consists of three core components:
- Power BI Desktop (for report development and data modelling)
- Power BI Service (a cloud-based SaaS platform for publishing, sharing, and collaboration)
- Power BI Mobile (for consuming reports on mobile devices).
In addition, the broader Power BI ecosystem includes Power BI Gateway (for connecting to on-premises data), Power BI Embedded (for integrating reports into custom applications), and Power BI Report Server (for on-premises reporting).
In most professional contexts, the day-to-day workflow starts with building in Desktop. This is followed by publishing to the Service, and then managing access and refresh from there.
Note: In my experience, I’ve never had a genuine need to use the
Power BI Mobile component. In most corporate environments, the bulk
of analytical work happens on desktop machines, and that’s where
users spend their time. Even when companies issue work phones, they’re
almost always used for communication rather than anything data‑heavy.
As a result, mobile reporting tends to be more of a “nice to have” than
a practical requirement in day‑to‑day BI projects.Q2. What is the difference between Power BI Desktop, Power BI Service, and Power BI Mobile? 🟢
The key distinction is: Desktop is for building, Service is for sharing and managing, Mobile is for consuming.
Power BI Desktop is the development tool — it’s where you connect to data, transform it, build the model, write DAX, and design the report.
Power BI Service is the cloud platform where you publish that report, manage refresh schedules, set up permissions and row‑level security, and share content with others.
Power BI Mobile is simply the consumption layer — the iOS and Android apps for viewing and interacting with reports on the go.
Q3. What is a dataset, a report, and a dashboard — and how do they differ? 🟢
These three terms are often confused by newcomers but represent distinct objects in the Power BI Service.
Dataset — The underlying data model that powers reports. It contains the data connections, the data model (tables, relationships, calculated columns), and all DAX measures. When you publish a .pbix file from Desktop, a dataset and a report are both created in the Service. Datasets can be reused across multiple reports.
Report — One or more pages of visualisations, all built from a single dataset. A report is interactive — users can filter, cross-highlight, drill through, and slice data. It is the primary development artefact.
Dashboard — A dashboard in Power BI is a single‑page canvas created in the Power BI Service by pinning individual visuals (tiles) from one or more reports. Dashboards are designed for high‑level monitoring and are not interactive in the same way reports are — they don’t support page navigation or report‑level filters. They are lightweight, cross‑report summaries that can be shared easily, especially in environments using Power BI Pro or Premium.
A useful way to think about it: a dataset feeds a report, and a dashboard is a curated view assembled from multiple reports.
Note: The terms dashboard and report are often mixed up by people who
don’t build Power BI solutions. Most end users call any Power BI output
a “dashboard” because that’s how it feels to them — it doesn’t resemble
a traditional, static report. This confusion is largely due to Microsoft’s
naming conventions, which don’t always align with how people naturally
describe what they’re looking at.Q4. What are the main data connectivity modes in Power BI? 🟡
Power BI offers three primary connectivity modes, each with meaningful implications for performance, refresh, and data freshness.
Import Mode — Data is extracted from the source and stored in Power BI’s in-memory VertiPaq engine. This gives the fastest query performance because all data lives locally within the model. The trade-off is that data is only as fresh as the last scheduled refresh (up to 8 times per day on Pro, 48 times on Premium). This is the most commonly used mode.
DirectQuery — No data is imported. Every interaction with a report sends a live query directly to the source database. This ensures real-time data freshness and is suitable for very large datasets that cannot fit in memory. The trade-off is slower report performance, as query speed is entirely dependent on the source system. Not all DAX functions and Power Query transformations are supported in DirectQuery.
Live Connection — Similar to DirectQuery in that no data is stored in the model, but it is specifically used to connect to pre-existing models hosted in Analysis Services (on-premises or Azure) or Power BI datasets in the Service. You cannot add your own tables or modify the model — you are simply consuming one that already exists.
Composite Models — A more advanced option that allows mixing Import and DirectQuery tables within the same model, giving you flexibility over which tables are imported and which are queried live.
Choosing the right connectivity mode is one of the most consequential architectural decisions on any Power BI project.
Note: In real projects, API‑based data sources almost always use Import
Mode in standard implementations. APIs aren’t designed for live querying,
so Power Query pulls the data on refresh and loads it into the model. This
means refresh scheduling and API rate limits become important architectural
considerations.Q5. What is the Power Query Editor and what is it used for? 🟢
Power Query is the data transformation and preparation layer within Power BI. It is accessed via the Power Query Editor in Desktop and allows you to connect to data sources, clean and reshape data, and prepare it for loading into the data model — all without writing code (though code is generated behind the scenes).
Every transformation you apply in the UI is recorded as a step in a query, written in the M language. These steps are applied in sequence each time the data is refreshed. Common tasks performed in Power Query include:
- Removing or renaming columns
- Filtering rows based on conditions
- Changing data types
- Splitting or merging columns
- Handling null and error values
- Pivoting and unpivoting data
- Merging (joining) and appending (stacking) queries
- Adding custom columns using M expressions
A key concept to understand alongside Power Query is query folding — the ability for Power Query to translate transformations back into native queries against the source system (e.g. SQL). When query folding occurs, the source does the heavy lifting rather than Power BI, which significantly improves refresh performance. This is covered in more detail in Section 4.
Power Query is separate from DAX. Power Query prepares data before it enters the model; DAX operates on the data once it is in the model.
Note: Power Query is not exclusive to Power BI, it is also available in
Excel. It can be especially useful here for appending and merging tables.Q6. What is the difference between a calculated column and a measure? 🟢
This is one of the most commonly asked Power BI questions and the distinction is fundamental.
Calculated Column — Computed row by row at data refresh time and stored physically in the model. It becomes a new column in a table, visible in the data view, and can be used as a slicer, axis, or filter. Because it is stored, it consumes memory. Calculated columns are evaluated in row context.
-- Example: Adds a column that assigns each user an interest bucket based on the email they clicked: returns the email's CampaignInterest when Clicked = 1, otherwise "No Click".
CustomerInterestBucket = IF(EmailRecipients[Clicked] = 1, EmailRecipients[CampaignInterest], "No Click")Measure — A dynamic calculation that is computed at query time, based on the current filter context (what the user has selected in slicers, filters, and visuals). Measures are not stored in the model — they are calculated on the fly and return a scalar value evaluated within the current filter context. They are always referenced in the Values field of a visual. Measures are evaluated in filter context.
-- Example: Calculating the click-though rate of a fictional email marketing campaign
Click-Through Rate = DIVIDE([Clicks], [Impressions]) * 100When to use which:
Use a calculated column when you need the result to be available as a filterable or groupable attribute — for example, a bucketed demographic group or a concatenated full name.
Use a measure for any aggregated value you want to display in a visual — totals, averages, percentages, running totals, and so on. Measures are almost always the right tool for values in reports.
A common mistake is creating calculated columns for things that should be measures, which bloats the model size unnecessarily. This causes loading time to slow down.
Q7. What is a Power BI Gateway and when would you need one? 🟡
A Power BI Gateway is software installed on an on-premises machine (typically a server) that acts as a secure bridge between local data sources and the Power BI Service in the cloud. Without a gateway, the cloud service cannot reach data that sits behind a corporate firewall or on a local network.
You would need a gateway when:
- Your data source is on-premises (SQL Server, Oracle, files on a network drive, etc.)
- You want to set up scheduled refresh for a dataset that connects to any on-premises source
- You are using DirectQuery or Live Connection to an on-premises Analysis Services instance
There are two types:
On-premises data gateway (Standard mode) — Supports multiple users and multiple data sources. This is the recommended option for enterprise use. It runs as a Windows service and requires a machine that is always on.
On-premises data gateway (Personal mode) — Can only be used by a single Power BI user and only supports Import mode refresh. Not suitable for team or production environments.
Gateways are managed in the Power BI Service and can support multiple data source connections. For cloud-only data sources (Azure SQL, SharePoint Online, etc.), no gateway is required.
Q8. What is the difference between a workspace and a personal workspace? 🟢
Personal Workspace (also called “My Workspace”) is a private area in the Power BI Service available to every licensed user. It is to be used for personal development and testing. Content published here cannot be easily shared with others and does not support all enterprise features. You would typically use your personal workspace to test a report before publishing it to a shared workspace.
Workspaces are collaborative environments in the Power BI Service where teams can develop, manage, and share Power BI content. Key characteristics:
- Multiple users can be given access with permission sets or roles (Admin, Member, Contributor, Viewer)
- Content in a workspace can be published as a Power BI App for broader distribution
- Workspaces support deployment pipelines (Dev / Test / Production)
Workspace roles determine what members can do:
- Admin — Full control, including managing access
- Member — Can publish and share content
- Contributor — Can create and edit content but not manage access
- Viewer — Can only consume content
In any professional or enterprise setting, all production content should live in a properly managed workspace, not in personal workspace.
Section 2 — Data Modelling
Q9. What is a star schema and why is it preferred in Power BI? 🟡
A star schema is a data modelling pattern in which a central fact table is surrounded by multiple dimension tables, connected via one-to-many relationships. The name comes from the typical star-like shape of the model in the modelling section.
DimDate ──────┐
DimProduct ───┤
DimCustomer ──┼──── FactSales
DimStore ─────┤
DimCurrency ──┘Why it is preferred in Power BI:
Power BI’s VertiPaq engine and DAX are both optimised for star schema structures. Specifically:
- Filter propagation flows naturally from dimension tables into the fact table along one-to-many relationships, making DAX logic simpler and more predictable
- Query performance is better because fewer joins are needed and the engine can efficiently use column compression
- DAX functions like
CALCULATE, time intelligence functions, andRELATEDall behave most reliably in a star schema - Reports are easier to build because dimension columns (used as slicers and axes) are cleanly separated from measures (which live in or reference the fact table)
A well-structured star schema also makes the model more maintainable — new dimensions or facts can be added without disrupting existing relationships or DAX logic.
Q10. What is the difference between a star schema and a snowflake schema? 🟡
Both are dimensional modelling patterns, but they differ in how dimension tables are structured.
Star schema — Dimension tables are denormalised. All attributes of a dimension are stored in a single flat table. For example, a DimProduct table might contain ProductName, Category, and Subcategory all in one table. The result is fewer tables, simpler relationships, and better performance in Power BI.
Snowflake schema — Dimension tables are normalised into multiple related tables. In the product example above, Category and Subcategory would be split into their own separate tables, each related to DimProduct. This reduces data redundancy but results in more tables and more complex relationships.
In Power BI, the star schema is almost always preferred. The VertiPaq engine stores data in a compressed columnar format, so data redundancy in a denormalised dimension table is not the storage concern it would be in a traditional relational database. The performance and DAX complexity costs of snowflaking generally outweigh any storage benefits in a Power BI context.
Note: Flattening snowflaked dimensions before loading into Power BI is
way more efficient because upstream engines like SparkSQL are built for
large‑scale joins, while Microsoft explicitly recommends delivering clean,
modelling‑ready, denormalised tables to VertiPaq for best performance.
Doing the work in Power Query shifts heavy processing into the refresh
pipeline and can slow refreshes or gateways, so pre‑flattening is the
optimal approach, with in‑Power‑Query flattening as a functional but
second‑best fallback.
That said, it all depends on what tech setup the company you work for has.Q11. What are fact tables and dimension tables? 🟢
Fact tables and dimension tables are the core components of dimensional modelling and form the foundation of how Power BI semantic models are designed.
Fact table — Stores measurable, quantitative data about business events or transactions. Each row typically represents a single event such as a sale, call, shipment, or booking. Fact tables are usually long (many rows) and narrow (fewer columns). They contain numeric measures like quantity, amount, or cost, along with foreign keys that link to dimension tables. Common examples include FactSales, FactOrders, and FactInventory.
Dimension table — Stores descriptive, categorical attributes that provide context for the facts. Dimension tables are used as slicers, filters, and axes in reports. They tend to be short (fewer rows) and wide (many descriptive columns). They contain a primary key that the fact table references. Examples: DimProduct, DimCustomer, DimDate, DimStore.
A simple way to think about it: fact tables answer “how much” or “how many”, dimension tables answer “who”, “what”, “when”, “where”.
One important special case is the date table (DimDate, DateTable or Date Table). Every Power BI model that uses time intelligence functions should have a dedicated, contiguous date table marked as such in the model — this is covered in the DAX section.
Q12. What is cardinality in Power BI relationships? 🟡
Cardinality describes the nature of the numerical relationship between the rows in two related tables. When you create a relationship between two tables in Power BI, you must define its cardinality. There are four options:
One-to-Many (1:*) — The most common and recommended cardinality. One row in the first table (usually a dimension) relates to many rows in the second table (usually a fact). For example, one product in DimProduct can appear in many rows in FactSales. Power BI and DAX are optimised for this type.
Many-to-One (*:1) — Functionally the same as one-to-many, just stated from the perspective of the other table.
One-to-One (1:1) — One row in each table relates to exactly one row in the other. This is rare in well-designed models and often indicates that the two tables could be merged into one. See the notes in question 10.
Many-to-Many (*:*) — Multiple rows in both tables can match multiple rows in the other. This was historically solved using a bridge table, but Power BI now supports many-to-many relationships natively. Use these cautiously, as they can introduce ambiguity in filter propagation and unexpected DAX results. Even though supported natively, they should not replace proper dimensional modelling.
Understanding cardinality is important because it directly affects how filters flow through the model and how DAX functions behave.
Note: Avoid many‑to‑many cardinality where possible. It often introduces
ambiguous filter paths, double-counting and unpredictable behaviour in DAX,
which can lead to severe headaches later down the line. It should only be
used when there is no cleaner modelling option.Q13. What is the difference between a one-to-many and a many-to-many relationship? 🟡
One-to-many is the standard relationship type in a star schema. The “one” side is typically a dimension table with a unique primary key, and the “many” side is typically a fact table where that key appears multiple times. Filters flow from the “one” side (dimension) to the “many” side (fact) by default. This is predictable, performant, and well-supported by DAX.
DimProduct (ProductID is unique) ──── FactSales (ProductID repeats many times)Many-to-many occurs when neither table has a unique key for the join — meaning one row in Table A can match multiple rows in Table B, and vice versa. A classic real-world example is a customer-to-account relationship where a customer can have multiple accounts and an account can have multiple customers.
Q14. What is cross-filter direction and when would you use bidirectional filtering? 🟡
Cross-filter direction controls which way filters propagate across a relationship between two tables.
Single direction (recommended default) — Filters flow from the “one” side of a relationship to the “many” side. In a standard star schema, this means filters flow from dimension tables into the fact table. This is predictable and performant.
Bidirectional — Filters flow in both directions across the relationship. This means a filter applied to the fact table can also filter the dimension table.
When bidirectional filtering is genuinely needed:
- Many-to-many relationships sometimes require it to work correctly
- Certain
DISTINCTCOUNTcalculations across related tables can require it - Models with role-playing dimensions occasionally benefit from it in specific scenarios
Why to use it sparingly:
Bidirectional filtering can cause ambiguous filter paths when there are multiple routes between tables. It can also cause significant performance degradation because the engine must evaluate filters in both directions simultaneously. In some cases it can cause circular dependency errors.
The general best practice is to keep all relationships single-directional and use DAX functions like CROSSFILTER or TREATAS to achieve bidirectional behaviour only where needed, rather than enabling it as a model-wide setting.
Q15. What are role-playing dimensions? 🟡
A role-playing dimension is a single dimension table that is related to a fact table multiple times, with each relationship representing a different role or context.
The most common example is a date dimension. A sales fact table might have three date columns — OrderDate, ShipDate, and DeliveryDate — and each one needs to relate to the same DimDate table. However, Power BI only allows one active relationship between any two tables at a time.
How to handle this:
Option 1 — Inactive relationships with USERELATIONSHIP: Create the relationships in the model but mark all but one as inactive. Then use the USERELATIONSHIP DAX function inside a CALCULATE to activate a specific relationship for a particular measure.
Total Shipped Sales =
CALCULATE(
[Total Sales],
USERELATIONSHIP(FactSales[ShipDate], DimDate[Date])
)Option 2 — Duplicate the date table: Create multiple copies of DimDate (e.g. DimOrderDate, DimShipDate, DimDeliveryDate) in Power Query and relate each one to the corresponding column in the fact table. This gives you active relationships for each role but increases model size and maintenance overhead.
Note: Option 1 is cleaner and therefore preferable; Option 2 can be useful
when users need to slice by each date role simultaneously in the same report.Q16. What is a date table and why should you always use a dedicated one? 🟡
A date table is a table in your data model that contains one row for every date within a required range, along with a set of date attributes — year, quarter, month, week, day of week, financial year, and so on. It’s absolutely essential to all time intelligence calculations in Power BI.
Why a dedicated date table is essential:
DAX’s built-in time intelligence functions (TOTALYTD, SAMEPERIODLASTYEAR, DATEADD, etc.) require a date table that meets specific criteria:
- Contains a column of data type Date (not DateTime)
- Has no gaps — every date in the range must be present, including weekends and holidays
- Has been marked as a Date Table in Power BI Desktop (via the Table Tools ribbon)
Without this, time intelligence functions may fail or return incorrect results. Always configure your model explicitly to avoid ambiguity.
Auto date/time — avoid it in production: Power BI Desktop has an “Auto date/time” setting that auto-generates hidden date tables for every date column. While convenient for beginners, it creates one hidden table per date column, bloats the model, and makes DAX harder to write consistently. Always disable this setting in production models and use your own dedicated date table instead.
A dedicated date table also gives you full control over attributes like fiscal year periods, holiday flags, or custom week numbering — which auto date/time cannot provide.
Note: I have worked in an organisation that only used the fiscal calendar,
rendering auto date/time completely useless. Therefore make sure you create
a dedicated date table.
Section 3 — DAX (Data Analysis Expressions)
This section covers the DAX questions most commonly asked in Power BI-focused interviews. For a much deeper dive into DAX — including iterator functions, advanced filter manipulation, time intelligence, and performance optimisation — see the companion post: The 39 Most Common DAX Interview Questions Answered.
Q17. What is DAX and how does it differ from Excel formulas? 🟢
DAX (Data Analysis Expressions) is the formula language used in Power BI, Power Pivot, and Analysis Services. It is used to write calculated columns, measures, and calculated tables within a data model.
While DAX syntax looks similar to Excel — it uses functions like SUM, IF, AVERAGE, and so on — there are fundamental differences:
- DAX operates on tables and columns, not cells. In Excel, a formula like
=SUM(A1:A10)references a range of cells. In DAX,SUM(Sales[Amount])refers to an entire column in a table. You don’t directly reference individual cells — DAX works over columns and tables instead. - DAX is context-aware. Measures recalculate dynamically based on slicers, filters, and visual interactions. Excel operates at the cell level. It can be made dynamic, but it doesn’t natively use filter context across a data model like DAX does.
- DAX has evaluation contexts. The concepts of row context and filter context (and how they interact) are fundamental to DAX and have no true direct equivalent in Excel’s formula model. This is often the most conceptually challenging part of learning DAX.
- DAX is designed for aggregation and analytical calculations over large datasets, whereas Excel is built around cell-by-cell computation. While they share some function names, they serve fundamentally different purposes.
Note: If not already, become an Excel power user. Many companies
expect it — even if the role doesn’t rely heavily on Excel.Q18. What is the difference between CALCULATE and FILTER? 🔴
CALCULATE and FILTER both deal with filtering, but they work in completely different ways.
CALCULATE changes the filter context for an entire calculation — it tells Power BI to re‑evaluate a measure as if the report were filtered differently. This makes it perfect for things like “Sales in 2026” or “Sales for Product A,” where you’re simply applying a new set of filters to the whole calculation.
Sales in 2026 =
CALCULATE(
[Total Sales],
DimDate[Year] = 2026
)FILTER, by contrast, works row by row. It scans a table and keeps only the rows that meet a condition, which is essential when the logic can’t be expressed as a simple column filter. You need FILTER when you’re comparing a row to a measure, using greater‑than or less‑than logic, or combining multiple row‑level conditions — situations where CALCULATE alone can’t express the rule.
Sales Above Average =
CALCULATE(
[Total Sales],
FILTER(
Sales,
Sales[Amount] > [Average Sale Amount]
)
)The key idea is this: CALCULATE changes the context of a calculation, while FILTER builds a table by evaluating each row individually. CALCULATE is fast and should be your first choice for simple filters; FILTER is powerful but slower, and best reserved for complex, row‑level logic that CALCULATE can’t handle on its own.
Q19. What are row context and filter context — and why does the distinction matter? 🟡
These are the two evaluation contexts in DAX, and understanding them is the most important conceptual step in becoming proficient with the language.
Filter context is the set of filters currently applied to the model — from slicers, page filters, visual filters, report filters, and DAX functions like CALCULATE. When a measure is evaluated, DAX looks at all active filters and computes the result for only the rows that pass those filters. Filter context is what makes a measure show different values in different rows of a table visual — each row has a different filter context.
Row context exists during iteration — when DAX is processing a table row by row. Calculated columns are evaluated in row context: DAX knows which row it is on and can reference column values in that row directly. Iterator functions like SUMX also create a row context as they loop through each row of a table.
Why the distinction matters:
Row context and filter context are independent. Having a row context does not mean you have a filter context. This is why you cannot use measures inside calculated columns directly — measures require filter context, which calculated columns don’t naturally have.
This distinction also explains context transition — when CALCULATE is called inside a row context (e.g. within SUMX), it converts the row context into an equivalent filter context. This is a powerful but subtle behaviour that catches many developers off guard.
Note: A common frustration for beginners is a column chart shows the same
number for every bar when your measure isn’t reacting to the category on the axis.
A card only has one filter context, but a chart creates a new one for each bar,
and if your measure ignores those filters, every bar ends up showing the
same result. The visual is doing exactly what it should — it’s the measure
that isn’t written to handle those per‑category context changes.Q20. What is context transition and when does it occur? 🟡
Context transition is a key DAX behaviour where a row context is converted into an equivalent filter context.
It occurs whenever CALCULATE (or any function that calls CALCULATE implicitly) is executed while a row context is active — for example, inside a calculated column or an iterator like SUMX.
When context transition happens, CALCULATE takes the values from the current row and applies them as filters before evaluating the expression. This is why CALCULATE behaves differently in calculated columns than in measures.
-- triggers context transition
Sales Contribution % = DIVIDE( Sales[Sales Amount], CALCULATE([Total Sales]) Here, CALCULATE([Total Sales]) uses the current row’s values as filters, so [Total Sales] returns the total sales for that row’s filter context, not the grand total. This behaviour often surprises people and is rarely what you want in a calculated column.
Something to watch out for: using a measure inside an iterator like SUMX can implicitly trigger CALCULATE inside the measure, causing context transition without you realising it.
Q21. What is the difference between ALL, ALLEXCEPT, and ALLSELECTED? 🟡
All three are filter removal functions in DAX, but they differ in scope.
ALL(table or column) — Removes all filters from the specified table or column, regardless of what slicers or other filters are in place. Commonly used to calculate percentages of a grand total.
% of Total Sales =
DIVIDE(
[Total Sales],
CALCULATE([Total Sales], ALL(Sales))
)ALLEXCEPT(table, column1, column2, ...) — Removes all filters from a table except for the specified columns. Useful when you want to calculate a subtotal that respects some filters but ignores others.
Sales % Within Category =
DIVIDE(
[Total Sales],
CALCULATE([Total Sales], ALLEXCEPT(DimProduct, DimProduct[Category]))
)ALLSELECTED(table or column) — Removes filters applied by the current query context (i.e. filters from the visual’s rows/columns) but respects filters applied outside the visual — such as slicers and page filters. This is commonly used for “% of visible total” calculations.
% of Filtered Total =
DIVIDE(
[Total Sales],
CALCULATE([Total Sales], ALLSELECTED(DimProduct))
)A common mistake is using ALL when ALLSELECTED is intended — ALL ignores slicers entirely, whereas ALLSELECTED respects them. The right choice depends on whether the percentage denominator should reflect slicer selections.
Q22. How do RELATED and RELATEDTABLE work? 🟡
Both functions let you pull data across relationships in your model — but they move in opposite directions and return different types of results.
RELATED retrieves a single value from the one side of a relationship. It only works when a row context exists (e.g., in a calculated column or inside an iterator like SUMX).
-- Calculated column on FactSales
Product Category = RELATED(DimProduct[Category])Looking at the code snippet above, FactSales sits on the many side of a many‑to‑one relationship with DimProduct. For each sales row, RELATED uses the product key to fetch the matching category from the dimension table.
RELATED only works if the relationship direction allows filters to flow from the dimension to the fact. If the relationship is single‑direction but reversed, RELATED won’t be able to navigate it.
RELATEDTABLE retrieves all matching rows from the many side of a relationship. It also requires a row context — but instead of looking up a single value, it returns a filtered table.
-- Calculated column on DimProduct
Number of Sales = COUNTROWS(RELATEDTABLE(FactSales))Above in the snippet, each product row in DimProduct pulls back the set of FactSales rows that relate to it, and COUNTROWS gives you the number of sales for that product. RELATEDTABLE doesn’t return the entire fact table — only the rows that match the current row’s keys.
Quick summary: RELATED → moves to the one side → returns a scalar. RELATEDTABLE → moves to the many side → returns a table.
Q23. What are time intelligence functions, and can you give common examples? 🟡
Time intelligence functions are DAX functions designed to perform calculations across standard time periods — year to date, month to date, previous year, rolling periods, and so on. They are what makes period-over-period analysis possible in Power BI.
-- Note: Time intelligence functions require a properly configured date
-- table in the model. You can create a date table easily:
DateTable = CALENDAR( DATE(2026, 1, 1), TODAY() )
-- Also remember, hardcoding the end date of an end table will
-- cause inevitable crashes down the line. Make this dynamic.Common examples:
Year-to-date:
Sales YTD = TOTALYTD([Total Sales], DimDate[Date])Same period last year:
Sales SPLY = CALCULATE([Total Sales],
SAMEPERIODLASTYEAR(DimDate[Date])
)Year-over-year growth:
YoY Growth % =
DIVIDE(
[Total Sales] - [Sales SPLY],
[Sales SPLY]
)Previous month:
Sales Previous Month =
CALCULATE([Total Sales], DATEADD(DimDate[Date], -1, MONTH))Rolling 3-month total:
Rolling 3M Sales =
CALCULATE(
[Total Sales],
DATESINPERIOD(
DimDate[Date],
LASTDATE(DimDate[Date]),
-3,
MONTH
)
)Note: You can also use Power BI's 'quick measures'
feature to come up with time intelligence meausres fasterQ24. Is there a difference between using DIVIDE and using the / operator? 🟢
Yes there is! Both methods perform division, but they handle division by zero differently.
Using the / operator will return an error if the denominator is zero or blank, which can cause visuals to display errors or behave unexpectedly.
-- Risky: will error if [Total Customers] is 0 or blank
Avg Sales per Customer = [Total Sales] / [Total Customers]DIVIDE(numerator, denominator, [alternateResult]) handles division by zero gracefully. If the denominator is zero or blank, it returns blank by default (or an optional alternate result you specify).
-- Safe: returns BLANK() if [Total Customers] is 0 or blank
Avg Sales per Customer = DIVIDE([Total Sales], [Total Customers])
-- Or with a custom fallback:
Avg Sales per Customer = DIVIDE([Total Sales], [Total Customers], 0)The best practice is to always use DIVIDE instead of / for any measure where the denominator could be zero or blank. This is a small habit that prevents a lot of report errors in production, especially when filters leave a denominator with no data.
Note: COALESCE is a useful companion to the <code>/</code>
operator because it lets you replace BLANK() with a safe fallback
value before performing division.
By wrapping the denominator in COALESCE, you prevent
errors caused by missing data, though you
still need to be careful about true zeros. It’s a handy
technique, but for most scenarios DIVIDE remains the
clearer and more robust choice.Q25. What are iterator functions and can you give examples? 🟡
Iterator functions (also called X functions) are DAX functions that iterate over every row of a table, evaluate an expression in the row context of each row, and then aggregate the results. They follow the naming convention of ending in X: SUMX, AVERAGEX, MAXX, MINX, COUNTX, RANKX, and so on.
They are most useful when you need to perform a row-level calculation before aggregating — something you cannot do with simple aggregation functions like SUM.
-- Using SUM (wrong if you need row-level calculation first):
-- This would sum Sales Amount and Cost Amount separately, then subtract — incorrect
Wrong Profit = SUM(Sales[Sales Amount]) - SUM(Sales[Cost Amount])
-- Using SUMX (correct):
-- This calculates profit for each row first, then sums those row-level profits
Total Profit = SUMX(Sales, Sales[Sales Amount] - Sales[Cost Amount])In this example, if discounts or taxes are applied at a row level, the SUMX version will give the correct result whereas the SUM version may not.
Performance note: Because iterator functions evaluate row by row, they can be expensive on large tables. Always consider whether the same result can be achieved with a simpler non-iterating function before reaching for SUMX. Pre-computing row-level values as calculated columns can sometimes be the right trade-off.
Q26. What is VAR in DAX and why should you use it? 🟢
VAR (variable) allows you to store the result of a DAX expression and reference it multiple times within the same measure or calculated column, using RETURN to specify the final output.
Profit Margin % =
VAR TotalSales = [Total Sales]
VAR TotalCost = [Total Cost]
VAR Profit = TotalSales - TotalCost
RETURN
DIVIDE(Profit, TotalSales)Benefits of using VAR:
Readability — Complex measures become much easier to follow when intermediate results are named and broken into steps. This is especially valuable when sharing DAX with colleagues or returning to measures after time away.
Performance — A DAX expression stored in a VAR is evaluated only once, even if it is referenced multiple times in the RETURN statement. Without VAR, repeating an expression causes it to be evaluated each time it appears, which can be costly for complex measures.
Avoiding unintended context transition — Variables capture the current filter context at the point they are defined. This means referencing a variable inside CALCULATE does not trigger another round of context transition, which can prevent subtle bugs.
Using VAR...RETURN is considered best practice for any measure of moderate complexity.
Note: Did you know that the VAR DAX function can be
used in Excel through the LET function, giving you
the same clean, modular calculation style you’re
used to in Power BI?Q27. What is RANKX and how does it work? 🟡
RANKX is an iterator function that returns the rank of a value within a list of values evaluated over a table.
Product Sales Rank =
RANKX(
ALL(DimProduct[ProductName]), -- The table to rank over
[Total Sales], -- The expression to rank by
, -- Value to rank (blank = use expression above)
DESC, -- Order (DESC = highest = rank 1)
Dense -- Tie handling (Dense, Skip)
)Key parameters:
- Table — The table to iterate over. Usually
ALL(column)to rank across all products regardless of current filter. - Expression — The measure to rank by.
- Value — Usually left blank, which tells
RANKXto use the expression result for the current context. - Order —
DESC(default, highest value = rank 1) orASC. - Ties —
Dense(tied items share a rank, next rank is sequential) orSkip(tied items share a rank, next rank skips the tied positions).
Common gotcha: Without ALL in the table argument, RANKX only ranks within the currently visible rows of a visual, which means every visible row returns rank 1. Using ALL ensures ranking is against the full population.
Q28. What is the difference between SELECTEDVALUE and VALUES? 🟡
Both functions return values from a column under the current filter context, but they behave differently when multiple values are present.
VALUES(column) — Returns a table of unique values from the specified column in the current filter context. If there is one value, it returns a one-row table. If there are multiple values (e.g. multiple products selected in a slicer), it returns multiple rows. Can cause errors if used where a scalar is expected and multiple values exist.
SELECTEDVALUE(column, [alternateResult]) — Returns the single value in a column if the filter context contains exactly one distinct value, or the alternate result (default: BLANK()) if there are zero or multiple values. It is the safe, scalar-returning version.
-- Show selected product name in a card visual, or default message
Selected Product =
SELECTEDVALUE(DimProduct[ProductName], "Multiple products selected")Practical use cases for SELECTEDVALUE:
- Displaying a dynamic title or subtitle that reflects the current slicer selection
- Writing conditional measures that behave differently based on a single selection
- Parameter table patterns (what-if parameters)
SELECTEDVALUE is the appropriate choice any time you need a scalar value from a slicer selection and want graceful handling when nothing or multiple items are selected.
Section 4 — Power Query & Data Transformation
Q29. What is M language and how does it relate to Power Query? 🟡
M (formally called the Power Query Formula Language) is the functional programming language that underpins every transformation in Power Query. When you perform transformations in the Power Query Editor UI — filtering rows, changing data types, merging tables — Power BI automatically generates M code to represent those steps. You can view and edit this code directly via the Advanced Editor.
M is a case-sensitive, lazy-evaluated, functional language. Every query in Power Query is ultimately an M expression that produces a table. A typical M query looks like this:
let
Source = Sql.Database("server", "database"),
SalesTable = Source{[Schema="dbo", Item="Sales"]}[Data],
FilteredRows = Table.SelectRows(SalesTable, each [Year] = 2024),
RenamedColumns = Table.RenameColumns(FilteredRows, {{"SalesAmt", "Sales Amount"}})
in
RenamedColumns
Each step is defined as a named expression, and steps reference previous steps. The final expression after in is the output of the query.
You do not need to write M from scratch in most day-to-day Power BI work — the UI handles it. However, understanding M becomes important when:
- You need transformations the UI cannot produce natively
- You need to create dynamic, parameterised queries
- You need to debug unexpected behaviour in Power Query steps
- You want to optimise queries for performance or query folding
Note: M is needed when you need to create custom queries
(by first creating a blank query in power query), when connecting to
an api starts to become especially difficult. Connecting to Jira
or HubSpot are good use cases for editing M code.Q30. What is query folding and why is it important? 🔴
Query folding is the process where Power Query translates your M steps into a single native query that runs directly on the source system. Instead of Power BI pulling all the data and doing the work locally, the database performs the filtering, grouping, and joining — and only the final, reduced result set is returned..
For example, if you filter to 2024 and group sales by product in Power Query, SQL Server might receive a folded query like:
SELECT
ProductID,
SUM(SalesAmount) AS TotalSales
FROM dbo.Sales
WHERE OrderDate >= '2024-01-01' AND
OrderDate < '2025-01-01'
GROUP BY ProductID;This is exactly what makes folding so powerful: the heavy lifting happens on the database server, network traffic is reduced, refreshes are faster, and incremental refresh can only work when folding is preserved.
Power Query can generate a SQL query like above into M like this:
Source = Sql.Database("ServerName", "DatabaseName"),
Sales = Source{[Schema="dbo",Item="Sales"]}[Data],
Filtered = Table.SelectRows(Sales, each [OrderDate] >= #date(2024,1,1) and [OrderDate] < #date(2025,1,1)),
Grouped = Table.Group(Filtered, {"ProductID"}, {{"TotalSales", each List.Sum([SalesAmount]), type number}})Q31. How do you handle null values in Power Query? 🟢
Null values show up as null in Power Query and can quietly break your model if you don’t deal with them early. They can disrupt calculations, cause unexpected blanks in visuals, and prevent fact rows from matching dimension tables. Power Query gives you several intuitive, UI‑driven ways to clean them up.
The simplest fixes are Replace Values, Remove Blank Rows, and Fill Down/Fill Up. Replace Values lets you swap nulls for something meaningful like 0 or “Unknown”. Removing nulls works well when the row is genuinely incomplete. And Fill Down is perfect for hierarchical data where nulls simply mean “same as above”. For more nuanced logic, a Conditional Column lets you define rules without writing any M code.
One area that deserves special attention is foreign key columns. If a fact table contains nulls in its key fields, those rows won’t relate to any dimension record — meaning they disappear from your visuals. A common modelling best practice is to add an “Unknown” row to the dimension (often with a key like 0 or –1) and replace nulls in the fact table with that key. This ensures every row participates in the model and keeps your reports consistent and complete.
Q32. What is the difference between merging and appending queries? 🟢
These two operations are the Power Query equivalents of SQL JOINs and UNIONs respectively.
Merge (JOIN equivalent) — Combines two tables horizontally based on a matching key column. The result adds columns from one table to the other based on matching values. Power Query supports multiple join types:
- Left Outer — All rows from the left table, matching rows from the right
- Right Outer — All rows from the right table, matching rows from the left
- Full Outer — All rows from both tables
- Inner — Only rows where a match exists in both tables
- Left Anti / Right Anti — Rows that exist in one table but not the other
CustomerID | Name + CustomerID | Region → CustomerID | Name | Region
1 | Alice 1 | North 1 | Alice | North
2 | Bob 2 | South 2 | Bob | South
Append (UNION equivalent) — Stacks two or more tables vertically, adding rows from one table below another. Both tables must have compatible column structures. Commonly used to combine data from multiple source files or tables with identical schemas:
Sales_Jan → Date | Amount Appended: Date | Amount
Sales_Feb → Date | Amount Jan | 100
Feb | 200
A simple rule of thumb: merge when you want more columns; append when you want more rows.
Q33. How do you unpivot columns in Power Query and when would you need to? 🟡
Unpivoting is the process of transforming columns into rows — converting a “wide” table into a “long” table. It is one of the most commonly needed data reshaping operations in Power Query.
Example — before unpivoting:
| Product | Jan | Feb | Mar |
|---|---|---|---|
| Widget A | 100 | 120 | 130 |
| Widget B | 200 | 210 | 195 |
After unpivoting the month columns:
| Product | Month | Sales |
|---|---|---|
| Widget A | Jan | 100 |
| Widget A | Feb | 120 |
| Widget A | Mar | 130 |
| Widget B | Jan | 200 |
The unpivoted structure is what Power BI expects — a column to slice by (Month) and a column of values (Sales). The wide format cannot be easily used in a matrix or line chart.
How to unpivot in Power Query:
Select the columns you want to keep as identifiers (e.g. Product), then right-click the selected columns and choose “Unpivot Other Columns.” Alternatively, select the columns you want to unpivot and choose “Unpivot Columns.”
In M:
Table.UnpivotOtherColumns(Source, {"Product"}, "Month", "Sales")
Unpivoting is commonly needed when source data comes from Excel spreadsheets, pivot tables, or reporting systems that store data in a cross-tabulated format rather than a flat, relational structure.
Q34. What are parameters in Power Query and how would you use them? 🟡
Parameters in Power Query are named, reusable values that can be referenced across one or more queries. They make queries dynamic and configurable without requiring code changes each time a value needs to be updated.
Common use cases:
- Environment switching — A
ServerNameparameter that can be changed to point queries at a development, test, or production database - Dynamic file paths — A
FolderPathparameter used across multiple file-based queries, so moving files only requires updating one value - Date filtering — A
StartDateparameter used to filter data at source, enabling incremental or selective loading - Reusable thresholds — A
MinimumSalesAmountparameter used as a filter threshold across multiple queries
How to create a parameter:
In the Power Query Editor: Home → Manage Parameters → New Parameter. Specify a name, type, and current value.
Parameters can also be connected to what-if parameter slicers in the report for user-driven inputs, though this is done differently (via the Modelling ribbon in Desktop).
When combined with query folding, date-based parameters are particularly powerful — they allow the filter to be pushed to the source system as a WHERE clause, dramatically reducing the volume of data loaded during refresh.
Section 5 — Visualisation & Report Design
Q35. What are slicers and how do they differ from filters? 🟢
Both slicers and filters allow users to restrict which data is shown in a report, but they differ in visibility, placement, and flexibility.
Slicers are on-canvas visual elements — users interact with them directly on the report page. They can be formatted, resized, and positioned like any other visual. Slicers are always visible and make filtering interactions transparent and intuitive for end users. They support various input types: lists, dropdowns, between ranges, relative date ranges, and so on.
Filters appear in the Filters pane (the panel on the right side of a report in Desktop or the Service). They can be applied at three levels:
- Visual-level filters — Affect only one specific visual
- Page-level filters — Affect all visuals on the current page
- Report-level filters — Affect all visuals across all pages
Filters in the Filters pane can be hidden from end users (or locked) by the report developer, making them useful for applying constraints that users should not be able to change — for example, filtering out cancelled orders or restricting data to the current fiscal year.
Key difference: Slicers are for user interaction; filter pane filters can be for developer-controlled constraints. Both modify filter context, so a selection in either affects DAX measures the same way.
Q36. What is a drillthrough and how does it differ from drill down? 🟡
Both features add depth to a report, but they work in fundamentally different ways.
Drill down operates within a single visual that has a hierarchy set up on its axis. Clicking a drill down button (or double-clicking a bar/column) moves from a higher level of the hierarchy to a lower level. For example: Year → Quarter → Month → Day. All the other visuals on the page are unaffected. Drill down is about exploring the levels of a single dimension hierarchy within one visual.
Drillthrough is a page-level navigation feature. You designate a report page as a drillthrough page and specify which field(s) act as the drillthrough target. When a user right-clicks on a data point in any visual and selects Drillthrough, they are taken to the drillthrough page, where all visuals are automatically filtered to the context of what they right-clicked.
For example: you right-click on “Product A” in a sales summary chart, select Drillthrough → Product Detail, and you are taken to a page showing all sales, returns, and trends for Product A specifically.
Summary:
- Drill down — Moves through hierarchy levels within a visual on the same page
- Drillthrough — Navigates to a different page filtered to a selected context
Drillthrough is particularly powerful for creating summary → detail report flows without cluttering summary pages with too much information.
Note: From my experience being asked to set up drill
downs is much more common than setting up drillthroughs.Q37. What are bookmarks and how can they enhance a report? 🟡
Bookmarks capture the current state of a report page — including which visuals are visible, what filters and slicers are applied, and which visual is selected — and allow that state to be recalled instantly with a click.
Common uses for bookmarks:
Toggle panels — Show or hide a filter panel, a help overlay, or an information tooltip by creating two bookmarks (one with the panel visible, one without) and linking a button to each.
Navigation buttons — Create a set of bookmarks representing different “views” of the same page (e.g. Sales View, Margin View, Volume View) and use buttons to switch between them. This simulates tabbed navigation without needing multiple pages.
Reset filters button — Capture the default, unfiltered state of a page as a bookmark and link a Reset button to it so users can return to the starting state.
Bookmarks are a core UX design tool in Power BI. Reports that make good use of bookmarks feel significantly more polished and app-like than those that rely solely on slicers and the Filters pane.
Q38. What is conditional formatting in Power BI and how would you apply it? 🟡
Conditional formatting allows you to dynamically change the appearance of visuals — colours, font colours, icons, data bars, and web URLs — based on the values of a measure or column. It brings static tables and matrices to life and directs user attention to what matters most.
Types of conditional formatting:
Background colour — Colour cells in a table or matrix based on a value range. You can use a gradient scale (e.g. red to green) or define specific rules.
Font colour — Change the colour of text in a table or matrix cell.
Icons — Display icons (arrows, traffic lights, flags) alongside values to indicate direction or status.
Data bars — Show an inline bar within a cell to give a visual sense of magnitude without a separate chart.
Web URL — Make a column a clickable link.
Conditional formatting is useful when you want to highlight something as especially important, for example if a number is particularly low or high for a given context. For example, you may use the colour red to highlight a metric in a card to indicate that email open rates are especially low this month.
Section 6 — Security, Sharing & Administration {#section-6}
Q39. What is Row-Level Security (RLS) and how do you implement it? 🟡
Row-Level Security (RLS) is a feature that restricts the data that individual users can see within a report, based on their identity. With RLS in place, two users viewing the same report will see different data — even though they are looking at the same dataset. It is like setting up a view in SQL.
How to implement static RLS:
- In Power BI Desktop, go to the Modelling ribbon → Manage Roles
- Create a role (e.g. “UK Sales Team”)
- Define a DAX filter expression on the relevant table:
[Region] = "UK"- Publish the report to the Power BI Service
- In the Service, go to the dataset settings → Security
- Assign the role to the appropriate users or security groups
When members of the “UK Sales Team” role open the report, the DAX filter is automatically applied — they only see UK data.
Testing RLS: In Desktop, use Modelling → View as → select a role to preview how the report appears to members of that role.
RLS filters propagate through all relationships in the model by default — filtering a dimension table will automatically filter any related fact tables. This is why a well-structured star schema makes RLS easier to implement correctly.
Q40. What is the difference between static and dynamic RLS? 🔴
Static RLS applies a fixed, hardcoded DAX filter to a role. All users assigned to that role see the same restricted view. It is straightforward to implement but requires creating and maintaining a separate role for each data partition — which becomes unmanageable at scale.
-- Static: Role "UK Region" hardcodes the filter
[Region] = "UK"
Dynamic RLS uses the identity of the currently logged-in user to filter data automatically, based on a mapping table in the model. Instead of creating separate roles per region, one role handles all users — the data each user sees is determined by their email address and a mapping stored in the data itself.
Implementation:
- Create a mapping table (e.g.
UserRegionMapping) with columns:UserEmailandRegion - Load this table into the model and relate it to your data
- Create a single role with a DAX filter using
USERPRINCIPALNAME():
[UserEmail] = USERPRINCIPALNAME()USERPRINCIPALNAME() returns the email address of the currently logged-in user. The filter then propagates through the relationship to restrict the data to that user’s mapped regions.
Advantages of dynamic RLS:
- Scales to any number of users without creating additional roles
- New users and region mappings can be added by updating the mapping table — no Power BI Desktop changes required
- Easier to audit and maintain
Dynamic RLS is the standard approach for any production Power BI deployment with more than a handful of distinct user groups.
RLS is also useful when multiple clients use the same report
but share a common SQL database — it ensures each client
only sees their own data, even though all data lives in
the same source.Q41. What are the different licence types in Power BI and what does each enable? 🟡
Power BI has several licence tiers, and understanding what each enables is important for solution design and stakeholder conversations.
Power BI Free — Allows a user to use Power BI Desktop to build reports and publish to their own personal workspace. They cannot share content with others or access shared workspaces. Suitable only for personal, non-collaborative use.
Power BI Pro — A per-user licence (paid monthly) that enables publishing to shared workspaces, sharing reports and dashboards with other Pro users, setting up scheduled refresh (up to 8 times per day), and accessing reports shared by others. Both the publisher and the consumer of shared content need a Pro licence unless the content is hosted in a Premium capacity.
Power BI Premium Per User (PPU) — A per-user licence that gives access to most Premium features at a lower cost than a full Premium capacity. Includes higher refresh frequency (up to 48 times per day), paginated reports, larger dataset sizes, deployment pipelines, and XMLA endpoint access. Content shared in PPU workspaces can only be viewed by other PPU users.
Power BI Premium (Capacity) — A capacity-based licence (P SKUs for cloud, EM SKUs for embedding). It reserves dedicated compute resources for a Power BI tenant. Key benefit: Free users can view content published to a Premium capacity without needing a Pro licence — making it cost-effective for large organisations with many consumers. Also includes all PPU features.
Power BI Embedded (A SKUs) — Azure-based capacity designed for embedding Power BI content in custom applications. Billed by the hour and can be paused when not in use.
Q42. What is the difference between sharing a report and publishing to an app? 🟡
These are two distinct distribution methods in the Power BI Service, suited to different scenarios.
Direct sharing — You share a specific report or dashboard directly with named individuals or security groups. Recipients receive a link and can view the content in the Service or embed it. Direct sharing is quick and flexible but can become difficult to manage at scale — each share is a separate permission. Users can potentially navigate to the workspace and see all content there, not just what you intended to share.
Publishing as an app — You bundle the content of a workspace (reports, dashboards) into a Power BI App — a polished, curated experience with its own navigation, branding, and access control. The app is separate from the underlying workspace. You can:
- Control exactly which reports and dashboards are included
- Set up custom navigation between sections
- Publish the app to specific users or the entire organisation
- Update the app independently (by publishing a new version) without affecting what users currently see
Key difference: A shared report gives access to a single artefact; an app gives access to a curated, versioned collection of content with its own access list. For any production deployment intended for a wider audience, publishing as an app is almost always the right approach.
Note: From my time as a Power BI Developer I have only ever
come across an organisation publishing an app once. I assume
therefore that it is not particularly common. Q43. What are Power BI deployment pipelines? 🔴
Deployment pipelines are a Power BI Premium / PPU feature that enables a structured Development → Test → Production workflow for Power BI content. They allow teams to work on reports and datasets in a development environment and promote them through stages to production, without manually re-publishing or reconfiguring content at each stage.
How they work:
- Create a deployment pipeline in the Power BI Service
- Assign workspaces to each stage: Development, Test, and Production
- Develop and test content in the Development workspace
- Use the pipeline to deploy content from Development to Test, and then from Test to Production with a single click
Key features:
- Comparison view — See which items differ between stages before deploying
- Selective deployment — Deploy only specific reports or datasets, not the entire workspace
- Dataset rules — Override data source connection strings and parameters per stage (e.g. Dev connects to a test database, Production connects to the live database)
- Deployment history — Track what was deployed and when
Deployment pipelines bring software development best practices (CI/CD) to Power BI. They are essential for any organisation that needs governance, auditability, and a safe way to test changes before they reach end users.
Closing Thoughts
Power BI is a deep platform. Knowing the answers to these 43 questions will put you in a strong position for most interviews, but the real differentiator — both in interviews and on projects — is being able to connect these concepts and apply them to real-world problems.
A well-structured data model makes DAX simpler. Good Power Query practice makes refresh faster. Proper governance makes the whole solution trustworthy.
I’m available for Power BI, data modelling, and web development contracts. If you’re looking for an experienced consultant, feel free to get in touch via the contact page.