- What should you do?
Answer: Create a shipping-sales measure that activates the ShipDateKey relationship by using USERELATIONSHIP.
When Power BI has multiple relationships between two tables, only one can be active at a time — the others remain inactive and are ignored by default. The challenge here is that you need two different date contexts in the same report: order month for existing visuals and shipping month for a new one. The solution is to leave the model's active relationship untouched and selectively activate the inactive one inside a specific measure.
This is exactly what USERELATIONSHIP does. By creating a shipping-sales measure like CALCULATE([Total Sales], USERELATIONSHIP(Sales[ShipDateKey], Date[DateKey])), you override the active relationship only within that measure's evaluation context. All existing visuals continue filtering through the active OrderDateKey relationship without any changes. Option C is correct because it achieves parallel date analysis without disrupting existing logic.
Option A fails because deleting the OrderDateKey relationship would break every existing visual that depends on order-month filtering — you'd solve one problem by creating a larger one. Option B misunderstands bidirectional filtering entirely; changing cross-filter direction affects how filters propagate between tables, not which relationship is used for a calculation. It would not allow Power BI to "choose" a path and would likely cause ambiguity errors. Option D is the wrong tool for the job — CROSSFILTER modifies the direction or disables a relationship within a calculation, but using it to disable relationships in every existing measure would require rewriting all of them and still wouldn't activate ShipDateKey correctly.
As a study tip, remember: USERELATIONSHIP is your go-to whenever a model has inactive relationships that need to be leveraged in specific measures without restructuring the entire schema.
- Which configuration should you apply to propagate the RLS filter through the bridge?
Answer: Make Region-to-UserRegion bidirectional and apply the security filter in both directions on that relationship.
When you see an RLS question involving a bridge table (a many-to-many junction), your focus should be on which specific relationship is blocking the filter from crossing, and then fixing only that relationship — not the entire schema.
Here's the chain: the RLS rule filters User, which flows to UserRegion through the User-to-UserRegion relationship. The problem is that Region sits on the one side of Region-to-UserRegion, meaning filter context flows from Region down to UserRegion by default — not the other way around. To let the user-based filter travel up from UserRegion into Region (and then down into Sales), you need to make the Region-to-UserRegion relationship bidirectional and enable security filtering in both directions. That's exactly what D prescribes: once this relationship propagates filters both ways, the user identity can reach Region, which already flows naturally into Sales.
A is wrong because the User-to-UserRegion relationship isn't the blockage — that filter already crosses successfully. Modifying it doesn't help the filter reach Region or Sales.
B is wrong because Region-to-Sales isn't the bottleneck either. The filter never even makes it to Region yet, so fixing the downstream relationship accomplishes nothing.
C is a common trap — making every relationship bidirectional is overly broad, introduces ambiguity risks, and leaving security-filter directions unchanged (as C specifies) still won't fix the propagation gap.
Study tip: On Power BI RLS questions, trace the filter path step by step and identify the exact relationship where the chain breaks. Change only that relationship's cross-filter and security-filter direction — surgical precision beats blanket changes every time.
- Which change should you make to resolve the ambiguity while allowing Date and Product slicers to filter both fact tables?
Answer: Configure all four relationships as single-direction relationships from each dimension to each fact table.
When you see a question about bidirectional relationships and ambiguity in Power BI, think about how filter paths propagate through your model. Ambiguity arises when there are multiple valid filter routes between tables — Power BI can't determine which path to use, causing errors or unpredictable results.
The clean solution here is A: convert all four relationships to single-direction (dimension → fact). This eliminates ambiguous paths entirely because filters flow in only one direction — from Date to Sales, Date to Inventory, Product to Sales, and Product to Inventory. Slicers on Date and Product still filter both fact tables perfectly because the filter direction points toward them. You get the cross-filtering behavior you need without giving Power BI conflicting route options.
B is wrong because marking the Date-to-Inventory relationship inactive would break your requirement — Date slicers would no longer automatically filter the Inventory table without explicit USERELATIONSHIP() calls in every measure. You'd solve ambiguity by sacrificing functionality.
C is wrong and actually worsens the problem. Adding a direct bidirectional relationship between the two dimension tables creates even more filter paths, multiplying the ambiguity rather than resolving it. Never add relationships between dimension tables to fix path conflicts.
D is wrong because a bidirectional relationship between the two fact tables (Sales and Inventory) creates a many-to-many-style filter loop. This introduces serious ambiguity and performance issues, and dimensions would no longer cleanly drive both tables.
The study tip to remember: bidirectional relationships are powerful but dangerous in multi-fact models. When ambiguity appears, your first instinct should be to reduce directionality, not add more relationships.
- Which model change is the most appropriate correction?
Answer: Remove the fact-to-fact relationship and relate Returns directly to the shared dimensions by its keys.
Whenever you see a question about fact table relationships in Power BI, your instinct should be to ask: do these fact tables need to talk to each other, or do they just share the same dimensions? Many-to-many, bidirectional relationships between fact tables are a well-known anti-pattern because they create ambiguous filter paths that produce unpredictable aggregations — exactly the "inconsistent return totals" the question describes.
The right fix is D: since each return row already carries its own ProductKey and ReturnDateKey, the Returns table can relate directly to the Product and Date dimension tables without any dependency on Orders. Removing the fact-to-fact relationship eliminates the ambiguous cross-filtering, and both fact tables now receive clean, independent filters from the shared dimensions through a proper star schema.
A is a partial improvement — single-direction filtering reduces ambiguity — but keeping any direct fact-to-fact relationship still risks incorrect aggregations when filters from multiple dimensions are combined. It treats the symptom, not the cause. B is a trap: "Assume Referential Integrity" is a query-optimization hint that tells Power BI not to check for unmatched keys; it has nothing to do with filter direction or many-to-many join behavior, so it doesn't address the inconsistency at all. C sounds logical but is destructive — merging fact tables with different granularities (orders vs. returns) into a single physical table creates sparse, messy data and breaks the ability to analyze each process independently.
Your study tip: in Power BI modeling, fact tables should never filter each other. If two fact tables share dimensions, connect each one directly to those dimensions and let the shared dimension act as the bridge.
- Which relationship change provides the required propagation while minimizing bidirectional filtering?
Answer: Set Account-to-RepresentativeAccount to Both and leave Account-to-Transaction single-direction.
When you see a question about filter propagation across bridge tables in Power BI, think about where the filter needs to cross and find the minimum change that opens that path.
Here, the filter chain needs to travel from Representative → RepresentativeAccount → Account → Transaction. The bottleneck is RepresentativeAccount — it sits between Representative and Account as a bridge table. With all relationships set to single-direction, filters flow into RepresentativeAccount from both sides but cannot pass through it in both directions. To let a Representative slicer reach Account (and from there reach Transaction), you need Account-to-RepresentativeAccount set to Both. This allows the filter entering RepresentativeAccount from the Representative side to propagate back up to Account, which then filters Transaction normally via the existing single-direction relationship. That's exactly what B prescribes.
A is wrong because flipping Representative-to-RepresentativeAccount to Both doesn't help — filters still can't cross from RepresentativeAccount over to Account. The real gap is on the Account side of the bridge, not the Representative side.
C is wrong because setting Account-to-Transaction to Both addresses a relationship that already works fine (Account already filters Transaction with single-direction). It doesn't fix the missing path between Representative and Account at all.
D is wrong because creating a direct many-to-many bidirectional relationship between Representative and Transaction skips the bridge table entirely, introduces unnecessary model complexity, and adds broad bidirectional filtering that can cause ambiguous filter paths and performance problems.
Study tip: In bridge-table scenarios, always trace the filter path step by step and identify exactly which relationship is blocking propagation — then flip only that one.
- What is the most likely cause, and what should you do?
Answer: Sales contains unmatched product keys; correct or map those keys to restore referential integrity.
Whenever you see a blank member appearing in a Power BI slicer, your first instinct should be to think about referential integrity between related tables. Power BI automatically generates a blank member on the "one" side of a relationship when rows on the "many" side contain keys that don't match any key on the one side — essentially orphaned rows.
Here, Product[ProductKey] is confirmed to have no nulls and is unique, so the Product table itself is clean. The blank appears because Sales contains product keys that have no corresponding entry in Product. Power BI creates a virtual blank row in Product to "house" those unmatched Sales rows, which is why selecting the blank actually shows real sales data. The fix is to correct or map those orphaned keys in the Sales table — answer B — restoring referential integrity so the blank disappears.
A is a trap: cross-filter direction controls how filters propagate between tables, not whether orphaned keys produce blanks. Switching to bidirectional filtering would not eliminate the phantom blank member. C reverses the relationship direction, which makes no logical sense here — Product legitimately is the one side (one product, many sales), and reversing it would break your data model. D confuses the mechanism entirely; making a relationship inactive simply stops it from being used in calculations by default — it has no effect on how Power BI handles unmatched keys.
As a study tip, remember this pattern: blank on the one side = orphaned rows on the many side. Always verify data quality on the many side before changing relationship settings.
- Which solution best addresses the issue?
Answer: Keep MetricSelection disconnected and use its selected value to switch the measure being evaluated.
When a slicer isn't meant to filter rows but instead to control what a measure calculates, you're in the territory of dynamic measure switching — a core DAX pattern in Power BI. The key insight is that not every slicer needs a relationship; sometimes the slicer's job is to pass a value to a measure, not to filter a table.
This is exactly why C is correct. By keeping MetricSelection disconnected, you use a measure like SELECTEDVALUE(MetricSelection[Metric]) inside a SWITCH statement to return Revenue, Margin, or Units depending on what the user picks. The slicer doesn't need to filter Sales — it just signals which calculation to perform. This is clean, intentional, and the standard approach for metric-switching scenarios.
Option A falls into a common trap: creating a many-to-many relationship when none is semantically valid. The metric label in MetricSelection has no meaningful match to rows in Sales, so forcing a relationship would either produce incorrect filter propagation or no meaningful filtering at all. Cross-filter direction "Both" doesn't fix a conceptually broken relationship.
Option B requires modifying the Sales table to store a metric label column, which distorts the data model. Sales rows represent transactions, not metric types — adding a metric label column would be structurally nonsensical and create data quality problems.
Option D is simply incorrect. Marking a table as a date table is a time intelligence feature that tells Power BI how to handle date filtering; it has no effect on relationship propagation for non-date tables.
Study tip: On Power BI exam questions, when you see a disconnected slicer controlling a visual, think SWITCH + SELECTEDVALUE — not relationship engineering.
- How should you redesign the model to eliminate the semantic ambiguity?
Answer: Create separate Customer Geography and Store Geography role-playing dimensions, each with its own filter path.
When a single dimension table serves multiple distinct business roles — like a Geography table that simultaneously represents both where a customer lives and where a store operates — you're dealing with what Power BI practitioners call a role-playing dimension. The classic solution is to create separate, dedicated copies of that dimension, each wired into the model through its own relationship path. This eliminates ambiguity because report authors can now slice by "Customer Geography" and "Store Geography" as independent, clearly labeled fields.
Answer A is correct because duplicating the Geography table into two purpose-built tables — one for customer location, one for store location — gives each filter path its own identity. DAX measures and visuals can reference either dimension unambiguously, and slicers behave predictably without hidden conflicts.
Answer B fails because deactivating the Geography-to-Customer relationship doesn't solve the dual-role problem — it simply disables half the functionality. You'd lose the ability to filter by customer geography in standard report interactions without writing USERELATIONSHIP() in every single measure.
Answer C is dangerous. Switching both paths to bidirectional filtering doesn't resolve semantic ambiguity; it amplifies it. Bidirectional filters can cause unexpected cross-filtering between Customer and Store tables, producing incorrect aggregations and making the model harder to reason about.
Answer D destroys analytical capability. Embedding geographic names directly in the Sales table denormalizes the model, eliminates reusable geography attributes, and makes any geographic analysis brittle and redundant.
Study tip: Whenever you see a single table with multiple relationship paths to the same fact table, think "role-playing dimension" and consider duplication as your first design solution — not relationship deactivation or bidirectional filtering.
- Which approach meets the requirement with the smallest impact on the model?
Answer: Use CROSSFILTER within the target measure to make Customer-to-Sales bidirectional during that calculation.
When a Power BI model needs filter behavior that differs per measure rather than globally, your first instinct should be to reach for DAX functions that modify relationships at calculation time — keeping the model structure clean and predictable for everything else.
In this scenario, Date filters Sales through an active relationship, and Customer connects Sales to ServiceCase. To count service cases for customers who purchased within the selected Date range, you need Customer-to-Sales to propagate filters back through Customer and down into ServiceCase — but only for this one measure. The CROSSFILTER function does exactly this: inside your measure's DAX expression, you can set the Customer-to-Sales relationship to BOTH, enabling bidirectional filtering just for that calculation. Once the measure finishes evaluating, the model reverts to its original single-direction behavior. This is option C, and it surgically solves the requirement with zero structural changes.
Option A makes Customer-to-Sales permanently bidirectional, which means Date would filter ServiceCase through that chain for every measure — directly violating the model owner's restriction. Option B creates an entirely new active relationship from Date to ServiceCase, which adds model complexity, potentially conflicts with existing relationships, and still doesn't limit the side effects the owner wants to avoid. Option D is logically flawed: relationship activation doesn't depend on how many values a slicer has selected, and Power BI has no native mechanism to toggle relationships based on slicer state.
Study tip: On Power BI exam questions, whenever you see "apply this filter behavior only in one measure," think CROSSFILTER or USERELATIONSHIP in DAX — they're your scalpel; permanent model changes are a sledgehammer.
- Which action is the best long-term fix?
Answer: Create a conformed customer dimension with a unique key and resolve source-system identity conflicts.
When a relationship problem stems from dirty source data, the real question is whether you're treating the symptom or curing the disease. This question tests your understanding of dimensional modeling best practices and data quality governance in Power BI.
The root cause here is that two source systems generate conflicting records for the same customer, producing duplicate CustomerIDs with inconsistent attributes. The only durable solution is C: building a conformed customer dimension that resolves identity conflicts upstream and guarantees a unique key. This approach enforces referential integrity, enables a clean one-to-many relationship, ensures consistent attributes across all reports, and scales as new source systems are added. It addresses the problem at the data layer, where it belongs.
A is a common trap. Bidirectional filtering on a many-to-many relationship doesn't eliminate duplicate rows — it actually amplifies ambiguity, causing double-counting and unpredictable filter propagation. You'd be layering complexity onto a broken foundation.
B sounds pragmatic but is dangerous. Arbitrarily keeping the first-loaded record ignores which source system holds the authoritative attribute values. Report totals may stabilize temporarily, but you're silently discarding data without business rules to justify it, making the fix invisible and fragile.
D removes the relationship entirely, which cripples the model's analytical capability. Disconnected tables require users to apply filters manually through slicers, breaking any automated relationship-based aggregation and undermining the purpose of a star schema.
As a study tip: on Power BI exam questions involving relationship cardinality problems, always ask where the problem originates. If the answer is the source data, the correct fix modifies the data — not the relationship settings.
