ExamFinch.com My Study

Study guide

2.1 Azure Container Apps: Environments, Config & Revisions

Practice this exam

Exam AI-200: Developing AI Cloud Solutions on Azure Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Audience Profile & Study Path

2 Chapter 1: Container Registry & App Service Hosting

1.1 ACR: Build, Store, Version & Manage Images 1.2 ACR Tasks: Build & Run Images 1.3 Deploy Containers to Azure App Service

3 Chapter 2: Azure Container Apps & KEDA Scaling

2.1 Azure Container Apps: Environments, Config & Revisions 2.2 KEDA Event-Driven Scaling in Container Apps

4 Chapter 3: AKS Manifests & Container Troubleshooting

3.1 Deploy & Manage Apps on AKS with Manifests 3.2 Monitor & Troubleshoot AKS and Container Apps

5 Chapter 4: Cosmos DB for NoSQL Fundamentals

4.1 Cosmos DB for NoSQL: SDK Connect & Queries 4.2 Optimize RUs: Indexing Policies & Consistency Levels

6 Chapter 5: Cosmos DB Vectors & Change Feed

5.1 Embeddings & Vector Similarity Search in Cosmos DB 5.2 Change Feed Processor for New/Updated Items

7 Chapter 6: Azure PostgreSQL Foundations for AI

6.1 Azure Database for PostgreSQL: Connect & Query with SDKs 6.2 Schema Design, Data Types & Indexing Strategies 6.3 pgvector Indexing: Latency & Compute Overhead

8 Chapter 7: PostgreSQL Vector Workloads & RAG

7.1 Configure Compute, Memory & Storage for Vector Workloads 7.2 Vector Search, Semantic Retrieval & RAG with Metadata Filters 7.3 Connection Optimization for Throughput & Latency

9 Chapter 8: Azure Managed Redis for AI Solutions

8.1 Azure Managed Redis: Caching, Expiration & Invalidation 8.2 Redis Vector Indexing for Similarity Search

10 Chapter 9: Service Bus & Event Grid for AI Pipelines

9.1 Service Bus Queues & Message Processing 9.2 Topics, Subscriptions & Dead-Letter Queues 9.3 Event Grid: Custom Events & Filters 9.4 Event Grid Retries & Event-Driven Workflows

11 Chapter 10: Azure Functions for Serverless AI Back Ends

10.1 Azure Functions: Triggers & Bindings 10.2 Build Serverless APIs with Functions 10.3 Configure & Deploy Function Apps

12 Chapter 11: Key Vault & App Configuration

11.1 Azure Key Vault: Secret Storage & Retrieval 11.2 Key Vault Secret Rotation Patterns 11.3 Azure App Configuration for App Settings

13 Chapter 12: OpenTelemetry & KQL Observability

12.1 Distributed Tracing with OpenTelemetry SDKs 12.2 Correlating Traces into Azure Monitoring 12.3 Write KQL Queries to Analyze Logs 12.4 KQL for Metrics & Troubleshooting Scenarios

2.1 Azure Container Apps: Environments, Config & Revisions

Key Takeaways Explain This Topic AI

An Azure Container Apps environment is a secure boundary that hosts one or more apps and shares networking, logging, and Dapr settings.

Container Apps revisions are immutable snapshots of an app’s container image and configuration; new deployments create new revisions rather than mutating the old one in place.

Traffic splitting lets you route percentages of ingress traffic across active revisions for blue-green or canary-style rollouts.

Secrets are stored at the app level and referenced by environment variables or volume mounts; never bake credentials into the container image.

Ingress can be external (public) or internal (environment-only); configure target port, transport (HTTP/HTTP2/TCP), and optional custom domains/TLS at the app ingress layer.

Last updated: July 2026

Why Container Apps matter on AI-200

Exam AI-200 measures your ability to develop containerized solutions on Azure (Domain 1, 20–25% ). Within that domain, Azure Container Apps is the primary product for deploying containerized APIs and background workers without managing Kubernetes control-plane day-2 work yourself. You still think in containers, revisions, ingress, and scale—but Azure owns the orchestrator. That middle ground is exactly what many AI backend workloads need: package a Python or .NET inference/API container, push it to Azure Container Registry (ACR) , deploy to Container Apps, then iterate with revisions and traffic splits.

Do not confuse Container Apps with App Service for containers (simpler PaaS web hosting) or AKS (full Kubernetes cluster control). On exam stems, pick Container Apps when the scenario wants revision traffic splitting , KEDA event-driven scale (next section), scale to zero , and environment-scoped networking—without asking you to author Deployments/Services YAML for a whole cluster.

Container Apps environments

An environment is the foundational unit. Apps you create live inside an environment. The environment provides:

  • A secure boundary for apps that need to talk to each other privately
  • Shared Log Analytics (or other observability wiring) for consolidated logs

Optional VNet integration so apps can reach private Azure resources (databases, Service Bus, Key Vault private endpoints)

Shared Dapr configuration when you enable the Dapr extension for sidecar-style building blocks

Concept What it is Exam cue

Environment Boundary hosting one or more Container Apps Shared networking/logging; apps in same env can use internal ingress

  • Container App Deployable unit: image + config + ingress + scale One app ≈ one microservice or worker
  • Revision Immutable snapshot of image + configuration New deploy → new revision; old revision can keep traffic
  • Replica Running instance of a revision Scale rules change replica count

When you create an environment, choose the region carefully: apps in that environment run in that region. For AI backends that call regional data services (Cosmos DB, PostgreSQL, Managed Redis), co-locate the environment with those dependencies to reduce latency.

Consumption vs dedicated (workload profiles): Modern Container Apps environments often use workload profiles . Consumption profile is the serverless-style option many AI-200 labs use; dedicated profiles reserve compute for steadier workloads. Exam questions usually care more about behavior (revisions, ingress, scale) than SKU shopping—but know that environments define how compute is provided to the apps inside them.

Deploying an application

A typical deploy path for AI-200-style solutions:

Build a container image (locally or with ACR Tasks ).

Push the image to ACR with a tag (prefer immutable tags or digests for production).

Create or update a Container App that pulls from ACR (managed identity or registry credentials).

Set environment variables , secrets , ingress , and scale settings.

Activate the new revision and optionally split traffic .

You can deploy with Azure portal, Azure CLI ( az containerapp ), Bicep/ARM/Terraform, or GitHub Actions. The exam cares that you understand the resulting model : the app points at an image; configuration is separate from the image; each meaningful change creates a revision.

Configuration: environment variables and secrets

Treat configuration as first-class , not something stuffed into the Dockerfile.

Environment variables — non-secret settings: feature flags names, connection mode , model name, log level, upstream URI hosts that are not credentials.

Secrets — connection strings, API keys, client secrets. Define secrets on the Container App, then reference them from env vars (for example, an env var whose value is a secret reference) or mount them as files.

  • Approach Use when Risk if misused
  • Plain env var Non-sensitive config Leaks if you put passwords here
  • Secret + env reference Runtime needs CONNECTION_STRING Secret still visible to the process—limit RBAC
  • Secret volume mount Apps that read files for credentials Misconfigured mount paths
  • Key Vault reference patterns Central secret store / rotation Still wire ACA identity + access policy/RBAC

Exam discipline: If a stem says secrets appeared in the image layers or in source control, the fix is move to Container Apps secrets (and preferably Key Vault) , not “make the image private only.” Private ACR helps supply-chain exposure; it does not replace secret management.

Ingress: exposing the app

Ingress controls how traffic reaches your containers.

  • Ingress mode Who can call it Typical use
  • External Public internet (plus your auth controls) Public HTTP API, webhook endpoint
  • Internal Only within the Container Apps environment Private microservice called by other apps
  • Disabled No HTTP ingress Queue/Event Hub workers scaled by KEDA

Key ingress settings you should recognize:

  • Target port — container listening port (for example, 8080)
  • Transport — HTTP, HTTP/2, or TCP depending on the protocol
  • Insecure connections allowed — whether HTTP (non-TLS) is permitted to the app’s ingress endpoint
  • Custom domains and certificates — bind a hostname and TLS for production APIs

Internal ingress is a classic pattern for an AI pipeline: a public “gateway” app with external ingress calls an internal “embedding worker” or “ranker” app. That keeps private services off the public internet while staying inside one environment.

Revisions: immutable deployment units

A revision captures the container image and the configuration that was active when the revision was created. Revisions are immutable : you do not “edit revision 3.” You create revision 4 with the new image or config.

Why that matters operationally:

You can roll forward by activating a new revision.

You can roll back by shifting traffic to a previous healthy revision.

You can run multiple revisions at once with different traffic weights.

Revision modes (terminology you may see):

Single revision mode — primarily one active revision; simpler mental model.

Multiple revision mode — intentionally keep more than one revision serving traffic (canary/blue-green).

Labels and revision suffixes help humans and automation identify which build is live. For exam scenarios, map “deploy a new version without dropping the old one yet” → create a new revision and split traffic , not “overwrite the only running container in place.”

Traffic splitting

Traffic splitting assigns percentages of ingress traffic to specific revisions. Example:

  • Revision Image tag Traffic weight Purpose
  • api--00012 api:1.4.0 90% Stable production
  • api--00013 api:1.5.0-rc 10% Canary

After metrics look healthy, shift to 50/50, then 100% on the new revision. If error rates spike, set the canary weight to 0% and keep the stable revision at 100%.

Traffic splitting is ingress-centric . Background workers with ingress disabled do not “split HTTP traffic” the same way; for those, you manage which revision is active and how many replicas KEDA runs.

Putting it together: a deploy scenario

Priya ships a Python FastAPI service that wraps an Azure OpenAI call. She pushes cooldemo.azurecr.io/ranker:1.2.0 to ACR, creates Container App ranker in environment ai-shared-env , sets external ingress on port 8080, stores the Azure OpenAI key as a secret , and references it from an environment variable. She deploys 1.3.0 as a new revision and routes 20% of traffic to it. Latency and 5xx rates stay flat, so she moves to 100% . That story hits every major ACA control: environment, secret/env config, ingress, revision, traffic split.

  • Configuration checklist before you leave this section
  • Environment chosen and networking aligned with private dependencies
  • Image comes from ACR with pull auth via identity or registry credentials
  • Secrets not baked into the image
  • Ingress mode matches exposure needs (external / internal / none)
  • Revision strategy decided (single vs multiple) and traffic weights understood
  • Ready to attach scale rules (covered in §2.2 with KEDA)

If you can explain how an environment bounds apps, how a revision differs from a replica, and how traffic splitting enables canary releases, you are ready for Container Apps configuration questions on AI-200.