Courseiva
← PL-300
Full test
Manage and secure Power BI →hardMultiple ChoiceObjective-mapped

Why RLS Is Bypassed: The effectiveIdentity Property in Power BI

Exhibit

{
  "datasets": [
    {
      "name": "SalesDataset",
      "effectiveIdentity": "user@contoso.com",
      "RLS": true,
      "roles": [
        {
          "name": "SalesRole",
          "users": [
            {"identity": "sales@contoso.com"},
            {"identity": "manager@contoso.com"}
          ]
        }
      ]
    }
  ]
}

Refer to the exhibit. You are reviewing the configuration of a Power BI dataset with row-level security (RLS). A user named 'user@contoso.com' reports that they can see all data when they should see only data for their region. What is the most likely cause?

Quick Answer

The answer is the effectiveIdentity property being set to the user’s email, which bypasses RLS. In Power BI, the effectiveIdentity is a testing override that forces the system to evaluate RLS as if a specific user is making the request; when it is hardcoded to ‘user@contoso.com’, that user sees all data regardless of their assigned role. This scenario tests your understanding of the RLS effective identity bypass, a common pitfall in the PL-300 exam where candidates confuse role configuration with identity enforcement. The trap is that the roles and mappings may look correct, but the effective identity explicitly overrides them, granting full access. For the exam, remember that effectiveIdentity is for testing only—if it is set to a real user in production, RLS is effectively disabled. Memory tip: “Effective identity equals effective bypass”—if you see a specific user in that property, RLS is not filtering for them.

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

✓

The 'effectiveIdentity' is set to the user's email, bypassing RLS.

The 'effectiveIdentity' property in the exhibit is set to 'user@contoso.com', which overrides RLS and allows that user to see all data. In Power BI, the effective identity is used for testing purposes; in production, it should not be set for a specific user if RLS is intended. Option B is incorrect because the exhibit shows RLS roles are defined, so missing mapping is not the issue. Option C is incorrect because roles exist. Option D is incorrect because the user is likely assigned to a role, but the effective identity overrides it.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    The 'effectiveIdentity' is set to the user's email, bypassing RLS.

    Why this is correct

    The effective identity setting forces the dataset to use that identity, ignoring RLS for that user.

  • ✗

    The RLS roles are missing the 'SalesRole' mapping to the dataset.

    Why it's wrong here

    The roles are connected to the dataset; the issue is the effective identity.

  • ✗

    The dataset does not have any RLS roles defined.

    Why it's wrong here

    The exhibit shows roles are defined.

  • ✗

    The user is not assigned to any RLS role.

    Why it's wrong here

    The user is not listed, but the effective identity overrides RLS.

About these practice questions

This PL-300 question is part of Courseiva's 217-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 →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

3 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 are troubleshooting an RLS configuration. The role 'SalesManager' is intended to restrict the user 'salesmanager@contoso.com' to see only their data. However, the user sees all data. What is the most likely issue?

medium
  • A.The filter expression should be '= "salesmanager@contoso.com"' without USERPRINCIPALNAME().
  • ✓ B.The filter expression compares the user's UPN to a static string, but there is no column in the table to filter against.
  • C.The dataset is using DirectQuery, which does not support RLS.
  • D.The model permission should be 'ReadAndExplore' instead of 'Read'.

Why B: The filter expression uses DAX's USERPRINCIPALNAME() to retrieve the current user's UPN, but then compares it to a static string 'salesmanager@contoso.com'. For Row-Level Security (RLS) to work, the filter must compare a column in the table (e.g., a 'UserEmail' column) to the function result. Since no such column exists, the filter cannot restrict any rows, and the user sees all data. Option A is incorrect because removing USERPRINCIPALNAME() would not help; the core issue is the missing column. Option C is incorrect because DirectQuery does support RLS as long as the filter uses valid columns. Option D is incorrect because 'Read' permission is sufficient for RLS; changing to 'ReadAndExplore' is not necessary.

Variation 2. You are configuring row-level security (RLS) for a Power BI dataset. The sales data includes a 'Region' column. You want users in the 'Sales Managers' group to see data only for their assigned region, which is stored in a separate mapping table. You create the following DAX filter: [Region] = LOOKUPVALUE(EmployeeRegion[Region], EmployeeRegion[UserPrincipalName], USERPRINCIPALNAME()). When testing, a user in 'Sales Managers' sees no data. What is the most likely issue?

hard
  • ✓ A.The LOOKUPVALUE function returns multiple values for the user, causing an error.
  • B.The USERPRINCIPALNAME function is not supported in RLS filters.
  • C.The DAX filter syntax is incorrect; it should use CALCULATE.
  • D.RLS requires a Premium capacity license.

Why A: LOOKUPVALUE returns an error if it finds multiple values for the same user (e.g., duplicate entries in the EmployeeRegion table), causing the filter to fail and return no data. Option B is wrong because USERPRINCIPALNAME() is supported in RLS filters in Power BI Service. Option C is wrong because the syntax is valid; CALCULATE is not required for RLS filters. Option D is wrong because RLS is available in Power BI Pro, not just Premium.

Variation 3. Refer to the exhibit. You are configuring row-level security (RLS) for a Power BI dataset. The JSON shows a role named 'RegionManager' with a filter expression. Users assigned to this role complain that they see all regions instead of only 'North'. What is the likely cause?

medium
  • A.The 'Read' permission should be 'ReadAndExplore' to apply filters.
  • B.The role name 'RegionManager' is case-sensitive and must match the user's group name.
  • C.The filter expression is written in M language, which is not supported for RLS.
  • ✓ D.The filter expression uses incorrect DAX syntax; it should reference the table name, e.g., 'Sales[Region] = "North"'.

Why D: In Power BI RLS, filter expressions must reference columns with the full table name, e.g., 'Sales[Region] = "North"'. The JSON shows '[Region] = "North"', which lacks the table name and thus is invalid DAX syntax. Option A is incorrect because 'Read' permission is sufficient for RLS to filter data; 'ReadAndExplore' is not required. Option B is incorrect because role names are not case-sensitive in Power BI RLS. Option C is incorrect because RLS filters use DAX, not M language.

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.