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 the system region settings of the Power BI service to US

  Why it's wrong here

  Modifying the Power BI service regional settings is a tenant-wide administrative action that affects dashboards, date formatting, and number display for every report in the organization; it cannot be scoped to a single CSV file. Moreover, the date parsing for imported CSV files occurs in Power Query Editor during the transformation phase in Power BI Desktop, not in the Power BI service, so changing the service region has no influence on the 'Change Type' step's interpretation of the date strings. This option is overkill and ineffective for resolving a locale-specific column conversion.

• ✓

  Use the 'Using Locale' option in the Change Type step to select the appropriate locale (e.g., English (United States))

  Why this is correct

  The 'Using Locale' option in the Change Type step (accessed via the Data Type dropdown in Power Query Editor) lets you specify a culture, such as English (United States), that determines how date strings are parsed. By selecting a locale, you override the default system regional settings for that specific transformation, ensuring that a date like '03/04/2021' is interpreted as March 4th rather than April 3rd. This is the precise, minimal solution because it applies only to the selected column and records an M expression with 'Culture' parameter, making it reproducible in subsequent data refreshes without altering any global or tenant-wide configuration.

• ✗

  Change the column data type to Text and then manually replace separators

  Why it's wrong here

  Converting the date column to Text and manually replacing separators is a fragile, multi-step workaround that does not resolve the core ambiguity between day and month. Replacing '/', with '-' merely changes the delimiter; it does not reorder the date components, so '03/04/2021' remains ambiguous without additional logic to detect which portion is the month. This approach also risks corrupting data if the column contains nulls, blank values, or inconsistent formatting, and it never leverages Power Query's built-in locale-aware parsing, making it both more error-prone and more complex than the intended 'Using Locale' solution.

• ✗

  Split the column into day, month, and year, then combine them in the correct order

  Why it's wrong here

  Splitting the column into day, month, and year and recombining them in the correct order introduces unnecessary complexity and risks data corruption if the original column contains nulls or inconsistent formatting. Power Query’s built-in `Change Type with Locale` function directly overrides the default regional interpretation of date strings, which is the precise mechanism needed here. This option is tempting because it mirrors a manual data-cleaning approach that works well when source data lacks a standardised locale or when you need to rearrange non-date text components, such as concatenating separate day, month, and year columns from a legacy system.

Go deeper

Related to this question