This post is a part of the AI-200: Developing AI Cloud Solutions on Azure Exam Prep Hub.
This topic falls under these sections:
Develop containerized solutions on Azure (20–25%)
--> Implement container-orchestrated solutions
--> Implement event-driven scaling by using Kubernetes Event‑driven Autoscaling (KEDA) in Container Apps
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
Modern AI applications frequently perform work asynchronously. Instead of processing every request synchronously, an application might place work onto a queue or event stream and have one or more containerized workers process those events.
This architecture creates an important scaling question:
How can the application automatically add or remove container instances based on the amount of work waiting to be processed?
Kubernetes Event-driven Autoscaling (KEDA) provides the answer.
Azure Container Apps uses KEDA to support event-driven autoscaling. A container app can use KEDA-based scaling rules to respond to events and metrics from supported sources such as Azure Service Bus, Azure Event Hubs, Apache Kafka, and Redis. Container Apps manages the KEDA integration for you, so you don’t install or operate KEDA yourself.
For the AI-200 exam, the important skill is understanding when to use KEDA, how KEDA determines replica counts, how scaling rules are configured, and how authentication and scale limits affect the resulting application behavior.
1. What Is KEDA?
Kubernetes Event-driven Autoscaling (KEDA) is an autoscaling component designed to scale containerized workloads based on events or external metrics.
Traditional autoscaling commonly uses resource metrics such as:
- CPU utilization
- Memory utilization
Those metrics can be useful, but they don’t always represent the actual workload.
Consider an AI document-processing application:
┌──────────────────┐
Documents ────► │ Service Bus │
│ Queue │
└────────┬─────────┘
│
│ Pending messages
▼
┌──────────────────┐
│ KEDA scaler │
└────────┬─────────┘
│
Scale decision
│
┌──────────┴──────────┐
▼ ▼
Container App Container App
Replica 1 Replica 2
If there are only a few messages, the application may need only one replica.
If thousands of messages are waiting, additional replicas can be created to process the workload concurrently.
This is event-driven autoscaling.
2. KEDA in Azure Container Apps
Azure Container Apps incorporates KEDA into its scaling architecture.
This is an important exam distinction:
You don’t deploy and manage a separate KEDA installation for an Azure Container App.
Instead, you configure a scale rule on the container app. Azure Container Apps uses KEDA behind the scenes to evaluate the rule and determine how many replicas are needed.
Conceptually:
External event source │ ▼ KEDA scaler │ ▼Scale rule evaluation │ ▼Desired replica count │ ▼Azure Container Apps │ ├── Replica 1 ├── Replica 2 ├── Replica 3 └── ...
This makes KEDA particularly useful for background workers and asynchronous AI workloads.
3. Why Event-Driven Scaling Is Important for AI Applications
AI workloads frequently have unpredictable demand.
For example, imagine a document-processing application:
- Users upload documents.
- Documents are placed into an Azure Service Bus queue.
- Containerized workers retrieve documents.
- Workers send documents to an AI service.
- Results are stored in a database.
During periods of low activity, perhaps only one worker is necessary.
During a large batch upload, hundreds or thousands of documents might be waiting.
A fixed number of replicas creates two problems:
Too few replicas
1 worker │ ├── Document 1 ├── Document 2 ├── Document 3 ├── ... └── Document 10,000
Processing becomes slow.
Too many replicas
20 workers │ └── Almost nothing to process
Resources are unnecessarily consumed.
KEDA allows the application to dynamically respond to the workload.
4. KEDA Versus CPU-Based Autoscaling
A common exam scenario is determining whether resource-based scaling or event-based scaling is more appropriate.
Suppose a worker application consumes messages from Azure Service Bus.
CPU usage might look like this:
| Queue Messages | CPU Usage |
|---|---|
| 0 | 5% |
| 100 | 15% |
| 1,000 | 20% |
| 10,000 | 25% |
CPU isn’t necessarily a good representation of the amount of work waiting.
KEDA can instead monitor the queue itself.
For example:
Target = 20 messages per replica20 messages → 1 replica40 messages → 2 replicas100 messages → 5 replicas200 messages → 10 replicas
This makes the scaling decision directly related to the workload.
5. KEDA Scalers
A KEDA scaler connects KEDA to an external event source or metric.
Azure Container Apps supports KEDA-based custom scaling rules for various event sources.
Common examples include:
- Azure Service Bus
- Azure Event Hubs
- Apache Kafka
- Redis
- Azure Queue Storage
- Other supported KEDA scalers through custom rules
Azure Container Apps also supports HTTP and TCP scaling rules, but these aren’t the same thing as event-driven KEDA scaling.
For the exam, remember:
HTTP scaling and event-driven scaling are different scaling mechanisms.
6. Container Apps Scale Rules
Scaling is configured through the container app’s scale configuration.
A scale configuration contains concepts such as:
minReplicasmaxReplicasrules- polling interval
- cooldown period
A simplified conceptual configuration looks like this:
scale: minReplicas: 0 maxReplicas: 10 rules: - name: service-bus-rule type: azure-servicebus metadata: queueName: orders messageCount: 20
The exact metadata depends on the KEDA scaler being used.
The important exam concept is the relationship:
Scale Rule │ ├── Scaler type ├── Metadata └── Authentication │ ▼ KEDA │ ▼ Desired replicas
7. minReplicas
minReplicas specifies the minimum number of replicas that the application can maintain.
For example:
minReplicas = 1
means that the application won’t scale below one replica.
This is useful when:
- The application must always be available.
- Cold-start latency is undesirable.
- The workload can’t tolerate scaling to zero.
By contrast:
minReplicas = 0
allows the application to scale down to zero when there is no workload.
Azure Container Apps supports a minimum of zero replicas and a maximum configurable replica count of up to 1,000.
8. maxReplicas
maxReplicas establishes the upper limit on scaling.
For example:
minReplicas: 0maxReplicas: 20
means:
0 ≤ replicas ≤ 20
Even if the event source contains a massive backlog, the application won’t exceed the configured maximum.
This is important for:
- Controlling costs
- Protecting downstream services
- Preventing excessive concurrency
- Preventing an application from overwhelming a database or AI service
Exam tip
If a question asks:
“How can you prevent an event-driven application from creating an excessive number of replicas?”
Look for:
Configure maxReplicas.
9. Target Values and Scaling
Many KEDA scalers use a target value that represents the desired workload per replica.
For example, consider:
messageCount = 20
Conceptually, this means the scaler targets approximately 20 messages per replica.
If there are 100 messages:
Desired replicas = ceil(100 / 20)Desired replicas = 5
Therefore:
100 messages │ ▼Target = 20 messages/replica │ ▼5 replicas
Azure Container Apps describes the general scaling calculation as:
desiredReplicas = ceil(currentMetricValue / targetMetricValue)
subject to the configured scaling limits and Container Apps’ scaling behavior.
10. Example: Azure Service Bus
Suppose an AI application processes image-analysis requests from an Azure Service Bus queue.
The scaling rule specifies:
messageCount = 10minReplicas = 0maxReplicas = 10
The approximate relationship is:
| Messages | Desired Replicas |
|---|---|
| 0 | 0 |
| 1–10 | 1 |
| 11–20 | 2 |
| 21–30 | 3 |
| 51–60 | 6 |
| 91–100 | 10 |
| 500 | 10 |
The final example is limited by maxReplicas.
Therefore, even if 500 messages are waiting, the application won’t create 50 replicas when the maximum is 10.
11. Polling Interval
KEDA periodically checks the event source.
Azure Container Apps uses a default KEDA polling interval of 30 seconds for custom scale rules.
Conceptually:
T0 │ ├── KEDA checks queue │T+30 sec │ ├── KEDA checks queue │T+60 sec │ ├── KEDA checks queue │...
This is important because event-driven scaling isn’t necessarily instantaneous.
If a question describes a workload that suddenly receives messages and asks why scaling doesn’t happen immediately, the polling interval may be relevant.
12. Cooldown Period
The cooldown period determines how long KEDA waits before scaling an application from its final active replica down to zero after the event source becomes inactive.
The default cooldown period for Container Apps custom scaling is 300 seconds.
For example:
Messages arrive │ ▼Scale out │ ▼Messages processed │ ▼Queue becomes empty │ ▼Cooldown period │ ▼Scale to zero
An important distinction is that the cooldown period specifically affects scaling from the final replica to zero; it isn’t simply a universal delay applied to every scale-in operation.
13. Scale-to-Zero
One of the major advantages of event-driven scaling is the ability to scale an application to zero.
For example:
No work │ ▼0 replicas │ │ New event arrives ▼1 replica │ ▼More events │ ▼5 replicas
This is especially useful for workloads that aren’t continuously active.
Examples include:
- Document processing
- Image processing
- AI inference jobs
- Data enrichment
- Background processing
- Queue consumers
When the workload disappears, the application can eventually return to zero replicas.
Azure Container Apps doesn’t charge usage charges for a container app while it is scaled to zero.
14. Authentication for KEDA Scale Rules
A KEDA scaler often needs permission to inspect the external event source.
For example, a Service Bus scaler needs access to Service Bus.
Azure Container Apps supports authentication for scale rules using:
- Secrets
- Managed identities for supported Azure resources
The authentication configuration is associated with the scale rule rather than requiring application code to perform the scaling operation.
Managed identity
For Azure resources, managed identity is often preferable because the application doesn’t need to store a long-lived credential.
Conceptually:
Container App │ │ Managed Identity ▼Microsoft Entra ID │ ▼Azure Service Bus
This is generally preferable to embedding credentials in application source code.
15. Secret-Based Authentication
Scale rules can also reference secrets.
Conceptually:
Container App │ ├── Secret │ ▼KEDA scale rule │ ▼Event source
For example, a Service Bus connection string could be stored as a Container Apps secret and referenced by the scale rule.
Exam distinction
Don’t confuse:
Application authentication
with:
Scaler authentication
The application itself may have its own credentials or managed identity, while KEDA separately needs authorization to inspect the event source.
16. Multiple Scaling Rules
A container app can have multiple scaling rules.
For example:
Container App │ ├── HTTP rule │ ├── Service Bus rule │ └── Redis rule
When multiple rules are configured, the application scales when the first applicable scaling condition is met.
This means you can combine different workload signals.
For example:
HTTP traffic ────────┐ │Service Bus backlog ─┼──► Scaling decision │Redis events ────────┘
17. KEDA and Azure Container Apps Revisions
A particularly important Azure Container Apps concept is that changing scaling rules creates a new revision of the container app. A revision is an immutable snapshot of the application configuration.
Conceptually:
Revision 1 │ ├── Old scaling rules │ ▼Update scaling configuration │ ▼Revision 2 │ └── New scaling rules
This matters when managing production applications using revision-based deployment strategies.
18. KEDA and Dapr
KEDA can also be used with Dapr-based applications.
For example, an application could use Dapr pub/sub:
Publisher │ ▼Dapr Pub/Sub │ ▼Subscriber Container App │ ▼KEDA
KEDA can scale the subscriber based on pending events/messages.
In this scenario, KEDA can scale both the application and its Dapr sidecar based on the workload.
19. KEDA Versus Event-Driven Container Apps Jobs
Azure Container Apps supports both:
Container Apps
A container app normally maintains a number of replicas that continuously process work.
Queue │ ▼Container App ├── Replica 1 ├── Replica 2 └── Replica 3
Event-driven Container Apps Jobs
An event can instead trigger individual job executions.
Queue │ ├── Event 1 ──► Job execution 1 ├── Event 2 ──► Job execution 2 └── Event 3 ──► Job execution 3
Both use KEDA-based scaling concepts, but the result is different.
For an application, the scaling rule determines the number of replicas.
For an event-driven job, the scaling rule determines the number of job executions to start.
Exam tip
If the question says:
“Each event should result in a separate container execution.”
Consider an event-driven Container Apps Job rather than a continuously running container app.
20. KEDA Configuration Concepts to Know
For AI-200, be comfortable recognizing these concepts:
| Concept | Purpose |
|---|---|
| Scaler | Connects KEDA to an event source or metric |
| Scale rule | Defines how Container Apps uses a scaler |
| Metadata | Provides scaler-specific configuration |
| Authentication | Allows KEDA to access the event source |
| minReplicas | Lowest number of replicas |
| maxReplicas | Highest number of replicas |
| Polling interval | How frequently KEDA checks an event source |
| Cooldown period | Delay associated with scaling the final replica to zero |
| Scale-to-zero | Allows inactive applications to have zero replicas |
| Replica | An active instance of the container app revision |
21. Example Architecture
Consider an AI document-classification system.
┌──────────────────┐
│ Web/API App │
└────────┬─────────┘
│
│ Submit document
▼
┌──────────────────┐
│ Azure Service │
│ Bus Queue │
└────────┬─────────┘
│
Pending messages
│
▼
┌──────────────────┐
│ KEDA │
│ Scaler │
└────────┬─────────┘
│
Scaling decision
│
▼
┌─────────────────────────┐
│ Azure Container App │
│ │
│ ┌────┐ ┌────┐ ┌────┐ │
│ │ R1 │ │ R2 │ │ R3 │...│
│ └────┘ └────┘ └────┘ │
└───────────┬─────────────┘
│
▼
Azure AI Service
│
▼
Data Store
The important point is that KEDA doesn’t process the messages.
KEDA’s responsibility is to determine how many replicas should be running.
The application replicas are responsible for processing the messages.
22. Common Exam Scenarios
Scenario 1: Queue backlog
A containerized AI worker processes Service Bus messages. The application should automatically add workers as the queue backlog increases.
Use KEDA event-driven scaling.
Scenario 2: Scale to zero
The application should consume no running replicas when there are no messages.
Configure:
minReplicas = 0
and use an appropriate event-driven scale rule.
Scenario 3: Limit cost
A sudden event spike must not cause more than 20 workers.
Configure:
maxReplicas = 20
Scenario 4: Avoid stored credentials
KEDA needs access to an Azure Service Bus resource, and the organization doesn’t want connection strings stored.
Use an appropriate managed identity configuration.
Scenario 5: Separate execution per event
Each event should start an independent container execution.
Consider an event-driven Container Apps Job rather than a continuously running container app.
23. Common Mistakes to Avoid
Mistake 1: Installing KEDA manually
For Azure Container Apps, you don’t need to deploy your own KEDA installation.
Remember: Container Apps provides the KEDA integration.
Mistake 2: Assuming KEDA only works with Kubernetes clusters
KEDA originated in the Kubernetes ecosystem, but Azure Container Apps exposes KEDA functionality without requiring you to manage Kubernetes infrastructure.
Mistake 3: Confusing KEDA with CPU autoscaling
KEDA is particularly valuable when scaling should be driven by external events or metrics, such as queue length or event backlog.
Mistake 4: Forgetting maxReplicas
Without an appropriate maximum, a large workload can potentially result in substantial scale-out.
Always consider:
minReplicasmaxReplicas
Mistake 5: Assuming scaling is instantaneous
KEDA polls event sources. The default polling interval for custom Container Apps scaling rules is 30 seconds, so there can be a delay between a change in workload and the scaling decision.
Mistake 6: Confusing cooldown with polling
These are different:
Polling interval
How frequently KEDA checks the event source.
Cooldown period
How long KEDA waits before scaling the final replica to zero after the workload becomes inactive.
24. AI-200 Exam Takeaways
For the exam, make sure you can answer these questions:
What is KEDA?
A Kubernetes-based event-driven autoscaling mechanism used by Azure Container Apps to scale workloads based on external events and metrics.
Why use KEDA?
When application demand is better represented by an external event source—such as a queue backlog—than by CPU or memory utilization.
Do you install KEDA in Container Apps?
No. Azure Container Apps provides the KEDA integration.
What controls the minimum number of replicas?
minReplicas
What controls the maximum?
maxReplicas
What determines the type of event source?
The KEDA scaler type, such as:
azure-servicebus
What does scaler metadata provide?
The scaler-specific information needed to monitor the event source and determine scaling.
Can Container Apps scale to zero?
Yes, when configured appropriately, such as with minReplicas: 0.
What is the default polling interval?
30 seconds for custom KEDA scale rules.
What is the default cooldown period?
300 seconds for custom scaling, with the cooldown specifically applying to scaling from the final replica to zero.
What happens when multiple scale rules exist?
The application begins scaling when the condition for the first applicable rule is met.
Practice Exam Questions
Question 1
An AI application running in Azure Container Apps processes messages from an Azure Service Bus queue. The application should automatically increase the number of replicas when the number of pending messages increases.
Which technology should you use?
A. Kubernetes Event-driven Autoscaling (KEDA)
B. Azure Traffic Manager
C. Azure Front Door
D. Azure DNS
Answer: A
Explanation
KEDA is designed for event-driven autoscaling. In Azure Container Apps, KEDA can monitor supported event sources such as Azure Service Bus and adjust the number of application replicas according to the workload.
The other services are primarily concerned with traffic routing or DNS rather than workload-driven container scaling.
Question 2
You configure an Azure Container App with the following settings:
minReplicas: 0maxReplicas: 10
The application uses a KEDA-based scale rule and currently has no events to process.
What is the expected minimum number of running replicas?
A. 0
B. 5
C. 1
D. 10
Answer: A
Explanation
minReplicas specifies the minimum number of replicas. Setting it to 0 permits the application to scale to zero when the workload is inactive.
This is one of the major benefits of event-driven scaling for intermittently used workloads.
Question 3
An AI worker consumes messages from an Azure Service Bus queue. The KEDA scale rule uses a target of 20 messages per replica. There are currently 100 messages waiting.
Ignoring scaling limits and other scaling behavior, approximately how many replicas does the target calculation request?
A. 2
B. 5
C. 20
D. 100
Answer: B
Explanation
The target calculation is conceptually:
desiredReplicas = ceil(currentMetricValue / targetMetricValue)desiredReplicas = ceil(100 / 20)desiredReplicas = 5
Therefore, the target is approximately 5 replicas.
Question 4
An organization wants to ensure that an event-driven Container App never scales beyond 25 replicas, even when a large backlog accumulates.
Which setting should you configure?
A. pollingInterval
B. cooldownPeriod
C. minReplicas
D. maxReplicas
Answer: D
Explanation
maxReplicas establishes the maximum number of replicas that the container app can use for the configured scaling configuration.
For this requirement, configure:
maxReplicas: 25
pollingInterval controls how frequently the event source is checked, while cooldownPeriod relates to scale-down behavior. minReplicas controls the lower bound.
Question 5
A developer wants KEDA in an Azure Container App to determine scaling based on the number of pending messages in Azure Service Bus.
Which component identifies the event source and its associated scaling behavior?
A. Azure Monitor workbook
B. Container Apps ingress configuration
C. KEDA scaler
D. Azure Load Balancer
Answer: C
Explanation
A KEDA scaler connects the autoscaling mechanism to an event source or external metric. The scaler type and associated metadata define how KEDA obtains the workload information.
Ingress and load-balancing configurations don’t provide this event-driven autoscaling capability.
Question 6
An application uses a KEDA custom scale rule in Azure Container Apps. The administrator wants to understand how frequently KEDA checks the external event source by default.
Which interval should the administrator expect?
A. 5 seconds
B. 30 seconds
C. 5 minutes
D. 15 minutes
Answer: B
Explanation
The default polling interval for custom KEDA scaling rules in Azure Container Apps is 30 seconds.
This means event-driven scaling isn’t necessarily evaluated continuously or instantaneously.
Question 7
An AI application uses an Azure Service Bus queue. The organization wants KEDA to access the Azure resource without storing a long-lived Service Bus credential in the application configuration.
Which approach is most appropriate?
A. Disable authentication for the scale rule
B. Store the credential in application source code
C. Use a managed identity where supported
D. Increase the maximum replica count
Answer: C
Explanation
Azure Container Apps supports managed identity authentication for supported Azure resource scale rules.
Managed identities allow Azure resources to authenticate without requiring application developers to embed long-lived credentials in source code or configuration.
Question 8
An event-driven Container App has finished processing its queue. The application currently has one replica, and the queue remains empty.
The application is configured with the default 300-second cooldown period.
What is the purpose of the cooldown period?
A. Determine how frequently the queue is polled
B. Determine the maximum number of replicas
C. Determine the target number of messages per replica
D. Delay scaling the final replica to zero after the workload becomes inactive
Answer: D
Explanation
The cooldown period is associated with scaling from the final active replica to zero.
For Container Apps custom scaling rules, the default cooldown period is 300 seconds.
It should not be confused with the polling interval, which determines how frequently KEDA checks the event source.
Question 9
An Azure Container App has two scaling rules:
- An HTTP scaling rule
- An Azure Service Bus KEDA scaling rule
The Service Bus queue suddenly contains a large backlog while HTTP traffic remains low.
What happens?
A. The application can scale based on the Service Bus rule
B. Only the HTTP rule is evaluated
C. The application must use CPU scaling instead
D. The two rules are averaged before scaling
Answer: A
Explanation
Azure Container Apps can have multiple scaling rules. The application begins scaling when the condition for an applicable rule is met.
Therefore, a Service Bus backlog can cause scaling even if HTTP traffic isn’t high enough to trigger the HTTP rule.
Question 10
A development team has a workload in which each incoming event should trigger a separate container execution. The workload doesn’t need a continuously running pool of worker replicas.
Which Azure Container Apps capability is the best fit?
A. HTTP ingress scaling
B. Event-driven Container Apps Jobs
C. Azure Traffic Manager
D. TCP ingress scaling
Answer: B
Explanation
Event-driven Container Apps Jobs are designed for workloads where events trigger individual job executions.
This differs from a normal Container App, where KEDA determines how many replicas of the application should be running to process the workload.
For example:
Event 1 → Job execution 1Event 2 → Job execution 2Event 3 → Job execution 3
A continuously running container application would instead maintain a pool of replicas that process events.
Final Exam Cheat Sheet
| Topic | Key Point |
|---|---|
| KEDA | Event-driven autoscaling |
| Azure Container Apps + KEDA | KEDA integration is managed by Container Apps |
| Primary use case | Scale based on external events/metrics |
| Examples | Service Bus, Event Hubs, Kafka, Redis |
minReplicas | Minimum replicas |
maxReplicas | Maximum replicas |
minReplicas = 0 | Allows scale-to-zero |
| Scaler | Connects KEDA to an event source |
| Metadata | Configures the scaler |
| Authentication | Secrets or managed identity where supported |
| Default polling interval | 30 seconds |
| Default cooldown | 300 seconds |
| Target calculation | ceil(metric / target) conceptually |
| Multiple rules | Scaling can begin when an applicable rule triggers |
| Scaling-rule changes | Create a new Container Apps revision |
| Container App | Scales replicas |
| Event-driven Container Apps Job | Scales job executions |
| Primary benefit | Efficient scaling based on actual workload |
| Major advantage | Can scale inactive workloads to zero |
The key idea to remember for AI-200 is simple: KEDA allows Azure Container Apps to scale containerized workloads according to events and external workload metrics rather than relying solely on traditional resource utilization such as CPU or memory.
Go to the AI-200 Exam Prep Hub main page
The Data Community 