How Should You Configure ACA Service Bus Event-Driven Scaling?
DRAG DROP
This is a case study. Case studies are not timed separately from other exam sections. You can use as much exam time as you would like to complete each case study. However, there might be additional case studies or other exam sections. Manage your time to ensure that you can complete all the exam sections in the time provided. Pay attention to the Exam Progress at the top of the screen so you have sufficient time to complete any exam sections that follow this case study.
To answer the case study questions, you will need to reference information that is provided in the case. Case studies and associated questions might contain exhibits or other resources that provide more information about the scenario described in the case. Information provided in an individual question does not apply to the other questions in the case study.
A Review Screen will appear at the end of this case study. From the Review Screen, you can review and change your answers before you move to the next exam section. After you leave this case study, you will NOT be able to return to it.
To start the case study
To display the first question in this case study, select the "Next" button. To the left of the question, a menu provides links to information such as business requirements, the existing environment, and problem statements. Please read through all this information before answering any questions. When you are ready to answer a question, select the "Question" button to return to the question.
Background
Proseware Inc. develops AI-powered knowledge management solutions for enterprise customers. The company is modernizing its platform to support semantic search, intelligent document retrieval, and real-time partner integrations.
The engineering team uses Python and Azure SDKs. The architecture is being redesigned to support containerized microservices, vector search workloads, and serverless backend processing.
Planned Application Architecture
Microservices are containerized by using Docker.
Code for containerized microservices and Azure Function apps is developed locally but stored in a GitHub repository.
Custom images for containerized microservices are stored in Azure Container Registry (ACR).
Base images are stored in Docker Hub. Custom images must be rebuilt automatically whenever their base images are updated.
Azure Cosmos DB for NoSQL stores documents, metadata, and vector embeddings.
Azure Functions generate vector embeddings of Azure Cosmos DB for NoSQL-hosted documents and send messages to Service Bus to trigger search index updates.
Azure Container Apps (ACA) apps host backend API services that provide semantic search across Azure Cosmos DB for NoSQL documents. API services process Service Bus messages and update search indexes.
Azure Kubernetes Service (AKS) processes batch vector embedding regeneration for existing Azure Cosmos DB for NoSQL documents (whenever the embedding model is changed).
An extranet-facing containerized webhook allows business partners to submit documents to be processed by internal AI workflows for semantic search and retrieval.
Monitoring
Telemetry generated by Azure resources is sent to Azure Monitor.
A Log Analytics workspace is used to collect ACA apps logs, AKS container logs, and Azure Functions apps logs.
Monitoring of Azure Functions is currently implemented by using Azure Application Insights SDK instrumentation.
Business Requirements
Embeddings for new or updated Azure Cosmos DB for NoSQL-hosted documents must be automatically generated.
Backend API services must scale automatically during business hours.
Cold start delay of backend APIs must be minimized.
Secrets must be stored outside of container images.
Developers must be able to correlate telemetry across Azure Functions hosts and apps.
All tracing must be implemented by using OpenTelemetry SDK instrumentation.
Development efforts must be minimized.
Technical Requirements
Container images must be built automatically and validated before code updates are merged into the main branch.
Image build automation must run inside the Azure Container Registry, eliminating dependency on local developer machines and external build services.
Dependency of image builds on local developer machines must be eliminated.
Event-driven scaling in ACA must occur based on the number of pending messages in the Azure Service Bus queue.
Azure Cosmos DB for NoSQL RU consumption must be minimized.
Vector similarity search must use embeddings stored in Azure Cosmos DB for NoSQL.
The partner-facing containerized webhook service must run on Azure App Service.
Secrets must NOT be stored in container images, source control, or application configuration directly. They must be accessed securely at runtime.
All secrets must be stored centrally in Azure Key Vault and accessed at runtime through a managed identity.
Azure App Service must supply secrets at runtime without relying on external services.
Resources and workloads must be deployed by using Bicep templates through an automated, version-controlled pipeline. Local and command-line deployments must be eliminated to ensure repeatable, auditable deployments.
Known Issues
RU consumption spikes during vector similarity queries.
You need to configure event-driven scaling for the backend API services to meet the technical requirements.
Which settings should you use for each element? To answer, move the appropriate settings to the correct elements. You may use each setting once, more than once, or not at all. You may need to move the split bar between panes or scroll to view content.
NOTE: Each correct selection is worth one point.

Community Insight
It tests whether you can map ACA KEDA scaler fields to Service Bus queue depth and cold-start requirements, with the trap being to use the Storage Queue scaler's queueLength field or scale to zero.
This AI-200 case-study item tests configuring Azure Container Apps event-driven scaling from an Azure Service Bus queue. The page establishes the azure-servicebus KEDA scaler, the messageCount trigger metadata, and min-replicas 1 for cold-start avoidance.
Candidates often choose queueLength because KEDA uses it for Azure Storage Queue scalers, but the Azure Service Bus scaler's target is messageCount; they also set min replicas to 0 and reintroduce cold starts.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The case requires ACA event-driven scaling from "the number of pending messages in the Azure Service Bus queue," which maps to a KEDA Service Bus scaler, not an HTTP or CPU rule. In ACA, the scaler type is azure-servicebus, and its target queue-depth metadata is messageCount; queueLength is not the Service Bus scaler's metadata key. Setting min-replicas to 1 keeps at least one backend API replica running, satisfying "Cold start delay of backend APIs must be minimized" while still allowing the rule to scale out on queue depth. This combination directly matches the technical requirement and avoids scale-to-zero.Why Other Candidate Answers Are Wrong
queueLength is the Azure Storage Queue scaler's metadata and is a common trap; using it for Service Bus leaves the rule without a valid target. Setting min-replicas to 0 is wrong because ACA can scale to zero and the next Service Bus message incurs cold-start latency, violating the minimization requirement. CPU/memory or HTTP scalers do not measure pending Service Bus messages, so they cannot satisfy the event-driven queue-depth requirement. messageCount alone without the azure-servicebus scaler type would not bind to the Service Bus queue.Community Comment Notes
Codia argued for "queueLength", but the Azure Service Bus KEDA scaler documents messageCount as the queue-depth target, so that comment should not override the vendor metadata. Mattt correctly linked "Cold start delay of backend APIs must be minimized" to min-replicas 1, explaining that 0 permits scale-to-zero. Ja13's selection of messageCount and min-replicas 1 aligns with the documented scaler fields. The split shows why verifying the exact KEDA scaler metadata matters more than vote count.Official Reference
Exam Strategy
For ACA scaling items, first identify the KEDA scaler type, then confirm the exact metadata key for that scaler rather than reusing a key from a different scaler. Check cold-start requirements against min-replicas because 0 is almost always wrong when latency must be minimized.
Frequently Asked Questions
Does the Azure Service Bus KEDA scaler use queueLength or messageCount in ACA?
It uses messageCount for the target queue depth; queueLength belongs to the Azure Storage Queue scaler, not the Service Bus scaler.
Why set min replicas to 1 for the backend API in Azure Container Apps?
Keeping one replica warm avoids scale-to-zero cold starts, which the case requires when minimizing backend API cold-start delay.