AZ-305 Design infrastructure solutions 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.

• ✗

  Azure Virtual Machine Scale Sets

  Why it's wrong here

  Azure Virtual Machine Scale Sets (VMSS) operate at the IaaS layer to autoscale identical VM instances, but they do not provide any container orchestration capabilities. Even if you install a container runtime on each VM, you are still responsible for scheduling containers, managing service discovery, and performing rolling updates manually or by integrating external tooling such as a self-managed Kubernetes cluster. VMSS autoscaling is based on VM-level metrics like CPU, not container health, so it cannot natively scale or repair individual containerized workloads, making it a poor fit for a fully managed container platform.

• ✓

  Azure Kubernetes Service (AKS)

  Why this is correct

  Azure Kubernetes Service (AKS) is a fully managed container orchestration platform that abstracts the Kubernetes control plane—including etcd and the API server—so you never have to manage those components. It provides managed node pools, cluster autoscaler, seamless integration with Azure Load Balancer and Application Gateway, and declarative rolling updates through Kubernetes Deployments and ReplicaSets. AKS handles scheduling, self-healing, service discovery, and secret management natively, making it the appropriate choice when you need robust, production-grade orchestration for containerized applications without managing the underlying orchestration infrastructure.

• ✗

  Azure App Service

  Why it's wrong here

  Azure App Service is a PaaS offering that can run containerized web apps, but its container support is best suited for a single container or a simple Docker Compose definition, not for orchestrating distributed microservices. It does not expose Kubernetes primitives like Pods, Services, or Ingress controllers, and its autoscaling is based on web app metrics or a scheduled profile, not application-level container scheduling. While it reduces management overhead by providing built-in web server integration and HTTPS, it lacks the granular deployment strategies and cluster-level service discovery that AKS offers, so it would be limiting for large-scale container-centric architectures.

• ✗

  Azure Container Instances

  Why it's wrong here

  Azure Container Instances (ACI) provides a serverless environment to start an individual container or a small container group on demand, but it has no built-in orchestrator to manage multiple containers across virtual nodes. It cannot automatically scale the number of container replicas based on traffic, nor does it support rolling updates or advanced placement policies—you would have to manually tear down and recreate containers to change an application version. ACI is ideal for a simply scheduled job or an event-driven burst workload, but it leaves all lifecycle and multi-container orchestration decisions to the developer, so it does not satisfy the requirement of running a containerized application without managing orchestration.

Go deeper

Related to this question