Free DP-750 Practice Questions: Set Up and Configure an Azure Databricks Environment
Practice 10 free Microsoft Certified: Azure Databricks Data Engineer Associate (Microsoft DP-750) questions on Set Up and Configure an Azure Databricks Environment, with answers, explanations, and the IT Mastery next step.
Try the IT Mastery web app for a richer interactive practice experience with mixed sets, timed mocks, topic drills, explanations, and progress tracking.
Topic snapshot
| Field | Detail |
|---|---|
| Exam route | Microsoft DP-750 |
| Topic area | Set Up and Configure an Azure Databricks Environment |
| Blueprint weight | 18% |
| Page purpose | Focused sample questions before returning to mixed practice |
How to use this topic drill
Use this page to isolate Set Up and Configure an Azure Databricks Environment for Microsoft DP-750. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 18% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
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: Set Up and Configure an Azure Databricks Environment
A team must let analysts query customer reference tables that remain in an externally managed Azure SQL Database. The data must not be copied into Delta tables, credentials must not appear in notebooks, and access must be governed through Unity Catalog grants. Which implementation should the data engineer use?
Options:
A. Store the JDBC password in each analyst notebook and query with PySpark.
B. Create a Unity Catalog connection and foreign catalog, then grant catalog/schema/table privileges.
C. Create a volume that points to the Azure SQL Database endpoint.
D. Use
COPY INTOto load the Azure SQL tables into managed Delta tables.
Best answer: B
Explanation: Foreign catalogs are used when Azure Databricks needs governed access to data that remains cataloged in an external system. The implementation creates a Unity Catalog connection that stores the connection details and credentials, then creates a foreign catalog from that connection. Users can query the external objects through Unity Catalog names, and administrators can apply grants such as USE CATALOG, USE SCHEMA, and SELECT without putting credentials in notebooks. This preserves the external system as the source of truth instead of ingesting the data into Delta tables.
- Copying data fails because
COPY INTOingests data into Databricks, violating the no-copy requirement. - Notebook credentials fail because per-notebook JDBC secrets bypass centralized Unity Catalog governance.
- Volume mapping fails because volumes govern file-based storage, not relational foreign catalogs.
Question 2
Topic: Set Up and Configure an Azure Databricks Environment
A data engineering team is building an Azure Databricks notebook that must be run interactively by several developers. The notebook queries Unity Catalog tables and imports a custom Python wheel used for transformations. The team wants the package available whenever the notebook is attached, without adding %pip install commands to the notebook. Which configuration should be used?
Options:
A. Use UC-enabled all-purpose compute, grant
Can Attach To, and install the wheel as a compute library.B. Use job compute with the wheel configured only on the job task.
C. Grant Unity Catalog table privileges and leave the wheel uninstalled.
D. Use a SQL warehouse and upload the wheel as a warehouse library.
Best answer: A
Explanation: For interactive notebook development, the notebook must attach to compute that developers are allowed to use. Because the notebook queries Unity Catalog objects, the compute must support Unity Catalog access, and users also need the appropriate data privileges. Because the custom wheel is required by the notebook and should not be installed with notebook commands each time, installing it as a compute-scoped library makes it available whenever the notebook attaches to that compute. Job-only library configuration is useful for production task runs, but it does not satisfy shared interactive development by itself.
- SQL warehouse mismatch fails because SQL warehouses are for SQL workloads, not PySpark notebooks that import custom Python wheels.
- Job-only dependency fails because it supports a scheduled task run, not several developers attaching notebooks interactively.
- Privileges only fails because Unity Catalog access does not provide the required Python package dependency.
Question 3
Topic: Set Up and Configure an Azure Databricks Environment
A company is enabling Unity Catalog for two data domains: Finance and Marketing. Each domain has separate owners for dev and prod, and each owner must manage objects independently within that environment. Within each boundary, tables should be grouped by workload stage such as raw, curated, and reporting. Which catalog and schema layout should you configure?
Options:
A. Create catalogs for raw, curated, and reporting, with schemas for each domain and environment.
B. Create one catalog per domain and environment, with workload-stage schemas inside each catalog.
C. Create one catalog per table group, with all schemas shared across Finance and Marketing.
D. Create one shared catalog, with schemas named for each domain, environment, and workload stage.
Best answer: B
Explanation: Unity Catalog uses a three-level namespace: catalog, schema, and object. Catalogs are the right top-level boundary when ownership, environment separation, or broad workload isolation must be managed independently. In this scenario, Finance dev, Finance prod, Marketing dev, and Marketing prod each need independent management, so each should be represented as a separate catalog. Schemas inside those catalogs can then group related objects by workload stage, such as raw, curated, and reporting. This keeps ownership and environment boundaries clear without overloading schemas with every governance concern.
- Single shared catalog weakens the requested independent top-level ownership and environment boundaries.
- Stage-based catalogs make raw and curated the main boundary, not the domain and environment owners.
- Table-group catalogs create unnecessary catalog sprawl and do not clearly separate Finance from Marketing.
Question 4
Topic: Set Up and Configure an Azure Databricks Environment
A Lakeflow Job task that runs a PySpark notebook started failing immediately after the platform team updated the cluster policy used by the job compute. The notebook code, libraries, and Unity Catalog grants were not changed.
Failed run evidence:
| Item | Value |
|---|---|
| Error | Unsupported Spark major version: 4.0 |
| Connector note | Supports Spark 3.5 only |
| Previous successful runtime | Databricks Runtime 15.4 LTS, Spark 3.5 |
| Failed run runtime | Databricks Runtime 16.0, Spark 4.0 |
What is the best root cause?
Options:
A. Photon acceleration changed the connector permissions
B. The cluster policy allowed an incompatible runtime upgrade
C. Autoscaling reduced the number of executor nodes
D. Unity Catalog revoked access to the source table
Best answer: B
Explanation: Runtime compatibility is the deciding signal. The failed run changed from Databricks Runtime 15.4 LTS with Spark 3.5 to Databricks Runtime 16.0 with Spark 4.0, and the connector message states that only Spark 3.5 is supported. When workload compatibility depends on the runtime environment, the job compute or cluster policy should be checked for runtime selection behavior, such as using the latest available runtime instead of pinning a supported LTS runtime. The fix would be to configure the job compute or policy to use a compatible Databricks Runtime/Spark version until the connector supports the newer version.
- Photon permission issue is not supported because the visible error is a Spark version compatibility message, not an authorization failure.
- Autoscaling issue does not fit because the job fails immediately with an unsupported version, not from resource starvation.
- Unity Catalog access is unlikely because the grants were unchanged and the error does not mention denied access or missing privileges.
Question 5
Topic: Set Up and Configure an Azure Databricks Environment
A data engineering team is configuring a production Lakeflow Jobs task that runs a PySpark notebook with Delta Lake MERGE operations each night. Workspace governance requires production workloads to use the Prod-ETL cluster policy, which enforces an approved runtime, Unity Catalog-compatible access mode, a maximum of 10 workers, and approved library sources. The workload typically needs 2 to 8 workers and benefits from Photon. Which compute configuration should the team use?
Options:
A. Job compute using
Prod-ETL, autoscaling 2–8 workers, Photon enabledB. All-purpose classic compute with unrestricted settings and Photon enabled
C. Job compute without a policy and fixed 16 workers
D. Serverless SQL warehouse for the PySpark notebook task
Best answer: A
Explanation: Production job compute should satisfy the workload requirements while staying inside workspace governance controls. In this scenario, the approved cluster policy is the governance boundary: it enforces the runtime, Unity Catalog-compatible access mode, worker maximum, and library sources. Configuring job compute with that policy, autoscaling from 2 to 8 workers, and Photon enabled matches the workload pattern without exceeding the policy’s 10-worker cap or bypassing required controls. The key distinction is that compute flexibility is acceptable only within the policy’s allowed range; unrestricted or oversized compute may run the workload but violates governance.
- Unrestricted all-purpose compute may support interactive work, but it bypasses the required production cluster policy.
- No-policy fixed compute violates governance and exceeds the stated maximum worker limit.
- SQL warehouse compute is not the right target for a PySpark notebook task in Lakeflow Jobs.
Question 6
Topic: Set Up and Configure an Azure Databricks Environment
A data engineering team deploys a Lakeflow Jobs workflow to run a PySpark notebook on job compute. The task fails before the notebook starts.
Exhibit: Run error and job compute settings
Run state: FAILED
Message: Cluster creation failed.
Policy validation error: node_type_id 'Standard_NC8as_T4_v3' is not allowed by policy 'etl-job-compute'.
Job compute:
runtime: 15.4 LTS
workers: 2-8
node_type_id: Standard_NC8as_T4_v3
What is the best root cause?
Options:
A. Photon is incompatible with the notebook code
B. The notebook lacks Unity Catalog table privileges
C. Autoscaling is underprovisioned for the workload
D. The job compute violates its cluster policy
Best answer: D
Explanation: The visible error is a compute provisioning failure, not a notebook execution failure. Azure Databricks validates job compute against any assigned cluster policy before starting the cluster. Because the policy rejects the requested node_type_id, the task cannot launch and the notebook never runs. The next fix is to choose a node type allowed by the etl-job-compute policy or have an administrator update the policy if that node type is required.
Unity Catalog, autoscaling, and Photon issues would typically appear after compute starts or in query/runtime behavior, not as a policy validation error during cluster creation.
- Unity Catalog privileges do not fit because the notebook did not start or attempt to access tables.
- Autoscaling capacity is not indicated; the error names a disallowed
node_type_id, not worker exhaustion. - Photon compatibility is unsupported by the evidence and is not mentioned in the failing compute settings.
Question 7
Topic: Set Up and Configure an Azure Databricks Environment
A data engineering team is designing Unity Catalog objects for a new Azure Databricks workspace. They need separate top-level namespaces for Sales and Finance, separate Bronze/Silver/Gold areas inside each namespace, managed Delta datasets, a reusable query projection without copying data, a maintained precomputed aggregate, storage for source JSON files that are not tables, and access to an external PostgreSQL database through Lakehouse Federation. Which configuration best matches these responsibilities?
Options:
A. Catalogs for each dataset, volumes for Delta datasets, views for aggregates, and schemas for external databases
B. One catalog, tables for all files and projections, schemas for aggregates, and a volume for PostgreSQL access
C. Catalogs for domains, schemas for layers, tables, views, materialized views, volumes, and a foreign catalog
D. Schemas for domains, catalogs for layers, tables, views, volumes, and a materialized view for PostgreSQL access
Best answer: C
Explanation: Unity Catalog uses a three-level namespace of catalog, schema, and object. A catalog is the top-level container, often aligned to domains or environments, and schemas organize related objects within a catalog, such as Bronze, Silver, and Gold layers. Tables store structured data such as managed Delta datasets. Views provide reusable logical projections without copying data. Materialized views store and maintain precomputed query results for repeated access patterns. Volumes are for non-tabular files governed by Unity Catalog, and foreign catalogs represent external data systems exposed through Lakehouse Federation. The key is to choose the object type based on what is being organized or accessed, not to make one object type serve every purpose.
- Reversed namespace levels fails because catalogs are the top-level containers, while schemas sit inside catalogs.
- Tables for all assets fails because non-tabular files belong in volumes and logical projections belong in views.
- Volumes for Delta datasets fails because structured Delta datasets should be tables, not file-only storage objects.
Question 8
Topic: Set Up and Configure an Azure Databricks Environment
A data engineering team maintains sales.orders and sales.customers in Unity Catalog. Analysts need a reusable SQL object in the reporting schema that standardizes a join and filter logic, reflects current data from the underlying tables, and does not persist a separate result set. Which configuration should the team implement?
Options:
A. Create a managed Delta table with CTAS
B. Create a materialized view in
reportingC. Create a Unity Catalog view in
reportingD. Create a foreign catalog for the source tables
Best answer: C
Explanation: A Unity Catalog view is the right object when users need a reusable logical query definition over one or more underlying tables. The view stores the SQL definition, not a separate copy of the query results, so queries against it evaluate the underlying tables and can reflect current source data. This fits the requirement to centralize join and filter logic for analysts without creating another persisted dataset. A materialized view is useful when precomputed results and refresh behavior are desired, but that adds persisted results and maintenance semantics that the scenario explicitly does not need.
- Materialized view is tempting for reuse, but it stores precomputed results rather than only a logical query definition.
- Managed CTAS table creates a separate persisted Delta table, which violates the no-copy requirement.
- Foreign catalog is for exposing external data sources, not for defining reusable SQL logic over existing Unity Catalog tables.
Question 9
Topic: Set Up and Configure an Azure Databricks Environment
A team publishes an object for analysts in Unity Catalog. Analysts must receive access only to the published object, and the dashboard workload must use a precomputed aggregate that the pipeline can refresh.
Exhibit: DDL and job symptom
CREATE VIEW analytics.reporting.qtr_revenue AS
SELECT region, date_trunc('quarter', order_date) AS qtr, sum(amount) AS revenue
FROM prod.sales.orders
GROUP BY region, date_trunc('quarter', order_date);
GRANT SELECT ON VIEW analytics.reporting.qtr_revenue TO `analyst_group`;
Pipeline step: REFRESH MATERIALIZED VIEW analytics.reporting.qtr_revenue fails because the object cannot be refreshed as a materialized view.
What is the best root cause?
Options:
A. The object was created as a standard view, not a materialized view.
B. The object should be created as a volume for governed access.
C. The aggregate query requires a foreign catalog to refresh.
D. The object is missing a
GRANT SELECTon the base table.
Best answer: A
Explanation: The DDL defines a standard view, which stores a query definition and evaluates against underlying data when queried. That can be useful for governed abstraction, because analysts can be granted access to the view instead of the base table. However, the processing requirement says the dashboard must use a precomputed aggregate that the pipeline can refresh. That requirement points to a materialized view, which stores computed results and supports refresh behavior. The failed REFRESH MATERIALIZED VIEW step matches the visible mismatch: the object name exists, but its object type is not materialized view. The fix is to create the object with materialized view DDL, not to change grants or storage location.
- Base-table grant is not indicated by the symptom; the failure is during a materialized-view refresh operation.
- Volume object fails because volumes govern file storage, not SQL aggregate query results.
- Foreign catalog is unrelated; the source table is already referenced and the issue is the published object’s type.
Question 10
Topic: Set Up and Configure an Azure Databricks Environment
A team uses Azure Databricks notebooks for development against Unity Catalog tables. The group data-engineers already has edit permission on the notebooks and the required catalog, schema, and table privileges. The notebooks must run on the existing compute dev-etl-cluster, but users should not be able to change the compute configuration. What should you configure?
Options:
A. Grant
data-engineersUSE CATALOGon the workspace catalog.B. Grant
data-engineersCan Manage ondev-etl-cluster.C. Grant
data-engineersCan Attach To ondev-etl-cluster.D. Assign
data-engineersto the cluster policy owner role.
Best answer: C
Explanation: Notebook execution requires both data/object permissions and permission to use the target compute. In this scenario, Unity Catalog and notebook permissions are already in place, so the missing control is compute access. Granting the group Can Attach To on the existing compute allows members to attach notebooks and run development or processing workloads. It preserves the constraint because it does not give them administrative control over the compute configuration. Higher compute permissions are unnecessary when the goal is only to run notebooks on a managed cluster.
- Can Manage overgrants because it allows compute administration, which violates the requirement not to change configuration.
- Catalog privileges mismatch because Unity Catalog access is already granted and does not authorize attaching notebooks to compute.
- Cluster policy ownership controls policy administration, not routine notebook attachment to an existing compute resource.
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.