In this post we are going to cover real-world manager scenarios for Power BI. These are 7 real interview questions, and this time every one of them is a scenario a hiring manager asks: two reports that disagree, a KPI needed by tomorrow, users who export everything to Excel, Copilot readiness, a failed refresh before an executive meeting, a page with 40 visuals, and a messy environment with 300 reports.
By this point in an interview, the manager already believes you know DAX and modeling. Now they test judgment and process. They want to hear that you reproduce a number before you explain it, define a KPI before you build it, communicate during an incident, and fix the root cause instead of patching the symptom. There is rarely one right answer, but there is always a right order.
The first two scenarios run on a small sample data set, so you can rebuild them in Power BI Desktop and check each number yourself.
Part 10 of the Real Time Power BI Interview Questions and Answers series on TechBrothersIT.
- The short answer
- Let's create some sample data
- Scenario 1: Two reports show different revenue numbers for the same month. How do you find out why?
- Scenario 2: A stakeholder asks for a new KPI by tomorrow. How do you gather requirements and deliver it?
- Scenario 3: Users export everything to Excel. What do you do?
- Scenario 4: Leadership wants AI and Copilot in Power BI. What do you need to set up?
- Scenario 5: The refresh failed at 6 AM and the executive meeting is at 9. Walk me through it.
- Scenario 6: How do you handle a request for a report with 40 visuals on one page?
- Scenario 7: How would you take over a messy Power BI environment with 300 reports?
- The full SQL script
The short answer
Managers test judgment and process: reproduce a number before you explain it, define a KPI before you build it, communicate during an incident, and fix the root cause with one certified, shared semantic model.
Keep that summary in mind. Every scenario below is one piece of it.
Let's create some sample data
We use a tiny shop: 5 products, 4 customers in two regions, a date table for 2025 and 2026, and 12 sales in January to March of each year. The script below is written for PostgreSQL (the date table uses generate_series), and it works on any database with small changes. Load the four tables into Power BI Desktop and relate fact_sales to each dimension on its key.
DROP TABLE IF EXISTS fact_sales;
DROP TABLE IF EXISTS dim_product;
DROP TABLE IF EXISTS dim_customer;
DROP TABLE IF EXISTS dim_date;
CREATE TABLE dim_product (product_key INT PRIMARY KEY, product VARCHAR(30), category VARCHAR(20));
INSERT INTO dim_product VALUES
(1, 'Laptop Stand', 'Accessories'), (2, 'USB-C Cable', 'Accessories'),
(3, 'Monitor', 'Electronics'), (4, 'Keyboard', 'Electronics'),
(5, 'Desk Lamp', 'Home');
CREATE TABLE dim_customer (customer_key INT PRIMARY KEY, customer VARCHAR(30), city VARCHAR(20), region VARCHAR(10), email VARCHAR(40));
INSERT INTO dim_customer VALUES
(1, 'Sara Khan', 'Toronto', 'East', 'sara@tbshop.com'),
(2, 'Omar Ali', 'Dallas', 'West', 'omar@tbshop.com'),
(3, 'Lina Park', 'Seattle', 'West', 'lina@tbshop.com'),
(4, 'Mei Chen', 'Boston', 'East', 'mei@tbshop.com');
-- one row per day, 2025-01-01 .. 2026-12-31 (calendar year = fiscal year here)
CREATE TABLE dim_date (date DATE PRIMARY KEY, year INT, quarter VARCHAR(2), month_no INT, month VARCHAR(3));
INSERT INTO dim_date
SELECT d, EXTRACT(YEAR FROM d), 'Q' || EXTRACT(QUARTER FROM d), EXTRACT(MONTH FROM d), TO_CHAR(d, 'Mon')
FROM generate_series(DATE '2025-01-01', DATE '2026-12-31', INTERVAL '1 day') AS g(d);
CREATE TABLE fact_sales (
sale_id INT PRIMARY KEY,
order_date DATE REFERENCES dim_date(date),
product_key INT REFERENCES dim_product(product_key),
customer_key INT REFERENCES dim_customer(customer_key),
qty INT,
unit_price DECIMAL(10,2)
);
INSERT INTO fact_sales VALUES
( 1, '2025-01-10', 1, 1, 2, 40.00), ( 2, '2025-01-22', 3, 2, 1, 250.00),
( 3, '2025-02-05', 2, 3, 5, 10.00), ( 4, '2025-02-18', 5, 4, 1, 60.00),
( 5, '2025-03-03', 4, 1, 2, 50.00), ( 6, '2025-03-27', 3, 3, 1, 250.00),
( 7, '2026-01-08', 1, 2, 3, 40.00), ( 8, '2026-01-25', 3, 1, 1, 250.00),
( 9, '2026-02-11', 2, 4, 4, 10.00), (10, '2026-02-20', 4, 3, 2, 50.00),
(11, '2026-03-09', 5, 2, 2, 60.00), (12, '2026-03-30', 3, 4, 2, 250.00);Here are the 12 sales. Each row is one sale line: a date, a product, a customer, a quantity and a unit price.
| sale_id | order_date | product_key | customer_key | qty | unit_price |
|---|---|---|---|---|---|
| 1 | 2025-01-10 | 1 | 1 | 2 | 40.00 |
| 2 | 2025-01-22 | 3 | 2 | 1 | 250.00 |
| 3 | 2025-02-05 | 2 | 3 | 5 | 10.00 |
| 4 | 2025-02-18 | 5 | 4 | 1 | 60.00 |
| 5 | 2025-03-03 | 4 | 1 | 2 | 50.00 |
| 6 | 2025-03-27 | 3 | 3 | 1 | 250.00 |
| 7 | 2026-01-08 | 1 | 2 | 3 | 40.00 |
| 8 | 2026-01-25 | 3 | 1 | 1 | 250.00 |
| 9 | 2026-02-11 | 2 | 4 | 4 | 10.00 |
| 10 | 2026-02-20 | 4 | 3 | 2 | 50.00 |
| 11 | 2026-03-09 | 5 | 2 | 2 | 60.00 |
| 12 | 2026-03-30 | 3 | 4 | 2 | 250.00 |
And the customers, so you can see who is East and who is West.
| customer_key | customer | city | region | |
|---|---|---|---|---|
| 1 | Sara Khan | Toronto | East | sara@tbshop.com |
| 2 | Omar Ali | Dallas | West | omar@tbshop.com |
| 3 | Lina Park | Seattle | West | lina@tbshop.com |
| 4 | Mei Chen | Boston | East | mei@tbshop.com |
Scenario 1: Two reports show different revenue numbers for the same month. How do you find out why?
Don't guess. Reproduce both numbers first. The sales report says March 2026 revenue is 620.00. The regional report says 500.00.
| sales_report | region_report | gap |
|---|---|---|
| 620.00 | 500.00 | 120.00 |
Check this result yourself with SQL
Reproduce both numbers first: 620 in the sales report, 500 in the regional report, a gap of 120.
SELECT SUM(f.qty * f.unit_price) AS sales_report,
SUM(CASE WHEN c.region = 'East' THEN f.qty * f.unit_price END) AS region_report,
SUM(f.qty * f.unit_price) - SUM(CASE WHEN c.region = 'East' THEN f.qty * f.unit_price END) AS gap
FROM fact_sales f
JOIN dim_date d ON d.date = f.order_date
JOIN dim_customer c ON c.customer_key = f.customer_key
WHERE d.year = 2026 AND d.month = 'Mar';So the gap is 120.00. Now split the gap by a dimension until it explains itself. Here is a quick query in DAX query view: revenue by region for March 2026.
EVALUATE
CALCULATETABLE (
SUMMARIZECOLUMNS (
Customer[Region],
"Revenue", [Total Sales]
),
'Date'[Year] = 2026,
'Date'[Month] = "Mar"
)| region | revenue |
|---|---|
| East | 500.00 |
| West | 120.00 |
Check this result yourself with SQL
West is exactly the 120 gap, so the regional report only shows East: a hidden page filter.
SELECT c.region, SUM(f.qty * f.unit_price) AS revenue
FROM fact_sales f
JOIN dim_date d ON d.date = f.order_date
JOIN dim_customer c ON c.customer_key = f.customer_key
WHERE d.year = 2026 AND d.month = 'Mar'
GROUP BY c.region
ORDER BY c.region;East is 500.00 and West is 120.00. West is exactly the gap, so the regional report only shows East. Here the cause was a hidden page filter.
When the cause is not obvious, check the usual suspects in order:
- Filters: report, page and visual filters.
- RLS: who is viewing the report.
- Measure definition: the same name, but different logic.
- Keys and refresh: blank or unmatched keys, and different refresh times.
Then fix the root cause, not just the number.
Both reports should read one certified semantic model with one Total Sales measure, so the question can't come back.
Scenario 2: A stakeholder asks for a new KPI by tomorrow. How do you gather requirements and deliver it?
Start with a short call and pin down the definition before you write any DAX. Say the KPI is average order value:
- Define: the exact formula. Do returns count? Which date do we use?
- Grain and filters: do they need it by month, or by region?
- Owner: who signs off the number.
Then prototype the measure in DAX query view. Here it is total sales divided by the number of orders. The triple slash comment becomes the measure description when you update the model.
DEFINE
/// Revenue divided by number of orders
MEASURE Sales[Avg Order Value] =
DIVIDE ( [Total Sales], COUNTROWS ( Sales ) )
EVALUATE
SUMMARIZECOLUMNS (
'Date'[Year],
"Sales", [Total Sales],
"Orders", COUNTROWS ( Sales ),
"AOV", [Avg Order Value]
)Validate before anyone sees it. The query must return the same values as a SQL check on the source.
| year | sales | orders | aov |
|---|---|---|---|
| 2025 | 790.00 | 6 | 131.67 |
| 2026 | 1130.00 | 6 | 188.33 |
Check this result yourself with SQL
Sales divided by orders: 790 / 6 and 1130 / 6. The prototype measure must return the same values.
SELECT d.year, SUM(f.qty * f.unit_price) AS sales, COUNT(*) AS orders,
CAST(SUM(f.qty * f.unit_price) / COUNT(*) AS DECIMAL(10,2)) AS aov
FROM fact_sales f JOIN dim_date d ON d.date = f.order_date
GROUP BY d.year
ORDER BY d.year;2025 has 790.00 in sales over 6 orders, which is 131.67. 2026 has 1130.00 over 6 orders, which is 188.33. If the source check gives anything else, you find out tonight, not in front of the stakeholder.
Deliver a first version tomorrow on the shared model, clearly labeled, with a description and an agreed review date.
Fast is fine. Undefined is not.
Scenario 3: Users export everything to Excel. What do you do?
First, ask why, and don't block it on day one. Exports are a symptom: something people need is missing from the report, or Excel is where they do their real work.
Then match the answer to the reason.
| Why they export | What you give them |
|---|---|
| Pivot and slice it their own way | Analyze in Excel: live, same measures, needs Build |
| A printable, formatted file | A paginated report (Report Builder) |
| The same table every week | Build that view into the report |
| Data leaves the model | Sensitivity labels, CSV export setting, audit logs |
If they want to pivot and slice their own way, Analyze in Excel gives them a live connection to the certified model. They keep Excel, but use the same measures and the same security. They need Build permission on the model.
If they need a printable, pixel-perfect file, that is a paginated report. And if they export the same table every week to build the same chart, build that view into the report.
Finally, protect what still leaves. Sensitivity labels follow exports to Excel, but not to CSV, so admins can restrict CSV export in the tenant settings. Track export activity in the audit logs, and expect it to go down.
Scenario 4: Leadership wants AI and Copilot in Power BI. What do you need to set up?
Walk through it in four layers: capacity, admin settings, the model, and the change plan.
Capacity. Copilot needs a paid Fabric capacity of F2 or larger, or P1 or larger. A trial capacity, or Pro and PPU on their own, don't qualify.
Admin settings. Confirm the tenant setting that lets users use Copilot and Azure OpenAI features is on, and check the region. Outside the US and the EU, you also need the cross-geo setting.
The model. This is the part most teams forget. Copilot reads your model, not your mind, so it is only as good as your names and descriptions. Use Prep data for AI, still in preview, to set:
- The AI data schema: what Copilot may use.
- AI instructions: how it should use it.
- Verified answers: approved visuals for common questions.
Then mark the model Approved for Copilot.
The change plan. Q&A is retiring in February 2027, and Copilot is its replacement. Start with one certified model and a pilot group, and set clear expectations.
Scenario 5: The refresh failed at 6 AM and the executive meeting is at 9. Walk me through it.
This is an incident question, so answer it as a sequence.
- Read the error. Open the refresh history and read the actual message. Most failures are one of a few causes: the gateway is offline, the credentials expired, the source was down for maintenance, or the refresh timed out.
- Fix and rerun. Fix that cause and run the refresh again. An on-demand refresh from the service doesn't count against the daily scheduled quota, and with the new refresh options you can refresh only the tables you need, to save time.
- Communicate. While it runs, tell the meeting owner what happened, which numbers are affected, and when fresh data will be ready. If it won't make 9, say the report shows yesterday's data.
- Prevent. Send failure notifications to a team, not one person, monitor the gateway, schedule the refresh well before business hours, and write a short root cause note.
Never let executives find stale data in the meeting. Say it first, with a time.
Scenario 6: How do you handle a request for a report with 40 visuals on one page?
Don't say no, and don't just build it. Ask what decision the page supports. Usually the answer is a handful of numbers they check every morning.
Then explain the cost in their terms. Every visual runs its own query, so 40 visuals make a slow page, and nobody can read 40 charts at once anyway.
Offer a better design:
- A summary page with the top KPIs, each with a target and a trend.
- Drillthrough pages for the detail, on demand.
- Tooltips for context on hover.
Use Performance Analyzer to show the before and after. Then agree on the top KPIs together, and show a prototype.
Managers want someone who pushes back with a better option, not someone who only says yes or no.
Scenario 7: How would you take over a messy Power BI environment with 300 reports?
Don't start by rebuilding. Start by finding out what you actually have, then shrink it, then organize it, then keep it that way.
| What you do | |
|---|---|
| 1 INVENTORY | Workspaces, reports, models, owners, last viewed (audit logs) |
| 2 CLEAN UP | Archive what nobody opens, with the owners |
| 3 CONSOLIDATE | Thin reports on certified, shared semantic models |
| 4 ORGANIZE | Workspaces by domain, dev / test / prod, apps for users |
| 5 GOVERN | Endorsement, Viewer role, labels, pipelines or Git |
Inventory every workspace, report, semantic model and owner, plus when each report was last viewed, from the admin tools and the audit logs. In most environments, a lot of that content is barely used.
Clean up with the owners: archive what nobody opens. Fewer reports means less to fix, refresh and secure.
Consolidate. For example, ten reports with ten copies of sales data become thin reports on one certified, shared semantic model. Organize workspaces by domain, with dev, test and prod, and serve users through apps.
Govern so it doesn't grow back: endorsement, the Viewer role for consumers, sensitivity labels, and deployment through pipelines or Git.
Deliver a quick win early, like fixing the slowest executive report, so people trust the plan.
Key points to remember
- Reproduce both numbers, then split the gap
- Define a KPI, then prototype and validate
- Give exporters what they export for
- Copilot: F2+ or P1+ and a prepared model
- Communicate early; inventory before you rebuild
The full SQL script
If you want to rebuild everything at once, here is the whole script: the sample data and the SQL check behind every result above.
Show the full SQL script (sample data and every check)
-- ========================================================================
-- Power BI Interview Q&A #10 - Real-world manager scenarios
-- TechBrothersIT. Sample data is invented for teaching.
-- Standard SQL, tested on PostgreSQL 16. Runs top to bottom in one go.
-- Run it in an empty database or schema: other videos reuse table names
-- like dim_customer, and their leftover tables can block the DROPs below.
-- PostgreSQL example: CREATE SCHEMA pbi_q10; SET search_path TO pbi_q10;
-- SQL Server: write DATE '2026-06-01' as CAST('2026-06-01' AS DATE).
-- ========================================================================
-- Step 0: create and load the sample data
DROP TABLE IF EXISTS fact_sales;
DROP TABLE IF EXISTS dim_product;
DROP TABLE IF EXISTS dim_customer;
DROP TABLE IF EXISTS dim_date;
CREATE TABLE dim_product (product_key INT PRIMARY KEY, product VARCHAR(30), category VARCHAR(20));
INSERT INTO dim_product VALUES
(1, 'Laptop Stand', 'Accessories'), (2, 'USB-C Cable', 'Accessories'),
(3, 'Monitor', 'Electronics'), (4, 'Keyboard', 'Electronics'),
(5, 'Desk Lamp', 'Home');
CREATE TABLE dim_customer (customer_key INT PRIMARY KEY, customer VARCHAR(30), city VARCHAR(20), region VARCHAR(10), email VARCHAR(40));
INSERT INTO dim_customer VALUES
(1, 'Sara Khan', 'Toronto', 'East', 'sara@tbshop.com'),
(2, 'Omar Ali', 'Dallas', 'West', 'omar@tbshop.com'),
(3, 'Lina Park', 'Seattle', 'West', 'lina@tbshop.com'),
(4, 'Mei Chen', 'Boston', 'East', 'mei@tbshop.com');
-- one row per day, 2025-01-01 .. 2026-12-31 (calendar year = fiscal year here)
CREATE TABLE dim_date (date DATE PRIMARY KEY, year INT, quarter VARCHAR(2), month_no INT, month VARCHAR(3));
INSERT INTO dim_date
SELECT d, EXTRACT(YEAR FROM d), 'Q' || EXTRACT(QUARTER FROM d), EXTRACT(MONTH FROM d), TO_CHAR(d, 'Mon')
FROM generate_series(DATE '2025-01-01', DATE '2026-12-31', INTERVAL '1 day') AS g(d);
CREATE TABLE fact_sales (
sale_id INT PRIMARY KEY,
order_date DATE REFERENCES dim_date(date),
product_key INT REFERENCES dim_product(product_key),
customer_key INT REFERENCES dim_customer(customer_key),
qty INT,
unit_price DECIMAL(10,2)
);
INSERT INTO fact_sales VALUES
( 1, '2025-01-10', 1, 1, 2, 40.00), ( 2, '2025-01-22', 3, 2, 1, 250.00),
( 3, '2025-02-05', 2, 3, 5, 10.00), ( 4, '2025-02-18', 5, 4, 1, 60.00),
( 5, '2025-03-03', 4, 1, 2, 50.00), ( 6, '2025-03-27', 3, 3, 1, 250.00),
( 7, '2026-01-08', 1, 2, 3, 40.00), ( 8, '2026-01-25', 3, 1, 1, 250.00),
( 9, '2026-02-11', 2, 4, 4, 10.00), (10, '2026-02-20', 4, 3, 2, 50.00),
(11, '2026-03-09', 5, 2, 2, 60.00), (12, '2026-03-30', 3, 4, 2, 250.00);
-- Step 1: March 2026 revenue: the sales report vs the regional report (hidden East page filter)
SELECT SUM(f.qty * f.unit_price) AS sales_report,
SUM(CASE WHEN c.region = 'East' THEN f.qty * f.unit_price END) AS region_report,
SUM(f.qty * f.unit_price) - SUM(CASE WHEN c.region = 'East' THEN f.qty * f.unit_price END) AS gap
FROM fact_sales f
JOIN dim_date d ON d.date = f.order_date
JOIN dim_customer c ON c.customer_key = f.customer_key
WHERE d.year = 2026 AND d.month = 'Mar';
-- Step 2: Split the gap by region (same as the DAX query view query)
SELECT c.region, SUM(f.qty * f.unit_price) AS revenue
FROM fact_sales f
JOIN dim_date d ON d.date = f.order_date
JOIN dim_customer c ON c.customer_key = f.customer_key
WHERE d.year = 2026 AND d.month = 'Mar'
GROUP BY c.region
ORDER BY c.region;
-- Step 3: New KPI: average order value by year, validated against the source
SELECT d.year, SUM(f.qty * f.unit_price) AS sales, COUNT(*) AS orders,
CAST(SUM(f.qty * f.unit_price) / COUNT(*) AS DECIMAL(10,2)) AS aov
FROM fact_sales f JOIN dim_date d ON d.date = f.order_date
GROUP BY d.year
ORDER BY d.year;
All 10 parts are listed on the Real Time Power BI Interview Questions and Answers page on this blog.
The sample data on this page is invented for teaching. The result tables were produced by running the same calculation in SQL on PostgreSQL 16 over that sample data (open "Check this result yourself" under any result), so you can rebuild every number in Power BI Desktop and compare.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.