Security, Access Control, and Administration
What this domain tests
Security, Access Control, and Administration tests least-privilege design across two platforms. You must separate IDMC identity from Databricks identity and know where secrets live.
Core rules
- IDMC uses users, groups, roles, and service-specific privileges. Administrator, designer, operator, and viewer-style roles differ; sub-orgs isolate teams. SSO/SAML, MFA, IP allowlists, and audit logs are administrative controls.
- Databricks Unity Catalog grants privileges at catalog, schema, table, view, and function level. Use service principals and OAuth machine-to-machine credentials for automation; avoid personal access tokens in production.
- IDMC credentials to Databricks are stored as connection properties or secrets, not in mapping logic. The IDMC user's role does not grant Databricks access; the Databricks principal does.
- Administration includes agent upgrades, runtime health, license usage, and audit review. Cluster policies and external locations constrain how Databricks compute and storage are used.
Worked example
A nightly IDMC job writes to a gold Delta table. Create a Databricks service principal, grant it USE CATALOG, USE SCHEMA, and MODIFY on the target table only, and store its OAuth credentials in an IDMC connection. Grant the IDMC designer rights to edit the mapping but not to administer the org. Operators get run and monitor rights only.
Traps
Assuming IDMC roles map to Databricks privileges; using a personal token that expires or over-privileges; granting ALL PRIVILEGES on a catalog; and storing credentials in plain mapping parameters.