Databricks-GenAI-Assoc Design Applications Practice Question
An engineer is designing a GenAI application where a Databricks workflow must call an external LLM provider that enforces a strict rate limit and occasionally returns transient errors. The engineer wants the application to degrade gracefully instead of failing the whole job. Which design choice best addresses this requirement?
⚠ Common exam trap
The trap here is reaching for cluster or job-level scaling to solve an external dependency problem, when the failure originates at the API boundary and must be handled in the calling code.
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
✓
Wrap the external call in retry logic with exponential backoff and a fallback response path
Resilience to external rate limits and transient failures comes from handling the call itself: bounded retries with exponential backoff smooth over temporary rejections, and a fallback response keeps the application functional when the provider stays unavailable. Infrastructure sizing, task-level retries, and response caching do not address the failure at its source.
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 driver node type on the job cluster
Why it's wrong here
A larger driver provides more local memory and CPU, but rate limits and transient provider errors originate outside the cluster and are unaffected by driver size. The job would still fail on a 429 or timeout response, so this option does not deliver graceful degradation.
- ✗
Cache all prompts and responses in a Delta table before calling the provider
Why it's wrong here
Caching prior responses helps only when an identical request was seen before and does not handle first-time calls that hit a rate limit. It also introduces staleness risk for dynamic prompts, so it does not provide the resilience that backoff and a fallback path deliver.
- ✗
Set the job to retry the entire task on failure
Why it's wrong here
Task-level retries restart the whole task from the beginning, which can re-issue already-successful calls, duplicate side effects, and still fail if the provider remains rate-limited. It is a coarse recovery mechanism rather than a design that degrades gracefully at the point of the external call.
- ✓
Wrap the external call in retry logic with exponential backoff and a fallback response path
Why this is correct
Retries with exponential backoff absorb transient rate-limit and server errors without immediately failing the job, and a fallback path lets the application return a degraded but useful response when retries are exhausted. Together they prevent a single external hiccup from aborting the entire workflow.
About these practice questions
One of 330 original Databricks-GenAI-Assoc 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 Databricks exam blueprint
This Databricks-GenAI-Assoc practice question is part of Courseiva's free Databricks 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 Databricks-GenAI-Assoc exam.