What you will be able to do
- Choose between performance-optimized and standard serverless performance modes
- Decide when high-memory serverless is the right fix, and where it can be used
- Turn off serverless auto-optimization for non-idempotent tasks
- Match each Lakeflow Jobs task type to its recommended compute
1.Performance mode: startup speed versus cost
Serverless has two performance modes. Performance-optimized is the default. Databricks keeps a pool of warm compute ready so interactive work starts quickly. Standard mode uses less compute and suits automated batch jobs and pipelines that can accept a 4–6 minute startup. It can cost up to 70% less than performance-optimized mode. Both modes use the same SKU. Standard mode just consumes fewer DBUs. For scheduled jobs where startup latency doesn't matter, Standard mode is usually the better value.
For a job, you set this with the Performance optimized toggle on the job details page. Turning it off switches the job to standard mode. The toggle appears only when the job has at least one serverless task, and it affects only the serverless tasks in that job.
| Aspect | Performance optimized | Standard |
|---|---|---|
| Default? | Yes | No; turn off Performance optimized |
| Startup | Fast; warm compute pool | 4 to 6 minutes |
| Cost | Baseline | Up to 70% lower; same SKU, fewer DBUs |
| Available for | Notebooks, jobs, pipelines | Lakeflow Jobs and Lakeflow pipelines only |
| Best for | Interactive and time-sensitive workloads | Scheduled batch jobs and pipelines |
Checkpoint 1 of 6· Exam question
An analyst opens an interactive serverless notebook to explore a sales dataset and needs the compute to start within seconds so they aren't kept waiting between commands. A teammate suggests switching the notebook's compute to Standard performance mode to cut cost. Which statement correctly evaluates that suggestion?
Correct answer: B — The suggestion cannot be applied, because serverless notebooks only support Performance Optimized mode, built for low-latency, always-warm interactive sessions.
- A. Standard performance mode exists for Lakeflow Jobs and Lakeflow Spark Declarative Pipelines, but it is not offered as a selectable option for serverless notebooks, so this evaluation misstates what's configurable.
- B. Serverless notebooks are restricted to Performance Optimized mode precisely because interactive sessions need warm, low-latency compute, which correctly explains why the teammate's suggestion isn't something the analyst can turn on.
- C. Serverless compute does support notebooks as one of its core workload types, so claiming notebooks require classic compute misrepresents the platform's current capabilities.
- D. The memory tier and the performance mode are independent settings in the notebook's Environment panel, so enabling High memory has no bearing on which performance mode is selectable.
2.High-memory notebooks and notebook tasks
If a serverless notebook runs out of memory, you can switch it from Standard memory (16 GB total) to High memory (32 GB total). This feature is in Public Preview. Be clear about what it increases: the REPL memory that runs your notebook code, such as a large pandas object on the driver. It doesn't change the Spark session's memory. High memory also has a higher DBU emission rate, so turn it on only for workloads that need it.
Checkpoint 2 of 6· Put it in order
Put the steps for enabling high memory on a serverless notebook in order
- 1.Under Memory, select High memory
- 2.Click Apply
- 3.In the notebook UI, click the Environment side pane
You configure memory in the same Environment side pane as the base environment and dependencies, and the change takes effect when you click Apply.
“Under Memory, select High memory.”Source: docs.databricks.com
Jobs pick up this setting from the notebook. A notebook task uses its notebook's memory preference, and a change made in the notebook applies from the next job run. High memory is available only for notebook tasks. Python script, wheel and other task types can't use it. Also note that serverless provisions enough resources for the job, so jobs that need a lot of memory or contain many tasks may take longer to start. In practice, reach for High memory only after you have confirmed that the failure is an out-of-memory error in the notebook's own Python process, because the setting does nothing for Spark-side memory pressure and it raises the DBU rate for every run.
Checkpoint 3 of 6· Check yourself
A serverless notebook task fails with out-of-memory errors while collecting a large result into pandas. Which change targets the problem?
High memory increases REPL memory, which is where driver-side Python objects live. Most Spark configurations can't be set on serverless, performance mode has nothing to do with memory, and high memory is available only for notebook tasks.
“This memory size setting increases the size of the REPL memory used when running code in the notebook.”Source: docs.databricks.com
3.Auto-optimization and disallowing retries
Serverless compute for jobs includes auto-optimization. It tunes the compute that runs your job and automatically retries failed tasks. It's on by default, and Databricks recommends keeping it on so that critical workloads complete at least once. Those automatic retries are a problem for a task that must run at most once, such as a non-idempotent job that appends records or calls an external system. Running it twice would produce duplicates. Auto-optimization is a per-task setting, and you turn it off in the task's retry policy.
Checkpoint 4 of 6· Put it in order
Put the steps for disabling serverless auto-optimization on a task in order
- 1.In the Retry Policy dialog, uncheck Enable serverless auto-optimization (may include additional retries)
- 2.Next to Retries, click Add
- 3.Click Confirm
- 4.Click Save task
The setting is in the task's Retry Policy dialog. You must confirm the dialog and then save the task.
“In the Retry Policy dialog, uncheck Enable serverless auto-optimization (may include additional retries).”Source: docs.databricks.com
Checkpoint 5 of 6· Exam question
A scheduled notebook task running on serverless compute repeatedly fails with out-of-memory errors while building a large in-memory pandas DataFrame partway through the run. The transformation logic is correct and the team does not want to rewrite it as a distributed Spark job. Which configuration change is most likely to resolve the failure?
Correct answer: A — Open the notebook's Environment side panel and change the Memory setting from Standard to High, which raises the task's total memory from 16 GB to 32 GB.
- A. The Memory setting in the Environment panel is exactly the control for this problem: switching from Standard to High doubles the total memory available to a notebook or notebook job task from 16 GB to 32 GB, giving the pandas workload more headroom.
- B. Performance mode governs startup latency and DBU cost, not the amount of memory allocated to a task, so changing it would not give the pandas transformation any additional headroom.
- C. Auto-optimization controls whether serverless compute can add extra retry attempts for failed tasks; disabling it changes retry behavior but does not reserve or free any memory for the running task.
- D. Pandas version changes do not materially alter the memory ceiling imposed by the notebook's compute tier, so downgrading the library would not address a task that is exceeding its allotted memory.
Sources2
4.Choosing compute per task type
Databricks recommends serverless for all job tasks. Compute is set per task, though, so a single job can mix compute types when a task type isn't supported on serverless. Notebook, Python script, Python wheel and dbt CLI tasks should use serverless jobs compute. SQL and dbt tasks should use a serverless SQL warehouse. Pipeline tasks should use a serverless pipeline. JAR and Spark Submit tasks should use classic jobs compute. Serverless also restricts tuning: you can set only a supported subset of Spark configurations, and only at session level. A job run fails if it sets an unsupported Spark configuration.
| Task | Recommended compute | Supported compute |
|---|---|---|
| Notebooks | Serverless jobs | Serverless jobs, classic jobs, classic all-purpose |
| Python wheel | Serverless jobs | Serverless jobs, classic jobs, classic all-purpose |
| SQL | Serverless SQL warehouse | Serverless SQL warehouse, pro SQL warehouse |
| Lakeflow pipelines | Serverless pipeline | Serverless pipeline, classic pipeline |
| JAR | Classic jobs | Classic jobs, classic all-purpose |
| Spark Submit | Classic jobs | Classic jobs |
Checkpoint 6 of 6· Match them up
Match each requirement to the setting that meets it
Tap a term, then the definition that fits it.
Each requirement corresponds to one setting: performance mode controls startup cost, high memory controls REPL memory, the auto-optimization checkbox controls automatic retries, and Spark Submit tasks run only on classic jobs compute.
“Databricks recommends using serverless compute for all job tasks.”Source: docs.databricks.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Selecting High memory gives the Spark session more memory for large shuffles and joins.Why is that wrong?
High memory increases only the notebook's REPL memory, from 16 GB to 32 GB total. It doesn't change Spark session memory, and it costs more DBUs.
Covered in High-memory notebooks and notebook tasks
2.Standard performance mode can reduce the cost of interactive serverless notebooks.Why is that wrong?
Standard mode is available for Lakeflow Jobs and Lakeflow pipelines only. Notebooks run in performance-optimized mode.
Covered in Performance mode: startup speed versus cost
3.Turning off auto-optimization is best practice for critical production jobs because it makes their behavior predictable.Why is that wrong?
Keep auto-optimization on so critical workloads complete at least once. Turn it off only for workloads that must run at most once, such as non-idempotent jobs.
Covered in Auto-optimization and disallowing retries
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Standard mode can reduce costs by up to 70% compared to performance-optimized mode.”
↩︎ Performance mode: startup speed versus cost“Job runs on serverless compute will fail if you set an unsupported Spark configuration.”
↩︎ Choosing compute per task type“Standard mode is available for Lakeflow Jobs and Lakeflow pipelines, but not for notebooks.”
↩︎ Exam trap 2“Standard mode is available for Lakeflow Jobs and Lakeflow pipelines, but not for notebooks.”
↩︎ Prediction - 2.
“Both modes use the same SKU, but standard performance mode consumes fewer DBUs, reflecting lower compute usage.”
↩︎ Performance mode: startup speed versus cost“This setting only affects the serverless tasks within the job.”
↩︎ Performance mode: startup speed versus cost“High memory is only available for notebook task types.”
↩︎ High-memory notebooks and notebook tasks“Auto-optimization is enabled by default, and Databricks recommends leaving it enabled to ensure critical workloads run successfully at least once.”
↩︎ Auto-optimization and disallowing retries“Databricks recommends using serverless compute for all job tasks.”
↩︎ Choosing compute per task type“if you have workloads that must be executed at most once, for example, jobs that are not idempotent, you can turn off auto-optimization”
↩︎ Exam trap 3“In the Retry Policy dialog, uncheck Enable serverless auto-optimization (may include additional retries).”
↩︎ Checkpoint - 3.
“Serverless usage with high memory has a higher DBU emission rate than standard memory.”
↩︎ High-memory notebooks and notebook tasks“Updating the memory preference in the notebook affects the next job run.”
↩︎ High-memory notebooks and notebook tasks“It doesn't affect the memory size of the Spark session.”
↩︎ Exam trap 1“Under Memory, select High memory.”
↩︎ Checkpoint“This memory size setting increases the size of the REPL memory used when running code in the notebook.”
↩︎ Checkpoint