If your platform team is bottlenecked by manual AWS console clicks and fragmented Terraform scripts every time someone needs a new Databricks workspace, you have a scaling problem.

A request for another Databricks workspace involves more than creating the workspace itself. Someone must choose the AWS network, configure storage and IAM, assign access, decide which compute options teams can use, and make sure the next workspace follows the same rules.

Terraform can describe those resources. The harder problem is deciding how people request changes, how those requests become Terraform inputs, and how the changes reach AWS and Databricks.

A configuration-driven approach gives those decisions a consistent, repeatable path:

This article explains that design using the Databricks Platform Engineering repository . Part two walks through setting up its development deployment from zero.

The repository has working development automation, with additional infrastructure and account provisioning for staging.…