Free DP-700 flashcards

In Microsoft Fabric, which Spark workspace setting lets notebook sessions start within seconds without permanently reserving compute?

Keeping the starter pool enabled. The starter pool holds pre-warmed, pre-allocated nodes attached to the capacity, so a session binds to a ready node in seconds instead of paying cold-start provisioning time, and the nodes are released when idle rather than reserved continuously.

Raising the default node size on the Fabric starter pool will fix slow Spark session start-up.

Bigger nodes only give each session more memory and processing power; they do nothing about cold-start provisioning. Larger nodes can actually take longer to acquire, so startup latency is unchanged or worse.

How should you incrementally load an append-only source with an ever-increasing timestamp into a bronze Delta table while keeping overhead low?

Store the highest timestamp value loaded so far as a high-water mark, then each run copy only source rows whose timestamp exceeds that stored value and update the mark. Because rows are only inserted and the timestamp always increases, the previous maximum cleanly separates old from new rows, so you load exactly the new data without reading the whole table or enabling source-side change tracking.

For an append-only source, truncating the bronze Delta table and reloading the full source each night is a low-overhead way to keep it in sync.

A full truncate-and-reload guarantees a match but reads the entire source every night, which scales poorly and ignores the append-only nature. It adds cost and run time, the very overhead a high-water-mark watermark is meant to avoid.

In Microsoft Fabric, where do you see recent runs of pipelines, Dataflows Gen2, and notebooks together in one status view?

The Monitoring hub is the central place that aggregates run activity across item types into a single filterable list showing each run's status and start time. This lets you spot overnight failures across many Data Factory pipelines, Dataflows Gen2, and Spark notebooks at once, without opening each item's own history.

To check whether dozens of overnight jobs succeeded, you should open each pipeline and notebook's run history one by one.

Per-item run history only shows that single item's runs and forces manual, item-by-item checking. The Monitoring hub already consolidates runs across all item types into one filterable list with status and start time, so there is no need to open each item separately.