Courseiva
Model the datahardMultiple ChoiceObjective-mapped

PL-300 Model the data Practice Question

You are a Power BI administrator for a large enterprise. You have a Power BI semantic model that uses a single large fact table named Sales (100 million rows) and several dimension tables. The model is used by multiple departments, each with different row-level security (RLS) rules based on the SalesRegion column. You have implemented RLS using static roles. However, you notice that when users from different departments view the same report page, the query performance varies significantly. You suspect that the RLS filters are causing the performance difference. You need to investigate and optimize the RLS performance. What should you do first?

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

Use Power BI Performance Analyzer to capture query performance for each user role and analyze the generated DAX queries in DAX Studio.

Using Power BI Performance Analyzer allows you to capture query performance for each user role, and analyzing the generated DAX queries in DAX Studio helps identify which queries are slow and whether RLS is the cause. This is the first logical step to diagnose the performance variation. Option A (increasing memory) may not address RLS-specific issues. Option C (converting to dynamic RLS) is a potential optimization but not the initial diagnostic step. Option D (removing RLS and using bookmarks) is not a recommended security approach and would not investigate the root cause.

Answer analysis

Option-by-option breakdown

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

  • Increase the data model's memory limit in Premium capacity.

    Why it's wrong here

    Boosting the Premium capacity's memory limit merely allocates more RAM to the backend; it does not change how row-level security (RLS) predicates are evaluated against every query. RLS filters are transformed into DAX expressions that must be resolved by the formula engine, and memory constraints are rarely the reason those expressions run slowly. The slowness stems from query plan inefficiency or filter cardinality, not from lack of memory, so this action masks symptoms without fixing the underlying RLS logic.

  • Use Power BI Performance Analyzer to capture query performance for each user role and analyze the generated DAX queries in DAX Studio.

    Why this is correct

    Power BI Performance Analyzer captures per-visual query durations and the exact DAX produced, which you can then paste into DAX Studio for deep profiling. Running the same report as each RLS role (or using DAX Studio's 'Trace as Role'/'User' feature) lets you compare query plans and see how RLS filters are injected, exposing whether they cause excessive storage-engine scans or formula-engine bottlenecks. This combination is the standard way to pinpoint the exact query path responsible for role-specific slowness.

  • Convert all RLS roles to use dynamic RLS with USERPRINCIPALNAME.

    Why it's wrong here

    Switching every role to dynamic RLS with USERPRINCIPALNAME is not a guaranteed performance improvement; it replaces a static filter with an expression evaluated per user, which can increase query complexity and inhibit query caching if the predicate is not highly selective. The actual impact depends on the column's cardinality, the DAX used, and whether the model is well-optimized, so this change may actually degrade performance further. You first need to diagnose where the cost is being incurred before modifying the RLS implementation.

  • Remove all RLS roles and implement security at the report level using bookmarks.

    Why it's wrong here

    Removing RLS entirely and relying on report bookmarks is not a viable security model because bookmarks only hide or show visuals and cannot prevent a user from querying the underlying dataset directly via other reports or the XMLA endpoint. This approach also breaks row-level security best practices and leaves your data exposed to anyone who accesses the report from a different entry point. It is a workaround that trades security for perceived performance, never a sanctioned solution in Power BI.

About these practice questions

One of 217 original PL-300 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.