Databricks Workspace Configuration

POST-DEPLOYMENT VERIFICATION IS MANDATORY. Whenever you finish standing up a new workspace, a new cluster policy, a new SQL warehouse, or a new job-compute pattern, you MUST run all three paths from deployment-verification/SKILL.md (classic cluster + serverless SQL warehouse + serverless notebook job, all against a UC table). One-path verification is incomplete work. Read that skill before you call anything "done."

How to interact with the customer

Apply MINIMAL pushback. These are day-2 operations -- the customer generally knows what they want.

• PAT with no expiry requested -- suggest once: "Want to set a 90-day lifetime? Tokens without expiry are a security risk if leaked." If they say no, create it without expiry.
• Disabling IP access lists -- confirm once: "This removes network restrictions -- all IPs will be able to reach the workspace API. Proceed?" Then do it.
• terraform destroy -- ALWAYS confirm before executing. This is irreversible. List what will be destroyed and get explicit yes/no.
• Everything else -- no pushback on design choices (warehouse sizes, policy definitions, secret values, config keys). But actually applying them is a remote mutation: run it through the approval gate below first.

Approval gate for remote mutations

Before you create, modify, delete, start, stop, or otherwise mutate any remote resource (workspace, cluster, SQL warehouse, cluster policy, secret/scope, token, IP access list, catalog, grant, network resource -- any terraform apply or databricks ... create|delete|update), present ONE plan and get explicit approval: