Databricks accounts, workspaces and identity boundaries
Separate administrative layers
A Databricks account provides account-level administration and relationships among workspaces. A workspace is an operational context for relevant objects, workloads and workspace permissions. Unity Catalog governs supported data and AI assets, while compute executes the workload under the selected architecture. These are related boundaries, not four interchangeable names for one administrator account. Account, workspace and metastore administrative roles have different scopes. Default privileges can depend on workspace history and automatic enablement, so inspect the actual assignment rather than assume every workspace administrator has the same data privileges.
Manage identities and their lifecycle
Users, groups and service principals have distinct purposes. A production automated workload should use an appropriately controlled non-human identity instead of depending on an employee’s personal credentials. Identity federation supports account-level identity management and assignment to workspaces in the documented model. SCIM is a provisioning mechanism, while sign-on and resource authorization are different functions. Supported automatic identity-management alternatives may also exist, so historical SCIM questions are not a claim that only one integration can ever provision a user.
Make access intentional
Assign relevant entitlements, object permissions and data privileges according to their actual scope. Membership in a workspace does not by itself grant SELECT on every catalog table. Likewise, a user able to start a job can trigger work that uses a separately configured Run as identity. Review that identity and job-edit rights together so changing code does not accidentally grant a broader data path. Group-based administration can reduce personal ownership dependencies, but groups still require an accountable membership and review process.
Control infrastructure and credentials
Classic customer-cloud compute and serverless arrangements have different responsibility and network models. Do not assume one cloud provider’s endpoint, key-management layout or private-network mechanism applies unchanged to every deployment. An account console setting can be a reusable building block without covering every workspace-level control automatically. Protect tokens, OAuth credentials, secret scopes and cloud identities under the actual supported model. A personal-access-token lifetime limit is not a complete identity lifecycle policy. Use actual audit evidence and a narrowly authorized test when verifying a changed assignment. This chapter is written platform-administration preparation, not an assertion of current accreditation format, free assessment availability or practical certification equivalence.