Monitor and optimize an analytics solution practice questions

Dataflow Gen2 refresh history lists each run. Opening a run shows a Tables section (each loaded query's status) and an Activities section (actions such as writing to the output destination), each of which can be drilled into for errors and statistics.

The engineer needs two facts: which table failed, and in which phase. Only the run details in the dataflow's refresh history break a refresh down by table and by activity. Row counts in the Lakehouse show symptoms, not causes. The Capacity Metrics app measures compute usage. Lineage maps dependencies. None of them records why a refresh failed.

1. Open the dataflow's recent runs (refresh history) from the workspace or the Monitoring hub.
2. Select the start time of the failed run to open its details.
3. Check the Tables list for the query that failed, then the Activities list for a failed load to the destination.
4. Drill into the failed table or activity to read the error message.

Exam tip: For a failed Dataflow Gen2 refresh, open the run in its refresh history. Tables and Activities show where the failure happened.

Fabric notebook and Spark job definition runs expose the Apache Spark UI from their run details. Its jobs, stages and tasks views show task durations, shuffle sizes and retries, which is where slowness such as data skew becomes visible.

The run succeeds, so error-oriented diagnostics (the snapshot, the driver log) have nothing to show. The question is how work is distributed inside stages, and only the Spark UI reports per-task duration and shuffle read size. The Monitoring hub and the Capacity Metrics app work at run and capacity level and cannot see inside a Spark stage.

1. Decide whether the run failed or was only slow. Here it was only slow.
2. Open the run details from the Monitoring hub or the notebook's recent runs.
3. Open the Spark UI and find the long-running stage.
4. Compare task durations and shuffle read sizes. A few outsized tasks point to skewed partitions.

Exam tip: The snapshot and logs explain why a run failed. The Spark UI stage and task views explain why it was slow.

Semantic model scheduled refresh settings include built-in failure notifications: the owner is emailed by default, and extra contacts can be added. These notifications cover scheduled refreshes.

Activator, a pipeline with an Outlook activity, and the built-in setting could all deliver a failure email. The constraint is "no new item". Activator and the pipeline each create an item, so only the setting on the existing model fits. A report subscription is a real email feature, but it delivers report content on a timetable, not refresh failures.

1. Identify the event to alert on: a scheduled refresh failing.
2. Note the constraint: no new items.
3. Rule out options that create an Activator or pipeline item.
4. In the model's scheduled refresh settings, keep owner notifications on and add the support mailbox as a contact.

Exam tip: For a semantic model's scheduled refresh failures, the lightest alert is the built-in failure notification in its refresh settings.

Activator is the Fabric alerting engine for data in motion. A rule watches events, evaluates a condition (optionally per object, such as per sensor) and fires actions such as email, a Teams message, starting a Fabric item, or a Power Automate flow.

Three requirements decide this: near-real-time, per-sensor detail, and a Teams message. An Activator rule on the eventstream meets all three. A scheduled dataflow is too slow and has no notification action. A dashboard tile alert can reach Teams through Power Automate, but it watches one aggregate rather than each sensor. An update policy only moves data inside the Eventhouse.

1. Spot the need: react to individual streaming events within seconds.
2. Choose the Fabric component that evaluates conditions on streams and takes actions, which is Activator.
3. Define the condition (temperature greater than 90), grouped by sensor ID.
4. Add a Teams action that includes the sensor ID as context.

Exam tip: Use an Activator rule to alert on conditions in streaming data. Batch transforms and storage policies do not notify anyone.

The Microsoft Fabric Capacity Metrics app is the capacity-wide monitoring tool. It shows compute-unit usage by item and operation, overages, and throttling (interactive delay, interactive rejection, background rejection).

Slow interactive queries and "try again later" rejections are classic signs of throttling. The question is capacity-wide (which items consumed the compute), and only the Capacity Metrics app aggregates usage across workloads and shows throttling. The other options each look at a single kind of job or item.

1. Recognise the symptoms: interactive slowdowns plus rejected requests point to an overloaded capacity.
2. Choose the tool that covers all workloads on the capacity, which is the Capacity Metrics app.
3. Use its utilization views to find the top-consuming items and operations.
4. Check its throttling charts and system events for delays and rejections.

Exam tip: Questions about compute consumption across items or throttling are answered in the Capacity Metrics app, not in job-level monitoring.

The Real-Time hub is Fabric's single place to discover, manage, and act on data in motion across the tenant: eventstreams, streams from external sources, and KQL tables, with actions such as previewing data and setting Activator alerts.

The requirement has two parts — tenant-wide discovery of streaming sources, and setting an alert without navigating into the owning workspace. The Real-Time hub satisfies both: it catalogs the streams the user can access and exposes a Set alert action that provisions an Activator rule inline. The Monitoring hub is about run history, and the other options are scoped to a single item's contents.

1. Open the Real-Time hub from the Fabric navigation pane.
2. Browse or search the streams and streaming tables available to you across workspaces.
3. Select the stream of interest and preview its events to confirm it is the right source.
4. Choose Set alert to define the condition and action, which creates the Activator rule.

Exam tip: The Real-Time hub is the tenant-wide catalog for streaming data, with Set alert built in to create Activator rules on any accessible stream.