Microsoft DP-700 Practice Test 49

Question 480

During the daily peak, Fabric Eventhouse queries intermittently throttle while off-peak queries succeed with the same KQL and data. Which investigation should guide corrective changes?

Correlate Eventhouse concurrency and resource metrics with Fabric capacity utilization, query memory/CPU and competing workloads; then schedule, optimize or resize only the proven bottleneck.
Rewrite every query to return empty results and count the lack of throttling as success.
Remove all query telemetry because graphs are expensive to interpret.
Increase the lakehouse notebook’s Python library version without checking Eventhouse resources.

Explanation

Correct Answer

A peak-only throttle often reflects contention or quota enforcement; telemetry is needed to separate expensive queries from capacity exhaustion.

Incorrect Answers

An empty result may trivially reduce work but breaks business query requirements. It does not implement the corrective control requested in this incident.

Disabling metrics hides throttling rather than restoring enough resources for the workload. It does not implement the corrective control requested in this incident.

Spark dependency versions do not directly govern peak KQL concurrency or Eventhouse resource limits. It does not implement the corrective control requested in this incident.

Question 481

Eventhouse query errors coincide with an approved capacity being saturated by multiple concurrent KQL workloads, but each query succeeds when isolated. What explains the peak failure?

Isolated query success rules out shared capacity contention at peak.
Concurrent queries exceed available capacity or query resource limits during the busy window, causing throttling even though individual query logic is valid.
The Eventhouse time range must be wrong because query errors happen at peak.
Eventhouse concurrency is controlled by sensitivity labels on KQL tables.

Explanation

Correct Answer

A successful off-peak test does not prove peak concurrency fits into the available Eventhouse resources.

Incorrect Answers

Contention appears under concurrent workload even when each individual query succeeds with free capacity.

A bad predicate would likely fail consistently, not correlate strongly with capacity saturation.

Governance labels don't allocate compute concurrency or remove high shared utilization.

Question 482

A team moves costly KQL jobs off peak and right-sizes a Fabric capacity. What validation shows reduced Eventhouse contention?

Benchmark only one KQL query after moving jobs off peak.
Inspect capacity allocation alone without measuring query errors, concurrency and latency.
Run comparable peak-volume traffic and compare throttling rates, concurrent query success, p95 latency and capacity CPU/memory before and after the changes.
Conclude the optimization succeeded by suppressing error logs while leaving workload unchanged.

Explanation

Correct Answer

Lower error rates with stable correct query results under equivalent peak loads demonstrate that the resource-scheduling or capacity adjustment helped.

Incorrect Answers

One isolated query can't establish that contention among concurrent workloads has decreased.

Configured size doesn't prove actual peak behavior improved across representative workloads.

Hiding telemetry doesn't remove resource contention or restore successful queries.

Question 483

A Fabric Spark job joins two billion-row datasets on customer_id, and one customer_id represents half of all rows. A few tasks run much longer than other tasks. Select TWO reasonable skew remedies.

Investigate Adaptive Query Execution skew-join handling and use repartitioning or salting when compatible with the join semantics.
Disable all Spark shuffle partitioning regardless of the join size.
Increase only the driver’s notebook display limit to fix skewed executor work.
Grant unrestricted OneLake permissions to every executor identity without measuring partition sizes.
Profile the join-key frequency and Spark stage task input/shuffle distributions before selecting and validating the adjustment.

Explanation

Correct Answers

AQE and deliberate key distribution can split hot partitions, shortening straggler tasks without changing matching-key requirements.

A concentrated heavy key must be confirmed as the cause; targeted profiling supports a safe repartition plan and post-change accuracy comparison.

Incorrect Answers

Large joins still require a physical data movement or compatible distribution strategy; blanket removal can make the query invalid or infeasible. It does not implement the corrective control requested in this incident.

Notebook presentation does not redistribute an oversized hot-key partition. It does not implement the corrective control requested in this incident.

Permissions do not remedy a large concentration of matching rows on a few shuffle tasks. It does not implement the corrective control requested in this incident.

Question 484

Most Spark join tasks finish in seconds, but a handful of tasks take ten times longer and all process one dominant customer_id. What is the most likely source of the job tail?

Severe join-key data skew sends much more work into a small number of shuffle partitions and leaves long-running stragglers.
The key distribution is balanced because most Spark join tasks finish quickly.
An imbalance in Spark join keys can always be fixed by adding a bigger driver.
The dominant ID requires a new Fabric domain for its data.

Explanation

Correct Answer

Skewed key frequencies distribute work unevenly; more total executors will not by itself divide a single oversized partition evenly.

Incorrect Answers

A small number of partitions with a dominant ID can make long stragglers despite normal median tasks.

Skew happens across executors/partitions; driver size alone doesn't rebalance dominant keys.

Domain classification doesn't change join key frequencies or per-task shuffle volume.

Question 485

After tuning a skewed Spark join, which evidence proves real performance gain without duplicating or dropping join results?

Compare mean task duration only, ignoring worst-case partition and spill metrics.
Compare task-duration distribution, maximal shuffle partition volume, total stage time and output key/count reconciliation under equivalent input data.
Validate execution speed but ignore per-key joined record counts.
Test only a synthetic uniform key distribution rather than the production heavy hitter.

Explanation

Correct Answer

The tail of the task distribution should shrink while the relational join still produces exactly the same expected matches.

Incorrect Answers

Skew typically appears in the tail; average metrics may hide the problematic dominant key.

Skew mitigation must preserve results, not simply drop or undersample the dominant key.

Uniform fixtures can't prove the changed strategy handles the observed dominant key imbalance.

Question 486

A Fabric Spark notebook calculates a complex normalized DataFrame and performs five independent analyses using exactly the same intermediate result. What performance change is worth testing?

Leave every large intermediate cached for the entire capacity lifetime without monitoring memory.
Delete the source Delta transaction log so Spark does not recompute it.
Persist or materialize the reused intermediate where supported, choose a suitable storage level and unpersist it after the final consumer.
Use workspace domain membership as the cache key and ignore the DataFrame lineage.

Explanation

Correct Answer

Reusing expensive transformations can avoid repeated recomputation, but caching consumes memory and should be profiled rather than enabled indiscriminately.

Incorrect Answers

Unlimited retention can exhaust executor resources and harm other notebook workloads. It does not implement the corrective control requested in this incident.

The transaction log is essential to consistent Delta reads and not a caching control. It does not implement the corrective control requested in this incident.

Catalog domain labels do not materialize or invalidate Spark transformations. It does not implement the corrective control requested in this incident.

Question 487

A notebook computes the same expensive groupBy transformation for each of five downstream actions and the physical plan repeats the full upstream computation every time. What causes unnecessary work?

Spark automatically caches every DataFrame after the first action for subsequent independent actions.
Repeated groupBy work is caused by a missing Fabric SQL endpoint query-acceleration policy.
Reusing the same Python variable guarantees that all upstream partitions remain materialized.
The lazily evaluated intermediate has not been persistently materialized for reuse across Spark actions.

Explanation

Correct Answer

Without a reused cache or materialized result, each independent action can execute the dependency lineage again.

Incorrect Answers

Without explicit persistence, the dependency graph can recompute an expensive transformation repeatedly.

A Spark DataFrame action recomputes Spark lineage independently of Eventhouse/SQL cache settings.

A DataFrame object captures a logical plan; variable reuse alone isn't a storage/persistence contract.

Question 488

An engineer enables caching for an intermediate Spark DataFrame. Select THREE checks required to establish that the change is beneficial and safe.

Profile how many times the upstream transformation executes before and after caching.
Check only that the cache command succeeds without measuring actual recomputation.
Measure memory use after caching but ignore eviction, task time and execution plans.
Compare aggregate row counts but do not verify the underlying source changed or cache invalidated.
Compare executor-memory pressure, spill behavior and storage level while the intermediate is retained.
Reconcile downstream result values on fresh valid input and verify that cache invalidation or unpersist occurs when the data changes.

Explanation

Correct Answers

Reduced recomputation is the mechanism by which caching can accelerate repeated actions.

A cache is not free: it can displace executor memory, causing garbage collection, spills or out-of-memory failures.

Correctness and cache lifecycle matter because reused stale results can hide upstream Delta updates.

Incorrect Answers

Cache configuration must reduce physical upstream work across repeated actions, not just exist syntactically.

Higher memory alone doesn't prove the expensive aggregation stopped recomputing or remained semantically correct.

Stale cache contents can preserve counts while returning outdated records after an upstream change.

Question 489

A Fabric PySpark notebook calls `collect()` on a 25-million-row result only to calculate category totals. Driver memory rises rapidly and the session fails. Which design should replace this?

Increase notebook output row display limits and keep collecting millions of rows to Python.
Perform aggregation with distributed Spark DataFrame operations and return only the small grouped summary to the driver.
Rename the upstream DataFrame to smaller_df without changing its materialization.
Create a workspace security role to move `collect()` execution into every Spark executor.

Explanation

Correct Answer

A large collect transfers records to one driver, defeating distributed execution; aggregation on executors can shrink the result before collection.

Incorrect Answers

The display limit cannot change the size of an already driver-collected dataset. It does not implement the corrective control requested in this incident.

Variable naming has no effect on memory needed to collect full distributed results. It does not implement the corrective control requested in this incident.

Authorization grants do not change the semantics of driver-side collection. It does not implement the corrective control requested in this incident.

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.

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

Microsoft DP-700 Practice Test 47 - 10 Questions (Last Reviewed 18-Sep-2026)
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 480

Explanation

Correct Answer

Incorrect Answers

Question 481

Explanation

Correct Answer

Incorrect Answers

Question 482

Explanation

Correct Answer

Incorrect Answers

Question 483

Explanation

Correct Answers

Incorrect Answers

Question 484

Explanation

Correct Answer

Incorrect Answers

Question 485

Explanation

Correct Answer

Incorrect Answers

Question 486

Explanation

Correct Answer

Incorrect Answers

Question 487

Explanation

Correct Answer

Incorrect Answers

Question 488

Explanation

Correct Answers

Incorrect Answers

Question 489

Explanation

Correct Answer

Incorrect Answers

Question 490

Explanation

Correct Answer

Incorrect Answers

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