AZ-104 Deploy and Manage Azure Compute Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  ACI is ideal for simple, short-lived tasks or burst workloads that do not require orchestration.

  Why this is correct

  ACI is correct for simple, short-lived tasks or burst workloads because it is a serverless container offering with per-second billing and no underlying cluster to provision. It starts containers quickly and is designed for discrete executions such as batch jobs or event-driven processing, but it does not manage the full orchestration lifecycle, so workloads needing inter-container service discovery, rolling updates, or cluster-scale coordination are better served by AKS.

• ✓

  AKS provides built-in auto-scaling, service discovery, and rolling update capabilities.

  Why this is correct

  AKS provides built-in orchestration features because it is a managed Kubernetes service, which natively includes the horizontal pod autoscaler for replica scaling and the cluster autoscaler for node scaling. It also leverages Kubernetes DNS for service discovery and supports ReplicaSet/Deployment controllers that enable rolling updates and rollback capabilities without manual VM-level intervention. These capabilities are core to Kubernetes rather than add-ons, making AKS appropriate for complex microservice architectures.

• ✓

  ACI supports mounting an Azure Files share as a persistent volume.

  Why this is correct

  ACI supports mounting an Azure Files share as a persistent volume by using the azureFile volume plugin, allowing container instances to read and write files stored in a managed SMB share. This is essential for stateful containers that need to share data across restarts or multiple container groups, and it integrates directly with Azure Storage accounts. Note that ACI does not natively support Azure Disk persistent volumes, so Azure Files is the primary persistent storage option for container groups.

• ✗

  AKS supports only Linux-based container images and cannot run Windows containers.

  Why it's wrong here

  This statement is wrong because AKS does support Windows containers, although Linux is the default node pool operating system. You can explicitly add a Windows Server node pool (for example, using Windows Server 2019 or 2022) to an AKS cluster and schedule Windows Server containers on it. While Linux containers enjoy first-class support in most Kubernetes features, Windows containers are fully supported on AKS with proper tolerations and nodeSelectors.

• ✗

  ACI automatically manages container orchestration, including load balancing and scaling across nodes.

  Why it's wrong here

  This statement is wrong because ACI does not include an orchestration control plane; it is designed for managing a single container or a container group but does not automatically handle cross-node load balancing or scaling. Scaling in ACI is manual or based on external triggers (e.g., Azure Functions, Logic Apps) since there are no built-in replicas or autoscaler. For automatic load balancing and scaling across multiple nodes, you need an orchestrator like AKS or connect ACI to another load-balancing service.

• ✗

  AKS requires you to manage the underlying virtual machine infrastructure, including patching the OS.

  Why it's wrong here

  This statement is wrong because AKS is a managed Kubernetes service where Azure manages the control plane and, for system node pools, patching and updates of the underlying virtual machine infrastructure are largely automated. While user node pools run on worker VMs that you can configure, Azure handles node image updates and OS security patching as part of the managed service, subject to your maintenance windows. You do not have to manually RDP into nodes or patch the OS yourself, which is a major benefit of AKS over self-managed Kubernetes.

Go deeper

Related to this question