Microsoft DP-700 Practice Test 19

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.

Question 181

A customer dimension contains changing postal addresses and each customer needs a stable warehouse surrogate key. Which design should be adopted?

Assign a new random surrogate key to the same customer on each repeat of the load.
Maintain an explicit business-key-to-surrogate-key mapping and apply the selected slowly changing dimension policy consistently on subsequent loads.
Use postal address as the sole immutable customer identifier.
Set the effective-date end for every customer row to the same load timestamp.

Explanation

Correct Answer

Source business keys identify the same entity across updates, while warehouse surrogate keys support stable fact relationships and intentional SCD history.

Incorrect Answers

A surrogate key must be consistently resolved for each intended dimension member; random retry keys break fact relationships.

Addresses change, so using them as identity can split one customer's historical dimension lineage.

A Type 2 history needs nonoverlapping validity intervals, not a blanket timestamp that corrupts dimension versions.

Question 182

An updated customer record creates a new unrelated surrogate ID on every load even though the business customer identifier is unchanged. What is the design error?

The customer’s postal address is used as the immutable business key, so address edits force a new entity.
A Type 2 policy was intentionally configured with effective-date versioning, so multiple surrogate rows are always an error.
The dimension loading process generates surrogate keys without reconciling the persistent business-key mapping or chosen SCD versioning policy.
A warehouse statistics refresh reset all surrogate identifiers.

Explanation

Correct Answer

Without deterministic entity identity handling, repeated loads fork the same customer into inconsistent dimension members.

Incorrect Answers

Addresses are attributes that can change; the stable business customer key should anchor surrogate-key reconciliation under the selected SCD policy.

Multiple version rows can be correct for Type 2, but the scenario describes unrelated random IDs every retry without stable business-key mapping.

Query statistics do not regenerate dimension surrogate keys. The load incorrectly creates new identities rather than looking up the existing customer and version.

Question 183

A customer dimension upsert is implemented. What tests distinguish Type 1 replacement from Type 2 history when appropriate?

Insert only a brand-new customer and verify that any surrogate key was produced.
Compare dimension row count without inspecting effective dates or business keys.
Change the customer domain assignment and check the renamed table metadata.
Load the same business key with a changed attribute and inspect surrogate-key continuity or versioned effective dates according to the documented SCD policy.

Explanation

Correct Answer

The expected outcome differs by SCD type; verifying only row count cannot demonstrate key and history semantics.

Incorrect Answers

A new entity does not distinguish Type 1 overwrite from Type 2 history behavior. Use the same business key with a changing attribute.

Both SCD strategies can produce acceptable-looking counts for some loads, while key continuity and version history are wrong.

Governance labels do not establish whether a revised business key is overwritten or versioned with valid surrogate identifiers.

Question 184

A fact sale arrives before its product dimension row. How should a modeled Fabric warehouse handle the temporarily unknown product without silently losing the sale?

Use an approved unknown-member or late-arriving dimension strategy, then reconcile the fact’s dimension reference once the member is available.
Discard the sale until the product master appears, then rely on the upstream system to resend it.
Invent a product surrogate key that points to an unrelated valid item.
Remove the product foreign key entirely and treat missing dimensions as always acceptable without tracking.

Explanation

Correct Answer

Late-arriving dimensions require a deliberate referential strategy so the fact is retained and can later be associated with the correct product.

Incorrect Answers

A late product dimension should not silently cause the original fact to be lost.

This makes the fact appear linked to the wrong product, corrupting analytical attribution.

A controlled unknown-member or late-dimension resolution strategy is required to preserve and later reconcile the sale.

Question 185

A nightly fact load discards transactions whenever a referenced dimension record is late, creating unexplained sales gaps. What causes the loss?

The fact table’s business date uses the wrong display time zone.
The transformation uses an exclusionary lookup or inner join without an unknown-member/reconciliation policy for missing dimension keys.
The warehouse cardinality estimator removed unmatched product transactions.
A supported unknown-member row was created but the pipeline reconciled it successfully.

Explanation

Correct Answer

An inner join drops unmatched facts by default, turning temporary dimension delays into permanent missing transactions.

Incorrect Answers

Time-zone mistakes can affect report periods, but the stated missing sale correlates with an absent product dimension key and an exclusionary lookup.

A query optimizer does not intentionally delete fact rows; the ETL join or validation logic excluded them when the dimension lookup failed.

That design would retain the fact and later resolve the product. The described implementation drops the fact instead.

Question 186

After introducing late-dimension handling, which check proves the facts are neither lost nor permanently misclassified?

Validate only invoices whose product dimension was present before the fact arrived.
Check the count of dimension members but ignore the fact’s resolved product foreign key.
Load a fact before its dimension, verify initial unknown-member handling, then add the dimension and confirm the fact resolves to the correct product key.
Insert a late dimension member first and then send the fact, treating that as a late-arrival test.

Explanation

Correct Answer

A two-stage load verifies both preservation at first arrival and subsequent reconciliation of the dimension relationship.

Incorrect Answers

Matched facts never exercise the unknown-member and subsequent reconciliation path.

A dimension row can exist while the fact remains assigned to Unknown or has been lost. Verify both fact retention and later key resolution.

When the dimension is present first, normal lookup succeeds. The required test reverses the order to simulate a late member.

Question 187

A vendor supplies only full nightly snapshots and has no CDC stream or reliable modification timestamp. Changes and deletions still must reach Fabric. What approach fits?

Use a timestamp watermark on snapshot files even though no source change timestamp is available.
Append the entire current snapshot each night and never compare missing keys to the previous snapshot.
Treat missing rows as successfully loaded without reconciling prior-vs-current snapshot keys.
Compare successive source snapshots by stable business key and relevant attributes, applying identified inserts, changes and deletions to the target.

Explanation

Correct Answer

A full snapshot diff can detect removals and modified surviving records when there is no reliable incremental event feed.

Incorrect Answers

An arbitrary snapshot-row timestamp cannot reliably identify changes or deletions between complete source extracts.

Blind append duplicates unchanged records and cannot detect removed source rows.

A complete-snapshot strategy needs key-based comparison to recognize deletions and changed records.

Question 188

A team appends each nightly full source snapshot to a target warehouse table and claims it represents only new changes. Why is the claim wrong?

The incoming snapshot contains unchanged historical rows; append-only processing duplicates them and does not identify deletes.
The target warehouse lacks a clustered index for the new source snapshot.
The team uses a CDC feed but has disabled capturing update operations.
The rows were duplicated because source file names were regenerated while target MERGE handled business keys.

Explanation

Correct Answer

Without key-based comparison or change feed, a full snapshot is not an incremental delta and cannot safely be treated as one.

Incorrect Answers

An index decision is not the reason append-only full snapshots duplicate unchanged rows or fail to identify disappeared source keys.

The source explicitly supplies only full snapshots and no CDC feed. No incremental change events can be inferred without comparing successive snapshots.

A correct key-based MERGE would reconcile repeated logical rows. The observed duplicates follow from unconditional append processing without snapshot diffing.

Question 189

A snapshot-comparison load is deployed. How should it be validated?

Compare two snapshots that contain only identical rows.
Compare controlled old and new snapshots containing an insert, update and delete, then verify each target operation and unchanged-key stability.
Check only that the newest snapshot file was copied into OneLake Files.
Validate one inserted key but do not remove an old key or revise an existing attribute.

Explanation

Correct Answer

A three-operation fixture demonstrates the diff handles both surviving changes and records absent from the new snapshot.

Incorrect Answers

Unchanged rows can detect needless appends but do not test insert, update, and delete handling, which the design is required to support.

File arrival does not establish that change detection reconciled the warehouse target by business key.

Insert-only testing cannot prove update or deletion semantics when the source provides no CDC events.

Question 190

IoT records must be queryable within seconds, but current nightly Copy jobs deliver them the next day. What loading architecture better matches the latency target?

Move the once-nightly Copy trigger to early morning and retain the same interval.
Enable native Delta file compaction but keep the nightly source acquisition schedule.
Implement a supported continuous ingestion route, such as Eventstream to an Eventhouse or compatible streaming destination, sized to the source and query needs.
Use a KQL visualization over yesterday's warehouse import and call it near-real-time.

Explanation

Correct Answer

A live event path reduces acquisition latency compared with batch scheduling and can expose recently received events to KQL queries.

Incorrect Answers

Changing the batch hour doesn't satisfy a seconds-level event-to-query requirement.

Faster scans won't make source events available before the next batch arrives.

A real-time query interface can't provide new messages that are still waiting for nightly ingestion.

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

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

Pass Your Microsoft DP-700 Exam Easy!

Question 180

Explanation

Correct Answer

Incorrect Answers

Question 181

Explanation

Correct Answer

Incorrect Answers

Question 182

Explanation

Correct Answer

Incorrect Answers

Question 183

Explanation

Correct Answer

Incorrect Answers

Question 184

Explanation

Correct Answer

Incorrect Answers

Question 185

Explanation

Correct Answer

Incorrect Answers

Question 186

Explanation

Correct Answer

Incorrect Answers

Question 187

Explanation

Correct Answer

Incorrect Answers

Question 188

Explanation

Correct Answer

Incorrect Answers

Question 189

Explanation

Correct Answer

Incorrect Answers

Question 190

Explanation

Correct Answer

Incorrect Answers

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