Provision and manage containers in the Azure portal

Saltmarsh Foods is deploying an HTTP API as a container image to Azure Container Apps in a Consumption environment. The API receives traffic only during business hours. The finance team insists that the app incur no compute charges overnight, and the engineering team wants the app to handle up to roughly 500 concurrent requests during the day without manual intervention.

How should you configure the container app's scale settings?

1. ASet minimum replicas to 0, maximum replicas to 10, and add an HTTP scaling rule with 50 concurrent requests per replica.A minimum of 0 lets the app scale to zero and stop compute billing when idle; the HTTP rule adds replicas as concurrency rises, and 10 replicas at 50 concurrent requests each covers the daytime load.
2. BSet minimum replicas to 1, maximum replicas to 10, and add an HTTP scaling rule with 50 concurrent requests per replica.A minimum of 1 keeps a replica running all night, which incurs compute charges and violates the finance constraint.
3. CSet minimum and maximum replicas to 10 with no scaling rules.Fixed replicas never scale down, so the app pays for ten replicas around the clock.
4. DSet minimum replicas to 0, maximum replicas to 10, and add a CPU utilization scaling rule at 70 percent.CPU and memory scaling rules in Container Apps cannot scale to zero; only HTTP, TCP and event-driven (KEDA) rules support scaling to zero replicas.

Wrenfield Imaging has two containerized workloads. Workload A is a single-container image converter that runs on demand for 20 minutes and needs 2 vCPU and 8 GiB. Workload B is a queue-driven worker that must run multiple replicas when an Azure Storage queue backs up and must scale to zero when the queue is empty; each replica needs 1 vCPU and 2 GiB. The company wants to avoid managing Kubernetes and wants each workload on the service whose scaling model fits it with minimal custom code.

Where should you run each workload?

1. AWorkload A on Azure Container Instances; Workload B on Azure Container Apps with a queue-based scale rule.ACI runs a single container group on demand with per-second billing and no autoscaling, which suits the converter. Container Apps provides KEDA-based queue scaling with scale-to-zero, which suits the worker.
2. BBoth workloads on Azure Container Instances, with a Logic App that creates additional container groups when the queue length grows.ACI has no built-in autoscaling; replicating queue-based scaling with Logic Apps is custom orchestration that Container Apps already provides natively.
3. CBoth workloads on Azure Container Apps with minimum replicas set to 1.A minimum of 1 keeps replicas running when idle, and the on-demand converter would be billed continuously instead of for 20 minutes at a time.
4. DWorkload A on Azure Container Apps with a CPU scale rule; Workload B on Azure Container Instances with a container group per queue message.This inverts the fit: CPU rules cannot scale to zero, and launching a container group per message requires custom code to poll the queue and manage groups.

Ironbridge Apparel is creating an Azure Container Registry named acrironbridge to hold container images for its online store. Deployments run in both the East US and West Europe regions, and the security team requires that images be pulled over a private endpoint only, with no public network access. The company wants the lowest-cost tier that satisfies both requirements.

Which service tier should you choose?

1. ABasicBasic is a cost-optimized tier for development and learning. It does not support geo-replication or private endpoints.
2. BStandardStandard increases storage and throughput over Basic but still does not offer geo-replication or private endpoints.
3. CPremiumPremium is the only tier that supports geo-replication to serve images locally in multiple regions and private endpoints with public access disabled.
4. DPremium with a dedicated data endpoint in each regionDedicated data endpoints are an optional Premium feature for firewall allow-listing of data traffic; they are not required for private endpoint access and add nothing the scenario asks for.

Larchmont Research needs to run a nightly data-processing job as a Linux container. The job consists of two containers that must start together, share a single Azure Files volume, communicate over localhost, and be billed only while they run. The job uses up to 2 vCPUs and 6 GiB in total and finishes within an hour. The team wants the simplest Azure service that meets these needs without managing orchestration.

What should you create?

1. AOne Azure Container Instances container group containing both containers, with the Azure Files share mounted as a volume.A container group schedules multiple containers on the same host with a shared lifecycle, shared local network and shared volumes, and ACI bills per second only while the group runs.
2. BTwo separate Azure Container Instances container groups connected through a virtual network.Separate groups do not share localhost or a lifecycle; they would need a virtual network and service discovery that the scenario does not require.
3. CAn Azure Kubernetes Service cluster with one pod running both containers.A pod would provide the shared network and volume, but AKS requires managing a cluster and node pool that are billed continuously, which conflicts with the simplicity and pay-while-running constraints.
4. DAn App Service Web App for Containers hosting a Docker Compose configuration.App Service runs continuously on an App Service plan that is billed whether or not the job is executing, and it is designed for web workloads rather than batch jobs.