Free DP-700 practice questions

A data engineering team runs many small notebook jobs in a Microsoft Fabric workspace. Each job currently waits several minutes before its Spark session is ready, and the delay dominates the short run times. The team wants new sessions to start in a few seconds without permanently reserving compute. Which Spark workspace setting should they configure to meet this requirement?

• AKeep the starter pool enabled so pre-warmed nodes back the workspace, letting Spark sessions begin in seconds without reserving a dedicated cluster.check_circle Correct
• BRaise the default node size on the starter pool so each session has more memory and processing power available the moment it begins running.
• CEnable high concurrency for the workspace so several notebooks share one Spark session and a new notebook reuses the already-running session.
• DCreate a custom Spark pool with autoscale disabled and a fixed minimum node count so the cluster is always sized and ready for incoming jobs.

Why A is correct: The starter pool holds pre-allocated, pre-warmed nodes for the workspace, so a session attaches in a few seconds and the nodes are released when idle, which matches the need for fast starts without permanently reserved compute.

Why B is wrong: Larger nodes give each session more compute but do nothing about the cold-start delay; provisioning time is the stated problem, and bigger nodes can actually take longer to acquire rather than shortening startup.

Why C is wrong: High concurrency lets notebooks share a session and helps once a session exists, but the very first session in the workspace still pays the full provisioning cost, so it does not on its own deliver the few-second start the team wants.

Why D is wrong: A custom pool with a fixed floor would be ready, but a cold custom pool still provisions on demand and a permanent floor reserves compute continuously, which contradicts the requirement to avoid permanently reserving capacity.

An organisation wants every data engineering team to reuse the same set of public Python libraries, a shared Spark configuration, and consistent runtime versions across all of their notebooks and Spark job definitions in a Microsoft Fabric workspace. They want to define this once and attach it rather than reconfiguring each item. Which Fabric construct should they create to satisfy this requirement?

• AAdd the libraries and Spark properties to each notebook with inline pip commands and session configuration cells so every notebook carries its own setup.
• BCreate a Fabric environment that bundles the runtime, Spark properties, and libraries, then attach it as the workspace default for notebooks and Spark job definitions.check_circle Correct
• CConfigure a custom Spark pool with the required node family and autoscale, since the pool definition also carries the runtime version and the attached library set.
• DPublish the libraries to a OneLake folder and reference that path from each notebook so the dependencies load from shared storage at session start.

Why A is wrong: Inline installs and session cells do work per notebook, but they must be repeated in every item and drift apart over time, which is exactly the per-item duplication the team is trying to avoid.

Why B is correct: A Fabric environment is the reusable container for runtime version, Spark configuration, and libraries; attaching it as the workspace default applies the same setup to every notebook and Spark job definition without per-item configuration.

Why C is wrong: A custom Spark pool controls compute sizing and scaling, but it does not hold libraries or runtime version; those belong to an environment, so the pool alone cannot standardise the shared library and runtime requirement.

Why D is wrong: OneLake stores data and files, not managed Spark library installs; pointing notebooks at a folder does not register packages in the Spark session, so this neither installs the libraries nor standardises runtime or Spark properties.

A Fabric administrator is organising the tenant so that the finance, sales, and operations groups each manage their own set of workspaces, apply their own governance, and have a dedicated landing page that groups their content. The administrator wants a tenant-level grouping construct that workspaces are assigned to, rather than relying on workspace names alone. Which Microsoft Fabric feature should the administrator use?

• AAssign each group's workspaces to a separate Fabric capacity so the capacity boundary acts as the grouping that keeps each group's content together.
• BUse a OneLake shortcut from a parent workspace into each group's workspace so all of the group content appears under one shared catalogue view.
• CCreate a domain for each business group and assign that group's workspaces to its domain, with a domain admin governing the grouped content.check_circle Correct
• DCreate a workspace folder hierarchy inside one shared workspace and place each group's items in its own folder under that single workspace.

Why A is wrong: Capacity governs compute and billing, not logical content grouping; several unrelated groups can share one capacity and one group can span several capacities, so the capacity boundary does not provide the data-ownership grouping described.

Why B is wrong: A shortcut surfaces data items in place across workspaces, but it is a data-access mechanism, not a tenant grouping with delegated governance, so it cannot give each group its own managed boundary and landing page.

Why C is correct: Domains are the tenant-level construct for grouping workspaces by business area, with delegated domain admins, domain-scoped governance, and a domain landing experience, which is exactly the per-group ownership and grouping the administrator wants.

Why D is wrong: Folders organise items within a single workspace and do not provide separate, delegated governance per group across multiple workspaces; the requirement is a tenant-level grouping of whole workspaces, which folders cannot express.

A nightly pipeline ingests an append-only sales event table from an on-premises SQL Server source into a bronze Delta table in a Microsoft Fabric Lakehouse. Each event row carries an immutable EventId and an ever-increasing CreatedUtc timestamp, and rows are never updated or deleted at source. The team wants each run to copy only rows added since the previous run while keeping operational overhead low. Which design best meets this requirement?

• AStore the highest CreatedUtc loaded so far as a high-water mark, then on each run copy only source rows whose CreatedUtc exceeds that stored value and update the mark.check_circle Correct
• BTruncate the bronze Delta table at the start of every run and reload the entire source table so the destination always matches the source exactly.
• CEnable change data capture on the source table and stream the captured insert, update, and delete records into the bronze Delta table on each run.
• DCopy the full source each run into a staging table, then MERGE staging into bronze on EventId so unchanged rows are skipped during the upsert step.

Why A is correct: An append-only source with a monotonically increasing timestamp is the textbook case for a high-water-mark watermark; querying rows above the stored mark loads only new rows with minimal overhead and no source-side change tracking.

Why B is wrong: A full truncate-and-reload guarantees a match but reads the whole source nightly, which scales poorly and ignores the append-only nature; it adds cost and time the stated low-overhead requirement is trying to avoid.

Why C is wrong: Change data capture is built for sources that change rows; this source is insert-only, so capturing updates and deletes adds source-side configuration and overhead for change types that never occur here.

Why D is wrong: A MERGE on EventId would avoid duplicates, but it still reads the entire source every run; the expensive full read is exactly what a watermark removes, so this keeps the cost the requirement wants to cut.

A silver Delta table in a Microsoft Fabric Lakehouse holds current customer records keyed by CustomerId. The upstream source returns a daily extract of customers whose details changed that day, where a customer may be new or may have an updated address or status. The team needs the silver table to reflect inserts and in-place updates without keeping prior versions of a row. Which load operation best applies the daily extract?

• AAppend the daily extract to the silver Delta table so every changed customer is added as an additional row alongside the earlier version.
• BMERGE the daily extract into the silver Delta table on CustomerId, updating matched rows in place and inserting rows that do not yet exist.check_circle Correct
• COverwrite the entire silver Delta table with the daily extract so the table contains only the customers that changed that day.
• DMERGE the daily extract on CustomerId but mark each matched row inactive and insert a new versioned row to retain the prior address and status.

Why A is wrong: Appending preserves every version and creates duplicate CustomerId rows, so the silver table no longer holds one current record per customer; the requirement asks for in-place updates, not retained history.

Why B is correct: A MERGE keyed on CustomerId performs an upsert: matched customers are updated in place and unmatched ones are inserted, which is exactly the insert-and-overwrite behaviour the Type 1 requirement describes for changed rows.

Why C is wrong: Overwriting replaces the whole table with just the day's changed customers, which discards every unchanged customer; the extract is a delta, not a full snapshot, so an overwrite destroys valid existing rows.

Why D is wrong: This describes a Type 2 history-keeping pattern; it is tempting because it uses MERGE, but the requirement explicitly states prior versions should not be kept, so the added versioning is unwanted overhead.

A Microsoft Fabric Data Factory pipeline copies new order rows into a bronze Delta table using an INSERT for each batch, filtered by an OrderDate watermark. After a transient failure, an operator re-runs the same batch, and the daily revenue totals downstream are now inflated because some orders were inserted twice. The team wants the load to be safe to re-run without producing duplicates. Which change best makes the load idempotent?

• AWiden the OrderDate watermark window by one day on every run so any rows missed by the previous run are guaranteed to be picked up and inserted.
• BWrap the INSERT in a pipeline retry policy with a higher retry count so a failed batch finishes cleanly instead of being re-run by an operator.
• CReplace the INSERT with a MERGE that matches on the order business key, so a replayed batch updates existing rows instead of inserting duplicates.check_circle Correct
• DAppend to a staging table first, then truncate the bronze Delta table and reload it fully from staging on every pipeline run.

Why A is wrong: Overlapping the watermark window reduces the risk of missing rows, but combined with a plain INSERT it actually increases duplication on overlap; it treats the symptom in the wrong direction and does not make re-runs safe.

Why B is wrong: More retries may reduce manual re-runs, but the underlying INSERT still double-counts whenever a batch is replayed for any reason; the load itself remains non-idempotent, so duplicates can still occur.

Why C is correct: Keying the MERGE on the order business key makes the operation idempotent: a replayed batch matches rows already present and updates them in place rather than inserting copies, so re-running the same batch leaves the table unchanged.

Why D is wrong: A full reload would avoid duplicates, but it discards the incremental design and reads everything each run; it solves duplication by abandoning the incremental load rather than making the incremental step replay-safe.

A data engineer manages dozens of scheduled Data Factory pipelines, Dataflows Gen2, and Spark notebooks across a single Microsoft Fabric workspace. Each morning they need one place that lists the recent runs of all of these item types together, with status and start time, so they can quickly spot any that failed overnight without opening each item individually. Which Fabric feature should they use?

• AOpen the run history on each individual pipeline and notebook in turn, reading the per-item activity output to confirm whether the most recent overnight run completed.
• BInstall the Microsoft Fabric Capacity Metrics app and read its timepoint detail page to see which scheduled items ran and whether any of them failed overnight.
• CCreate a Data Activator reflex that watches each pipeline and raises an alert, then review the alert history every morning to learn which runs failed.
• DOpen the Monitoring hub, which lists recent runs of pipelines, Dataflows Gen2, and notebooks together with their status and start time so failures are visible in one view.check_circle Correct

Why A is wrong: Per-item run history does show that item's runs, but checking each item separately is exactly the manual, item-by-item effort the requirement rules out and gives no single consolidated view.

Why B is wrong: The Capacity Metrics app reports compute consumption and throttling against a capacity, not a consolidated success or failure list of individual runs, so it is the wrong tool for spotting failed overnight jobs.

Why C is wrong: Data Activator can alert on conditions, but building and maintaining a reflex per item is heavier than needed and is forward-looking alerting rather than the consolidated run list the engineer asked to review each morning.

Why D is correct: The Monitoring hub aggregates run activity across item types in one filterable list with status and timing, which is precisely the single cross-item view needed to spot overnight failures quickly.

A Data Factory pipeline in Microsoft Fabric failed during its overnight run. The pipeline runs several activities in sequence, and the engineer needs to identify which specific activity failed and read the error message that activity returned, so they can fix the root cause. Where in Fabric should they look first?

• AOpen the failed pipeline run in the Monitoring hub and drill into its per-activity run details, where each activity shows its status and the error output it returned.check_circle Correct
• BOpen the Capacity Metrics app and inspect the throttling and overload chart for the time of the run to determine which activity inside the pipeline failed.
• COpen the Spark application monitoring page for the workspace and read the executor logs to find the pipeline activity that raised the error overnight.
• DOpen the deployment pipeline comparison view and inspect the differences between stages to see which activity changed and therefore caused the run to fail.

Why A is correct: Drilling into a pipeline run exposes the per-activity breakdown with each activity's status and error message, which is exactly what isolates the failing activity and its root-cause detail.

Why B is wrong: Capacity metrics show consumption and throttling for the capacity as a whole and do not break a pipeline down into its activities, so they cannot name the activity that failed or its error text.

Why C is wrong: Spark application monitoring covers notebook and Spark job runs, not Data Factory pipeline activity orchestration, so the failing pipeline activity and its error would not appear there.

Why D is wrong: A deployment pipeline compares content between environment stages for release management and has no run history or activity error output, so it cannot reveal which activity failed at runtime.

An engineer is troubleshooting a Spark notebook in Microsoft Fabric that succeeds but runs far slower than expected. They want to inspect the jobs, stages, and tasks of the most recent execution, including the Spark UI, to find which stage is spending the most time and whether data is skewed. From which starting point can they reach this detail?

• AThe Capacity Metrics app timepoint page, which lists the notebook's individual Spark stages and tasks along with their durations for the slow run.
• BThe notebook's recent run in the Monitoring hub, from which the engineer can open the Spark application detail and the Spark UI showing jobs, stages, and tasks.check_circle Correct
• CThe deployment pipeline stage view, which surfaces the notebook's executor timeline and shuffle metrics once the notebook is promoted between workspaces.
• DThe dataset refresh history of the semantic model that the notebook populates, which records the Spark task durations for each refresh of the notebook.

Why A is wrong: The Capacity Metrics app reports capacity-level consumption and does not expose a notebook's Spark jobs, stages, and tasks, so it cannot show the per-stage timing needed to find the slow stage.

Why B is correct: A notebook run in the Monitoring hub links to its Spark application monitoring and the Spark UI, where jobs, stages, and tasks with their durations reveal the slow stage and any skew.

Why C is wrong: Deployment pipelines manage promotion of content between stages and carry no Spark execution telemetry, so the executor timeline and shuffle metrics for a run are not available there.

Why D is wrong: Semantic model refresh history tracks dataset refresh operations, not the Spark jobs and stages of a notebook execution, so it is the wrong source for stage-level timing and skew analysis.