AZ-204 Practice Question: Connect to and consume Azure services and third-party services
Your company has a microservices application deployed on Azure Kubernetes Service (AKS). One service, OrderProcessor, needs to read messages from an Azure Service Bus queue and write results to Azure Cosmos DB. The processing must be reliable: if the service crashes mid-processing, the message should not be lost and should be retried. You also need to ensure that messages are processed in order within a partition. The solution should minimize code changes and leverage platform features. Which approach should you use?
⚠ Common exam trap
Test-takers frequently confuse ReceiveAndDelete mode with PeekLock mode, or assume that manual completion alone guarantees ordering, but they overlook that sessions are the only way to enforce FIFO ordering within a partition in Service Bus.
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
✓
Use Azure Functions with a Service Bus trigger that uses sessions for ordered processing.
Azure Functions with a Service Bus trigger using sessions provides exactly-once processing and ordered message delivery within a partition. The Service Bus trigger automatically uses PeekLock mode, ensuring messages are not lost if the function crashes, and sessions guarantee FIFO ordering within a session. This minimizes code changes by leveraging the platform's built-in retry and checkpointing mechanisms.
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 the Azure Service Bus SDK with ReceiveAndDelete mode in a background worker.
Why it's wrong here
Using the Azure Service Bus SDK with ReceiveAndDelete mode is highly unreliable for critical message processing. In this mode, a message is immediately removed from the queue upon retrieval, meaning if the background worker crashes or fails to process the message successfully after receiving it, the message is permanently lost without any retry mechanism or dead-lettering. This approach sacrifices message durability and guaranteed delivery for a slight performance gain, which is unsuitable for most microservices requiring robust message handling.
- ✓
Use Azure Functions with a Service Bus trigger that uses sessions for ordered processing.
Why this is correct
Azure Functions with a Service Bus trigger provides a robust and scalable solution for processing messages reliably. Functions automatically leverage Service Bus's PeekLock mechanism, handling message retrieval, retries, and completion or dead-lettering without explicit developer code. Furthermore, utilizing Service Bus sessions ensures that related messages are processed in a guaranteed order by the same function instance, which is crucial for maintaining data consistency in microservices architectures.
- ✗
Use the Azure Service Bus SDK with PeekLock mode and manual message completion.
Why it's wrong here
While using the Azure Service Bus SDK with PeekLock mode and manual message completion offers reliability by holding messages until explicitly completed, it places a significant burden on the developer. Implementing this requires writing custom code for retry logic, handling message abandonment, managing concurrency, and potentially integrating with a dead-letter queue. Azure Functions abstracts away much of this complexity, providing a more efficient and less error-prone way to achieve the same reliable processing without extensive boilerplate code.
- ✗
Use Azure Event Hubs with a consumer group and checkpointing.
Why it's wrong here
Azure Event Hubs is fundamentally designed for high-throughput, real-time event streaming and ingestion, not for traditional message queuing with transactional semantics. It functions as a distributed log where events are immutable and can be read by multiple consumer groups, rather than a queue where messages are 'consumed' and removed. Event Hubs lacks built-in features like PeekLock, message sessions, or automatic dead-lettering for individual message processing failures, making it unsuitable for scenarios requiring guaranteed, ordered, and retriable message delivery in a microservices command/event pattern.
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
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.
Key term
Azure Relay
Azure Relay is a cloud service that securely exposes on-premises web services to the public internet or other cloud applications without opening firewall ports.
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.