Microsoft DP-700 Practice Test 23

Question 220

A new Fabric solution includes complex PySpark lake processing and occasional SQL analytics on Delta data. Which store is the better primary engineering landing zone?

Choose a lakehouse with OneLake Delta/Files and Spark, using its SQL analytics endpoint for supported read-only relational queries.
Use a standalone SQL Warehouse as the only storage surface and run all large PySpark files through it.
Use Eventhouse native KQL ingestion as the primary store for conventional PySpark transformations.
Rely on a lakehouse SQL analytics endpoint to execute all writes via T-SQL INSERT.

Explanation

Correct Answer

Lakehouse offers native file and Delta engineering workflows while still exposing tables through a read-only T-SQL surface.

Incorrect Answers

Warehouse optimizes relational SQL DML; the task specifically needs Spark-centric lakehouse Files and Delta engineering.

Eventhouse targets KQL/event workloads, not the normal Spark lakehouse engineering file surface.

The lakehouse SQL endpoint is read-only for table-data DML; Spark writes provide the engineering path.

Question 221

An engineer expects to INSERT into lakehouse Delta tables through their SQL analytics endpoint, and the DML is rejected. Why?

A destination SQL analytics endpoint needs a notebook attached as default before any INSERT.
The lakehouse SQL analytics endpoint is read-only for Delta table data; supported writes occur through the lakehouse/Spark or appropriate ingest paths.
The engineer omitted a Fabric domain role for SQL DML on lakehouse tables.
The lakehouse Delta table has not been compacted with OPTIMIZE since its creation.

Explanation

Correct Answer

Its T-SQL querying capability does not make the endpoint a full warehouse DML interface.

Incorrect Answers

The endpoint is intrinsically read-only for data modification, regardless of default notebook attachments.

Domain governance does not grant write capability to the lakehouse SQL query surface.

File compaction influences read performance, not the endpoint's lack of table-data INSERT support.

Question 222

A warehouse-oriented team selects a Fabric store. Which validation distinguishes warehouse T-SQL serving from a lakehouse engineering path?

Execute only a SELECT through the lakehouse SQL endpoint and declare a T-SQL write requirement satisfied.
Run a Spark write on a lakehouse and infer that the same SQL endpoint accepts INSERT.
Run a supported warehouse T-SQL data modification and query test, and compare lakehouse Spark/Files handling against the required workload.
Compare lakehouse and warehouse display names instead of running DML or file-path tests.

Explanation

Correct Answer

The intended write and query engines determine store fitness; labels such as warehouse and lakehouse are not interchangeable access paths.

Incorrect Answers

A successful SELECT proves query access but cannot establish warehouse T-SQL DML capability.

Spark has a distinct write execution path, so its success does not validate the warehouse's transactional SQL surface.

Names reveal nothing about which engine supports INSERT or engineered Delta Files/Spark operations.

Question 223

A manufacturing system emits hundreds of thousands of timestamped telemetry observations to be queried within seconds using KQL. Which Fabric data store matches that need?

Keep a nightly warehouse batch and point a KQL dashboard at yesterday's data.
Store every raw event as a separate Delta file and query it only through Spark scheduled jobs.
Use a Power BI imported model refreshed hourly as the sole telemetry landing zone.
Use an Eventhouse/KQL database with a suitable native telemetry ingestion path and event-time indexing/query model.

Explanation

Correct Answer

Eventhouse is designed for high-throughput time-series/event workloads with the Kusto Query Language rather than batch-centric SQL transformations.

Incorrect Answers

KQL presentation cannot satisfy sub-second/seconds freshness if records aren't ingested until the next night.

A file-per-event and scheduled Spark design doesn't supply native low-latency KQL ingestion/query characteristics.

Imported hourly refreshes lack the immediate event capture and native time-series querying required.

Question 224

A telemetry project chooses a nightly SQL warehouse import and then complains that newly emitted sensor records are not searchable immediately. Select TWO observations or design corrections that explain and address this shortfall.

The nightly batch landing path lacks a low-latency event ingestion route.
The nightly warehouse batch is missing a Spark environment with a higher node count.
The telemetry field names do not match a warehouse naming convention.
The KQL-oriented real-time workload would be better served by a supported Eventstream-to-Eventhouse flow if it meets source and query requirements.
The operations dashboard has not enabled URL category filtering.

Explanation

Correct Answers

The chosen cadence delays data arrival until the next scheduled warehouse load.

A managed event path supports frequent ingestion and time-series querying rather than relying on nightly relational refresh.

Incorrect Answers

Increasing Spark resources does not change the batch's once-per-night arrival cadence into continuous ingestion.

Names can matter to mapping but do not explain predictable missing events between scheduled batch windows.

Web/category filtering is unrelated to real-time sensor ingestion and cannot decrease event-to-query delay.

Question 225

A new Eventhouse ingestion path is deployed for sensor telemetry. Which acceptance test best demonstrates its suitability?

Query an old daily snapshot and report its aggregate row count as live ingestion latency.
Send timestamped sensor events, query their arrival with KQL and record event-to-query visibility and filtering under representative load.
Verify that a Power BI report refresh completed during the previous night.
Compare warehouse object names to Eventstream destination labels without sending a sensor event.

Explanation

Correct Answer

Source timestamp, ingest time and query availability establish freshness rather than simply counting a created Eventhouse item.

Incorrect Answers

A snapshot total cannot measure how rapidly newly emitted sensor events reach Eventhouse.

A previous refresh is not evidence of current KQL event visibility or the configured streaming route.

Configuration labels do not exercise ingestion, time filters or representative throughput.

Question 226

A data engineering team already has a complex PySpark cleaning and feature-generation routine, and it must run on distributed compute against large Delta files. What Fabric execution surface fits?

Convert the custom PySpark package into Power Query formulas without verifying equivalent operations.
Run the job entirely on a SQL analytics endpoint and expect Python library imports there.
Use a Fabric Spark notebook with a compatible published environment and a lakehouse path for the transformed Delta output.
Use a Spark notebook with only the default lakehouse name, ignoring the runtime package requirements.

Explanation

Correct Answer

Notebooks support distributed PySpark logic and managed dependency selection, matching code-first transformations.

Incorrect Answers

Power Query may not run the same distributed Spark code, dependencies and feature-generation algorithm.

A read-only T-SQL query surface doesn't execute notebook PySpark environments and custom wheels.

A notebook needs the correct published environment and execution settings, not only an attached data path.

Question 227

An existing PySpark transformation joins two large Delta datasets and calls a private wheel whose Python dependencies are published in a Fabric environment. A developer proposes converting the workload into a plain Dataflow Gen2 transformation, but the pipeline needs the existing distributed Spark code unchanged. Select TWO technically necessary design decisions.

The PySpark job requires one more Dataflow Gen2 transformation-step name before it can import wheels.
The runtime error is caused by a lakehouse Delta column's V-Order setting.
A Dataflow Gen2 Power Query transformation does not execute arbitrary PySpark join code or the private Spark-attached Python package.
Keep the distributed transformation as a Fabric Notebook activity bound to the approved published Spark environment, and orchestrate that activity in the pipeline.
The pipeline has not created a KQL database to host custom Python packages.

Explanation

Correct Answers

The existing code relies on Spark DataFrame execution and a Python wheel. Dataflow Gen2 has a different transformation engine, so a Power Query step is not a drop-in interpreter for the code.

Retaining a supported Spark notebook preserves the distributed joins and required dependency environment while permitting pipeline triggers and dependencies. This addresses both engine and package execution, not merely a language mismatch.

Incorrect Answers

A Dataflow's low-code Power Query runtime does not execute arbitrary PySpark custom wheels; renaming steps cannot add that engine.

Delta layout does not make Python-only modules and Spark APIs available inside a Dataflow definition.

Eventhouse/KQL storage is not a package/runtime substitute for scheduled PySpark code.

Question 228

A notebook-based Spark transform is moved into production. What proves the runtime and output satisfy the code-first requirement?

Inspect its effective Spark environment, successful job run and representative transformed Delta data under a compatible lakehouse location.
Confirm the Dataflow preview shows an equivalent column name without running the custom transformation.
Check only the successful notebook scheduler status, ignoring package versions and output.
Run the job with a different Spark environment and compare only its workspace display name.

Explanation

Correct Answer

Checking the actual job and persisted output demonstrates that the correct code path and dependencies ran.

Incorrect Answers

Matching schema previews do not verify that the actual Python package logic or Spark job ran.

A green scheduler can coexist with wrong library versions or incorrect transformation output.

Environment names are metadata; effective runtime/library inventory and substantive result checks are required.

Question 229

An existing Fabric Warehouse contains normalized staging tables and the team needs relational window functions to create a curated presentation table. Which language/engine is appropriate?

Transfer every normalized warehouse table into a notebook before applying SQL window functions.
Use KQL summarize as a drop-in replacement for all T-SQL window specifications.
Rewrite the staging tables as Power BI visual calculations and skip reproducible curated SQL tables.
Use supported T-SQL transformations against warehouse tables, including relational joins and window functions, with an appropriate target write.

Explanation

Correct Answer

Warehouse SQL supports relational ELT patterns and avoids exporting data to a different engine solely for standard SQL transformations.

Incorrect Answers

The existing Fabric Warehouse supports relational T-SQL transformations without unnecessary Spark staging.

KQL time-series aggregation isn't a general equivalent of the requested relational SQL windowing logic.

A report-layer calculation doesn't provide the persisted warehouse presentation table and SQL object lineage.

Question 230

A warehouse transform uses SQL `ROW_NUMBER()` over the wrong partition key and keeps duplicate records. What explains the unexpected result?

The warehouse window function is not preceded by a `DISTINCT` on every output column.
The target needs a larger Fabric capacity to select exactly one row per logical entity.
The window partition/order specification does not match the intended business-entity grain, so the row-selection logic is incorrect.
A lakehouse Files shortcut was not created for the warehouse query plan.

Explanation

Correct Answer

Window functions preserve explicit partition semantics; a wrong partition allows duplicates or discards legitimate rows.

Incorrect Answers

An incorrect ROW_NUMBER partition cannot be repaired reliably by a blanket DISTINCT, which can collapse valid rows.

Compute capacity does not correct the partition-key logic determining which rows are peers.

A shortcut cannot fix the wrong PARTITION BY columns in a relational deduplication query.

Implementing Data Engineering Solutions Using Microsoft Fabric (DP-700) Practice Tests

Microsoft DP-700 Practice Test 21 - 10 Questions (Last Reviewed 14-Oct-2026)
Microsoft DP-700 Practice Test 22 - 10 Questions (Last Reviewed 13-Oct-2026)
Microsoft DP-700 Practice Test 23 - 10 Questions (Last Reviewed 12-Oct-2026)
Microsoft DP-700 Practice Test 24 - 10 Questions (Last Reviewed 11-Oct-2026)
Microsoft DP-700 Practice Test 25 - 10 Questions (Last Reviewed 10-Oct-2026)

Pass Your Microsoft DP-700 Exam Easy!

Question 220

Explanation

Correct Answer

Incorrect Answers

Question 221

Explanation

Correct Answer

Incorrect Answers

Question 222

Explanation

Correct Answer

Incorrect Answers

Question 223

Explanation

Correct Answer

Incorrect Answers

Question 224

Explanation

Correct Answers

Incorrect Answers

Question 225

Explanation

Correct Answer

Incorrect Answers

Question 226

Explanation

Correct Answer

Incorrect Answers

Question 227

Explanation

Correct Answers

Incorrect Answers

Question 228

Explanation

Correct Answer

Incorrect Answers

Question 229

Explanation

Correct Answer

Incorrect Answers

Question 230

Explanation

Correct Answer

Incorrect Answers

Implementing Data Engineering Solutions Using Microsoft Fabric (DP-700) Practice Tests