Cloud / Azure Container Apps (ACA) Interview questions

Azure Container Apps (ACA) is a fully managed, serverless container platform on Azure. You give it a container image, and it runs, scales and exposes that image for you. You never create or operate a Kubernetes cluster.

It runs on Kubernetes underneath, but that layer is hidden. You work with apps, revisions and environments instead of pods, nodes and manifests. It also bundles open-source pieces: KEDA for event-driven scaling, Dapr for microservice building blocks and Envoy for ingress.

Typical workloads are HTTP APIs, microservices, background workers, event processors and scheduled jobs. Any language works as long as it ships as a Linux container.

ACA suits containerized workloads where you want Kubernetes-style scaling without running Kubernetes. The usual cases:

• Public APIs and web apps that scale with traffic.
• Microservices that call each other inside one environment, often with Dapr.
• Event-driven processors that scale on queue length or Event Hubs lag, down to zero.
• Background workers that run continuously with no ingress.
• Jobs for ETL, batch runs, migrations and scheduled tasks.
• GPU and sandboxed workloads such as model inference or running untrusted code in dynamic sessions.

It is a weaker fit when you need custom operators, CRDs, privileged containers or direct control of the cluster. AKS is the better home for those.

A Container Apps environment is the secure boundary around a group of apps and jobs. Everything inside shares a virtual network and a logging destination (usually a Log Analytics workspace), and apps can reach each other by name over internal networking.

You create the environment first and then deploy apps into it. It is also where shared settings live: workload profiles, Dapr components, Azure Files storage definitions and VNet integration.

Use separate environments when you need network isolation or different lifecycles, for example dev, test and prod.

az containerapp env create --name my-env --resource-group my-rg --location eastus

A revision is an immutable snapshot of one version of a container app. It records the image, environment variables, CPU and memory, scale rules and the other settings in the app's template section.

A new revision is created when you change a revision-scope setting, such as the image tag or a scale rule. Application-scope changes, like ingress, secrets, registry credentials and Dapr settings, update the app without creating one.

Revision names look like myapp--v2, and you can pick the suffix with --revision-suffix. Revisions are what you roll back to or split traffic between.

A replica is one running instance of a revision. It works like a Kubernetes pod: it holds your main container plus any sidecar and init containers, and they share the same network and volumes.

The platform adds and removes replicas based on your scale rules. The minimum defaults to 0, the maximum defaults to 10, and the maximum can be raised (up to 1,000 at the time of writing).

CPU and memory are set per container, but the total across a replica must fit the limits of the workload profile. Requests are load-balanced across the ready replicas of a revision.

A workload profile decides what compute your apps run on. ACA has three types: Consumption, Dedicated and Flex. Flex was still in preview when this was written, so check its status before relying on it.

Every environment starts with a default Consumption profile, and you can add others next to it.

The Consumption plan is the serverless default. The platform decides where replicas run, and you pay only for what they use. Apps can scale to zero, so an idle app costs nothing for compute.

A single replica can use up to 4 vCPU and 8 GiB of memory at the time of writing. Billing is by vCPU-seconds and GiB-seconds, plus a charge per million requests, with a monthly free grant per subscription.

Pick it for spiky APIs, event handlers and jobs. If you need bigger replicas, special hardware or steady high utilization, look at Dedicated profiles.

Scale to zero means ACA drops a revision to 0 replicas when no scale rule has work to do, so the app uses no compute and has no active charges. It applies when minReplicas is 0.

When a request or event arrives, the platform starts a replica again. That first request pays a cold start: image pull (if not cached), container start and app initialization.

Only rules that can detect work while nothing is running can scale from zero: HTTP, TCP and event-driven (KEDA) rules. CPU and memory rules can't, because there is no replica to measure.

az containerapp update -n myapp -g my-rg --min-replicas 0 --max-replicas 5

KEDA (Kubernetes Event-driven Autoscaling) is the open-source scaler behind ACA's scale rules. You never install or run it. You describe a rule, and ACA configures KEDA for you.

A KEDA scaler watches an external source such as Service Bus, Storage queues, Event Hubs, Kafka or a cron schedule, and reports a metric. The platform turns that metric into a replica count between your min and max.

HTTP, TCP, CPU and memory rules are built in. Anything else is a custom rule, where you give the KEDA scaler type, its metadata and how to authenticate.

Dapr (Distributed Application Runtime) is an open-source runtime that offers microservice building blocks through a sidecar. Your app calls it over HTTP or gRPC on localhost, and ACA lets you turn it on per app.

The building blocks include service invocation, pub/sub, state management, bindings, secrets and actors. Your code calls localhost:3500 and Dapr talks to the real backing service, so you can swap Redis for Cosmos DB through configuration instead of code changes.

Enable it with an app-id and app-port, and define the components at the environment level.

az containerapp create -n orders -g my-rg --environment my-env \
  --image myacr.azurecr.io/orders:1.0 \
  --enable-dapr --dapr-app-id orders --dapr-app-port 8080

A Container Apps job runs a containerized task that starts, does its work and exits. It does not stay up like a service. Each run is called an execution.

Jobs have no ingress and don't serve requests. You pay only while an execution is running, which suits batch processing, ETL, database migrations, report generation and queue-draining tasks.

The settings that matter are parallelism (replicas running at once), replicaCompletionCount, replicaTimeout and replicaRetryLimit.

A job starts in one of three ways:

The cron expression is evaluated in UTC, so convert your local time before you set it.

Add the extension, register the providers once, create an environment, then create the app. The shortest working path looks like this:

az extension add --name containerapp --upgrade
az provider register --namespace Microsoft.App
az provider register --namespace Microsoft.OperationalInsights

az containerapp env create -n my-env -g my-rg -l eastus

az containerapp create -n myapp -g my-rg --environment my-env \
  --image mcr.microsoft.com/k8se/quickstart:latest \
  --target-port 80 --ingress external

The command prints the app's FQDN when it finishes. If you have source code and no image yet, az containerapp up --source . builds it, pushes it to a registry and deploys in one step.

Ingress gives a container app an HTTPS endpoint so clients can reach it without you setting up load balancers or certificates. ACA terminates TLS and routes requests to replicas through an Envoy proxy.

You enable it and set a target port, which is the port your container listens on. Visibility is either external (reachable from outside the environment) or internal (reachable only by other apps in the same environment).

The app gets an FQDN such as myapp.<unique-id>.<region>.azurecontainerapps.io. Ingress also provides traffic splitting, IP restrictions, CORS, sticky sessions and client certificate options.

Ingress supports HTTP/1.1, HTTP/2 (which carries gRPC) and TCP. WebSockets work over HTTP/1.1.

The --transport setting picks the mode: auto (the default), http, http2 or tcp. With auto, ACA negotiates HTTP/1 or HTTP/2 per request.

HTTP ingress terminates TLS at the edge and forwards plain HTTP to your container. TCP ingress is for non-HTTP protocols and has extra restrictions, so check the current docs for environment requirements. UDP is not supported.

Secrets hold sensitive values such as connection strings or API keys at the app level, apart from the image and the code. They are stored encrypted and referenced by name.

Containers use them in two ways: as an environment variable through secretref:, or as files in a mounted volume. Scale rules can also reference them to authenticate.

az containerapp secret set -n myapp -g my-rg --secrets db-pass=S3cret
az containerapp update -n myapp -g my-rg --set-env-vars "DB_PASSWORD=secretref:db-pass"

Changing a secret is an application-scope change. It doesn't create a revision, and running replicas keep the old value until the revision restarts. For stricter control, use a Key Vault reference instead.

Set them on the container in the app template, using the CLI, a YAML file, Bicep or the portal. A plain value is name=value. A secret is name=secretref:secret-name.

az containerapp update -n myapp -g my-rg \
  --set-env-vars "ASPNETCORE_ENVIRONMENT=Production" "API_KEY=secretref:api-key"

Environment variables belong to the revision template, so changing one creates a new revision. Use --replace-env-vars to overwrite the full set and --remove-env-vars to delete specific ones.

ACA also injects a few variables of its own, such as CONTAINER_APP_NAME and CONTAINER_APP_REVISION.

Both are extra containers that run inside the same replica as your main container and share its network and volumes. The difference is when they run.

Dapr is a separate platform-managed sidecar. You don't define it as a container yourself.

A managed identity gives your app a Microsoft Entra ID identity with no credentials in code or config. It is either system-assigned (tied to the app's lifecycle) or user-assigned (a separate resource you can reuse across apps).

Common uses are pulling images from ACR, reading Key Vault secrets, and calling Storage, Service Bus or SQL with Entra authentication. Some scale rules can use it too.

In code, an SDK credential such as DefaultAzureCredential picks it up. You still have to grant the identity an RBAC role on the target resource.

az containerapp identity assign -n myapp -g my-rg --system-assigned

The recommended way is identity-based pull. Give the app a managed identity that has the AcrPull role on the registry, then point the registry setting at that identity. No admin password is involved.

az identity create -n aca-pull-id -g my-rg
az role assignment create --assignee <principal-id> --role AcrPull --scope <acr-id>

az containerapp create -n myapp -g my-rg --environment my-env \
  --image myacr.azurecr.io/api:1.0 \
  --user-assigned <identity-resource-id> \
  --registry-server myacr.azurecr.io \
  --registry-identity <identity-resource-id>

A user-assigned identity avoids a chicken-and-egg problem. With a system-assigned one, the app must exist before you can grant the role, but it can't start until the role exists. The fallbacks are ACR admin credentials or a username and password stored as a secret.

On the Consumption plan you pay for vCPU-seconds and GiB-seconds used by replicas, plus the number of HTTP requests.

Replicas bill in two states. Active replicas, which are starting or handling requests, are charged at the full rate. Idle replicas, kept alive by a minimum replica count but not busy, are charged at a lower rate. Replicas at zero cost nothing.

Each subscription gets a monthly free grant (180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests at the time of writing, so confirm on the pricing page).

Dedicated profiles bill per node instance-hour plus a plan management fee, no matter how many apps share the node. Jobs bill only for execution time.

Console output (stdout and stderr) and platform events go to the environment's logging destination, usually a Log Analytics workspace. App output lands in ContainerAppConsoleLogs_CL. Platform events such as scaling, image pulls and crashes land in ContainerAppSystemLogs_CL.

ContainerAppConsoleLogs_CL
| where ContainerAppName_s == "myapp"
| order by TimeGenerated desc
| take 50

For quick checks, stream logs from the CLI or open Log stream in the portal. az containerapp exec opens a shell in a running replica.

az containerapp logs show -n myapp -g my-rg --follow

If you chose resource-specific tables, the names drop the _CL suffix.

Both run containers on Kubernetes. The difference is how much of Kubernetes you get to touch. ACA hides it and gives you an app-level model. AKS gives you the whole cluster and the work that comes with it.

Pick ACA when the team wants to ship containers, not run clusters. Pick AKS when you need operators, DaemonSets, a specific service mesh or custom networking.

ACI runs a container group on demand with no orchestration around it. ACA is an application platform with scaling, revisions, ingress, Dapr and jobs.

For a short job with no scaling needs, ACI works. If the task is recurring or event-driven, an ACA job is usually the neater choice.

Azure Functions gives you a trigger-and-binding programming model, and you write small functions. ACA runs whole containers, so any runtime, any web server, multiple containers per replica and long-running processes are fair game.

Choose Functions for small event-triggered code that benefits from bindings, such as a blob-triggered resize or a timer that posts a report.

Choose ACA when you need a custom runtime or a multi-container design, long-running or CPU-heavy services, Dapr, or one platform for APIs, workers and jobs together.

The two also combine. You can host Azure Functions on ACA and get KEDA-based scaling and the same environment networking.

One environment can hold both, and you attach each app to a profile with --workload-profile-name. Steady, heavy workloads often get cheaper on Dedicated, since many apps share the same paid-for node.

az containerapp env workload-profile add -n my-env -g my-rg \
  --workload-profile-name d4 --workload-profile-type D4 \
  --min-nodes 1 --max-nodes 3

The mode decides how many revisions of an app can be active at once.

Single is the default. In multiple mode, every active revision keeps its replicas running, so it can raise cost. Set the weights explicitly so you know where traffic is going.

az containerapp revision set-mode -n myapp -g my-rg --mode multiple

ACA scales the replicas of each revision between minReplicas and maxReplicas, driven by scale rules. If you define none, an HTTP rule is applied by default.

Rule types: HTTP (concurrent requests per replica), TCP (concurrent connections), CPU and memory utilization, and custom KEDA scalers. The desired count is roughly the metric divided by your target, rounded up. If several rules are active, the one asking for the most replicas wins.

Event-driven rules poll every 30 seconds by default, and there is a 300-second cooldown before scaling in to zero.

flowchart LR
  A["Metric source: requests, queue, CPU"] --> B["KEDA evaluates scale rules"]
  B --> C{Desired count vs min and max}
  C -- higher --> D["Add replicas"]
  C -- lower --> E["Remove replicas after cooldown"]
  C -- no work and min is 0 --> F["Scale to zero"]

Example: 50 concurrent requests with a target of 10 per replica gives 5 replicas.

Add a custom scale rule using the azure-servicebus KEDA scaler. Give it the queue name, a target message count per replica, and a way to authenticate.

az containerapp create -n worker -g my-rg --environment my-env \
  --image myacr.azurecr.io/worker:1.0 \
  --min-replicas 0 --max-replicas 20 \
  --secrets sb-conn=&quot;<service-bus-connection-string>&quot; \
  --scale-rule-name sb-rule \
  --scale-rule-type azure-servicebus \
  --scale-rule-metadata queueName=orders messageCount=5 \
  --scale-rule-auth connection=sb-conn

messageCount=5 means each replica is expected to handle about 5 queued messages. With 100 messages waiting, ACA aims for 20 replicas, capped by the maximum. When the queue is empty and min-replicas is 0, the app scales to zero.

Where the scaler supports it, prefer managed identity over a connection string so there is no secret to rotate.

The usual reason is that something in the config keeps at least one replica alive. Check these in order:

1. minReplicas is 1 or more. Confirm with az containerapp show --query properties.template.scale.
2. A CPU or memory rule is configured. Those can't scale from zero and require at least one replica.
3. The scale metric never drops. A queue that never empties, or WebSocket and long-lived connections that keep concurrent requests above zero.
4. The cooldown hasn't passed. The default is 300 seconds after the last activity.
5. The scaler is failing. Bad credentials or a wrong queue name can leave the metric stuck. Look in the system logs.

Fix the cause, and the next cooldown window should bring the replica count down to zero.

In multiple revision mode, ingress sends each request to a revision according to weights that must add up to 100. This is how you run canary, blue-green and A/B tests.

az containerapp ingress traffic set -n myapp -g my-rg \
  --revision-weight myapp--v1=80 myapp--v2=20

The same thing in YAML:

ingress:
  traffic:
    - revisionName: myapp--v1
      weight: 80
    - revisionName: myapp--v2
      weight: 20

Splitting is random per request, so one user may hit both versions. Turn on session affinity to keep a client on the same replica with a cookie. To roll back, set the old revision's weight to 100.

Use multiple revision mode and revision labels. A label gives a revision its own stable URL, so you can test it before it gets any production traffic.

1. Switch the app to multiple revision mode and label the current revision blue.
2. Deploy the new version as a revision with a clear suffix and label it green, with 0% traffic.
3. Test it on the label URL, which has the form <app>---green.<env-domain>.
4. Move the weights to green once you're happy.
5. Keep blue around for a quick rollback, then deactivate it.

az containerapp revision set-mode -n myapp -g my-rg --mode multiple
az containerapp revision label add -n myapp -g my-rg --label blue --revision myapp--blue
az containerapp update -n myapp -g my-rg --image myacr.azurecr.io/api:2.0 --revision-suffix green
az containerapp revision label add -n myapp -g my-rg --label green --revision myapp--green
az containerapp ingress traffic set -n myapp -g my-rg --label-weight blue=0 green=100

A revision is created when you change something in the app's template, such as the image or a scale rule. From there it moves through a few stages.

flowchart LR
  A["Template change"] --> B["Revision created: Provisioning"]
  B --> C["Image pulled and replicas start"]
  C --> D{Probes pass?}
  D -- Yes --> E["Provisioned and Running"]
  D -- No --> F["Failed or Degraded"]
  E --> G["Receives traffic and scales"]
  G --> H["Replaced by newer revision"]
  H --> I[Inactive]

In single revision mode, the new revision takes all traffic only once it is healthy, and the old one is then deactivated automatically. In multiple mode you deactivate revisions yourself.

An inactive revision has no replicas and costs no compute, but it can be reactivated. ACA keeps a limited history of inactive revisions (100 by default, configurable), and the oldest are purged. You can also manage them with az containerapp revision activate, deactivate and restart.

By default an environment uses a platform-managed network. To control it, you bring your own subnet when you create the environment. The VNet can't be swapped afterwards.

A workload profiles environment needs a subnet of at least /27, delegated to Microsoft.App/environments. The older consumption-only environment needed /23.

Once the environment is in your VNet, you can apply NSGs, route egress through a firewall or NAT gateway with user-defined routes, reach private resources like databases, and make the environment internal-only.

az containerapp env create -n my-env -g my-rg -l eastus \
  --infrastructure-subnet-resource-id <subnet-id> \
  --internal-only true

Both types are built on your VNet. Note that this is separate from per-app ingress visibility. In an external environment, an app can still use internal ingress and stay hidden from the internet.

Apps in the same environment can call each other over internal networking. If the target app has ingress enabled, the caller can use its app name, such as http://orders, or the internal FQDN. Internal ingress keeps the target off the internet.

With Dapr enabled, you can use service invocation instead. The call goes through two sidecars, which adds retries, mTLS and tracing.

GET http://localhost:3500/v1.0/invoke/orders/method/api/orders/42

sequenceDiagram
  participant F as Frontend app
  participant FD as Dapr sidecar
  participant OD as Orders sidecar
  participant O as Orders app
  F->>FD: invoke orders method api/orders/42
  FD->>OD: mTLS call with retries
  OD->>O: forward request
  O-->>F: response via both sidecars

Plain name-based calls are simpler. Choose Dapr when you want built-in retries and tracing without writing them yourself.

Combine layers, from the app outward:

1. Ingress visibility. Use internal ingress so only apps in the environment can call it.
2. IP restrictions. Allow or deny specific CIDR ranges on the ingress.
3. Private environment. Use an internal environment or private endpoint, and put Application Gateway or Front Door with a WAF in front.
4. Authentication. Turn on built-in auth so only signed-in users reach the app.
5. Client certificates. Require or accept client certs for mutual TLS.
6. NSGs on the environment's subnet for network-level filtering.

az containerapp ingress access-restriction set -n myapp -g my-rg \
  --rule-name office --ip-address 203.0.113.0/24 --action Allow

Built-in authentication (often called Easy Auth) puts an auth layer in front of your app, so your code doesn't implement OAuth itself. It supports Microsoft Entra ID, Google, GitHub, Facebook, Apple, X and any OpenID Connect provider.

sequenceDiagram
  participant B as Browser
  participant A as Auth layer
  participant I as Identity provider
  participant P as Your app
  B->>A: request without session
  A->>B: redirect to login
  B->>I: sign in
  I->>A: token
  A->>A: validate and create session
  B->>A: request with session cookie
  A->>P: forward with identity headers

Your app receives the user's details in headers such as X-MS-CLIENT-PRINCIPAL and X-MS-CLIENT-PRINCIPAL-NAME.

For unauthenticated requests you pick an action: allow them, redirect to login (best for browser apps), or return 401 or 403 (best for APIs). Treat the headers as trusted only when the app can't be reached except through the auth layer.

Instead of copying a secret value into ACA, you store a reference to the Key Vault secret URI and give the app a managed identity that can read it. ACA fetches the value for the app, so the secret lives in one place.

az containerapp secret set -n myapp -g my-rg \
  --secrets &quot;db-pass=keyvaultref:https://myvault.vault.azure.net/secrets/db-pass,identityref:<identity-resource-id>&quot;

The identity needs read access to secrets, for example the Key Vault Secrets User role. If the vault has a firewall, the app's network path must be allowed.

A reference without a version tracks the latest version, but running replicas read the value at start. After you rotate a secret, restart the revision so replicas see the new value.

ACA supports three probe types, over HTTP or TCP. Exec probes aren't supported. What happens on failure depends on the type:

If ingress is on and you define no probes, ACA applies default TCP probes against the target port.

probes:
  - type: Liveness
    httpGet:
      path: /healthz
      port: 8080
    initialDelaySeconds: 5
    periodSeconds: 10
    failureThreshold: 3

Start with the system logs, since they say why a replica was restarted, then match the symptom to a cause.

az containerapp logs show -n myapp -g my-rg --type system --follow

If the cause is still unclear, run the image locally with the same environment variables, or open a shell with az containerapp exec.

A 502 or 504 means ingress couldn't get a good answer from a replica. Common causes:

• Wrong target port. The container listens on a different port than the ingress setting.
• Listening on localhost. The app binds to 127.0.0.1 instead of 0.0.0.0, so the proxy can't reach it.
• No ready replica. Readiness probes fail, or the app scaled from zero and is still starting.
• Request too long. Ingress times out after about 240 seconds (4 minutes). Move long work to a background job or return a status URL.
• Crash under load. Memory limits or an unhandled exception restart replicas mid-request.

Check the system logs for probe and restart events, then the console logs for the app's own errors. Compare a request through the public URL with a call from another app in the environment to see whether the problem is the ingress or the app.

A cold start is the delay when a replica starts from zero. It has three parts: pulling the image, starting the container and your app's own initialization.

Measure it first. The gap between the replica-created and app-listening events in the system logs shows which part dominates.

Most savings come from not paying for idle capacity.

1. Scale to zero where a cold start is acceptable. Keep minimum replicas for latency-critical apps only.
2. Right-size CPU and memory from observed usage, not guesses.
3. Set a sensible max replicas so a bad scale rule can't run up the bill.
4. Use jobs for batch work instead of an always-on app.
5. Consolidate on a Dedicated profile when many apps carry steady load, so they share nodes you already pay for.
6. Watch logging cost. Log Analytics ingestion is often a big line item. Trim noisy logs and retention.
7. Use the free grant for small dev and test environments.

Review the actual bill before and after each change. Check whether any commitment discounts apply to your plan type.

Three pieces: turn Dapr on for each app, define the pub/sub component once on the environment, and publish or subscribe through the sidecar.

Component definition, scoped to the apps that may use it:

componentType: pubsub.azure.servicebus.topics
version: v1
metadata:
  - name: namespaceName
    value: "mybus.servicebus.windows.net"
  - name: azureClientId
    value: &quot;<identity-client-id>&quot;
scopes:
  - orders
  - inventory

az containerapp env dapr-component set -n my-env -g my-rg \
  --dapr-component-name pubsub --yaml pubsub.yaml

The publisher then posts to http://localhost:3500/v1.0/publish/pubsub/orders. The subscriber exposes a /dapr/subscribe endpoint (or uses a declarative subscription) and receives messages as HTTP calls. Swapping Service Bus for another broker means changing the component file, not the app.

Dynamic sessions give you fast, isolated sandboxes on demand, which is handy for running untrusted code such as LLM-generated Python. Each session runs in its own Hyper-V sandbox, separate from every other session.

You create a session pool, which keeps ready sessions warm. Your app calls the pool's management endpoint with a session identifier. The same identifier always maps to the same session, so state is kept between calls. After an idle cooldown period, the session is destroyed.

There are two session types: code interpreter (Python or Node.js, managed by the platform) and custom container (your own image).

sequenceDiagram
  participant App as Your app
  participant Pool as Session pool endpoint
  participant S as Isolated session
  App->>Pool: execute code, session id u123
  Pool->>S: allocate ready session or reuse u123
  S-->>App: result
  Note over S: idle past cooldown, session destroyed

The common pattern: build an image, push it to a registry, then update the app, which creates a new revision. GitHub Actions is the easiest route.

name: deploy
on:
  push:
    branches: [main]
permissions:
  id-token: write
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - uses: azure/container-apps-deploy-action@v2
        with:
          appSourcePath: ${{ github.workspace }}
          acrName: myacr
          containerAppName: myapp
          resourceGroup: my-rg

Use OIDC federated credentials with azure/login so no long-lived secret is stored in GitHub. Set --revision-suffix to the commit SHA for easy tracing.

Azure Pipelines has an AzureContainerApps task, and az containerapp github-action add can generate a starter workflow. Keep the app definition itself in Bicep or Terraform.

ACA supports four volume types:

For Azure Files, first register the share on the environment, then reference it from the app:

az containerapp env storage set -n my-env -g my-rg \
  --storage-name myfiles --azure-file-account-name mystg \
  --azure-file-account-key <key> --azure-file-share-name share1 \
  --access-mode ReadWrite

template:
  containers:
    - name: app
      volumeMounts:
        - volumeName: files
          mountPath: /data
  volumes:
    - name: files
      storageType: AzureFile
      storageName: myfiles

ACA runs on Kubernetes clusters that Microsoft owns and operates. You never see them. You talk to the Microsoft.App resource provider, and the platform turns your app definition into workloads on those clusters.

• Control plane: stores apps, revisions and settings, and creates replicas for each revision.
• Envoy-based ingress: terminates TLS and routes requests, applying traffic weights and IP rules.
• KEDA: reads scale rules and decides how many replicas each revision needs.
• Dapr: an optional sidecar injected into replicas of apps that enable it.
• Logging and metrics agents: send console and system logs to your destination.

flowchart LR
  C[Client] --> E["Envoy ingress"]
  E --> R1["Replica 1"]
  E --> R2["Replica 2"]
  K["KEDA scaler"] -- sets replica count --> R1
  M["Metrics and event sources"] --> K
  CP["Control plane"] -- creates revisions and replicas --> R1
  R1 --> L["Logs to Log Analytics"]

The practical consequence is that you can't reach the Kubernetes API or install custom controllers. In return you skip node patching, upgrades and capacity planning.

ACA offers two GPU options through workload profiles. GPU types and regions change, so check the current list before you plan.

• Serverless GPU (Consumption GPU profiles): NVIDIA T4 or A100 options, scale to zero, per-second billing, managed drivers.
• Dedicated GPU profiles: NC-series VMs for sustained use. This type can only be added when the environment is first created.

1. Request GPU quota in your region.
2. Add a GPU workload profile to the environment.
3. Deploy the app and assign it to that profile.

az containerapp env workload-profile add -n my-env -g my-rg \
  --workload-profile-name gpu \
  --workload-profile-type Consumption-GPU-NC24-A100

az containerapp create -n infer -g my-rg --environment my-env \
  --image myacr.azurecr.io/infer:1.0 \
  --workload-profile-name gpu

The first request after scaling from zero is slow, because a new replica must pull a large image and load model weights. Keep one replica warm if latency matters, or mount weights from Azure Files instead of baking them into the image.