Identify and Resolve Fabric Errors: Pipelines, Dataflows, Notebooks, and More

The method that works across every Fabric item type has six steps, and DP-700 scenarios reward you for following them in order rather than jumping to a fix.

1. Locate the failing run. Start in the Monitoring hub (for jobs) or the item's own editor (for continuous items like Eventstreams) and find the failed execution.
2. Read the actual error. Drill to the deepest surface available — the failed activity's error details, the failing table in a refresh, the exception in a cell, the failure record from a KQL command. Never diagnose from the top-level status alone.
3. Classify the failure. Almost every error falls into one of five classes: authentication (expired credentials, missing permission), connectivity (unreachable source, gateway, firewall), schema or data (type mismatch, missing column, malformed rows), resource (out of memory, capacity throttling, timeout), or logic (bad expression, wrong path, wrong query).
4. Reproduce at the smallest scope. Preview the failing query on a subset, run the failing cell alone, ingest one file, or execute the T-SQL statement directly. Small reproductions turn a vague run failure into a specific message.
5. Fix the class, not the symptom. An expired credential needs a connection update, not a retry policy; a type mismatch needs a schema fix, not more memory.
6. Rerun from the failure point and prevent recurrence. Rerun the pipeline from the failed activity, then add retries for genuinely transient classes and an Activator alert so the next failure is heard immediately.

Keep the classification list in your head — the rest of this lesson is those five classes expressed per item type.

A pipeline fails at the activity level, so diagnosis always starts by opening the run and finding the failed activity's error code and message in its output. The run-level status only tells you that some activity on the executed path failed without a recovery path.

The common failure classes map cleanly:

• Authentication — the connection used by a source or sink has expired or lost permission. The fix is updating the connection's credentials, not editing the pipeline.
• Connectivity — the source is unreachable, or an on-premises source is used without a healthy data gateway. Verify the gateway status and network path.
• Schema and data — a Copy activity hits a column mapping mismatch or a value that will not convert to the destination type. Fix the mapping or the destination schema; for recurring dirty data, adjust the copy settings for handling incompatible rows.
• Resource and transient — throttling from the source, a timeout on a long copy, or a temporary service fault. These are the failures retry policies exist for: each activity has a retry count, retry interval, and timeout. Transient classes deserve retries; deterministic ones (auth, schema) do not — retrying a bad credential three times just fails three times.
• Logic — a dynamic expression evaluates to a wrong path or parameter. Check the activity input JSON in the run details, which shows the expression after evaluation.

After fixing, use rerun from failed activity so completed upstream work is not repeated. Also recognize the orchestration angle: failures in an invoked child (a notebook or dataflow activity) surface on the parent's activity, and you drill through to the child's own run for the underlying error.

A Dataflow Gen2 failure is diagnosed from its refresh history: open the failed refresh and find which table (query) and which activity failed, because a dataflow with many queries usually fails in exactly one of them while the rest succeed.

Classify by phase:

• Evaluation errors — the mashup engine could not execute the query: a source credential expired, an on-premises source has no reachable gateway, a source column referenced by a step was renamed or removed, or a step produced an error value. Reproduce by opening the query in the dataflow editor, where the failing step is flagged and you can inspect the error on the exact cell or column.
• Staging errors — dataflows can stage data before loading it; failures here are usually resource-shaped (very large intermediate results) or environmental. If a query does not need staging, disabling staging for it is a legitimate fix as well as an optimization.
• Load-to-destination errors — the write to the Lakehouse, Warehouse, or other destination failed: a data type in the query does not convert to the destination column type, a schema changed so the fixed column mapping no longer matches, or the writer lacks permission on the destination. Fix the query's types, update the destination mapping, or correct the permission.

Two recurring exam patterns: first, a dataflow that works on demand but fails on schedule is usually an authentication or gateway problem tied to the scheduled context; second, when the error text mentions the destination table rather than the source, stop debugging the query steps — the query evaluated fine, and the mapping or destination schema is the problem.

A notebook fails with an exception in the failing cell's output, and that traceback is your first diagnostic. Read it bottom-up: the last frames name the real cause — an unresolved table or path, a column not found, a schema mismatch on write, a Python or PySpark API misuse.

The failures that need more than the cell output are the resource ones:

• Driver out-of-memory — the classic cause is pulling distributed data onto the driver: collect() on a large DataFrame, toPandas(), or building huge local objects. The fix is to stop materializing on the driver (write results to a table, aggregate first, or sample), not to blindly enlarge the pool.
• Executor out-of-memory or lost executors — typically skewed or oversized partitions, or an explosive join. Repartition, fix the skewed key, avoid unnecessary wide shuffles, or scale the Spark pool's node size if the workload legitimately needs it. The Spark UI's stage and task view shows the skew: a handful of tasks running far longer or spilling far more than their peers.
• Session and environment errors — the Spark session failed to start or died: capacity limits on concurrent sessions, a misconfigured environment, or a library conflict from custom packages. Check the driver log and the environment attached to the notebook.

Distinguish surfaces the way the exam does: cell output for code and data errors, driver and executor logs for session-level and infrastructure failures, the Spark UI for where memory and time actually went. And when a notebook fails only when invoked from a pipeline, compare parameters: the pipeline's notebook activity passes parameter values that may differ from your interactive defaults.

Eventhouse (KQL database) errors are dominated by ingestion failures, and the diagnostic is a management command: .show ingestion failures returns the failure records, including the failing database and table, the error code, the failure detail, and whether the failure was permanent or transient. That distinction drives the fix: transient failures (throttling, temporary unavailability) are retried by the service and generally resolve; permanent failures mean the data or configuration is wrong and will fail every retry until you change something.

The common permanent classes:

• Schema and mapping errors — the incoming records do not match the table's ingestion mapping: wrong field names, a mapping referencing a nonexistent column, or values that do not parse as the declared type (a malformed datetime, a string in a numeric column). Fix the mapping or the table schema; verify with a small sample ingestion.
• Format errors — the payload is not the declared format (declared JSON but actually CSV, compressed unexpectedly, or corrupt files).
• Permission errors — the ingesting identity lacks the required database-level permission to ingest into the target table.

Beyond ingestion, two more Eventhouse classes appear on the exam. Update policy failures: a transactional update policy that errors causes the source ingestion to fail too, so an unexplained ingestion failure on a table with update policies means testing the policy's query. And query-side errors: KQL semantic errors (unknown column, wrong operator usage) or queries that exceed limits on very large scans — resolved by correcting the query or narrowing its time range and filters rather than raising limits first.

An Eventstream fails at its edges — sources and destinations — and you diagnose it inside the Eventstream editor using data preview, data insights (per-node metrics), and runtime logs, since a continuously running stream has no run history in the Monitoring hub sense.

On the source side, the dominant class is connectivity and authentication: an external source's connection string, key, or credential is wrong or expired, or the network path to the source is blocked. The symptom is a source node showing errors in the runtime logs, or simply no incoming events in data insights. Verify by checking incoming event metrics: if nothing arrives at the first node, stop debugging transformations — the problem is upstream of Fabric.

Transformation nodes fail on data shape: an operation references a field that stopped appearing in the events, or a type assumption breaks when a producer changes its payload. Data preview at each node shows exactly where the shape diverges from what the downstream operator expects.

On the destination side, the classic error is a schema mismatch with an Eventhouse destination: the events no longer match the target table's schema or mapping, so events flow through the stream but fail to land. Fix the mapping or table, exactly as with direct Eventhouse ingestion. Lakehouse destinations fail similarly on type conversion into the Delta table.

Also recognize the resource class: a stream whose incoming rate outruns its processing shows growing latency in data insights. That is a throughput problem — addressed by simplifying in-stream operations or scaling — not an error to hunt in logs.

T-SQL errors in a Fabric Warehouse (or the Lakehouse SQL analytics endpoint) fall into three classes you should name on sight:

• Permission errors — the caller lacks access to the object: the fix is granting the appropriate permission (GRANT SELECT and friends), workspace role, or item permission — and remembering that the SQL analytics endpoint is read-only, so any INSERT, UPDATE, or CREATE TABLE against it fails by design; writes to Lakehouse tables happen through Spark, pipelines, or dataflows.
• Unsupported-surface errors — a statement or data type the Warehouse does not support. Fabric Warehouse implements a subset of SQL Server's T-SQL surface, and constraints like primary keys exist only as NOT ENFORCED metadata. The fix is rewriting to a supported pattern, not retrying.
• Transaction and conflict errors — Fabric Warehouse uses snapshot isolation; conflicting concurrent modifications can force one transaction to fail and roll back. The fix is retrying the transaction and reducing contention by scheduling conflicting writers apart.

OneLake shortcut errors come in two classes. Authorization: a shortcut to an external source such as ADLS Gen2 authenticates with the credentials stored in its cloud connection — if those expire or lose rights on the target, every read through the shortcut fails with an access error until the connection is fixed; internal OneLake shortcuts instead evaluate the calling user's permission on the target item, so one user reading a shortcut fine while another gets access-denied means a target-side permission gap. Path: the target folder or table was moved, renamed, or deleted, leaving a broken shortcut whose fix is recreating it against the current path. Remember a shortcut holds no data — errors are always about the target or the credentials, never about the shortcut's own contents.

Rehearse this table — it compresses the whole topic into the exam's question shape.

Scenario: a nightly pipeline runs a notebook that reads an ADLS Gen2 shortcut and writes a Lakehouse table; it has failed for two nights. The notebook activity shows a failure; drilling into the notebook run, the cell throws an access error on the shortcut path. Classify: authentication — and because it fails for every identity, it is the shortcut's external connection, not a user permission. The storage key used by the connection was rotated. Fix the connection's credential, rerun the pipeline from the failed activity, and add an Activator rule on failed job events so the next credential rotation is caught the same night.