Free Microsoft DP-750 Practice Questions: Secure and Govern Unity Catalog Objects

Topic snapshot

Sample questions

These are original IT Mastery practice questions aligned to this topic area. They are not official Microsoft questions, copied live-exam content, or exam dumps. Use them for self-assessment, scope review, and deciding what to drill next.

Question 1

Topic: Secure and Govern Unity Catalog Objects

A finance team stores payroll data in the Unity Catalog table finance.prod.payroll. Analysts must query this same table directly from notebooks and SQL warehouses. They should see only rows for their assigned region, and employee_ssn must be masked unless the user is in payroll_pii_readers. The team must avoid copying or maintaining duplicate tables. Which implementation should you use?

Options:

• A. Grant access only through region-specific views.

• B. Create separate Delta tables for each region.

• C. Write masked regional outputs from a Lakeflow pipeline.

• D. Add a row filter and column mask to the table.

Best answer: D

Explanation: Unity Catalog row filters and column masks are designed for fine-grained access control on shared tables. A row filter can restrict visible payroll rows based on the querying principal, such as a user-to-region mapping. A column mask can return the real employee_ssn only for members of payroll_pii_readers and a masked value for other users. Because these controls are attached to the governed table, users can continue querying the same object from notebooks or SQL warehouses while access rules are enforced consistently. Creating regional tables or pre-masked outputs adds unnecessary data duplication and operational overhead.

• Regional tables duplicate governed data and create maintenance risk when regions or source records change.
• Pipeline masking permanently changes the written output and does not support different visibility by querying principal.
• Region-specific views can filter access, but they do not satisfy the requirement to query the same table directly.

Question 2

Topic: Secure and Govern Unity Catalog Objects

A Unity Catalog governance validation job checks whether protected tables have required descriptions and tags. The job runs as spn-governance-audit and reports that finance.secure.payroll has no sensitivity tag, but the table owner confirms the tag exists.

Validation principal: spn-governance-audit
Observed result: no tag row returned for finance.secure.payroll
Owner check: sensitivity=restricted is present
Current grants for spn-governance-audit:
- USE CATALOG on finance
- no USE SCHEMA on secure
- no SELECT on finance.secure.payroll

What is the best next diagnostic step?

Options:

• A. Transfer table ownership to the validation principal

• B. Replace the Unity Catalog tag with a table property

• C. Check metadata visibility privileges on the schema

• D. Grant SELECT on the payroll table

Best answer: C

Explanation: Unity Catalog metadata and tags support governance workflows, but they still respect object ownership and access boundaries. A validation job can return incomplete results if its principal cannot discover the relevant catalog, schema, or object metadata. In this case, the owner can see the tag, while the validation principal lacks USE SCHEMA on the schema and has no table access. The next diagnostic step is to verify the principal’s metadata visibility path before changing the table. The goal is not to bypass governance by transferring ownership or granting data read access; it is to ensure the validation process has the minimum discovery permissions needed to inspect metadata.

• Ownership transfer is excessive because the job needs metadata discovery, not control of the table.
• SELECT access is not required merely to validate tags and would expand data access unnecessarily.
• Table properties are not a replacement for Unity Catalog tags used in governance workflows.

Question 3

Topic: Secure and Govern Unity Catalog Objects

A notebook job was changed to create a Delta Sharing share for prod.sales.orders after internal analysts received PERMISSION_DENIED: User does not have SELECT on table prod.sales.orders. All analysts use Azure Databricks workspaces attached to the same Unity Catalog metastore. The requirement is to allow only regional groups to query rows for their region. The share does not fix the notebook error. What is the best diagnostic conclusion?

Options:

• A. Convert the table to an external table

• B. Add discovery tags to the shared table

• C. Diagnose Unity Catalog grants and row filters

• D. Create a Delta Sharing recipient per region

Best answer: C

Explanation: Delta Sharing is designed for sharing data with external consumers or across sharing boundaries, not for fixing internal Unity Catalog permission errors. Here, the users are internal principals in workspaces attached to the same metastore, and the error explicitly says they lack SELECT on the table. The row-level requirement also points to Unity Catalog governance, such as grants combined with row filters or governed views. The next diagnostic step is to inspect internal privileges and row-restriction configuration, not recipient or share setup. Metadata improvements, such as tags or comments, can help discovery but do not grant access or enforce row-level filtering.

• Recipient setup fails because recipients are for Delta Sharing consumers, while the users are internal Unity Catalog principals.
• External table conversion is not required to resolve a missing SELECT privilege or enforce regional row access.
• Discovery tags can improve findability, but they do not correct permissions or row-level restrictions.

Question 4

Topic: Secure and Govern Unity Catalog Objects

A Lakeflow Job runs a notebook on job compute to ingest data from a partner REST API into a Unity Catalog managed table. The API token is rotated by the security team in Azure Key Vault, and the job is deployed from Git by using Databricks Asset Bundles. How should the token be implemented?

Options:

• A. Set the token as a Spark configuration value on job compute.

• B. Save the token in a restricted Unity Catalog volume file.

• C. Use an Azure Key Vault-backed secret scope and read the token at runtime.

• D. Store the token as a Databricks Asset Bundle variable.

Best answer: C

Explanation: Sensitive credentials for Azure Databricks workloads should be stored in a secret store, not in Git, bundle configuration, table data, volume files, or cluster settings. In this scenario, Azure Key Vault owns rotation, so a Key Vault-backed Databricks secret scope is the appropriate bridge. The notebook can reference the token at runtime, for example with dbutils.secrets.get(scope, key), while access to the scope is limited to the job’s authorized principal. This preserves separation between deployment artifacts and secret values.

• Bundle variable fails because bundle files and deployment parameters are not a secret-management boundary.
• Volume file fails because Unity Catalog storage permissions protect data objects, but a plain file is not the right place for credentials.
• Spark configuration fails because job or cluster configuration can expose sensitive values to users with compute or job visibility.

Question 5

Topic: Secure and Govern Unity Catalog Objects

A Lakeflow Job owned by service principal spn-curated-orders began failing after a governed tag was applied in Unity Catalog. The job reads main.raw.orders and writes main.curated.orders_clean.

Diagnostic evidence:

What is the best root cause?

Options:

• A. The curated table has an incompatible schema change

• B. The data retention policy deleted the source files

• C. The service principal is missing a table SELECT grant

• D. The ABAC rule excludes the ETL service principal

Best answer: D

Explanation: Unity Catalog privileges and ABAC controls are evaluated together. The service principal already has SELECT, so the failed read is not explained by a missing object grant. The visible error says the denial came from the ABAC policy, and the policy only allows principals with purpose=analytics or break_glass=true. The job principal has department=engineering and workload=etl, which do not satisfy that rule. To preserve governance without breaking legitimate data engineering, the policy should include the approved ETL principal attribute or group rather than bypassing the control entirely.

• Missing grant is tempting because reads require SELECT, but the exhibit already shows that grant exists.
• Retention deletion does not match the permission-denied error or the ABAC policy evidence.
• Schema change would surface as a schema or write failure, not an ABAC access denial on the source read.

Question 6

Topic: Secure and Govern Unity Catalog Objects

A data engineering team must let Azure Databricks read and write files in an ADLS Gen2 account through Unity Catalog external locations. The security requirement states that the configuration must use Azure-integrated authentication and must not store client secrets, keys, or passwords in Databricks. Which configuration should the team use?

Options:

• A. Use an Azure Key Vault-backed secret scope for a service principal secret.

• B. Store a SAS token in a notebook parameter for the job.

• C. Create a Unity Catalog storage credential backed by an Azure managed identity.

• D. Create a Databricks secret scope that stores the storage account key.

Best answer: C

Explanation: Managed identities are the best fit when Azure Databricks needs Azure-integrated access without stored credentials. For Unity Catalog external locations on ADLS Gen2, a storage credential can be configured to use an Azure managed identity, commonly through an Azure Databricks access connector. This lets Azure control authentication and authorization while avoiding client secrets, storage keys, SAS tokens, or passwords in Databricks. Secret scopes and Azure Key Vault can reduce exposure of stored secrets, but they still rely on a stored credential. The key distinction is whether the design eliminates stored credentials, not merely hides them.

• Storage account key fails because it is a stored credential and is broader than needed.
• Key Vault secret fails because it protects a service principal secret but still stores and rotates a credential.
• SAS token parameter fails because SAS tokens are credentials and notebook parameters are not an appropriate secret store.

Question 7

Topic: Secure and Govern Unity Catalog Objects

A Lakeflow Job in Azure Databricks must run nightly without depending on a human user. The job reads Unity Catalog tables and calls an external SaaS API that requires a static API token. Security requires the token to be centrally rotated in Azure Key Vault and not stored in notebooks or job parameters. Which configuration should you choose?

Options:

• A. Run as a service principal and read the token from an Azure Key Vault-backed secret scope

• B. Run as a service principal and store the API token in a Unity Catalog table

• C. Run as a managed identity and pass the API token as a job parameter

• D. Run as a workspace user and read the token from an Azure Key Vault-backed secret scope

Best answer: A

Explanation: Use separate mechanisms for identity and secret storage. A service principal is the appropriate non-human principal for owning or running an automated Azure Databricks job and can be granted the required Unity Catalog privileges. A secret, preferably backed by Azure Key Vault, is used to store sensitive values such as a SaaS API token so the value is not embedded in code or job configuration. A managed identity is useful for Azure resource access patterns that support identity-based authentication, but it does not replace a required static API token for an external service.

• Managed identity misuse fails because the SaaS API still requires a static token, and passing it as a job parameter exposes it in job configuration.
• Human owner dependency fails because the job must not depend on a workspace user’s identity.
• Table as secret store fails because Unity Catalog tables are data objects, not a secure secret-management mechanism.

Question 8

Topic: Secure and Govern Unity Catalog Objects

A team curates a Unity Catalog table named prod.gold.customer_orders in Azure Databricks. An external partner must query the governed data from their own analytics tools, must not receive workspace access, and the team wants to avoid scheduled exports or duplicate data copies. Which implementation should the team use?

Options:

• A. Create a Delta Sharing share and recipient for the table

• B. Grant the partner service principal SELECT on the table

• C. Export the table nightly to the partner’s storage account

• D. Create a shared cluster for the partner’s analysts

Best answer: A

Explanation: Delta Sharing is designed for governed data sharing with external consumers. In Unity Catalog, the provider creates a share, adds the approved table or view, creates a recipient, and gives the recipient the sharing profile or Databricks-to-Databricks access. The partner can query the shared data from supported tools without being added to the provider’s workspace and without the provider building export pipelines or duplicate datasets.

Granting table privileges is appropriate for internal principals in the same governance boundary, not independent external consumers. Scheduled exports and shared compute both weaken the stated requirement to avoid copies and workspace access.

• Direct table grant fails because it assumes the partner is an internal Unity Catalog principal with access to the provider environment.
• Nightly export fails because it creates a duplicate copy and adds a scheduled data movement process.
• Shared cluster access fails because it gives the partner workspace compute access, which the scenario explicitly avoids.

Question 9

Topic: Secure and Govern Unity Catalog Objects

A Lakeflow Jobs task in Azure Databricks retrieves a database password with dbutils.secrets.get("kv-prod", "sql-password") from an Azure Key Vault-backed secret scope. The notebook succeeds when run interactively by a developer, but the scheduled job fails after its Run as identity is changed to the service principal spn-etl-prod.

Error excerpt:

PERMISSION_DENIED: Principal spn-etl-prod does not have READ permission on secret scope kv-prod

What is the most likely root cause?

Options:

• A. The Key Vault secret was rotated

• B. The Unity Catalog table grant is missing

• C. The service principal lacks READ on the secret scope

• D. The secret value must be embedded in the notebook

Best answer: C

Explanation: Azure Databricks secret access is evaluated for the identity running the workload. In this case, the developer can read the Azure Key Vault-backed secret scope, but the scheduled job now runs as spn-etl-prod. The error specifically identifies that service principal and the missing READ permission on the secret scope. Granting the workload identity access to the Databricks secret scope allows governed retrieval without placing credentials in notebook code. This is separate from Unity Catalog table access and separate from whether the secret value itself changed.

• Embedding credentials is the opposite of governed secret retrieval and is not required to fix scope access.
• Table grants control data objects in Unity Catalog, not reading a Databricks secret scope.
• Secret rotation would not explain an explicit missing READ permission for the run-as principal.

Question 10

Topic: Secure and Govern Unity Catalog Objects

A Unity Catalog table prod.sales.customer_orders contains customer_email, region, and order details. The analysts group must query the table for all regions, but only members of pii_readers may see actual email addresses. Other analysts must see a redacted value. The team must avoid duplicating the table or maintaining separate views. Which implementation best meets the requirement?

Options:

• A. Attach a column mask on customer_email

• B. Attach a row filter on region

• C. Grant SELECT only to pii_readers

• D. Move email values to a separate table

Best answer: A

Explanation: Unity Catalog column masks are the decisive control when users should query the same table and rows but see different values for a sensitive column. In this scenario, all analysts need access to all order rows, so restricting table access or filtering rows would not meet the reporting requirement. A mask on customer_email can return the real value for pii_readers and a redacted value for other users, without duplicating data or creating separate views. Row filters are for controlling which rows are visible; table privileges control access to the object as a whole.

• Object-only access fails because granting SELECT only to pii_readers blocks other analysts from the table.
• Row filtering fails because the requirement is to hide email values, not remove rows or regions.
• Separate storage fails because it duplicates governance and violates the requirement to avoid maintaining separate objects.

Continue in the web app

Use IT Mastery for interactive Microsoft DP-750 practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.

Try Microsoft DP-750 on Web

Related focused pages

• Free Microsoft DP-750 Full-Length Practice Exam
• Set Up and Configure an Azure Databricks Environment
• Prepare and Process Data
• Deploy and Maintain Data Pipelines and Workloads