Tag: Kubernetes

AI-200, azure, Cloud computing, Microsoft Certification

Implement event-driven scaling by using Kubernetes Event‑driven Autoscaling (KEDA) in Container Apps (AI-200 Exam Prep)

 
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:

  1. Users upload documents.
  2. Documents are placed into an Azure Service Bus queue.
  3. Containerized workers retrieve documents.
  4. Workers send documents to an AI service.
  5. 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 MessagesCPU Usage
05%
10015%
1,00020%
10,00025%

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 replica
20 messages → 1 replica
40 messages → 2 replicas
100 messages → 5 replicas
200 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:

  • minReplicas
  • maxReplicas
  • rules
  • 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: 0
maxReplicas: 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 = 10
minReplicas = 0
maxReplicas = 10

The approximate relationship is:

MessagesDesired Replicas
00
1–101
11–202
21–303
51–606
91–10010
50010

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:

ConceptPurpose
ScalerConnects KEDA to an event source or metric
Scale ruleDefines how Container Apps uses a scaler
MetadataProvides scaler-specific configuration
AuthenticationAllows KEDA to access the event source
minReplicasLowest number of replicas
maxReplicasHighest number of replicas
Polling intervalHow frequently KEDA checks an event source
Cooldown periodDelay associated with scaling the final replica to zero
Scale-to-zeroAllows inactive applications to have zero replicas
ReplicaAn 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:

minReplicas
maxReplicas

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: 0
maxReplicas: 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 1
Event 2 → Job execution 2
Event 3 → Job execution 3

A continuously running container application would instead maintain a pool of replicas that process events.

Final Exam Cheat Sheet

TopicKey Point
KEDAEvent-driven autoscaling
Azure Container Apps + KEDAKEDA integration is managed by Container Apps
Primary use caseScale based on external events/metrics
ExamplesService Bus, Event Hubs, Kafka, Redis
minReplicasMinimum replicas
maxReplicasMaximum replicas
minReplicas = 0Allows scale-to-zero
ScalerConnects KEDA to an event source
MetadataConfigures the scaler
AuthenticationSecrets or managed identity where supported
Default polling interval30 seconds
Default cooldown300 seconds
Target calculationceil(metric / target) conceptually
Multiple rulesScaling can begin when an applicable rule triggers
Scaling-rule changesCreate a new Container Apps revision
Container AppScales replicas
Event-driven Container Apps JobScales job executions
Primary benefitEfficient scaling based on actual workload
Major advantageCan 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