10.1 Containerized Application Delivery: ACR, AKS & Container Apps

10.1 Containerized Application Delivery: ACR, AKS & Container Apps

Containerization has fundamentally altered continuous delivery pipelines by packaging application code, runtime dependencies, and system libraries into portable, immutable artifacts. However, achieving enterprise-grade delivery in Microsoft Azure requires robust orchestration across the container lifecycle: optimizing build layers, automating registry security and patching, executing zero-downtime cluster rollouts, and configuring event-driven serverless container runtimes.

On the AZ-400 exam, candidates must demonstrate technical mastery across the container delivery lifecycle, configure Azure Container Registry (ACR) automated tasks and image signing, orchestrate Azure Kubernetes Service (AKS) deployments using native and pipeline-driven canary patterns, and manage Azure Container Apps (ACA) revisions and traffic splitting.

---

1. Container Delivery Lifecycle & Dockerfile Optimization

The container delivery lifecycle begins at the developer workstation or build agent and ends with running pods or container instances in Azure. A poorly constructed Dockerfile introduces security vulnerabilities, slows down CI/CD pipelines through bloated image layers, and increases network transfer latencies across deployment targets.

┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐       ┌─────────────────┐
│ Developer / CI  │       │ Azure Container │       │ Security & Trust│       │ Target Compute  │
│ Multi-Stage     │──────►│ Registry (ACR)  │──────►│ Notation/Cosign │──────►│ AKS / ACA / ACI │
│ Docker Build    │       │ Tasks & Geo-Rep │       │ Signature Check │       │ Zero-Downtime   │
└─────────────────┘       └─────────────────┘       └─────────────────┘       └─────────────────┘

Multi-Stage Builds

Traditional single-stage Dockerfiles include compilers, software development kits (SDKs), test runners, and intermediate build artifacts in the final container image. Multi-stage builds solve this problem by defining multiple FROM statements within a single Dockerfile. Each stage represents a discrete phase of the build pipeline, allowing engineers to selectively copy compiled binaries from an intermediate build stage into a clean, minimal runtime stage.

# Stage 1: Build & Compile
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build-env
WORKDIR /src
COPY src/*.csproj ./
RUN dotnet restore
COPY src/ ./
RUN dotnet publish -c Release -o /app/out --no-restore

# Stage 2: Final Lean Runtime
FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS runtime-env
WORKDIR /app
# Create an unprivileged non-root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
COPY --from=build-env --chown=appuser:appgroup /app/out ./
USER appuser
EXPOSE 8080
ENTRYPOINT ["dotnet", "PaymentService.dll"]

Minimal Base Images: Alpine vs. Distroless

Selecting an enterprise runtime base image requires balancing attack surface reduction against debugging and libc runtime requirements:

• Alpine Linux: Uses musl libc instead of glibc and the apk package manager, producing base images under 10 MB. However, engineers must be aware that musl libc can introduce performance differences in memory allocation (e.g., thread stack sizes) and binary incompatibilities with pre-compiled native C/C++ dependencies.
• Google Distroless: Strips the base image down to the absolute bare minimum: the application runtime and its essential glibc libraries. Distroless images contain no shell (/bin/sh, /bin/bash), no package manager (apk, apt), and no standard Unix utilities (ls, curl, wget). If an attacker manages to achieve remote code execution inside the container, they cannot spawn an interactive shell or download external malicious payloads, drastically limiting post-exploitation lateral movement.

Layer Caching & Build Optimization

Docker processes Dockerfile instructions sequentially, caching intermediate layers. If a layer changes, all subsequent layers must be rebuilt:

1. Order of Changes: Place frequently changing instructions (e.g., COPY . .) as late as possible. Place static instructions (e.g., installing base dependencies, copying project package descriptors like package.json or *.csproj, and running dependency restores) early.
2. Combine Commands: Combine related commands using && in a single RUN instruction and clean up package caches within the same layer (e.g., apt-get update && apt-get install -y --no-install-recommends libssl-dev && rm -rf /var/lib/apt/lists/*) to avoid storing cached installers in layer history.
3. Enforce Non-Root Execution: Always declare an explicit USER instruction with a non-root UID. By default, containers execute as root (UID 0), creating high privilege escalation risks if a container breakout vulnerability occurs.

---

2. Azure Container Registry (ACR) Enterprise Capabilities

Azure Container Registry (ACR) is a managed, OCI-compliant registry service hosted in Azure. For enterprise CI/CD and the AZ-400 exam, candidates must understand the differentiators between service tiers (Basic, Standard, and Premium) and master ACR Tasks, Geo-Replication, and Image Signing.

ACR Tasks: Automated Builds & Patching

ACR Tasks is a suite of container image build and management capabilities that automate image generation across both inner and outer loops:

1. Quick Tasks: Compile and push container images directly to ACR in the cloud without requiring a local Docker daemon:
   az acr build --registry myregistry --image payment:v1.0 .
2. Automated Git Commit Triggers: Automatically builds a new container image whenever source code is pushed to an Azure Repos Git repository or GitHub branch.
3. Base Image Update Triggers: One of the most critical enterprise patching mechanisms tested on AZ-400! In traditional setups, if an upstream base image (such as mcr.microsoft.com/dotnet/aspnet:8.0) receives a critical OS security patch, downstream application images remain vulnerable until a developer manually rebuilds them. When an ACR Task is configured with --base-image-trigger-enabled true, ACR monitors tracked base images. When Microsoft updates the upstream base image, ACR automatically triggers an automated build of your dependent application image and pushes it to the registry without developer intervention.

# Creating an ACR Task with Git push and Base Image Update Triggers
az acr task create \
  --registry contosoacr \
  --name task-build-payment \
  --image payment:{{.Run.ID}} \
  --context https://github.com/contoso/payment-service.git#main \
  --file Dockerfile \
  --git-access-token $GIT_PAT \
  --base-image-trigger-enabled true \
  --base-image-trigger-type Runtime

ACR Geo-Replication

For global deployments spanning multiple Azure regions, maintaining a single-region ACR causes high egress data transfer costs and substantial container pull latencies during cluster scale-out events. ACR Geo-Replication (exclusive to the Premium tier) solves this:

• The registry operates under a single uniform login server name (e.g., contoso.azurecr.io).
• Image pushes to any regional endpoint replicate asynchronously to all configured target regions.
• When an AKS cluster in East US 2 pulls an image, Azure proximity routing automatically routes the pull request to the local East US 2 replica, eliminating cross-region latency and outbound data transfer fees.

Content Trust and OCI Image Signing

Securing the software supply chain requires cryptographic guarantees that container images deployed into production clusters have not been tampered with and originate from trusted CI/CD pipelines.

• Docker Content Trust (DCT / Notary v1): Relies on tag-level signatures managed by a Notary server. While widely supported, it requires separate infrastructure and is tied to specific image tags.
• Notation (Notary Project / OCI v1.1) & Cosign: The modern, cloud-native standard for signing container images. Signatures and software bills of materials (SBOMs) are stored as distinct OCI artifacts referencing the image digest inside the registry itself. Notation integrates directly with Azure Key Vault to protect private signing keys using hardware security modules (HSM).
• AKS Enforcement via Azure Policy and Gatekeeper/Ratify: In an AKS cluster, the Azure Policy add-on for Kubernetes (powered by Gatekeeper) couples with Ratify to inspect container image signatures at the admission controller stage. If an engineer attempts to deploy an unsigned container or an image signed by an untrusted certificate, the admission webhook rejects the deployment before pods are scheduled.

---

3. Deploying to Azure Kubernetes Service (AKS)

Deploying containerized microservices to AKS requires structured manifest management and resilient rollout strategies. Enterprise teams choose between three primary configuration paradigms:

Ingress-Driven Canary Deployments in AKS

Kubernetes rolling updates update pods incrementally, but canary releases require shifting a precise percentage of live user traffic to new pods while comparing telemetry.

• NGINX Ingress Controller Canary Annotations: Teams create a secondary 'canary' Ingress resource that targets the new service version, using specific annotations to shift traffic:
  • nginx.ingress.kubernetes.io/canary: 'true'
  • nginx.ingress.kubernetes.io/canary-weight: '10' (Routes 10% of inbound requests to the canary service)
  • nginx.ingress.kubernetes.io/canary-by-header: 'X-Beta-User' (Routes requests containing specific headers directly to canary)
• Service Mesh (Istio / Open Service Mesh): Configures fine-grained traffic routing via VirtualService and DestinationRule resources, enabling percentage splits across pod subsets, header-based routing, and fault injection.

Azure Pipelines KubernetesManifest@1 Task

The native Azure Pipelines task for Kubernetes deployments provides specialized actions designed for GitOps and progressive delivery:

1. action: bake: Uses a manifest templating tool (Helm, Kustomize, or KOMPOSE) to render parameterized definitions into raw, hydrated YAML files during pipeline execution, publishing the output as an artifact.
2. action: deploy: Applies the hydrated manifests to the target AKS cluster via a Kubernetes service connection. Automatically handles imagePullSecrets injection and waits for workload rollout status.
3. strategy: canary: Automatically creates a canary workload (e.g., payment-service-canary) with an isolated pod replica set and service based on a specified percentage, allowing automated health checks to evaluate the release before promotion.

# Stage 1: Bake Manifests using Helm
- task: KubernetesManifest@1
  displayName: 'Bake K8s Manifests with Helm'
  inputs:
    action: 'bake'
    renderType: 'helm'
    helmChart: '$(Pipeline.Workspace)/charts/payment'
    overrideValues: 'image.repository=contosoacr.azurecr.io/payment,image.tag=$(Build.BuildId)'

# Stage 2: Canary Deployment to AKS
- task: KubernetesManifest@1
  displayName: 'Deploy Canary to AKS'
  inputs:
    action: 'deploy'
    strategy: 'canary'
    percentage: '15'
    manifests: '$(Bake.manifestsBundle)'
    containers: 'contosoacr.azurecr.io/payment:$(Build.BuildId)'

---

4. Azure Container Apps (ACA) Delivery & Revision Management

Azure Container Apps (ACA) is a fully managed, serverless container hosting platform built on top of Azure Kubernetes Service, Envoy proxy, and KEDA. It is optimized for microservices, web APIs, and asynchronous event-driven background jobs without exposing the operational complexity of raw Kubernetes clusters.

                                  [Inbound HTTP Traffic]
                                             │
                                             ▼
                                   [Built-in Envoy Proxy]
                                             │
                               (Traffic Splitting Weights)
                         ┌───────────────────┴───────────────────┐
                         │ 80% Traffic                           │ 20% Traffic
                         ▼                                       ▼
            [Revision: payment--rev-2026-v1]        [Revision: payment--rev-2026-v2]
            • Active Production Baseline            • Canary Release Candidate
            • Minimum Replicas: 2                   • Minimum Replicas: 1
            • KEDA HTTP Scaler Active               • KEDA HTTP Scaler Active

Revisions and Traffic Splitting

A Revision in ACA is an immutable snapshot of a container app version. Whenever you update container images, environment variables, or resource allocations, ACA generates a new revision.

• Single Revision Mode: Only one revision is active at any time. When a new revision is deployed, ACA performs a zero-downtime rolling update, directing 100% of traffic to the new revision once its health probes pass.
• Multiple Revision Mode: Multiple revisions run simultaneously, each with a unique URL. This mode is the prerequisite for canary deployments, blue-green releases, and A/B testing in Container Apps.

# Enabling Multiple Revision Mode and Splitting Traffic via Azure CLI
az containerapp revision set-mode \
  --name payment-service \
  --resource-group rg-microservices-prod \
  --mode multiple

# Split traffic: 80% to stable baseline, 20% to newly deployed revision
az containerapp ingress traffic set \
  --name payment-service \
  --resource-group rg-microservices-prod \
  --revision-weight payment-service--rev1=80 payment-service--rev2=20

KEDA Event-Driven Autoscaling

ACA includes native integration with Kubernetes Event-driven Autoscaling (KEDA). Unlike standard CPU or memory threshold autoscalers, KEDA scales container instances based on real-world events and queue depths:

• Scale-to-Zero: When an Azure Service Bus queue, Azure Storage Queue, or Kafka topic is empty, ACA deprovisions all container instances (replicas = 0), incurring zero compute costs.
• Rapid Event Bursting: As messages flood the queue, KEDA instantly scales up container replicas to the configured maximum limit.

---

5. Comprehensive Container Hosting Options Matrix

---

6. Realistic Exam Scenario & Common Traps

Scenario: Supply Chain Microservice Modernization

Organization: Contoso Logistics runs a real-time tracking microservice receiving telemetry from delivery vehicles worldwide. They are migrating from on-premises Docker hosts to Azure.

• Requirement 1: Container images must be pulled locally in North America, Europe, and Southeast Asia to minimize image pull latency during regional auto-scaling events.
• Requirement 2: Upstream security vulnerabilities in the official .NET runtime base image must be automatically patched without waiting for developers to commit code.
• Requirement 3: Releases must shift 10% of live HTTP traffic to the new revision and scale compute based on incoming Azure Service Bus message depth, scaling down to zero during nighttime hours.

DevOps Architect Solution:

1. Provision an Azure Container Registry Premium instance with Geo-Replication configured across East US, West Europe, and Southeast Asia.
2. Configure an ACR Task with --base-image-trigger-enabled true targeting the .NET base image.
3. Deploy the application to Azure Container Apps in Multiple Revision Mode, configuring weighted traffic splitting (90/10) on ingress and attaching a KEDA Azure Service Bus scaler with minReplicas: 0.

Common Exam Traps to Avoid

• Trap: Selecting ACR Standard when Geo-Replication or Private Link is required. Geo-Replication and Azure Private Link private endpoints are strictly restricted to the Premium tier.
• Trap: Assuming Docker Content Trust (DCT) is the only container signing mechanism. The modern exam focuses heavily on OCI v1.1 standards using Notation and Cosign backed by Azure Key Vault and enforced via Gatekeeper/Ratify admission control.
• Trap: Recommending AKS when the scenario requires minimal infrastructure management and native scale-to-zero. If an exam prompt emphasizes reducing Kubernetes cluster maintenance overhead while retaining event-driven scaling, Azure Container Apps is the correct answer over raw AKS.