In an ADF Mapping Data Flow, why does Data preview require debug mode to be on?

## What the toggle actually starts A Mapping Data Flow is a design surface, but everything it shows you about your data comes from real execution. The **Data flow debug** toggle at the top of the designer starts a Spark cluster dedicated to your session. It is the same kind of managed compute a triggered run would use, held open interactively so the designer can ask it questions. That is the whole answer to why preview needs it: without a live cluster there is nowhere to run the query that produces the preview. Because a cluster has to be acquired, flipping the toggle takes a couple of minutes before previews become available - the same cold-start cost that a scheduled data flow pays. ## What Data preview gives you Every transformation in the graph has a Data preview tab. Clicking it executes the flow from the sources up to and including that transformation and returns a limited number of rows. That is enormously useful because you can inspect the intermediate state at each hop rather than reasoning about the whole graph at once: - On a Source, confirm the projection and the types the service inferred. - On a Derived Column, see the computed values and catch a null-propagating expression immediately. - On a Join, see how many rows survived and whether the key matched at all. - On an Alter Row, see the marker assigned to each row, which is the fastest way to prove a policy expression is firing. Previews are also where you notice type surprises early - a numeric column read as string from a delimited text source, or a date that failed to parse. ## Debug settings The **Debug settings** panel controls the session. You can cap the number of rows a preview returns so the round trip stays fast, point a source at a sample file or a smaller row limit instead of the full production dataset, and supply values for the flow's parameters so parameterized expressions resolve while you are designing. Setting parameter values here is easy to forget and produces confusing previews when an expression silently evaluates against an empty parameter. ## Preview does not write; a debug run does This distinction catches people out and is worth being precise about in an interview. **Data preview** inside the designer reads from sources and materialises rows for display. It does not write to sinks - previewing the Sink transformation shows what would arrive there. So previewing against production sources is safe from the target's point of view, though it does read real data. A **Debug run of the pipeline** containing the Data Flow activity is a genuine execution. It uses the debug session's compute rather than waiting for a fresh cluster, but the flow runs end to end and the sinks are written with whatever settings they carry, including table actions like truncate or recreate. Pointing a debug run at a production table because "it is only debug" is a real way to lose data. ## Cost and hygiene The debug session holds a cluster, and holding a cluster consumes compute time whether you are actively previewing or reading email. Sessions have an inactivity shutdown, but the disciplined habit is to turn debug off when you finish designing. On a shared factory, several developers each holding a debug session is a quiet, recurring cost that nobody notices until the bill arrives. One more caution: because previews are sampled and often run against smaller inputs, a preview that returns instantly tells you nothing about how the flow will perform on the full dataset. Correctness feedback, yes; performance evidence, no. For that you need a real run and its monitoring detail. ## The short version for an interview Debug mode starts a session cluster; Data preview executes the graph up to a node on that cluster and shows sampled rows; previews never write to sinks but a pipeline debug run does; debug settings cap rows, choose sample sources and supply parameters; and the session costs compute until you switch it off.