2.1 Azure Container Apps: Environments, Config & Revisions

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

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:

1. Build a container image (locally or with ACR Tasks).
2. Push the image to ACR with a tag (prefer immutable tags or digests for production).
3. Create or update a Container App that pulls from ACR (managed identity or registry credentials).
4. Set environment variables, secrets, ingress, and scale settings.
5. 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.

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.

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:

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.