Troubleshooting Row-Level Security Bypassed by Workspace Roles
Exhibit
Refer to the exhibit.
DAX Expression:
= CALCULATE(
SUM(Sales[Amount]),
Sales[Region] = "West"
)Refer to the exhibit. You are reviewing a DAX expression used in a Power BI measure. You need to ensure that only users in the 'West' region see data for that region. Which approach should you use?
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
✓
Implement row-level security (RLS) in the dataset with a role filter.
Row-level security (RLS) in the dataset with a role filter is the correct approach because it enforces data restrictions at the model level, so users in the 'West' region automatically see only rows where the region equals 'West' regardless of which report or visual they open. RLS roles are defined in Power BI Desktop and assigned to users or groups in the Power BI Service, providing centralized and secure filtering. Using CALCULATE with a report-page filter (B) only affects calculations or visuals, not the underlying data visible to users, so it can be bypassed. A measure with a conditional statement checking the user's email (C) is not a security boundary and cannot reliably restrict row visibility. A calculated column (D) computes values at refresh time and does not filter data per user, so it cannot enforce regional access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Implement row-level security (RLS) in the dataset with a role filter.
Why this is correct
Correct. Row-level security (RLS) is enforced at the dataset level by defining one or more roles in Power BI Desktop, each with a DAX filter that restricts rows based on the current user (e.g., using USERPRINCIPALNAME() or CUSTOMDATA()). This filter is applied by the Analysis Services engine for every query against the dataset, regardless of which report pages, visuals, or measures are used, so no user can ever see rows outside their role's allowed set. It is the only option here that actually slices data by security identity before results reach the reporting layer.
- ✗
Use the CALCULATE function with a filter on the report page.
Why it's wrong here
Incorrect. CALCULATE does modify filter context within a measure, but it operates on the current query context and returns a scalar value for a visual; it does not tell Power BI to hide rows from a user. A filter placed on a report page is part of the report's view layer and can be changed by any user who has editing or even view access if the pane is enabled, and it only affects that one report page, not the underlying dataset or other reports. Because it never restricts access to the underlying data, a user could still query the dataset directly or view the same data in a different report with no such filter.
- ✗
Modify the measure to include a conditional statement that checks the user's email.
Why it's wrong here
Incorrect. Adding a conditional statement such as IF(USERPRINCIPALNAME() = "string", ...) inside a measure simply changes the calculated value returned for that measure; it does not filter the rows that contribute to the measure or limit which rows are visible. Measures are evaluated in the filter context created by the visual and do not rewrite that context for other measures or for the table behind the dataset, meaning the underlying rows remain available to any other visual or measure. Moreover, this approach is not a security enforcement mechanism because the measure is never evaluated during direct dataset queries or when a user builds their own report using the dataset.
- ✗
Create a calculated column with the same logic.
Why it's wrong here
Incorrect. A calculated column is added to the table during data refresh and contains a static value for every row, evaluated once in the current user context (which is none, because calculated columns cannot depend on USERPRINCIPALNAME() or any other dynamic user function at refresh time). While you could use that column in a report-level filter, a filter is still not security: any user with access to the report or dataset can simply remove the filter or write a query that ignores it. The column also does nothing to prevent direct SQL or tabular query access to the rows, so it fails to provide any real row-level restriction.
Go deeper
Related to this question
About these practice questions
This PL-300 question is part of Courseiva's 524-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.