Module 2 of 9 20–25% 3 sub-modules · 27 units Domain 1: Develop Containerized Solutions on Azure

Deploy and Manage Apps on Azure Container Apps

AI-200 Exam Objective: Module 2 covers Deploy and Manage Apps on Azure Container Apps in Domain 1 (Develop Containerized Solutions on Azure), weighted 20–25% of Microsoft Exam AI-200. Core competencies tested include Azure Container Apps, KEDA, AKS, CLI/SDK command syntax, production scaling trade-offs, and fault-tolerant architecture.

Deploy applications to Azure Container Apps with environment configuration and revision management. Implement event-driven scaling with KEDA. Deploy and manage apps on AKS using manifest files.

Azure Container AppsKEDAAKS

Last updated: · Aligned with Course AI-200T00-A

Module

Deploy Containers to Azure Container Apps

units
Unit 1

Introduction

2 min

Azure Container Apps (ACA) is a serverless container platform built on Kubernetes — but you never touch kubectl. It handles scaling (including scale-to-zero), ingress, revision-based deployments, and built-in observability. Perfect for AI microservices: deploy a Python FastAPI embeddings service with zero Kubernetes expertise.

Exam Tip

Exam pillars: 1) Environments (shared networking) 2) Revisions (versioned deployments) 3) Secrets + secretref: pattern 4) Registry auth (managed identity) 5) Logs/replica diagnosis flow.
Unit 2

Container Apps Environments

5 min

1. What an Environment Provides

  1. Shared VNet boundary — apps in the same environment share a virtual network and can reach each other via internal DNS.
  2. Shared Log Analytics workspace — console and system logs from all apps in one environment flow to one workspace.
  3. Isolation boundary — apps in different environments are fully isolated (separate VNet, separate logs).

Real-life: group AI API + background worker in one environment. Put dev and prod in separate environments.

2. Ingress: External vs Internal

  1. External ingress (--ingress external) — public FQDN, accessible from the internet. Use for user-facing AI APIs.
  2. Internal ingress (--ingress internal) — only reachable within the environment via appname.internal.domainname. Use for backend microservices.

Exam Tip

Internal ingress = service-to-service only. External = internet-accessible. Match ingress type to who needs to reach the service.
az containerapp env create --name aca-env-prod --resource-group rg-ai --location eastus
az containerapp env show --name aca-env-prod --resource-group rg-ai
Unit 3

Deploy a Container App

8 min

1. Fast Deploy: az containerapp up

Creates environment and app in one command. Use for prototypes or first deployments.

az containerapp up --name ai-api --resource-group rg-ai \\
  --environment aca-env-prod \\
  --image mcr.microsoft.com/k8se/quickstart:latest \\
  --target-port 80 --ingress external \\
  --query properties.configuration.ingress.fqdn

2. Explicit Deploy: az containerapp create + update

az containerapp create --name ai-api --resource-group rg-ai \\
  --environment aca-env-prod \\
  --image myregistry.azurecr.io/ai-api:v1 \\
  --ingress external --target-port 8000

az containerapp update --name ai-api --resource-group rg-ai \\
  --image myregistry.azurecr.io/ai-api:v2

Each update with a new image creates a new revision — your safety net for rollbacks.

3. YAML-Based Deployment (Configuration as Code)

az containerapp create -n ai-api -g rg-ai --environment aca-env-prod --yaml ./app.yml
az containerapp update -n ai-api -g rg-ai --yaml ./app.yml

Exam Tip

--yaml ignores ALL other CLI flags. YAML becomes the single source of truth. Best answer for "repeatable, reviewable, git-tracked deployments".
Unit 4

Configure Runtime: Env Vars and Secrets

7 min

1. Non-Sensitive Environment Variables

az containerapp create -n ai-api -g rg-ai \\
  --env-vars LOG_LEVEL=info FEATURE_EMBEDDINGS=true ...
az containerapp update -n ai-api -g rg-ai --set-env-vars LOG_LEVEL=debug

--set-env-vars adds/updates without removing existing vars. Use --replace-env-vars to replace all.

2. Secrets + secretref: Pattern (Exam-Critical)

  1. Store as a Container Apps secret:
    az containerapp secret set -n ai-api -g rg-ai \\
      --secrets embeddings-api-key="sk-abc123"
  2. Reference the secret as an env var using secretref::
    az containerapp update -n ai-api -g rg-ai \\
      --set-env-vars EMBEDDINGS_API_KEY=secretref:embeddings-api-key
  3. In YAML:
    env:
    - name: EMBEDDINGS_API_KEY
      secretRef: embeddings-api-key

Common Gotcha

secretref: maps a secret to an env var — the actual value is never in YAML, CLI history, or logs. This is THE secure pattern. The exam tests this explicitly.
Unit 5

Configure Private Registry Authentication

6 min

1. Managed Identity for ACR (Recommended)

az containerapp registry set -n ai-api -g rg-ai \\
  --server myregistry.azurecr.io --identity system

Assign managed identity + AcrPull role on the registry. Zero stored credentials.

2. Username/Password (Fallback)

az containerapp registry set -n ai-api -g rg-ai \\
  --server myregistry.azurecr.io --username MyUser --password MyPassword

3. Verify Registry Config

az containerapp registry list -n ai-api -g rg-ai
az containerapp registry show -n ai-api -g rg-ai --server myregistry.azurecr.io
Unit 6

Verify Deployments: Logs, Revisions, Replicas

7 min

KEDA Event-Driven Scaling: source triggers → scale 0→N replicas

Event SourceHTTP / QueueEvent GridKEDAScale 0 → Nbased on loadContainer AppsReplica 1Replica 2Replica NRevision: rev-2 (traffic: 100%)Managed Environment • Ingress Enabled

Diagnosis Order (Exam Critical)

  1. Container logs — app stdout/stderr
    az containerapp logs show -n ai-api -g rg-ai --follow --tail 50
    az containerapp logs show -n ai-api -g rg-ai --type system
  2. Revision status — check health of each version
    az containerapp revision list -n ai-api -g rg-ai -o table
  3. Replica count — check if instances are running
    az containerapp replica list -n ai-api -g rg-ai --revision myapp--xyz123

Exam Tip

Diagnosis sequence: logs first → revision status → replica count. This is the expected troubleshooting order in exam scenarios.

Container Apps Master Cheatsheet

Fast deployaz containerapp up
Config as code--yaml ./app.yml (ignores all other flags)
Inject secret safelysecretref:secret-name in env vars
Registry auth (best)Managed identity + AcrPull
Internal service URLhttp://appname.internal.domainname
View app logsaz containerapp logs show --follow
List revisionsaz containerapp revision list
RollbackDeactivate bad revision, activate previous
Scale to zeroSet minReplicas=0 + KEDA trigger
Canary deployMultiple revision mode + traffic split %
Unit 7

Exercise — Deploy Backend API

30 min
  1. Create environment and deploy from ACR using managed identity
  2. Configure secrets as env var references using secretref:
  3. Update image (creates new revision) and verify with revision list
  4. Trigger logs and check replica status
  5. Deactivate a bad revision and confirm traffic routes to healthy one
Unit 8

Module Assessment

5 min
  1. Q: Shared networking + logging for multiple apps? A: A Container Apps Environment
  2. Q: AI API key must not appear in YAML. How to inject? A: Store as Container Apps secret, reference with secretref:
  3. Q: App fails after image update. First diagnostic step? A: az containerapp logs show
  4. Q: Best approach for git-tracked, repeatable deployments? A: YAML deployment with --yaml flag
Unit 9

Summary

2 min

Environments scope networking and logging. Deploy with up (fast), create (precise), or --yaml (repeatable). Use secretref: for secure secret injection. Use managed identity + AcrPull for registry auth. Diagnose: logs → revision → replicas.

Memory Tricks

Revision = immutable snapshot of your app config. Each update creates one. Use them for rollbacks and canary deployments.

secretref: = zero exposure. The value never appears in logs, YAML, or shell history. This is THE exam answer for "secure secret injection".

Module Cheatsheet

Azure Container Apps

20–25% PDF

Key Facts

  • secretref: — Maps Container Apps secret to env var — THE secure injection pattern
  • --yaml flag — Config-as-code — IGNORES all other CLI flags
  • Revision — Immutable snapshot on each update — rollback + canary traffic split
  • External ingress — Public FQDN — internet accessible
  • Internal ingress — Same-environment only via internal DNS
  • Scale to zero — minReplicas=0 + KEDA trigger (HTTP, queue, cron)
  • Registry auth (best) — Managed Identity + AcrPull role
  • Diagnose order — logs → revision list → replica list

Commands & Patterns

az containerapp up --name ai-api -g rg   --environment myenv --image myacr.azurecr.io/api:v1   --target-port 8000 --ingress external
az containerapp secret set -n ai-api -g rg   --secrets openai-key="sk-abc123"
az containerapp update -n ai-api -g rg   --set-env-vars OPENAI_KEY=secretref:openai-key
az containerapp logs show -n ai-api -g rg --follow
az containerapp revision list -n ai-api -g rg -o table
Module

Scale Container Apps with KEDA and Manage Revisions

units
Unit 1

KEDA Event-Driven Autoscaling

3 min

KEDA (Kubernetes Event-Driven Autoscaling) is built into Container Apps. It scales replicas based on external event sources — Service Bus queue depth, HTTP requests, custom metrics — including scaling to zero when idle. Perfect for bursty AI workloads.

Exam Tip

KEDA exam pillars: 1) Scale to zero (min=0) on Service Bus / queue triggers 2) HTTP scaling: concurrent requests per replica 3) Scale rule in YAML: type, metadata, auth 4) Revision mode: single vs multiple for traffic splitting 5) Traffic weight per revision for canary deployments.
Unit 2

KEDA Scale Rules

9 min

Service Bus Queue Depth Scaling

az containerapp update \
  --name ai-worker \
  --resource-group rg \
  --min-replicas 0 \
  --max-replicas 10 \
  --scale-rule-name sb-queue-rule \
  --scale-rule-type azure-servicebus \
  --scale-rule-metadata queueName=embed-queue \
    messageCount=5 \
    namespace=mynamespace \
  --scale-rule-auth triggerAuth=sb-auth-ref

Exam Tip

messageCount=5 means one new replica per 5 messages. With 50 messages → 10 replicas. min-replicas=0 = scale to zero when queue empty (cost savings).

HTTP Concurrent Request Scaling

az containerapp update \
  --name ai-api \
  --resource-group rg \
  --min-replicas 1 \
  --max-replicas 20 \
  --scale-rule-name http-rule \
  --scale-rule-type http \
  --scale-rule-metadata concurrentRequests=10

Common Gotcha

HTTP trigger cannot scale to zero (min=1) — someone must receive the first request. Service Bus / queue triggers CAN scale to zero since messages queue up externally.
Unit 3

Revisions and Traffic Splitting

8 min

Canary Deployment with Traffic Weights

# Enable multiple revision mode
az containerapp revision set-mode \
  --name ai-api --resource-group rg \
  --mode multiple

# Deploy new version (creates new revision)
az containerapp update \
  --name ai-api --resource-group rg \
  --image myregistry.azurecr.io/ai-api:v2

# Split traffic: 90% stable, 10% canary
az containerapp ingress traffic set \
  --name ai-api --resource-group rg \
  --revision-weight \
    ai-api--v1=90 \
    ai-api--v2=10

Exam Tip

Revision = immutable snapshot of your app. Single mode: only one active revision (blue/green). Multiple mode: many active revisions with traffic weights (canary). Rollback = shift 100% weight back to previous revision.
Unit 4

Dapr Sidecar Integration

6 min

Enable Dapr for Service-to-Service Calls

# Enable Dapr on container app
az containerapp update \
  --name ai-api --resource-group rg \
  --dapr-enabled true \
  --dapr-app-id ai-api \
  --dapr-app-port 8000

# Call another service via Dapr sidecar (no service discovery needed)
import httpx
# Dapr handles retries, tracing, mTLS automatically
response = httpx.post(
    "http://localhost:3500/v1.0/invoke/embedding-svc/method/embed",
    json={"text": content}
)

Exam Tip

Dapr sidecar handles service discovery, retries, mTLS, and distributed tracing. App calls localhost:3500 (Dapr port) — Dapr routes to the target service by app-id. No hardcoded URLs.
Unit 5

Summary

2 min

KEDA in Container Apps: scale to zero on queue triggers, HTTP scaling on concurrent requests, custom metrics. Revisions: immutable snapshots, single (blue/green) vs multiple (canary with traffic weights). Traffic splitting via --revision-weight. Dapr sidecar: service-to-service calls via localhost:3500, handles retries, mTLS, tracing automatically. Min-replicas=0 only works with non-HTTP triggers.

Exam Scenario Walkthrough

Zero-Idle Cost AI Inference API with KEDA Scaling & Revision Traffic Splitting

An asynchronous document analysis service processes erratic batches of PDFs. During business hours, up to 10,000 documents arrive on Azure Service Bus; at night, zero documents arrive. Blue/Green canary rollouts must verify new prompt pipelines on 10% of traffic before full cutover.

Scenario Constraints & Requirements:
  • Scale down to zero replicas during quiet hours to incur zero compute charges.
  • Scale based on Azure Service Bus Queue message backlog (KEDA).
  • Direct 90% of requests to production revision and 10% to staging revision without deploying an API Gateway.
Architecture Solution:

Deploy on Azure Container Apps with `minReplicas: 0`, configure a KEDA Azure Service Bus scaler using Managed Identity, and utilize native Revision Traffic weights.

1. Configure Container App with Multiple Revisions Mode
az containerapp revision set-mode \
  --name pdf-extractor \
  --resource-group rg-ai \
  --mode multiple
Key Rule: Multiple revision mode allows simultaneous running revisions for canary splitting and zero-downtime testing.
2. Attach KEDA Service Bus Scaler
az containerapp update \
  --name pdf-extractor \
  --resource-group rg-ai \
  --min-replicas 0 \
  --max-replicas 30 \
  --scale-rule-name sb-backlog \
  --scale-rule-type azure-servicebus \
  --scale-rule-metadata queueName=incoming-docs messageCount=20
Key Rule: The scaler spawns 1 replica for every 20 messages waiting in the queue, scaling to 0 when queue is empty.
3. Shift Canary Traffic Weights
az containerapp ingress traffic set \
  --name pdf-extractor \
  --resource-group rg-ai \
  --revision-weight pdf-extractor--v1=90 pdf-extractor--v2=10
Key Rule: Traffic percentages must sum to exactly 100. Native Envoy proxy routes requests without external load balancers.
Key Exam Takeaway

Whenever an AI-200 question mentions "scale to zero", "KEDA event triggers", and "built-in canary traffic splitting" without Kubernetes cluster maintenance, Container Apps is the correct choice.

Architectural Comparison

Container Hosting: Container Apps vs AKS vs App Service

Crucial architectural comparison frequently tested in Domain 1 scenarios.

FeatureContainer AppsAKSApp Service for Containers
Scale to ZeroNative (minReplicas = 0)Requires KEDA + cluster configNo (App Service plan always runs)
Pricing ModelPer vCPU-second consumedPer node VM hourPer App Service Plan tier
Kubernetes Control PlaneHidden / ServerlessFull kubectl & API accessNone
Dapr SupportNative 1-click integrationSelf-installed / managedNone
GPU Inference SupportSelected serverless SKUsComprehensive GPU node pools (NC/ND series)None
Custom Ingress / CNIManaged Envoy onlyCustom CNI / Ingress controllersBuilt-in reverse proxy
Exam Traps to Avoid

Common Mistakes & Gotchas in Azure Container Apps

✕ The Trap: Confusing single revision mode with multiple revision mode during canary deployments.
The Reality: In single revision mode, deploying a new image immediately terminates the previous version 100%.
✓ Correct Answer Rule: Must run `az containerapp revision set-mode --mode multiple` before configuring traffic weights.
✕ The Trap: Using connection strings inside KEDA scale rules instead of Managed Identity auth.
The Reality: Hardcoded secrets violate security questions. KEDA supports Azure identity triggers via SecretRef and Managed Identity.
✓ Correct Answer Rule: Reference secret from Key Vault or configure Managed Identity client ID on the Container Apps environment.
✕ The Trap: Expecting background worker daemon tasks to stay running with minReplicas=0 without active scale triggers.
The Reality: If minReplicas=0 and no HTTP or queue scaler is triggered, Container Apps will terminate the container immediately.
✓ Correct Answer Rule: Set `minReplicas: 1` for persistent daemon listeners or use Azure Container Apps Jobs for scheduled cron tasks.

Recommended Next Steps for Azure Container Apps

Quick Quiz

5 questions — test your understanding before moving on

Technical Deep Dives & Official References

Hands-On Labs & Microsoft Architecture References

Master Azure Container Apps by reviewing our production benchmark labs, architecture decision guides, and primary Microsoft Learn documentation.

Finished reading this module? Mark it complete to track your progress.

Related Modules — Develop Containerized Solutions on Azure

Frequently Asked Questions — Azure Container Apps

How does Azure Container Apps scale to zero compared to AKS? +

Azure Container Apps is serverless and driven by KEDA. When there are no incoming HTTP requests or queued messages, replicas scale to 0 and you incur zero vCPU/memory compute costs. AKS always incurs costs for running VMs in node pools.

How do you configure traffic splitting between revisions for blue/green or canary testing? +

Enable multiple revision mode in Container Apps and run `az containerapp ingress traffic set --revision-weight latest=20 previous=80`. This routes a specific percentage of live traffic to the new revision while preserving the stable build.

What built-in KEDA scalers are supported natively in Container Apps for AI solutions? +

Native scalers include HTTP concurrent requests per replica (`concurrentRequests`), Azure Service Bus queue depth (`messageCount`), Azure Event Hubs consumer lag, Azure Storage Queues, and custom KEDA scalar definitions.

How does Dapr integration simplify microservice communication in Container Apps? +

Container Apps provides Dapr as a managed sidecar. Your containers communicate over HTTP/gRPC locally (`localhost:3500`) to access pub/sub messaging, secret stores, state management, and distributed tracing without embedding cloud-specific SDKs in application code.

How should sensitive secrets be injected into container app environments? +

Store secrets in Azure Key Vault and reference them in Container Apps using a User-Assigned Managed Identity. The container app retrieves the secret at runtime without hardcoding values in environment variables or deployment manifests.