Data Governance — DE Professional Practice Questions

1 Data Governance

A data governance lead wants business users to find trustworthy tables by searching for business concepts (e.g., 'PII', 'gold', 'customer 360') and to see human-readable descriptions of tables and columns directly in the catalog. The solution must be queryable and enforceable through Unity Catalog metadata rather than an external spreadsheet. Which combination of Unity Catalog features best supports discoverability at scale?

AAttach COMMENT text to catalogs, schemas, tables, and columns for human-readable descriptions, and apply Unity Catalog tags (key-value) to tables/columns for concepts like pii=true or layer=gold; both comments and tags are stored in Unity Catalog and are searchable and queryable (e.g., via information_schema / system catalog), enabling concept-based discovery.
BStore all descriptions and classifications as table properties using TBLPROPERTIES ('description'='...') only, because table properties are the sole Unity Catalog mechanism for metadata and tags are not supported on Unity Catalog securables.
CMaintain a separate Delta 'catalog_metadata' table that maps table names to descriptions and tags, and join it in every query; Unity Catalog itself cannot store descriptions, so an external mapping table is the recommended discoverability pattern.
DEncode concepts into table and column names (e.g., prefix PII columns with pii_) since name-based conventions are the only reliably searchable metadata; comments are display-only and cannot be queried programmatically.
ERely exclusively on Databricks Marketplace listings to publish descriptions and tags, because discoverability metadata is a Marketplace feature and is not available for internal Unity Catalog objects.

Show answer & explanation

Correct answer: A

WHY A: Unity Catalog supports COMMENT descriptions on every securable level (catalog, schema, table, column) for human-readable documentation, and it supports tags (key-value pairs) on tables and columns for classifying business concepts like PII or medallion layer. Both live in Unity Catalog and are searchable/queryable (including via information_schema and system tables), enabling concept-based discovery at scale. WHY NOT B: Tags ARE supported on Unity Catalog securables; restricting to TBLPROPERTIES ignores comments and column-level tagging. WHY NOT C: Unity Catalog can store descriptions and tags natively, so an external mapping table is unnecessary and not the recommended pattern. WHY NOT D: Comments and tags are queryable metadata, not display-only, so name conventions are not the 'only' searchable option and are far less flexible. WHY NOT E: Discoverability metadata (comments, tags) applies to internal Unity Catalog objects; it is not exclusive to Marketplace.

2 Data Governance

An analyst is granted SELECT on finance.reports.revenue but reports they cannot query it — the table does not even appear when they browse the catalog, and SELECT fails with a permission error on the schema. The table owner confirms the SELECT grant on the table itself is present and correct. Which additional privileges does Unity Catalog require for the analyst to successfully read the table?

AThe analyst needs USAGE on the metastore and BROWSE on the catalog; USAGE on the metastore is the top-level privilege that cascades read access down to any table with a SELECT grant.
BThe analyst must be made the owner of the table, because in Unity Catalog only the owner or the metastore admin can run SELECT, regardless of any SELECT grant.
CThe analyst needs MODIFY on the schema in addition to SELECT on the table, since MODIFY is what makes a securable visible in the catalog browser and enables read traversal.
DNo extra grant is needed at the Unity Catalog level; the failure means the analyst lacks the underlying cloud storage credential, so the fix is to grant them direct read access to the table's storage path.
EThe analyst also needs USE CATALOG on finance and USE SCHEMA on finance.reports; these traversal privileges are required to reach a securable, and without them a table-level SELECT cannot be exercised even though it exists.

Show answer & explanation

Correct answer: E

WHY E: To read a table in Unity Catalog, a principal needs the data privilege (SELECT) on the table AND the traversal privileges to reach it: USE CATALOG on the parent catalog and USE SCHEMA on the parent schema. Missing traversal privileges make the object invisible and block the query even when SELECT is granted. WHY NOT B: Ownership is not required to SELECT; a SELECT grant is sufficient once traversal privileges are present. WHY NOT C: MODIFY grants write (insert/update/delete) capability, not catalog visibility or read traversal; the traversal privileges are USE CATALOG/USE SCHEMA. WHY NOT D: Unity Catalog manages storage access via the table's managed/external credential; analysts do not need direct cloud storage grants, and the error is a UC traversal issue, not a raw storage permission. WHY NOT A: BROWSE aids discovery but is not what enables the read, and there is no metastore-level USAGE privilege that cascades SELECT to all tables; traversal is via USE CATALOG/USE SCHEMA.

3 Data Governance

A data engineer must let a BI service principal read only the Gold-layer schema sales.gold, while a separate data science group needs read access to sales.gold and sales.silver but must never see the raw sales.bronze schema. The catalog sales also contains other schemas that neither principal should access. Following least privilege, which grant strategy is correct?

AGrant SELECT on sales.gold and sales.silver without any USE CATALOG/USE SCHEMA grants, since data privileges alone are sufficient and adding traversal privileges would over-grant beyond least privilege.
BGrant SELECT on the sales catalog to both principals, then REVOKE SELECT on sales.bronze from the data science group; catalog-wide grants minus targeted revokes is the least-privilege pattern because it uses the fewest statements.
CMake the BI service principal and data science group owners of sales.gold and sales.silver respectively; ownership is the least-privilege way to grant read because owners implicitly get only read access to the objects they own.
DGrant USE CATALOG on sales to both principals; grant USE SCHEMA + SELECT on sales.gold to the BI service principal; grant USE SCHEMA + SELECT on sales.gold and on sales.silver to the data science group. Do not grant any SELECT at the catalog level, so no principal inherits access to bronze or other schemas.
ECreate a single group containing both principals and grant it SELECT on sales.silver and sales.gold; consolidating principals into one group with schema-level grants is least privilege because it avoids per-principal grants entirely.

Show answer & explanation

Correct answer: D

WHY D: Least privilege here means granting traversal (USE CATALOG on sales, USE SCHEMA on only the needed schemas) plus SELECT scoped to exactly the schemas each principal requires, and never granting SELECT at the catalog level (which would be inherited by bronze and every other schema). This gives the BI principal only gold and the data science group only gold+silver, with bronze unreachable. WHY NOT B: A catalog-wide SELECT inherits down to ALL schemas including bronze and the other schemas; relying on targeted REVOKE to claw back access is error-prone and violates least privilege. WHY NOT C: Ownership confers full control (not just read) and management rights, which is far more than least-privilege read access. WHY NOT A: Without USE CATALOG/USE SCHEMA traversal privileges the SELECT cannot be exercised, so this fails to grant working access. WHY NOT E: The BI principal must not read silver; putting both principals in one group with silver+gold over-grants silver to the BI principal, violating least privilege.

4 Data Governance

A compliance auditor asks a data engineer to produce, from within Databricks SQL, a queryable inventory of (1) every table in a catalog with its owner and comment, and (2) a record of who granted which privilege on those tables. The engineer wants to use built-in Unity Catalog metadata surfaces rather than scraping the UI. Which sources correctly provide this information?

ACall the SHOW GRANTS statement in a loop and paste results into a spreadsheet; Unity Catalog does not expose grants as queryable relations, so imperative SHOW commands are the only programmatic option.
BRead the Delta transaction logs (_delta_log) of each table with DESCRIBE HISTORY, since ownership, comments, and grant history are all recorded as commit metadata in the table's own log.
CQuery the catalog's information_schema (e.g., information_schema.tables for names/owners/comments and information_schema.table_privileges for grants), which exposes Unity Catalog metadata for that catalog as standard SQL relations the auditor can filter and join.
DQuery dbfs:/system/audit/ JSON files with a schema-on-read DataFrame, because Unity Catalog writes all governance metadata (owners, comments, grants) as flat files under DBFS that must be parsed manually.
EEnable the Hive metastore SYSTEM.GOVERNANCE database and query its tables and grants views; Unity Catalog governance metadata is surfaced only through the legacy Hive metastore, not through information_schema.

Show answer & explanation

Correct answer: C

WHY C: Unity Catalog exposes per-catalog metadata through the standard information_schema, including tables (names, owner, comment) and table_privileges (grantor, grantee, privilege), so the auditor can build the inventory with ordinary SQL joins and filters. (Account-level system tables complement this for cross-catalog auditing.) WHY NOT B: DESCRIBE HISTORY/_delta_log records data-changing commits for a single table, not ownership, comments, or grant history. WHY NOT A: Unity Catalog DOES expose grants as queryable relations via information_schema.table_privileges (and system tables), so imperative SHOW GRANTS copy-paste is not the only option. WHY NOT D: Unity Catalog governance metadata is not stored as parseable flat files under DBFS. WHY NOT E: Governance metadata is exposed via information_schema/system tables in Unity Catalog, not through a legacy Hive metastore governance database.

5 Data Governance

A Unity Catalog administrator wants to allow a service principal to create tables in any schema that currently exists OR will be created in the future within the catalog prod. Which privilege grant achieves this with the FEWEST, MOST targeted privileges?

AGRANT CREATE TABLE ON SCHEMA prod.bronze TO etl_sp; GRANT CREATE TABLE ON SCHEMA prod.silver TO etl_sp; (repeat for each schema)
BGRANT ALL PRIVILEGES ON CATALOG prod TO etl_sp;
CGRANT USE CATALOG ON CATALOG prod TO etl_sp; GRANT CREATE TABLE ON CATALOG prod TO etl_sp;
DGRANT CREATE SCHEMA ON CATALOG prod TO etl_sp; GRANT USE CATALOG ON CATALOG prod TO etl_sp;

Show answer & explanation

Correct answer: C

WHY C is correct: Unity Catalog's privilege inheritance model allows certain privileges granted at the catalog level to automatically apply to all current AND future schemas within that catalog. The CREATE TABLE documentation states: 'Since privileges are inherited, CREATE TABLE can also be granted on a catalog, which allows a user to create a table or view in any existing or future schema in the catalog. The user must also have the USE CATALOG privilege on its parent catalog.' Granting both USE CATALOG and CREATE TABLE at the catalog level satisfies all requirements in two statements and covers any schema created now or in the future — no per-schema re-grants are ever needed. WHY NOT A: Granting CREATE TABLE per schema is operationally fragile and does NOT scale to future schemas. Every time a new schema is added, the administrator must remember to re-grant CREATE TABLE to the service principal. This approach does not leverage privilege inheritance and does not satisfy the 'future schemas' requirement. WHY NOT B: ALL PRIVILEGES on a catalog is far too broad. It grants all applicable privileges (SELECT, MODIFY, CREATE TABLE, CREATE SCHEMA, APPLY TAG, etc.) on every existing and future object in the catalog. This violates the principle of least privilege — the SP only needs to create tables, not read, modify, or manage all data. WHY NOT D: GRANT CREATE SCHEMA on a catalog allows the service principal to create new schemas, which is not the requirement. CREATE TABLE and CREATE SCHEMA are completely separate, unrelated privileges. This option would not grant the ability to create tables in any schema.

6 Data Governance

A governance requirement states that in the hr.employees table, non-HR users must see the salary column as NULL while HR users see the true value, and all users must only see rows for their own department. The team wants to enforce this centrally on the base table so every downstream query and BI tool inherits the rules, without maintaining a separate secured view. Which Unity Catalog approach implements both requirements directly on the table?

ACreate a dynamic view hr.employees_secure with CASE WHEN is_member('hr') logic for salary and a WHERE clause on department, then revoke SELECT on the base table; a secured view is the only way to combine column and row rules, so downstream tools must point at the view.
BAttach a column mask function to the salary column that returns NULL unless is_account_group_member('hr'), and attach a row filter function to the table that restricts rows to the caller's department; both are Unity Catalog table-level policies that apply to every query against the base table.
CEnable Delta table columnMasking and rowFiltering properties set to true and list the protected column and predicate in TBLPROPERTIES; Unity Catalog reads these properties and enforces masking and filtering automatically without any function.
DGrant SELECT on all columns except salary to non-HR users using column-level GRANT, and partition the table by department so that department-scoped GRANTs restrict rows; column and partition GRANTs together achieve masking and row security on the base table.
EUse two row filters — one that nullifies salary and one that restricts departments — because row filters can both drop rows and rewrite column values; column masks are only for hashing and cannot return NULL conditionally.

Show answer & explanation

Correct answer: B

WHY B: Unity Catalog provides two table-attached fine-grained controls: column masks (a UDF bound to a column that rewrites its returned value, e.g., NULL for non-HR via is_account_group_member) and row filters (a UDF bound to the table that returns a boolean predicate to restrict visible rows, e.g., matching the caller's department). Both are enforced on the base table for every query and tool. WHY NOT A: A dynamic view works but is exactly the 'separate secured view' the requirement wants to avoid; row filters and column masks let you enforce on the base table itself. WHY NOT C: There are no columnMasking/rowFiltering boolean table properties that auto-enforce from a predicate list; masks and filters are implemented as UDF policies attached to the column/table. WHY NOT D: Column-level GRANTs remove a column entirely for a principal (they do not mask to NULL selectively), and partitioning does not enforce per-user row security. WHY NOT E: Column masks CAN conditionally return NULL and are the correct primitive for the salary rule; row filters only include/exclude rows and cannot rewrite a column's value.

7 Data Governance

A data governance team wants all users in the Databricks account to be able to discover tables registered in a newly created catalog called analytics — meaning users can view the catalog, its schemas, and table names in Catalog Explorer and search results, even if they cannot yet query the data. The catalog was created via SQL. What is the MINIMUM privilege the team needs to grant, and to which principal?

AGrant BROWSE on analytics to All account users.
BGrant SELECT on analytics to All account users.
CGrant USE CATALOG on analytics to All account users.
DGrant ALL PRIVILEGES on analytics to All account users.

Show answer & explanation

Correct answer: A

WHY A is correct: The BROWSE privilege on a catalog allows users to view an object's metadata — including catalog, schema, and table names — using Catalog Explorer, the schema browser, search results, and the lineage graph without granting any access to actual data. Databricks explicitly recommends granting BROWSE on catalogs to the 'All account users' group to make objects discoverable and allow all users to request access. Crucially, catalogs created via SQL statements, the REST API, or the Databricks CLI do NOT grant BROWSE by default — it must be explicitly granted. USE CATALOG is NOT required to view metadata if the user has BROWSE on the catalog. WHY NOT C: USE CATALOG on a catalog allows a user to interact with objects within the catalog (i.e., run queries), but it does not enable discovery on its own without SELECT or other data access privileges. Granting USE CATALOG to all account users would allow them to traverse the hierarchy but not query data — however, it is a broader grant than needed and is not the targeted discovery mechanism Databricks recommends. WHY NOT B: SELECT grants read access to data in tables and views. This is far broader and more permissive than needed for mere discoverability. Granting SELECT to all account users on the entire catalog would expose all data, violating least privilege. WHY NOT D: ALL PRIVILEGES on a catalog grants every applicable privilege to all users on every existing and future object in the catalog. This is an extreme grant that would expose all data and enable modifications, violating fundamentally the principle of least privilege.

8 Data Governance

A data engineer runs the following command: ``sql GRANT SELECT ON CATALOG main TOanalyst_team;`A new table calledmain.reporting.revenue is created one week later. Which of the following statements CORRECTLY describes analyst_team`'s access to this new table?

Aanalyst_team has no access to main.reporting.revenue because privileges must be re-granted after new objects are created.
Banalyst_team can SELECT from main.reporting.revenue because privilege inheritance causes the catalog-level SELECT grant to automatically apply to all current and future tables in the catalog.
Canalyst_team can SELECT from main.reporting.revenue only after the table owner explicitly grants SELECT on that specific table.
Danalyst_team has SELECT on main.reporting.revenue but still needs USE SCHEMA on main.reporting and USE CATALOG on main granted separately, since catalog-level grants do not cover navigation privileges.

Show answer & explanation

Correct answer: B

WHY B is correct: Unity Catalog uses a privilege inheritance model where privileges granted at a higher level in the object hierarchy automatically apply to all current AND future objects beneath it. The documentation explicitly states: 'Since privileges are inherited, you can grant a user the SELECT privilege on a catalog or schema, which automatically grants the user SELECT privilege on all current and future tables, and views in the catalog or schema.' Furthermore, granting SELECT at the catalog level implicitly covers the necessity to traverse the hierarchy — the GRANT at the catalog level encompasses the USE CATALOG privilege on that same catalog. Similarly, USE SCHEMA is also covered by the catalog-level grant because all descendant privileges inherit downward. The analyst team can therefore immediately query main.reporting.revenue without any further explicit grants. WHY NOT A: This is incorrect. Privilege inheritance means existing catalog-level grants propagate to future objects automatically. There is no requirement to re-grant privileges each time a new object is created when the grant was made at the catalog level. WHY NOT C: With a catalog-level SELECT grant in place, there is no need for the table owner to grant SELECT on individual tables. Inheritance eliminates the need for object-by-object grants for users who already have the privilege at a higher level. WHY NOT D: When SELECT is granted at the catalog level, USE CATALOG and USE SCHEMA are implicitly satisfied as part of the catalog-level inheritance. They do not need to be granted separately; the catalog-level grant covers the full navigation chain needed to access objects within that catalog.

Take the full DE Professional practice test →

Keep going

Data Governance: Databricks Data Engineer Professional Practice Questions

Other DE Professional topics