Set up and configure an Azure Databricks environment

An Azure Databricks environment is built from two separable pillars, and this domain configures both of them. Compute is the engine you rent to run notebooks, jobs, and queries; you pick a type per workload and pay for it by the hour in Databricks Units (DBUs). Unity Catalog is the governed namespace where the data those engines read and write actually lives, addressed everywhere as a three-level catalog.schema.object name. The two are set up independently, and neither implies the other: attaching to a cluster grants no data access, and creating a catalog provisions no compute. The recurring exam trap is to blur that line, for example treating a SQL warehouse as a place where tables "live", or assuming a compute policy controls who can read a table. A compute policy governs cluster creation; a grant on a catalog object governs the data. Hold "what runs the work" and "where the data lives" apart as two axes, and most environment questions resolve cleanly.

The domain unfolds in two steps that mirror its two subtopics. First, Select and Configure Compute in a Workspace settles what runs the work and what it costs: choose the compute type per workload (job or serverless compute for scheduled production, all-purpose compute for interactive notebook development, a SQL warehouse for BI and SQL queries), size it with worker count and node type, set autoscaling and automatic termination, pin a Databricks Runtime version, and decide through entitlements, compute policies, and compute ACLs (access control lists) who may create and attach it. Reach for it whenever the question is which engine, how big, and who may run it. Second, Create and Organize Objects in Unity Catalog settles where data lives and how it is addressed: lay out the catalog.schema.object hierarchy with one catalog per environment as the isolation boundary, choose managed or external storage for tables and volumes, pin managed storage with MANAGED LOCATION, and add views, Lakehouse Federation, or an AI/BI Genie Agent. Reach for it whenever the question is where an object lives and what its full name is. (The word "serverless" spans both steps: it names a compute choice you select in the first, and separately, in the second, the Databricks-managed pipeline that refreshes a materialized view, a stored precomputed query result.)

Across both pillars the exam rewards one instinct: pick the purpose-built option that keeps environments isolated and lets Databricks own the lifecycle, and depart from it only when a stated requirement forces a more manual form. On compute, that favors job or serverless compute for production over shared all-purpose compute, and automatic termination for idle cost rather than trusting autoscaling to stop a cluster, which it never does, because autoscaling only resizes an active cluster's workers. On data, it favors a separate catalog per environment over separating environments by schema alone, a managed table or volume as the default so Databricks owns storage and optimization, and MANAGED LOCATION rather than the legacy LOCATION clause, which Unity Catalog rejects on a schema. Choose external storage only when files must survive a DROP, and all-purpose compute only when the work is genuinely interactive and shared.