Databricks compute policies, jobs and operational evidence
Constrain the intended compute configuration
Compute policies can restrict supported configuration attributes, such as worker bounds, runtime choices, tags and idle termination. Policy use permissions are distinct from the JSON constraints themselves and from data access privileges. In an explicitly supplied autoscaling example with a worker range, the maximum constrains workers, not automatically every resource or all possible compute forms. Check access to unrestricted creation, other policies, fixed-size configurations and serverless options before claiming a universal cost or capacity limit.
Model a job as an execution graph
Tasks, dependencies, conditional run settings, retries and timeouts determine execution. A retry count normally describes additional attempts under its supported configuration; state the actual model before calculating a maximum attempt count. A skipped downstream task and a successful task are different outcomes. Repairing a failed run can preserve completed upstream results under supported behavior, but the exact tasks, parameter overrides and effects need the actual run state. A repair is not permission to repeat an irreversible external side effect without reviewing idempotence.
Distinguish scheduling from concurrency
A cron expression needs its supplied dialect and time zone. A paused schedule suspends that trigger, not necessarily every possible manual or external invocation. Reaching a concurrent-run limit can result in queueing or skipping according to the configured supported behavior; the concurrency number alone does not decide which. Dedicated job compute has a lifecycle associated with the run, while a pool can reduce some provisioning delay without guaranteeing instant startup. Serverless compute changes management responsibilities but does not remove customer identity, code and data-governance obligations.
Use the relevant evidence source
Operational system tables can support audit, cost and compute analysis according to actual regional scope, enablement, privileges and retention. They are not ordinary writable application tables, and their data can expose sensitive information. Driver logs, task output, query history and a Delta table’s transaction history describe different events. A Spark shuffle, spill or skew observation can guide a performance hypothesis, but no single metric proves every bottleneck. Performance changes require representative measurement and supported runtime assumptions. This chapter does not execute a job, change a policy, query private data or promise a current UI layout, cloud-specific feature or official assessment format.