Microsoft Power BI Quiz: Relationship Troubleshooting
10 questions · exam conditions
0:00
Relationship TroubleshootingQuestion 1 of 10

A Sales table contains OrderDateKey and ShipDateKey. Both columns relate to Date[DateKey]. The OrderDateKey relationship is active, and the ShipDateKey relationship is inactive. A report must show sales by shipping month in one visual while existing visuals continue to use order month.

What should you do?

Make the ShipDateKey relationship active and delete the existing OrderDateKey relationship.
Change both Date relationships to bidirectional and allow Power BI to select the applicable path.
Create a shipping-sales measure that activates the ShipDateKey relationship by using USERELATIONSHIP.
Use CROSSFILTER to disable both Date relationships within every existing sales measure.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Relationship Troubleshooting

Practice Relationship Troubleshooting in Microsoft Power BI with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Relationship Troubleshooting, giving you a quick way to practice the rules, question types, and explanations that matter most for Microsoft Power BI.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A Sales table contains OrderDateKey and ShipDateKey. Both columns relate to Date[DateKey]. The OrderDateKey relationship is active, and the ShipDateKey relationship is inactive. A report must show sales by shipping month in one visual while existing visuals continue to use order month.

What should you do?

  1. Make the ShipDateKey relationship active and delete the existing OrderDateKey relationship.
  2. Change both Date relationships to bidirectional and allow Power BI to select the applicable path.
  3. Create a shipping-sales measure that activates the ShipDateKey relationship by using USERELATIONSHIP. (correct answer)
  4. Use CROSSFILTER to disable both Date relationships within every existing sales measure.
Explanation: 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.

Question 2

A model contains Orders and Returns fact tables. They are related directly by OrderID with a many-to-many, bidirectional relationship. Product and Date also filter both fact tables. Users report inconsistent return totals when Product and Date slicers are combined. Each return row already contains ProductKey and ReturnDateKey.

Which model change is the most appropriate correction?

  1. Keep the fact-to-fact relationship but change it to single-direction filtering from Orders to Returns.
  2. Keep the bidirectional relationship and activate the Assume referential integrity setting for OrderID.
  3. Merge Returns into Orders so that every order and return is represented by one physical row.
  4. Remove the fact-to-fact relationship and relate Returns directly to the shared dimensions by its keys. (correct answer)
Explanation: 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.

Question 3

A disconnected table named MetricSelection contains values used in a slicer. It has no key that can form a valid relationship to Sales. The selected value is intended to choose whether a visual displays Revenue, Margin, or Units. A developer reports that changing the slicer does not filter Sales and proposes creating a many-to-many relationship based on the metric label.

Which solution best addresses the issue?

  1. Create the proposed many-to-many relationship and configure its cross-filter direction as Both.
  2. Add the metric label to Sales and create a one-to-many relationship from MetricSelection.
  3. Keep MetricSelection disconnected and use its selected value to switch the measure being evaluated. (correct answer)
  4. Mark the MetricSelection table as a date table so its slicer can propagate without a relationship.
Explanation: 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.

Question 4

A model is intended to have a one-to-many relationship from Customer to Sales. Power BI permits only a many-to-many relationship because Customer[CustomerID] contains duplicate values introduced by combining two source systems. Customer attributes can differ between the duplicate rows, and report totals change unexpectedly when those attributes are used.

Which action is the best long-term fix?

  1. Keep the many-to-many relationship and enable bidirectional filtering so both customer records reach Sales.
  2. Remove duplicate rows arbitrarily from Customer while retaining the first record loaded for each identifier.
  3. Create a conformed customer dimension with a unique key and resolve source-system identity conflicts. (correct answer)
  4. Move CustomerID into a disconnected table and apply customer filtering only through visual interactions.
Explanation: 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.

Question 5

Customer has active single-direction one-to-many relationships to Sales and ServiceCase. Date filters Sales. A measure must count service cases for customers who made a purchase during the selected Date period. The model owner does not want Date to affect ServiceCase through Sales for any other measure.

Which approach meets the requirement with the smallest impact on the model?

  1. Change Customer-to-Sales to Both permanently so Date filters Customer and then ServiceCase.
  2. Create an active direct relationship from Date to ServiceCase using the service-case creation date.
  3. Use CROSSFILTER within the target measure to make Customer-to-Sales bidirectional during that calculation. (correct answer)
  4. Make Customer-to-ServiceCase inactive and activate it only when the Date slicer has one selected value.
Explanation: 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.

Question 6

A Power BI model contains Date and Product dimension tables and Sales and Inventory fact tables. Date and Product each have active relationships to both fact tables. All four relationships are configured with a cross-filter direction of Both. Power BI reports ambiguous filter paths when another relationship is added.

Which change should you make to resolve the ambiguity while allowing Date and Product slicers to filter both fact tables?

  1. Configure all four relationships as single-direction relationships from each dimension to each fact table. (correct answer)
  2. Keep all four relationships bidirectional and mark the Date-to-Inventory relationship as inactive.
  3. Create a direct bidirectional relationship between the Date and Product dimension tables.
  4. Replace the dimension-to-fact relationships with a bidirectional relationship between the two fact tables.
Explanation: 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.

Question 7

A company uses one Geography table for two meanings. Geography filters Customer, Customer filters Sales, Geography also filters Store, and Store filters Sales. Geography therefore reaches Sales through both the customer's location and the store's location. Report authors need to slice sales independently by customer geography and store geography.

How should you redesign the model to eliminate the semantic ambiguity?

  1. Create separate Customer Geography and Store Geography role-playing dimensions, each with its own filter path. (correct answer)
  2. Keep one Geography table and make the Geography-to-Customer relationship inactive for all reports.
  3. Keep one Geography table and change every relationship in both paths to bidirectional filtering.
  4. Remove both Geography relationships and store only the geographic names in the Sales table.
Explanation: 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.

Question 8

Product[ProductKey] is the one side of an active one-to-many relationship to Sales[ProductKey]. A Product slicer unexpectedly includes a blank member. Selecting the blank member displays sales rows. Product[ProductKey] contains no null values and is unique.

What is the most likely cause, and what should you do?

  1. The relationship uses single-direction filtering; change it to Both so every product key becomes visible.
  2. Sales contains unmatched product keys; correct or map those keys to restore referential integrity. (correct answer)
  3. The Product table is on the one side; reverse the relationship so Sales becomes the one side.
  4. The relationship is active; make it inactive so Power BI removes the generated blank member.
Explanation: 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.

Question 9

A row-level security model contains User, UserRegion, Region, and Sales tables. User has a one-to-many relationship to UserRegion. Region has a one-to-many relationship to UserRegion, and Region has a one-to-many relationship to Sales. An RLS rule filters User to the signed-in user's email address. The user filter reaches UserRegion but does not restrict Region or Sales.

Which configuration should you apply to propagate the RLS filter through the bridge?

  1. Make User-to-UserRegion bidirectional and enable security filtering in both directions on that relationship.
  2. Make Region-to-Sales bidirectional and enable security filtering in both directions on that relationship.
  3. Make every relationship bidirectional but leave the security-filter direction settings unchanged.
  4. Make Region-to-UserRegion bidirectional and apply the security filter in both directions on that relationship. (correct answer)
Explanation: 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.

Question 10

Sales representatives can manage multiple accounts, and each account can be managed by multiple representatives. The model contains Representative, RepresentativeAccount, Account, and Transaction tables. Representative has a one-to-many relationship to RepresentativeAccount. Account has a one-to-many relationship to both RepresentativeAccount and Transaction. With all relationships using single-direction filtering from the one side, a Representative slicer does not filter Transaction.

Which relationship change provides the required propagation while minimizing bidirectional filtering?

  1. Set Representative-to-RepresentativeAccount to Both and leave Account-to-RepresentativeAccount single-direction.
  2. Set Account-to-RepresentativeAccount to Both and leave Account-to-Transaction single-direction. (correct answer)
  3. Set Account-to-Transaction to Both and leave Account-to-RepresentativeAccount single-direction.
  4. Create a direct many-to-many bidirectional relationship from Representative to Transaction.
Explanation: 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.