DP-700 Implement and Manage an Analytics Solution Practice Question
Exhibit
{
"name": "DailyIngestionJob",
"type": "SparkJobDefinition",
"properties": {
"executableFile": "main.py",
"defaultLakehouse": {
"name": "RawDataLH",
"id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
},
"retryPolicy": {
"event": "FAILED",
"maxRetryCount": 3
},
"compute": {
"runtimeVersion": "1.2",
"driverSize": "Small",
"executorSize": "Small",
"numExecutors": 2
}
}
}Refer to the exhibit. You are reviewing the JSON definition for a Spark Job Definition in Microsoft Fabric. The job is failing after exhausting all retries during periods of high capacity utilization. To ensure the job has a better chance of succeeding without increasing the maxRetryCount, which change should you implement in the job configuration?
⚠ Common exam trap
Candidates often try to increase the 'maxRetryCount' to resolve failures, not realizing that immediate retries during a capacity spike will likely fail again due to the same resource contention.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Add a 'retryIntervalInSeconds' property to the retryPolicy.
When a Spark job fails due to capacity constraints or resource contention, the failure often happens quickly. By adjusting the retry policy to include an interval or delay, the job can wait for transient capacity spikes to subside before attempting the next run. This increases the likelihood of success in a busy Fabric environment where resources are shared.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the 'numExecutors' value to 10.
Why it's wrong here
Increasing the number of executors actually increases the resource demand on the Fabric capacity. During periods of high utilization, requesting more executors is more likely to result in the job being queued or failing due to lack of available CUs, rather than helping it succeed during contention.
- ✗
Change the 'runtimeVersion' to 1.3.
Why it's wrong here
Upgrading the runtime version provides newer Spark features and library updates but does not directly address resource availability or transient failures caused by capacity throttling. Runtime versions are generally changed for compatibility or performance improvements within the Spark engine itself rather than for retry logic.
- ✓
Add a 'retryIntervalInSeconds' property to the retryPolicy.
Why this is correct
Adding a retry interval allows the system to wait between attempts. If the failure was caused by a transient capacity spike or reaching the throttling limit, a delay gives the capacity time to recover or for other jobs to complete, significantly improving the success rate of subsequent attempts.
- ✗
Change the 'driverSize' to 'Large'.
Why it's wrong here
Selecting a larger driver size allocates more memory and CPU to the Spark driver node. While this helps with jobs handling large metadata or complex orchestrations, it does not help with retry logic or capacity-based failures; it actually consumes more Capacity Units, potentially worsening the contention issue.
About these practice questions
One of 152 original DP-700 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
This DP-700 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DP-700 exam.