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

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

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.