AZ-204 Develop Azure compute 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.

• ✓

  Use Azure Logic Apps with a Container Instances connector.

  Why this is correct

  Azure Logic Apps provide a robust, serverless workflow engine perfectly suited for event-driven scenarios, such as processing messages from a queue. Its native Azure Container Instances (ACI) connector enables the dynamic creation and execution of a new container instance for each incoming queue message. This design ensures true 'from zero' scaling, where compute resources are provisioned only when needed and deallocated immediately after the containerized task completes, optimizing cost and operational overhead for sporadic batch jobs.

• ✗

  Use Azure Functions with a custom container and queue trigger.

  Why it's wrong here

  While Azure Functions support running custom container images and can be triggered by queue messages, their scaling model primarily scales the underlying Function App host instances, not necessarily launching a distinct, isolated container instance per message. This means the container environment might persist or scale based on host demand rather than individual message processing, potentially incurring costs even when idle. It lacks the granular, per-task isolation and 'from zero' efficiency of directly orchestrating ephemeral ACI instances for each specific message.

• ✗

  Use Azure Batch to process the images in a pool of VMs.

  Why it's wrong here

  Azure Batch manages a pool of VMs and a job scheduler, but it introduces overhead for provisioning and maintaining the underlying compute nodes, which contradicts the requirement for a container that runs only when messages appear and scales automatically without persistent infrastructure. This option is tempting because Azure Batch is designed for high-throughput, parallel batch processing of large workloads, such as rendering or genomic analysis, where a dedicated pool of VMs is justified; in that scenario, it would be the correct choice.

• ✗

  Deploy the image processing job as a pod in Azure Kubernetes Service.

  Why it's wrong here

  Deploying as a pod in Azure Kubernetes Service introduces the overhead of managing a Kubernetes control plane, cluster nodes, and pod scheduling, which is unnecessary for a simple batch job triggered by queue messages. The requirement is for a serverless, event-driven container that scales automatically from zero, which ACI with a virtual node or KEDA integration achieves without cluster management. This option is tempting because AKS excels at orchestrating complex, multi-container microservices with advanced scaling policies, making it the correct choice for a long-running, stateful application requiring load balancing and rolling updates.

Go deeper

Related to this question