Easy Power BI Interview Questions

Power BI is a business intelligence platform for connecting to data, modelling it and building interactive reports and dashboards. Main components are Power BI Desktop for building reports, Power BI Service (part of Microsoft Fabric) for publishing, sharing and refresh, Power BI Mobile apps for viewing, the on-premises data gateway for refreshing local sources, and Power BI Report Server for fully on-premises hosting of paginated and Power BI reports.

A report is a multi-page, fully interactive document built on one semantic model, with slicers, filters, drill-through and cross-highlighting. A dashboard is a single-page canvas in the Power BI Service made of pinned tiles that can come from several reports and models; it is used for a quick at-a-glance view. Dashboards are created only in the Service, while reports are usually built in Desktop.

First connect to sources such as Excel, SQL Server or SharePoint and clean the data in Power Query. Then build a data model with relationships, ideally a star schema, and write DAX measures. Next design report visuals and interactions in Desktop. Publish to a workspace in the Power BI Service, set scheduled refresh through a gateway if needed, apply row-level security and share through an app or dashboard.

A semantic model, earlier called a dataset, is the published data model behind reports: tables, relationships, measures, hierarchies, security roles and refresh settings. Many reports can connect to one shared semantic model, which keeps business logic and numbers consistent across teams. Certified or promoted endorsements help users find trusted models. Build permission controls who can create new reports on it.

Excel is flexible for ad hoc analysis and small models but struggles with large data, version control and secure sharing. Power BI handles millions of rows with a compressed columnar engine, central semantic models, scheduled refresh, row-level security and interactive web and mobile sharing. They work together: Power Query and Power Pivot exist in both, and users can analyse Power BI models in Excel.

A workspace is a container in the Power BI Service for semantic models, reports, dashboards, dataflows and other items that a team works on together. Roles are Admin, Member, Contributor and Viewer. Admins manage everything including access, Members can publish and share, Contributors can create and edit content but not share, and Viewers can only view. Consumers are usually given access through an app instead.

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.

Use Home, Get Data, SQL Server. Enter the server name and optionally the database, choose Import or DirectQuery, and optionally paste a native SQL query under Advanced options. Choose Windows or database authentication, then pick tables in the Navigator and select Transform Data to clean them in Power Query. For scheduled refresh of an on-premises server, an on-premises data gateway must be configured in the Service.

In Desktop, choose Publish and select a workspace. In the Service, set up the semantic model's credentials and scheduled refresh. Then create or update an app from the workspace, choose the reports and audiences, and grant access to user groups. Apps give consumers a clean, stable view while authors keep working in the workspace. Avoid sharing from My workspace for team content.

I like turning raw data into clear answers that people can act on. In my projects I enjoyed the full flow: cleaning messy Excel and SQL data, designing a proper model, writing DAX and making reports that users actually open every day. Power BI is widely used across Indian companies and global clients, so the role offers strong growth into data analytics, data engineering with Fabric, or BI architecture.

Power Query is the data connection and transformation engine in Power BI, Excel, dataflows and Fabric Data Factory. It lets you connect to hundreds of sources and shape data with a recorded series of steps, such as removing columns, changing types, merging and unpivoting. Behind the interface each step is written in the M language. Steps re-run automatically on every refresh, making cleaning repeatable.

Merge is like a SQL join: it combines columns from two tables based on matching key columns, with join kinds like left outer, inner, full outer, left anti and right anti. Append stacks rows of tables with the same structure on top of each other, like a SQL UNION ALL, for example combining monthly sales files. Merge widens a table, append lengthens it.

Unpivot turns columns into rows, creating attribute and value columns. It is used when data comes in a wide, report-style layout, such as months as separate columns Jan, Feb, Mar. Unpivoting them into a Month column and an Amount column gives a tall, tidy table that works well with relationships, a date table and DAX. Unpivot Other Columns is safer because new months are handled automatically.

Correct data types make sorting, filtering, aggregation and relationships work properly; text-typed numbers cannot be summed and mismatched key types break relationships. Types also affect compression and model size, for example whole numbers compress better than decimals or text. Set types once near the end of a query and avoid repeated automatic Changed Type steps, which can fail when column names change.

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 first understand the goal behind the changes, because frequent changes often mean the core question was not clear. I write down agreed requirements and a mock-up, then deliver in small iterations so feedback comes early. In one project weekly 20-minute reviews cut rework a lot, and changes that were large were logged for the next version rather than added mid-sprint.

A star schema has central fact tables holding numeric events, such as sales lines, linked to dimension tables describing them, such as Date, Product, Customer and Store. Power BI's engine and DAX are optimised for this shape: filters flow cleanly from dimensions to facts, measures are simpler, models compress better and reports run faster. Flat single tables or snowflakes usually need more complex DAX.

Fact tables store measurable events at a defined grain, such as one row per order line, with numeric columns like quantity and amount and foreign keys to dimensions. Dimension tables store descriptive attributes used for filtering and grouping, such as product name, category, region or calendar month, with one row per key. Facts are usually long and narrow; dimensions are shorter and wider.

Cardinality describes how keys match between two tables. One-to-many is the normal type, from a dimension's unique key to a fact table's repeating key. One-to-one links tables with unique keys on both sides and often means they should be merged. Many-to-many allows duplicates on both sides; it is supported but can produce confusing totals, so a bridge table is often clearer.

A date table gives one row per day with columns like year, quarter, month, week and fiscal periods, so all facts can be analysed on a common calendar. Time intelligence functions such as TOTALYTD and SAMEPERIODLASTYEAR need a contiguous date column, and the table should be marked as a date table. It also avoids the many hidden auto date/time tables that bloat the model.

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.

In Table view or Model view, select the date table, choose Table tools, Mark as date table, and select the date column, which must be unique, contiguous and without blanks. This tells Power BI to use it for time intelligence and disables the auto date hierarchy for that table. Also turn off Auto date/time under Options, Data Load to avoid hidden date tables for every date column.

By default month names sort alphabetically, April first. In the Date table add a Month Number column, select the Month name column, then choose Column tools, Sort by column, Month Number. The same applies to weekday names and fiscal months. The sort column must have one value per name value, otherwise Power BI shows an error.

I use a simple analogy: the fact table is the list of transactions, and dimensions are the labels we use to slice them, like date, product and region. I show the model diagram with only main tables and explain that slicers work through these links. Then I demonstrate one visual changing when a slicer changes, which makes the idea concrete quickly.

DAX, Data Analysis Expressions, is the formula language for Power BI, Analysis Services and Power Pivot. It is used to create measures, calculated columns, calculated tables and security rules. DAX looks like Excel formulas but works on tables and columns with filter context. Key functions include SUM, CALCULATE, FILTER, ALL, RELATED, time intelligence functions and iterators like SUMX.

A calculated column is computed row by row at refresh and stored in the model, so it uses memory and can be used in slicers, filters and relationships, for example Profit = Sales[Amount] - Sales[Cost]. A measure is computed at query time in the current filter context and is not stored, for example Total Profit = SUM(Sales[Profit]). Prefer measures for aggregations and use columns only when you need to slice by the value.

SUM aggregates a single column, such as SUM(Sales[Amount]). SUMX is an iterator: it evaluates an expression for each row of a table and then sums the results, such as SUMX(Sales, Sales[Qty] * Sales[Price]). Use SUMX when you need row-level calculations before aggregating. Other iterators include AVERAGEX, MAXX, COUNTX and RANKX.

RELATED fetches a value from the one side of a relationship into a row context on the many side, such as RELATED('Product'[Category]) in a Sales calculated column. RELATEDTABLE goes the other way, returning the related rows from the many side for the current row, often wrapped in COUNTROWS to count a customer's orders. Both need an existing relationship and a row context.

DIVIDE(numerator, denominator, alternate) handles division by zero and blank denominators safely, returning blank or the alternate value instead of an error or infinity. It makes measures like margin percentage cleaner without IF checks. The division operator is slightly faster when you are certain the denominator is never zero, but DIVIDE is the safer default in reports.

COUNT counts non-blank values in a column, COUNTA counts non-blank values of any type, COUNTROWS counts rows in a table, and DISTINCTCOUNT counts unique values in a column. For example, COUNTROWS(Sales) gives order lines while DISTINCTCOUNT(Sales[CustomerID]) gives active customers. COUNTROWS is generally preferred for counting records because its intent is clearer.

I learn by building tiny examples. For filter context I made a small model with five products and wrote measures with and without ALL, KEEPFILTERS and ALLSELECTED, checking each result in a table visual. I also read documentation and use DAX Studio to see queries. Explaining it to a teammate afterwards showed me which parts I had not fully understood.

Time intelligence functions compare values across periods using a proper date table, for example year-to-date, same period last year, moving averages and quarter-over-quarter growth. Key functions are TOTALYTD, DATESYTD, SAMEPERIODLASTYEAR, DATEADD, PARALLELPERIOD and DATESINPERIOD. They return sets of dates used as CALCULATE filters, so the date table must be contiguous, marked as a date table and related to the facts.

A good dashboard answers specific questions for a specific audience. Put the most important KPIs at the top left, follow a logical flow from summary to detail, use a few consistent colours with one highlight colour, and choose simple visuals like bar and line charts. Remove clutter such as 3D effects and heavy borders, label clearly, show context like targets or last year, and keep each page to a manageable number of visuals.

Match the chart to the question. Use bar or column charts to compare categories, line charts for trends over time, stacked bars for part-to-whole across few categories, scatter charts for relationships, maps only for true geographic patterns, cards and KPI visuals for single numbers, and tables or matrices when users need exact values. Avoid pie charts with more than four or five slices.

Drill-down moves within the same visual through a hierarchy, such as Year to Quarter to Month, using the drill buttons. Drill-through moves the user to a separate detail page filtered by the selected item, such as right-clicking a customer to open a Customer Details page. Drill-through pages are set up by adding fields to the drill-through well and include a back button.

Conditional formatting changes colours, icons, data bars or font based on values or rules, helping users spot good and bad performance quickly. You can apply it to table and matrix cells, backgrounds, font colour, chart data colours and titles using field values, rules or a measure that returns a colour code. A measure returning hex colours gives full control, such as red when below target.

A report theme is a JSON file that sets default colours, fonts, visual styles and backgrounds for all visuals. Using a company theme keeps reports consistent with brand guidelines and saves formatting time, since new visuals adopt it automatically. Themes can be built in Desktop's theme customiser or edited as JSON and shared across the team as a standard.

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.

Create a new page named Customer Details, add visuals showing customer information, orders and trends, and drag Customer Name or Customer ID into the Drill through well in the Visualizations pane. Power BI adds a back button automatically. Users can now right-click a customer in any visual and choose Drill through, Customer Details, and the page opens filtered to that customer.

Row-level security restricts which rows of data a user can see in a semantic model. You define roles in Desktop with DAX filter expressions on tables, such as Store[Region] = "North", then assign users or security groups to roles in the Service. Filters propagate through relationships to fact tables. RLS applies to viewers; workspace Admins, Members and Contributors can see all data.

The on-premises data gateway is software installed on a machine inside the company network that securely connects the Power BI Service to on-premises sources such as SQL Server, file shares or Oracle. It is needed for scheduled refresh and DirectQuery to those sources. Standard mode supports many users and is centrally managed; personal mode is for a single user. Cloud sources usually do not need a gateway.

Subscriptions email a snapshot of a report page or dashboard to users on a schedule, or after data refresh, with a link to the live content. Data alerts notify users when a value on a dashboard card, KPI or gauge tile crosses a threshold, such as daily sales below a target. Paginated reports support subscriptions with attachments like PDF or Excel. Power Automate can extend alerts into workflows.

In Desktop use Modeling, View as, select a role and optionally Other user with an email to simulate dynamic RLS, and check visuals show only expected rows. In the Service open the semantic model's Security settings, select a role and use Test as role. Test with real sample users from different regions and a user with no mapping, who should see no data, and confirm totals match expectations.

Open the workspace, select the semantic model's settings, and check Data source credentials and Gateway connection, mapping on-premises sources to a gateway. Then turn on Scheduled refresh, choose time zone, frequency and time slots, and add failure notification contacts. Pro allows up to 8 refreshes per day and Premium or Fabric capacity up to 48. Stagger refresh times to avoid source load peaks.

I log every request with its business goal, deadline and effort, and agree priorities with my manager instead of choosing alone. I reuse shared semantic models so new reports are faster, and I communicate realistic timelines early. In one quarter this helped me deliver eight reports, with two lower-priority ones moved by a week after discussion with requesters, without escalations.

Remove unused columns and rows, avoid high-cardinality columns like GUIDs and datetime with seconds by splitting date and time or rounding, use integer surrogate keys, prefer measures over calculated columns, turn off Auto date/time, and choose the right data types, such as fixed decimal. Load only the history users need, and summarise data where detail is not required.

Each visual sends at least one DAX query when the page loads or when filters change, and visuals render in the browser. A page with 30 visuals, especially complex tables and custom visuals, sends many queries in parallel, competing for capacity and causing long load times. Reducing visuals, combining cards into one multi-row card or using tooltips and drill-through pages improves speed.

Open View, Performance Analyzer, click Start recording and then Refresh visuals or interact with the page. Each visual shows total duration split into DAX query, visual display and other. Sort by duration to find the slowest visuals, expand them and choose Copy query to paste into DAX Studio for deeper analysis. Clear the cache between tests so timings are realistic.

Power BI releases features monthly, so I read the monthly update blog and Fabric release notes, try new features on a test report, and follow community experts and forums. I keep a short list of features relevant to our team, such as visual calculations or TMDL view, and share a five-minute demo in team meetings when something will save us effort.

M is the language of Power Query, used at refresh time to extract, clean and shape data before it enters the model, such as merging tables or splitting columns. DAX is used after data is loaded, to define measures, calculated columns and security that evaluate in filter context at query time. As a rule, do row-level shaping in M or the source and dynamic calculations in DAX.

Use the new Card visual or a KPI visual with a main measure such as Total Sales, a target measure and a variance percent measure. Add conditional formatting so the variance turns red below target and green above it, and include a small trend if space allows. Keep labels short, such as Sales vs Target, and show the comparison period in the subtitle.