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.

• ✓

  Use Parquet format instead of CSV if possible.

  Why this is correct

  Parquet is a columnar storage format with built-in compression and predicate pushdown, meaning Power Query can read only the specific columns and row groups required instead of scanning the entire 10 GB text file. This dramatically reduces the amount of I/O and memory consumed during the Data Refresh, and also preserves the schema and data types natively, eliminating costly type-inference and parsing steps. By shifting to Parquet, you effectively move the heavy lifting to the storage engine, which is far more efficient for analytical workloads.

• ✗

  Import all columns and use Power BI to hide unused ones.

  Why it's wrong here

  Hiding columns from the Fields pane only modifies the report's metadata—the hidden columns are still fully loaded into the in-memory Tabular model, consuming RAM and enlarging the .pbit and .pbix files. During refresh, all rows and columns of your 10 GB CSV are parsed, compressed, and stored even if you never create a visual from them, and hidden columns can still be referenced by DAX measures, relationships, or even security rules. A best practice is to remove unused columns in Power Query before loading them into the model, not to import everything and rely on hiding as a cosmetic cleanup.

• ✓

  Split the large CSV file into multiple smaller files in the same folder.

  Why this is correct

  Power Query's folder-import functionality reads each file individually and in sequence, so processing a 10 GB monolith peaks your memory usage at roughly the size of that one file; splitting it into, say, 100 MB chunks keeps peak memory proportional to the largest component, not the whole dataset. Each file is independently processed by Power Query, which allows for easier parallelization and simpler handling of partial, incremental refreshes, while the same transform steps automatically apply to every file. However, ensure all files share the same schema or your combine step may break, and be aware that you still read all rows if the rows aren't partitioned by date or some other filter.

• ✓

  Filter rows in Power Query to remove unnecessary data early in the transformation.

  Why this is correct

  By applying row-level filters in the very first steps of your Power Query—before any join, pivot, or expansion—you shrink the number of rows that all subsequent transformations process, directly reducing both the refresh duration and the memory footprint of the query running against your 10 GB CSV. Since flat CSV files offer no server-side query folding, the filtering happens client-side after the raw text is streamed into the engine, but doing it immediately after Source means the engine never materializes an oversized copy of the data in its buffer. This is especially true when splitting files (or using Folder) because filtering there prunes rows as each file enters the pipeline, keeping the engine's working set lean.

• ✗

  Use the on-premises data gateway to connect to Azure Blob Storage.

  Why it's wrong here

  The on-premises data gateway is exclusively designed to bridge connections from Power Query to data sources that live inside your private network, such as SQL Server or a local file share; Azure Blob Storage is a public cloud endpoint accessed over HTTPS, which the Power BI service can connect to directly from its own virtual networks. Forcing that direct connection through a gateway adds unnecessary latency, requires an always-on VM, and introduces a single point of failure, and also violates the principle of least complexity for cloud-to-cloud connections. The gateway is simply the wrong tool here; you only need it for cloud sources that reside in a private cloud or are firewalled off.

Go deeper

Related to this question