Containers Exam Tips

AZ-104 Exam Tips: Azure Containers#

---

Container Fundamentals#

Understand the container workflow end-to-end:

1. Write a Dockerfile
2. Build a container image
3. Push image to a container registry (e.g. Azure Container Registry)
4. Run image on a container host (e.g. Docker, ACI, Container Apps, AKS)

• A container image is the template for deploying an application
• Azure Container Registry (ACR) is Azure's private image registry
• Containers are stateless by default — use volumes or Azure Files for persistence

---

Azure Container Instances (ACI)#

What it is#

• PaaS Docker-like container runtime
• No underlying VM or cluster management needed
• Best for: simple jobs, dev/test, CI pipelines, batch tasks

Container Groups#

• The unit of deployment in ACI
• One or more containers sharing:
  • Lifecycle (start/stop together)
  • Local networking (communicate via localhost)
  • Storage (Azure Files mount)
• Separate container groups are independently isolated

Critical exam limitation — no scaling#

ACI cannot scale after deployment.

• Cannot add or remove containers from a group
• Cannot increase CPU or memory while running
• Must stop and redeploy to resize
• Use IaC (ARM templates or Bicep) to simplify redeployment

Networking#

• Public: requires an explicitly exposed port; gets public IP + FQDN
• Private: deployed into a VNet subnet; no public IP

---

Azure Container Apps#

What it is#

• Serverless container platform built on an abstracted Kubernetes cluster
• Sits between ACI (no orchestration) and AKS (full K8s)
• Best for: microservices architectures, event-driven apps

Key differentiators from App Service and ACI#

Container App Environment#

• Isolation boundary for Container Apps
• Apps in same environment share VNet, logs, and Dapr config
• Use custom VNet for private connectivity and on-prem access

Replicas and Scaling#

• Replicas = running instances of a Container App
• Scale to zero = no traffic → zero replicas → no cost
• Scaling triggers: HTTP concurrent requests, Azure Queue length, custom (KEDA)

Revisions#

• Each deployment update creates a new revision
• Multiple revisions can be active simultaneously
• Traffic can be split between revisions for canary/blue-green deployments
• Old revisions can be reactivated for rollback

Ingress#

• Controls how external traffic reaches the app
• Options: disabled, public, environment-only, VNet-only
• Always requires a target port and optionally IP restrictions

---

Choosing the Right Container Service#

---

Common Exam Traps#

• ACI cannot scale after deployment — this is a very common exam scenario question
• Container App scale-to-zero means cost is zero when idle; App Service always has baseline cost
• VNet integration in Container Apps requires custom VNet on the Environment, not per-app
• Container App revisions ≠ deployment slots — they function similarly but are Kubernetes-revision-based
• ACI container groups share local networking (localhost), not just the same physical host

---

Quick Revision Cheat Sheet#

Dockerfile → image → registry → host

ACI:
  Container group = unit of deployment
  Group shares: lifecycle + network + Azure Files
  Public: exposed port required
  Private: VNet subnet
  NO scaling after deploy → redeploy (use IaC)

Container Apps:
  Serverless Kubernetes (abstracted)
  Environment = isolation boundary
  Scale to zero ✅ (true serverless)
  Replicas = running instances
  Revisions = versioned deployments
  Traffic splitting between revisions
  Ingress: public / env-only / VNet-only / disabled
  Best for microservices

Choose ACI for simple; Container Apps for microservices; AKS for full control

Reference Documentation#

• Azure Container Instances overview
• Container groups in ACI
• Azure Container Apps overview
• Container Apps scaling
• Container Apps revisions
• Comparing container options in Azure
• Azure Container Registry