Scenario-Based Power BI Interview Questions

I would build a dashboard in the Power BI Service and pin the key KPI tiles from each report, so the manager sees all areas on one page and can click through to details. If the KPIs need cross-filtering together, a better option is a summary report built on a shared model or composite model that combines the needed tables, published inside an app.

Importing 2 billion rows is heavy and refresh-bound, so I would use DirectQuery or, on Fabric with data in OneLake, Direct Lake. To keep reports fast I would add aggregation tables in Import mode for common summary queries, keep detail in DirectQuery, and use a composite model. I would also make sure the warehouse has good indexing or clustering for the filter columns.

I would check the refresh history in the Service for errors or whether the refresh actually ran, confirm the gateway is online and has valid credentials, and verify the source itself has the latest data. Then check for cached dashboard tiles, query caching, or an incremental refresh policy that excludes recent days. Also confirm users are viewing the right workspace or app version, which may need republishing.

Giving all 500 viewers Pro licences is one option. If there are many viewers and heavy models, Fabric capacity at F64 or above lets free-licence users view content in workspaces on that capacity, while report creators still need Pro or PPU. I would compare costs, workload size and features like larger models with IT, and recommend the option that fits usage, without assuming one choice fits all.

Use the Folder connector, or SharePoint Folder for files on SharePoint, pointing to the folder, filter to the right file extension and naming pattern, then use Combine Files. Power Query creates a sample-file transform function applied to every file and appends the results. New files dropped into the folder are included on the next refresh, as long as their structure matches the sample.

I would check query folding with View Native Query or the folding indicators and move non-folding steps after folding ones. Filter rows and remove unused columns as early as possible, push joins and aggregations into SQL views, avoid row-by-row custom functions over large tables, and disable load for staging queries. For large fact tables, set up incremental refresh so only recent partitions reload.

I would fix the immediate step, then reduce dependence on exact column names: avoid hard-coded Changed Type steps on all columns, select only needed columns with MissingField.Ignore where suitable, and standardise names in one place. I would agree a data contract or SQL view with the source team so renames go through a stable interface, and set up refresh failure notifications.

I would create or import a region mapping table with code and name, clean both sides by trimming spaces and fixing case, then merge in Power Query or better, build a Region dimension table with both columns and relate sales by code and targets by name to it. Unmatched rows should be checked using a left anti join so missing mappings are fixed rather than silently dropped.

For exact duplicates, Remove Duplicates on the key column. For spelling variations, use fuzzy matching in Merge Queries with a similarity threshold and transformation table, review results, and maintain a mapping table of approved matches. The best long-term fix is to use a stable customer ID from the source system and report data quality issues to the owner rather than cleaning endlessly in Power BI.

I would identify the grain, such as one row per order line, and split descriptive attributes into dimension tables like Customer, Product, Store and Date using Reference queries and Remove Duplicates on keys. The fact table keeps keys and numeric columns only. Then create one-to-many single-direction relationships. This reduces size, simplifies DAX and makes slicers faster and more reliable.

I would check the relationship path in model view: whether Targets is related to the Product or Category dimension at all, whether the relationship is active, and its cross-filter direction. If Targets are at category level, it needs a relationship to a Category table that also filters Product. Also check whether visual interactions were turned off for that slicer and whether the measure uses ALL or REMOVEFILTERS.

I would keep the Date table related to OrderDate as the active relationship and add an inactive relationship to DeliveryDate. Then create measures like Sales by Delivery Date using USERELATIONSHIP. If users need separate slicers for both dates at the same time, I would create a second Delivery Date table as a role-playing copy related actively to the delivery column.

Likely a relationship is joining at the wrong grain or creating a many-to-many path, so rows get duplicated in filtering, or a bi-directional relationship is letting one fact filter another unexpectedly. I would check the relationships, keys and cardinality, make filters flow from shared dimensions only, and verify a measure against a known total in the source system using a simple table visual.

I would explain that a star schema with separate Customer and Sales tables is easier for them in practice: slicers are cleaner, totals are correct and reports run faster. To keep it user-friendly I would hide key columns, organise measures in display folders and name fields in plain language. I would show them the field list so they see simplicity on the surface.

The measure is probably ignoring the filter context of the rows, for example using ALL on that column or table, or the row field comes from a table that is not related to the fact table, so its filter cannot reach the data. I would check relationships in model view, the direction of filtering, and any ALL or REMOVEFILTERS in the measure.

Usually not. A measure's total is calculated in the total's own filter context, not by adding the visible rows. For non-additive measures like averages, distinct counts or ratios this differs from the row sum. If business wants the sum of rows, I write it explicitly with SUMX over the row values, for example SUMX(VALUES('Product'[Product]), [My Measure]).

I would move simple row-level logic into Power Query or the source SQL, where it compresses better and can fold, and replace aggregations stored as columns with measures. High-cardinality columns such as concatenated keys or precise timestamps should be removed or split. Then check model size with VertiPaq Analyzer in DAX Studio to confirm which columns used the most memory.

I would replace FILTER over the whole fact table with column filters in CALCULATE, such as CALCULATE([Sales], Sales[Channel] = "Online"), which the engine can apply efficiently. If a condition uses a measure, iterate over a small dimension table instead, like FILTER(VALUES(Customer[CustomerID]), [Sales] > 10000). Then test in DAX Studio with server timings before and after.

Comparing a partial year with a full last year understates growth. I would limit last year to the same date range, for example using the last date with sales this year and filtering last year's dates up to the matching day, or compare year-to-date to previous year-to-date. I would label the visual clearly as YTD versus same period last year so readers understand it.

The issue is the opposite for many teams: YTD repeats the last value for future months. I would add a condition so the measure returns BLANK when the period starts after the last date with data, for example IF(MIN('Date'[Date]) > [Last Sales Date], BLANK(), TOTALYTD(...)). Alternatively add a column flagging dates up to today in the date table and filter the visual on it.

I would create a calculation group, such as Time Calculation, with items Current, YTD, PY and YoY % that use SELECTEDMEASURE() wrapped in the time intelligence logic, and set format strings for percent items. Users pick the item from a slicer or matrix columns. This keeps the model small and consistent. I would document it because calculation groups change measure behaviour everywhere.

I would create a calculated table of product names plus an Others row, related or disconnected, and a measure that ranks products with RANKX over ALL products. For rows ranked 1 to 5 it returns their sales; for Others it returns total sales minus the top 5. TOPN helps compute the top 5 total. The rank should respect slicers like year so the top 5 updates dynamically.

I would test the measure at each level of the matrix using a table visual and check how filter context differs at the subtotal. Often logic uses SELECTEDVALUE or MAX, which return blank or misleading results when several values are visible. I would use ISINSCOPE to branch logic or SUMX over the grouping column for additive results, and validate with DAX Studio queries.

I would ask which decisions the page supports and keep only visuals that answer those questions. Then group related KPIs into a top row of cards, keep two or three main charts, and move details to drill-through or tooltip pages. Slicers can move into a collapsible panel using bookmarks. Fewer visuals also make the page load faster.

I would create a measure for achievement percentage, DIVIDE(Sales, Target), and a status measure returning a colour or icon based on thresholds agreed with leadership, such as below 90 percent red, 90 to 100 amber, above 100 green. Apply it through conditional formatting in a matrix or as icon rules. I would also add text or icons so status is clear without colour.

I would create a mobile layout in Desktop through View, Mobile layout, placing the most important cards and charts in a single column with larger fonts. Remove or simplify dense tables, check slicer usability on touch screens and test in the Power BI mobile app. If mobile use is common, I might design a separate concise summary page for mobile users.

I would understand what they want to see, usually share of total by category, then show a quick comparison: a sorted bar chart beside the pie, explaining that bars make small differences readable while 3D distorts sizes. Offering a donut with top five plus Others is a compromise. Usually seeing both side by side convinces them, and the final choice remains theirs.

I would start with three to five headline KPIs versus target and last year at the top, then a trend chart showing the quarter's movement, then a breakdown by region or product showing what drove the change, and finally a short text box or smart narrative stating key takeaways and actions. Each element answers the next natural question, and details live on drill-through pages.

Large detail tables are rarely read on screen. I would understand the real need: if users want to search specific records, add slicers or a search filter and a drill-through page; if they need to export, provide a paginated report or analyse in Excel. On the main page I would show aggregated results with top N filters, which improves both speed and readability.

This happens when an expression like VALUES or a column reference returns several rows where a scalar is needed, for example in IF or comparison. I would use SELECTEDVALUE with a fallback, wrap the column in an aggregation like MAX or SUM, or use HASONEVALUE to check first. If iteration is needed, use SUMX or another iterator over VALUES instead.

I would build dynamic RLS with a security table of Email and Region, related to the Region dimension, and a role filter Security[Email] = USERPRINCIPALNAME(). The CEO and other full-access users get an 'All' flag handled in the rule, or are placed in a separate role with no filter. I would test with View as role in Desktop and in the Service before publishing the app.

I would flatten the employee hierarchy with PATH(Employee[EmployeeID], Employee[ManagerID]) into a path column, then in the role filter use PATHCONTAINS(Employee[Path], LOOKUPVALUE(Employee[EmployeeID], Employee[Email], USERPRINCIPALNAME())). Each manager then sees every employee below them at any depth. I would test with a few known hierarchies and check performance on a large employee table.

I would check the refresh history error details, confirm the gateway machine is on and the gateway service is running and updated, and verify data source credentials in the gateway connection have not expired. Then test connectivity from the gateway machine to the source and check that the source names in the model exactly match the gateway data source. Gateway logs and network or firewall changes are next.

I would set up separate Development, Test and Production workspaces with a deployment pipeline, store PBIP files in Git, and route requests through a simple backlog. Changes are built in Dev, reviewed by a key user in Test and deployed to Production on a release schedule. Users consume through an app, so production stays stable and changes are traceable.

I would review whether export is really needed and adjust export settings per report or at tenant level, for example allowing only summarised data. I would apply Purview sensitivity labels so exported files keep protection, use RLS and OLS to limit what can be exported, and monitor exports through the activity log. For legitimate detailed needs, a governed paginated report is better.

I would run Performance Analyzer to find the slowest visuals, copy their DAX queries into DAX Studio and check server timings. Common fixes are rewriting measures that iterate large fact tables, removing bi-directional relationships, reducing visuals on the page, and shrinking the model by removing high-cardinality columns. If the source is DirectQuery, I would add aggregations or move to Import. Then re-measure after each change.

I would analyse it with VertiPaq Analyzer to find the largest columns and tables, remove unused columns, split or round datetime columns, replace text keys with integer keys and drop history users do not need. Then set up incremental refresh on large fact tables so only recent partitions reload. If needed, push heavy transformations upstream into the warehouse and consider Direct Lake on Fabric.

I would check which queries are slow using Performance Analyzer and the database's query logs. Then reduce visuals per page, add Import-mode aggregation tables for common summary views, set dimensions to Dual mode, and apply query reduction options so slicers send queries only on Apply. On the source side, indexes or columnstore tables help. If real-time is not essential, moving to Import with frequent refresh may be simpler.

Morning peaks often combine many users opening reports with heavy scheduled refreshes running at the same time. I would check the Fabric Capacity Metrics app for throttling and identify the heaviest items. Fixes include moving refreshes to off-peak hours, optimising the largest semantic models, spreading workloads across capacities, or scaling the capacity. Communicating refresh windows to teams also helps.

I would store repeated sub-expressions in variables so they are computed once, replace nested IF chains with SWITCH(TRUE(), ...), use column filters instead of FILTER over tables, and avoid context transition inside large iterators. I would also check whether some logic can move into a calculated column or Power Query at refresh time. DAX Studio timings confirm whether formula engine time drops.

I would identify the common tables and measures, then build one certified shared semantic model with a proper star schema and agreed measure definitions. Reports would be rebuilt or rebound as thin reports using live connections to it, starting with the most used ones from activity data. Old models are retired gradually. This cuts refresh load, removes conflicting numbers and makes changes in one place.

I would compare row counts and totals at a high level first, then drill down by date and key dimensions to find where the difference starts. Merge both tables with a full outer join on the business key and use anti joins to list missing rows, then compare values on matched rows. Common causes are different cut-off times, filters, duplicates, time zones or currency conversions.

I reconcile key measures with the finance system for several periods before launch and document definitions, such as whether revenue is net of returns and taxes, in measure descriptions and a glossary page. I add a refresh timestamp to each page and set up data quality checks. When differences appear, I explain them quickly. Certified semantic models signal that numbers went through review.

I would use Power BI Embedded with the 'embed for your customers' pattern, also called app owns data. The application authenticates with a service principal, generates embed tokens and passes customer identity for RLS, so each customer sees only their data. It needs Fabric or embedded capacity. I would design RLS carefully, test token expiry and monitor capacity load as the customer base grows.

I would export usage from the activity log or the workspace usage metrics, list items not viewed in 90 days and confirm with owners before archiving. Duplicate models are consolidated into shared semantic models, naming standards are applied, and workspaces are split by domain with clear owners. A quarterly review keeps it tidy. This also reduces refresh load on capacity.

Desktop runs on a local machine with its own memory and only you as user, while the Service shares capacity with other workloads and users, so throttling or memory pressure may appear. Also check RLS, which adds filters that do not exist in Desktop tests, gateway latency for DirectQuery, and differences in data volume after a full refresh. Testing with View as role and capacity metrics helps pinpoint it.

A slicer with thousands of values sends heavy queries and is hard to use. I would add a hierarchy so users pick category and subcategory first, enable the slicer search box, and consider a text filter visual for direct search. Apply buttons in query reduction settings stop queries on every click. If the slicer depends on a measure-filtered list, I would simplify that logic.