- Which role rule most directly implements dynamic RLS for this design?
Answer: Filter Users so that Users[Email] equals USERPRINCIPALNAME(), allowing the user's permitted territories to propagate to Sales.
When you see a question about Row-Level Security (RLS) in Power BI, focus on two things: where the filter is applied in the data model, and how it propagates through relationships. Dynamic RLS works by anchoring a filter to the current user's identity at runtime using USERPRINCIPALNAME(), then letting the relationship chain carry that restriction downstream to the data you want to secure.
Answer A is correct because it places the filter on the Users table — specifically matching Users[Email] to USERPRINCIPALNAME(). This isolates each logged-in user to only their permitted territory rows. Since Users is related to Territory, and Territory has a one-to-many relationship to Sales, the filter naturally propagates through both relationships, restricting each manager to only their assigned sales data. One role, dynamic behavior for every manager — exactly what the requirement asks for.
Answer B inverts the logic entirely. Filtering Sales by USERPRINCIPALNAME() assumes Sales stores email addresses as territory identifiers, which contradicts the described schema and makes no semantic sense.
Answer C misuses COUNTROWS(Users) as a filter value on Territory[ManagerCount]. This is a static, aggregate comparison — not dynamic per-user — and doesn't connect a manager's identity to their territory assignments at all.
Answer D hardcodes the semantic model owner's email, making every manager see the same data as the owner. This defeats the entire purpose of per-user dynamic RLS and is a classic security misconfiguration trap.
Study tip: On Power BI RLS questions, always trace the filter from the identity function (USERPRINCIPALNAME()) through the relationship chain to the target table — the correct filter anchor is usually the table closest to the user identity, not the data itself.
- What should the representative normally see when querying the model through Analyze in Excel?
Answer: Only North-region rows, because Build permission enables model queries but does not by itself bypass RLS for a Viewer.
Whenever you see a Power BI question combining RLS roles with Build permission, your central question should be: does this permission level override row-level security? These are two separate mechanisms that operate independently of each other.
Build permission controls what a user can do with a semantic model — specifically, it allows connecting external tools like Analyze in Excel, creating composite models, or building new reports. It says nothing about which rows a user is allowed to see. RLS roles, by contrast, filter data at the row level and apply regardless of how the model is being accessed — whether through a Power BI report, a paginated report, or an external connection like Analyze in Excel. Because the sales representative holds only Viewer access to the app and is assigned to the North-region RLS role, that filter travels with them into every query context. This makes C the correct answer: Build permission opens the door to query the model externally, but RLS still controls what data comes back through that door.
Choice A is wrong because RLS absolutely applies outside of Power BI reports — it is enforced at the semantic model layer, not the report layer, so Analyze in Excel respects it fully. Choice B reflects a common misconception that Build is an elevated permission that supersedes data restrictions; it is not — it is a capability permission, not a data visibility permission. Choice D invents a restriction that does not exist; RLS does not distinguish between measures and detail rows or block granular data selectively.
Your study tip: treat Build permission and RLS as completely orthogonal concepts — one governs access to tools, the other governs access to data.
- What is the most likely explanation, and what should be changed for a valid consumer test?
Answer: Contributor access is not restricted by RLS; give Ana Viewer access or distribute the report through an app for testing.
Whenever you see a question about Row-Level Security (RLS) in Power BI, the critical concept to keep in mind is the distinction between workspace roles and RLS enforcement. These two permission systems operate independently — and that independence is exactly what this question tests.
In Power BI, RLS is only enforced for users who access a report or dataset with Viewer-level permissions or lower (such as through an app or direct sharing). Users assigned as Admin, Member, or Contributor in a workspace are considered "owners" of the content for access purposes, so RLS is bypassed entirely for them — they always see all data. Ana holds Contributor access, which is why she sees every region despite being assigned to the West role. To properly test RLS, she needs to access the content as a true consumer: either by being granted Viewer access to the workspace or by consuming the report through a published app.
Choice A is wrong because RLS isn't "disabled" — it simply doesn't apply to elevated workspace roles. The fix isn't removing her from RLS roles; it's changing her workspace permission level. Choice C is incorrect because the static vs. dynamic role distinction has nothing to do with this problem; both types of roles are bypassed equally for Contributors. Choice D misrepresents how RLS works entirely — role membership restricts data, it doesn't grant unrestricted access; the bypass comes from workspace-level permissions, not role assignment.
Study tip: Memorize this rule — RLS applies to Viewers and app consumers, not to Admins, Members, or Contributors. On the exam, if a privileged workspace member "sees all data," the answer almost always involves downgrading their workspace role or testing via an app.
- Which rows can Priya see?
Answer: Rows in the East region or for Product A, because permissions from multiple RLS roles are combined additively.
When a question asks how Power BI handles a user assigned to multiple RLS roles, the key concept to recall is how role filters are combined. Power BI uses a union (OR) logic when a user belongs to more than one role — each role's filter is applied independently, and the user sees any row permitted by at least one of their roles.
In Priya's case, the East role unlocks rows where Region = East, and the ProductA role unlocks rows where Product = A. Because she holds both roles, Power BI evaluates each filter separately and returns the combined result: rows in the East region or rows for Product A. That makes B the correct answer.
A is a common trap — it describes intersection (AND logic), where only rows satisfying both filters would be visible. This would be true if a single role had two DAX filter conditions joined by AND, but that's not how multiple role assignments work. Power BI does not intersect across roles.
C is wrong because assigning multiple roles never causes Power BI to skip or ignore filters. Each role still enforces its own filter; they simply combine additively.
D is a fabricated rule. Power BI has no requirement that a user belong to exactly one role — multi-role assignment is a supported and common configuration.
Study tip: Remember the phrase "roles add, filters restrict." Multiple role memberships expand what a user can see (union), while multiple conditions within a single role narrow what they see (intersection). This distinction appears frequently on Power BI exam questions.
- Why does this design fail to satisfy the data-security requirement?
Answer: App audiences determine which content is visible, but they do not filter the semantic model's employee rows by department.
When you see a question about data security in Power BI, always ask yourself: what mechanism actually filters rows in the underlying data model? App audiences and RLS are two separate tools that solve two different problems, and confusing them is a classic exam trap.
App audiences in Power BI apps control which pages, reports, or dashboards different user groups can see — they're a navigation and content-visibility feature, not a data-filtering engine. Because the report author relied solely on app audiences without configuring Row-Level Security, the semantic model itself has no department-based filters applied. A manager assigned to the "Finance" audience can still query the full employee compensation table; the audience just determines which report pages they land on. This means A is correct — app audiences do not filter the semantic model's rows by department, so managers can still access all employee data.
Choice B introduces a false technical distinction. App audiences have nothing to do with whether a model is Import or DirectQuery — row filtering is RLS's job regardless of storage mode. Choice C invents a rule that doesn't exist: there is no Power BI behavior where audiences selectively apply to detail columns but skip measures. Choice D conflates Build permission with RLS enforcement. Build permission controls whether a user can connect to and build new content from the semantic model; it is unrelated to evaluating department-level filters.
Study tip: Memorize this clean distinction — app audiences control what content users see, while RLS controls what data rows users can access. Exam questions frequently present one as a substitute for the other; they are never interchangeable.
- Testing shows that Sales visuals are restricted but Budget visuals show all territories. What is the best explanation?
Answer: The Territory filter propagates to Sales through its relationship, but Budget needs an appropriate relationship or its own security filter.
Whenever you see a question about Row-Level Security (RLS) in Power BI, anchor your thinking to one core principle: RLS filters flow through relationships. The security engine applies a filter to a table in your role definition, and that filter propagates to related tables — but only along active relationship paths.
In this scenario, the Territory RLS role restricts rows in the Territory table. Because Territory has an active one-to-many relationship to Sales, the filter automatically cascades down to Sales — which is exactly why Sales visuals are correctly restricted. Budget, however, has no active relationship to Territory, so the filter has no path to travel. Budget rows are returned in full, exposing all territories to every user. The fix is either to create an active relationship between Territory and Budget (so the filter propagates naturally) or to add an explicit DAX filter on Budget within the role definition itself. That reasoning confirms D as the correct answer.
A is false because RLS works with both Import and DirectQuery models; the storage mode is irrelevant here. The problem is the missing relationship, not the import mode. B is a red herring — hiding a table from Report View is a UI-level setting that affects discoverability, not security; it does nothing to enforce data-level filtering. C reflects a fundamental misunderstanding: RLS is enforced at the data model level, not the report page level. Filters do not become active or inactive based on which page a visual lives on.
Your study tip: when an RLS role isn't working on a particular table, immediately ask yourself, "Is there an active relationship path from the filtered table to this one?" If not, you must add one or write an explicit security filter for that table directly.
- What action should the administrator take?
Answer: Assign the finance user or an appropriate security group to the Finance role in the Power BI service.
When working with Row-Level Security (RLS) in Power BI, it helps to distinguish between two separate steps: defining a role and assigning users to that role. These are independent actions, and both must be completed before a user sees filtered data.
A developer creates RLS roles in Power BI Desktop by writing DAX filter expressions, then publishes the semantic model. But publishing only transfers the role definitions — it does not automatically populate role membership. That assignment must happen separately in the Power BI service, under the semantic model's Security settings. This is exactly the scenario described: the Finance role exists in the service, but nobody has been added to it. A user with no role membership falls outside all RLS roles, so the service returns no data. The fix is answer A — assigning the finance user or an appropriate Azure AD security group to the Finance role in the Power BI service.
Answer B is a red herring; model authorship in Desktop controls who can edit the data model, not who is subject to RLS filters. Answer C conflates Reshare permission (a workspace-level sharing capability) with RLS evaluation — these are unrelated concepts, and Reshare does nothing to populate role membership. Answer D is simply false; publishing a Desktop file does not convert RLS roles into app audiences. App audiences control report visibility within a Power BI app, which is an entirely separate feature.
A useful rule of thumb: whenever a question describes a role that exists but shows no data, your first instinct should be to check role membership — not the role definition itself.
- Which statement best describes the role of RLS in meeting this requirement?
Answer: RLS can enforce the regional row restriction, but column protection requires an additional design such as object-level security or column removal.
When a question involves data security in Power BI, you need to distinguish between row-level controls and column-level controls — they are separate mechanisms that solve separate problems.
Row-Level Security (RLS) works by applying DAX filter expressions to tables, restricting which rows a user can see based on their identity or role. It's well-suited for the regional requirement here: you define a role that filters the customer table to rows matching the sales rep's assigned region. This is exactly what RLS was designed to do, making D correct on that half of the requirement.
However, RLS has no native ability to hide or restrict individual columns. The second requirement — blocking CustomerTaxID entirely — falls outside RLS's scope. Achieving column-level restriction in Power BI requires either Object-Level Security (OLS), which is configured in Tabular Editor or through the XMLA endpoint and blocks access to a specific column altogether, or physically removing the column from the model during data transformation.
Now for the distractors: A is wrong because hiding CustomerTaxID does nothing by itself to filter rows by region — those are unrelated mechanisms. B is wrong because RLS cannot filter a column to a blank value; it only filters rows, and "blanking" a column is not a built-in RLS behavior. C is wrong because hiding a field from the Fields pane is a cosmetic UI setting only — it does not prevent the column from being queried through tools like DAX Studio or external connections.
A useful rule to remember: RLS = rows, OLS = columns. Any exam question that mixes both security needs is testing whether you recognize they require separate solutions.
- Which security design best meets the requirement with the least report duplication?
Answer: Create an RLS role that filters territories for managers, assign managers to it, and leave executives outside restricted roles.
When a question asks you to enforce row-level data restrictions across a shared report without duplicating it, think immediately about Row-Level Security (RLS) in Power BI. RLS is the purpose-built feature for filtering what rows different users see within the same semantic model and report.
Option B is the right design. You define an RLS role in the semantic model that filters the territory table to only the rows matching the signed-in manager's assignment. Managers are added to that role in the Power BI service, so they automatically see only their data. Executives are simply not assigned to any restricted role, which means they pass through unfiltered and see all territories. One report, one model, zero duplication — exactly what the requirement demands.
Option A is a trap. App audiences control which pages or reports are visible to different user groups; they don't filter rows within a dataset. A regional manager could still see another territory's rows if they accessed the underlying report.
Option C creates enormous maintenance overhead by building separate pages per territory and managing page visibility. This directly violates the "least report duplication" constraint and doesn't scale as territories grow.
Option D conflates permissions with data filtering. Build permission lets users create their own reports from the model; Reshare lets users share the report with others. Neither permission restricts which rows a user sees — they're about what users can do, not what data they can read.
Study tip: On Power BI exam questions, anytime you see "same report, different data per user," that's your signal to think RLS — not app audiences, page visibility, or workspace permissions.
- Why is this expectation unsafe?
Answer: The database generally sees the shared service account, so per-viewer filtering requires model RLS or a supported identity-delegation design such as SSO.
When a DirectQuery semantic model uses a single shared service account to connect to a SQL database, every query Power BI sends to that database arrives authenticated as that one account — regardless of which end user triggered the report interaction. The database has no way to distinguish between viewers, so any row-level security logic built into the database around the login identity will apply uniformly (or not at all) to everyone. For per-viewer filtering to work, you need either model-level RLS defined in Power BI, or a supported identity-delegation mechanism like single sign-on (SSO), which passes each viewer's actual identity through to the database. That's exactly what C captures.
Choice A is wrong because Power BI never automatically converts database security logic into semantic model RLS roles — that mapping must be explicitly designed and configured by the model author. Choice B describes Import mode behavior, not DirectQuery. In Import mode, data is copied into the model during refresh; DirectQuery sends live queries to the source and does not cache imported rows. Choice D invents a behavior that doesn't exist — Power BI does not transmit app audience names as SQL logins. This is a fabricated mechanism with no basis in how DirectQuery or SQL authentication works.
A useful pattern to remember: whenever a question involves DirectQuery with a shared credential and no SSO or RLS, assume the database sees only one identity. Per-user data isolation always requires an explicit solution — either model RLS, object-level security, or SSO with identity delegation. The database cannot infer viewer identity on its own.
