How to Implement Row-Level Security with DirectQuery in Power BI
You have a Power BI report that uses a DirectQuery dataset. You need to ensure that users see only the data relevant to their department. What should you implement?
Quick Answer
The correct answer is row-level security (RLS) with DAX filter expressions. RLS is the appropriate solution because in a DirectQuery model, it pushes DAX filter logic down to the source database, dynamically restricting data at query time based on the authenticated user’s identity—ensuring each department sees only its own rows without requiring separate reports or duplicated datasets. On the PL-300 exam, this scenario tests your understanding of how RLS behaves differently in DirectQuery versus Import mode; a common trap is assuming you must create multiple role-based copies of the report or use report-level filters, which would be inefficient and insecure. Remember that RLS in DirectQuery translates your DAX filters into native SQL queries, so the filtering happens server-side before results reach Power BI. A useful memory tip: think of RLS as a “gatekeeper at the database door”—it checks the user’s credentials and only lets through the rows they are allowed to see, making it the only scalable method for department-level security in DirectQuery.
⚠ Common exam trap
Test-takers frequently confuse row-level security (RLS) with object-level security (OLS), thinking OLS can filter rows when it only hides entire objects like tables or columns.
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
✓
Row-level security (RLS) with DAX filter expressions.
Row-level security (RLS) is the correct approach because it filters data at the query level based on the user's identity. In a DirectQuery model, RLS translates DAX filter expressions into source queries, ensuring that each user only sees rows relevant to their department without duplicating reports or datasets.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Q&A features to restrict natural language queries.
Why it's wrong here
Q&A is not a security feature.
- ✓
Row-level security (RLS) with DAX filter expressions.
Why this is correct
RLS filters rows based on user identity.
- ✗
Object-level security (OLS) to hide tables.
Why it's wrong here
OLS hides objects, not filters rows.
- ✗
Data lineage view to control access.
Why it's wrong here
Data lineage is for impact analysis.
Go deeper
Related to this question
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 →
Same concept, more angles
7 more ways this is tested on PL-300
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Refer to the exhibit. You have a Power BI dataset with the JSON policy shown. You add a user to the USOnly role. What happens when that user views a report based on this dataset?
easy- A.The user sees all rows in the Sales table.
- ✓ B.The user sees only rows where Region is 'US' in the Sales table.
- C.The user sees all rows but the SalesAmount column is hidden.
- D.The user sees all rows in all tables of the dataset.
Why B: Row-level security (RLS) restricts data: only rows where Region is 'US' are visible. Option A is wrong because RLS does not hide the entire table. Option C is wrong because RLS does not affect columns. Option D is wrong because RLS does not affect other tables unless defined.
Variation 2. Refer to the exhibit. You are setting up row-level security (RLS) for a Power BI dataset. The JSON snippet shows the role definition. A user reports that they see no data when they view the report. What is the most likely cause?
medium- A.The filter syntax is incorrect; it should use CALCULATE.
- B.The role name 'RegionManager' is reserved.
- C.The 'SalesPerson' column should be used in the filter.
- ✓ D.The LOOKUPVALUE function requires a relationship between tables.
Why D: LOOKUPVALUE is a DAX scalar function that retrieves a value from a column based on search criteria; it does not require (or create) a table relationship. In RLS, a common cause of no data is that the LOOKUPVALUE returns blank (e.g., because the current user's name doesn't match any value in the lookup table), causing the filter condition to evaluate to FALSE for all rows. The role name 'RegionManager' is not reserved, CALCULATE is not required for RLS filter syntax, and using the SalesPerson column is not inherently the issue. Thus, none of the provided options correctly describe the cause, making the question invalid as written.
Variation 3. Which THREE of the following are valid methods to secure a Power BI dataset at the row level?
medium- ✓ A.Row-level security using the USERPRINCIPALNAME() DAX function.
- B.Azure role-based access control (Azure RBAC) on the data source.
- ✓ C.Static row-level security (RLS) using roles defined in Power BI Desktop.
- D.Object-level security (OLS) to restrict access to specific columns.
- ✓ E.Dynamic row-level security using the USERNAME() DAX function.
Why A: Options A, C, and E are correct. Static RLS uses roles defined in Power BI Desktop. Dynamic RLS uses USERNAME() or USERPRINCIPALNAME() to filter data based on the logged-in user. Object-level security (OLS) is for table/column security, not row-level. Option B is wrong because Azure RBAC is for managing access to Azure resources, not for Power BI row-level security.
Variation 4. You have a Power BI report that uses a dataset with row-level security (RLS) roles. You need to verify that a specific user sees only the data they are supposed to see. What is the most efficient way to test this?
medium- A.Run a DAX query in DAX Studio as the user.
- ✓ B.Use the 'View as' feature in the Power BI service or Desktop.
- C.Check the dataset settings in the workspace.
- D.Share the report with the user and ask them to verify.
Why B: 'View as' allows you to impersonate a user and see exactly what they see. Option A is incorrect because manually checking the dataset is not efficient. Option C is incorrect because you cannot verify in the dataset settings. Option D is incorrect because checking the report after sharing is less efficient.
Variation 5. You have a Power BI report that uses a dataset with row-level security (RLS) roles defined. Users report that they see no data when viewing the report. Which two checks should you perform first? (Assume all other configurations are correct.)
medium- A.Confirm that the workspace is assigned to a Premium capacity.
- B.Check that the report is published to a Power BI app.
- ✓ C.Verify that the dataset has the RLS roles applied and published.
- ✓ D.Ensure the users are members of the appropriate RLS role.
- E.Verify that the RLS role name matches exactly with the username.
Why C: RLS roles must be applied and published to the dataset for them to take effect. Option D is correct because users must be assigned as members of the appropriate RLS role to see data. Option A is incorrect because RLS works in any workspace capacity, not just Premium. Option B is incorrect because an app publishes reports but does not control RLS membership. Option E is incorrect because RLS role membership is based on user security groups or email addresses, not a matching role name with username.
Variation 6. Refer to the exhibit. You define an RLS role in Power BI Desktop as shown. You publish the dataset and assign the user 'user@contoso.com' to the role. When the user views a report that uses this dataset, they see no data. What is the most likely cause?
easy- A.The role name is invalid; it must not contain spaces.
- B.RLS is not applied in Power BI service for tables with less than 100 rows.
- C.The user is not assigned to the role correctly.
- ✓ D.The Region values in the data have leading spaces or are not exactly 'North' (e.g., 'North ').
Why D: The filter expression 'Region = "North"' performs an exact string match. If the actual data contains extra spaces (e.g., 'North ') or uses different casing, the comparison fails, resulting in no rows returned for the user. Options A, B, and C are incorrect: role names can contain spaces, RLS applies regardless of row count, and the user assignment is assumed correct. Therefore, D is the most likely cause.
Variation 7. Which TWO of the following are valid ways to enforce row-level security (RLS) on a Power BI dataset? (Choose two.)
medium- A.Use Power BI Report Builder to define RLS on paginated reports.
- B.Create RLS rules directly in the Power BI service under dataset security.
- ✓ C.Define roles and role members in Power BI Desktop using DAX filter expressions.
- D.Assign users to security groups in Microsoft Entra ID and map those groups to RLS roles in the Power BI service.
- ✓ E.Configure RLS in the source database when using DirectQuery with single sign-on (SSO).
Why C: Options C and E are correct. RLS can be defined in Power BI Desktop using DAX filter expressions to create roles and assign members. Additionally, when using DirectQuery with SSO enabled, RLS can be enforced at the source database level. Option A is incorrect because RLS for Power BI datasets is not defined in Report Builder; it is defined in Power BI Desktop. Option B is incorrect because RLS roles are not created directly in the Power BI service; they are defined in Desktop and then applied in the service. Option D is incorrect because RLS roles in Power BI are based on DAX expressions and user principals, not directly on Microsoft Entra ID groups.
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.