This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Prepare the data (25–30%)
   --> Transform and load the data
      --> Identify and Create Appropriate Keys for Relationships

Below are 10 practice questions (with answers and explanations) for this topic of the exam.
There are also 2 practice tests for the PL-300 exam with 60 questions each (with answers) available on the hub.

---

Practice Questions

---

Question 1

You want to create a one-to-many relationship between a Sales table and a Customers table. Which column should be used as the key on the one side?

A. Customer Name
B. Customer Email
C. CustomerID
D. Sales Amount

✅ Correct Answer: C

Explanation:
The key on the “one” side must be unique and non-null. CustomerID is a stable identifier designed to uniquely identify customers.

---

Question 2

Power BI automatically creates a many-to-many relationship between two tables. What is the MOST likely cause?

A. The relationship is inactive
B. The join direction is incorrect
C. Duplicate values exist in the key columns
D. The relationship was created in DAX

✅ Correct Answer: C

Explanation:
Many-to-many relationships occur when neither side of the relationship has unique values. This is often caused by poor key design or missing dimension tables.

---

Question 3

You need to create a relationship using two columns (OrderDate and StoreID) because no single column is unique. What should you do?

A. Create two relationships
B. Use a many-to-many relationship
C. Create a composite key in Power Query
D. Use a calculated column in DAX

✅ Correct Answer: C

Explanation:
Power BI does not support native composite relationships. You must combine columns into a single key—preferably in Power Query before loading data.

---

Question 4

A relationship fails to work even though the key values appear identical. What should you check FIRST?

A. Relationship cardinality
B. Column data types
C. Storage mode
D. Table visibility

✅ Correct Answer: B

Explanation:
Keys must have the same data type on both sides. Text vs numeric mismatches are a common cause of broken relationships.

---

Question 5

Which table should typically contain foreign keys in a star schema?

A. Dimension tables
B. Fact tables
C. Bridge tables only
D. Lookup tables only

✅ Correct Answer: B

Explanation:
In a star schema, fact tables contain foreign keys that reference the primary keys in dimension tables.

---

Question 6

Which of the following is the BEST candidate for a primary key in a dimension table?

A. Product Name
B. Product Category
C. ProductID
D. Product Description

✅ Correct Answer: C

Explanation:
Primary keys must be unique, stable, and non-descriptive. IDs are ideal, while names and descriptions are subject to change and duplication.

---

Question 7

You discover duplicate values in a dimension table’s key column. What is the BEST next step?

A. Enable many-to-many relationships
B. Remove duplicates or redesign the dimension
C. Use bidirectional filtering
D. Create a calculated table

✅ Correct Answer: B

Explanation:
Dimension tables must have unique keys. Allowing duplicates introduces ambiguity and breaks proper filter propagation.

---

Question 8

Where should keys ideally be created or cleaned for best model performance?

A. In DAX measures
B. In calculated columns
C. In Power Query
D. In Power BI visuals

✅ Correct Answer: C

Explanation:
Keys should be created and cleaned before data is loaded. Power Query is the correct environment for shaping and preparing keys.

---

Question 9

Which situation MOST strongly indicates that a surrogate key should be used?

A. A column contains null values
B. No stable unique identifier exists
C. The table contains many rows
D. The table is a fact table

✅ Correct Answer: B

Explanation:
Surrogate keys are often introduced when natural keys are missing, unstable, or composite, enabling reliable relationships.

---

Question 10

Why are descriptive columns (such as names or emails) poor choices for relationship keys?

A. They increase storage size
B. They slow down visuals
C. They are not guaranteed to be unique or stable
D. They cannot be indexed

✅ Correct Answer: C

Explanation:
Descriptive fields can change, contain duplicates, or include formatting inconsistencies, making them unreliable as relationship keys.

---

Key PL-300 Takeaways

• Keys must be unique, non-null, and stable
• Dimension tables define the one side
• Fact tables contain foreign keys
• Composite keys must be explicitly created
• Poor key design leads to incorrect results
• Prepare keys in Power Query, not DAX

---

Go back to the PL-300 Exam Prep Hub main page