AZ-204 Develop Azure compute solutions Practice Question
You are developing an Azure Functions app that processes orders. Each order triggers a function that writes to Azure Cosmos DB. You notice occasional throttling (429 errors) from Cosmos DB during peak hours. The function app uses the Consumption plan. What is the most cost-effective way to reduce throttling?
⚠ Common exam trap
Candidates often assume scaling the function app (Option C) or increasing Cosmos DB throughput (Option A) are the only ways to handle throttling, but they overlook that retry logic is a zero-cost, built-in mechanism that directly addresses the transient nature of 429 errors in a Consumption plan environment.
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
✓
Implement retry logic with exponential backoff in the function code.
Implementing retry logic with exponential backoff is the most cost-effective way to handle transient 429 errors from Cosmos DB. The Azure Cosmos DB SDK already includes built-in retry policies, but custom retry logic in the function code can be tuned to match the workload, allowing the function to wait and retry during peak throttling without incurring additional costs from scaling or increasing throughput.
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 provisioned throughput (RU/s) of the Cosmos DB container.
Why it's wrong here
Increasing the provisioned throughput (RU/s) of a Cosmos DB container directly raises its operational cost, regardless of actual usage. While higher RU/s can prevent throttling if Cosmos DB is the bottleneck, it's an expensive solution for transient or intermittent throttling events, as the increased capacity is paid for even during periods of low demand. This approach addresses symptoms with a costly, always-on resource increase rather than adapting to fluctuating load efficiently.
- ✗
Upgrade the function app to the Premium plan for dedicated instances.
Why it's wrong here
Upgrading an Azure Function app to the Premium plan provides benefits like pre-warmed instances, VNET integration, and dedicated compute resources, which can improve overall function performance and reduce cold start times. However, this upgrade primarily enhances the function app's hosting environment and does not directly resolve throttling issues originating from a downstream service, such as Cosmos DB. It increases the function app's operational cost without addressing the specific problem of being throttled by an external dependency.
- ✗
Increase the function app's instance count by scaling out.
Why it's wrong here
Scaling out the function app by increasing its instance count allows it to process more concurrent requests, potentially improving overall throughput for the function itself. However, if the underlying issue is throttling imposed by a downstream service like Cosmos DB, increasing the number of function instances will only exacerbate the problem. More concurrent requests from the scaled-out function app will intensify the load on the already throttled dependency, leading to more frequent and severe throttling errors rather than resolving them.
- ✓
Implement retry logic with exponential backoff in the function code.
Why this is correct
Implementing retry logic with exponential backoff is a highly effective and recommended pattern for handling transient faults, including throttling, in distributed systems. When a downstream service like Cosmos DB temporarily throttles a request, the function can automatically retry the operation after progressively longer delays. This approach allows the throttled service time to recover, reduces the immediate load, and ensures eventual success without incurring additional infrastructure costs, making the function more resilient.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
Learn chapter
Azure Functions Development
Key term
Azure Functions Bindings
Azure Functions Bindings are declarative connections that link your serverless function code to Azure services or external resources, handling input and output data automatically without writing extra networking or authentication code.
Key term
Durable Functions
Durable Functions is an extension of Azure Functions that lets you write stateful workflows in code, managing complex sequences of tasks, retries, and delays automatically.
About these practice questions
This AZ-204 question is part of Courseiva's 881-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-204 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 AZ-204 exam.