ACCENTURE POWER BI DEVELOPER

INTERVIEW QUESTIONS
0-3 YOE
9-11 LPA
Explain the concept of context transition in DAX and
provide an example.

What is Context in DAX?

DAX (Data Analysis Expressions) operates within two types of context:
• Row Context: Exists when DAX evaluates an expression row by row (e.g., in
calculated columns or iterating functions like SUMX).
• Filter Context: Comes from report filters, slicers, or explicit filters in CALCULATE.
What is Context Transition?
Context transition is the automatic conversion of row context into filter context. This is
triggered when CALCULATE or CALCULATETABLE is used.
Without context transition, a measure would not "respect" the row it is operating on in
calculated columns or row-level operations.
Example:
Let’s say you have a table Sales:
ProductID SalesAmount
1 100
2 200
And a related Products table:
ProductID ProductName
1 Apple
2 Banana
You define this measure:
Total Sales = SUM(Sales[SalesAmount])
Now, in the Products table, if you create a calculated column like this:
Sales Per Product = CALCULATE([Total Sales])
What's happening here?
• Each row of Products is being evaluated.
• CALCULATE triggers context transition, converting the current row (e.g., ProductID
= 1) into a filter context.
• So Total Sales is now filtered to ProductID = 1, and the result becomes 100.
Without CALCULATE:
If you used [Total Sales] directly in a calculated column, it would return the same total for
every row—no filter context would be applied.

How would you optimize a complex Power BI report for

faster performance?

Optimizing Power BI reports is crucial for usability, especially when datasets are large and
visuals are numerous.
Key Optimization Techniques:
1. Efficient Data Modeling
• Use Star Schema: Avoid snowflake schemas; flatten dimensions where feasible.
• Remove Unnecessary Columns & Tables: Only import what you need.
• Use Appropriate Data Types: Smaller data types reduce memory usage.
2. DAX Optimization
• Avoid iterator functions (SUMX, FILTER) where a simple aggregation (SUM,
COUNT) works.
• Minimize use of CALCULATE and FILTER if not necessary.
• Use variables in measures to avoid recalculating the same logic multiple times.
3. Manage Relationships Smartly
• Avoid bi-directional relationships unless absolutely required.
• Use inactive relationships with USERELATIONSHIP() if you need alternate filtering
without introducing complexity.
4. Control Visual Complexity
• Limit number of visuals on a page.
• Avoid unnecessary slicers and filters.
• Use bookmarks and drill-throughs to split logic across pages.
5. Use Aggregations and Summarized Tables
• Pre-aggregate data at the source or use Power BI aggregations.
• Create summary tables in Power Query for frequently accessed aggregates.
6. Optimize Query Folding
• Ensure transformations in Power Query (M) support query folding to offload heavy
lifting to the data source.
7. Use Performance Analyzer Tool
• Use this built-in tool to track which visuals are taking time.
• Focus your optimization efforts on the slowest DAX queries or visuals.
8. Optimize Data Refresh
• Enable incremental refresh on large datasets.
• Disable auto date/time feature unless needed.

Describe the process of creating and using calculation

groups in Power BI.

What are Calculation Groups?

Calculation Groups are a tabular model feature (available through Tabular Editor or Visual
Studio) that allows you to create reusable logic for multiple measures, reducing
redundancy and improving model maintainability.
Purpose:
Instead of writing multiple similar DAX measures (e.g., YTD, QTD, MTD, PY, etc.) for each
metric, you can write one base measure and apply transformations via calculation items.

How Calculation Groups Work:

• A Calculation Group contains Calculation Items, which define logic transformations
(like "YTD", "Previous Year", "Variance").
• When applied, the calculation logic modifies the filter or time context of a base
measure.

How to Create a Calculation Group (Using Tabular Editor):

1. Open Tabular Editor (from Power BI → External Tools).
2. Right-click on the model → Create New → Calculation Group.
3. Name it (e.g., Time Intelligence).
4. Add Calculation Items (e.g.):
o Name: YTD
Expression:
CALCULATE(SELECTEDMEASURE(), DATESYTD('Date'[Date]))
o Name: Previous Year
Expression:
CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR('Date'[Date]))
5. Save changes → Refresh Power BI → Calculation group appears as a slicer or field.

Example Scenario:
You have 10 KPIs like Revenue, Profit, Sales Volume, etc. Instead of writing 10 YTD, 10 QTD,
and 10 PY measures (30 total), you:
• Write only the 10 base measures.
• Apply the Time Intelligence calculation group → drastically reduces the number of DAX
measures and improves maintainability.

How would you handle large datasets in Power BI without

compromising performance?

Handling large datasets in Power BI requires a combination of data modeling,

transformation, and visualization best practices to ensure fast performance and
scalability.

Strategies to Handle Large Datasets Efficiently:

1. Use Import Mode (when possible)

• Preferred for performance.
• Only use DirectQuery if real-time data is critical and your data source is optimized (e.g.,
 using indexes, partitions).

2. Apply Data Reduction at the Source

• Use SQL views or filtered queries to pull only necessary data.
• Apply date filters, relevant KPIs, and exclude archived data not used in reporting.

3. Use Incremental Refresh

• Refresh only new or changed data rather than the full dataset.
• Great for partitioning time-based data (like transactions, logs, sales, etc.)

4. Use Aggregated Tables

• Pre-aggregate data into summary tables (e.g., Monthly Sales per Region).
• Reduces the size of the model and speeds up visual rendering.

5. Optimize DAX and Measures

• Avoid nested or repeated calculations.
• Use variables to store intermediate results.
• Replace heavy iterator functions (SUMX, FILTER) with native aggregations where
possible.

6. Disable Auto Date/Time

• This feature automatically creates a hidden date table per date column.
• Disable it in Options → Global → Data Load to reduce model size.

7. Efficient Data Modeling

• Follow star schema design.
• Minimize use of bi-directional relationships and avoid many-to-many where possible.
• Remove unused columns and hide unnecessary fields from the report view.

8. Use Performance Analyzer and DAX Studio

• Identify bottlenecks in visuals, slicers, or DAX measures.
• Use DAX Studio to analyze query performance and evaluate storage engine (SE) vs
formula engine (FE) operations.

Bonus Tips:
• Use Power BI Aggregations with DirectQuery for hybrid performance.
• Keep report pages light (≤6 visuals), use bookmarks for navigating between views.

What is a composite model in Power BI, and how can it be

used effectively?

What is a Composite Model?

A composite model in Power BI allows you to combine multiple data connectivity
modes in the same report — namely:
 • Import Mode
• DirectQuery Mode
• Dual Mode
This hybrid approach gives you the flexibility to balance performance and real-time
access.

Why Use a Composite Model?

In real-world scenarios, you might have:
• A large transactional table that must be in DirectQuery mode (e.g., live database)
• Smaller dimension/reference tables that can be imported
Composite models allow you to mix and match these based on:
• Performance needs
• Real-time reporting requirements
• Data refresh constraints

Key Concepts:
• Import Mode: Data is loaded into Power BI memory → faster but not real-time.
• DirectQuery Mode: Queries the data source live → real-time but slower.
• Dual Mode: Can act as either Import or DirectQuery based on context → helps
optimize performance.

How to Use Composite Models Effectively:

1. Enable "Allow composite models" under Preview features.
2. Use DirectQuery for large fact tables (like millions of rows).
3. Use Import mode for dimension tables (e.g., Region, Product, Calendar).
4. Set dimension tables to Dual Mode to share between both.

Example Use Case:

You build a sales dashboard:
• FactSales (large) → DirectQuery to ensure real-time sales data.
• DimProduct, DimRegion → Import or Dual for faster slicers and filters.
• DimDate → Dual mode, helps with time intelligence across both modes.

Limitations to Consider:
• Some DAX functions behave differently or are limited in DirectQuery.
• Relationships across different storage modes need careful management.
• May affect performance if not modeled properly.

How does the USERELATIONSHIP function work, and when

would you use it?

What is USERELATIONSHIP in DAX?

USERELATIONSHIP() is a DAX function used within CALCULATE to activate an inactive
relationship between two tables for the duration of that calculation only.
Power BI allows only one active relationship between two tables. If there are multiple
potential relationships, only one can be active — the rest remain inactive.

Syntax:
CALCULATE(<expression>, USERELATIONSHIP(Table1[Col], Table2[Col]))

Why Use USERELATIONSHIP?

You use it when:
• You need to use an alternate relationship for a specific calculation.
• You have two different relationships (e.g., OrderDate and ShipDate) with a Date
table and want to analyze based on both.

Example:
Suppose you have:
• Sales[OrderDate] and Sales[ShipDate]
• Date[Date]
You create:
• Active relationship → Date[Date] ↔ Sales[OrderDate]
• Inactive relationship → Date[Date] ↔ Sales[ShipDate]
Now you want to create a measure for Shipped Sales:
Shipped Sales =
CALCULATE(
SUM(Sales[SalesAmount]),
USERELATIONSHIP(Sales[ShipDate], Date[Date])
)
This tells Power BI: "For this calculation only, use the relationship based on ShipDate, not the
active OrderDate one."

Use Cases:
• Compare metrics across multiple dates (e.g., order vs. shipment).
• Toggle between primary and secondary date relationships dynamically.
• Financial reports comparing invoice vs. payment dates.

Explain how to use Power Query M language for advanced

data transformations.

What is Power Query M Language?

Power Query M is a functional, case-sensitive language used in Power BI (and also in
Excel and other Microsoft tools) for data transformation during the query editing stage
— before the data enters the data model.
It’s not DAX — M is used in the Power Query Editor, while DAX is used in the data model.

Key Use Cases for Advanced Transformations with M:

1. Custom Column Logic
You can write conditional logic using M functions:
= Table.AddColumn(Source, "Category", each if [Sales] > 1000 then "High" else "Low")

2. Combining Files from a Folder

Use Folder.Files() and then expand binary contents:
let
Source = Folder.Files("C:\SalesReports"),
Filtered = Table.SelectRows(Source, each Text.EndsWith([Extension], ".xlsx")),
Combined = Table.Combine(Excel.Workbook([Content]) for each row)
in
Combined

3. Creating Custom Functions

You can define your own reusable functions:
let
AddGST = (price as number) as number => price * 1.18
in
AddGST

4. Parameterizing Queries
M allows you to define parameters dynamically:
= Table.SelectRows(Source, each [Region] = ParameterRegion)
This is useful for filtering based on a user-selected region, product, etc.

5. Using Record and List Functions

M is powerful for record manipulation:
= Record.Field(Source{0}, "CustomerName")
Or for handling lists:
m
CopyEdit
= List.Sum({10, 20, 30}) // Output: 60

6. Advanced Filtering and Transformation

Apply regex-like text filtering:
= Table.SelectRows(Source, each Text.Contains([Product], "Laptop"))
Or unpivot and reshape data:
m
CopyEdit
= Table.UnpivotOtherColumns(Source, {"Product"}, "Attribute", "Value")

When to Use M Over GUI:

• When UI options are limited (like merging based on complex logic).
• When automating repetitive tasks.
• When dealing with dynamic column names or nested JSON/XML structures.
 Differentiate between CROSSFILTER and TREATAS in DAX.

Both CROSSFILTER() and TREATAS() are used in DAX to control filter propagation, but
they have very different purposes and syntax.

CROSSFILTER(): Control Relationship Direction

Purpose: Temporarily modify the filter direction between two related tables.
Syntax:
CROSSFILTER(Table1[Col], Table2[Col], Direction)
• Direction:
o "None" → disables filtering
o "OneWay" → filters only one way
o "Both" → bidirectional filtering
Use Case Example:
You have a relationship:
Customer[CustomerID] → Sales[CustomerID] (one-to-many)
To disable the filter:
Sales Total (No Filter) =
CALCULATE(SUM(Sales[Amount]), CROSSFILTER(Customer[CustomerID], Sales[CustomerID],
None))

TREATAS(): Apply Table Filters Across Unrelated Tables

Purpose: Simulates a relationship between tables by treating a column as if it’s
filtering another column — even if there's no direct relationship between them.
Syntax:
TREATAS(<table>, <column1>, <column2>, ...)
Use Case Example:
Let’s say Target[Region] and Sales[Region] are not related.
You want to filter Sales based on Target[Region]:
Treated Sales =
CALCULATE(SUM(Sales[Amount]), TREATAS(VALUES(Target[Region]), Sales[Region]))
TREATAS tells DAX: “Pretend that Target[Region] is filtering Sales[Region].”

Summary Comparison:
Feature CROSSFILTER TREATAS
Use Case Modify existing relationships Simulate relationships between unrelated tables
Works with Tables with relationships Unrelated tables
Change direction or disable
Purpose Project filters from one table to another
filters
Typical Inside CALCULATE, with VALUES() or
Within CALCULATE or FILTER
Usage SELECTCOLUMNS()
Affects No (temporary in expression
No (applies only to that calculation)
Model? only)
 What is the difference between SUMX and SUM in DAX?
Give an example.

Basic Difference:
Function Purpose How it Works
SUM Adds values in a single column Straightforward aggregation
Row-by-row evaluation over a table Evaluates an expression for each row, then
SUMX
expression sums the result

Conceptual Understanding:
• SUM works on one column only.
• SUMX can work on expressions across multiple columns or logic per row.

Example:
Imagine you have a table Sales with:
Product Quantity Price
A 2 100
B 5 200
Using SUM:
TotalQuantity = SUM(Sales[Quantity])
-- Output: 7
You cannot do:
SUM(Sales[Quantity] * Sales[Price])
Using SUMX:
TotalRevenue = SUMX(Sales, Sales[Quantity] * Sales[Price])
-- Row 1: 2 * 100 = 200
-- Row 2: 5 * 200 = 1000
-- Output: 1200
So SUMX is essential for custom row-by-row calculations before aggregation.

When to Use:
•Use SUM for simple aggregations on one column.
•Use SUMX when:
o You need to multiply/add between columns.
o You're working with calculated rows or logic.

How do you calculate a rolling 12-month total in Power BI?

Goal:
Calculate a sum of values over the past 12 months, dynamically based on the selected
date in the context.

DAX Formula:
Assume you want a rolling total of Sales[Amount] based on Sales[OrderDate].
Rolling 12M Sales =
CALCULATE(
SUM(Sales[Amount]),
DATESINPERIOD(
'Date'[Date],
MAX('Date'[Date]),
-12,
MONTH
)
)

Explanation:
• CALCULATE changes the context of the calculation.
• SUM(Sales[Amount]) → Base measure.
• DATESINPERIOD() creates a dynamic 12-month window:
o MAX('Date'[Date]) → Anchors the window to current context date.
o -12 and MONTH → Looks back 12 months.

Notes:
• Requires a calendar date table with continuous dates.
• Works well in visuals like line charts showing month trends.
• Ensure a relationship exists between your Date table and fact table.