Microsoft DP-700 Practice Test 17

Question 160

A Fabric production pipeline must target a production SQL connection, while the same workflow in test targets a sandbox connection. What design minimizes hard-coded stage-specific details?

Use supported pipeline parameters or variable-library references for stage-specific connection settings and bind the activities to the resolved values.
Keep the Test SQL connection hard-coded and change only the pipeline item name to Production.
Use a workspace domain assignment as the only stage-specific connection selector.
Define a production variable but leave the Copy activity using its literal Test source.

Explanation

Correct Answer

Environment-scoped configuration separates deployment logic from connection details and avoids accidentally copying a test endpoint literal into production.

Incorrect Answers

Renaming the pipeline does not change which SQL source Copy actually queries; the active binding remains the sandbox.

Governance domain labels do not substitute for a production parameter, variable-library value or real Copy connection mapping.

Creating a variable alone does not alter the activity. It must be referenced in a supported expression at run time.

Question 161

A production pipeline unexpectedly reads test data after promotion. Its Copy activity contains a literal Test connection instead of the configured production variable. Why?

The production variable library automatically replaces every literal source connection in Copy activities.
The activity still uses a hard-coded source binding and does not evaluate the production-stage connection variable.
A parameterized pipeline must be in a different Fabric domain to resolve the production source.
The SQL source can be chosen only by setting a Spark environment default.

Explanation

Correct Answer

A variable library or parameter exists only as configuration until the activity actually consumes it in its connection expression.

Incorrect Answers

Creating a stage-specific variable does not override a hard-coded Test connection unless the activity binds to that variable or parameter.

Governance domain association is not a runtime connection selection mechanism. The activity ignored the variable because its source remained literal.

A Copy activity uses its configured connection binding; Spark environment selection does not replace a stage-specific SQL connection literal.

Question 162

A production connection variable is introduced. What verifies the release binds the correct source?

Inspect only the variable-library value while leaving the activity source expression unchecked.
Run the pipeline in Test and infer that the Production stage will use different connections.
Inspect the effective connection during a controlled production-stage run and reconcile destination records to production-only known source keys.
Check only that the pipeline item appears in the Production workspace.

Explanation

Correct Answer

A live resolved connection and data provenance test detect accidental use of a test endpoint despite otherwise successful job execution.

Incorrect Answers

A correct production variable does not establish that the activity evaluates it instead of retaining a Test literal.

The target stage may still bind to the same literal Test source. Validate the connection and production-only data at Production.

Item deployment does not prove that the effective source connection resolves to the approved Production database.

Question 163

An event-based pipeline occasionally receives duplicate notifications for the same delivered file. How should the ingestion workflow avoid duplicate target rows?

Set storage notifications to at-most-one by renaming duplicate files after they arrive.
Append all event payload rows with a new random identifier on each retry.
Ignore repeat delivery events whenever pipeline execution status is already Succeeded for any file.
Filter trigger scope and implement idempotent processing keyed by a stable delivery identifier or target business key, with an atomic commit boundary.

Explanation

Correct Answer

File-event systems may redeliver. Idempotence prevents a retry or duplicate notification from appending the same logical records twice.

Incorrect Answers

File renaming does not make event delivery or pipeline execution exactly once. The sink must recognize duplicate business records.

Random IDs make repeated logical events look distinct, worsening duplication instead of preserving a stable deduplication key.

An unrelated previous successful run is not a reliable identity for the current delivery. Idempotency needs a stable key and a transactionally correct commit test.

Question 164

A storage-event trigger starts two runs for one file and both blindly append identical rows. What fundamental defect causes duplicate data?

The ingestion path lacks a stable deduplication/upsert or exactly-once business commit strategy for repeated delivery events.
Duplicate file notifications are always collapsed into one successful target insert by the event trigger.
Changing the stored file name on each retry prevents two appended copies of the same business rows.
The target automatically deduplicates all records whenever the pipeline activity reports Succeeded.

Explanation

Correct Answer

At-least-once triggering or duplicate notifications require sink-side idempotence; an append-only design duplicates work.

Incorrect Answers

Event delivery and data commits are distinct. The pipeline must implement a stable dedupe key or idempotent merge to tolerate repeated events.

Randomly renaming deliveries creates new identifiers but does not recognize repeated logical data, so duplicate appends remain possible.

A successful append can be executed twice; the sink requires explicit key-based reconciliation or an equivalent atomic exactly-once business boundary.

Question 165

An idempotent event-based ingestion workflow is deployed. Which test demonstrates that duplicate events are safe?

Replay two events with different business keys and declare duplicate-handling verified.
Emit the same logical delivery event twice and verify both runs’ audit identities while the target retains only one committed record per stable business key.
Compare only the two pipeline run statuses, without inspecting target records.
Confirm the storage trigger is enabled and assume the sink is idempotent.

Explanation

Correct Answer

The repeated-notification test verifies idempotence at the durable sink, rather than merely checking event trigger health.

Incorrect Answers

Different keys test two legitimate rows, not whether two deliveries of the same logical file are collapsed into one committed target row.

Both runs may legitimately succeed while blind append produces duplicate business rows. The table invariant is the real acceptance condition.

Trigger configuration controls invocation, not target commit semantics. Duplicate-event replay under a stable identifier must be tested.

Question 166

An operational database has a reliable `ModifiedUtc` value that changes on every insert or update. A daily Fabric load must transfer only changes. What loading pattern fits?

Recreate the entire destination on every daily run and append the full source snapshot.
Use only the record creation timestamp as the watermark, excluding updates to existing keys.
Use watermark-based incremental extraction with an appropriately persisted last-successful checkpoint and a supported destination update method.
Increment the saved ModifiedUtc checkpoint before the Copy job succeeds, regardless of destination commit.

Explanation

Correct Answer

A monotonic modification column can identify new/updated rows between successful runs without reloading unchanged history.

Incorrect Answers

Full append reloads unchanged records every day, contrary to transferring only records whose reliable ModifiedUtc advanced.

Creation time will not advance for an update; a field changing on both inserts and updates is required.

Advancing a checkpoint without successful transfer can permanently skip source changes after a retry.

Question 167

A source record changes, but the next Fabric watermark load does not include it. Investigation shows its `ModifiedUtc` was left unchanged. What caused the miss?

The sink is missing a Delta OPTIMIZE schedule and therefore the source row cannot be selected.
A new source row is excluded because the Copy job has never completed an initial full load.
The source change was automatically converted into a CDC delete record.
Watermark extraction only selects records whose comparison value advances beyond the saved checkpoint; the unchanged timestamp makes the update invisible.

Explanation

Correct Answer

A source timestamp is a valid incremental key only if every relevant modification updates it monotonically.

Incorrect Answers

Storage compaction changes target file layout; it does not alter the watermark predicate applied against source ModifiedUtc. The unchanged timestamp is the selecting defect.

The scenario concerns a previously loaded record changed after the checkpoint. It is missing because its ModifiedUtc did not advance, not because no initial baseline exists.

No CDC delete behavior is described. A watermark scan compares rows by a monotonic change column; updates that fail to update that column are invisible.

Question 168

After configuring watermark incremental loads, which test best establishes that the pipeline transfers changes rather than full history?

Run an initial load, modify one source row with a later watermark, then compare subsequent source selection, changed target record and checkpoint advancement.
Compare only the initial and final total row counts after one full load.
Check that the ModifiedUtc column exists in the source schema but do not update any record.
Query the target as a workspace Admin but ignore the Copy job checkpoint and transfer metrics.

Explanation

Correct Answer

A two-cycle test distinguishes genuine incremental state from blindly copying the entire source table on each invocation.

Incorrect Answers

A full load count can match even if the next incremental pass still scans all history or misses updates. The test must span at least one changed source row and later watermark.

Column presence is not proof that the incremental predicate and successful-run state are used. A real change after the baseline exercises the boundary.

The existing target could contain the right value from a full reload. Inspecting the next source selection and advanced checkpoint distinguishes true incremental behavior.

Question 169

A source database emits deletes and the target Fabric table must reflect those deletions. Which source change-detection method is appropriate when supported?

Select a modification-timestamp-only watermark and assume it emits explicit row-deletion events.
Use a supported change-data-capture feed and apply inserts, updates and deletes at the target using suitable write semantics.
Copy new inserts and leave deleted source rows in the target indefinitely.
Delete every destination record at each run instead of identifying specific deleted business keys.

Explanation

Correct Answer

CDC records delete operations that an ordinary increasing-timestamp comparison cannot discover once rows vanish from the source.

Incorrect Answers

Deleted rows may no longer be returned by incremental selects; use supported CDC/tombstones for deletes.

An insert-only pipeline cannot make the Fabric target reflect source removals.

A destructive full reset is unnecessary for supported change feeds and risks losing valid target state.

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.

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

Microsoft DP-700 Practice Test 15 - 10 Questions (Last Reviewed 20-Oct-2026)
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)

Pass Your Microsoft DP-700 Exam Easy!

Question 160

Explanation

Correct Answer

Incorrect Answers

Question 161

Explanation

Correct Answer

Incorrect Answers

Question 162

Explanation

Correct Answer

Incorrect Answers

Question 163

Explanation

Correct Answer

Incorrect Answers

Question 164

Explanation

Correct Answer

Incorrect Answers

Question 165

Explanation

Correct Answer

Incorrect Answers

Question 166

Explanation

Correct Answer

Incorrect Answers

Question 167

Explanation

Correct Answer

Incorrect Answers

Question 168

Explanation

Correct Answer

Incorrect Answers

Question 169

Explanation

Correct Answer

Incorrect Answers

Question 170

Explanation

Correct Answer

Incorrect Answers

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