Microsoft DP-700 Practice Test 26

Question 250

A fact ingest feed sometimes omits its required `transaction_id`. How should the pipeline handle these malformed records?

Generate a random transaction_id for each malformed row and load it as a valid business transaction.
Drop all malformed rows without recording their identifiers or reason for rejection.
Validate required keys before the target write and quarantine or reject null-ID records with traceable error reasons, leaving valid transactions intact.
Attempt MERGE using a null transaction_id and expect one unique match across previous loads.

Explanation

Correct Answer

A missing transaction identifier undermines deduplication and joins; deliberate validation preserves quality without silently dropping or fabricating IDs.

Incorrect Answers

Random IDs obscure source identity defects and can create nonreconcilable pseudo-transactions.

Silent deletion violates auditability and prevents upstream remediation of null-key source events.

Null keys cannot provide reliable source-to-target matching for idempotent fact upserts.

Question 251

A Delta target contains multiple rows whose transaction IDs are null after an automated merge. What is the core data-quality defect?

The null IDs were generated because Spark lacks an optimization hint for MERGE.
A Delta table automatically treats multiple null IDs as one unique database record.
The target did not set a domain-level data sensitivity label.
The pipeline accepted records lacking the required business key instead of enforcing a null-key validation boundary.

Explanation

Correct Answer

Without the key, the merge cannot reliably match an existing logical transaction or establish entity identity.

Incorrect Answers

Optimizer hints are irrelevant to missing business keys and the inability to match nulls reliably.

Delta doesn't enforce that arbitrary null merge keys represent a unique customer transaction.

Governance labels don't supply a nonnull business identity for safe upsert matching.

Question 252

After adding null-key quarantine, what outcome verifies the rule?

Load a fixture containing valid IDs, blank IDs and missing fields; confirm valid rows reach the target and invalid rows appear in an error set with reasons.
Verify that records with null keys no longer appear in the target but ignore the reject store.
Count only nonnull keys and infer every incoming record was correctly processed.
Apply OPTIMIZE and assume it automatically populates missing transaction identifiers.

Explanation

Correct Answer

Positive and negative fixtures prove data completeness for valid records and isolation of invalid identifiers.

Incorrect Answers

Dropping malformed records silently may conceal upstream loss; quarantine and reconciliation must be checked.

A nonnull count cannot establish null-key quarantine or total processed-record accounting.

Physical file compaction doesn't create missing business keys or validate reject handling.

Question 253

A message bus sometimes redelivers the same event with the same `event_id` but a later delivery timestamp. What deduplication key should a Fabric transform use?

Deduplicate on both event_id and delivery timestamp to select the latest delivery as a new key.
Deduplicate on the stable event identity with a documented ordering or latest-valid-record policy, not on the delivery timestamp alone.
Assign a new event_id every time the producer retries a message.
Use only the source arrival hour as the unique identity for every event.

Explanation

Correct Answer

The same logical event can arrive multiple times; id-based reconciliation prevents replay from inflating counts.

Incorrect Answers

The delivery timestamp differs across retries, so including it in the identity defeats logical deduplication.

Changing the stable identifier makes repeat delivery appear as a new event and inflates aggregates.

Many unrelated events share an hour, so this key would incorrectly merge distinct observations.

Question 254

A dataflow deduplicates on `(event_id, delivered_at)` and retains duplicate logical messages. Why?

The deduplication routine lacks an ORDER BY that sorts every message by `delivered_at` first.
The source event IDs require a Fabric domain before they are comparable.
The changing delivery timestamp makes repeated copies of one event appear to have distinct composite keys.
The sink's storage uses too many Delta files and therefore stores repeated events.

Explanation

Correct Answer

A deduplication key must reflect immutable event identity, not metadata that differs with each retry.

Incorrect Answers

Ordering can choose a preferred version but cannot define identity while the delivery timestamp remains in the key.

Domain grouping does not determine whether a logical event identifier stays stable across redeliveries.

Storage fragmentation does not explain deduplication keyed on a nonstable arrival timestamp.

Question 255

An event deduplication rule is introduced. What is an appropriate regression fixture?

Replay an identical event ID with three different delivery timestamps and accept three stored records.
Check only that the deduplication SQL compiles successfully.
Use only sample records that all have unique event IDs.
Send the same `event_id` twice with different delivery timestamps plus a truly distinct event ID, and confirm exactly two logical events remain.

Explanation

Correct Answer

This distinguishes legitimate new events from retries, validating key choice and any tie-breaking policy.

Incorrect Answers

The fixture must assert one retained logical event, not one row for each redelivery timestamp.

Compilation doesn't show stable logical-event keying or tie-break correctness.

A unique-ID-only fixture never exercises the duplicate redelivery case the rule was designed for.

Question 256

A source emits local wall-clock timestamps including a numeric UTC offset. Daily reporting must align events from several regions. What transformation is appropriate?

Parse the supplied offset and normalize instants to a documented UTC or business-zone time basis before deriving reporting dates.
Discard each input UTC offset and interpret the remaining local clock as UTC.
Group events by each source's unnormalized local date string.
Replace every event timestamp with Fabric ingestion time and ignore the original timestamp.

Explanation

Correct Answer

Equal text clock times can represent different instants; consistent normalization prevents wrong-day aggregation across locations.

Incorrect Answers

That shifts actual instants for nonzero-offset sources and misattributes near-midnight dates.

Different regions can describe the same instant with different local dates; normalize before common daily bins.

Ingestion can occur after the event, making historical and delayed regional events fall into the wrong business day.

Question 257

The same event is attributed to different dates in SQL and PySpark because SQL strips the offset before casting. What is the root cause?

The SQL engine needs a new warehouse name containing the source time zone.
One transformation lost time-zone information and treated a local timestamp as if it were already in the agreed common time basis.
The timestamps were correctly converted simply because the original text contained a plus/minus sign.
The two engines must use different Fabric capacity regions to agree on event days.

Explanation

Correct Answer

Offset-aware timestamps must be converted consistently; otherwise a near-midnight event can land in a different calendar date.

Incorrect Answers

Names do not preserve timestamp offsets or establish a consistent UTC conversion policy.

Discarding the offset before conversion can shift the actual event instant despite the original string's syntax.

Changing compute regions cannot fix lost offset information in the parser.

Question 258

The team standardizes source timestamps. What test reveals incorrect zone handling?

Test only midday timestamps with zero UTC offset to confirm daily attribution.
Compare formatted local strings without converting them to a common instant.
Check a fixture containing positive and negative offsets near midnight, then compare normalized instants and derived business dates across both engines.
Validate only the number of parsed timestamps rather than their UTC epoch values.

Explanation

Correct Answer

Boundary events provide discriminating evidence of conversion correctness instead of passing on middle-of-day test values.

Incorrect Answers

A noon UTC fixture cannot reveal day-boundary shifts produced by nonzero offsets.

Text equality isn't proof that both engines normalize equivalent UTC instants and day buckets.

Every timestamp can parse yet still be shifted into the wrong calendar day.

Question 259

An incremental batch load must accept orders that arrive a day late with old order dates. How should it avoid dropping them?

Filter only for OrderDate equal to the current processing date.
Increase copy-node parallelism while retaining the same today-only predicate.
Run a full append of all historical orders every day without stable-key deduplication.
Use a late-arrival reconciliation window or change-tracking strategy keyed by business identity and event date, with idempotent merge handling.

Explanation

Correct Answer

An arrival-time-only cutoff can miss legitimate prior-date orders; the processing boundary must support late records without duplication.

Incorrect Answers

A record delivered today with yesterday's order date is legitimately late and would be excluded.

Higher throughput cannot load rows explicitly excluded by the business-date filter.

Blind full replays could capture late rows but also duplicate already loaded orders.

Question 260

A daily incremental job filters for `OrderDate = today` and ignores yesterday’s orders delivered after midnight. Why?

Its filter assumes event date and ingestion date coincide and therefore excludes late-arriving business events.
The incremental job should always use OrderDate equal to the current date without a lookback.
The output needs more Fabric Spark workers to make yesterday's rows eligible.
The warehouse SQL query optimizer isn't preserving historical date partitions.

Explanation

Correct Answer

Event-time rows can arrive after their original date; the loader needs a change or lateness strategy beyond a strict current-date predicate.

Incorrect Answers

This duplicates the defect; delayed source arrival may carry an older business date than processing date.

Additional workers won't change a predicate that intentionally excludes those rows.

The explicit today-only filter, not optimizer partition pruning, removes legitimate delayed arrivals.

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

Microsoft DP-700 Practice Test 24 - 10 Questions (Last Reviewed 11-Oct-2026)
Microsoft DP-700 Practice Test 25 - 10 Questions (Last Reviewed 10-Oct-2026)
Microsoft DP-700 Practice Test 26 - 10 Questions (Last Reviewed 09-Oct-2026)
Microsoft DP-700 Practice Test 27 - 10 Questions (Last Reviewed 08-Oct-2026)
Microsoft DP-700 Practice Test 28 - 10 Questions (Last Reviewed 07-Oct-2026)

Pass Your Microsoft DP-700 Exam Easy!

Question 250

Explanation

Correct Answer

Incorrect Answers

Question 251

Explanation

Correct Answer

Incorrect Answers

Question 252

Explanation

Correct Answer

Incorrect Answers

Question 253

Explanation

Correct Answer

Incorrect Answers

Question 254

Explanation

Correct Answer

Incorrect Answers

Question 255

Explanation

Correct Answer

Incorrect Answers

Question 256

Explanation

Correct Answer

Incorrect Answers

Question 257

Explanation

Correct Answer

Incorrect Answers

Question 258

Explanation

Correct Answer

Incorrect Answers

Question 259

Explanation

Correct Answer

Incorrect Answers

Question 260

Explanation

Correct Answer

Incorrect Answers

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