Validating Dynamic RLS in Power BI
You have a semantic model named Model1. Model1 contains five tables that all use Import mode. Model1 contains a dynamic row-level security (RLS) role named HR. The HR role filters employee data so that HR managers only see the data of the department to which they are assigned. You publish Model1 to a Fabric tenant and configure RLS role membership. You share the model and related reports to users. An HR manager reports that the data they see in a report is incomplete. What should you do to validate the data seen by the HR Manager?
Community Votes
79% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The question tests the distinction between static and dynamic RLS, where selecting a generic role fails to validate user-specific data access without specifying the user identity.
This question addresses how to troubleshoot incomplete data visibility for users with dynamic row-level security (RLS) roles. The correct approach involves testing the role as a specific user to account for individual filtering logic.
Many learners choose Option A because it references the role name 'HR' directly, missing that dynamic RLS requires impersonating a specific person to see their filtered view.
Community Discussion (22 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option C is correct because dynamic Row-Level Security (RLS) relies on user attributes (like email or department) to filter data at runtime. To validate what an HR manager sees, you must use the 'Test as role' feature but specify the actual user (the HR manager). This allows you to see exactly which rows are visible to that specific individual based on the dynamic rules applied to their identity.Why the Other Options Are Wrong
Option A selects only the role ('HR') without a user context; while valid for static roles, it does not fully simulate the experience of a specific user in a dynamic setup. Option B suggests manually filtering in the report, which is a workaround rather than a validation of the security configuration. Option D is incorrect because opening Power BI Desktop locally does not reflect the published service behavior or RLS membership configured in the tenant.Community Comment Notes
Community consensus strongly favors C, noting that 'dynamic' implies per-user logic. As one commenter noted, 'Selecting A... would work for a static rule... but as it is dynamic you will need to input as well the HR manager email.' Another user clarified that 'There's no role called HR MANAGER,' emphasizing the need to test as the person, not just the role definition.Official Reference
Exam Strategy
When troubleshooting RLS issues involving 'dynamic' roles, always look for options that involve testing as a specific user rather than just the role itself. This ensures you are validating the intersection of the role definition and the user's specific attributes.
Frequently Asked Questions
Why can't I just test as the 'HR' role?
Static roles show all data allowed by the role. Dynamic roles require a specific user identity to apply filters correctly, so testing as a user is necessary.
Does 'Test as role' work in Power BI Service?
Yes, administrators can use 'Test as role' in the Power BI Service portal to simulate access for specific users assigned to roles.
Related Analysis
Practice All DP-600 Questions
Access 115 questions with complete answers and detailed explanations.
View Full DP-600 Practice Test →