Microsoft Power BI Quiz: Row Level Security Rls
10 questions · exam conditions
0:00
Row Level Security RlsQuestion 1 of 10

Within one role, a developer defines Region[RegionName] = "West" and Product[Category] = "Bikes". Both dimension tables have active relationships that filter Sales.

What is the effective result when this role is tested in Power BI Desktop?

Sales is restricted to rows that are in the West region and have a Bikes product.
Sales includes rows that are in the West region or have a Bikes product.
Sales is restricted only by the Region filter because it was defined before Product.
Sales remains unrestricted because one role cannot contain filters on two different tables.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Row Level Security Rls

Practice Row Level Security Rls in Microsoft Power BI with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Row Level Security Rls, giving you a quick way to practice the rules, question types, and explanations that matter most for Microsoft Power BI.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

Within one role, a developer defines Region[RegionName] = "West" and Product[Category] = "Bikes". Both dimension tables have active relationships that filter Sales.

What is the effective result when this role is tested in Power BI Desktop?

  1. Sales is restricted to rows that are in the West region and have a Bikes product. (correct answer)
  2. Sales includes rows that are in the West region or have a Bikes product.
  3. Sales is restricted only by the Region filter because it was defined before Product.
  4. Sales remains unrestricted because one role cannot contain filters on two different tables.
Explanation: When working with Row-Level Security (RLS) in Power BI, it helps to think of filters within a single role as a security contract — every condition listed must be satisfied simultaneously, not alternatively. Within one role, multiple DAX filter expressions across different tables are combined using AND logic. This means a user assigned that role must satisfy all defined filters at once. In this scenario, Region[RegionName] = "West" restricts the Region table to West, and Product[Category] = "Bikes" restricts the Product table to Bikes. Because both dimension tables have active relationships flowing into the Sales table, Sales is effectively filtered to only rows connected to both the West region and the Bikes category — confirming that A is correct. B is the most tempting trap. You might assume that two separate filter rules create an OR condition, but that is not how Power BI handles intra-role filters. OR logic would only apply if you explicitly wrote it inside a single DAX expression using ||. C is wrong because Power BI evaluates all filters within a role regardless of the order they were written. There is no "first defined wins" hierarchy — both filters are always applied. D is incorrect because Power BI absolutely supports multiple table filters within a single role. A role can contain as many filter expressions as needed, and they all take effect simultaneously. Your study tip: always distinguish within-role logic (AND — all filters apply) from multi-role logic (OR — a user in multiple roles gets the union of permissions). This distinction is a frequent exam trap.

Question 2

A Sales table contains OrderDate and ShipDate. Date has an active relationship to Sales through OrderDate and an inactive relationship through ShipDate. A role filter on Date is intended to restrict rows according to ShipDate, but testing shows that it restricts rows according to OrderDate.

Which model change most directly supports ShipDate-based RLS while preserving OrderDate analysis?

  1. Enable automatic date/time and rely on its local date table to propagate the existing role filter.
  2. Keep both relationships unchanged and select Other user when testing the role in the View as dialog.
  3. Move the Date filter to a report-level filter and hide the ShipDate column from report authors.
  4. Create a separate Ship Date dimension with an active relationship to Sales through ShipDate, and apply the role filter there. (correct answer)
Explanation: When Power BI applies Row-Level Security, filters travel through active relationships only. That's the core concept being tested here. If your role filter sits on a Date table that has an active relationship to OrderDate and an inactive relationship to ShipDate, the filter will always follow the active path — no matter your intention. The cleanest fix is option D: create a dedicated Ship Date dimension table with its own active relationship to the ShipDate column in Sales. Now your role filter on that Ship Date table flows through an active path directly to ShipDate, while your original Date table retains its active relationship to OrderDate — preserving all existing OrderDate-based reports and calculations. Both analysis paths coexist without conflict. Option A fails because enabling automatic date/time generates hidden local date tables per column, but it doesn't change which relationships are active or inactive. The role filter still propagates through the original active path to OrderDate. Option B is a testing/debugging feature, not a model fix — "View as other user" lets you simulate a role's perspective, but selecting it doesn't alter how filters propagate through relationships. The underlying problem remains. Option C moves the restriction to a report-level filter, which is not RLS at all — report-level filters can be bypassed by users who access the dataset directly, so this is a security anti-pattern, not a solution. As a study tip, remember this rule: RLS filters only travel through active relationships. Whenever a question involves filtering through a non-active relationship, the answer almost always involves either using USERELATIONSHIP() in a measure or — for RLS specifically — creating a separate dimension with its own active relationship.

Question 3

A dynamic role filters Employee[Email] by USERPRINCIPALNAME(). Employee filters Sales through an active relationship. During testing, you enter newmanager@contoso.com, but that address has no matching Employee row.

Assuming no other role is selected, what result should the properly configured role produce?

  1. The first Employee's Sales rows, because the relationship substitutes a default dimension member.
  2. All Sales rows, because an unmatched identity causes the dynamic role filter to be ignored.
  3. No Sales rows, because the identity filter finds no Employee row to propagate to Sales. (correct answer)
  4. An RLS configuration error, because every tested identity must already exist in the Employee table.
Explanation: When you see a question about dynamic RLS (Row-Level Security) in Power BI, think carefully about what happens at the filter stage before any relationship propagation occurs. The role applies a DAX filter to a dimension table first — only matching rows survive — and then that filtered set propagates through model relationships to fact tables. Here's the core logic: the role filters Employee[Email] where the value equals USERPRINCIPALNAME(). If newmanager@contoso.com doesn't exist in the Employee table, the filter returns zero rows. With no Employee rows passing the filter, there is nothing to propagate across the relationship to Sales. The result is an empty Sales table — no rows returned. That makes C the correct answer. A is wrong because Power BI relationships have no concept of a "default dimension member." If no dimension rows match, the fact table receives no context — there's no fallback substitution behavior built into RLS propagation. B describes a dangerous misconception: that a failed identity match causes the filter to be ignored, effectively granting full access. The opposite is true — a failed match produces an empty filter result, which is the most restrictive outcome possible, not the least. D is incorrect because Power BI doesn't validate whether a tested identity exists in the underlying data at configuration time. You can freely test any UPN in the "View as role" feature; no error is thrown simply because the address is absent from the table. Study tip: Think of dynamic RLS as a two-step gate — identity match first, relationship propagation second. If step one returns nothing, step two has nothing to pass through.

Question 4

A role named ManagerAccess uses Manager[Email] = USERPRINCIPALNAME(). You need to test what alex@contoso.com would see, even though you are signed in to Desktop with a different identity.

Which View as configuration provides the intended test?

  1. Select ManagerAccess only, and change the Windows display name temporarily to Alex's email address.
  2. Select ManagerAccess, select Other user, and enter alex@contoso.com as the simulated identity. (correct answer)
  3. Select Other user only, enter Alex's email, and leave every defined security role unselected.
  4. Select ManagerAccess, enter Alex's email in a report slicer, and refresh all report visuals.
Explanation: When testing row-level security (RLS) in Power BI Desktop, you need to simulate two things simultaneously: which role applies the filter rules, and which identity is injected into DAX functions like USERPRINCIPALNAME(). The "View as Roles" (or "View as") dialog lets you control both independently, and understanding that distinction is the key to this question. Because the role ManagerAccess uses Manager[Email] = USERPRINCIPALNAME(), the filter only returns rows where the Manager email matches the current user's principal name. If you want to see what alex@contoso.com sees, you must activate the role and tell Power BI to treat alex@contoso.com as the authenticated identity. Option B does exactly that — selecting ManagerAccess applies the role's DAX filter, while choosing "Other user" and entering alex@contoso.com causes USERPRINCIPALNAME() to return that address during evaluation. Together, these two settings produce an accurate simulation. Option A is wrong because changing a Windows display name does not affect USERPRINCIPALNAME() — that function reads the authenticated UPN, not a display label. Option C is wrong because leaving all roles unselected means no RLS filter is applied at all; you'd see unfiltered data regardless of the identity entered. Option D is wrong because report slicers are visual filters, completely separate from RLS and USERPRINCIPALNAME() — entering an email in a slicer does nothing to the security context. A good study tip: whenever a DAX security expression uses USERPRINCIPALNAME(), remember that testing it correctly requires both a role selection and an "Other user" identity — neither alone is sufficient.

Question 5

Seller is on the one side of an active, single-direction relationship to Sales. A developer applies an RLS filter directly to Sales by seller key. Sales totals are restricted correctly, but a slicer built from Seller[SellerName] still lists every seller.

Which change is the best way to make both Sales and the seller slicer reflect the permitted sellers?

  1. Keep the Sales role filter and hide the unpermitted seller values by using a visual-level filter.
  2. Apply the RLS filter to Seller instead, allowing the active relationship to filter Sales from the dimension. (correct answer)
  3. Keep the Sales role filter and mark Seller as a date table so filters propagate back to it.
  4. Apply identical report-level filters to Sales and Seller, and remove the RLS role from the model.
Explanation: When working with Row-Level Security in Power BI, always ask yourself: where should the filter originate? In a one-to-many relationship, filters naturally flow from the "one" side (the dimension) down to the "many" side (the fact table). RLS works best when you align with this direction rather than fight against it. Placing the RLS filter on the Seller table (option B) is the correct approach because the active relationship then carries that restriction automatically into Sales. When a user's permitted sellers are filtered at the dimension level, every visual connected to either table — including slicers built from Seller[SellerName] — respects the filter. You get one clean, centralized rule that propagates naturally through the model. Option A fails because visual-level filters are a cosmetic fix, not a security measure. They hide values in one specific visual but don't enforce data restrictions model-wide, so a user could still access forbidden data through another visual or export. Option C is a misconception about "Mark as Date Table" — that setting is strictly for time intelligence functions and has absolutely nothing to do with how RLS filters travel between tables. It would not cause filters to propagate back to Seller. Option D is dangerous: removing the RLS role and relying on report-level filters provides no real security. Report filters can be bypassed through tools like Analyze in Excel or direct dataset connections, exposing sensitive data entirely. Study tip: On Power BI RLS questions, remember that filters flow from dimension tables to fact tables. Always apply your RLS filter on the dimension (one-side) and let the relationship do the rest.

Question 6

A developer creates and successfully tests a role named EastManagers in Power BI Desktop. The developer now needs three employees to receive that role after the semantic model is published.

What should the developer do next?

  1. Add the employees to the role from Desktop Manage roles before publishing the semantic model.
  2. Enter the employees' email addresses in the Desktop View as dialog and save the PBIX file.
  3. Publish the model, and then add the employees as members of EastManagers in the Power BI service. (correct answer)
  4. Share the PBIX file with the employees and ask each employee to select EastManagers in View as.
Explanation: When working with Row-Level Security (RLS) in Power BI, it's essential to understand the two-phase workflow: roles are defined in Power BI Desktop, but role membership (assigning actual users) must be managed in the Power BI service after publishing. In Power BI Desktop, you use Manage Roles to create roles and write DAX filter expressions — this is where EastManagers was built and tested. However, Desktop has no concept of organizational users or email addresses in the context of role assignment. Once you publish the semantic model to the Power BI service, you navigate to the dataset settings and select Security, where you can add users' email addresses (or security groups) as members of the EastManagers role. This is exactly what option C describes, making it the correct answer. Option A is tempting but wrong — Manage Roles in Desktop is only for defining and testing roles with DAX filters, not for permanently assigning employees. Any "member" entries you attempt there don't carry organizational user assignments into the published model. Option B misrepresents the "View as" feature in Desktop, which is a testing tool that lets developers preview data as if they were in a role — it's not a way to assign employees, and saving the PBIX file does nothing to grant access. Option D compounds this misunderstanding: "View as" is a developer preview tool, not an end-user access mechanism, and sharing a PBIX file doesn't grant Power BI service access. Remember this rule: define roles in Desktop, assign members in the Service. On the exam, any answer that tries to assign users before publishing or through Desktop tools is a distractor.

Question 7

A model has two static roles. The North role permits only North rows, and the Retail role permits only Retail rows. While testing in Power BI Desktop, you select both roles in the View as dialog.

Which rows should you expect to see while viewing the report as both roles?

  1. Rows permitted by either North or Retail, because permissions from multiple roles are combined additively. (correct answer)
  2. Only rows that are both North and Retail, because filters from multiple roles are intersected.
  3. Only rows permitted by North, because Desktop evaluates the first selected role exclusively.
  4. No rows, because Power BI Desktop can test only one security role at a time.
Explanation: When a question involves testing multiple Row-Level Security (RLS) roles in Power BI, the key concept to understand is how role permissions combine — and the answer is always additive, not restrictive. In Power BI's security model, RLS roles filter data using DAX expressions. When you apply multiple roles simultaneously — whether in production (by belonging to multiple roles) or during testing via the View as dialog in Power BI Desktop — the filters from each role are combined with a logical OR. This means a row is visible if it satisfies any of the active roles. So viewing as both North and Retail shows you rows that are North rows, Retail rows, or both. Answer A correctly captures this behavior. Answer B describes the opposite behavior — an AND intersection — which would only show rows that are simultaneously North and Retail. This would actually restrict your view more than either single role, which contradicts how Power BI is designed to work. Answer C suggests Desktop ignores all but the first role, which is simply false — the View as dialog is specifically built to simulate multiple roles at once. Answer D is also false; Power BI Desktop absolutely supports multi-role testing through the View as interface; this is one of its core RLS debugging features. A useful study tip: remember the phrase "multiple roles = more access, not less." Power BI uses OR logic across roles, so adding roles expands the visible dataset. If a question tries to make multi-role filtering sound like an intersection or limitation, that's your signal to choose the additive option.

Question 8

A report page containing payroll details is hidden. A page filter limits the page to the Finance department, but no RLS role has been created. The report will be distributed to employees from several departments.

Which action provides the required row-level protection for Finance payroll data?

  1. Hide the payroll fields in report view and validate the hidden page by using Performance Analyzer.
  2. Keep the page hidden and lock every payroll visual so report consumers cannot modify the layout.
  3. Keep the page filter and disable visual interactions between the payroll visuals and department slicers.
  4. Create a role that filters the related Department table to Finance and test the role by using View as. (correct answer)
Explanation: Whenever you see a question about protecting sensitive data in Power BI, you need to distinguish between visual security (hiding things from view) and data security (preventing unauthorized data access at the model level). This distinction is critical — cosmetic hiding is never a substitute for true access control. Row-Level Security (RLS) is the correct tool here. By creating a role that filters the Department table to Finance, you ensure the underlying data is restricted regardless of how the report is consumed, shared, or exported. Testing with View as lets you verify the role behaves correctly before deployment. Option D is the only choice that implements genuine, enforceable data protection — making it the correct answer. Option A is a trap: hiding fields in Report View is purely cosmetic. A determined user can still access the underlying data through other means, such as Analyze in Excel or a direct dataset connection. Performance Analyzer measures rendering performance, not security. Option B compounds the same mistake. A hidden page offers zero data protection — hidden pages can be revealed, and locking visuals only prevents layout edits, not data exposure. Option C disabling visual interactions controls how visuals filter each other on screen, but it does nothing to restrict what data a user can retrieve from the dataset. A page filter is similarly bypassed once someone connects directly to the dataset. Study tip: On the Power BI exam, any answer involving hiding pages, locking visuals, or disabling interactions as a security measure is almost always wrong. Real data protection requires RLS roles defined in the model — remember: if it's only visual, it's not secure.

Question 9

A model has an Employee table containing one row per employee and an EmailAddress column. Employee has an active one-to-many relationship to Expense. The security requirement is that each signed-in employee can view only that employee's expenses.

Which role filter should you create on Employee?

  1. Employee[EmailAddress] = USERPRINCIPALNAME() (correct answer)
  2. Expense[EmailAddress] = USERPRINCIPALNAME()
  3. Employee[EmailAddress] = USERNAME() && Expense[Amount] > 0
  4. Employee[EmailAddress] IN ALL(Employee[EmailAddress])
Explanation: When implementing Row-Level Security (RLS) in Power BI, your goal is to filter a table so that each user sees only their own data. The key decision is which table to filter and which function to use to identify the signed-in user. Because Employee has an active one-to-many relationship to Expense, filtering the Employee table automatically propagates down to the Expense table — you never need to filter the Expense table directly. This makes A the correct answer: Employee[EmailAddress] = USERPRINCIPALNAME() filters Employee to the single row matching the signed-in user's identity, and the relationship cascades that filter to show only that employee's expenses. It's clean, targeted, and works with how Power BI's filter propagation is designed. B is wrong because it places the filter on the Expense table rather than Employee. While this might seem intuitive, it assumes Expense has its own EmailAddress column, which the scenario doesn't establish — and more importantly, you should filter on the "one" side of the relationship to let propagation do the work. C introduces USERNAME(), which returns a domain\username format rather than an email address, so it won't match an EmailAddress column reliably in most cloud environments. The added && Expense[Amount] > 0 condition is also irrelevant to the security requirement and would incorrectly hide zero-amount expenses. D uses ALL(Employee[EmailAddress]), which removes filters and returns every email address — the exact opposite of restricting access. As a study tip: on RLS questions, always filter the lookup/dimension side of a relationship using USERPRINCIPALNAME() for cloud-based identity matching, and let relationship propagation handle the rest.

Question 10

A model contains a Region table on the one side of an active one-to-many relationship with a Sales table. A role named WestUsers must restrict users to western-region rows. Region names also appear in report slicers.

Which configuration most appropriately creates and validates the required row-level security in Power BI Desktop?

  1. In Manage roles, filter Region[RegionName] to "West", and then use View as to select WestUsers. (correct answer)
  2. In Manage roles, filter Sales[RegionName] to "West", and then hide the Region table from report view.
  3. Add a report-level filter for the West region, and then use Performance Analyzer to validate the filter.
  4. Reverse the relationship so Sales filters Region, and then use View as without creating a role.
Explanation: When a question asks about row-level security (RLS) in Power BI, focus on two things: where the filter should live in the data model, and how to validate it before publishing. RLS works by filtering tables, and because the relationship flows from Region (one side) to Sales (many side), placing a DAX filter on Region[RegionName] is ideal. Power BI will automatically propagate that filter downstream to Sales through the active relationship. Option A does exactly this — it creates the WestUsers role with a filter on Region[RegionName] = "West", then uses the View as feature in Power BI Desktop to impersonate that role and confirm users see only western data. This is the correct, purpose-built workflow for RLS creation and validation. Option B filters Sales[RegionName] instead of the Region table. While this might technically restrict Sales rows, it bypasses the model's relationship logic, can miss rows, and doesn't filter the Region table itself — meaning slicers showing region names could still expose non-western regions to users. Option C uses a report-level filter, which is purely a visual layer and provides no real security; any user with direct dataset access can bypass it entirely. Option D reversing the relationship direction breaks the intended data model design and using View as without a defined role doesn't enforce any RLS at all — it's not a valid security configuration. Remember this pattern: always apply RLS filters on the lookup/dimension table (the "one" side) when a relationship exists, so the filter cascades naturally. Use View as — not Performance Analyzer — to test RLS roles in Desktop.