Courseiva
Model the data →hardMultiple Select

PL-300 Model the data Practice Question

Which THREE of the following are valid considerations when using Power BI DirectQuery mode?

⚠ Common exam trap

Many exam-takers confuse DirectQuery with Import mode, assuming data is still cached locally, or mistakenly think relationships cannot be created because they are not enforced at the dataset level, when in fact they are supported but with limitations.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Queries are sent to the underlying data source in real time.

Option C is correct because DirectQuery does not cache or import data into Power BI; instead, every visual interaction generates a query that is passed through to the underlying source (e.g., SQL Server, Azure Synapse, Oracle) in real time, so results reflect the source's current state. Option D is correct because row-level security can be defined in the Power BI model and, for DirectQuery sources, the RLS filters are translated into the native query sent to the data source, restricting the rows each user can see. Option E is correct because DirectQuery must translate DAX into the source's query language, so certain DAX functions and constructs (for example, some time intelligence and parent-child functions) are unsupported or behave differently, and Power BI will flag them as not supported in DirectQuery mode. Option A is wrong because importing data describes Import mode, not DirectQuery, which leaves the data in the source. Option B is wrong because relationships between tables can still be created in a DirectQuery model; they are simply used to generate the appropriate joins in the queries sent to the source.

Answer analysis

Option-by-option breakdown

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

  • ✗

    Data is imported into the Power BI dataset.

    Why it's wrong here

    In DirectQuery mode, the Power BI dataset does not store or cache data; every visual generates a query that is sent to the underlying source, and only the schema and metadata are retained locally. Saying data is imported into the dataset confuses DirectQuery with Import mode, where tables are copied into the in-memory VertiPaq engine. Therefore, this statement is incorrect because no data is ever materialized in the Power BI file.

  • ✗

    You cannot create relationships between tables.

    Why it's wrong here

    Relationships between tables are absolutely supported in DirectQuery mode, so this option is false. You can create relationships in the model editor, and these relationships are translated into joins in the queries sent to the source, though they may be limited by referential integrity or require a star schema for optimal performance. The key point is that the ability to relate tables is not removed by DirectQuery, contrary to the claim.

  • ✓

    Queries are sent to the underlying data source in real time.

    Why this is correct

    A defining characteristic of DirectQuery is that report interactions—such as filtering, slicing, or simply changing a page—are translated in real time into native queries executed directly against the underlying data source. This ensures that the report always shows the current state of the source, but it also means query performance depends heavily on the source's responsiveness and indexing. Since no snapshot is taken, any change in the source is immediately reflected in the report.

  • ✓

    Row-level security (RLS) can be applied.

    Why this is correct

    Row-level security (RLS) is fully supported in DirectQuery mode, allowing you to create static or dynamic roles that filter data based on the user context. The defined RLS filters are evaluated at query time and pushed down to the underlying source as part of the generated queries, ensuring that users only see rows permitted by their role. This makes the statement correct, though you must be careful with single sign-on when using stored credentials or custom data connections.

  • ✓

    Some DAX functions are not supported.

    Why this is correct

    DirectQuery mode imposes restrictions on certain DAX capabilities, particularly many time intelligence functions such as DATEADD, TOTALYTD, or SAMEPERIODLASTYEAR, which may return unsupported or incorrect results when compared to Import mode. Additionally, functions that depend on the engine's in-memory calendar table, or that require multiple passes over data, often are not allowed or are strongly limited. Therefore, saying 'some DAX functions are not supported' is accurate, although you can still use many other DAX functions and create calculated columns and measures within those constraints.

About these practice questions

Courseiva writes every PL-300 question from scratch — 524 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This PL-300 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PL-300 exam.