Free DP-700 practice questions

Fabric offers two kinds of Spark pools: starter pools (prehydrated, Microsoft-managed live clusters) and custom pools (user-defined node size, autoscale, and executor settings).

The starter pool is the default compute for a workspace and is kept warm by Fabric, so an interactive session begins in seconds with no setup — exactly the least-effort, fastest-start option. A custom pool must be defined first and its nodes are provisioned when the session starts, which typically takes a few minutes. An Airflow job is an orchestration tool and irrelevant to session startup speed, and attaching an environment with extra libraries adds personalization time rather than removing it.

1. Identify the requirement: instant session start plus no upfront compute configuration.
2. Recall that starter pools are always-on, prehydrated clusters managed by Fabric with default medium node sizing.
3. Recall that custom pools trade startup speed for control: they are created in workspace Spark settings and spin up on demand.
4. Eliminate orchestration (Airflow) and library packaging (environments) because neither is a compute-startup feature.

Exam tip: Choose the starter pool for instant, zero-config Spark sessions; choose a custom pool when you need specific node sizes or scaling behavior.

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

The source exposes a reliably maintained LastModifiedDate column, which is exactly the prerequisite for the watermark pattern. The pipeline stores the highest watermark value it has loaded, and each run filters the source with WHERE LastModifiedDate > <stored watermark>, moving only the changed 0.5% of rows. A full reload moves 2 TB to capture roughly 10 GB of change, hash comparison still scans the whole source, and streaming solves a latency problem this nightly batch job does not have.

1. Check whether the source has a reliably updated, monotonically increasing column (timestamp or ID); if yes, the watermark pattern applies.
2. Persist the maximum watermark value loaded in each run, then filter the next extraction with WHERE watermark_column > stored_value.
3. Merge or append the extracted delta into the Lakehouse Delta table, then update the stored watermark to the new maximum.
4. Reserve full loads for small tables or sources with no trustworthy change indicator.

Exam tip: When a source has a reliable last-modified or incrementing column, use it as a watermark and load only the delta.

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.

Custom Spark pools in Fabric workspace settings define the hardware profile of Spark compute: node family, node size, autoscale range, and dynamic executor allocation.

Only a custom pool lets you pick a memory-optimized node family and a larger node size, directly addressing executor memory pressure. High concurrency mode is about session sharing, not sizing. An environment configures software (runtime, libraries, Spark properties), not hardware. A shortcut changes where data is read from, not how much memory the computation consumes.

1. Diagnose the problem as insufficient executor memory (disk spill during wide joins).
2. Map the fix to compute hardware: node family and node size are pool-level properties.
3. In workspace settings, open Data Engineering/Science > Spark settings and create a new pool with the memory-optimized family and a larger node size.
4. Set the notebook or Spark job definition to use the new pool and re-run the workload.

Exam tip: Node family and node size are configured on a custom Spark pool — environments configure software, pools configure hardware.

Full loads replace the entire destination table each run. They are the right choice when the table is small, when the source offers no reliable change indicator, or when hard deletes must be reflected and cannot otherwise be detected.

Incremental patterns depend on being able to identify what changed; this source has no watermark column and no change tracking, and it hard-deletes rows. A full daily reload of 3,000 rows is effectively free, is idempotent, and always leaves the destination as an exact snapshot of the source. The sophistication of CDC or watermarking buys nothing at this scale and the append option actively corrupts the data.

1. Assess table size and change-detection options: no watermark column, no CDC, deletes present, tiny table.
2. Choose a full load: truncate-and-reload or overwrite the Delta table with each daily extract.
3. Schedule the pipeline daily; the run cost is negligible at this row count.
4. Revisit the pattern only if the table grows large enough that a full reload becomes expensive.

Exam tip: Small reference tables with no change tracking are best handled with a simple full reload, which also naturally handles deletes.