3.2.1. Azure Container Apps: Environments and Revisions
💡 First Principle: ACA splits your app's definition into two scopes with opposite update semantics: revision-scope properties (image, env vars, scale rules) define what a snapshot is, so changing them mints a new revision; application-scope properties (secrets, ingress) are shared plumbing, so changing them updates in place — and running revisions don't see new secret values until restarted. Most ACA exam traps are this one distinction in costume.
A Container Apps environment is the isolation boundary: apps in one environment share a virtual network and a Log Analytics workspace (which 3.2.4 queries), making it the natural home for one AI solution's microservices — API, embedding worker, semantic-cache warmer — that need to talk privately.
Within an app, the scope split drives everything:
| Revision-scope | Application-scope | |
|---|---|---|
| Examples | Container image, env vars, CPU/memory, scale rules | Secrets, ingress config, Dapr settings |
| On change | New revision created | Updated in place, no new revision |
| Consequence | Old revision keeps running until traffic shifts | Running revisions need restart to see new secrets |
Revision modes determine how many snapshots serve traffic. Single mode (default) auto-shifts all traffic to each new revision — simple promotion. Multiple mode keeps several revisions live with percentage traffic splitting — the mechanism for canary and blue-green:
For AI solutions this is more than deployment hygiene: a new model version or prompt template can be behaviorally wrong while operationally healthy, so a 10% canary with quality monitoring is the responsible rollout — and because old revisions remain intact, rollback is a traffic-weight change, not a redeploy.
Ingress config (application-scope) sets external vs. internal exposure and target port — ACA's equivalent of the WEBSITES_PORT contract from 3.1.3.
⚠️ Exam Trap: "We updated the API key secret, why do the apps still use the old one?" — because secrets are application-scope: no new revision, no automatic restart. Restart the revisions (or deploy a new revision) to pick up changed secret values. Any answer claiming the secret change "creates a new revision automatically" is the planted distractor.
A few operational specifics round out revisions. Revision names append a suffix to the app name (rag-api--v15), and you manage them with az containerapp revision list, deactivate, and activate — deactivated revisions keep their definition but hold no replicas, making reactivation cheap. Traffic weights can also target revision labels (e.g., blue/green) instead of raw names, so promotion scripts swap labels rather than editing weights per revision name. In multiple mode, keep an eye on revision sprawl: every revision-scope change mints another entry, and platforms cap active revisions — deactivate what canaries no longer need.
Reflection Question: Why does making revisions immutable enable instant rollback — and what does that imply about where mutable state (like secrets) can live?
