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

A semantic model has two RLS roles. The East role permits rows where Region is East, and the ProductA role permits rows where Product is A. Priya is assigned to both roles and accesses the report as a Viewer.

Which rows can Priya see?

Only rows that are both in the East region and for Product A, because role filters are combined by intersection.
Rows in the East region or for Product A, because permissions from multiple RLS roles are combined additively.
All rows, because assignment to more than one RLS role causes Power BI to ignore conflicting filters.
No rows, because a user must belong to exactly one role before Power BI can evaluate RLS.
← Back to quizzes

Microsoft Power BI Quiz

Microsoft Power BI Quiz: Understanding Rls

Practice Understanding 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 Understanding 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

A semantic model has two RLS roles. The East role permits rows where Region is East, and the ProductA role permits rows where Product is A. Priya is assigned to both roles and accesses the report as a Viewer.

Which rows can Priya see?

  1. Only rows that are both in the East region and for Product A, because role filters are combined by intersection.
  2. Rows in the East region or for Product A, because permissions from multiple RLS roles are combined additively. (correct answer)
  3. All rows, because assignment to more than one RLS role causes Power BI to ignore conflicting filters.
  4. No rows, because a user must belong to exactly one role before Power BI can evaluate RLS.
Explanation: 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.

Question 2

A report contains detailed employee compensation rows and a measure for average compensation. Managers must see only employees in their departments. Human resources analysts may see all departments. The report author creates separate app audiences but does not configure RLS.

Why does this design fail to satisfy the data-security requirement?

  1. App audiences determine which content is visible, but they do not filter the semantic model's employee rows by department. (correct answer)
  2. App audiences filter rows only for imported models, so the design would work after converting the model to DirectQuery.
  3. App audiences enforce department filters only on detail columns, so the average measure must be removed from the report.
  4. App audiences require every manager to receive Build permission before department-level filtering can be evaluated.
Explanation: 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.

Question 3

A developer defines a Finance RLS role in Power BI Desktop and publishes the semantic model. A finance user can open the report but sees no data. The role definition is present in the Power BI service, but no users or groups appear as role members.

What action should the administrator take?

  1. Assign the finance user or an appropriate security group to the Finance role in the Power BI service. (correct answer)
  2. Add the finance user as a model author in Power BI Desktop and republish the semantic model.
  3. Grant the finance user Reshare permission so the service can evaluate the Finance role definition.
  4. Create a Finance app audience because publishing automatically converts Desktop roles into app audiences.
Explanation: 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.

Question 4

A compliance requirement states that sales representatives may see customer rows only for their assigned region. They also must never see the CustomerTaxID column, even for customers in their own region.

Which statement best describes the role of RLS in meeting this requirement?

  1. RLS is unnecessary because hiding CustomerTaxID automatically restricts both the column and customers outside the assigned region.
  2. RLS can enforce both requirements by filtering CustomerTaxID to a blank value while retaining all permitted customer rows.
  3. RLS can hide CustomerTaxID from the Fields pane, which prevents the column from being queried through any connected tool.
  4. RLS can enforce the regional row restriction, but column protection requires an additional design such as object-level security or column removal. (correct answer)
Explanation: 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.

Question 5

A DirectQuery semantic model connects to a SQL database using one stored service account. The database has security logic that would filter rows by database login. Power BI users do not use single sign-on, and no RLS is defined in the semantic model. The report owner expects each viewer to receive different rows based on the viewer's Power BI identity.

Why is this expectation unsafe?

  1. Power BI automatically converts the SQL login filter into a semantic-model RLS role, but users must be assigned after publication.
  2. DirectQuery automatically imports all SQL rows into the semantic model, so database security is evaluated only during scheduled refresh.
  3. The database generally sees the shared service account, so per-viewer filtering requires model RLS or a supported identity-delegation design such as SSO. (correct answer)
  4. The database receives each viewer's app-audience name as the SQL login, so separate audiences are required for every permitted region.
Explanation: 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.

Question 6

A semantic model has correctly configured RLS roles. Ana is assigned to the West role. She is also a Contributor in the workspace that contains the semantic model. During testing, she can still see data for every region.

What is the most likely explanation, and what should be changed for a valid consumer test?

  1. RLS is disabled whenever a user belongs to a workspace; remove Ana from every semantic-model role before testing.
  2. Contributor access is not restricted by RLS; give Ana Viewer access or distribute the report through an app for testing. (correct answer)
  3. The West role must be converted to a dynamic role; static roles cannot restrict users who access workspace content.
  4. Ana needs Read permission instead of role membership; assigning a user to an RLS role automatically grants unrestricted data access.
Explanation: 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.

Question 7

A sales representative is a Viewer of a Power BI app and is assigned to an RLS role for the North region. The representative also has Build permission on the underlying semantic model so that Analyze in Excel can be used.

What should the representative normally see when querying the model through Analyze in Excel?

  1. No rows, because RLS is supported only in Power BI reports and cannot be evaluated by Analyze in Excel.
  2. All region rows, because Build permission has higher precedence than every RLS role assigned to the user.
  3. Only North-region rows, because Build permission enables model queries but does not by itself bypass RLS for a Viewer. (correct answer)
  4. Only summarized North-region values, because RLS permits measures but blocks all detail rows in external tools.
Explanation: 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.

Question 8

A report uses Sales and Budget fact tables. Both contain a TerritoryKey column. Territory has an active one-to-many relationship to Sales, but Budget is disconnected. An RLS rule filters Territory to the user's permitted territory.

Testing shows that Sales visuals are restricted but Budget visuals show all territories. What is the best explanation?

  1. RLS applies only to imported fact tables, so a disconnected Budget table cannot be secured in any semantic model.
  2. The Budget table must be hidden from report view before the Territory role can propagate its filter to that table.
  3. RLS filters report pages independently, so the Budget visuals must be moved onto the same page as the Sales visuals.
  4. The Territory filter propagates to Sales through its relationship, but Budget needs an appropriate relationship or its own security filter. (correct answer)
Explanation: 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.

Question 9

A company publishes one Power BI report containing sales for every territory. Regional managers must see only rows for their assigned territories. Executives must see all territories. All users should access the same report and semantic model.

Which security design best meets the requirement with the least report duplication?

  1. Create one app audience for managers and another for executives, and use audience membership to filter territory rows.
  2. Create an RLS role that filters territories for managers, assign managers to it, and leave executives outside restricted roles. (correct answer)
  3. Create separate report pages for each territory, hide the pages from other managers, and expose every page to executives.
  4. Grant managers Build permission on the semantic model, and grant executives Reshare permission on the published report.
Explanation: 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.

Question 10

A model contains Users, Territory, and Sales tables. Users contains one row per permitted user-territory assignment. Territory has a one-to-many relationship to Sales, and Users is related to Territory so that security filters can propagate toward Sales. The company wants one role that works for all managers.

Which role rule most directly implements dynamic RLS for this design?

  1. Filter Users so that Users[Email] equals USERPRINCIPALNAME(), allowing the user's permitted territories to propagate to Sales. (correct answer)
  2. Filter Sales so that Sales[TerritoryName] equals USERPRINCIPALNAME(), allowing sales rows to determine each user's identity.
  3. Filter Territory so that Territory[ManagerCount] equals COUNTROWS(Users), allowing each territory to identify its assigned manager.
  4. Filter Users so that Users[Email] equals the semantic model owner's email, allowing every manager to inherit owner permissions.
Explanation: 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.