What standard (formerly shared) and dedicated (formerly single user) access modes allow, and when each is required.
From Ultra Transcenders DP-750 by Tony Rough (coming November 2026)
The access mode of a classic compute resource decides who can use it and what data they can reach; only standard and dedicated access modes can access Unity Catalog data. Access mode is set under Advanced in the compute UI and as data_security_mode in the API.
| Access mode | Former name | Who can use it | Languages | Choose it for |
|---|---|---|---|---|
| Standard | Shared access mode | Multiple users, isolated from each other by Lakeguard | Python, SQL, Scala (Scala needs Databricks Runtime 13.3 LTS and above) | Most workloads: general data engineering, ETL, collaborative and interactive work, cost sharing |
| Dedicated | Single user (assigned) access mode | One user, or one group (group access is in Public Preview) | Python, SQL, Scala, R | RDD APIs, GPUs, R, Databricks Runtime for Machine Learning, privileged machine access |
The default access mode in the UI is Auto: it selects Standard unless you pick a machine learning runtime, a GPU instance type or a Databricks Runtime below 14.3, in which case it selects Dedicated. Databricks recommends standard access mode unless required functionality isn’t supported. No isolation shared is a legacy mode that isn’t recommended.
Standard compute’s current limitations include no Databricks Runtime for ML, no GPU-enabled compute, no R, no RDD APIs, no Spark-submit tasks (use a JAR task) and no Hive UDFs (use Unity Catalog UDFs). In Databricks Runtime 19 and above, certain Spark configuration properties (JVM options, spark.jars, environment variable injection and others) are restricted in standard access mode and setting them makes cluster creation fail.
When dedicated compute is assigned to a group, a user’s permissions are down-scoped to the group’s permissions. Fine-grained access control on dedicated compute (querying views over tables the user can’t read directly, or tables created by Lakeflow pipelines) needs Databricks Runtime 15.4 LTS or above and a workspace enabled for serverless compute, which does the filtering.
Common trap: Expecting a cluster created with the machine learning runtime to be shareable by the whole team - selecting Machine learning sets dedicated access mode for one user (or one group), because standard access mode doesn’t support Databricks Runtime for ML.
This note is one section of Ultra Transcenders DP-750: Implementing Data Engineering Solutions Using Azure Databricks, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Due on Amazon in November 2026, in Kindle and paperback editions.
About the book · DP-750 terms in the glossary · All DP-750 study notes
Who manages the files, what DROP TABLE does to each, and why Databricks recommends managed tables.
How SQL UDF row filters and column masks restrict data per user, and how they differ from dynamic views.
How the two retention properties and VACUUM decide which table versions you can still query or restore.
SCD types 0, 1, 2 and others compared, and when to keep history in a dimension table.
The table-size thresholds for partitioning, partition sizing, and why liquid clustering is usually the better choice.
How expectations validate records in Lakeflow Spark Declarative Pipelines and what each violation action does.
Job and task notifications, system destinations, duration warnings and how retries affect which alerts are sent.