2.2 Row/Column/Object/File-Level Security
Key Takeaways
- RLS (row-level security) filters which rows a user sees by defining roles with DAX filter expressions on a semantic model.
- CLS (column-level security) blocks access to specific columns so sensitive fields like salary or SSN are not returned at all.
- OLS (object-level security) hides entire tables or columns from the model metadata so restricted users do not even know the object exists.
- OneLake file/folder security controls access to physical lakehouse files and paths, independent of any semantic-model security.
- Dynamic RLS uses USERPRINCIPALNAME() against a mapping table so one role serves many users instead of one static role per group.
Pick the Layer by What Must Be Hidden
Quick Answer: RLS filters rows. CLS blocks specific column values. OLS hides the existence of a table or column from the model. OneLake file security restricts physical lakehouse files and folders. DP-600 distractor answers nearly always swap two of these, so be precise about whether the requirement protects rows, values, object existence, or raw files.
This is one of the most heavily tested ideas in the Maintain domain. Read the requirement and translate it into one of those four words before you look at the options.
RLS vs CLS vs OLS vs OneLake File Security
| Feature | What It Restricts | Where Configured | User Experience |
|---|---|---|---|
| RLS (row-level security) | Which rows are returned | Semantic model roles with DAX filter expressions | Sees the table but only permitted rows (e.g., their region) |
| CLS (column-level security) | Access to specific column values | Semantic model column permissions (Tabular Editor / metadata) | Query against the column is denied; visuals using it error out |
| OLS (object-level security) | The existence of a table or column | Semantic model object permissions | Object is hidden from metadata — user cannot see it exists |
| OneLake file security | Physical files/folders/paths in a lakehouse | OneLake data access / security roles | Restricted paths are not readable, regardless of model rules |
How to Decide
- A salesperson should see only their own region's rows → RLS (filter rows by a DAX expression keyed to the user).
- Most users may see the Employees table but must not see the Salary column's values → CLS.
- A restricted group must not even know a Compensation table exists → OLS (hide the object so it never appears in field lists).
- An engineer must be blocked from a raw
/Files/hr/folder in the lakehouse → OneLake file/folder security.
Static vs Dynamic RLS
RLS is implemented as named roles on the semantic model, each carrying a DAX filter. There are two patterns:
- Static RLS — the filter is a fixed value, e.g.
[Region] = "West". You create one role per group and assign members. Simple, but it does not scale to hundreds of regions. - Dynamic RLS — the filter compares a security table to the signed-in user, e.g.
[Email] = USERPRINCIPALNAME(). One role then tailors itself to every user via a mapping table. This is the preferred answer when the scenario says "each manager sees only their own team" or "thousands of users."
A classic worked example: a UserRegion table maps emails to regions. The role filter on Sales[Region] is Sales[Region] IN CALCULATETABLE(VALUES(UserRegion[Region]), UserRegion[Email] = USERPRINCIPALNAME()). Always validate with Test as role / View as before publishing.
Why OneLake File Security Is Separate
RLS, CLS, and OLS are semantic-model features — they protect data as consumed through the model. They do not protect the underlying lakehouse files. A user with lakehouse access could read the raw Delta files directly through the SQL analytics endpoint or a notebook and bypass model-level rules entirely. OneLake file/folder security closes that gap by restricting the physical paths. For genuine defense in depth, sensitive lakehouse data needs both model-level security and OneLake path security — a Confidential model with RLS is not protected if its source files are world-readable in OneLake.
Where RLS and Storage Mode Interact
RLS behavior depends on storage mode. In Import mode, the DAX filter is applied entirely inside the in-memory model, so RLS works without touching the source. In DirectQuery mode, the filter is folded into the query sent to the source, so the filter must be expressible there and performance depends on source indexing. In Direct Lake mode — the native Fabric mode that reads Delta tables directly from OneLake — RLS is still defined as model roles, but a query that cannot be satisfied in Direct Lake may fall back to DirectQuery against the SQL endpoint, where the same role filter is applied.
The takeaway for the exam: RLS roles are defined the same way regardless of mode, but you must ensure the security mapping table is available in whatever mode the model uses.
Practical Configuration Steps
| Task | Tool / Location | Note |
|---|---|---|
| Create an RLS role + DAX filter | Power BI Desktop Manage roles, or web modeling | Test with View as role |
| Configure CLS | Tabular Editor (metadata-level column permission) | Not exposed in Desktop's basic UI |
| Configure OLS | Tabular Editor object permissions | Hides table/column from metadata |
| Assign RLS members | Service > semantic model > Security | Map Entra groups to roles |
| OneLake file security | Lakehouse > Manage OneLake data access | Path-scoped read roles |
Worked Scenario
A retail analytics model must satisfy three rules at once: regional managers see only their region (rows), HR analysts must not see the Salary values (column values), and a contractor group must not even know a MergerPlans table exists (object existence). The correct stack is dynamic RLS for regions, CLS on Salary, and OLS on MergerPlans — three different features for three different protections, all on the same semantic model.
If the contractor also has notebook access to the lakehouse, add a OneLake file security role to block the raw merger files, because the OLS metadata hiding does not protect the physical Delta files underneath.
A semantic model contains an Employees table. Auditors may view all employee rows and the model structure, but a restricted analyst group must not be able to see that a 'Compensation' table even exists in the model. Which security feature meets the requirement for that group?
A company has 400 regional managers and wants each to see only their own region's sales rows in a single shared report, without creating 400 separate security roles. Which approach is correct?