Microsoft DP-700 Practice Test 50

Question 490

Spark executors are mostly idle while the notebook driver goes out of memory after calling `toPandas()` on a very large DataFrame. What boundary was crossed?

The executors are idle because their memory allocation is smaller than the driver's.
The issue occurs because KQL `external_table()` is not enabled on the Spark notebook.
The code attempted to materialize a distributed dataset in the single driver process, exceeding its local memory capacity.
A 25-million-row collect can be made safe by changing only the workspace domain name.

Explanation

Correct Answer

Distributed Spark partitions do not prevent memory exhaustion if the application explicitly gathers all rows into one driver-side DataFrame.

Incorrect Answers

An oversized `toPandas()` materializes data on the driver regardless of idle executor resources.

KQL external shortcuts are unrelated to driver memory exhaustion from a local Pandas conversion.

Names don't limit how much data is materialized on the notebook driver.

Question 491

An engineer replaces a 25-million-row `collect()` with distributed aggregation and a small final result. What is the appropriate validation?

Verify only that the driver doesn't crash when the source is reduced to a few hundred rows.
Compare only executor utilization without checking driver memory peaks and output totals.
Drop columns and rows arbitrarily until the query is fast and count that as a successful optimization.
Compare driver peak memory, Spark stage duration and the final group totals against a known reference dataset while confirming only the small summary reaches the client.

Explanation

Correct Answer

The optimization should keep large data on executors and preserve exact aggregates, not just suppress the driver error.

Incorrect Answers

A small fixture cannot test memory-safe processing at the production 25-million-row scale.

The prior failure was on the driver; low executor usage doesn't demonstrate the replacement avoids local materialization.

Unapproved data reduction changes results; validate the distributed aggregate against a trusted expected total.

Question 492

A Fabric Spark query planner chooses a broadcast hash join, but the build-side table has grown far beyond available executor memory. Which tuning approach should be considered?

Refresh useful size statistics and control the broadcast threshold/hint; use an appropriate distributed join strategy when the build side cannot fit in executor memory.
Force the same full broadcast on both sides to guarantee faster queries.
Use OneLake role-based access to allocate more executor memory without changing compute.
Remove every join predicate to shorten the join statement.

Explanation

Correct Answer

Broadcast replicates the build relation across executors; over-sized broadcasts can trigger OOM or retries and require a different physical join.

Incorrect Answers

Broadcasting more large data increases memory pressure and cannot make oversized build inputs safe. It does not implement the corrective control requested in this incident.

Data authorization cannot modify the size of a broadcast relation or Spark executor heap. It does not implement the corrective control requested in this incident.

A cartesian product can massively increase output and is not a valid performance remedy for the intended keyed join. It does not implement the corrective control requested in this incident.

Question 493

A Spark join starts failing with executor out-of-memory after a previously small lookup table expands by 100 times. The physical plan still broadcasts the table. What explains the failure?

The enlarged lookup can still be broadcast safely because the table name hasn't changed.
The physical join distributes a now-excessive broadcast relation into executor memory, exceeding the resources available per executor.
The failure must be caused by a source OneLake file permissions error.
Enabling V-Order automatically caps how many lookup rows each executor receives.

Explanation

Correct Answer

Broadcast is efficient for genuinely small build sides but becomes counterproductive when that input no longer fits.

Incorrect Answers

Broadcast size follows actual runtime data volume, not its historical name or classification.

The reported OOM occurs during a broadcast join plan; read access alone doesn't explain the memory growth.

File ordering doesn't make an oversized broadcast relation small enough for executor memory.

Question 494

After eliminating an oversized Spark broadcast, which evidence verifies that the replacement plan is correct and more stable?

Check the logical plan only and assume the physical strategy will stop broadcasting.
Benchmark on the old tiny lookup table rather than its expanded production size.
Inspect the new physical join plan and compare executor peak memory, spill/shuffle volume, failure count, runtime and join-result reconciliation.
Verify only that executors stop crashing while ignoring join output equivalence.

Explanation

Correct Answer

A shuffle join may cost more data movement but can avoid fatal broadcast memory pressure; only measured resource and result checks justify the change.

Incorrect Answers

Execution may still choose broadcast; verify the actual physical plan under representative data.

Old sizes don't exercise the broadcast memory fault that motivated the fix.

Avoiding OOM is not enough if changing join strategy drops unmatched rows or duplicates keys.

Question 495

A KQL query for suspicious sessions joins a full year of raw access logs with a small threat-intelligence table, then filters to yesterday. What rewrite should be evaluated?

Drop the time filter completely because the join engine will infer yesterday automatically.
Expand every dynamic JSON property before the time filter to maximize schema discovery.
Grant database Admin to the requesting analyst to speed predicate evaluation.
Filter the large log input to the required time window and selected fields before its expensive join, while preserving join and predicate semantics.

Explanation

Correct Answer

Restricting the large input early can reduce scanned rows and join work without changing the intended time-window answer.

Incorrect Answers

Without a predicate, the join can process a much larger history and change the intended incident scope. It does not implement the corrective control requested in this incident.

Unnecessary expansion on all-year data adds CPU and memory work before pruning. It does not implement the corrective control requested in this incident.

Role elevation changes authorization but is not a substitute for an efficient KQL operator order. It does not implement the corrective control requested in this incident.

Question 496

A KQL query processes a large join of all-year logs and applies `where Timestamp > ago(1d)` only after expansion. Why can it consume excessive CPU?

A selective time predicate was applied after costly processing rather than pruning the raw large input early.
Applying the time filter after a join always processes fewer rows than filtering each source first.
KQL CPU usage is driven only by the Eventhouse database display name.
A join result automatically carries the same prefilter optimization even when the predicate follows expansion.

Explanation

Correct Answer

Pushing the filter ahead of the join when semantically equivalent can dramatically reduce the join’s input cardinality.

Incorrect Answers

Late filters permit the expensive join to expand all-year data before reducing the result set.

Names do not determine predicate pushdown or rows processed before a large join.

Logical equivalence doesn't guarantee the engine avoids unnecessary intermediate data without an early selective predicate.

Question 497

After moving an equivalent time predicate before a large KQL join, what is the strongest optimization receipt?

Compare only execution times with different underlying time windows.
Compare original and rewritten result keys/totals plus bytes/rows scanned, CPU consumption, duration and query plan under comparable source data.
Check CPU reduction but omit row set parity and boundary timestamps.
Use cached results from an old all-year query to infer the rewritten plan is efficient.

Explanation

Correct Answer

The rewrite must preserve join semantics and output while demonstrating measurable reduction in input and compute.

Incorrect Answers

Different amounts of input data can create apparent speed changes unrelated to filter placement.

An incorrect predicate pushed too early could exclude valid join matches despite lower CPU.

Cache effects obscure whether the early `where` actually reduces scanned and joined rows.

Question 498

A near-real-time KQL aggregation query over Fabric Eventhouse telemetry groups nearly every device, event type and millisecond-wide time bin separately. During each query execution, it consumes excessive memory. Which design should be evaluated?

Make every event identifier a separate OneLake security role.
Increase time precision even further while retaining unique event-ID grouping.
Reduce unnecessary grouping-cardinality and evaluate coarser valid time bins, controlled partition/window scope and staged aggregation with equivalent business semantics.
Delete late events until memory falls without documenting completeness or event-time semantics.

Explanation

Correct Answer

Very fine bins and high-cardinality composite keys explode active aggregate groups; the right time granularity must meet the analytic requirement.

Incorrect Answers

Permission-role creation does not reduce the cardinality of runtime aggregation groups. It does not implement the corrective control requested in this incident.

Finer bins generally create more separate states and can exacerbate high-cardinality memory pressure. It does not implement the corrective control requested in this incident.

Discarding valid telemetry is a data-quality loss, not a proven equivalent aggregation optimization. It does not implement the corrective control requested in this incident.

Question 499

A repeated KQL near-real-time aggregation query uses one-millisecond bins and groups by a unique event ID. Query memory consumption grows despite modest input rows per second. What is the primary cause?

Memory pressure is caused by insufficient Eventhouse storage retention days.
Unique event IDs make each grouping cheaper because each key appears once.
One-millisecond windows automatically merge events into fewer buckets than one-minute windows.
The query creates almost one distinct aggregation group per event, preventing meaningful consolidation and increasing per-query memory work.

Explanation

Correct Answer

Grouping on a unique event ID with tiny time bins creates a high-cardinality set of aggregation groups during each query execution; this is distinct from long-lived state in a separately configured stream processor.

Incorrect Answers

High-cardinality per-event groups and tiny windows inflate aggregation state, not necessarily retention duration.

Grouping by a unique key creates a very high number of state entries even at modest event rates.

Smaller bins generally create more distinct time groups and state, increasing aggregation overhead.

Question 500

A team adjusts the KQL query time-bin and grouping granularity for a Fabric Eventhouse telemetry report to reduce aggregation memory. Which verification protects reporting correctness?

Benchmark distinct grouping-key count, per-query memory and latency while reconciling counts/sums for the approved reporting dimensions and time boundaries, including late-arriving records.
Verify only that memory drops after coarsening window bins.
Compare a single all-events total but ignore approved reporting dimensions and time boundaries.
Benchmark on uniform synthetic identifiers instead of representative high-cardinality production data.

Explanation

Correct Answer

Coarser query bins may reduce aggregation groups, but must preserve the approved dimensions, event-time boundaries and completeness of later arriving telemetry; a faster query alone does not prove equivalent reporting.

Incorrect Answers

Reduced memory could come from discarding meaningful groups; output aggregate semantics must be reconciled.

A grand total can match while per-window or per-dimension reports become incorrect.

Low-cardinality fixtures cannot establish that the new grouping addresses the observed state explosion.

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

Microsoft DP-700 Practice Test 48 - 10 Questions (Last Reviewed 17-Sep-2026)
Microsoft DP-700 Practice Test 49 - 10 Questions (Last Reviewed 16-Sep-2026)
Microsoft DP-700 Practice Test 50 - 10 Questions (Last Reviewed 15-Sep-2026)

Pass Your Microsoft DP-700 Exam Easy!

Question 490

Explanation

Correct Answer

Incorrect Answers

Question 491

Explanation

Correct Answer

Incorrect Answers

Question 492

Explanation

Correct Answer

Incorrect Answers

Question 493

Explanation

Correct Answer

Incorrect Answers

Question 494

Explanation

Correct Answer

Incorrect Answers

Question 495

Explanation

Correct Answer

Incorrect Answers

Question 496

Explanation

Correct Answer

Incorrect Answers

Question 497

Explanation

Correct Answer

Incorrect Answers

Question 498

Explanation

Correct Answer

Incorrect Answers

Question 499

Explanation

Correct Answer

Incorrect Answers

Question 500

Explanation

Correct Answer

Incorrect Answers

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