DP-700 monitor and optimize explained
Monitor and optimize an analytics solution is worth 30–35% of DP-700, the same as each other domain. It covers monitoring Fabric items, identifying and resolving errors, and optimizing performance. Many candidates under-prepare it because it feels like operations rather than engineering, yet it is a third of the marks.
Monitor Fabric items
The Monitor hub lists activity across items you can access: pipeline runs, Dataflow Gen2 refreshes, notebook and Spark job runs, and semantic model refreshes. From a run you can drill into details such as duration, status and error messages. For Spark, the run details link to the Spark UI and logs.
Alerts can be built with Activator on conditions in data or on item events, and inside a pipeline with activities that send a Teams message or an email on failure.
| Item | Where to look |
|---|---|
| Ingestion (pipeline, Copy) | Monitor hub run, activity output and error |
| Transformation (notebook, Dataflow Gen2) | Run details, Spark UI, refresh history |
| Semantic model refresh | Monitor hub or the refresh history of the model |
Identify and resolve errors
The outline lists seven item types. A useful way to remember them is by the typical cause.
| Item | Typical causes and first step |
|---|---|
| Pipeline | Source credentials, bad parameter, timeout; read the failed activity’s error output |
| Dataflow Gen2 | Expired credentials, a data type change, a query that cannot fold; open the refresh history |
| Notebook | Out-of-memory from collecting large results, a missing library, a schema mismatch; read the Spark error and driver logs |
| Eventhouse | Ingestion failures from mapping or format errors; run .show ingestion failures |
| Eventstream | A destination or source misconfigured, or schema issues; check the node’s logs and data insights |
| T-SQL | Unsupported syntax or permissions; read the error number and message |
| OneLake shortcut | Target moved or deleted, or the connection’s credentials or permissions changed |
The method is the same each time: find the failing run, find the failing step, read the actual message, then decide whether it is data, permissions, configuration or capacity.
Optimize performance
Lakehouse tables
- OPTIMIZE compacts many small files into fewer large ones; it can apply V-Order, a write-time layout that speeds reads.
- VACUUM removes files no longer referenced by the table once they are older than the retention period (7 days by default). It frees storage; it does not speed reads by compaction. Shortening retention below the default risks breaking time travel and readers of older versions.
- The small-file problem comes from frequent small appends; fix it with compaction and by batching writes.
Pipelines
Raise copy throughput with partition options on large sources and the degree of copy parallelism, use staging when needed, and run independent steps in parallel instead of in sequence.
Warehouses
Keep statistics current so the optimizer chooses good plans, and use the query insights views to find slow queries.
Eventhouse and Eventstream
Set the caching policy so recent data is in hot cache, and the retention policy to remove data you no longer need. Materialized views and update policies precompute common results.
Spark
Use a broadcast join when one side is small, so the large table is not shuffled. Avoid collect() on big data. Tune partitions to avoid skew, and let Spark settings such as adaptive query execution do their work before hand-tuning.
Example questions
Question 1. A Spark notebook joins a 2 TB fact table to a 30 MB lookup table. The join stage is slow because of a large shuffle. What is the most effective change?
- A. Call collect() on the fact table first
- B. Repartition the lookup table to 5,000 partitions
- C. Run VACUUM on the fact table
- D. Broadcast the lookup table in the join
Show answer
Answer: D
Broadcasting the small table sends a copy to every executor so the large table does not need to be shuffled. Collecting the fact table to the driver would run out of memory. Repartitioning the lookup table to thousands of partitions adds overhead for a tiny table. Running VACUUM on the fact table removes old files but does not change the join strategy.
Want more questions like this? Full DP-700 practice tests →
Question 2. An Eventstream sends data to an Eventhouse table, but some records never appear. You suspect mapping errors during ingestion. Which command shows the failed ingestions?
- A. Table | summarize count()
- B. .show ingestion failures
- C. .show tables
- D. VACUUM Table
Show answer
Answer: B
The management command .show ingestion failures lists failed ingestion operations and their reasons. A summarize count on the table only counts rows that arrived. The .show tables command lists tables, not failures. A VACUUM command applies to Delta tables in a lakehouse, not to Eventhouse ingestion.
Want more questions like this? Full DP-700 practice tests →
Question 3. Your team ran VACUUM with a retention of zero hours on a Delta table to save storage. Afterwards, a long-running query on an older version of the table fails. What explains this?
- A. V-Order removed the files used by the older version
- B. A shortcut to the table was deleted
- C. Zero-hour retention removed files that older versions and running readers still needed
- D. VACUUM only edits the transaction log, so the query timed out
Show answer
Answer: C
VACUUM deletes data files no longer referenced by the current table version once they pass the retention period; with zero retention, files that older versions and running readers still need are removed. The default retention of 7 days exists to avoid exactly this. V-Order does not delete files. Shortcuts are not involved, and the statement that VACUUM only affects the transaction log is incorrect.
Want more questions like this? Full DP-700 practice tests →
How this domain is tested
Expect a failure described in a sentence or two and the question of where to look or what to change. Practise by breaking things on purpose in a trial workspace. Then see the exam tips and the practice test.