Free DP-700 practice questions

Fabric creates a starter pool for every workspace: a prehydrated live pool of medium nodes that starts Spark sessions in seconds. Custom pools trade that speed for control over node size, family and scaling.

The deciding facts are 'within seconds' and 'nothing configured'. Only the starter pool is already warm and needs no setup. Any custom pool, even a single-node one, is provisioned when a session starts and takes minutes. Attaching an environment with extra libraries adds work and lengthens startup because the libraries are installed into the session.

1. Identify the requirement: interactive work, session ready in seconds, no prior setup.
2. Recall which compute is prehydrated: only the starter pool.
3. Rule out custom pools of any size, since they cold-start.
4. Rule out library customization, since it adds setup and startup time.

Exam tip: Seconds to start with no setup = the starter pool; any custom pool or custom-library install costs startup time.

Incremental loading with a watermark (high-water-mark) column copies only rows created or changed since the previous run, using a reliably maintained, increasing column such as a last-modified timestamp.

The source has a LastModifiedDate column that is set on every insert and update, which is the prerequisite for the watermark pattern. The pipeline stores the highest value it has loaded, extracts rows above it, and merges them so updated rows replace their earlier versions. A full reload and a hash comparison both read the whole 2 TB table, and a calendar-date append both misses late changes and duplicates updated rows.

1. Check whether the source has a reliably maintained, increasing change column; here LastModifiedDate qualifies.
2. Store the highest LastModifiedDate loaded so far in a control table.
3. Each run, extract rows above the stored value and merge them into the target on the business key.
4. Save the new maximum LastModifiedDate from the extracted rows for the next run.

Exam tip: Large table + reliable change column = watermark incremental load; reserve full reloads for small or change-opaque sources.

The Monitoring hub is Fabric's centralized operational monitoring surface. It aggregates run activity for pipelines, Dataflow Gen2, notebooks, Spark job definitions, and other supported items across the workspaces a user can access.

The requirement is a single cross-item, cross-workspace view of run history and current status. That is exactly what the Monitoring hub provides: each row is a run (or refresh) with its status, start time, duration, submitter, and a drill-through link into the item-specific run details. The other options solve different problems: the OneLake catalog is for data discovery and governance, the Capacity Metrics app is for capacity-level consumption and throttling analysis, and lineage view is for dependency mapping — none of them lists job runs and their statuses.

1. Open the Monitoring hub from the Fabric navigation pane.
2. Use the column filters to narrow by item type (pipeline, dataflow, notebook, Spark job definition), status, start time, or submitter.
3. Select a run to drill into its item-specific detail page — for example, activity-level detail for a pipeline or the Spark application view for a notebook run.

Exam tip: For cross-item run history and status in Fabric, go to the Monitoring hub; use the Capacity Metrics app only for capacity-level consumption questions.

Starter pools use fixed medium nodes (admins can only adjust their maximum nodes and executors). Custom pools let the admin choose the node family and size, which sets the memory available to each executor.

The symptom is per-executor memory, and the stem rules out scaling out. Only a bigger node gives each executor more memory, and node size can only be chosen on a custom pool, which the capacity permits here. Raising starter-pool limits adds more medium executors; high concurrency and runtime versions don't change executor memory.

1. Classify the problem: each executor lacks memory (scale up), not too few executors (scale out).
2. Note that the stem says scaling out has not helped.
3. Recall that node size is fixed on the starter pool and selectable on a custom pool.
4. Confirm the capacity allows workspace custom pools, then create one with larger nodes.

Exam tip: More memory per executor = bigger nodes = a custom pool; starter pools only scale out on medium nodes.

A full load replaces the destination with the complete source on every run. It is the right pattern when the source is small and offers no reliable way to detect change, because it captures inserts, updates and deletes without any change-tracking machinery.

With 3,000 rows and no change column, reloading costs almost nothing and guarantees an exact copy. The tempting MERGE upsert handles inserts and updates but misses removals unless it also deletes target rows that are not in the source. A business-key "watermark" is not a change indicator, and appending daily snapshots never makes the table itself match the list.

1. Check the table size: 3,000 rows is trivial to reload.
2. Check for a change indicator: there is none, so a watermark load cannot work.
3. Check the delete requirement: removed currencies must disappear, which an insert-and-update MERGE does not do.
4. Choose a full overwrite, which handles inserts, updates and deletes in one step.

Exam tip: Small table, no change indicator, deletes must be reflected = full load (overwrite).