PL-300 Prepare the data Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Change data type of all columns after all transformations

  Why it's wrong here

  Changing data types only after all transformations increases the risk of conversion errors and misinterpreted values. For instance, a column originally identified as text might contain numbers that get converted incorrectly when you later split or extract data. Setting data types early ensures that every subsequent transformation—such as filters, merges, or custom columns—operates on an accurate schema, preventing step failures and preserving data integrity.

• ✓

  Promote headers if the first row contains column names

  Why this is correct

  Promoting headers is a best practice because it replaces the default generic column names (Column1, Column2) with the meaningful labels from the first row, which then become the actual column names. Once promoted, you can reference these columns by name in Power Query formulas, making expressions more readable and maintainable. It also improves clarity for end users in the data model, since they see intuitive field names instead of placeholders.

• ✓

  Split columns that contain multiple values into separate rows

  Why this is correct

  Splitting a column that contains multiple values into separate rows normalizes the data by eliminating multi-valued fields, which violate first normal form. This practice creates a one-to-many structure—each individual value gets its own row—so filtering, joining, and measuring by that attribute works correctly. For example, a product cell containing 'Red, Blue, Green' can be split into three rows, enabling precise visual-level filters and aggregations without complex text parsing.

• ✗

  Avoid merging queries; always use lookups

  Why it's wrong here

  Avoiding query merges is not a best practice because merging combines related data from different sources using join logic, which is a core data preparation technique. Merges are fully supported in Power Query with controls for left, right, inner, and full joins, and they are often more efficient than pulling in large tables just to use relationships. The claim 'always use lookups' misunderstands that a merge is effectively the Power Query equivalent of a database join; skipping merges would force you to maintain flat, denormalized imports that are harder to manage.

• ✗

  Avoid unpivoting columns; keep data wide

  Why it's wrong here

  Keeping data wide by avoiding unpivoting is a common anti-pattern because it hides the dimensions represented by the column names. Unpivoting turns broad tables with many value columns into a lean, attribute-value format, which is exactly what Power BI's engine and DAX need for flexible measure creation and time-series analysis. For instance, unpivoting year columns (2019, 2020) into a 'Year' column lets you plot trends directly, whereas a wide format forces you to write separate measures for each column. This normalization step is not a loss of information; it reorganizes the data into a more analysis-ready form.

Go deeper

Related to this question