What you will be able to do
- Explain how workspace object ACLs are assigned to creators and admins and inherited through folders
- Choose the lowest compute, job, pipeline, dashboard and file permission level that fits a persona
- Recognise where workspace ACLs stop and Unity Catalog privileges take over
1.How workspace object ACLs work
Unity Catalog privileges control data. Notebooks, files, folders, compute, jobs, pipelines, dashboards and alerts are *workspace objects*, and they are controlled by a separate mechanism: access control lists on each object, with named permission levels such as CAN VIEW, CAN RUN, CAN EDIT and CAN MANAGE.
Two defaults affect least privilege. Workspace admins have CAN MANAGE on every object in their workspace. Users automatically get CAN MANAGE on anything they create. Applying least privilege in the workspace mostly means deciding what *other* people get on those objects.
Folders are where you scale workspace ACLs. Objects in a folder inherit all of the folder's permission settings, so CAN RUN on a folder gives CAN RUN on the alerts inside it. Grouping objects by audience and granting on the folder is the workspace version of granting on a schema. The same caution applies: anything later placed in the folder inherits the same access.
A grant on a single object reveals very little. The user can see the parent folder's *name*, but cannot view or open any other object in it without their own permission. Databricks has also announced a change for an upcoming release: members will inherit workspace object permissions from every account group they belong to, even groups not assigned to the workspace. Databricks provides an Orphaned permissions analysis notebook for reviewing existing grants before that change.
Checkpoint 1 of 5· Check yourself
You want a reporting team to run, but not edit, the 15 alerts in one workspace folder, and any alerts added to that folder later. What is the least-effort, least-privilege approach?
Objects inherit their folder's permission settings, so one CAN RUN grant on the folder covers current and future alerts without giving edit rights.
“Objects in a folder inherit all permissions settings of that folder.”Source: docs.databricks.com
Sources1
2.Compute permissions and the driver-log exposure
Compute has three levels above no permissions. Each level includes the abilities of the one below it.
| Ability | CAN ATTACH TO | CAN RESTART | CAN MANAGE |
|---|---|---|---|
| Attach notebook, view Spark UI and metrics | Yes | Yes | Yes |
| Start, restart and terminate compute | No | Yes | Yes |
| View driver logs (default) | No | No | Yes |
| Edit, resize, attach libraries, modify permissions | No | No | Yes |
Driver logs are the sensitive part. Secrets are not redacted from the Spark driver's stdout and stderr on classic compute. For that reason, on dedicated or standard access mode, driver logs are visible only to CAN MANAGE holders by default. Setting spark.databricks.acl.needAdminPermissionToViewLogs to false opens them to CAN ATTACH TO and CAN RESTART. It is a per-compute Spark property, so ephemeral runs submitted via jobs/runs/submit must set it in new_cluster.spark_conf.
Legacy No isolation shared compute reverses the default. Users with CAN ATTACH TO, CAN RESTART or CAN MANAGE can read driver logs, and CAN ATTACH TO holders can see service account keys in the log4j file. There, you set the property to true to restrict logs to CAN MANAGE.
spark.databricks.acl.needAdminPermissionToViewLogs falseCheckpoint 2 of 5· Check yourself
An on-call engineer must be able to restart a shared cluster when it hangs, but must not change its configuration or libraries. Which permission fits least privilege?
CAN RESTART adds start, restart and terminate on top of CAN ATTACH TO. Editing, resizing and attaching libraries remain CAN MANAGE only.
“Secrets are not redacted from the classic compute resource's Spark driver's stdout and stderr streams.”Source: docs.databricks.com
Sources1
3.Jobs and pipelines: separating run from change
For production jobs, the key decision is who may *run* the code and who may *change* it. Each job permission includes everything below it in the list:
| Permission | Grant |
|---|---|
| IS OWNER | The identity used for Run as by default |
| CAN MANAGE | Can edit the job definition, including configuration, tasks, and permissions |
| CAN MANAGE RUN | Can trigger and cancel job runs |
| CAN VIEW | Can view job run results, including details, history, and status |
Databricks' guidance follows least privilege directly: give monitors CAN VIEW, give operators who trigger, stop or restart runs CAN MANAGE RUN, and keep CAN MANAGE and IS OWNER for people trusted to modify production code. The creator is IS OWNER by default. A job has exactly one owner, and that owner cannot be a group. A job started with Run Now runs with the permissions of the Run as identity (the owner by default), not those of the person who clicked. Granting CAN MANAGE RUN does not give the operator the job's data access.
Pipelines use a similar ladder.
| Ability | CAN VIEW | CAN RUN | CAN MANAGE / IS OWNER |
|---|---|---|---|
| View pipeline details, Spark UI and driver logs | Yes | Yes | Yes |
| Start and stop a pipeline update | No | Yes | Yes |
| Edit settings, delete, modify permissions | No | No | Yes |
Checkpoint 3 of 5· Match them up
Match each job persona to the least-privilege permission
Tap a term, then the definition that fits it.
Viewing results, triggering runs and editing the definition are separate, increasing levels. Each persona gets the lowest level that covers their task.
“Users that trigger, stop, or restart job runs need the Can Manage Run permission.”Source: docs.databricks.com
Checkpoint 4 of 5· Exam question
A metastore admin runs `GRANT ALL PRIVILEGES ON SCHEMA finance.reports TO data_engineers;` to simplify onboarding a team. Which privilege is NOT included in this grant, and must be granted separately if the team needs it?
Correct answer: A — `MANAGE`, which controls the ability to change permissions, transfer ownership, or delete the schema, and is intentionally excluded from `ALL PRIVILEGES` grants.
- A. `ALL PRIVILEGES` grants every applicable privilege on the schema except a small set of administrative privileges, and `MANAGE` (along with `READ METADATA`, `EXTERNAL USE SCHEMA`, and `EXTERNAL USE LOCATION`) is deliberately excluded so that broad data grants do not automatically hand out administrative control.
- B. `SELECT` is a standard data-access privilege and is included when `ALL PRIVILEGES` is granted on a schema, so it does not need to be granted separately.
- C. `CREATE TABLE` is included when `ALL PRIVILEGES` is granted on a schema, since it is one of the ordinary creation privileges the grant is meant to bundle together.
- D. `USE SCHEMA` is included when `ALL PRIVILEGES` is granted, since usage on the schema itself is one of the baseline privileges the bundled grant covers.
Sources2
4.Dashboards, files, and where workspace ACLs end
The other workspace objects follow the same pattern. On files, CAN VIEW lets a user read and comment, CAN RUN adds attaching and running interactively, CAN EDIT adds editing, and only CAN MANAGE can modify permissions. On dashboards, editing needs CAN EDIT or above, while deleting and changing permissions need CAN MANAGE. On alerts, CAN RUN covers viewing, triggering and subscribing, and editing or deleting needs CAN MANAGE. In the UI the view-only level is called CAN VIEW. The Permissions API calls the same level CAN READ.
No. A workspace ACL governs the object (the notebook) only. Any operation that touches Unity Catalog still needs Unity Catalog privileges on the data object, so the query fails without SELECT and the usage privileges.
These are two separate layers, and least privilege has to hold in both. Workspace ACLs decide who can use a notebook, cluster or job. Unity Catalog privileges decide which data that work can reach. Databricks describes several complementary data-side models, which their own lessons cover. For workspaces specifically, *workspace bindings* restrict which workspaces can reach a catalog, external location or storage credential. Even a principal with grants then cannot use that object from a workspace it is not bound to.
| Mechanism | Applies to | Use case |
|---|---|---|
| Workspace object ACLs | Notebooks, folders, compute, jobs, pipelines, dashboards | Who can use or change a workspace object |
| Privileges | Catalogs, schemas, tables | Baseline access and delegation |
| Workspace bindings | Catalogs, external locations, storage credentials | Restricting access to objects from specific workspaces |
Checkpoint 5 of 5· Check yourself
A catalog contains regulated data that must never be queried from the sandbox workspace, even by users who hold SELECT on it. Which control addresses this?
Workspace bindings limit where a catalog can be accessed, independently of who holds privileges on it.
“Workspace-level restrictions control where users can access data, by limiting objects to specific workspaces.”Source: docs.databricks.com
Sources1
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.On dedicated or standard compute, any user with CAN ATTACH TO can read the Spark driver logs.Why is that wrong?
By default only CAN MANAGE holders can view driver logs on job and all-purpose compute in those access modes. This changes only if needAdminPermissionToViewLogs is set to false.
2.When someone clicks Run Now, the job runs with that person's own permissions.Why is that wrong?
Run Now uses the Run as identity, which is the owner by default, not the identity of the user who triggered it.
3.You can make a group the IS OWNER of a production job so that ownership is shared.Why is that wrong?
A job has exactly one owner, and a group cannot be assigned IS OWNER.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“In Databricks, you can use access control lists (ACLs) to configure permission to access workspace level objects.”
↩︎ How workspace object ACLs work“Users automatically have the CAN MANAGE permission for objects that they create.”
↩︎ How workspace object ACLs work“they can view the parent folder's name, even if they do not have permissions on the parent folder.”
↩︎ How workspace object ACLs work“users with CAN ATTACH TO permissions can view the service account keys in the log4j file.”
↩︎ Compute permissions and the driver-log exposure“The workspace UI refers to view-only access as CAN VIEW, while the Permissions API uses CAN READ to represent the same level of access.”
↩︎ Dashboards, files, and where workspace ACLs end“When performing operations that interact with Unity Catalog you need to have permissions on the Unity Catalog object”
↩︎ Dashboards, files, and where workspace ACLs end“Spark driver logs are viewable only by users with CAN MANAGE permission on job compute and all-purpose compute”
↩︎ Exam trap 1“Objects in a folder inherit all permissions settings of that folder.”
↩︎ Checkpoint“Secrets are not redacted from the classic compute resource's Spark driver's stdout and stderr streams.”
↩︎ Checkpoint - 2.https://docs.databricks.com/aws/en/jobs/privilegesOfficial docs
“Only grant Can Manage or Is Owner privileges to users trusted to modify production code.”
↩︎ Jobs and pipelines: separating run from change“Jobs triggered through Run Now assume the permissions of the Run as user”
↩︎ Exam trap 2“A group cannot be assigned the IS OWNER permission as an owner.”
↩︎ Exam trap 3“Users that trigger, stop, or restart job runs need the Can Manage Run permission.”
↩︎ Checkpoint
Also cited
“Workspace-level restrictions control where users can access data, by limiting objects to specific workspaces.”
↩︎ Checkpoint