Skip to main content

Technical Lab: Manage sizing and scaling for containers, including Azure Container Instances and Azure Container Apps

Questions​

Question 1 — Multiple Choice​

A team needs to run a batch processing job that should run to completion and terminate automatically. The workload is stateless, lasts about 40 minutes, and doesn't require continuous orchestration. Which restart policy behavior in Azure Container Instances is most suitable for this scenario?

A) Always, as it ensures the container is restarted in case of failure during processing.

B) Never, as it prevents any restart and terminates the container upon completion of execution.

C) OnFailure, as it restarts the container only if it terminates with a non-zero exit code.

D) Always, as it's the default and ensures high availability for long-running workloads.

Question 2 — Technical Scenario​

A developer deployed an application to Azure Container Apps with the following scaling configuration:

{
  "scale": {
    "minReplicas": 0,
    "maxReplicas": 5,
    "rules": [
      {
        "name": "http-rule",
        "http": {
          "metadata": {
            "concurrentRequests": "10"
          }
        }
      }
    ]
  }
}

During low traffic periods, the application completely disappears from the environment and new requests take several seconds to be served. What is the direct cause of this behavior?

A) The concurrentRequests value is too low, forcing scaling to zero prematurely.

B) minReplicas: 0 allows the environment to reduce replica count to zero when there's no traffic, causing cold start on first requests.

C) Azure Container Apps doesn't support HTTP-based scaling; a custom KEDA rule is required.

D) maxReplicas: 5 is insufficient and causes throttling, which the environment interprets as lack of demand.

Question 3 — True or False​

In Azure Container Instances, it's possible to change the number of CPUs and memory amount of an already deployed container group through an in-place update operation, without needing to recreate the resource.

Question 4 — Technical Scenario​

An application deployed to Azure Container Apps processes messages from an Azure Service Bus queue. The team configured a KEDA-based scaling rule for this queue. During load testing, it was observed that new replicas are created correctly, but the number of replicas never exceeds 3, even with hundreds of pending messages.

What is the most likely cause of this behavior?

A) KEDA is not compatible with Azure Service Bus in Azure Container Apps; queue-based scaling requires the use of Azure Event Hubs.

B) The Container Apps environment reached the consumption plan resource limit, preventing new replicas.

C) The maxReplicas value in the scaling configuration is set to 3, limiting the maximum number of instances.

D) The KEDA rule is configured with messageCount instead of queueLength, which prevents correct metric reading.

Question 5 — Multiple Choice​

When comparing the scaling model of Azure Container Instances with Azure Container Apps, which statement correctly describes a fundamental difference between the two services?

A) Azure Container Instances supports native horizontal auto-scaling, while Azure Container Apps requires manual replica configuration.

B) Azure Container Apps offers horizontal auto-scaling with KEDA support, while Azure Container Instances doesn't have native auto-scaling.

C) Both services support horizontal auto-scaling, but Azure Container Instances uses KEDA and Container Apps uses Azure Monitor metrics.

D) Azure Container Instances scales vertically automatically based on CPU load, while Container Apps only scales horizontally.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: C

The OnFailure policy restarts the container only when it terminates with a non-zero exit code, i.e., in case of error. For a batch processing job that should run to completion and terminate normally, this behavior is correct: if execution is successful, the container stops; if it fails, it tries again.

The Never alternative would eliminate the possibility of retry in case of intermediate failure, which is inadequate for jobs where minimal resilience is desirable. The Always policy would keep the container restarting indefinitely after successful completion, consuming unnecessary resources and never ending the job as expected.

Answer Key — Question 2​

Answer: B

When minReplicas is set to 0, Azure Container Apps allows the environment to reduce the number of active replicas to zero during periods without traffic. When receiving a new request, the environment needs to provision a replica from scratch, which generates the cold start observed as high initial latency.

This behavior is intentional and useful for reducing costs, but has the trade-off of latency on first requests. The solution for environments that don't tolerate cold start is to set minReplicas to at least 1. The concurrentRequests value only controls when new replicas are added during scaling, not scale-to-zero.

Answer Key — Question 3​

Answer: False

Azure Container Instances does not support in-place updating of CPU and memory resources of an already deployed container group. Changes to these parameters require deletion and recreation of the container group. This is a relevant architectural limitation of the service that differentiates it from platforms with support for resource mutation during execution. Planning the initial sizing correctly is essential, as later adjustments imply downtime of the container group.

Answer Key — Question 4​

Answer: C

The maxReplicas parameter defines the absolute ceiling of instances that Azure Container Apps can provision for a revision, regardless of demand. If this value is configured as 3, the scaler will never create a fourth replica, even with hundreds of pending messages in the queue.

This is a common configuration error: the KEDA rule may be correctly defined to react to the queue, but maxReplicas acts as a hard limiter above KEDA's logic. The compatibility between KEDA and Azure Service Bus in Container Apps is native and well supported, making alternatives A and D incorrect. The consumption plan resource limit (alternative B) would produce different behavior, usually with provisioning error, not a silent limit at 3 replicas.

Answer Key — Question 5​

Answer: B

Azure Container Apps is designed for workloads that require dynamic scaling, using KEDA (Kubernetes Event-Driven Autoscaling) as the horizontal scaling engine, with support for multiple event sources like queues, topics, HTTP metrics, and others.

Azure Container Instances, on the other hand, is an on-demand container execution service without native horizontal auto-scaling. Each container group is an isolated unit; to scale horizontally in ACI, it's necessary to provision multiple container groups through external mechanisms (like Azure Logic Apps, scripts, or integrations with AKS). Confusing the scaling models of the two services is a frequent conceptual error in AZ-104 preparation.