Microsoft DP-700 Practice Test 38

Question 370

A pipeline continues missing its SLA after Copy was optimized from five to three minutes. The transform still takes 80 minutes. Why is the gain small?

The optimized activity was not the dominant critical-path bottleneck; transformation runtime still controls nearly all end-to-end duration.
The pipeline's total time is dominated by the Copy step because it runs first.
Reducing Copy from five to three minutes should remove almost all total latency.
The remaining duration is a dashboard refresh display artifact rather than actual processing.

Explanation

Correct Answer

Reducing a minor component cannot materially improve the full run while the principal long-running activity remains unchanged.

Incorrect Answers

Copy is only five minutes; the downstream 80-minute transform dominates elapsed time.

Saving two minutes cannot substantially improve a pipeline still dominated by the long transformation.

Observed transform duration is 80 minutes, so instrument the activity instead of blaming presentation.

Question 371

The long transformation is optimized. What test shows the overall pipeline SLA genuinely improved?

Check only the optimized transform activity duration and ignore pipeline dependencies.
Compare one pipeline run with a much smaller input volume and claim an improvement.
Measure source Copy row counts but never inspect the 80-minute notebook output validity.
Compare representative full-run and per-activity durations across equivalent input sizes, including dependency wait and actual output parity.

Explanation

Correct Answer

Overall completion time and data correctness both matter; a faster isolated notebook does not prove the orchestration meets its deadline.

Incorrect Answers

A faster transform helps but end-to-end SLA also includes other activities, waiting and reruns.

Different input sizes invalidate a direct before/after runtime comparison.

Copy counts alone cannot validate the transformed results or the pipeline's overall runtime.

Question 372

A Fabric pipeline was scheduled for yesterday but no run was submitted. What configuration should operations check?

Inspect the schedule’s enabled state, start/end dates, time zone and expected next occurrence alongside the monitoring run history.
Rerun the pipeline manually and assume its expired schedule will restart itself.
Increase Copy job timeout even though no pipeline run was submitted.
Check only that the pipeline definition is published, without inspecting active schedule dates and time zone.

Explanation

Correct Answer

A disabled, expired or misconfigured schedule can prevent submission even when the pipeline definition is valid.

Incorrect Answers

Manual execution bypasses trigger scheduling and doesn't repair the past end date.

No activity executed, so a Copy timeout cannot explain a missing scheduled submission.

Publication and a valid enabled trigger schedule are separate conditions for automatic runs.

Question 373

A pipeline schedule has a past end date, and runs stopped without a pipeline error. Why?

The trigger did not run because the pipeline's Copy activity returned a 404 yesterday.
The scheduling window expired, so no future pipeline invocations are created even though the activities themselves were unchanged.
The schedule's past end date is ignored automatically while the pipeline remains published.
Fabric requires a manual click after every scheduled execution to authorize the next one.

Explanation

Correct Answer

The trigger lifecycle is independent of whether a previously submitted run succeeded.

Incorrect Answers

No run was submitted; downstream Copy errors cannot explain a schedule that ended before execution.

An expired trigger schedule stops new submissions until corrected or reactivated.

Supported schedules submit runs without manual initiation while their validity and permissions remain correct.

Question 374

After correcting a schedule with no recent submissions, which evidence shows recovery?

Run the pipeline manually and assume the schedule will submit it at the next planned time.
Inspect last week's successful run only, ignoring the current schedule end and activation state.
Verify the future occurrence is in the intended time zone and confirm an actual scheduled run appears under the correct invocation type.
Compare notebook Spark compute sizes instead of trigger logs and submitted run IDs.

Explanation

Correct Answer

The schedule UI and run record together demonstrate that submission—not merely manual execution—is restored.

Incorrect Answers

Manual success doesn't prove the corrected trigger is active at its configured time zone.

Prior success cannot demonstrate future recurrence after an expired schedule was repaired.

Compute sizing doesn't validate the scheduler's next occurrence or eligibility.

Question 375

A production Eventhouse receives telemetry continuously and operators need early warning if ingestion starts failing. Which monitoring should be configured?

Rely only on a dashboard that staff must remember to check manually.
Alert only when an operator opens the Eventhouse query editor.
Monitor KQL query result counts without ingest failures or delivered-event metrics.
Monitor Eventhouse ingestion errors/rates and connect an appropriate supported alert to sustained failures or threshold breaches.

Explanation

Correct Answer

Ingestion telemetry and threshold-based notifications detect failures before analysts notice missing events.

Incorrect Answers

Manual visibility lacks a proactive threshold-driven notification when ingestion begins failing.

A UI-open event doesn't detect a sustained ingestion error period unattended.

Query counts may continue on old data; explicit ingestion errors and backlog are needed for early warning.

Question 376

Eventhouse ingestion fails for 30 minutes, but no one is notified because the only dashboard was checked manually. What observability control is missing?

An automated alert or active monitoring rule was not configured for Eventhouse ingestion failures.
The Eventhouse's query engine automatically sends an email for every failed ingestion attempt.
The dashboard was not given a sensitivity label, so it failed to email operators.
The current KQL table needs a different name to enable notification.

Explanation

Correct Answer

A static dashboard provides passive visibility; it does not deliver timely failure notifications by itself.

Incorrect Answers

Ingestion metrics do not themselves establish an alert rule, recipient and notification action.

Governance labels are unrelated to scheduling or delivering operational ingestion alerts.

Renaming a table does not create a rule that watches ingestion errors or sends on-call messages.

Question 377

An Eventhouse ingestion failure alert is introduced. How should its operation be validated?

Check only that the alert rule appears in the portal without inducing an ingestion error.
Inject a controlled invalid ingestion or temporarily lower a monitored failure threshold and confirm the event and notification appear with correct time and source.
Send only valid events and declare ingestion-failure notification tested.
Use an email from another service as proof that this Eventhouse alert is connected.

Explanation

Correct Answer

An actual alert receipt tied to test telemetry proves detection, threshold evaluation and delivery.

Incorrect Answers

Rule existence doesn't confirm correct error threshold, resource scope or notification delivery.

A successful ingest never exercises the failure condition the alert must detect.

Other service mail delivery does not validate Eventhouse metrics, trigger execution or approved recipients.

Question 378

After publishing a new Fabric Spark environment, nightly notebooks run 40% slower. What evidence should be correlated to isolate a regression?

Compare only two notebook durations and ignore actual published Spark environment versions.
Roll back all workspace items without verifying that the performance change is environment-specific.
Compare environment versions, runtime/pool settings, package changes and representative Spark stage/capacity metrics before and after the update.
Inspect source Delta row counts alone and assume they explain the 40% regression.

Explanation

Correct Answer

A controlled version and workload comparison identifies whether the changed environment or unrelated capacity demand explains the slowdown.

Incorrect Answers

The changed runtime, packages, compute and input data must be correlated to isolate a configuration regression.

Broad rollback risks unrelated changes and doesn't identify the cause of slower notebooks.

Input volume hasn't changed; inspect session runtime, libraries, compute and Spark task telemetry.

Question 379

Notebooks slow immediately after an environment upgrade, while input volume and scheduling are unchanged. Which possible explanation should be tested?

The environment's display name changed, so Spark must execute all transformations more slowly.
The slowdown proves the Delta source has more input rows than the previous night.
The workspace was assigned a different Fabric domain and therefore Spark joined data less efficiently.
The new Spark environment changed runtime, library or compute configuration in a way that increases work for this notebook.

Explanation

Correct Answer

Environment publication can alter effective execution dependencies or pool settings; a version-controlled comparison is needed instead of guessing from the date alone.

Incorrect Answers

A name change doesn't alter runtime libraries or compute; inspect actual published runtime and executor settings.

Input volume is unchanged, so a changed environment's packages/compute should be compared first.

Domain classification does not directly select Spark physical plans or package versions.

Question 380

A team reverts a suspected Spark environment change. What validates that it was the cause of degraded performance?

Run the same notebook with equivalent input under the previous and new environment configurations and compare stage timing, output parity and resource usage.
Confirm only that the rolled-back environment name matches the previous version.
Compare fastest single-run times after rollback against the slowest pre-rollback run.
Ignore job output differences if rollback reduces elapsed time.

Explanation

Correct Answer

An A/B execution controlled for input and capacity establishes technical causality more credibly than simple before/after wall-clock observations.

Incorrect Answers

Names can remain unchanged while published runtime, libraries or compute differ; inspect effective settings.

Cherry-picked timing can misrepresent performance; use comparable representative runs and resource metrics.

A faster run with changed or lost data is not an acceptable environment regression fix.

Implementing Data Engineering Solutions Using Microsoft Fabric (DP-700) Practice Tests

Microsoft DP-700 Practice Test 36 - 10 Questions (Last Reviewed 29-Sep-2026)
Microsoft DP-700 Practice Test 37 - 10 Questions (Last Reviewed 28-Sep-2026)
Microsoft DP-700 Practice Test 38 - 10 Questions (Last Reviewed 27-Sep-2026)
Microsoft DP-700 Practice Test 39 - 10 Questions (Last Reviewed 26-Sep-2026)
Microsoft DP-700 Practice Test 40 - 10 Questions (Last Reviewed 25-Sep-2026)

Pass Your Microsoft DP-700 Exam Easy!

Question 370

Explanation

Correct Answer

Incorrect Answers

Question 371

Explanation

Correct Answer

Incorrect Answers

Question 372

Explanation

Correct Answer

Incorrect Answers

Question 373

Explanation

Correct Answer

Incorrect Answers

Question 374

Explanation

Correct Answer

Incorrect Answers

Question 375

Explanation

Correct Answer

Incorrect Answers

Question 376

Explanation

Correct Answer

Incorrect Answers

Question 377

Explanation

Correct Answer

Incorrect Answers

Question 378

Explanation

Correct Answer

Incorrect Answers

Question 379

Explanation

Correct Answer

Incorrect Answers

Question 380

Explanation

Correct Answer

Incorrect Answers

Implementing Data Engineering Solutions Using Microsoft Fabric (DP-700) Practice Tests