Microsoft DP-700 Practice Test 18

Question 170

A target retains rows that were deleted in the source, although timestamp-based incremental copy continues running successfully. Why?

The source deletion generated a later modification timestamp on the now-missing row.
Target retention automatically preserves deleted rows because the source has an RLS policy.
The watermark scan observes surviving rows with newer values but receives no tombstone or delete event for a vanished source row.
The CDC connector dropped a delete event while copying a supported change feed.

Explanation

Correct Answer

Deletion cannot be inferred reliably from a monotonic timestamp on records that no longer exist; CDC or full reconciliation is needed.

Incorrect Answers

A deleted row is no longer returned by the ordinary source table scan, so a watermark column cannot emit its tombstone or removal by itself.

RLS controls read visibility for identities. The issue is that the copy pipeline received no delete operation from its watermark scan.

The scenario states timestamp-based incremental copying, not CDC. No source delete event was captured for the target to apply.

Question 171

After configuring CDC-backed copying, which validation proves source deletion semantics reached the destination?

Insert and update source rows but never delete a controlled key.
Delete a row only in the target and call it evidence of CDC replication.
Check the CDC subscription configuration without comparing the target key set.
Insert, update and delete controlled source keys, run the supported change-feed load and verify the target applies each operation including the deletion.

Explanation

Correct Answer

Testing a deletion specifically distinguishes CDC correctness from insert/update-only incremental behavior.

Incorrect Answers

Inserts and updates are supported by both watermark and CDC paths. A deliberate delete is necessary to demonstrate removal semantics reached the destination.

Manual target deletion does not establish that the Fabric job received and applied the source change event.

Enabled CDC alone cannot prove the target applied a delete. Confirm the specific vanished source key disappears from the destination after the job runs.

Question 172

A Fabric Copy job must load an entire legacy dataset once and then transfer only new changes after go-live. Which configured sequence fits?

Perform the initial full copy and then use supported incremental mode with maintained successful-run state for later loads.
Run the entire historical initial snapshot as a full append on every later schedule.
Skip the initial baseline load and begin with a high watermark set to the current timestamp.
Initialize a watermark without persisting it between executions, assuming later jobs inherit it automatically.

Explanation

Correct Answer

An incremental copy job establishes the baseline on its first run and subsequently tracks changes from the last successful checkpoint.

Incorrect Answers

Repeated full appends duplicate previously loaded data rather than restricting subsequent movement to changes.

Existing historical records would be absent from the Fabric target after go-live.

Without durable checkpoint state the job cannot reliably know which source changes have already been processed.

Question 173

A team builds a custom Fabric pipeline that starts immediately with a high watermark from the current day, instead of first loading the full historical baseline into its new empty target. Only recent rows arrive. What is the loading gap?

Advance the incremental watermark to tomorrow so the pipeline will automatically include all earlier historical source records.
The initial full-history load or reset-to-full baseline was not completed before relying on subsequent incremental deltas.
The target was filtered by a watermark lower than all historical records.
The schema of the oldest record differs slightly from recent rows.

Explanation

Correct Answer

Incremental changes do not necessarily reconstruct records that predate the saved start state; baseline completeness must be established first.

Incorrect Answers

Moving the lower-bound watermark farther forward excludes still more older records. The empty target requires a deliberate historical baseline load before relying on later deltas.

An incremental-only extraction after its starting position can omit the history. The failing design is the missing baseline, not an inherently too-low threshold.

A schema discrepancy could affect selected rows, but the stated systematic absence of history follows from relying on deltas before performing the first full copy.

Question 174

Following baseline backfill, which acceptance test verifies the conversion to incremental copy?

Verify the second Copy job run succeeded without comparing what it transferred.
Check only the final target row count after two runs, ignoring which source records were newly changed.
Reconcile full source and target counts after the first run, then add a few source changes and confirm the second run copies only those changes.
Clear the incremental checkpoint repeatedly and assume the sequence is correct.

Explanation

Correct Answer

The first-run total and second-run delta test verify both historical coverage and proper incremental state retention.

Incorrect Answers

A green status can reflect a full copy, an empty incremental batch, or missing changes. The first complete baseline and later delta must be reconciled.

Totals can match despite re-copying history or dropping changed rows. The second-run source selection is essential.

Resetting Copy state can trigger a new baseline and duplicates under append. It is not an acceptance test for proper full-then-delta transition.

Question 175

A custom watermark pipeline crashes after reading a new range but before committing its target merge. When should it move the persisted high watermark?

Advance the persisted high watermark as soon as the source query returns results.
Change the high watermark to a later arbitrary time to bypass failed source records.
Commit the new watermark before writing the target and rely solely on Copy retries for safety.
Advance the committed watermark only after the corresponding target transaction succeeds, with idempotent retry logic for the same interval.

Explanation

Correct Answer

Checkpointing ahead of the sink commit loses unprocessed changes; deferring state advancement until durable success avoids gaps.

Incorrect Answers

If the target merge then fails, those uncommitted rows may be skipped on the next attempt.

Skipping unprocessed events conceals a failed load and violates durable incremental progress.

Retries cannot recover skipped source rows when the stored watermark already advanced beyond them.

Question 176

A source batch was extracted, its watermark immediately advanced and the sink write failed. Rerunning skips those records. What caused the data loss?

The checkpoint advanced before a successful target write, so the retry starts past changes that never reached the destination.
The sink’s merge step succeeded but the source watermark column was not indexed.
The high watermark is defined in UTC, so every failed write changes time zones.
The retry selected duplicate records because a Delta table was optimized.

Explanation

Correct Answer

Extraction alone is not a durable data-loading success. State and sink commit must be coordinated, or use a supported Copy job that maintains successful-run state.

Incorrect Answers

Indexing can affect query performance, not whether data already skipped by an early checkpoint is retried. The failed sink commit left a gap.

UTC representation is not the cause here. The checkpoint was persisted before the target transaction, violating the progress-after-commit requirement.

Compaction does not advance a source checkpoint or cause skipped source keys. Persisting progress before sink success creates the missing interval.

Question 177

A recovery design claims to handle interrupted incremental loads. Which test proves it?

Test only a successful initial load with no induced failure.
Force failure after extraction but before target completion, rerun the same interval and verify every expected key appears once before checkpoint advancement.
Restart after deleting the source rows and accept a clean zero-row target.
Inspect the watermark timestamp without comparing the committed target business keys.

Explanation

Correct Answer

An injected mid-run failure validates no-gap, no-duplicate recovery across the checkpoint and target commit boundary.

Incorrect Answers

A clean run cannot expose the premature-checkpoint defect. Force the failure between source extraction and sink commit.

Removing input rows destroys the evidence needed to verify safe replay and correct checkpoint progression.

A persisted checkpoint could have advanced even while target writes failed. Reconciliation must show exact-once retained keys and progress only after commit.

Question 178

Transaction events may arrive up to two hours after their event-time timestamp. Aggregations must include late arrivals in the intended date bucket. Which pattern is suitable?

Group results only by ingestion date because arrival time is always equal to event time.
Set the lateness allowance to zero and drop all records with event timestamps before the latest batch.
Use event-time logic with a bounded lateness or reprocessing window suited to the maximum expected delay, and update affected aggregates.
Increase the Spark trigger interval without defining event-time state and watermark behavior.

Explanation

Correct Answer

A processing-time-only cutoff can discard events whose valid event timestamp predates their arrival; the window policy must accommodate late data.

Incorrect Answers

The scenario permits two-hour delays, so arrival-date aggregation can place valid events in the wrong bucket.

That policy explicitly excludes the delayed events the business requires to count.

Slower micro-batches do not automatically honor event-time windows or bounded late arrivals.

Question 179

A streaming aggregate misses transactions that arrive 45 minutes after their event timestamps. Its watermark permits only five minutes of lateness. Why?

The late events are automatically assigned to the next calendar date instead of the event-time window.
The input uses a decimal amount field that Spark converts to a string.
The stream’s source checkpoint was deleted before every microbatch.
The event-time watermark advances past these late timestamps and the stateful aggregation may drop them as too late.

Explanation

Correct Answer

A watermark is a bounded-lateness policy, not a synonym for keeping every past event indefinitely.

Incorrect Answers

A too-short event-time watermark may drop events after state has advanced. It does not necessarily reassign the old event into a later correct window.

The scenario isolates event timestamps and a five-minute lateness threshold. A numeric cast is not the reason 45-minute-late events disappear.

A missing checkpoint would cause offset/replay issues, not systematically exclude records 45 minutes late when the event-time watermark is five minutes.

Question 180

After extending an event-time lateness boundary, what validation is most direct?

Inject on-time and deliberately late events with known timestamps, then compare final window aggregates and any intentionally dropped beyond-boundary events.
Only send events in timestamp order and compare their final row counts.
Inspect the watermark configuration text without running windowed aggregation.
Sort results by ingestion timestamp and infer that the event-time buckets are correct.

Explanation

Correct Answer

This checks the actual event-time cutoff and update behavior rather than only counting messages that reached the streaming input.

Incorrect Answers

On-time inputs never exercise a late-arrival allowance. Include deliberately late records within and beyond the configured boundary.

A configured delay can be appropriate yet the actual stateful query can still produce wrong results; check the resolved event-time buckets.

Processing-time order differs from event time. The test requires known timestamps and expected aggregate membership for each window.

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

Microsoft DP-700 Practice Test 16 - 10 Questions (Last Reviewed 19-Oct-2026)
Microsoft DP-700 Practice Test 17 - 10 Questions (Last Reviewed 18-Oct-2026)
Microsoft DP-700 Practice Test 18 - 10 Questions (Last Reviewed 17-Oct-2026)
Microsoft DP-700 Practice Test 19 - 10 Questions (Last Reviewed 16-Oct-2026)
Microsoft DP-700 Practice Test 20 - 10 Questions (Last Reviewed 15-Oct-2026)

Pass Your Microsoft DP-700 Exam Easy!

Question 170

Explanation

Correct Answer

Incorrect Answers

Question 171

Explanation

Correct Answer

Incorrect Answers

Question 172

Explanation

Correct Answer

Incorrect Answers

Question 173

Explanation

Correct Answer

Incorrect Answers

Question 174

Explanation

Correct Answer

Incorrect Answers

Question 175

Explanation

Correct Answer

Incorrect Answers

Question 176

Explanation

Correct Answer

Incorrect Answers

Question 177

Explanation

Correct Answer

Incorrect Answers

Question 178

Explanation

Correct Answer

Incorrect Answers

Question 179

Explanation

Correct Answer

Incorrect Answers

Question 180

Explanation

Correct Answer

Incorrect Answers

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