What's changed: Created PL-300 Chapter 5, completing the textbook (domain: Manage and secure). Managing workspaces and assets (workspaces/apps, distribution, dashboards, subscriptions/alerts, promote/certify, on-premises data gateway, scheduled refresh) and security and governance (workspace roles Admin/Member/Contributor/Viewer, Build permission, row-level security RLS (static/dynamic USERNAME()), RLS group assignment, sensitivity labels).
5.2Security and governance
Understand workspace roles, item-level access, semantic model Build permission, row-level security (RLS), and sensitivity labels.
Show only the right data to the right people. Access control and row-level filtering are at the heart of Power BI security.
5.2.1Workspace roles and access
Workspace roles are development-side permissions: Admin > Member > Contributor > Viewer in decreasing power (Admin manages access; Contributor creates/edits; Viewer reads only). For post-distribution viewers, grant item-level access or app access; to let others reuse a semantic model, grant the Build permission.
5.2.2Row-level security (RLS)
Row-level security (RLS) limits which rows a user sees. In Power BI Desktop you define roles with a DAX filter expression per table (e.g., [Region] = "East"). There is static RLS (fixed conditions) and dynamic RLS using USERNAME()/USERPRINCIPALNAME() to filter by the signed-in user. In the service you assign users/groups to roles to apply it. RLS controls row visibility, a separate layer from whether someone can open the item at all (access control).
5.2.3Sensitivity labels
Sensitivity labels integrate with Microsoft Purview to classify reports/data (e.g., "Confidential") and apply encryption, access restrictions, and protection on export. This is classification and governance, different in purpose from RLS that filters rows.
Cues: "dev permission strength" = Admin>Member>Contributor>Viewer. "others reuse the model" = Build permission. "limit rows per user" = RLS (DAX filter). "filter dynamically by signed-in user" = dynamic RLS (USERNAME()). "classify Confidential + encrypt" = sensitivity labels (Purview). RLS=row visibility / access control=item access.
Watch the mix-ups: (1) RLS (row visibility) vs item-level access (can open). (2) Even Viewers need RLS separately (viewing ≠ all rows). (3) Static vs dynamic RLS (USERNAME()). (4) Sensitivity labels (classify/encrypt) vs RLS (row filter) differ in purpose. (5) Without Build permission, a model cannot be reused.
5.2.4Section summary
- Workspace roles = Admin>Member>Contributor>Viewer; model reuse needs Build permission
- RLS = roles + DAX filter to limit rows; dynamic RLS uses USERNAME()
- Sensitivity labels (Purview) = classify + encrypt; different purpose from RLS
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want salespeople to see only their region’s rows, not other regions. Best feature?
Q2. You want to switch visible rows automatically based on the signed-in user. Best approach?
Q3. You want to classify a report as "Confidential" and apply encryption/export protection. Best feature?
Q4. You want other authors to build new reports on a published semantic model. Which permission to grant?
Q5. Which workspace role can create/edit content but cannot manage access?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.