Microsoft AZ-204: Azure Container Solutions — Study Guide

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Part of the Microsoft Azure Developer Associate AZ-204 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure provides a spectrum of container options that span single-container execution, orchestrated clusters, and a secure, enterprise-grade image supply chain. Azure Container Instances (ACI) is the fastest path to run Linux or Windows containers without managing servers. Azure Kubernetes Service (AKS) is a managed Kubernetes control plane that scales microservices with advanced scheduling, networking, security, and DevOps integrations. Azure Container Registry (ACR) is the private, geo-replicated registry that anchors your build, tag, push/pull, and Helm distribution flows. Mastering Docker image construction and lifecycle management is foundational to reliable deployments on any of these platforms. This section establishes a practical, developer-centric view of how the pieces fit together, including YAML-driven deployments, Helm packaging, service exposure, and identity/security patterns.

Docker and Azure Container Registry (ACR)

Reliable container delivery starts with sound Docker fundamentals. Each image is composed of layers formed by Dockerfile instructions; layer reuse and cache hits are critical to fast builds.

• Common Dockerfile instructions and guidance:
  • FROM defines the base image. Prefer minimal images (e.g., distroless, alpine when appropriate) to reduce attack surface and size.
  • RUN executes commands to install dependencies. Combine related commands to reduce layer count, but avoid monolithic RUN lines that obscure failures.
  • COPY and ADD place application artifacts. Use .dockerignore to avoid bloating contexts; pin COPY to explicit paths.
  • WORKDIR sets the working directory; use it instead of chaining cd in RUN.
  • EXPOSE documents intended listening ports (not a firewall).
  • ENV and ARG configure environment and build-time variables; promote build-time determinism by fixing ARG defaults or passing explicit values.
  • ENTRYPOINT defines the main executable; use CMD for default arguments. Favor exec form (JSON array) to preserve signal handling for graceful shutdown.
  • HEALTHCHECK enables liveness evaluation so orchestrators can react.
• Multi-stage builds separate build and runtime stages, copying only needed artifacts into a clean runtime image, drastically reducing size and CVE footprint. For example, build with SDK, publish binaries, then copy into a runtime base.
• Image layers are immutable and content-addressed. Reordering instructions alters caching. Place frequently-changing instructions (e.g., COPY source) late in the Dockerfile to maximize cache hits.

With ACR, store and distribute images and Helm charts privately:

• Repositories and tagging: Push images as <registry>.azurecr.io/<repo>:<tag>. Prefer semantic or Git-based tags (e.g., 1.4.0, build SHA) and use immutable digests in production deployments for repeatability.
• Pushing and pulling:
  • Authenticate to ACR using az acr login -n <acr-name> or docker login with an Azure AD token. Avoid enabling the ACR admin user in production.
  • Tag and push: docker tag app:1.0 <acr>.azurecr.io/apps/app:1.0; docker push <acr>.azurecr.io/apps/app:1.0. Pull with docker pull or via Kubernetes image references.
  • Import upstream images to ACR to control supply chain: az acr import -n <acr> –source docker.io/library/nginx:1.25 –image base/nginx:1.25.
• ACR Tasks: Build, test, and patch images natively in Azure. Use az acr build -r <acr> -t apps/app:1.0 . for on-demand builds; automate updates with az acr task create to trigger from Git commits or base image updates, enabling CVE remediation without changing app code.
• Geo-replication (Premium SKU) provides multi-region pull locality and resilience. Configure replicas in regions close to AKS clusters to reduce pull latency and cross-region egress.
• Access control:
  • Integrate with Azure AD and assign built-in roles like AcrPull to AKS kubelet identity, and AcrPush to CI pipelines. Repository-scoped permissions are available via tokens and scope maps for fine-grained control.
  • Restrict network access with private endpoints, service endpoints, and firewall rules. Prefer private endpoints for production.
  • Attach ACR to AKS with az aks update –attach-acr <acr> to simplify AcrPull role assignment.

Azure Container Instances (ACI)

ACI runs containers on-demand without cluster management. The primary unit is a container group, a co-scheduled set of containers sharing the same host OS kernel, lifecycle, IP, and volumes. Use container groups to implement the sidecar pattern (e.g., log shippers, proxies) or combine a main process with a helper.

• Multi-container groups share a network namespace, enabling inter-container communication over localhost. They also share mounted volumes (Azure Files, emptyDir) and lifecycle, making them suitable for cohesive one-off tasks that require close coupling.
• Restart policies control execution semantics:
  • Always restarts containers when they exit. Best for long-running services.
  • OnFailure restarts only on non-zero exit codes. Fit for batch tasks that should retry on failure.
  • Never runs containers once and never restarts them, ideal for idempotent jobs.
• Networking integrations include public IP with a DNS label, private IPs in a delegated Azure VNet subnet, and secure egress via NAT or firewall. VNet-injected ACI enables private access to services (databases, storage) without public exposure.
• Operational considerations:
  • Inject secrets using secure environment variables or mount Azure Files; for stronger posture, retrieve secrets at runtime via managed identity from Key Vault.
  • Observe with az container logs and az container attach; run interactive commands with az container exec.
  • Billing is per-second for vCPU and GiB memory. Containers start quickly and fit bursty workloads, CI helper tasks, integration tests, and queue-triggered jobs where Kubernetes overhead is unnecessary.

Azure Kubernetes Service (AKS)

AKS provides a managed control plane with node pools, autoscaling, and deep networking/identity options.

Node pools structure capacity and workload placement. System node pools run core services; user node pools run application pods. Use multiple pools to segregate workloads by CPU/Memory/GPU needs, OS (Linux/Windows), VM size, and availability zone. Employ taints/tolerations to protect system pools, labels for selection, and cluster autoscaler to add/remove nodes based on pending pods. Consider maxPods per node and pod density when sizing.

Pod scheduling is driven by resource requests/limits, QoS classes (Guaranteed/Burstable/BestEffort), and constraints. Use nodeSelector/affinity and anti-affinity to push pods to appropriate pools and distribute replicas across zones and failure domains. Topology spread constraints improve even distribution. For critical services, define PodDisruptionBudgets and PriorityClasses to shape voluntary disruptions and preemption behavior. DaemonSets place per-node agents (logging, monitoring), and CronJobs schedule containers for periodic tasks.

Deployments in AKS are declarative. YAML manifests define apiVersion, kind, metadata, and spec for Deployments, StatefulSets, Jobs, Services, and Ingress. Keep manifests in source control, parameterize with Kustomize overlays for environment differences, and apply with kubectl apply -f. Server-side apply and proper labels/annotations help with ownership and drift detection. For packaging reusable apps, Helm 3 bundles templates and values. Host Helm charts as OCI artifacts in ACR and install with helm upgrade –install <release> oci://<acr>.azurecr.io/helm/<chart> -f values.yaml. Use values files per environment, track chart versions, and rollback with helm rollback for fast recovery.

kubectl commands you will use daily:

• Access the cluster context: az aks get-credentials -g <rg> -n <cluster> merges kubeconfig; using an Azure AD–joined machine with kubectl is sufficient—Docker isn’t required to deploy manifests.
• Inspect and operate: kubectl get nodes,pods,deploy,svc -A; kubectl describe pod <name>; kubectl logs -f <pod>; kubectl exec -it <pod> – sh; kubectl rollout status deploy/<name>; kubectl set image deploy/<name> container=<image>:<tag>; kubectl top pods; kubectl cordon/drain nodes for maintenance; kubectl auth can-i to verify RBAC.
• Apply/patch: kubectl apply -f k8s/; kubectl patch deploy <name> –type merge -p ‘{…}’.

Networking in AKS exposes pods and services with clear responsibilities:

• ClusterIP provides internal-only, cluster-scoped virtual IPs and DNS for service discovery. This is the default for east-west traffic between microservices.
• NodePort opens the same port on each node; it’s best used behind an Ingress or external LB rather than consumed directly.
• LoadBalancer provisions an Azure Load Balancer frontend that targets NodePorts. Mark services as internal by annotating service.beta.kubernetes.io/azure-load-balancer-internal: “true”, or assign a static public IP for stable DNS.
• Ingress controllers provide L7 routing, TLS termination, and path/host rules. The NGINX Ingress Controller is a versatile default with rich annotations. The Application Gateway Ingress Controller (AGIC) integrates with Azure Application Gateway for WAF, autoscaling, and enterprise L7 capabilities while maintaining Kubernetes-native manifests. Use cert-manager to automate TLS with ACME, or synchronize Key Vault certs into Kubernetes secrets with CSI Secret Store.

Identity and authorization integrate Azure AD without in-cluster secrets:

• Managed identities for AKS consist of the cluster/control plane identity and the kubelet identity. Grant the kubelet AcrPull on ACR (az aks update –attach-acr <acr>) so nodes can pull images securely.
• Workload identity enables pods to access Azure resources using federated Azure AD credentials mapped to Kubernetes service accounts—no node-level credentials or sidecars. Enable OIDC issuer on the cluster, create a user-assigned managed identity, configure a FederatedIdentityCredential for the service account/namespace, and use the Azure Identity SDK in the app. This supersedes the older AAD Pod Identity model and aligns with open standards.
• RBAC governs Kubernetes API permissions. Bind Kubernetes Roles/ClusterRoles to Azure AD users or groups via RoleBindings/ClusterRoleBindings when AKS is integrated with Azure AD. Alternatively, enable Azure RBAC for Kubernetes Authorization to manage access with Azure RBAC roles such as Azure Kubernetes Service RBAC Reader, Writer, and Admin. Follow least privilege, separate namespaces by team or workload, and gate production via group-based bindings.

End-to-end image flow to AKS is straightforward and secure. Build multi-stage images, tag with immutable versions, push to ACR, and deploy to AKS with manifests or Helm. AKS pulls from ACR using the kubelet managed identity, and pods consume Azure resources via workload identity. Services are exposed via ClusterIP/LoadBalancer and refined with an ingress controller that centralizes TLS and routing.

Practical Problem Scenario

Adobe’s Creative Cloud team is decomposing a monolithic media processing service into microservices, targeting low-latency global delivery and a hardened supply chain.

1. Build and store images using multi-stage Dockerfiles in CI

• Use Docker multi-stage to compile media codecs and copy only the runtime binaries into a slim base image, minimizing size and CVEs. Push images as <acr>.azurecr.io/processing/encoder:<git-sha> to ACR. This ensures reproducible, secure artifacts with immutable digests for deployment pinning.

2. Harden the registry and automate patching

• Create an ACR Premium registry with private endpoints in each virtual network that hosts AKS. Enable geo-replication to North Europe and East US to keep pulls local. Configure ACR Tasks to trigger rebuilds on upstream base image updates, automatically propagating patched layers. This balances performance with security and reduces egress.

3. Stand up AKS with separated node pools and identity

• Deploy AKS with Azure CNI and system/user node pools: a small system pool for control plane add-ons, GPU-enabled user pools for transcoding, and general-purpose pools for APIs. Enable Azure AD integration, OIDC issuer, and workload identity. Assign AcrPull to the kubelet identity via az aks update –attach-acr. This isolates workloads, scales efficiently, and removes secret-based image pulls.

4. Define declarative deployments and packaging

• Author Kubernetes YAML for Deployments, StatefulSets where persistence is needed, Services, HorizontalPodAutoscaler, and PodDisruptionBudgets. Package the encoder service and API gateway as Helm charts, publish them as OCI artifacts to ACR, and deploy with helm upgrade –install using environment-specific values. This provides consistent, versioned releases and simple rollbacks.

5. Expose services and enforce L7 security

• Use ClusterIP for internal microservices and a LoadBalancer service with the Application Gateway Ingress Controller for public APIs. Terminate TLS at Application Gateway with a WAF policy, manage certificates using cert-manager integrated with Azure DNS for ACME challenges, and route to backends by host/path. This yields enterprise-grade L7 security with Kubernetes-native configuration.

6. Implement secure workload access to Azure resources

• For a thumbnailing service that writes to Blob Storage and reads secrets, create a user-assigned managed identity, federate it with the service account via workload identity, and grant Storage Blob Data Contributor and Key Vault Secrets User roles. The pod authenticates with Azure AD, eliminating secret mounts and enabling fine-grained, auditable access.

7. Operate batch overflow with ACI

• For sporadic, high-priority batch overflow, trigger ACI multi-container groups (encoder + sidecar metrics collector) with restartPolicy: Never inside a VNet-injected subnet. This absorbs spikes without scaling AKS to peak and preserves private data paths to storage accounts.

Each choice directly supports Adobe’s goals: ACR Premium with geo-replication and private endpoints secures and accelerates image pulls; AKS with specialized node pools and workload identity enforces isolation and least-privilege access; Helm and declarative YAML standardize deployments and rollbacks; AGIC with WAF delivers resilient, secure L7 ingress; and ACI handles burst batch processing without persistent cluster cost.

← Azure Cosmos DB · All domains · Azure Authentication →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →