Monitor and optimize an analytics solution

A nightly load reports Succeeded, the report built on it is still stale, and four different Fabric monitoring surfaces each hold one piece of the answer. The other two domains of this exam build the workspace and load the data; this one takes over once the solution is running, and every question it asks falls into one of three stages: Observe (what ran and how it ended), Diagnose (why a named failure happened), and Optimize (why work that succeeds is slow or expensive). The trap the exam leans on hardest is answering a Diagnose question with an Observe surface, because a pipeline run or the monitoring hub reports which activity stopped and returns its error code, while the explanation lives inside the engine that activity invoked. Name the stage first and the surface follows; guess the surface first and you end up reading a capacity chart to explain a schema error.

Each of this exam's three domains carries 30 to 35 percent, so all three stages here deserve the same care. Monitor Fabric items covers Observe, and its whole skill is choosing by scope: the monitoring hub for a cross-workspace sweep of what ran, an item's own run view for why one execution behaved as it did, the Microsoft Fabric Capacity Metrics app for whether the capacity itself was saturated, and workspace monitoring, a read-only Eventhouse database of logs and metrics queried with KQL (Kusto Query Language), for trends and automation across many runs. Identify and resolve errors covers Diagnose, pairing each item type with the engine-level surface that explains its failures, from Dataflow Gen2 Mashup engine logs and Spark UI to Eventhouse System overview, eventstream runtime logs, warehouse DMVs (dynamic management views) with Query Insights, and Lakehouse shortcut settings. Optimize performance covers Optimize, splitting the dials by the engine doing the work: Delta table layout in the lakehouse, Spark compute, pipeline data movement, warehouse SQL, and the real-time pair of Eventstream and Eventhouse.

When two answers both look workable, the exam rewards the one that acts on the constraint the evidence has already named and punishes the generic remedy. A retry is useful for handling a transient failure such as a network timeout. Extra copy threads cannot rescue a source that is already saturated, and a higher eventstream throughput level cannot beat a source with too few partitions. The same habit carries across all three stages: open the surface that owns the question, name the constraint it reports, then change the one dial that governs that constraint.