Row-level security restricts the rows available through a semantic model under the applicable user's role. Hiding a visual or applying an ordinary slicer is not the same security boundary.

These Power BI interview questions use fictional North and South data. The exercise is to verify both allowed and denied rows, including totals and alternate report views.

How can a simple role be defined?

Use a Region table with unique RegionId values N and S, and a related Sales table with amounts 100 for North and 50 for South. Create an active relationship from Region to Sales with the intended security propagation.

-- Role filter on the Region table for this static exercise:
Region[RegionId] = "N"

Enter the expression as the role filter on Region, rather than as a normal measure. Under that role, North sales should be available and South sales should be excluded. A total for the protected sales data should reflect only the allowed rows.

What must be checked in the model?

A role on Region protects related facts only through the model's effective security relationships. Inspect inactive paths, bridge tables and disconnected copies of protected data. A second unrelated fact table can accidentally remain unfiltered.

Do not enable bidirectional security propagation everywhere as a shortcut. Use it only with a clear model requirement and tests for the resulting paths. Security behavior deserves a deliberate design.

How does testing as a role help?

Use the supported View as or Test as role features to inspect the restricted view. Include a view with individual rows and another with totals. Check a user who should see North, a user who should see South and a user without the intended assignment.

A model-author view can show more data than a report consumer should see. Passing a test as the author does not prove a restricted consumer has the same protection.

What changes after publication?

Role membership and sharing context matter in the service. Power BI workspace roles with editing permissions have different RLS applicability from a Viewer. Test with the intended consumer access level and supported role assignments.

For dynamic security, verify the actual identity value used by the environment and its mapping to permitted rows. A guessed email string in a local fixture is not proof that service identity mapping works.

Can multiple roles expand access?

Membership in multiple roles can combine allowed rows. Do not assume a restrictive role subtracts rows granted by another role. Review all applicable memberships when a user sees more than expected.

Row-level security also does not mean every model object or column is hidden. Requirements to conceal particular columns or metadata need the appropriate separate design and supported features.

What does a useful checklist include?

  • Allowed row IDs are present.
  • Forbidden row IDs are absent.
  • Totals match the restricted rows.
  • Related fact tables follow the intended boundary.
  • Multiple-role membership is tested.
  • The published report is checked with the intended consumer role.

Include export and other consumption paths that the deployment permits. Keep access checks tied to the real permissions rather than assuming the visible report is the only way data can be consumed.

Interview answer to practice

Explain the identity, role filter, relationship path and service access context. Then name one denied-row test. That shows you can validate a security requirement instead of merely creating a role with a plausible name.

References and next practice

learn.microsoft.com — bi security

Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud