Overview
Domain 3 carries the same 30–35% weight as the other two DP-700 skill areas and focuses on operating what you built. Microsoft lists three functional groups. Monitoring covers data ingestion, data transformation, semantic model refresh and alert configuration.
Error resolution names six item types explicitly: pipelines, dataflows, notebooks, eventhouses, eventstreams and T-SQL. Performance optimization covers lakehouse tables, pipelines, data warehouses, eventstreams and eventhouses, Spark, and general query performance. Questions here describe a symptom, such as a slow table scan, a failed refresh, a stuck stream or a notebook running out of memory, and ask for the diagnostic tool or the fix. You need to know where each item reports its run history and which tuning levers belong to each engine.
How it's tested
Domain 3 scenarios start with a symptom: a run failed, a refresh is late, a query slowed down or a stream dropped events. You choose where to look, what the cause is and which change fixes it with the least effort, often from options that each address a different engine.
-
Where do I look
A failure or delay is described, and you choose the Monitoring hub, run details, Spark UI, query insights or eventhouse diagnostics.
-
Fix the table
Reads are slow on a Delta table, and you pick OPTIMIZE, V-Order, Z-order, VACUUM or partitioning based on the cause.
-
Tune the engine
A Spark job, pipeline copy, warehouse query or eventhouse is slow, and you pick the setting or design change for that engine.
Queries on a lakehouse sales table slowed after months of hourly appends. The table now has tens of thousands of small Parquet files. Adding Spark nodes treats the symptom and costs capacity. Running OPTIMIZE compacts small files into larger ones, and applying V-Order improves read speed for the SQL analytics endpoint and Power BI. Scheduling table maintenance prevents the problem from returning.
Functional groups 3
Official functional groups from the Microsoft outline, in outline order.
3.1 Monitor Fabric itemsIngestion, transformation and refresh monitoring, plus alerts.
- What it means
- This group covers watching data ingestion runs, transformation jobs and semantic model refreshes, and configuring alerts that notify people or start actions when something fails or crosses a threshold.
- What to understand
- The Monitoring hub lists activity across pipelines, dataflows, notebooks, Spark job definitions and semantic models, with filters by item type, status and time. Each pipeline run shows activity-level input, output and duration. Spark applications expose the Spark UI and driver logs. Semantic model refresh history shows status and duration, and refresh failures can email owners. Workspace monitoring stores detailed logs and metrics in a monitoring eventhouse you can query with KQL. The Fabric Capacity Metrics app shows capacity consumption and throttling. Alerts can be set through Activator on data or events, through pipeline Outlook or Teams activities on failure paths, or through Real-Time hub events.
- How it shows up
- Expect a requirement to find failed runs across items, track refresh duration, or notify a team on failure.
- Common confusion
- Using the Capacity Metrics app to find why one pipeline failed; it shows consumption and throttling, not activity errors.
3.2 Identify and resolve errorsDiagnosing pipeline, dataflow, notebook, eventhouse, eventstream and T-SQL errors.
- What it means
- This group covers reading error details and fixing failures for six item types: pipeline activities, Dataflow Gen2 refreshes, notebooks, eventhouse ingestion and queries, eventstream processing, and T-SQL statements in warehouses or SQL analytics endpoints.
- What to understand
- Pipeline failures show an error code and message per activity; fixes include credentials, timeouts, retries, and dependency conditions such as on failure or on completion. Dataflow errors appear in refresh history per query and table, often from data type mismatches, gateway problems or destination schema changes. Notebook errors show in cell output and Spark logs, with common causes being out-of-memory, missing libraries or session timeouts. Eventhouse ingestion failures can be listed with .show ingestion failures, often caused by mapping or schema mismatch. Eventstreams report data insights and runtime logs for each node. T-SQL errors include unsupported features in Fabric Warehouse and snapshot isolation write conflicts.
- How it shows up
- Expect a symptom and error text, then a choice of cause or fix for the named item.
- Common confusion
- Retrying a failed activity repeatedly when the error is a schema mismatch that will fail every time.
3.3 Optimize performanceLakehouse table, pipeline, warehouse, real-time, Spark and query tuning.
- What it means
- This group covers improving performance of lakehouse Delta tables, pipelines, data warehouses, eventstreams and eventhouses, Spark workloads, and queries across engines.
- What to understand
- Lakehouse tables benefit from OPTIMIZE to compact small files, V-Order for faster reads, Z-order on filter columns, and VACUUM to remove old files after the retention period, seven days by default. Pipelines improve with parallel copies, intelligent throughput optimization, staging and a higher ForEach batch count. Warehouses rely on automatic statistics, sensible data types and batched rather than single-row inserts. Eventhouses tune caching policy to keep hot data in cache, retention policy and materialized views; eventstreams can raise throughput settings. Spark gains from the native execution engine, broadcast joins, caching reused DataFrames, avoiding collect on large data, and choosing pool sizes. Query insights views help locate expensive warehouse queries.
- How it shows up
- Expect a slow item and options spanning several engines; choose the lever that belongs to the item described.
- Common confusion
- Running VACUUM to speed up reads; it frees storage and removes old versions but does not compact files.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Monitoring hub
Central view of runs across Fabric items.
- Remember
- Filter by item type, status and time.
- Tested as
- Monitoring questions.
- Trap
- Searching each workspace manually.
-
Workspace monitoring
Logs and metrics stored in a monitoring eventhouse.
- Remember
- Query with KQL for detailed history.
- Tested as
- Advanced monitoring questions.
- Trap
- Expecting it to be on by default.
-
Capacity Metrics app
Shows capacity usage, overages and throttling.
- Remember
- Explains slowdowns caused by capacity limits.
- Tested as
- Capacity questions.
- Trap
- Using it to read activity error messages.
-
Activator
Rule engine that watches data or events and triggers actions.
- Remember
- Sends alerts or starts items.
- Tested as
- Alerting questions.
- Trap
- Building a polling notebook instead.
-
Dependency conditions
On success, on failure, on completion and on skip paths in pipelines.
- Remember
- Used for error handling and alerts.
- Tested as
- Pipeline error questions.
- Trap
- Using on success for a failure notification.
-
.show ingestion failures
KQL command listing eventhouse ingestion errors.
- Remember
- Reveals mapping and format problems.
- Tested as
- Eventhouse error questions.
- Trap
- Looking only in the Monitoring hub.
-
Query insights
Warehouse system views of query history and long-running queries.
- Remember
- Find expensive or frequent queries.
- Tested as
- Warehouse tuning questions.
- Trap
- Guessing which query is slow.
-
OPTIMIZE
Compacts small files in a Delta table.
- Remember
- Improves read performance.
- Tested as
- Lakehouse tuning questions.
- Trap
- Confusing it with VACUUM.
-
V-Order
Write-time Parquet optimization for faster reads.
- Remember
- Benefits SQL endpoint, Power BI and Spark reads.
- Tested as
- Read performance questions.
- Trap
- Expecting faster writes from it.
-
Z-order
Co-locates related values to improve file skipping.
- Remember
- Use on frequent filter columns.
- Tested as
- Query filter questions.
- Trap
- Applying it to every column.
-
VACUUM
Removes unreferenced files older than the retention threshold.
- Remember
- Default retention is seven days.
- Tested as
- Storage questions.
- Trap
- Expecting faster queries.
-
Native execution engine
Vectorized engine that runs Spark queries natively.
- Remember
- Enabled at environment or session level.
- Tested as
- Spark tuning questions.
- Trap
- Adding nodes before trying it.
-
Broadcast join
Sends a small table to every executor to avoid shuffles.
- Remember
- Fits small dimension joins.
- Tested as
- Spark join questions.
- Trap
- Broadcasting a large table and causing memory errors.
-
Caching policy
Eventhouse setting for how much data stays in hot cache.
- Remember
- Hot data queries fastest.
- Tested as
- Eventhouse tuning questions.
- Trap
- Changing retention instead of cache.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Delta table maintenance
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| OPTIMIZE | Bin compaction of small files | Faster reads | Running it expecting storage savings |
| V-Order | Optimized Parquet layout on write | Read speed across engines | Expecting write speed gains |
| Z-order | Clusters data by chosen columns | Better data skipping on filters | Too many columns dilute benefit |
| VACUUM | Deletes old unreferenced files | Storage cleanup, limits time travel | Short retention breaks time travel |
Where to diagnose
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Monitoring hub | Runs across items | First stop for failed runs | Expecting Spark stage detail |
| Spark UI and logs | Stages, tasks, executors | Notebook and Spark job detail | Ignoring skew and spill |
| Query insights | Warehouse query history | T-SQL performance detail | Using it for Spark jobs |
| Capacity Metrics app | Capacity consumption | Throttling and overload | Using it for item-level errors |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
VACUUM for speed
- What candidates pick
- Run VACUUM to make a slow table faster.
- Why it looks right
- It cleans up the table.
- Why it's wrong
- VACUUM removes old files to save storage; OPTIMIZE compaction is what reduces small-file reads.
Clue to watch for Many small files and slow reads.
-
More nodes first
- What candidates pick
- Increase Spark pool size for a slow join.
- Why it looks right
- More compute seems faster.
- Why it's wrong
- Shuffles or skew persist; a broadcast join or native execution engine often fixes the root cause.
Clue to watch for A small table is joined to a large one.
-
Retry forever
- What candidates pick
- Increase retry count for an activity failing on a type conversion.
- Why it looks right
- Retries fix transient errors.
- Why it's wrong
- Deterministic errors such as schema mismatch fail every attempt; fix the mapping or data.
Clue to watch for The same error text appears on each run.
-
Capacity app for errors
- What candidates pick
- Open the Capacity Metrics app to find why a dataflow failed.
- Why it looks right
- It is the admin monitoring tool.
- Why it's wrong
- The app shows consumption and throttling; refresh history shows the failing query and message.
Clue to watch for A single item failure with an error message.
-
Retention for hot queries
- What candidates pick
- Increase eventhouse retention so recent queries run faster.
- Why it looks right
- Retention and caching sound similar.
- Why it's wrong
- Retention controls how long data is kept; the caching policy controls hot-cache speed.
Clue to watch for Recent data is queried slowly.
-
Success path alert
- What candidates pick
- Connect a Teams activity on the success output to report failures.
- Why it looks right
- It is the default connector.
- Why it's wrong
- Notifications for failures belong on the on failure dependency path.
Clue to watch for The requirement says notify only when a step fails.
Answer framework
Apply these steps when a Domain 3 question describes a failure or slow workload in Fabric.
- Name the item and the engine behind it from the symptom described: pipeline, dataflow, notebook, eventstream, eventhouse, warehouse or lakehouse table.
- Go to the matching diagnostic: Monitoring hub and run details, refresh history, Spark UI, ingestion failures, data insights or query insights.
- Decide whether the cause is transient, such as throttling, capacity limits or timeouts, or deterministic, such as schema, permission or code errors.
- Apply the lever for that engine: OPTIMIZE and V-Order for tables, parallelism for copies, caching policy for eventhouses, broadcast or native execution for Spark.
- Prevent recurrence with scheduled table maintenance, failure-path alerts, Activator rules or workspace monitoring queries.
Practice question
Want more like this? The DP-700 practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Treat this domain as practice in breaking things on purpose. In a test workspace, make a pipeline fail with a bad path, a dataflow fail with a type mismatch and a notebook fail with a missing library. For each failure, find the error in the Monitoring hub and in the item's own run details, then fix it. Add an on failure path that posts to Teams so you remember how dependency conditions work.
For optimization, write many small appends to a Delta table, measure a query, run OPTIMIZE with V-Order and measure again. Then run VACUUM and confirm it changes storage rather than speed. In Spark, compare a regular join with a broadcast join and turn on the native execution engine to see the difference.
Finish with real-time items: create an ingestion mapping error in an eventhouse and find it with .show ingestion failures, then adjust the caching policy. Review the Capacity Metrics app briefly so you know what it can and cannot tell you.
FAQ
How much of DP-700 is Domain 3, Monitor and optimize an analytics solution?
Microsoft assigns Domain 3, Monitor and optimize an analytics solution, a 30–35% weight. It has three functional groups: monitoring Fabric items, identifying and resolving errors, and optimizing performance.
Which tool shows failed runs across many Fabric items?
The Monitoring hub. It lists runs for pipelines, dataflows, notebooks, Spark job definitions and semantic models, with filters and links to details.
What is the difference between OPTIMIZE and VACUUM?
OPTIMIZE compacts small files to speed up reads. VACUUM deletes files no longer referenced by the table after the retention period to save storage.
What is V-Order?
A write-time optimization of Parquet files in Fabric that makes reads faster for the SQL analytics endpoint, Power BI Direct Lake and Spark.
How do I get alerted when a pipeline fails?
Add an Outlook or Teams activity on the on failure path, or use Activator rules on Fabric job events.
Where do I find slow warehouse queries?
Use the query insights views in the warehouse, which record query history, frequently run queries and long-running queries.
Which item types appear in the error resolution bullets?
Pipelines, dataflows, notebooks, eventhouses, eventstreams and T-SQL. Practice reading errors for each one.
Other Data & Analytics certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have covered monitoring, alerts, error resolution across six item types and performance tuning. Check whether you can match each symptom to the right tool and fix.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the DP-700 AI tutor Get any concept explained your way