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 lets users type natural-language questions; it applies no row-level filter, so every department still sees all rows. It is tempting because Q&A feels like a query control, but it would be correct for enabling conversational exploration, not for restricting which department's data each user retrieves.
- ✓
Row-level security (RLS) with DAX filter expressions.
Why this is correct
DirectQuery datasets push filters to the source, and row-level security with DAX filter expressions is evaluated server-side, restricting each user to their department's rows. This satisfies the requirement that users see only data relevant to their department.
- ✗
Object-level security (OLS) to hide tables.
Why it's wrong here
Object-level security hides entire tables or columns from all non-authorised users; it cannot filter rows per department, so users would lose the table rather than see their own rows. It is tempting because it restricts data, but it would be correct for concealing sensitive columns, not for department-level row filtering.
- ✗
Data lineage view to control access.
Why it's wrong here
Data lineage view is a documentation feature showing dataset dependencies; it enforces no access control, so all departments still see every row. It is tempting because it visualises data flow, but it would be correct for impact analysis and troubleshooting, not for restricting which rows each user can view.
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 →
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: The two correct options are C and D. Option C is right because RLS roles must be created in the dataset and then published to the Power BI Service; if the roles were defined only in Power BI Desktop and never published, or if the published dataset lacks the roles, users will be filtered to no rows. Option D is right because a user who is not assigned to any RLS role (directly or via an Azure AD security group) will, by default, see no data when RLS is enabled on the dataset. Option A does not fit because Premium capacity is not required for RLS to function. Option B does not fit because app publication is not a prerequisite for RLS filtering. Option E does not fit because RLS role names are arbitrary labels and are never matched against usernames; membership is assigned through the role's Members list.
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 correct option is D: the Region values in the data likely have leading/trailing spaces or are not exactly 'North' (e.g., 'North '), so the DAX filter [Region] = "North" evaluates to FALSE for every row and the user sees no data. Row-level security filters are applied as exact string comparisons, so any whitespace or casing difference (DAX string comparison is case-insensitive but not whitespace-insensitive) causes all rows to be excluded. Option A is wrong because role names may contain spaces; Power BI does not restrict them. Option B is wrong because RLS applies regardless of table row count. Option C is wrong because the scenario states the user was assigned to the role, so misassignment is not 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: Option C is correct because RLS roles are authored in Power BI Desktop using DAX filter expressions (for example, [Region] = USERPRINCIPALNAME()) on tables, and role membership is then managed after publishing. Option E is correct because with DirectQuery and SSO, RLS can be enforced at the source database (for example, SQL Server row-level security or Oracle VPD) so the credentials passed through SSO determine which rows the query returns. Option A is not valid because Report Builder defines paginated report layouts and parameters, not dataset RLS. Option B is not valid because the Power BI service lets you add members to existing roles, but RLS rules themselves are created in Desktop or by using Tabular Editor/XMLA, not authored in the service. Option D is not valid because Entra ID security groups can be added as role members, but mapping groups to roles is membership management, not a way to define or enforce the RLS rules themselves.
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.