AZ-204 Develop for Azure storage Practice Question
You are developing an application that writes blobs to Azure Blob Storage. The application requires high throughput and must handle transient failures. You need to implement a retry policy. Which approach should you use?
⚠ Common exam trap
Many candidates confuse the circuit breaker pattern (a resilience pattern for preventing cascading failures) with a retry policy, or they incorrectly assume that a custom Thread.Sleep loop is acceptable in modern asynchronous Azure SDK applications.
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
✓
Configure the retry policy in the Azure.Storage.Blobs SDK
The Azure.Storage.Blobs SDK provides built-in retry policies (e.g., ExponentialRetry, FixedRetry) that handle transient failures automatically with configurable delays, retry counts, and backoff strategies. This is the recommended approach because it integrates directly with the SDK's client pipeline, respects service throttling, and avoids blocking threads or reinventing error handling logic.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a circuit breaker pattern
Why it's wrong here
A circuit breaker pattern is designed to prevent an application from repeatedly trying to invoke a service that is failing, thereby conserving resources and preventing cascading failures. While useful for persistent service outages or unresponsive downstream services, it's generally an overkill for handling transient network glitches or temporary server-side throttling encountered when writing blobs to Azure Storage. Simple retry policies are more appropriate and efficient for these short-lived, self-correcting issues, as they aim to eventually succeed rather than open a circuit.
- ✗
Implement a custom retry loop with Thread.Sleep
Why it's wrong here
Implementing a custom retry loop with Thread.Sleep is highly discouraged due to its inherent error-proneness and lack of sophistication compared to SDK-provided solutions. Such an approach often fails to incorporate essential features like exponential backoff, jitter to prevent thundering herd problems, or proper maximum retry limits, leading to inefficient resource usage and potential application unresponsiveness. The blocking nature of Thread.Sleep also negatively impacts application scalability and responsiveness, making it a poor choice for robust cloud applications.
- ✗
Generate a SAS token with a long expiry
Why it's wrong here
Generating a Shared Access Signature (SAS) token with a long expiry primarily addresses authentication and authorization concerns, granting time-limited access to Azure Storage resources. However, the duration of a SAS token's validity has no direct impact on the application's ability to recover from transient operational failures, such as network timeouts or server throttling, during a blob write operation. A retry mechanism is still necessary to re-attempt the operation when such temporary issues occur, regardless of the SAS token's lifespan.
- ✓
Configure the retry policy in the Azure.Storage.Blobs SDK
Why this is correct
Configuring the retry policy within the Azure.Storage.Blobs SDK is the recommended and most robust approach for handling transient faults during blob write operations. The SDK's built-in retry mechanisms automatically implement best practices like exponential backoff with jitter, which intelligently increases the delay between retries and adds randomness to prevent simultaneous retries from multiple clients. This approach significantly improves application resilience and reliability by gracefully recovering from temporary service interruptions without complex custom code.
Quick reference
Azure Blob Storage Tier Comparison
| Tier | Storage Cost | Retrieval Cost | Latency | Use Case |
|---|---|---|---|---|
| Hot | Highest | Lowest | Immediate | Active data, frequent reads |
| Cool | Lower | Higher | Immediate | Data accessed < once / month |
| Cold | Lower still | Higher | Immediate | Data accessed < once / quarter |
| Archive | Lowest | Highest + rehydration delay | Hours | Long-term compliance retention |
Go deeper
Related to this question
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.