A repeatable landing zone for Azure Databricks: workspaces, Unity Catalog, identity and CI/CD wired up from one parameter file. You describe the estate once, the accelerator generates the infrastructure as code and the first project scaffold. Everything it emits is plain code you can read, edit and own.
Most Databricks programmes start with a workspace someone clicked together in the portal. It works, so it stays. Six months later the platform team is running three environments that drifted apart, an account console full of ad hoc groups, and a catalog layout nobody can explain. Every new client or business unit means rebuilding the same foundation from memory, and the second build is never quite the same as the first.
No private networking, no storage credential strategy, no cluster policies, and no path from the proof of concept to a governed production estate.
Entra ID groups, account level SCIM sync, workspace assignment and Unity Catalog grants get set up by different people at different times, so permissions end up defined in three places that disagree.
Dev, test and prod diverge because they were provisioned by hand. Nobody can tell you what changed or when without diffing screenshots.
You describe the target estate once: subscription and region, environment names, network mode, storage accounts, the Entra ID groups that map to platform roles, and the catalog and schema layout per domain. From that input the accelerator generates account level and workspace level infrastructure as code, plus the scaffolding for the first project. What it does not do is decide for you: the open decisions are surfaced for human sign off before anything is applied.
One parameter file defines environments, regions, naming conventions and group to role mappings, and drives every generated artefact so dev, test and prod cannot silently drift.
Metastore assignment, catalog and schema layout per domain, external locations and storage credentials on an access connector with managed identity, plus a default grant model instead of ad hoc GRANT statements.
Entra ID groups mapped to account level groups, workspace assignment, and Unity Catalog privileges expressed in code, so the permission model has one source of truth.
Cluster policies, instance pool and node type defaults, serverless and SQL warehouse settings, and tagging rules for cost attribution, applied before the first workload lands.
A working Databricks Asset Bundle with per environment targets, a medallion notebook and job structure, and a deployment pipeline definition ready for Azure DevOps or GitHub Actions.
Every decision the accelerator made and every decision it deliberately left open: networking mode, private endpoints, metastore admin, storage firewall. A human signs those off before apply.
The generated estate uses the tooling your platform team already reviews in pull requests. Where a client also runs Microsoft Fabric, the storage and catalog layout is designed to stay readable from Fabric shortcuts rather than fight it.
Number of environments, how many business domains need their own catalog, whether the network has to be locked down, and which identity groups already exist. We map that onto the blueprint and show you what the generated deployment would look like before anyone touches a subscription. If you already have a Databricks workspace running, the same session doubles as a gap review against the target foundation.