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 semantic-model security.
- Choose by what must be hidden: rows = RLS, column values = CLS, object existence = OLS, lakehouse files/paths = OneLake security.
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. The exam tests whether you match the security feature to the exact thing being protected.
This is one of the most heavily tested ideas in the Maintain domain. The wrong answers usually swap two of these, so be precise.
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 | User sees the table but only their permitted rows (e.g., their region) |
| CLS (column-level security) | Access to specific column values | Semantic model column permissions | Query against the column is denied; the field returns no data for that user |
| OLS (object-level security) | The existence of a table or column | Semantic model object permissions | Object is hidden from metadata — the user cannot see it exists at all |
| OneLake file security | Physical files/folders/paths in a lakehouse | OneLake data access / security roles | Restricted paths are not readable, regardless of semantic-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 does not appear in field lists).
- An engineer must be blocked from a raw
/Files/hr/folder in the lakehouse → OneLake file/folder security.
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. If a user has lakehouse access, they could read the raw Delta files directly and bypass model-level rules. OneLake file/folder security closes that gap by restricting the physical paths. For true defense in depth, sensitive lakehouse data needs both model-level security and OneLake path security.
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?