4.1 Monitor and optimize an analytics solution Overview

DP-700 Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: DP-700 Orientation and Exam Strategy

1.1 Current DP-700 Exam Facts 1.2 Eligibility, Application, and Scheduling 1.3 Blueprint Domains and Weighting 1.4 Question Style and Score Report Thinking 1.5 Study Calendar and Practice Plan

2 Chapter 2: Implement and manage an analytics solution

2.1 Implement and manage an analytics solution Overview 2.2 Core Workflows and Decision Points 2.3 Scenario Practice for Implement and manage an analytics solution 2.4 Common Traps in Implement and manage an analytics solution 2.5 Practice Drills and Readiness Markers

3 Chapter 3: Ingest and transform data

3.1 Ingest and transform data Overview 3.2 Core Workflows and Decision Points 3.3 Scenario Practice for Ingest and transform data 3.4 Common Traps in Ingest and transform data 3.5 Practice Drills and Readiness Markers

4 Chapter 4: Monitor and optimize an analytics solution

4.1 Monitor and optimize an analytics solution Overview 4.2 Core Workflows and Decision Points 4.3 Scenario Practice for Monitor and optimize an analytics solution 4.4 Common Traps in Monitor and optimize an analytics solution 4.5 Practice Drills and Readiness Markers

5 Chapter 5: Final Review and Test Day

5.1 Timed Practice Strategy 5.2 Last-Week Review Map 5.3 Exam-Day Checklist 5.4 After the Exam and Next Steps

4.1 Monitor and optimize an analytics solution Overview

Key Takeaways Explain This Topic AI

This domain is 30-35% of the DP-700 blueprint, the largest weighting on the exam.

The Monitoring hub shows up to 30 days of run history and the last 100 activities per item across workspaces.

Workspace monitoring writes platform logs to a read-only KQL Eventhouse you query with KQL for historical analysis.

Fabric Activator (formerly Data Activator/Reflex) is the no-code engine for condition-based alerts on events, refreshes, and failures.

Capacity Metrics app is the source of truth for CU consumption, smoothing, overages, and throttling.

Last updated: June 2026

What this domain tests

Monitor and optimize an analytics solution is the single largest scored area on DP-700, accounting for 30-35% of the exam. Microsoft groups the measured skills into four buckets: monitoring Fabric items, identifying and resolving errors , optimizing performance , and managing capacity behavior such as throttling and smoothing. Unlike the ingestion or transformation domains, almost every question here is operational: something is already running, and you must choose the correct tool, setting, or remediation.

The items you must be able to monitor are explicit in the outline: data pipelines , dataflows (Gen2) , semantic model refreshes , Apache Spark jobs and notebooks , and eventstreams . You also tune the storage and compute layers beneath them — Delta tables in a lakehouse, the Warehouse SQL engine, and OneLake — and you operate the Fabric capacity that funds all of it.

The monitoring tool map

Fabric exposes several monitoring surfaces, and the exam rewards picking the right one for the stem's scope and time horizon.

Tool What it shows Scope / retention

Monitoring hub Recent runs of pipelines, notebooks, Spark jobs, dataflows, semantic-model refreshes Last 100 activities per item, up to 30 days, across workspaces you can access

Workspace monitoring Platform logs/metrics written to a read-only KQL Eventhouse Queryable with KQL, ~30 days retention; per-workspace, opt-in toggle

Fabric Activator Condition-based alerts and automated actions on events/refreshes/failures Real-time, no-code rules ('reflexes')

Capacity Metrics app CU seconds consumed, smoothing, overages, throttling, top items Capacity-wide, ~14 days at 30-second timepoints

Item-level monitor Refresh history, Spark UI, pipeline run detail, query insights Per item, deeper drill-down

A quick operational glance at "what just ran and did it succeed" is the Monitoring hub . A queryable, historical, KQL-driven analysis is workspace monitoring . An automated notification when something fails or a threshold is crossed is Fabric Activator . A question about CU consumption, cost, or why jobs are being rejected is the Capacity Metrics app .

Capacity behavior you must internalize

Fabric capacities are self-managing and self-healing through two mechanisms. Bursting lets an operation temporarily use more compute than the SKU provisions so results return fast. Smoothing then averages that consumed CU usage over future 30-second timepoints — interactive operations smooth over 5 to 64 minutes , and background operations smooth over a full 24 hours . Because of smoothing, only a fraction of a heavy job lands on any single timepoint, which is why a small SKU can run a large job without immediate throttling.

When demand still exceeds supply, throttling kicks in progressively: overage protection (up to 10 minutes of future capacity, no throttle), then interactive delay (20-second delays, 10-60 min), then interactive rejection (60 min-24 hr), then background rejection (over 24 hr). Rejected requests return CapacityLimitExceeded . Keep this ladder memorized — it appears repeatedly across the domain.

The four skill buckets in detail

Breaking the domain into the four measured buckets clarifies what to study and how questions are framed.

Monitor Fabric items. Configure monitoring and alerts for capacities and items, and monitor specific item types: data pipelines, dataflows, semantic model refreshes, Spark jobs, and eventstreams. The exam tests which surface answers which question, not just that monitoring exists.

Identify and resolve errors. Triage pipeline, dataflow, notebook, eventhouse, T-SQL, and Spark errors. The skill is reading the failed activity, the cell-level exception, or the KQL ingestion error and tracing it to a root cause such as a schema change, a credential issue, a missing source path, or an overlapping refresh.

Optimize performance. Tune lakehouse Delta tables (OPTIMIZE, V-Order, Z-Order, VACUUM, partitioning), Warehouse queries (statistics, query insights, set-based loads), and Spark configuration (pool sizing, autoscale, dynamic executor allocation, high concurrency, Native Execution Engine).

Manage capacity. Interpret CU consumption, smoothing, bursting, overages, carryforward, burndown, and the throttling ladder, and decide whether to right-size the SKU, pause/resume, or fix an item.

Why this domain dominates the score

Because it is 30-35% of a roughly 40-60 question exam, this domain alone can contribute a dozen or more items. Many questions are multi-step — they describe a symptom (slow report, failed refresh, rejected job) and ask for the single best next action. Mastering the tool-to-symptom map and the exact thresholds above is the highest-leverage preparation you can do for DP-700, because the same facts recur across monitoring, error-resolution, and capacity questions.

Roles and access to monitoring

Monitoring is also governed by permissions . The Monitoring hub shows only items in workspaces you can access, and the workspace monitoring Eventhouse is read-only and queryable by workspace members with appropriate roles. Capacity-level data in the Capacity Metrics app is intended for capacity admins , who can also configure email alerts when a capacity reaches 100% of its provisioned CUs. Knowing who sees what prevents the common mistake of recommending a tool the described role cannot actually open — for example pointing an analyst at capacity throttling charts that only a capacity admin can configure.

As you study, always pair each monitoring surface with the role that operates it and the exact retention window it offers.