Java / Azure Container Instances (ACI) Interview questions

Azure Container Instances is Azure's serverless way to run containers. You supply an image plus CPU and memory values, and Azure runs it for you. There are no VMs to provision and no orchestrator to operate, and containers usually start within seconds.

The unit you deploy is a container group. ACI runs both Linux and Windows containers, and you pay per second for the vCPU and memory you request.

• Public IP with a DNS label, or a private IP inside a virtual network
• Azure Files volumes, managed identities and private registry pulls
• Optional Spot (cheaper, interruptible) and confidential (hardware-protected) containers

ACI is not a full orchestrator. It has no built-in autoscaling, rolling updates or service discovery, so it fits short-lived and bursty workloads best.

A container group is the top-level ACI resource (Microsoft.ContainerInstance/containerGroups). It holds one or more containers that are scheduled on the same host and share a lifecycle, network and storage. It is the closest thing ACI has to a Kubernetes pod.

• One IP address and port space; containers talk to each other over localhost
• Shared volumes that any container in the group can mount
• One restart policy and one start/stop/delete lifecycle for the whole group
• Billing based on the sum of the containers' CPU and memory requests

Multi-container groups are Linux only, and a group can hold up to 60 containers. Windows groups are limited to a single container.

ACI charges per second for the vCPU and memory GB you request for a container group, for as long as it runs. You pay for what you request, not what the process actually uses.

Billing starts when ACI begins pulling the image and ends when the group stops, is deleted, or finishes running to completion.

• Windows containers add a software charge on top of compute
• GPU resources are billed per GPU-second
• Spot containers can be up to 70% cheaper than regular ones
• Public IPs, Log Analytics ingestion and Azure Files are billed separately

Because requests drive the bill, right-sizing CPU and memory is the easiest saving.

ACI runs Linux and Windows containers through the same API. You pick the OS with --os-type (Linux is the default). Images must be built for x64 (AMD64); ARM64 images are not supported.

The two operating systems do not have identical features:

If an image fails to start right away, check the OS type and architecture before anything else.

Windows base images are also much larger than Linux ones, so cold starts take noticeably longer on Windows.

Create a resource group, then run az container create with the image, size and ports. A DNS label gives you a public name.

az group create --name rg-aci-demo --location eastus

az container create \
  --resource-group rg-aci-demo \
  --name aci-hello \
  --image mcr.microsoft.com/azuredocs/aci-helloworld \
  --cpu 1 --memory 1.5 \
  --ports 80 \
  --dns-name-label aci-hello-12345

1. Check progress with az container show --query instanceView.state.
2. Browse to the FQDN (for example aci-hello-12345.eastus.azurecontainer.io).
3. Clean up with az container delete so billing stops.

The command returns once the group is created, and the first start is slower because the image has to be pulled from the registry.

ACI has three restart policies, set once on the whole container group with --restart-policy:

With Never or OnFailure, the group ends once its containers finish, and billing stops. A batch image left on Always will loop forever.

Choose the policy to match how your process behaves: a web server should never exit, so Always fits, while a script that ends on purpose should not be restarted.

There are two network modes. A public group gets a public IP (--ip-address Public), the ports you list with --ports, and an optional DNS label that produces label.region.azurecontainer.io. A private group is deployed into a virtual network and only gets a private IP.

Ports must be declared on the group and the application must actually listen on them. TCP and UDP are both supported.

ACI does not terminate TLS for you. For HTTPS, put a sidecar proxy such as nginx or Caddy in the group, or place Application Gateway or Front Door in front.

There are three options, listed from least to most preferred: registry username and password, a service principal, or a managed identity. The managed identity needs the AcrPull role on the registry, so no password has to be stored.

az container create \
  --resource-group rg-aci-demo --name aci-private \
  --image myregistry.azurecr.io/app:1.0 \
  --assign-identity <identity-resource-id> \
  --acr-identity <identity-resource-id> \
  --registry-login-server myregistry.azurecr.io

Keep the registry in the same region as the group to speed up pulls. If the registry is behind a firewall or private endpoint, make sure the ACI subnet can reach it.

Use az container logs. It returns what the container process wrote to stdout and stderr, so your application has to log to the console and not only to files.

az container logs -g rg-aci-demo -n aci-hello
az container logs -g rg-aci-demo -n aci-multi --container-name sidecar
az container attach -g rg-aci-demo -n aci-hello

az container attach streams output live and also shows container events, which helps when a container is slow to start. For retention and queries, send logs to a Log Analytics workspace.

Run az container exec with the command you want, for example a shell. It opens an interactive session through the Azure management API, so you need the right RBAC permissions on the group and the container must be running.

az container exec -g rg-aci-demo -n aci-hello --exec-command "/bin/sh"
# multi-container group: pick the target container
az container exec -g rg-aci-demo -n aci-multi \
  --container-name app --exec-command "/bin/sh" 

The image has to contain the binary you call. Minimal or distroless images often have no shell, in which case you debug with logs and events instead.

ACI supports four volume types, and only one of them is persistent.

A group can have up to 20 volumes. Anything not on Azure Files disappears when the group is stopped or deleted.

Use Azure Files for anything you cannot afford to lose, and keep emptyDir for temporary files such as caches or hand-offs between containers.

Both pass configuration into the container. A normal variable (--environment-variables) is visible in the group's properties in the portal and API output. A secure variable (--secure-environment-variables, or secureValue in YAML) is not returned when you read the group back.

az container create -g rg-aci-demo -n aci-env --image myapp:1.0 \
  --environment-variables MODE=prod \
  --secure-environment-variables DB_PASSWORD=S3cr3t!

The process inside the container can still read the secure value, so never print it. For stronger secret handling, fetch secrets from Key Vault using a managed identity.

Each action has its own CLI command, and they behave differently:

Ephemeral data (emptyDir, container filesystem) is lost when a group is stopped, and its IP address is not guaranteed to stay the same after a start.

Each container declares requests (the guaranteed, billed amount) and optionally limits (a ceiling). The group total is the sum of all container requests. CPU can be fractional and memory is in GB.

containers:
- name: app
  properties:
    image: myapp:1.0
    resources:
      requests:
        cpu: 1.0
        memoryInGB: 1.5
      limits:
        cpu: 2.0
        memoryInGB: 2.0

A container that goes over its CPU limit is throttled, and one that goes over its memory limit is killed. The maximum group size varies by region and OS (commonly 4 vCPU and 16 GB), so check the region availability page before sizing.

A managed identity gives a container group a Microsoft Entra identity, so code inside it can call Azure services without storing credentials. Typical targets are Key Vault, Storage, SQL and Container Registry.

Enable it with --assign-identity, then grant the identity an Azure role on the target resource. Code gets tokens through the Azure SDK or the token endpoint in the container.

ACI shines wherever you need containers quickly, for a short time, with no cluster to run.

• Batch and ETL jobs that run on a schedule or trigger
• CI/CD build agents that appear for a pipeline run and vanish afterwards
• Event-driven tasks started from Logic Apps, Functions or Event Grid
• Dev/test environments and quick demos
• Burst capacity for AKS through virtual nodes

It is a poor fit for large, always-on microservice estates that need autoscaling, rolling deployments and service discovery. Those belong on AKS or Azure Container Apps.

Init containers run before your application containers, one after another, and each must finish successfully before the next starts. If an init container fails, the application containers do not start.

They suit one-time setup such as downloading config, waiting for a dependency, or preparing a shared volume. They are defined in YAML, ARM or Bicep, not through simple CLI flags.

properties:
  initContainers:
  - name: prep
    properties:
      image: busybox
      command: ["/bin/sh", "-c", "echo ready > /mnt/shared/ready"]
      volumeMounts:
      - name: shared
        mountPath: /mnt/shared

Spot containers run on spare Azure capacity at a discount of up to 70% compared with regular ACI. The catch is that Azure can preempt them when it needs the capacity back.

That makes them a good match for fault-tolerant work such as retryable batch jobs, rendering, or test runs. Design the workload to checkpoint progress and be safely restarted.

You select them with --priority Spot at creation. Spot groups do not support availability zones, and they are the wrong choice for anything with strict uptime needs.

Confidential containers run Linux container groups inside a hardware-based trusted execution environment built on AMD SEV-SNP. Memory is encrypted and protected, even from the Azure host operators, which protects data while it is in use.

You create them with the Confidential SKU and a confidential computing enforcement (CCE) policy. The policy pins the exact images, commands and settings allowed to run, and is typically generated with the az confcom extension.

Workloads can prove their environment through remote attestation. Region availability is more limited than for regular containers.

Describe the group in a YAML file and pass it to az container create --file. YAML is the easiest route for things the simple CLI flags cannot express, such as multiple containers, init containers and probes.

apiVersion: 2023-05-01
location: eastus
name: aci-yaml-demo
type: Microsoft.ContainerInstance/containerGroups
properties:
  osType: Linux
  restartPolicy: Always
  containers:
  - name: web
    properties:
      image: mcr.microsoft.com/azuredocs/aci-helloworld
      ports:
      - port: 80
      resources:
        requests:
          cpu: 1.0
          memoryInGB: 1.5
  ipAddress:
    type: Public
    ports:
    - protocol: tcp
      port: 80

az container create --resource-group rg-aci-demo --file deploy-aci.yaml

Note the ports appear twice: once on the container and once on the group's ipAddress block. Forgetting the second one is a common reason a deployed container is unreachable.

ACI runs individual container groups with no cluster. AKS is a managed Kubernetes cluster where you manage node pools and workloads, and Azure manages the control plane.

The two also combine: AKS virtual nodes can run overflow pods on ACI.

Both are serverless, but they sit at different levels. Container Apps is a platform for apps and microservices, built on Kubernetes with KEDA and Dapr behind the scenes. ACI is a lower-level building block that just runs container groups.

Use ACI when you want the simplest, fastest way to run a container for a bounded task. Use Container Apps when you are running a service that needs scale rules, ingress and safe rollouts.

Web App for Containers (Azure App Service) hosts a containerized web app on an App Service plan. ACI runs any container, web or not, and has no plan to pay for.

Choose App Service when you are hosting a web app and want slots, domains and scaling out of the box. Choose ACI for tasks, jobs and short-lived workloads.

All containers in a group run on one host inside the same sandbox, so they share the network namespace, the volumes declared on the group, and the group's lifecycle.

• Network: one IP, one port space. Containers call each other on localhost, and two containers cannot listen on the same port.
• Storage: any volume on the group can be mounted by several containers, which is how a sidecar reads files the app writes.
• Compute: each container has its own CPU and memory request, and the group size is the sum.
• Lifecycle: the restart policy and start/stop/delete apply to the whole group.

Common patterns are an app plus a TLS-terminating nginx proxy, or an app plus a log-shipping sidecar. This is Linux only.

Create a subnet delegated to Microsoft.ContainerInstance/containerGroups, then deploy the group into it. The group gets a private IP from that subnet and can talk to other VNet resources, peered networks and on-premises over VPN or ExpressRoute.

az container create -g rg-aci-demo -n aci-vnet \
  --image myapp:1.0 \
  --vnet vnet-demo --subnet snet-aci \
  --ip-address Private

• The delegated subnet is dedicated to ACI; other resource types cannot share it.
• A VNet group cannot be given a public IP or DNS label directly; use Application Gateway or Front Door for internet traffic.
• NSGs and route tables on the subnet control traffic.
• Add a NAT gateway if you need a fixed outbound IP.

Create the storage account and file share first, then pass the account name, key, share name and mount path at deployment. The share is mounted over SMB, so it persists after the group is stopped or deleted. Azure Files mounts work on Linux containers only.

az container create -g rg-aci-demo -n aci-files \
  --image myapp:1.0 \
  --azure-file-volume-account-name mystorageacct \
  --azure-file-volume-account-key "$STORAGE_KEY" \
  --azure-file-volume-share-name appdata \
  --azure-file-volume-mount-path /mnt/appdata

Several groups can mount the same share, but your application has to handle file locking. For throughput-sensitive jobs, consider a premium file share, and remember the storage key is a secret that should come from a pipeline or vault.

A liveness probe checks that a container is still healthy. After the configured number of consecutive failures, ACI restarts the container. A readiness probe checks whether it is ready to serve; a failing readiness probe does not restart anything, it just marks the container as not ready for traffic.

Each probe is either an exec command or an httpGet request, tuned with delay, period, timeout and threshold values:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 15
  failureThreshold: 3
readinessProbe:
  exec:
    command: ["cat", "/tmp/ready"]
  periodSeconds: 5

Set initialDelaySeconds high enough for slow starters, or the liveness probe will kill the container before it finishes booting.

Start with the container events, which usually name the exact reason.

az container show -g rg-aci-demo -n aci-app \
  --query "containers[0].instanceView.events" -o table

Try pulling the same image locally with the same credentials. If that works, the problem is in the ACI configuration, not the image.

Look at the restart count and the previous state to see why the last run ended.

az container show -g rg-aci-demo -n aci-app \
  --query "containers[0].instanceView.{restarts:restartCount,prev:previousState,cur:currentState}" 

1. Read the exit code. Zero with policy Always means the process simply finished; use Never or OnFailure for jobs.
2. Exit code 137 usually points to a kill, often out of memory. Raise the memory request or fix the leak.
3. Check logs with az container logs for startup errors such as missing config or a port bind failure.
4. Review probes. An aggressive liveness probe can kill a healthy but slow container.

Fix one cause at a time and redeploy, since a restart loop often has more than one reason stacked up behind it.

Choose ACI when the workload is already containerized, short-lived or bursty, and you do not want to patch or manage an OS. You pay only while it runs and it starts in seconds, whereas a VM needs to boot and bills while allocated.

• Pick ACI for: on-demand jobs, build agents, quick test environments, event-triggered tasks.
• Pick a VM for: steady 24/7 workloads where reserved pricing wins, custom kernels or drivers, full OS control, persistent local disks, or software that is not containerized.

Keep in mind that ACI storage is ephemeral unless you mount Azure Files, and per-second pricing can cost more than a reserved VM when a container runs all month.

A virtual node is a virtual-kubelet based node in your AKS cluster that backs pods with ACI instead of VMs. When you schedule a pod onto it, AKS creates a container group in ACI. You skip waiting for the cluster autoscaler to add a VM, and you pay per second for that burst.

spec:
  nodeSelector:
    type: virtual-kubelet
  tolerations:
  - key: virtual-kubelet.io/provider
    operator: Exists

• The cluster needs Azure CNI networking and a delegated subnet for the virtual node.
• Not everything is supported: DaemonSets, for example, do not run on virtual nodes.
• Only pods that carry the nodeSelector and toleration land there; other pods stay on regular nodes.

Deploy the group into a virtual network subnet and attach a NAT gateway with a static public IP (or IP prefix) to that subnet. All outbound traffic then leaves from that address, which you can add to partner firewalls and allow lists.

1. Create a public IP and a NAT gateway.
2. Attach the NAT gateway to the subnet delegated to ACI.
3. Deploy the container group into that subnet.

Without a VNet and NAT gateway, a public group's outbound address is not guaranteed and can change when it restarts, so you should not allow-list it.

A NAT gateway also offers a much larger pool of outbound ports than default outbound access, which helps chatty workloads that open many connections.

Azure Monitor gives you platform metrics for free: CPU usage, memory usage and network bytes in and out. You can chart them and attach alert rules to them.

For logs, link the group to a Log Analytics workspace at creation with --log-analytics-workspace and its key. Container output and events then land in the ContainerInstanceLog_CL and ContainerEvent_CL tables.

ContainerInstanceLog_CL
| where ContainerGroup_s == "aci-app"
| where Message contains "ERROR"
| order by TimeGenerated desc
| take 50

Without a workspace, logs only live as long as the group. Set it up before you need it.

An alert on memory usage close to the group's request gives early warning before an out-of-memory kill restarts the container.

You re-deploy with the same group name and an updated definition (az container create, a YAML file, or an ARM/Bicep template). ACI supports updating only a limited set of properties, such as the image or environment variables, and applying the change restarts the containers.

Anything structural, such as the OS type, CPU and memory, or moving to a different network, means deleting and recreating the group.

• There is no rolling update, so expect a short outage.
• For zero downtime, deploy a second group, test it, then switch DNS or the gateway backend.
• Keep the definition in Bicep or YAML so every change is repeatable.

Most of the startup time goes into pulling the image, so the biggest wins come from making that step smaller and closer.

• Shrink the image. Use slim or distroless bases and multi-stage builds, and avoid bundling build tools.
• Keep the registry close. Use ACR in the same region, or geo-replicate it, to cut pull time.
• Prefer Linux. Windows base images are very large and start slower.
• Trim the app start. Lazy-load heavy components and avoid long init work.
• Use standby pools when you need ready-to-go groups for bursts.

Measure with the events timeline from az container show; it separates pull time from container start time.

Because billing is per second on requested resources, cost control is mostly about requesting less and running for less time.

• Right-size CPU and memory using the usage metrics, not guesses.
• Delete or stop groups that are idle; use Never or OnFailure for jobs so they stop on their own.
• Use Spot for interruptible work to save up to 70%.
• Prefer Linux to avoid the Windows software charge.
• Move steady 24/7 workloads to a VM, Container Apps or AKS, where flat or reserved pricing is cheaper.

Also watch the side costs: public IPs, Log Analytics ingestion and Azure Files storage can add up for large fleets.

A public group can have a DNS name label, which becomes label.region.azurecontainer.io. The IP is not guaranteed to be stable: stopping and starting or recreating a group can give it a new address. Clients should use the DNS name, not the IP.

Labels are unique per region. To reduce the risk of someone claiming a name you released (a subdomain takeover), ACI offers a DNS name label reuse policy (dnsNameLabelReusePolicy in ARM/Bicep) with scopes such as tenant, subscription and resource group, or no reuse at all.

• VNet groups get private IPs that can also change after a restart.
• For a stable front door, use Application Gateway, Front Door or a NAT gateway for outbound.

ACI has no built-in scheduler. You set the restart policy to Never (or OnFailure) and trigger creation of the group from something that does schedule.

• Logic Apps with the ACI connector on a recurrence trigger
• Azure Functions with a timer trigger that calls the management API or SDK
• Data Factory or pipelines that start a group as a step
• Event Grid or queue messages for event-driven runs

az container create -g rg-jobs -n nightly-etl \
  --image myregistry.azurecr.io/etl:2.1 \
  --restart-policy Never \
  --assign-identity <identity-resource-id>

Write results to Azure Files or Blob storage, not the container disk. The group stops billing when the process exits, but you should still delete finished groups to keep the resource group tidy.

Security comes from layering several controls rather than one switch:

• Network: deploy into a VNet with no public IP, and control traffic with NSGs. Use Application Gateway for any inbound internet traffic.
• Identity: use managed identities instead of keys, and give them least-privilege roles.
• Secrets: use secure environment variables or secret volumes, and prefer Key Vault fetched at runtime.
• Images: pull from a private registry with a managed identity and scan images for vulnerabilities.
• Data: use customer-managed keys for the data ACI stores, and the Confidential SKU for data-in-use protection.
• Access: restrict who can run az container exec or create groups with Azure RBAC.

A few limits come up in almost every design discussion. Many can be raised with a support request.

You also have regional vCPU quotas per subscription. Always check the region availability page before choosing sizes, since limits are per region and deployments are subject to available capacity.

Quota increases go through a support request in the Azure portal. Even inside your quota, capacity in a region is never guaranteed at the moment you deploy.

A standby pool keeps a set of pre-provisioned container groups ready so a new container can be handed out almost immediately, instead of waiting through scheduling and image pull each time. It is aimed at bursty workloads that need very fast start.

1. Create a container group profile that describes how pooled groups are configured.
2. Create a standby pool that references the profile and a target pool size.
3. Request a container from the pool by referencing the profile and pool when you create a group.

• The pool only hands out groups that are fully provisioned and ready.
• If the pool is empty, ACI falls back to creating a new group normally.
• The refill policy is Always, so the pool is topped up after groups are taken.
• Confidential SKU, managed identity and zones are supported.

Standby pools are for speed, not resilience, and they were in preview when this was written, so check current status.

NGroups is an ACI feature for managing several related container groups as one unit. It brings some of the orchestration that a single group lacks.

• Maintain a desired number of container groups
• Perform rolling upgrades across them
• Spread groups across availability zones
• Place a load balancer in front for ingress
• Deploy confidential containers

It sits between plain ACI and a full cluster: you get replica count, rolling updates and load balancing without running Kubernetes. Like standby pools, it uses container group profiles to describe the group template. The feature was in preview in the docs I checked, so confirm its current status before you commit to it.

Standby pools speed up how fast a group can be created, while NGroups controls how many groups exist and how they are updated. They solve different problems, so decide which one your workload actually needs.

ACI isolates each container group at the hypervisor level. A group runs in its own sandboxed environment, so it does not share a kernel with groups from other customers or other deployments. That is stronger than a typical container host where containers from different apps share the host kernel.

• Between groups: hypervisor-level isolation, plus separate network configuration.
• Inside a group: containers share the network namespace and volumes on purpose, so they are not isolated from each other on the network.
• Extra hardening: the Confidential SKU adds hardware memory encryption, and VNet deployment adds network-level control.

This is why ACI is considered a safe choice for running untrusted or multi-tenant jobs without managing your own node isolation.

Since the isolation boundary is the group, put workloads that must not share a network namespace into separate groups.

ACI has no built-in autoscaling. A group is a fixed size, and scaling out means creating more groups. You scale up by recreating a group with a bigger size.

For queue-driven batch work, a common pattern is one short-lived group per message or batch, which gives you parallelism without managing capacity.

ACI has no built-in ingress, so you add one. The right choice depends on whether the group is public or in a VNet.

• Application Gateway: deploy the group into a VNet and add its private IP as a backend. It gives you TLS termination and a WAF.
• Azure Front Door: use the group's public FQDN as an origin for global routing and caching.
• Traffic Manager: use DNS-based routing across groups in different regions.
• NGroups with a load balancer: spread traffic over several groups.

Watch out for IP changes. A group's private IP can change when it is recreated, so automate updating the gateway backend, or put the stable name in front of the group, whenever you redeploy.

As a rule of thumb, pick Application Gateway when you need a WAF and path-based routing inside one region, and Front Door when you need global reach and edge caching.

ACI has no native Key Vault reference syntax, so the group's own code usually fetches secrets using its managed identity. Give the identity a role like Key Vault Secrets User, then have the app read the secret at startup with the Azure SDK.

sequenceDiagram
    participant App as Container app
    participant IMDS as Token endpoint
    participant AAD as Microsoft Entra ID
    participant KV as Key Vault
    App->>IMDS: Request token for vault.azure.net
    IMDS->>AAD: Authenticate managed identity
    AAD-->>App: Access token
    App->>KV: Get secret with token
    KV-->>App: Secret value

The alternative is to resolve the secret in your pipeline and inject it as a secure environment variable or secret volume. That is simpler but puts the value in the deployment, so the runtime fetch is the stronger option.

Cache the secret in memory and refresh it on a schedule instead of calling Key Vault on every request. Also scope the role so the identity can read only the secrets it needs, not the whole vault.

A group moves through a small set of states, and the restart policy decides what happens when its containers exit.

flowchart TD
    A[Create] --> B["Pending: scheduling and image pull"]
    B --> C[Running]
    C -->|Policy Always| C
    C -->|Exit 0 with Never or OnFailure| D[Succeeded]
    C -->|Non-zero exit with Never| E[Failed]
    C -->|az container stop| F[Stopped]
    F -->|az container start| B
    D --> G[Delete]
    E --> G
    F --> G

• Pending: ACI schedules the group, sets up networking and pulls images. Billing begins with the pull.
• Running: containers are up; each has its own state of Waiting, Running or Terminated.
• Succeeded or Failed: reached when a run-to-completion group finishes.
• Stopped: compute released, no billing, definition kept.
• Deleted: the resource is removed.

Container-level states are tracked separately from the group state. Each container reports Waiting while its image is pulled or a restart is pending, Running while the process is alive, and Terminated with an exit code once it stops. With the Always policy a terminated container goes straight back to Waiting, which is why a crashing app shows a rising restart count instead of a Failed group.

Deploying a group is an Azure Resource Manager operation followed by scheduling, networking, image pulls and container start.

flowchart TD
    A["az container create or Bicep"] --> B["ARM validates request and quota"]
    B --> C["ACI scheduler picks a host with capacity"]
    C --> D["Network set up: public IP or VNet private IP"]
    D --> E["Volumes mounted: Azure Files, secret, emptyDir"]
    E --> F["Images pulled from the registry"]
    F --> G["Init containers run in order"]
    G --> H["Application containers start"]
    H --> I["Probes run and the group reports Running"]

1. ARM checks the request, permissions and quota.
2. The scheduler places the group on a host in the region.
3. Network and volumes are attached, then images are pulled with the supplied credentials.
4. Init containers run to completion, then the app containers start.

Failures at each step have distinct symptoms: quota or capacity errors fail early, pull errors leave containers in Waiting, and crashes show up as restarts after start.

Because billing starts with the image pull, a slow pull costs money as well as time. If the group sits in Pending for a long time, look at the events first, since they show whether the delay is scheduling, the registry, or an init container that never finishes.

There are two different problems that look similar. A quota error means your subscription is out of allowance. A capacity error, often a ServiceUnavailable message saying the resources are not available in the location, means the region cannot fit your request right now.

1. Read the full error to see which of the two it is, and which resource (CPU, memory, GPU) is named.
2. Check regional vCPU usage in the portal under Usage + quotas and request an increase if you are at the limit.
3. Reduce the request: a smaller CPU and memory combination is easier to place.
4. Retry in another region, or in another availability zone setting if you use zones.
5. Check the hard limits: 60 containers and 20 volumes per group, and creation rate limits of 300 per hour and 100 per 5 minutes.

If you create many groups, add retry with backoff in your automation, and consider NGroups or standby pools so capacity is requested in a more controlled way.

Declare the group as a Microsoft.ContainerInstance/containerGroups resource and deploy it with az deployment group create. Bicep keeps the definition in source control, so every change is reviewed and repeatable, which matters because ACI cannot be edited freely in place.

param location string = resourceGroup().location

resource aci 'Microsoft.ContainerInstance/containerGroups@2023-05-01' = {
  name: 'aci-bicep-demo'
  location: location
  properties: {
    osType: 'Linux'
    restartPolicy: 'Always'
    containers: [
      {
        name: 'web'
        properties: {
          image: 'mcr.microsoft.com/azuredocs/aci-helloworld'
          ports: [ { port: 80 } ]
          resources: { requests: { cpu: 1, memoryInGB: 2 } }
        }
      }
    ]
    ipAddress: {
      type: 'Public'
      ports: [ { protocol: 'TCP', port: 80 } ]
      dnsNameLabel: 'aci-bicep-demo-12345'
    }
  }
}

az deployment group create -g rg-aci-demo --template-file aci.bicep

Use parameters for image tag and secrets, and run the deployment from a pipeline with a managed identity or service principal.