A city open-data team runs nightly batch transforms for 311 tickets and needs compute that starts for the job and shuts down when the run finishes. Which compute should they select?

For a municipal open-data 311 nightly transform, job compute is the correct Azure Databricks pattern because it is purpose-built for scheduled, non-interactive workloads: the cluster (or serverless job compute) starts when the job is submitted, runs the batch transforms over ticket extracts, and terminates when the run completes so the city is not billed for idle capacity between nights. That lifecycle matches civic ETL economics—predictable start, bounded runtime, automatic shutdown—without leaving shared developer clusters warm all day for a once-per-night pipeline.

Classic all-purpose compute sized for the 311 batch so it terminates when the job completes is still interactive/development compute, not a production batch runner. Even though it claims to terminate when the job completes, it remains shared interactive compute designed for notebook development, so it lacks the dedicated job-compute isolation and start-for-the-run lifecycle the stem requires for the nightly 311 batch. A serverless SQL warehouse sized for the 311 batch so it terminates when the job completes is still the wrong compute family for this scheduled job: warehouses are built to serve SQL query and BI/dashboard concurrency, and claiming termination does not give it the job-compute lifecycle the stem requires for batch transforms—it lacks dedicated Spark job execution that starts specifically when this job is submitted and terminates the instant it completes. A single-node compute sized for the scheduled 311 batch so it terminates when the job completes is still development-pattern compute: single-node clusters exist to make interactive notebook iteration cheap and fast on one machine, and claiming termination doesn’t change that purpose—it lacks distributed scale-out execution for a production nightly batch rather than providing dedicated job compute that starts when the job is submitted and terminates the moment the run finishes.

Exam caveat: “job compute” does not mean “any cluster with a schedule.” Interactive all-purpose clusters can be triggered from jobs, but the exam expects the dedicated job-compute pattern when the requirement stresses terminate-on-completion and cost isolation from notebooks. Do not confuse SQL warehouses (SQL endpoints) with Spark job clusters just because both can run SQL – claiming a warehouse terminates when the job completes doesn’t make it job compute for the 311 batch, since warehouses are for serving concurrent SQL/BI traffic, not for starting when this job is submitted and terminating when it completes to run scheduled transforms.

Operational check: confirm the 311 workflow is defined as a Databricks Job (or Lakeflow job) using job compute (classic job cluster or serverless job compute per policy), verify auto-termination/completion behavior in run history, and confirm no all-purpose classic compute sized for the 311 batch is substituted even though it claims to terminate when the job completes before promoting the schedule to production.