The DP-750 exam certifies your ability to integrate, model, secure, and optimize data engineering workloads on Azure Databricks, with skills measured as of March 11, 2026 across four domains: environment setup, Unity Catalog security and governance, data preparation, and pipeline deployment and maintenance. It expects working fluency in SQL and Python, Git-based software development lifecycle practices, and familiarity with Microsoft Entra, Azure Data Factory, and Azure Monitor as the surrounding Azure ecosystem. Unity Catalog is the connective tissue across nearly every domain - the same governed catalog, schema, and table objects you create in setup get secured with grants and row and column controls, ingested into, transformed, and finally monitored for drift and performance, so a candidate who treats Unity Catalog as one continuous data model rather than four separate exam topics recognizes scenario questions faster. Expect scenario driven questions on choosing the right compute type, ingestion tool, table format, or troubleshooting approach for a stated constraint, not simple recall of feature names.
What This Cheat Sheet Covers
This topic spans 23 focused tables and 240 indexed concepts, 226 flashcards, 7 practice tests with 305 questions. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Selecting and Configuring Compute in a WorkspaceTable 2: Unity Catalog Structure: Naming, Catalogs, Schemas & VolumesTable 3: Unity Catalog Data Objects: Tables, Views, Foreign Catalogs & GenieTable 4: Securing Unity Catalog Objects: Grants, Row/Column Access & AuthenticationTable 5: Governing Data Discovery: Definitions, ABAC, Row Filters & Column MasksTable 6: Governing Data Lifecycle: Retention, Lineage, Audit Logging & Delta SharingTable 7: Data Ingestion Planning: Source Configuration, Tool & Loading Method SelectionTable 8: Data Modeling Decisions: Table Format, Partitioning, SCD Type & GranularityTable 9: Table Clustering Strategy: Liquid Clustering, Z-Ordering & Deletion VectorsTable 10: Ingesting Data with Lakeflow Connect and NotebooksTable 11: SQL and Declarative Data Ingestion: CTAS, COPY INTO, CDC & Auto LoaderTable 12: Streaming Ingestion: Spark Structured Streaming and Azure Event HubsTable 13: Data Profiling and Cleansing: Statistics, Data Types & Null HandlingTable 14: Data Transformation and Loading: Joins, Reshaping, Merge & AppendTable 15: Data Quality Constraints: Validation, Type Checks & Schema EnforcementTable 16: Designing Data Pipelines: Order of Operations, Task Logic & Error HandlingTable 17: Implementing Lakeflow Jobs: Setup, Triggers, Scheduling & AlertsTable 18: Git Version Control and SDLC Testing PracticesTable 19: Databricks Asset Bundles: Configuration and DeploymentTable 20: Cluster Cost Monitoring and Azure Monitor ObservabilityTable 21: Troubleshooting Lakeflow Jobs and Spark Job FailuresTable 22: Diagnosing Spark Performance: Caching, Skew, Spilling & ShuffleTable 23: Delta Table Optimization: OPTIMIZE and VACUUM
Quick IndexSubscribe to unlock
A jump-to index of every table row in this cheat sheet.
Mind MapSubscribe to unlock
An interactive map of every table and concept in this topic.
Table 1: Selecting and Configuring Compute in a Workspace
Azure Databricks environment setup, compute task: choose the right compute type for a workload, tune its performance and feature settings, install libraries on it, and control who can use it. Getting this right is the biggest lever on both DBU cost and workload reliability in a workspace.
| Concept | Example | Description | |
|---|---|---|---|
job_clusters: new_cluster per taskshared cluster: starts at first task, ends after last task | • An ephemeral cluster created just for a job run and torn down afterward; costs significantly less per DBU than leaving an all-purpose cluster running for the same non-interactive workload. • A cluster shared across tasks starts when the first task needing it begins and terminates only after the last one finishes • Not to be confused with all-purpose compute, which Databricks does not recommend for production job runs | ||
Compute > Create compute > All-purposestays up for interactive notebook work until idle timeout or manual stop | • A persistent classic cluster meant for interactive development and ad hoc notebook work, configured through the same simple-form UI as job compute. • Databricks does not recommend running production job tasks on all-purpose compute, since job compute is cheaper for that use • Best suited to exploration, debugging, and collaborative analysis rather than scheduled pipelines | ||
No node type, no cluster size, no runtime version to pickworkspace just needs Unity Catalog + a supported region | • A fully managed, on-demand compute layer for notebooks, jobs, and Lakeflow pipelines with no infrastructure to size or tune. • Serverless jobs still have real limits: continuous Structured Streaming scheduling only works with bounded triggers like Trigger.AvailableNow, not fixed time-interval triggers • Serverless SQL warehouses and serverless pipelines are configured separately from serverless compute for notebooks and jobs | ||
Serverless: Photon + Predictive I/O + Intelligent Workload ManagementPro: Photon + Predictive I/O, no IWM • Classic: Photon only | • SQL warehouses come in three types with a strict feature ladder: serverless has the most capability, pro drops Intelligent Workload Management, classic drops Predictive I/O too. • Pro and classic run compute in your own Azure subscription and take around four minutes to start • Choose pro over serverless mainly when you need custom network peering to on-prem systems, or serverless isn't available in your region | ||
Standard: multi-user, Python/SQL/Scala, data isolated per userDedicated: one user or group, adds R, RDD APIs, GPU | • Access mode controls who can attach to a classic compute resource and what languages it supports; Standard (formerly Shared) is Databricks' default recommendation for most workloads. • Dedicated (formerly Single User) is reserved for workloads Standard cannot run: RDD APIs, GPU instances, R, or privileged system access • Leaving access mode on Auto still resolves to Dedicated whenever you pick an ML runtime, a GPU instance type, or a Databricks Runtime below 14.3 | ||
Min 2, Max 8 workers, optimized autoscalingscale-down check: job compute 40s idle, all-purpose 150s idle | • Lets Databricks add and remove worker nodes automatically between a min and max you set, reaching the max in at most two scaling events under optimized autoscaling. • Autoscaling can make a job run faster, cut cost, or both, but Databricks frames the two benefits as conditional on your workload, not a guarantee every time • Not the same setting as instance pooling, which pre-warms idle instances rather than resizing a running cluster | ||
Terminate after 30 minutes of inactivitya finished Job compute cannot restart; a terminated All-Purpose compute auto-starts on the next job | • Shuts a compute resource down after a set number of idle minutes with no commands, Spark jobs, or JDBC activity. • DBU and cloud instance charges keep accruing for the whole inactivity window, right up until the termination actually fires • A terminated, unpinned compute resource is permanently deleted after 30 days | ||
2 workers x 16 cores/128 GB = 8 workers x 4 cores/32 GBsame total cores and memory, different shuffle cost | • Sizing is a tradeoff between total executor cores (parallelism), total executor memory (how much fits before spilling to disk), and local storage, not just the raw worker count. • Complex, shuffle-heavy ETL with unions and joins across many tables usually runs better on fewer, larger workers, since that cuts the data moved between nodes • Simple batch ETL with no wide transformations is the case for the opposite choice, smaller and cheaper instances | ||
Minimum Idle Instances: 2, Maximum Capacity: 20Databricks does not charge DBUs for instances sitting idle in the pool | • A pool of pre-warmed, ready instances that a new compute resource can claim instead of waiting on the cloud provider, cutting cluster launch time. • Only cloud instance provider billing applies to idle pooled instances, no DBU charge, until a cluster actually attaches and starts running • A separate mechanism from autoscaling: a pool does not change how many nodes an already-running cluster uses, autoscaling does | ||
UI: Use Photon Acceleration checkbox, on by defaultClusters/Jobs API: must set runtime_engine: "PHOTON" explicitly | • A vectorized, native query engine that speeds up SQL, DataFrame, ETL, and stateless streaming workloads by processing data in columnar batches. • It's on by default for compute created in the UI on Databricks Runtime 9.1 LTS and later, but a compute resource created through the Clusters or Jobs API needs runtime_engine explicitly set to PHOTON • Simple batch ETL with short, sub-two-second queries typically sees little benefit even with Photon enabled | ||
Job compute running production ETL: latest LTS releaseAll-purpose interactive compute: most current non-LTS release | • Databricks Runtime bundles Apache Spark plus the platform's core components, and the right version depends on the workload, not a single blanket choice. • Job compute running operational workloads should use a Long Term Support (LTS) release for stability and extended security patches • All-purpose compute benefits more from the most current release, for the latest optimizations and package compatibility | ||
Machine learning checkbox at compute creationauto-sets access mode to Dedicated for Unity Catalog access | • A specialized runtime that pre-installs a large set of ML and deep learning libraries so you don't assemble an environment by hand. • To read Unity Catalog data from a compute resource running Databricks Runtime ML, access mode must be Dedicated, Standard access mode is not sufficient here • Photon on this runtime speeds up Spark SQL and DataFrame code, but not Spark RDDs, Pandas UDFs, or Python ML packages like XGBoost or PyTorch | ||
%pip install pandas==2.2.0scoped to this notebook's session only, not the whole compute | • Compute-scoped libraries install once and become available to every notebook and job attached to that resource; notebook-scoped libraries (%pip in Python or R) apply only to the notebook session that ran the install. • A %pip install in one notebook never affects another notebook sharing the same compute, and it does not persist once the session ends • Best practice favors notebook-scoped installs and environment specs over compute-scoped libraries, since compute-scoped installs cause environment drift across jobs sharing that resource | ||
CAN ATTACH TO: attach notebook, view Spark UICAN RESTART: adds terminate/start • CAN MANAGE: adds edit, resize, permissions | • Four permission levels gate what a user can do on a compute resource: NO PERMISSIONS, CAN ATTACH TO, CAN RESTART, and CAN MANAGE, each level adding on to the one before it. • Only CAN MANAGE can edit the compute's configuration, attach a library, resize it, or change who else has access • On the legacy No Isolation Shared access mode, CAN ATTACH TO users can read service account keys from the log4j file, a real reason to avoid granting that mode broadly |