Azure Container Apps Config & Scaling Review Prompt
Review an Azure Container Apps configuration for scaling rules, ingress, secrets, and revision strategy, then propose a reliable, cost-aware setup with safe rollout.
- Target user
- Platform and application engineers running Azure Container Apps
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior platform engineer who runs production workloads on Azure Container Apps. You reason about KEDA scale rules, ingress, revisions, and managed identity — and you know scale-to-zero is a feature, not always a default you want. I will provide: - The app config — the Container Apps resource, container spec, resources (CPU/memory), and environment — [APP_CONFIG] - Scaling rules — min/max replicas and the KEDA scalers in use (HTTP, queue length, CPU, cron) — [SCALING] - Ingress — external/internal, target port, traffic-split across revisions — [INGRESS] - How it gets secrets and auth — Container Apps secrets, Key Vault refs, managed identity — [SECRETS_AUTH] - Revision/deploy strategy — single vs multiple revisions, how new versions roll out — [REVISIONS] - The pain — cold starts, cost, scaling lag, failed deploys — [PAIN_POINTS] Your job: 1. **Scaling correctness** — match the scaler to the workload. HTTP scaler for sync APIs, queue-length (Service Bus/Storage Queue) for workers, cron for scheduled. Flag min-replicas=0 on a latency-sensitive API (cold start) and recommend min=1 there; flag a high min that wastes money on bursty workers. 2. **Resource sizing** — sanity-check CPU/memory against the workload and the allowed CPU/memory combinations; flag requests that will be throttled or OOM-killed. 3. **Ingress & traffic** — confirm external vs internal is correct for the exposure intended, the target port matches the container, and traffic-split percentages are deliberate. 4. **Secrets & identity** — recommend Key Vault references via managed identity over inline secrets, and least-privilege roles for what the app calls. 5. **Safe rollout** — recommend multiple-revision mode with a traffic-split canary (e.g. 10% to the new revision) over a single-revision swap for risky changes, and how to roll back by shifting traffic. Output as: (a) findings table — area, current, issue, recommendation; (b) the corrected `az containerapp update` / YAML; (c) the scale-rule definition; (d) a canary rollout + rollback plan. Use only the config and pain points I gave you. Don't assume scalers, secrets, or revision modes that aren't shown — ask.
Why this prompt works
Azure Container Apps abstracts away a lot of Kubernetes, but it introduces its own sharp edges — chiefly KEDA scale rules and the scale-to-zero default. Teams reach for Container Apps expecting serverless simplicity, then get paged for cold-start latency because a customer-facing API was left at min-replicas=0, or burn money because a bursty queue worker was pinned to a high minimum. This prompt anchors the review on matching the scaler to the workload and choosing the right minimum replica count, which is where most Container Apps configurations go wrong in practice.
The review is grounded in the platform’s real constraints rather than generic container advice. Container Apps only allows specific CPU and memory combinations, secrets are best supplied as Key Vault references through managed identity rather than inline values, and the revision model is the safety mechanism for rollouts. By asking for the actual scalers, ingress mode, and revision strategy, the prompt produces fixes tied to your configuration — the correct scale rule definition, the right ingress exposure, and a deliberate traffic split — instead of restating documentation.
The guardrails target the two decisions that quietly cause incidents: scaling a latency-sensitive app to zero, and swapping a single revision in one shot. Both are defaults that feel fine until production traffic hits them. By requiring cold-start load testing before relying on scale-to-zero and a canary traffic split with verification before a full cutover, the prompt keeps the configuration both cost-aware and safe, with every risky change observable and reversible before it owns all the traffic.