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 application hosting
      --> Deploy applications to Azure Container Apps, including environment configuration and revision management

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.

Introduction

Azure Container Apps is a serverless container platform designed for running modern applications and microservices without requiring developers to manage the underlying Kubernetes infrastructure. For the AI-200 exam, developers should understand not only how to deploy a containerized application, but also how to configure its Container Apps environment, manage application settings, and use revisions to safely deploy and operate different versions of an application.

This topic is particularly important because Azure Container Apps separates the concepts of the application environment, the container application, and the revision. Understanding those boundaries makes many exam questions much easier to answer.

1. What Is Azure Container Apps?

Azure Container Apps provides a managed platform for running containerized applications while abstracting much of the infrastructure management associated with Kubernetes.

It is well suited for applications such as:

• REST APIs
• Web applications
• Microservices
• Background processing services
• Event-driven applications
• AI inference services
• Containerized application backends

Unlike Azure Kubernetes Service, developers do not need to manage Kubernetes clusters, nodes, or the Kubernetes control plane.

Azure Container Apps can provide:

• Containerized application hosting
• Automatic scaling
• Scale-to-zero capabilities
• HTTP and TCP ingress
• Service-to-service communication
• Revisions and traffic splitting
• Secrets and configuration
• Managed identities
• Dapr integration
• Logging and monitoring
• Workload profiles

For AI applications, Container Apps can be particularly useful for hosting APIs, inference services, orchestration components, and other containerized workloads.

2. Understand the Container Apps Environment

A Container Apps environment is a secure boundary around a group of Container Apps.

Multiple Container Apps can be deployed into the same environment. Apps within the same environment can share important infrastructure characteristics, including networking and logging. Microsoft describes the environment as a secure boundary for a group of container apps.

A useful mental model is:

Azure subscription → Resource group → Container Apps environment → Container Apps → Revisions

For example:

Subscription
│
└── Resource Group
    │
    └── Container Apps Environment
        │
        ├── customer-api
        │   ├── Revision 1
        │   ├── Revision 2
        │   └── Revision 3
        │
        ├── recommendation-api
        │   ├── Revision 1
        │   └── Revision 2
        │
        └── document-processor
            └── Revision 1

The environment therefore provides infrastructure-level isolation and shared capabilities, while the individual Container App represents an application or service running inside that environment.

3. Why the Environment Matters

When creating a Container App, you either select an existing Container Apps environment or create a new one.

Environment configuration can affect:

• Networking
• Logging
• Workload profiles
• Application isolation
• Communication between applications
• Infrastructure configuration

For example, applications deployed into the same environment can communicate with one another using Container Apps’ internal networking capabilities.

The environment can also be associated with logging infrastructure such as a Log Analytics workspace.

Exam Tip

If a question says that several Container Apps need to share a common environment, networking boundary, or logging configuration, think about the Container Apps environment rather than creating separate environments for every application.

4. Creating a Container App

A typical deployment involves the following conceptual steps:

1. Create or select a resource group.
2. Create or select a Container Apps environment.
3. Specify the container image.
4. Configure compute resources.
5. Configure environment variables and secrets.
6. Configure ingress if the application needs to receive traffic.
7. Configure scaling.
8. Deploy the application.
9. Monitor the resulting revision.

For example, Azure CLI can deploy an existing container image with a command conceptually similar to:

az containerapp create \
  --name my-container-app \
  --resource-group my-resource-group \
  --environment my-container-environment \
  --image myregistry.azurecr.io/myapp:v1 \
  --target-port 80 \
  --ingress external

The important exam concept is not memorizing the exact command syntax. Instead, understand which configuration belongs to the environment and which belongs to the Container App.

5. Container App Configuration vs. Revision Configuration

One of the most important concepts for AI-200 is that not every change to a Container App creates a new revision.

Azure Container Apps distinguishes between:

Revision-scope changes

These changes define the version of the application and result in a new revision.

Examples include changes to:

• Container image
• Container configuration
• Container resources
• Environment variables associated with the container template
• Scale configuration
• Scale rules
• Container commands and arguments
• Probes
• Volumes and mounts
• Revision suffix

The Container Apps API documentation describes the template as the versioned application definition, and changes to the template result in a new immutable revision.

Application-scope changes

These changes affect the Container App configuration rather than creating a new version of the application.

Examples include:

• Revision mode
• Ingress configuration
• Traffic rules
• Secrets
• Registry credentials
• Dapr configuration
• Other application-level configuration

These settings apply to the application rather than representing a new immutable revision.

Exam shortcut

When deciding whether a change creates a revision, ask:

Does this change define the versioned application template?

If yes, it is generally a revision-scope change.

If it changes how the application is configured or exposed without changing the application template, it is generally an application-scope change.

6. What Is a Revision?

A revision is an immutable snapshot of a Container App’s versioned configuration.

Think of a revision as a deployable version of the application.

For example:

customer-api
│
├── Revision 1 → v1 container image
├── Revision 2 → v2 container image
└── Revision 3 → v3 container image

Once created, a revision is immutable.

If you change the container image from:

myapp:v1

to:

myapp:v2

Azure Container Apps creates a new revision rather than modifying the existing revision.

This provides an important deployment-management capability:

A deployed revision represents a known version of the application.

Microsoft’s documentation describes revisions as immutable, versioned snapshots that can remain available for rollback, testing, or traffic management.

7. Why Revisions Are Important

Revisions provide several important capabilities.

Version management

You can identify different versions of an application.

Safe deployments

A new revision can be deployed without immediately replacing the existing version in multiple-revision scenarios.

Rollbacks

If a new version fails, traffic can be directed back to a previous revision.

A/B testing

Different revisions can receive different percentages of traffic.

Blue-green deployments

One revision can serve production traffic while another is deployed and validated before switching traffic.

Testing

A new revision can be tested before directing production traffic to it.

These capabilities make revisions particularly valuable for AI applications where changes to models, inference code, prompts, dependencies, or APIs may need controlled deployment.

8. Single Revision Mode

Azure Container Apps supports single revision mode and multiple revision mode. Single revision mode is the default.

In single revision mode:

• Only one revision is active at a time.
• A new revision is created when a revision-scoped change is deployed.
• Azure manages the transition from the old revision to the new revision.
• Traffic moves to the new revision after it is ready.
• The old revision is eventually deprovisioned.

This mode is useful when the desired deployment model is essentially:

“Deploy the new version and replace the old version.”

For example:

Before deployment:
100% traffic
     │
     ▼
Revision 1
After deployment:
100% traffic
     │
     ▼
Revision 2

9. Zero-Downtime Deployment

Single revision mode is designed to avoid unnecessary downtime during deployment.

When a new revision is created, the existing revision continues serving traffic while the new revision is provisioned.

The new revision must become ready before traffic is moved.

Readiness involves factors such as:

• Successful provisioning
• Required replicas becoming available
• Startup probes passing
• Readiness probes passing

Therefore, if a new revision fails to become ready, the existing revision can continue serving traffic rather than immediately being replaced.

Exam scenario

Suppose:

• Revision 1 is healthy.
• Revision 2 is deployed.
• Revision 2 fails its readiness checks.

The safest answer is generally that Revision 1 continues receiving traffic in single revision mode while Revision 2 fails to become ready.

10. Multiple Revision Mode

Multiple revision mode allows multiple revisions to remain active simultaneously.

This provides significantly more control over deployments.

For example:

                 ┌── Revision 1 ── 80%
Incoming traffic ┤
                 └── Revision 2 ── 20%

This is useful for:

• A/B testing
• Canary releases
• Blue-green deployments
• Gradual rollouts
• Testing a new application version
• Maintaining multiple application versions

Microsoft’s traffic-splitting functionality allows traffic to be distributed among active revisions using percentage weights. The total traffic allocation must equal 100%.

11. Traffic Splitting

In multiple revision mode, traffic can be divided among revisions.

For example:

Revision 1 → 90%
Revision 2 → 10%

This means approximately 90% of incoming traffic is routed to Revision 1 and 10% to Revision 2.

A common deployment strategy is to gradually increase the percentage assigned to the new revision:

Stage 1
v1 = 100%
v2 =   0%
Stage 2
v1 =  90%
v2 =  10%
Stage 3
v1 =  50%
v2 =  50%
Stage 4
v1 =   0%
v2 = 100%

This provides a controlled rollout.

Important exam point

Traffic weights must add up to 100%.

For example:

Revision A = 70%
Revision B = 30%

is valid.

But:

Revision A = 70%
Revision B = 20%

does not fully allocate traffic.

12. Revision Labels

Revision labels provide a way to identify a particular revision with a meaningful name.

Instead of relying entirely on an automatically generated revision name, a developer can use a label representing an environment or deployment stage.

For example:

staging
production

A labeled revision can be accessed through a label-specific endpoint.

Labels can be useful when:

• Testing a specific revision
• Maintaining a staging version
• Providing direct access to a particular revision
• Performing deployment workflows
• Separating testing traffic from production traffic

Azure CLI provides commands for managing revision labels, including adding, removing, and swapping labels.

13. Revision Names and Suffixes

Azure Container Apps automatically generates revision names, but developers can provide a meaningful revision suffix.

For example:

customer-api-v2

could be represented conceptually by a Container App named:

customer-api

with a revision suffix such as:

v2

Meaningful revision naming can make deployment management easier.

Good naming can help identify:

• Application version
• Deployment stage
• Release identifier
• Build number
• Feature release

However, revision names and suffixes have naming restrictions, so applications should follow Azure’s supported naming rules rather than assuming arbitrary strings are valid.

14. Deploying a New Revision

A new revision is created when a revision-scope property changes.

For example, changing:

image = myregistry.azurecr.io/customer-api:v1

to:

image = myregistry.azurecr.io/customer-api:v2

creates a new revision.

Conceptually:

Revision 1
Image: customer-api:v1
       │
       │ deploy image v2
       ▼
Revision 2
Image: customer-api:v2

Revision 1 remains an independent immutable version.

This is one of the most important concepts to understand for exam questions involving deployments.

15. Rollbacks

Suppose Revision 2 introduces a serious problem:

Revision 1 → stable
Revision 2 → defective

In a multiple-revision deployment, traffic can be redirected back to Revision 1.

For example:

Before rollback:
Revision 1 → 20%
Revision 2 → 80%
After rollback:
Revision 1 → 100%
Revision 2 → 0%

The existing revision doesn’t need to be rebuilt because the previous revision already represents the known-good application version.

This is one of the primary benefits of immutable revisions.

16. Blue-Green Deployments

Azure Container Apps revisions can be used to implement a blue-green deployment strategy.

For example:

BLUE
Revision 1
Production
100% traffic
GREEN
Revision 2
New version
0% traffic

The new revision can be tested while receiving no production traffic.

Once validation is complete:

BLUE  → 0%
GREEN → 100%

The new version becomes the production version.

If a problem occurs:

BLUE  → 100%
GREEN → 0%

This provides a fast rollback mechanism.

17. Canary Deployments

Multiple revisions can also support a canary release.

For example:

Stable revision → 95%
New revision    → 5%

Only a small percentage of users initially reach the new version.

If the new version performs well, the deployment can gradually increase its traffic allocation:

95/5
80/20
50/50
20/80
0/100

This is especially useful for AI applications because a new model or inference implementation can be exposed to a limited portion of traffic before being fully deployed.

18. Scaling and Revisions

Scaling configuration can also be revision-scoped.

For example, a Container App might use:

Minimum replicas: 1
Maximum replicas: 10

and scale based on HTTP concurrency.

Changing the application’s scale configuration can result in a new revision because scale settings are part of the versioned template.

This is important because two revisions can potentially have different scaling configurations.

For example:

Revision 1
min replicas = 1
max replicas = 5
Revision 2
min replicas = 2
max replicas = 20

In multiple revision mode, these revisions can coexist with their respective configurations.

19. Ingress Configuration

Ingress determines how network traffic reaches a Container App.

Depending on the application, ingress can be:

• External
• Internal

External ingress makes the application accessible from outside the environment.

Internal ingress is useful when the application should only be reachable from within the environment or associated network configuration.

Container Apps supports HTTP and TCP-oriented ingress scenarios, with HTTP/1.1, HTTP/2, and TCP transport options depending on the configuration and workload.

Exam clue

If a question asks:

“The application must be accessible from the public internet.”

Look for an external ingress configuration.

If it asks:

“The API should only be accessible by other applications inside the Container Apps environment.”

Look for internal ingress.

20. Environment Variables

Containerized applications frequently require configuration values such as:

ENVIRONMENT=Production
MODEL_NAME=my-model
API_ENDPOINT=https://example

These values can be provided as environment variables.

Environment variables are part of the container configuration and therefore can be associated with a revision.

For example:

Revision 1
API_ENDPOINT = endpoint-v1
Revision 2
API_ENDPOINT = endpoint-v2

This is important when different application versions need different configuration.

21. Secrets

Sensitive information should not be hard-coded into container images.

Examples include:

• API keys
• Passwords
• Connection strings
• Tokens
• Credentials

Azure Container Apps supports secrets that can be referenced by container environment variables.

Conceptually:

Container
   │
   └── Environment variable
           │
           └── secretRef
                    │
                    ▼
              Container App Secret

The Container Apps API supports environment variables that reference Container App secrets using secretRef.

For more advanced secret-management requirements, Azure Key Vault can be used rather than embedding credentials directly in the application.

Exam Tip

If the question asks where to store a password or API key, do not choose a Dockerfile or hard-coded environment variable.

Think:

Secret management → Container Apps secrets / Azure Key Vault

22. Private Container Registries

Container Apps can deploy images from private container registries.

For example:

Azure Container Registry
        │
        │ image
        ▼
Azure Container Apps

The Container App must have appropriate authorization to pull the image.

For Azure-hosted workloads, managed identities can often be used to avoid embedding long-lived credentials.

This follows an important security principle:

Prefer identity-based authentication over hard-coded credentials.

23. Container Apps and Azure Container Registry

A common AI-200 deployment architecture is:

Developer
   │
   ▼
Build container image
   │
   ▼
Azure Container Registry
   │
   ▼
Azure Container Apps
   │
   ├── Revision 1
   └── Revision 2

Azure Container Registry stores the container image while Azure Container Apps runs the container.

A new image version can then be deployed as a new revision.

For example:

my-ai-api:v1
my-ai-api:v2
my-ai-api:v3

Each deployment can correspond to a new revision.

24. Environment Configuration vs. Revision Management

A useful exam distinction is:

Understanding these distinctions helps prevent choosing an answer that sounds plausible but operates at the wrong level.

25. A Typical Deployment Lifecycle

A production deployment might look like this:

Step 1 — Build

Create the container image.

AI application source
        ↓
Docker build
        ↓
Container image

Step 2 — Store

Push the image to Azure Container Registry.

Container image
        ↓
Azure Container Registry

Step 3 — Deploy

Deploy the image to Azure Container Apps.

Registry
   ↓
Container App
   ↓
Revision 1

Step 4 — Update

Deploy a new image.

Registry
   ↓
Container App
   ↓
Revision 2

Step 5 — Validate

Check:

• Provisioning state
• Running state
• Replica health
• Application logs
• Health probes
• Application metrics

Step 6 — Route traffic

In multiple revision mode:

Revision 1 → 90%
Revision 2 → 10%

Step 7 — Complete rollout

If the new revision is healthy:

Revision 1 → 0%
Revision 2 → 100%

Step 8 — Roll back if necessary

If problems appear:

Revision 1 → 100%
Revision 2 → 0%

This workflow illustrates why revisions are such an important Azure Container Apps capability.

26. Common Exam Traps

Trap 1: Assuming every configuration change creates a revision

Not every change creates a new revision.

Remember the distinction between revision-scope and application-scope configuration.

Trap 2: Assuming revisions are mutable

Revisions are immutable.

To change the versioned application configuration, deploy a new revision.

Trap 3: Confusing single and multiple revision modes

Single mode is designed around one active revision.

Multiple mode allows several revisions to be active simultaneously.

Trap 4: Using traffic splitting in single mode

Traffic splitting requires multiple active revisions.

If the question specifically requires distributing traffic between two versions, look for multiple revision mode.

Trap 5: Assuming a failed new revision automatically replaces the healthy one

Azure Container Apps provides mechanisms that help maintain availability during deployment. In single revision mode, the existing revision can continue serving traffic while the new revision is being prepared.

Trap 6: Confusing a Container Apps environment with a Container App

The environment is the broader hosting boundary.

The Container App is the actual application.

Multiple Container Apps can exist within an environment.

Trap 7: Hard-coding secrets into a container

Passwords and API keys should not be placed directly into application code or container images.

Use appropriate secret-management capabilities.

Trap 8: Forgetting that scale configuration can be revision-specific

Scale configuration belongs to the versioned application template and can therefore create a new revision when changed.

27. AI-200 Exam Summary

For the AI-200 exam, remember these core points:

1. Azure Container Apps provides managed hosting for containerized applications.
2. A Container Apps environment provides a secure boundary for a group of Container Apps.
3. Multiple Container Apps can share the same environment.
4. A revision represents an immutable version of a Container App.
5. Changes to revision-scoped properties create new revisions.
6. Application-scoped changes don’t create new revisions.
7. Single revision mode is the default.
8. Multiple revision mode allows multiple active revisions.
9. Traffic can be split between active revisions in multiple mode.
10. Traffic weights must total 100%.
11. Revisions support blue-green deployments.
12. Revisions support canary and A/B testing scenarios.
13. Previous revisions can provide a convenient rollback target.
14. Revision labels can provide meaningful access to particular revisions.
15. Environment variables provide application configuration.
16. Secrets should be used for sensitive values.
17. Container Apps can pull images from container registries such as Azure Container Registry.
18. Managed identities can reduce the need for embedded credentials.
19. Ingress determines how applications receive network traffic.
20. Health probes and application readiness are important during deployment.
21. Scaling configuration can be revision-specific.
22. Understanding the difference between environment, application, revision, and traffic configuration is essential for scenario-based questions.

Practice Exam Questions

Question 1

You deploy a container app named orders-api using revision 1. You then change the container image from orders:v1 to orders:v2.

What happens when the change is deployed?

A. Revision 1 is modified in place.

B. A new revision is created containing the new container image.

C. The Container Apps environment is recreated.

D. The application is automatically moved to another region.

Answer: B

Explanation

The container image is part of the versioned container template. Changing the image is therefore a revision-scope change, which causes a new immutable revision to be created. Revision 1 remains unchanged. Azure’s Container Apps API identifies the container template as versioned and states that changes to it create a new revision.

Question 2

An organization has three Container Apps that need to share a common networking boundary and logging infrastructure.

What should you create?

A. A separate revision for each application.

B. A single Container Apps environment containing the three applications.

C. A single container image containing all three applications.

D. A separate Azure Kubernetes Service cluster for each application.

Answer: B

Explanation

A Container Apps environment provides a secure boundary around a group of Container Apps. Applications within the same environment can share environment-level capabilities such as networking and logging.

Question 3

You need to gradually introduce a new version of an API. Initially, 95% of requests should go to the existing revision and 5% should go to the new revision.

Which configuration should you use?

A. Single revision mode with an environment variable.

B. A new Container Apps environment.

C. Multiple revision mode with traffic splitting.

D. A second container inside the same revision.

Answer: C

Explanation

Multiple revision mode allows multiple revisions to remain active simultaneously and supports percentage-based traffic splitting. This makes it appropriate for gradual or canary deployments.

Question 4

A Container App is currently configured in single revision mode. A developer deploys a new revision, but the new revision fails its readiness checks.

What is the expected behavior?

A. The existing healthy revision can continue serving traffic while the new revision fails to become ready.

B. All revisions are immediately deactivated.

C. The environment is automatically deleted.

D. Traffic is automatically divided equally between the failed and healthy revisions.

Answer: A

Explanation

In single revision mode, Azure Container Apps maintains the existing revision while the new revision is being provisioned. The new revision must become ready before traffic is moved to it. This helps support zero-downtime deployments.

Question 5

You need to deploy a new revision for testing while keeping the current production revision at 100% traffic. The test revision should remain available so developers can test it directly.

Which approach is most appropriate?

A. Use single revision mode and delete the production revision.

B. Create a second Container Apps environment and duplicate the application.

C. Modify the existing production revision in place.

D. Use multiple revision mode and keep the test revision active with appropriate traffic allocation or a revision label.

Answer: D

Explanation

Multiple revision mode allows several revisions to remain active. A revision can also be associated with a label to provide direct access to a particular revision. This is useful for staging and testing scenarios without immediately shifting production traffic.

Question 6

A developer changes an application’s revision mode from Single to Multiple.

Does changing the revision mode itself create a new revision?

A. Yes. Every configuration change creates a revision.

B. Yes, but only if traffic splitting is also configured.

C. No. Revision mode is an application-scope configuration.

D. No, because revision mode is stored in the container image.

Answer: C

Explanation

Revision mode is an application-scope configuration setting. Changing the revision mode does not itself create a new revision. Azure’s current API documentation identifies activeRevisionsMode as part of the non-versioned Container App configuration.

Question 7

An application has two active revisions configured with traffic weights of 70% and 20%.

What is wrong with this configuration?

A. Traffic splitting can only be 50/50.

B. Traffic weights must total 100%.

C. Multiple revision mode only supports two revisions.

D. Traffic splitting requires three revisions.

Answer: B

Explanation

Traffic weights define the percentage of incoming traffic routed to each revision. The combined weights must equal 100%. A 70% + 20% configuration accounts for only 90% of traffic.

Question 8

An AI inference API stores an Azure OpenAI API key in its container image.

What is the best improvement?

A. Move the key into a Dockerfile argument.

B. Put the key into the container image as an encrypted text file.

C. Store the key in a Container Apps secret or an appropriate external secret-management service such as Azure Key Vault.

D. Put the key directly into the application’s source code.

Answer: C

Explanation

Secrets such as API keys and passwords should not be embedded in source code or container images. Container Apps supports secrets that can be referenced by environment variables, while Azure Key Vault provides centralized secret management for more advanced scenarios. The Container Apps API supports secretRef for connecting environment variables to Container App secrets.

Question 9

You are implementing a blue-green deployment. Revision 1 is currently serving production traffic. Revision 2 contains a new version that has been fully tested.

What should you do to switch production to Revision 2 while retaining the ability to quickly roll back?

A. Delete Revision 1 immediately.

B. Update Revision 1 so it contains Revision 2’s code.

C. Create a new Container Apps environment and redirect DNS.

D. Shift production traffic from Revision 1 to Revision 2 while keeping Revision 1 available.

Answer: D

Explanation

Revisions are immutable versions of an application. A blue-green deployment can maintain the existing revision while the new revision is validated. Production traffic can then be shifted to the new revision. Keeping the previous revision available provides a straightforward rollback target if problems occur.

Question 10

You have an application running in multiple revision mode:

Revision A → 80%
Revision B → 20%

You change the container image used by Revision B.

What should you expect?

A. Revision B is modified in place while retaining its existing revision identity.

B. The Container Apps environment is recreated.

C. A new revision is created containing the changed container image.

D. Revision A is automatically deleted.

Answer: C

Explanation

The container image is part of the revision’s versioned template. Changing it creates a new revision rather than modifying the existing immutable revision. The new revision can then be activated and assigned traffic according to the application’s revision configuration.

Final Exam Takeaway

The easiest way to reason about Azure Container Apps deployment questions is to think in terms of layers:

CONTAINER APPS ENVIRONMENT
        │
        │  Shared hosting/networking boundary
        ▼
CONTAINER APP
        │
        │  Application configuration
        ▼
REVISION
        │
        │  Immutable version
        ▼
CONTAINER IMAGE + TEMPLATE + SCALE CONFIGURATION

Then ask:

Does the question involve the hosting boundary?
→ Think Container Apps environment.

Does it involve the application itself?
→ Think Container App configuration.

Does it change the versioned application template?
→ Think new revision.

Does it require multiple versions to run simultaneously?
→ Think multiple revision mode.

Does it require controlled percentages of traffic?
→ Think traffic splitting.

Does it require a gradual rollout?
→ Think canary deployment.

Does it require switching between old and new versions?
→ Think blue-green deployment.

Does it require returning to a known-good version?
→ Think previous revision and rollback.

Mastering those distinctions will cover a substantial portion of the scenario-based questions you are likely to encounter around deploying applications to Azure Container Apps for AI-200.

Go to the AI-200 Exam Prep Hub main page