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

Memory Trick

secretref: = value never in YAML/history/logs. Always correct for 'secure injection'. Revision = safety net. --yaml = absolute truth, ignores CLI flags.

Exam Gotcha

--yaml ignores ALL other CLI flags. secretref: never stores secret in plain text. Multiple revisions need 'multiple' revision mode for traffic splitting.

Module

Scale Container Apps with KEDA and Manage Revisions

units
Implement Azure Container Apps — Microsoft Learn
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.

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

Module 1
ACR & App Service
20–25%
Module 3
Azure Kubernetes Service
20–25%

Frequently Asked Questions

What percentage of the AI-200 exam covers Develop Containerized Solutions on Azure? +

Domain 1 (Develop Containerized Solutions on Azure) accounts for 20–25% of the AI-200 exam. Deploy and Manage Apps on Azure Container Apps topics like Azure Container Apps and KEDA are actively tested. Study all official skill objectives listed in the module header above.

Is Azure Container Apps on the AI-200 exam? +

Yes. Deploy and Manage Apps on Azure Container Apps is part of Domain 1 in the official AI-200 skill outline, weighted at 20–25%. The key services tested are Azure Container Apps, KEDA, AKS. Review the code examples and exam tips in this module for targeted prep.

How do I practice Azure Container Apps hands-on? +

The best approach is to create a free Azure account and follow the code examples in this module step-by-step. The official Microsoft Learn sandbox for Course AI-200T00-A also provides free lab environments for Azure Container Apps and related services.

←
Previous
ACR & App Service
Next
Azure Kubernetes Service
→
Take Quiz Next →