DP-750 Secure and govern Unity Catalog objects

Secure and govern Unity Catalog objects Detailed Explanation

Fast review map for this domain:

Exam signal	First object to inspect	Correct-answer pattern
User can see catalog but not data	Privilege inheritance and securable object grant	Grant the lowest necessary privilege at catalog, schema, table, view, volume, or function scope
Different users need different rows or columns	Row filters, column masks, ABAC policies	Use fine-grained controls instead of duplicating tables
Notebook needs a secret or Azure resource	Azure Key Vault secret scope, service principal, managed identity	Validate identity and secret boundary before changing table grants
Sharing must stay controlled	Delta Sharing and audit logs	Separate recipient/provider model from internal workspace permissions

flowchart LR  
    N1[Principal] --> N2  
    N2[Privilege or policy] --> N3  
    N3[Unity Catalog object] --> N4  
    N4[Data access] --> N5  
    N5[Audit and lineage evidence]  

Grant Unity Catalog privileges to principals at the correct securable scope

Exam Radar

• Core Priority: Unity Catalog privilege questions test the exact securable scope where a principal loses traversal or action rights.
• High Frequency: Expect USE CATALOG, USE SCHEMA, SELECT, MODIFY, READ VOLUME, WRITE VOLUME, CREATE TABLE, CREATE VOLUME, group grants, and service-principal access.
• Confusion Alert: Do not grant workspace admin or table SELECT alone when the parent catalog or schema traversal privilege is missing.
• Scenario Logic: Read the error target, then inspect parent grants before leaf-object grants; a valid table grant still fails if USE CATALOG or USE SCHEMA is absent.
• Version Delta: This topic remains in the Microsoft DP-750 skills measured from March 11, 2026 under Secure and govern Unity Catalog objects; answer choices should use current Azure Databricks, Unity Catalog, Lakeflow, Azure Monitor, and Microsoft Entra terminology.
• Failure Trigger: The failure appears as query denial, invisible schemas, blocked volume access, or a service principal that can run a job but cannot read the governed object.
• Operational Dependency: Microsoft Entra principal mapping, catalog grant, schema grant, and leaf-object privilege must all align for data access.
• How the Exam Asks It: The exam asks which grant or scope fixes the access path without overprivileging the user.
• How Distractors Are Designed: Wrong answers resize compute, convert table type, or assign broad workspace roles instead of repairing the missing securable grant.
• Why the Correct Answer Works: The correct answer grants the minimum parent and leaf privilege and verifies it with SHOW GRANTS or a representative read.

Practice Question: A user has SELECT on a table but receives an access error when querying it. The table is in a new catalog and schema. What is the most likely missing dependency?
A. The user also needs USE CATALOG and USE SCHEMA on the parent namespace.
B. The user must become workspace admin.
C. The table must be converted to an unmanaged table.
D. The SQL warehouse must be resized.
Correct Answer: A.
Explanation: A is correct because Unity Catalog object traversal requires parent namespace usage privileges in addition to table SELECT. B overprivileges. C changes storage lifecycle. D targets performance, not authorization. Exam Takeaway: Select the object that owns the dependency; the distractor pattern is an adjacent Databricks feature that is technically real but does not satisfy the scenario's first blocking condition.

Atomic Deconstruction - Operational Level

Security topics must be decomposed from parent scope to leaf access. Unity Catalog authorizes traversal first, then object action, then fine-grained policy. Azure resource access adds a separate identity plane through Key Vault, service principals, managed identities, storage credentials, and cloud RBAC.

A correct answer does not simply grant more access. It names the missing permission or identity hop: USE CATALOG before table SELECT, READ VOLUME before file access, Key Vault permission before secret lookup, storage credential role before external location reads, or row/column policy before data is exposed.

The practical habit is to test with two principals: one that should succeed and one that should be restricted. This catches the common DP-750 distractor where a broad workspace or admin grant appears to fix the symptom but destroys the governance requirement.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Principal	Identity target	User, group, or service principal	No access unless inherited or granted	Microsoft Entra identity sync and workspace assignment	Grant fails or applies to the wrong identity
Catalog privilege	Namespace access	USE CATALOG, CREATE SCHEMA, ownership-related permissions	Not granted to arbitrary principals	Catalog object and metastore assignment	User sees no schemas despite table-level intent
Schema privilege	Object access layer	USE SCHEMA, CREATE TABLE, CREATE VOLUME	No object traversal without USE	Catalog privilege	Table grant appears correct but query still fails
Table/view privilege	Data access action	SELECT, MODIFY, or ownership-related actions	No data access	USE CATALOG and USE SCHEMA	403-like authorization failure at query time
Volume privilege	File access action	READ VOLUME or WRITE VOLUME	No file access	Catalog and schema traversal	Notebook cannot read governed files

Step-by-Step Execution Path

1. Identify the exact securable object named in the error: catalog, schema, table, view, volume, or function.
2. Check whether the principal is a user, group, or service principal; group grants are often preferred for operational maintainability.
3. Validate parent traversal grants before diagnosing the leaf object privilege.
4. Grant the smallest privilege needed for the task, such as SELECT for read-only query or READ VOLUME for file reading.
5. Re-run the same query or file access operation through the intended compute resource.
6. Capture audit or Catalog Explorer evidence so the exam scenario can distinguish permission-scope mismatch from compute or storage failures.

Exam implementation pattern:

• When to use: a principal can see some objects but cannot query, create, read files, or traverse the Unity Catalog hierarchy.
• Minimal syntax: inspect parent and leaf grants with SHOW GRANTS ON CATALOG, SHOW GRANTS ON SCHEMA, or SHOW GRANTS ON TABLE.
• What to verify: USE CATALOG, USE SCHEMA, SELECT/MODIFY, READ/WRITE VOLUME, and the exact user/group/service principal.
• Common wrong answer: assigning workspace admin when a parent namespace grant is missing.

Command confidence note: Commands shown in this section are verification-oriented examples. Validate exact Databricks CLI syntax against the active CLI and workspace version before using it as an authoritative production procedure.

Technical Chain

The chain starts with identity resolution: Azure Databricks maps the user, group, or service principal to Unity Catalog privileges or external Azure resource permissions.

Unity Catalog then evaluates parent namespace traversal, object action, and fine-grained policy. For external storage, the storage credential or managed identity must also be authorized on the cloud resource. A failure at any hop can look like a table problem even when the table definition is correct.

Correct remediation changes the failed hop and preserves auditability. Broad workspace admin grants can mask the failure, but they do not prove the securable object or cloud resource was governed correctly.

Exam Trap Summary: Do not grant workspace admin for a missing USE CATALOG or USE SCHEMA dependency.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate catalog grants	SQL verification: SHOW GRANTS ON CATALOG <catalog>;	Principal has USE CATALOG or required catalog-level action
Validate schema grants	SQL verification: SHOW GRANTS ON SCHEMA <catalog>.<schema>;	Principal has USE SCHEMA and relevant create privilege if needed
Validate table grants	SQL verification: SHOW GRANTS ON TABLE <catalog>.<schema>.<table>;	Principal has SELECT or MODIFY according to scenario
Validate access outcome	Run representative SELECT * FROM <catalog>.<schema>.<table> LIMIT 1;	Query succeeds only for intended principal

Implement row filters, column masks, and ABAC policies in Unity Catalog

Exam Radar

• Core Priority: Row filters, column masks, and ABAC policies test fine-grained data visibility without duplicating governed datasets.
• High Frequency: Expect region-based row visibility, masked PII, governed tags, policy functions, and scenarios where central users see more than regional users.
• Confusion Alert: Do not copy the table per audience or grant broad access when one governed table can apply a policy at row, column, or attribute scope.
• Scenario Logic: Identify whether the rule differs by row, by column value, or by tagged object attribute, then bind the policy at the correct object.
• Version Delta: This topic remains in the Microsoft DP-750 skills measured from March 11, 2026 under Secure and govern Unity Catalog objects; answer choices should use current Azure Databricks, Unity Catalog, Lakeflow, Azure Monitor, and Microsoft Entra terminology.
• Failure Trigger: The failure appears as overexposed rows, redacted values becoming unusable, ABAC rules not firing because tags are missing, or policy functions blocking legitimate users.
• Operational Dependency: Policy function logic, principal or group attributes, governed tags, table/column binding, and ownership permissions must all be valid.
• How the Exam Asks It: The exam asks which fine-grained control fits the visibility requirement and how to validate it with multiple principals.
• How Distractors Are Designed: Wrong answers duplicate physical tables, change compute isolation, or move storage paths without enforcing row or column logic.
• Why the Correct Answer Works: The correct answer applies the policy to the governed object and proves the allow/deny behavior with representative users.

Practice Question: A single sales table must show only each region's rows to regional analysts while central finance can see all rows. The team wants to avoid copying the table. Which design best fits?
A. Create one physical table per region and schedule copy jobs.
B. Use a row filter function or ABAC policy that evaluates the analyst's region attribute.
C. Increase cluster isolation so analysts cannot share notebooks.
D. Move the table to an external location.
Correct Answer: B.
Explanation: B is correct because row-level policy controls visibility on one governed table. A creates duplication and drift. C addresses compute collaboration, not data rows. D changes storage path but does not enforce regional access. Exam Takeaway: Select the object that owns the dependency; the distractor pattern is an adjacent Databricks feature that is technically real but does not satisfy the scenario's first blocking condition.

Atomic Deconstruction - Operational Level

Security topics must be decomposed from parent scope to leaf access. Unity Catalog authorizes traversal first, then object action, then fine-grained policy. Azure resource access adds a separate identity plane through Key Vault, service principals, managed identities, storage credentials, and cloud RBAC.

A correct answer does not simply grant more access. It names the missing permission or identity hop: USE CATALOG before table SELECT, READ VOLUME before file access, Key Vault permission before secret lookup, storage credential role before external location reads, or row/column policy before data is exposed.

The practical habit is to test with two principals: one that should succeed and one that should be restricted. This catches the common DP-750 distractor where a broad workspace or admin grant appears to fix the symptom but destroys the governance requirement.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Row filter	Predicate function binding	Boolean row-visibility expression	No row filter	Function definition and table binding	Users see too many rows or no rows because predicate is wrong
Column mask	Transformation function binding	Redacted, null, hashed, or conditional value	No mask	Function and table column binding	Sensitive columns leak or become unusable
ABAC tag	Attribute label	Governed tag value	No tag	Tag policy and object assignment	Policy does not apply because attribute is absent
Policy function	Access logic	SQL function with identity or attribute checks	Not created	Function permissions and deterministic logic	Filter or mask blocks legitimate users
Securable object	Policy attachment point	Table, column, catalog, or schema supported by feature	No policy	Unity Catalog support and ownership	Fine-grained control is attempted in the wrong layer

Step-by-Step Execution Path

1. Determine whether the requirement varies by row, by column, or by object attribute.
2. For row differences, design a predicate that maps the principal or group to allowed values.
3. For sensitive columns, design a mask that preserves query usability while hiding protected values.
4. For policy-scale governance, apply tags or ABAC where supported so the rule follows tagged objects.
5. Attach the filter or mask to the table or column only after verifying ownership and function behavior.
6. Test with at least two representative principals so the expected allow and deny paths are both visible.

Exam implementation pattern:

• When to use: one table must return different rows or masked values to different principals without copying data.
• Minimal syntax: define a policy function or supported row filter/column mask and bind it to the target table or column.
• What to verify: two-principal query output, policy binding in Catalog Explorer, and expected unmasked or filtered result.
• Common wrong answer: creating one physical table per user group or granting broad access and relying on documentation.

Command confidence note: Commands shown in this section are verification-oriented examples. Validate exact Databricks CLI syntax against the active CLI and workspace version before using it as an authoritative production procedure.

Technical Chain

The chain starts with identity resolution: Azure Databricks maps the user, group, or service principal to Unity Catalog privileges or external Azure resource permissions.

Unity Catalog then evaluates parent namespace traversal, object action, and fine-grained policy. For external storage, the storage credential or managed identity must also be authorized on the cloud resource. A failure at any hop can look like a table problem even when the table definition is correct.

Correct remediation changes the failed hop and preserves auditability. Broad workspace admin grants can mask the failure, but they do not prove the securable object or cloud resource was governed correctly.

Exam Trap Summary: Do not duplicate tables for each audience when a row filter, column mask, or ABAC policy can enforce visibility.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate row filter binding	Catalog Explorer > table > Permissions or supported SQL policy inspection	Table shows the expected row filter association
Validate column mask binding	Catalog Explorer > table > Columns	Sensitive column shows mask policy or masking function
Validate ABAC tags	Catalog Explorer > object > Tags	Required governed tags exist with expected values
Validate user-specific output	Run the same filtered query as two test principals	Rows or masked values differ according to policy intent

Authenticate secrets and Azure resource access from Azure Databricks

Exam Radar

• Core Priority: Secret and Azure resource access questions test the identity hop between Databricks code, Key Vault, Unity Catalog storage credentials, and Azure RBAC.
• High Frequency: Expect Azure Key Vault-backed secret scopes, service principals, managed identities, storage credentials, external locations, token audience, and ADLS Gen2 permissions.
• Confusion Alert: Do not fix a Key Vault or storage-identity failure by changing table SELECT grants or cluster size.
• Scenario Logic: Separate secret retrieval from resource authorization: a notebook may read a secret but still fail because the storage credential identity lacks Azure permissions.
• Version Delta: This topic remains in the Microsoft DP-750 skills measured from March 11, 2026 under Secure and govern Unity Catalog objects; answer choices should use current Azure Databricks, Unity Catalog, Lakeflow, Azure Monitor, and Microsoft Entra terminology.
• Failure Trigger: The failure appears as secret not found, permission denied, token audience mismatch, external location validation failure, or storage read denial.
• Operational Dependency: Secret scope access, Key Vault permission, service-principal or managed-identity role assignment, storage credential, and external location URL must match.
• How the Exam Asks It: The exam asks which identity or secret boundary to inspect before changing the data object.
• How Distractors Are Designed: Wrong answers broaden Unity Catalog table grants, resize compute, or rotate secrets before proving the identity and path.
• Why the Correct Answer Works: The correct answer validates the identity chain and confirms read-only access through the intended credential.

Practice Question: A notebook can read a secret name but cannot access ADLS Gen2 data through a Unity Catalog external location. Which dependency should be checked before changing table grants?
A. The storage credential identity and its Azure role assignment on the storage path.
B. The number of worker nodes on the cluster.
C. The table's column comments.
D. The SQL warehouse auto-stop setting.
Correct Answer: A.
Explanation: A is correct because external data access depends on the storage credential identity and cloud permission. B is capacity. C is discovery metadata. D is SQL serving behavior. Exam Takeaway: Select the object that owns the dependency; the distractor pattern is an adjacent Databricks feature that is technically real but does not satisfy the scenario's first blocking condition.

Atomic Deconstruction - Operational Level

Security topics must be decomposed from parent scope to leaf access. Unity Catalog authorizes traversal first, then object action, then fine-grained policy. Azure resource access adds a separate identity plane through Key Vault, service principals, managed identities, storage credentials, and cloud RBAC.

A correct answer does not simply grant more access. It names the missing permission or identity hop: USE CATALOG before table SELECT, READ VOLUME before file access, Key Vault permission before secret lookup, storage credential role before external location reads, or row/column policy before data is exposed.

The practical habit is to test with two principals: one that should succeed and one that should be restricted. This catches the common DP-750 distractor where a broad workspace or admin grant appears to fix the symptom but destroys the governance requirement.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Secret scope	Secret lookup boundary	Databricks-backed or Azure Key Vault-backed	No scope until configured	Key Vault permission and workspace scope access	Notebook cannot retrieve required secret
Azure Key Vault secret	Secret URI and version	Current or versioned secret value	Stored outside Databricks if AKV-backed	Vault access policy or RBAC and network path	Secret lookup returns permission or not-found error
Service principal	Application identity	Client ID, tenant ID, secret or certificate	No data access by default	Azure role assignment and secret availability	Storage access fails despite valid notebook code
Managed identity	Azure resource identity	System-assigned or user-assigned where supported	Not available unless configured	Workspace/resource support and Azure role assignment	Token request succeeds for wrong audience or role is missing
Storage credential	Unity Catalog data identity	Managed identity or service principal-backed credential	Absent until created	External location and cloud storage permission	External table or volume access fails

Step-by-Step Execution Path

1. Separate secret retrieval from resource authorization; a retrieved secret does not prove the identity can access storage.
2. Validate Azure Key Vault access when the scenario names secret lookup, vault URI, secret version, or network restrictions.
3. Validate service principal or managed identity role assignment when the failure occurs at the Azure resource boundary.
4. Inspect the Unity Catalog storage credential and external location when tables or volumes reference cloud storage.
5. Run a read-only test against the target path or table with the intended principal.
6. Use audit logs or Azure activity evidence to distinguish missing secret, wrong token audience, blocked network path, and missing RBAC.

Exam implementation pattern:

• When to use: a notebook or job must retrieve secrets, authenticate to Azure storage, or access Azure resources with a service principal or managed identity.
• Minimal syntax: validate secret scope, Key Vault permission, storage credential, external location, and cloud RBAC before changing table grants.
• What to verify: secret lookup path, storage credential identity, Azure role assignment, external location URL, and read-only data access.
• Common wrong answer: granting SELECT on a table when the blocked dependency is Key Vault, token, or storage identity.

Command confidence note: Commands shown in this section are verification-oriented examples. Validate exact Databricks CLI syntax against the active CLI and workspace version before using it as an authoritative production procedure.

Technical Chain

The chain starts with identity resolution: Azure Databricks maps the user, group, or service principal to Unity Catalog privileges or external Azure resource permissions.

Unity Catalog then evaluates parent namespace traversal, object action, and fine-grained policy. For external storage, the storage credential or managed identity must also be authorized on the cloud resource. A failure at any hop can look like a table problem even when the table definition is correct.

Correct remediation changes the failed hop and preserves auditability. Broad workspace admin grants can mask the failure, but they do not prove the securable object or cloud resource was governed correctly.

Exam Trap Summary: Do not change table grants before proving Key Vault, token, storage credential, and Azure RBAC dependencies.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate secret scope	Azure Databricks workspace > Secret scopes; or active-version CLI: databricks secrets list-scopes	Scope exists and matches the intended backing store
Validate storage credential	Catalog Explorer > External Data > Storage Credentials	Credential uses the expected managed identity or service principal
Validate external location	Catalog Explorer > External Data > External Locations	Location URL and credential match target storage
Validate data access	Read-only notebook or SQL query against the external table or volume	Access succeeds without granting broad workspace admin rights

Govern data discovery, lineage, audit logging, retention, and Delta Sharing

Exam Radar

• Core Priority: Governance-evidence questions test whether discovery, lineage, audit events, retention, and Delta Sharing produce inspectable proof.
• High Frequency: Expect table and column descriptions, lineage graph, audit log routing, retention settings, shares, recipients, and provider/consumer boundaries.
• Confusion Alert: Do not use internal workspace permissions when the requirement is external sharing, auditability, or impact analysis.
• Scenario Logic: Choose the governance evidence object first: lineage for dependency impact, audit logs for investigation, retention for compliance, and Delta Sharing for external read-only access.
• Version Delta: This topic remains in the Microsoft DP-750 skills measured from March 11, 2026 under Secure and govern Unity Catalog objects; answer choices should use current Azure Databricks, Unity Catalog, Lakeflow, Azure Monitor, and Microsoft Entra terminology.
• Failure Trigger: The failure appears as missing event trails, unknown downstream consumers, overshared partner data, expired history, or undocumented objects that consumers cannot trust.
• Operational Dependency: Diagnostic settings, supported lineage-producing operations, table metadata, retention policy, share object, and recipient configuration must be present.
• How the Exam Asks It: The exam asks which governance object proves or controls the data lifecycle rather than which compute runs a workload.
• How Distractors Are Designed: Wrong answers tune clusters, export CSV files, or rely on notebook comments where governed evidence is required.
• Why the Correct Answer Works: The correct answer selects the governance record or sharing object and verifies it in Catalog Explorer, audit destination, or recipient state.

Practice Question: An external partner needs read-only access to curated Delta tables without receiving workspace credentials. What should be designed?
A. A Delta Sharing provider share and recipient configuration.
B. A cluster policy that allows partner users to attach.
C. A notebook that exports CSV files with no audit trail.
D. A row-level filter on an internal-only table without sharing.
Correct Answer: A.
Explanation: A is correct because Delta Sharing separates provider and recipient access without workspace login. B grants workspace-level interaction. C loses governance. D may filter rows internally but does not deliver external sharing. Exam Takeaway: Select the object that owns the dependency; the distractor pattern is an adjacent Databricks feature that is technically real but does not satisfy the scenario's first blocking condition.

Atomic Deconstruction - Operational Level

Governance evidence across descriptions, lineage, audit events, retention rules, and external sharing must be studied as a concrete Azure Databricks operating path: identify the owning object, the prerequisite state, the change mechanism, and the verification signal.

The correct action is the smallest action that changes the controlling dependency while preserving governance, repeatability, and observable evidence.

Wrong options usually name real features at the wrong layer, so the learner should eliminate any option that skips parent scope, identity, data-state, run-state, or monitoring proof.

Component Specifications

Object	Attribute	Value Range	Default State	Dependency	Failure State
Audit log	Operational event stream	Workspace, account, or supported diagnostic destination	Not always configured for downstream analysis	Diagnostic settings and storage or Log Analytics destination	Access changes cannot be investigated
Lineage record	Dependency graph	Upstream and downstream object links	Generated by supported operations	Query or pipeline execution with lineage support	Impact analysis misses consumers
Retention policy	Lifecycle rule	Time-based data or log retention	Service default or table property dependent	Compliance requirement and table history behavior	Data is retained too long or removed before audit need
Delta Sharing share	Provider-side package	Tables, views, or notebooks supported by sharing	No share	Recipient and object eligibility	External consumer cannot access shared data
Recipient	External sharing identity	Open or Databricks-to-Databricks recipient model	No recipient	Sharing credential and network/account trust	Data is overshared or unreachable

Step-by-Step Execution Path

1. Identify whether the scenario requires internal governance evidence or external data sharing.
2. For investigation scenarios, configure and validate audit logging before relying on retrospective analysis.
3. For impact analysis, inspect lineage in Catalog Explorer and confirm supported pipeline or query execution has produced lineage.
4. For compliance retention, map the retention rule to table history, log destination, or storage lifecycle rather than a generic backup setting.
5. For external consumption, create or inspect the Delta Sharing share, recipient, and shared object list.
6. Validate the consumer path with read-only access evidence and confirm no workspace credential was required.

Exam implementation pattern:

• When to use: the scenario names data discovery definitions, ABAC tags, row/column policy governance, retention, lineage, audit logging, or Delta Sharing.
• Minimal syntax: configure the governance object, then verify it in Catalog Explorer, diagnostic settings, Delta Sharing provider/recipient pages, or audit destination.
• What to verify: table/column descriptions, tag and policy binding, retention setting, lineage graph, audit event route, and recipient/share scope.
• Common wrong answer: changing compute or table format when the requirement is governance evidence.

Command confidence note: Commands shown in this section are verification-oriented examples. Validate exact Databricks CLI syntax against the active CLI and workspace version before using it as an authoritative production procedure.

Technical Chain

The chain starts with identity resolution: Azure Databricks maps the user, group, or service principal to Unity Catalog privileges or external Azure resource permissions.

Unity Catalog then evaluates parent namespace traversal, object action, and fine-grained policy. For external storage, the storage credential or managed identity must also be authorized on the cloud resource. A failure at any hop can look like a table problem even when the table definition is correct.

Correct remediation changes the failed hop and preserves auditability. Broad workspace admin grants can mask the failure, but they do not prove the securable object or cloud resource was governed correctly.

Exam Trap Summary: Do not export CSV files or grant workspace access when Delta Sharing, audit logs, lineage, or retention records are the evidence requirement.

Operational Skills Matrix

Task	Precise Command or Path	Verification Standard
Validate audit destination	Azure portal > Diagnostic settings for the Databricks resource or account-level audit configuration	Audit events are routed to the approved destination
Validate lineage graph	Catalog Explorer > target object > Lineage	Expected upstream and downstream objects are visible
Validate shared objects	Catalog Explorer > Delta Sharing > Shares	Share contains only approved objects
Validate recipient access	Catalog Explorer > Delta Sharing > Recipients	Recipient status and credential model match the partner scenario