PL-300 Visualize and analyze 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.

• ✓

  Import mode provides faster query performance for aggregated data

  Why this is correct

  Import mode loads and compresses the entire dataset into memory using the VertiPaq columnar engine, so query execution does not incur network round-trips to the source database. Aggregated queries such as SUM, COUNT, or GROUP BY run directly against this in-memory columnstore, enabling response times that are typically orders of magnitude faster than pushing the same aggregation to an external relational engine. In addition, shared aggregations get cached at the model level, which further accelerates repeated report interactions.

• ✗

  DirectQuery mode supports all DAX functions without limitations

  Why it's wrong here

  DirectQuery does not support every DAX function without limitations; for example, many time intelligence functions (such as TOTALYTD) require a properly marked date table, and some table functions are either unavailable or must be avoided because the entire model query must be translated into a single native SQL statement for the underlying source. Certain DAX functions, including PATH and some statistical functions, either behave differently or are not supported due to the inability to generate a valid SQL translation. Microsoft publishes an explicit list of functions that are unsupported or restricted in DirectQuery models.

• ✓

  Import mode has a maximum data size limit (e.g., 1 GB per dataset in shared capacity)

  Why this is correct

  Because Import mode must keep a compressed copy of the data in memory, capacity limits directly constrain dataset size. In shared (Pro) capacity, each dataset is limited to 1 GB, whereas Premium capacity offers much larger limits depending on the SKU (for example, 100 GB per dataset). This cap is a critical planning factor: if your imported dataset grows beyond the limit, you must either upgrade to a Premium capacity, enable Large Dataset Storage Format, or reconsider whether DirectQuery is more viable for the workload.

• ✗

  DirectQuery mode cannot query large data sources

  Why it's wrong here

  DirectQuery has no inherent cap based on source data volume; it can connect to massive data warehouses or data lakes because no copy of that data is stored inside Power BI. The real constraint is not absolute size but the performance of the source database—how many rows must be scanned, whether indexes and partitions are present, and how efficiently the source engine executes the generated SQL. If a source is poorly tuned, DirectQuery reports may return slowly, which can misleadingly suggest that DirectQuery 'cannot handle large sources,' when in fact the bottleneck is the source database's responsiveness.

• ✓

  DirectQuery mode is suitable when real-time data is required

  Why this is correct

  DirectQuery mode issues a fresh query to the underlying source every time a visual loads or a user changes a slicer, so the results always reflect the latest committed data in the source system without requiring a scheduled refresh. This makes it the appropriate choice when near-real-time or real-time data freshness is the primary requirement, such as operational dashboards where decisions depend on current transactions. However, because every interaction incurs source latency and cannot fall back to a local cache, choosing DirectQuery for freshness should be balanced against the performance that your users experience.

Go deeper

Related to this question