DP-700 - Monitor and Optimize an Analytics Solution (33% of the exam) - Section 3.3

Identify and resolve Data Factory pipeline and Dataflow Gen2 errors.

Identify Data Factory pipeline errors by reading activity error output and adjust retry and timeout settings to make pipelines resilient. Diagnose Dataflow Gen2 refresh errors, distinguishing staging and evaluation failures from Copy activity connectivity issues.

pipeline activity error outputretry and timeout settingsDataflow Gen2 refresh errorsstaging and evaluation errorsdiagnosing Copy activity failures

Practice question for this objective

Free sampleMonitor and Optimize an Analytics Solutionmedium

A Microsoft Fabric pipeline runs ten activities, and one downstream Copy activity fails. The monitoring view shows the failed run, but the team needs the specific error message and the source row count the activity reached before it stopped, so they can decide whether the source file was malformed. Where should they look first to get this detail without re-running the pipeline?

AThe Fabric capacity metrics app, which surfaces the compute units the pipeline consumed and shows the per-activity error text alongside the throttling events for that run.
BThe Copy activity's output and error details on the failed run in the pipeline run-detail view, which records the error message and the rows read before the failure. Correct
CThe Lakehouse table's Delta transaction log, which lists the commit that the Copy activity attempted and records the rejected rows together with the source error returned.
DThe workspace recent-runs list, which shows each pipeline run's overall status and duration and links the failed activities to their full error output by default.

Read a failed activity's output and error details in the pipeline run-detail view to diagnose Copy activity failures without re-running the pipeline. The pipeline run-detail view exposes each activity's output object, which for a Copy activity includes the error message and rows-read counters at the point of failure; this is the authoritative place to diagnose a malformed source, whereas capacity metrics, the Delta log, and the run summary list lack that per-activity error payload.

Why A is wrong: The capacity metrics app reports compute consumption and throttling, not per-activity error messages or rows-read counts, so it cannot answer whether the source file was malformed.

Why B is correct: Each activity's run detail captures its output payload including the error message and rows-read counters, so opening the failed Copy activity in the run-detail view gives the needed diagnostics without any rerun.

Why C is wrong: The Delta log records committed table versions, not a failed activity's source error or its partial read count, so a failure that never committed leaves nothing useful there.

Why D is wrong: The recent-runs list summarises run status and duration but does not itself display the per-activity error text and row counts; you must open the run detail to reach those, so it is not where the detail lives.

See more DP-700 practice questions, answers explained.

Exam traps in Monitor and Optimize an Analytics Solution

Answers that look right on this material and are not. Each one is a distractor from a different question in the DP-700 bank for this domain.

Raise the Copy activity timeout from the default to twenty-four hours so the activity keeps waiting through the outage rather than failing when the source connection drops mid-copy.
Why it is wrong: A longer timeout only governs how long a single attempt may run; it does not re-establish a connection that has already been reset, so the activity still fails on the dropped attempt rather than recovering.
Link both the Notebook and the cleanup activity to the Copy activity on Completion dependencies so each runs after the Copy activity finishes either way.
Why it is wrong: Completion fires regardless of outcome, so the Notebook would run even when Copy fails and cleanup would run even when Copy succeeds, breaking both rules.
Set the Retry count to five so the activity stops after five failed attempts and the pipeline can then take its error path quickly.
Why it is wrong: Retry count controls how many times a failed attempt is repeated, not how long a single in-progress call may run, so a stalled call would still hang for over an hour.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.