- Which View as configuration provides the intended test?
Answer: Select ManagerAccess, select Other user, and enter alex@contoso.com as the simulated identity.
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.
- What should the developer do next?
Answer: Publish the model, and then add the employees as members of EastManagers in the Power BI service.
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.
- Which role filter should you create on Employee?
Answer: Employee[EmailAddress] = USERPRINCIPALNAME()
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.
- Which rows should you expect to see while viewing the report as both roles?
Answer: Rows permitted by either North or Retail, because permissions from multiple roles are combined additively.
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.
- Which model change most directly supports ShipDate-based RLS while preserving OrderDate analysis?
Answer: Create a separate Ship Date dimension with an active relationship to Sales through ShipDate, and apply the role filter there.
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.
- Which change is the best way to make both Sales and the seller slicer reflect the permitted sellers?
Answer: Apply the RLS filter to Seller instead, allowing the active relationship to filter Sales from the dimension.
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.
- Assuming no other role is selected, what result should the properly configured role produce?
Answer: No Sales rows, because the identity filter finds no Employee row to propagate to Sales.
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.
- Which configuration most appropriately creates and validates the required row-level security in Power BI Desktop?
Answer: In Manage roles, filter Region[RegionName] to "West", and then use View as to select WestUsers.
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.
- Which action provides the required row-level protection for Finance payroll data?
Answer: Create a role that filters the related Department table to Finance and test the role by using View as.
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.
- What is the effective result when this role is tested in Power BI Desktop?
Answer: Sales is restricted to rows that are in the West region and have a Bikes product.
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.
