Interactive Databricks clusters created freehand with no cluster policy attached

What a missing policy leaves uncontrolled

A cluster policy is the guardrail Databricks gives admins for compute creation. Databricks describes policies as a way to limit users to prescribed settings, limit how many clusters each user can create, and control cost by limiting per-cluster maximum cost. Users who hold the Unrestricted cluster creation entitlement get an Unrestricted policy that lets them configure anything, and that is where freehand clusters come from.

Without a policy nothing stops a cluster from being built on the largest node type, with a high fixed worker count, no cost tags and no idle shutdown. None of that costs money on the day it is created; it costs money every hour afterwards.

Finding policy-less clusters from the CLI

The cluster record exposes policy_id. List clusters where it is absent or blank:

databricks clusters list -o json \
  | jq -r '.[] | select((.policy_id // "") == "") | [.cluster_id, .cluster_name, .cluster_source] | @tsv'

Then see which policies already exist and could be attached:

databricks cluster-policies list -o json | jq -r '.[] | [.policy_id, .name] | @tsv'

The reverse filter, databricks clusters list --policy-id <id>, is handy for checking which clusters a policy already governs.

The evidence this rule insists on

ZopNight fires only when it actually read the cluster’s policy field and the value was empty. The cluster must also be interactive (created from the UI or API, not by a job, pipeline, SQL warehouse or model serving) and must not be stopped or in error, so the finding always concerns compute that is live.

Why a blank field is not always a finding

A missing field and an empty field are different things. If the policy field was never collected for a cluster, or ZopNight holds no configuration for it at all, the rule does not raise a finding, because it cannot tell “no policy” apart from “unknown”. Terminated clusters are skipped too; the gap matters again when someone restarts them.

No saving is attached, only exposure

This is a governance finding, so the saving shown is zero. The value is preventive: a policy caps the settings that other rules measure after the fact, such as Cluster Missing/Weak Auto-Termination and Missing Cost-Allocation Tags.

Putting clusters under a policy

1. Start from a policy family or write a definition. Policy attributes can be fixed, range or allowlist, for example a fixed autotermination_minutes, a range on autoscale.max_workers, an allowlist on node_type_id, and fixed custom_tags.team; see the policy definition reference.
2. Assign it to existing all-purpose compute with Add compute to policy, which previews the configuration changes before applying them.
3. Grant users the policy and remove Unrestricted cluster creation from those who do not need it, so new clusters cannot be created freehand.