Databricks DE-ASSOC Compute Choices Guide

This lesson covers one of the easiest places to lose points on DE-ASSOC: choosing compute by habit instead of by workload. The exam often gives you an interactive, scheduled, SQL-serving, or hands-off engineering scenario and asks whether you understand the operational fit of the compute choice.

All-purpose compute: Interactive compute meant for development, exploration, and collaborative notebook work.

Job compute: Compute meant for scheduled or triggered runs where repeatability matters more than ad hoc interactivity.

Serverless: Databricks-managed compute where infrastructure sizing and much of the operational overhead are abstracted away.

SQL warehouse: Databricks SQL-serving compute used for analyst queries, dashboards, and BI-facing workloads.

The first question to ask

Do not start with which compute option sounds powerful. Start with what kind of work is this:

1. Is the work interactive or scheduled?
2. Is the main consumer a data engineer, analyst, dashboard, or automated workflow?
3. Does the stem reward control and tuning, or lower operational overhead?
4. Is the compute choice solving execution fit, not permissions or data modeling?

High-yield chooser

Workload fit table

The real exam habit

Strong answers do not ask “which compute type do I personally use most?” They ask:

1. Is the work interactive or scheduled?
2. Is the consumer a data engineer, an analyst, or a dashboard?
3. Does the problem reward hands-off managed runtime behavior?
4. Is the concern throughput, latency, ease of operation, or collaborative development?

Once those are clear, the compute answer usually becomes much easier.

Serverless is an operational choice

DE-ASSOC does not test serverless as magic. It tests whether you see when hands-off managed compute is stronger than manually sizing and managing clusters yourself. If the stem rewards:

• faster setup
• less infrastructure handling
• auto-optimized runtime behavior
• managed scaling for a standard workload

then serverless often becomes the strong lane.

Common traps

Candidates sometimes choose interactive compute for scheduled production work because that is where they developed the notebook originally. The exam usually rewards separating how you developed the logic from how you should run it in production.

Other frequent misses:

• picking SQL-serving compute for ETL just because the code uses SQL syntax
• picking serverless only because it sounds newer rather than because the scenario rewards lower ops overhead
• resizing compute before deciding whether the workload should be interactive, job-based, or warehouse-backed at all

Harder scenario question

A team has a transformation notebook that was built interactively, but it now must run every two hours, keep clean run history, and recover inside a production workflow. Which compute instinct is strongest first?

• A. Keep the same interactive development cluster running forever
• B. Move the logic into a scheduled workflow with job-oriented compute
• C. Convert the whole pipeline into a dashboard
• D. Grant more Unity Catalog permissions

Correct answer: B. The requirement changed from development convenience to scheduled, repeatable execution.

Decision order that usually wins

1. Classify the workload first: interactive exploration, scheduled ETL, or analyst-facing queries.
2. Match compute mode to workload intent before thinking about size.
3. Separate development convenience from production execution fit.
4. Prefer serverless or job-oriented answers when the stem rewards less ops overhead.
5. Treat cluster choice as an operational-fit decision, not a personal habit.

Quiz