PL-300 Static RLS Practice Question
Which TWO approaches can you use to implement row-level security (RLS) in Power BI?
⚠ Common exam trap
A common trap is confusing static RLS (fixed filters in roles) with dynamic RLS (using USERNAME() or USERPRINCIPALNAME() to filter by user).
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
✓
Create roles with static filters.
Option D is correct because creating roles with static filters is a core RLS implementation method in Power BI: in Power BI Desktop you define roles in Manage Roles and add DAX filter expressions on tables (for example, [Region] = "West"), then assign users or groups to those roles in the Power BI service, so each user sees only the rows matching the filter. Option E is correct because dynamic filters based on USERNAME() (or USERPRINCIPALNAME()) implement RLS by evaluating the signed-in user at query time, typically via a relationship to a security/identity table, so row visibility adapts automatically without creating a separate static role per user. Option A is not a valid RLS approach because assigning users to security groups in the dataset is a membership/administration step, not a row-filtering mechanism by itself. Option B is wrong because column-level security restricts which columns are visible, not which rows. Option C is wrong because object-level security restricts access to tables and columns (metadata), not rows.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Assign users to security groups in the dataset.
Why it's wrong here
Assigning users to security groups in the dataset is merely an administrative step that simplifies role assignment; it does not implement row filtering itself. To enforce RLS, you must first create a role containing a DAX filter predicate (e.g., "Region = 'West'") and then assign the security group to that role. Without a role definition, grouping users has no effect on row visibility, making it an incomplete approach rather than a standalone RLS method.
- ✗
Use column-level security to restrict row visibility.
Why it's wrong here
Column-level security (CLS) controls which columns (fields) a user can view, such as hiding the "Salary" column from certain groups. It does not affect row visibility at all; users still see every row in the table, just with certain attributes omitted. Since RLS requires filtering rows, CLS is a separate security mechanism and cannot be used to restrict row-level data access.
- ✗
Use object-level security to restrict rows.
Why it's wrong here
Object-level security (OLS) is used to control access to specific tables or objects in a model, not to individual rows. When a user has permission to an object, they can see all rows in that object unless row-level filters are also applied. OLS cannot restrict which rows are returned; it either grants or denies access to the entire table, so it is not a valid approach for row-level security.
- ✓
Create roles with static filters.
Why this is correct
Static row-level security is implemented by creating one or more roles whose DAX filters use constant values, such as [Country] = "USA". Every user assigned to a specific role receives exactly the same filtered view; to grant different views, you must create separate roles for each distinct filter value. This approach is predictable and easy to audit, but it becomes cumbersome when many user groups need different subsets of rows.
- ✓
Use dynamic filters based on USERNAME().
Why this is correct
Dynamic row-level security uses DAX expressions that reference the current user via USERNAME() or USERPRINCIPALNAME(), allowing a single role to serve many users with personalized filters. For example, filtering [Salesperson] = USERPRINCIPALNAME() returns only rows where the salesperson column matches the logged-in user's email. This is more scalable than static RLS because no new role is needed per user, though the underlying data must contain user identifiers that match the function's output (e.g., UPN).
Go deeper
Related to this question
About these practice questions
One of 524 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 →
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.