PL-300 Visualize and analyze the data Practice Question
You have a Power BI dataset that uses row-level security (RLS) with roles defined in Power BI Desktop. You publish the dataset to the Power BI service. Which TWO statements are true about RLS behavior?
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
✓
Users assigned to a role will only see rows that satisfy the role's DAX filter.
Option B is correct because RLS in Power BI enforces row filtering through the DAX filter expression defined on each table in the role; when a user is assigned to that role, queries executed against the dataset return only the rows where the DAX predicate evaluates to TRUE. Option E is correct because roles are authored in Power BI Desktop, but user or group membership in those roles is assigned in the Power BI service (via the dataset's Security page or the Admin portal / REST API), since Desktop has no knowledge of the service's users and groups. Option A is not correct because RLS filters data at query time for viewers and does not change or affect the dataset's scheduled refresh process. Option C is not correct because RLS filters rows in the underlying tables, not visual titles or other report metadata, which are not automatically altered by RLS. Option D is not correct because RLS operates at the row level on tables, not at the measure level; restricting measures requires object-level security (OLS), which is a separate feature.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
RLS affects the refresh schedule of the dataset.
Why it's wrong here
Row-level security is a query-time filter applied to a dataset, not a data-refresh operation. The refresh schedule determines when data is loaded or updated from source systems; RLS filters rows when a user queries the report. Therefore, whether a user sees a row or not does not affect the time or frequency of scheduled refreshes. The two mechanisms are entirely independent.
- ✓
Users assigned to a role will only see rows that satisfy the role's DAX filter.
Why this is correct
When a Power BI role is defined with a DAX filter, such as 'Where Salesperson = USERNAME()', that expression is evaluated against every row in the secured table for each member of the role. Any row that evaluates to TRUE is visible; any row that evaluates to FALSE is hidden from that user. This filtering is applied automatically to all visuals, exports, and tile queries against the dataset, making it the fundamental mechanism for row-level security.
- ✗
Visual titles are automatically filtered based on RLS.
Why it's wrong here
Visual titles are static text or fields configured in the report layout; they are not governed by row-level security. RLS restricts the set of records that flow into a visual's data, not the visual's appearance or its title property. Even if a title could be based on a field, the title expression itself is not filtered by RLS; only the data fields bound to the visual are filtered. Consequently, a user with RLS restrictions will see the same title as an unrestricted user as long as they have access to the report.
- ✗
RLS can restrict access to specific measures.
Why it's wrong here
Row-level security operates exclusively at the granularity of rows in a table; it cannot hide individual measures or columns. When a measure is defined, it computes over the subset of rows visible to the current user, but the measure itself is always available on the report. To restrict access to specific measures, you would need different report pages or object-level security, which is a separate feature that can hide entire tables or columns, not measure definitions. RLS only reduces the data domain, leaving the entire measure set untouched.
- ✓
Role membership must be assigned in the Power BI service after publishing.
Why this is correct
In Power BI Desktop, you can define roles and their DAX filter expressions, but you cannot specify which users belong to each role; the Desktop session has no concept of a target end-user. After publishing the dataset to the Power BI service, you navigate to the Security tab, select a role, and add users, groups, or security principals. Membership can also be automated using the Power BI REST API or by using dynamic RLS with DAX functions like USERPRINCIPALNAME() inside the filter. The assignment step is always a service-side operation.
Go deeper
Related to this question
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 →
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.