Microsoft DP-700 Practice Test 25

Question 240

The CSV parser is updated for malformed numeric values. What is the most useful acceptance test?

Test only a CSV row with a valid number, without malformed or out-of-range samples.
Check only total row counts, ignoring the rejected-row quarantine and original raw values.
Change target integers to strings silently and assume numeric business calculations still work.
Load a fixture with valid integers, blanks, negative values and an invalid token; reconcile parsed rows, null handling and quarantined errors.

Explanation

Correct Answer

Mixed-input testing distinguishes successful numeric conversion from silent data loss or undesired type coercion.

Incorrect Answers

Happy-path examples won't reveal unresolved invalid-token or overflow handling defects.

Counts can mask dropped or coerced bad rows and fail to validate the intended error policy.

Avoiding conversion by changing types can violate the expected schema and arithmetic semantics.

Question 241

A daily Fabric lakehouse load receives updates for existing order IDs alongside new orders. What Delta operation should prevent duplicate logical orders?

Use Append on every arriving record because Delta's transaction log removes logical duplicates automatically.
Use a supported Delta MERGE keyed by stable order ID with defined matched-update and unmatched-insert actions.
Overwrite the entire orders table with only today's changed rows.
MERGE on a newly randomized load identifier instead of the source order business key.

Explanation

Correct Answer

MERGE reconciles existing records and new keys in one controlled target operation, unlike append-only batches.

Incorrect Answers

Delta transactions guarantee storage consistency but do not implicitly deduplicate repeated business-order IDs.

That would discard unchanged historical orders and violate the complete current-state table requirement.

A new load ID will never match existing orders, causing duplicate records rather than updates.

Question 242

A lakehouse append load produces two versions of the same order after an upstream correction. What caused it?

The target is missing a scheduled VACUUM, which would normally remove older duplicate business keys.
A source order correction should always produce another independent business order ID.
The load appends updates rather than using business-key reconciliation for records already present in the Delta target.
The Dataflow visualization has not been endorsed as certified.

Explanation

Correct Answer

An updated source row with the same order ID requires match-based handling to avoid double-counting.

Incorrect Answers

VACUUM removes obsolete physical files, not logical duplicate order versions from an append-only table.

The business key should remain stable for updates; inventing a new ID would worsen duplicate logical records.

Endorsement affects discoverability, not Delta business-key update/upsert semantics.

Question 243

A Delta MERGE load is implemented. Which test proves it performs idempotent updates?

Append the same corrected order twice and declare MERGE idempotent if total rows increase.
Compare only current file sizes after MERGE without querying the business key.
Delete all previous order rows before each retry and assume transaction semantics are preserved.
Run a controlled batch with one existing ID and one new ID twice, and verify only one target row per ID with the updated existing values.

Explanation

Correct Answer

An identical rerun reveals whether matched records are updated instead of duplicated.

Incorrect Answers

An upsert should not duplicate the matching key on repeat delivery; row increases are a failure.

File layout can change independently of logical one-key-one-current-row correctness.

Destructive full replacement doesn't verify stable targeted matching updates or unaffected keys.

Question 244

A finance fact table records one row per invoice line, but a report needs customer region and product category attributes. Which reporting design is suitable?

Join the fact to the appropriate dimension versions at the invoice-line grain and expose the needed descriptive fields in a curated view or table.
Join invoice lines to both dimensions using only nonunique descriptive labels.
Cross join every customer region to each product category and filter only after measuring sums.
Aggregate away invoice-line IDs before joining and assume each measure remains at its original grain.

Explanation

Correct Answer

A purpose-specific denormalized projection can simplify reporting while retaining the original fact’s identity and correct dimensional relationships.

Incorrect Answers

Labels such as category or region can repeat; use appropriate keys and valid dimension matches at fact grain.

A cross join multiplies invoice lines and inflates revenue before any correct dimension relationship is established.

Early aggregation can lose the line-level relationships needed for accurate customer/product attribution.

Question 245

After joining customer and product dimensions, the invoice report doubles the number of lines. One dimension has duplicate effective matches. What caused the inflation?

The customer lookup requires a larger Spark executor before joining to the same invoice lines.
The lookup join is no longer one-to-one at the intended fact grain and creates extra rows for each duplicate dimension match.
The SQL query needs V-Order optimization to eliminate repeated fact rows.
The report omitted a Power BI sensitivity label on the product table.

Explanation

Correct Answer

Denormalizing descriptive attributes is safe only when each fact row resolves to the intended unique dimension member or version.

Incorrect Answers

More compute cannot prevent duplicate join matches when the dimension key/effective-time condition is nonunique.

V-Order changes file layout but cannot correct a many-to-many join that multiplies line records.

A label does not change join cardinality or overlapping customer/product dimension matches.

Question 246

A denormalized invoice reporting view is ready for QA. What comparison is most discriminating?

Compare only the distinct number of invoices and ignore the invoice-line count.
Verify that customer and product dimensions both contain more than one version per key.
Reconcile distinct invoice-line keys and numeric totals before and after the dimension joins while spot-checking region and category attributes.
Inspect Power BI card formatting for identical numeric totals.

Explanation

Correct Answer

Stable fact grain and totals demonstrate that enrichment did not multiply or omit transactions.

Incorrect Answers

Invoice header counts may be unchanged while multiple dimension matches duplicate each line's measure.

Multiple versions may be correct Type 2 history; the test must enforce exactly one effective match per fact row.

Formatting cannot prove the joins preserve source line grain or prevent duplicated measures.

Question 247

An order fact stream has order amount and a UTC timestamp; a daily regional report must aggregate by business date and branch. Which grouping strategy is appropriate?

Group by date only and treat branch as a display label added after aggregation.
Group by the raw UTC timestamp down to the second rather than by business day and branch.
Use the ingestion-processing date without defining the business time zone and branch key.
Convert timestamps to the agreed business-day definition, then group by date and branch with a documented sum/row-filter policy.

Explanation

Correct Answer

An aggregate is meaningful only if the grouping grain and time basis match the business requirement, rather than merging locations or misassigning day boundaries.

Incorrect Answers

A date-only grouping collapses branches and cannot reconstruct their individual sums later.

Per-second aggregation fails to compute the required daily business-date reporting grain.

Event-time UTC may cross local business dates; using processing time and omitting branch can misattribute totals.

Question 248

A report shows different daily totals after an engineer groups records only by date and omits branch. What caused the discrepancy?

The group-by grain collapsed sales from different branches into the same daily bucket.
The table's physical date partitions were not compacted before summing branch totals.
The source lacks a workspace domain corresponding to each branch.
The query's date expression uses a display format rather than a date type.

Explanation

Correct Answer

An aggregation without the required location dimension cannot reproduce per-branch totals regardless of whether the global sum is accurate.

Incorrect Answers

Compaction doesn't restore a missing BranchID in GROUP BY and cannot undo aggregate grain collapse.

Domains organize Fabric workspaces; they don't make a SQL GROUP BY retain omitted branch keys.

Formatting may have effects but does not by itself explain branch subtotals being merged into one daily group.

Question 249

After implementing daily branch aggregation, what test validates its grain and math?

Compare the combined daily total to the source and assume every branch subtotal is correct.
Use a fixed set of orders across two branches and midnight, then reconcile branch/day keys, counts and sums to the original records.
Validate only one branch-day combination and extrapolate all dates.
Inspect the number of daily output rows without checking composite keys and sums.

Explanation

Correct Answer

Known boundary fixtures expose wrong time conversions, missing grouping keys and double-counted values.

Incorrect Answers

A total can balance while individual branch values are interchanged or merged.

A single row can't detect cross-branch mixing or boundary-date errors across all groups.

Row counts alone cannot prove `(business_date, branch)` uniqueness or arithmetic correctness.

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.

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

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

Pass Your Microsoft DP-700 Exam Easy!

Question 240

Explanation

Correct Answer

Incorrect Answers

Question 241

Explanation

Correct Answer

Incorrect Answers

Question 242

Explanation

Correct Answer

Incorrect Answers

Question 243

Explanation

Correct Answer

Incorrect Answers

Question 244

Explanation

Correct Answer

Incorrect Answers

Question 245

Explanation

Correct Answer

Incorrect Answers

Question 246

Explanation

Correct Answer

Incorrect Answers

Question 247

Explanation

Correct Answer

Incorrect Answers

Question 248

Explanation

Correct Answer

Incorrect Answers

Question 249

Explanation

Correct Answer

Incorrect Answers

Question 250

Explanation

Correct Answer

Incorrect Answers

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