Row-Level Security Considerations in Power BI
Which THREE considerations are important when implementing row-level security (RLS) in Power BI? (Select exactly 3.)
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
✓
Roles can use DAX expressions to define filters
Option A is correct because RLS roles in Power BI define filters using DAX expressions (for example, [Region] = "West" or USERPRINCIPALNAME()), which is the core mechanism for row-level filtering. Option B is correct because RLS is designed to filter data based on the user's identity, typically via functions like USERNAME() or USERPRINCIPALNAME() mapped to a security table. Option D is correct because in DirectQuery mode, RLS filters are translated and pushed down to the source database as part of the query, so the source must be able to process them. Option C is not correct because RLS is not automatically applied in Analyze in Excel; the connection must use a role or the user must be a member of a role, and behavior depends on the connection method. Option E is not correct because RLS filters rows, not measures; restricting access to specific measures is handled through object-level security (OLS), not RLS.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Roles can use DAX expressions to define filters
Why this is correct
Roles in Power BI define row-level security by using DAX expressions as filter predicates. For example, a role can be configured with a DAX filter like `[SalesRegion] = "North"` or a more complex FILTER expression that returns a table of allowed rows. These expressions are evaluated within the filter context of each row, and only rows that return TRUE for the predicate become visible to users assigned to that role. This makes DAX the core mechanism for implementing custom, flexible row-level security in Power BI.
- ✓
RLS can filter data based on the user's identity
Why this is correct
Row-level security can be dynamic, meaning it responds to the identity of the user currently viewing the report. Power BI provides DAX functions such as `USERNAME()` and `USERPRINCIPALNAME()` that return the authenticated user's name or principal name, which can be used to match against a security table or an employee manager hierarchy. For instance, a filter like `[ManagerEmail] = USERPRINCIPALNAME()` ensures that each manager only sees rows belonging to their direct or indirect reports. This identity-based filtering is evaluated in real time, giving each user a personalized view without creating separate reports.
- ✗
RLS is automatically applied when using Analyze in Excel
Why it's wrong here
The claim that RLS is automatically applied when using Analyze in Excel is incorrect because Analyze in Excel typically establishes a live connection to a report or dataset. If the connection is made to a dataset hosted in the Power BI service, RLS does apply. However, if you use Analyze in Excel from Power BI Desktop, the connection is to the local model, and because Desktop has no concept of a signed-in report viewer, RLS is not enforced and all rows are visible. Therefore, RLS enforcement requires the dataset to live in the Power BI service, not just in Desktop or an Excel workbook.
- ✓
RLS in DirectQuery mode pushes filters to the source database
Why this is correct
When a DirectQuery dataset uses row-level security, Power BI translates the DAX role filters into native SQL WHERE clauses and pushes those filters down to the underlying data source. This means the source database itself applies the security predicates before returning data, which can significantly reduce the amount of data transferred and improve query performance. This is in contrast to Import mode, where filtering happens in the Power BI engine after all data is loaded into memory. The pushdown behavior is a key performance consideration for large or sensitive on-premises data sources that support DirectQuery.
- ✗
RLS can restrict access to specific measures
Why it's wrong here
RLS is designed to restrict rows of a table, not individual measures. A role cannot automatically hide or block a specific measure while leaving other measures visible; the measure remains computed for the rows that pass the row filter. To restrict access to sensitive measures, you must use object-level security (OLS) on the underlying columns or tables, or use a custom security layer such as a separate dataset that excludes the measure entirely. Thus, equating RLS with measure-level security is a common misconception that leads to inadequate protection of aggregated numbers.
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.