Common Anti-Patterns¶

This quick-reference guide lists frequent Azure Container Apps anti-patterns seen in production, why they fail, and what to do instead. Use it as a pre-deployment review checklist and incident prevention reference.

Why This Matters¶

Production Container Apps behavior depends on explicit platform choices for ingress, scale, identity, observability, and release safety. This page turns the cited Microsoft Learn guidance into reviewable practices that can be checked before promotion.

Prerequisites¶

• Azure Container Apps environment and at least one deployed app
• Azure CLI with Container Apps extension
• Access to ACR, Log Analytics, and app configuration

export RG="rg-aca-prod"
export APP_NAME="ca-orders-api"
export ACA_ENV_NAME="cae-prod-shared"
export ACR_NAME="acrsharedprod"
export LOCATION="koreacentral"

az extension add --name "containerapp" --upgrade
az account show --output table

Recommended Practices¶

Anti-pattern quick reference table¶

1) Using :latest image tag in production¶

latest breaks revision traceability because the same tag can point to different image contents over time.

Bad pattern:

az containerapp update \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --image "$ACR_NAME.azurecr.io/orders-api:latest"

Better pattern:

az containerapp update \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --image "$ACR_NAME.azurecr.io/orders-api:v1.9.4"

2) Fat container images larger than 1 GB¶

Large images increase pull duration and make scale-from-zero slower.

Operational impact:

• Longer revision provisioning windows
• Higher failure probability during pull/network pressure
• Increased registry storage and transfer overhead

Better approach:

• Use slim base image
• Remove build-time tooling from runtime image
• Keep only required runtime assets

3) No health probes configured¶

Without probes, platform-level health decisions are less precise.

Bad outcome examples:

• Broken dependency initialization treated as healthy
• Stuck replicas remain in rotation too long

Better approach with explicit probe settings:

az containerapp update \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --set "properties.template.containers[0].probes[0].type=Readiness" \
        "properties.template.containers[0].probes[0].httpGet.path=/health" \
        "properties.template.containers[0].probes[0].httpGet.port=8000"

4) Secrets in environment variables instead of Container Apps secrets¶

Directly embedding secrets in plain environment values increases exposure risk.

Bad pattern:

az containerapp update \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --set-env-vars "DATABASE_URL=Server=tcp:db.example;User Id=admin;Password=<plaintext>"

Better pattern using platform secret abstraction:

az containerapp secret set \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --secrets "db-connection=<redacted-secret-value>"

az containerapp update \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --set-env-vars "DATABASE_URL=secretref:db-connection"

5) Using ACR admin credentials instead of managed identity¶

ACR admin credentials are long-lived shared secrets and weaken least privilege.

Better approach:

1. Assign managed identity to app.
2. Grant AcrPull role to that identity.
3. Configure registry identity-based auth.

Assign identity:

az containerapp identity assign \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --system-assigned

6) minReplicas=0 on latency-sensitive APIs¶

For strict SLO APIs, scale-to-zero introduces predictable cold-start delay.

Bad pattern:

az containerapp update \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --min-replicas 0

Better pattern:

az containerapp update \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --min-replicas 1 \
  --max-replicas 20

7) Single revision mode in production¶

Single revision mode removes safe progressive rollout options.

Risks:

• All traffic instantly exposed to new build
• Rollback depends on full revision replacement
• Reduced observability for side-by-side comparison

Better approach:

• Enable multiple revisions
• Send small traffic percentage to candidate revision
• Promote after SLO and error checks

8) Hardcoded connection strings¶

Hardcoded values in code or container args become operational debt.

Failure modes:

• Secrets leak through repository, logs, or diagnostics
• Environment promotion requires image rebuilds
• Rotation causes downtime or drift

Better approach:

• Use secret references and managed identity
• Use one code artifact across environments
• Resolve environment-specific values at deploy/runtime

9) Ignoring SIGTERM and ungraceful shutdown¶

Container Apps sends termination signal during scale-in and revision changes.

If ignored:

• In-flight requests can fail
• Background work may be interrupted mid-transaction
• Telemetry may never flush

Better approach:

• Handle SIGTERM in runtime
• Stop accepting new work immediately
• Drain active work and close cleanly within timeout

10) Missing ingress configuration for externally consumed apps¶

A common issue is healthy app replicas with no reachable endpoint.

Set ingress explicitly during create:

az containerapp create \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --environment "$ACA_ENV_NAME" \
  --image "$ACR_NAME.azurecr.io/orders-api:v1.9.4" \
  --ingress external \
  --target-port 8000

Validate ingress state:

az containerapp show \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --query "properties.configuration.ingress" \
  --output json

11) Using Container Apps for persistent local-state workloads¶

Container Apps is optimized for stateless or externally stateful services.

Anti-pattern examples:

• Local filesystem as primary database
• Stateful leader election dependent on replica identity
• Long-running node-local storage assumptions

Better approach:

• Use managed database/storage services for durable state
• For strict container-orchestrated persistent patterns, evaluate AKS

12) Over-provisioning CPU and memory¶

Provisioning "just in case" directly inflates cost and can mask performance problems.

Review configured resources:

az containerapp show \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --query "properties.template.containers[0].resources" \
  --output json

Better approach:

• Start with measured baseline
• Increase only when metrics show sustained contention
• Reassess after each major release

13) Mixing dev/staging/prod in one environment¶

Single shared environment for all stages causes blast-radius coupling.

Typical failures:

• Non-production experiments impact production networking or quotas
• Shared secrets and RBAC reduce control boundaries
• Troubleshooting signal is noisy and ambiguous

Better approach:

• Separate managed environments per stage
• Separate resource groups and budgets
• Enforce stage-specific RBAC policies

14) Running database migrations in app startup¶

Startup migrations turn deployment into an implicit schema operation.

Risk pattern:

• Horizontal scale events run migration logic concurrently
• App startup blocks on long migration tasks
• Failed migration leaves mixed schema/runtime state

Better approach:

• Run migrations as explicit pre-deployment job
• Verify migration success before traffic shift
• Keep startup path limited to health-ready initialization

Example migration as job:

az containerapp job create \
  --name "job-db-migrate" \
  --resource-group "$RG" \
  --environment "$ACA_ENV_NAME" \
  --trigger-type "Manual" \
  --replica-timeout 1800 \
  --replica-retry-limit 0 \
  --image "$ACR_NAME.azurecr.io/orders-migration:v1.9.4"

15) Ignoring scale rule interaction and precedence¶

Multiple scalers can interact in unexpected ways when thresholds are inconsistent.

Symptoms:

• Replica oscillation (rapid up/down)
• Excessive scale-out under one hot metric
• Cost spikes without throughput gains

Better approach:

• Document each scale rule intent and owner
• Test rule combinations under synthetic load
• Align cooldown and threshold settings with downstream capacity

Inspect current scale settings:

az containerapp show \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --query "properties.template.scale" \
  --output json

Anti-pattern severity and impact matrix¶

Anti-pattern relationship map¶

graph TD
    A[Anti-Patterns] --> B[Release Safety]
    A --> C[Runtime Reliability]
    A --> D[Security and Identity]
    A --> E[Cost Control]
    A --> F[Architecture Fit]

    B --> B1[:latest tag]
    B --> B2[Single revision mode]
    B --> B3[Startup migrations]

    C --> C1[No probes]
    C --> C2[Ignoring SIGTERM]
    C --> C3[Scale rule conflicts]

    D --> D1[Secrets in plain env]
    D --> D2[ACR admin credentials]
    D --> D3[Hardcoded connection strings]

    E --> E1[Over-provisioning resources]
    E --> E2[minReplicas misconfiguration]
    E --> E3[Fat images]

    F --> F1[Persistent workload mismatch]
    F --> F2[No environment separation]
    F --> F3[Ingress misconfiguration]

Pre-production anti-pattern review checklist¶

Verify anti-pattern surfaces in Azure Portal¶

[Observed] ca-sample-d38538 | Revisions and replicas Container App Create new revision Save Refresh Deployment mode Active revisions Inactive revisions Replicas Name Date created Running status View Logs Label Traffic Replicas ca-sample-d38538--0uzoi59 6/3/2026, 10:34:26 PM Running View details Show Logs 100 % 1 (Show replicas).

[Inferred] The immutable revision suffix on ca-sample-d38538--0uzoi59 is consistent with the digest-or-versioned-tag guidance in 1) Using :latest image tag in production, which treats mutable tags as the anti-pattern under review. The Deployment mode setting appears to map to the multi-revision posture called out in 7) Single revision mode in production, which is consistent with treating single-revision mode as the anti-pattern. The Active revisions and Inactive revisions grouping appears to map to the rollout-history guidance referenced in the Anti-pattern quick reference table, which is consistent with treating retained revisions as the rollback surface. The Traffic column with the displayed 100 % value is consistent with the no-staged-rollout concern in 7) Single revision mode in production, where all traffic on a single revision removes the canary option.

[Not Proven] Additional revision configuration detail and runtime parameters are not visible on this view.

Advanced Topics¶

• Automate anti-pattern detection in CI using policy checks for image tags, resource limits, and revision mode.
• Build organization-level deployment templates that enforce managed identity and secret reference defaults.
• Combine platform diagnostics and KQL dashboards to detect anti-pattern drift (for example sudden increase in image pull failures or cold-start latency).
• Establish a quarterly architecture review to identify workloads that should move to jobs, managed services, or AKS based on state and performance requirements.

Common Mistakes / Anti-Patterns¶

• Treating sample defaults as production-ready without checking ingress, scale, identity, and monitoring requirements.
• Applying a configuration change without verifying the resulting revision, logs, and metrics.
• Leaving ownership for certificates, private DNS, secrets, or rollout decisions undocumented.

Validation Checklist¶

• [ ] Required Container Apps settings are represented in infrastructure as code.
• [ ] The active revision, ingress, scale, identity, and monitoring state match the intended design.
• [ ] Rollback or cleanup commands have been tested in a non-production environment.

See Also¶

• Best Practices - Revision Strategy
• Best Practices - Scaling
• Best Practices - Identity and Secrets
• Best Practices - Reliability
• Platform - Reliability

Sources¶

• Microsoft Learn source 1
• Microsoft Learn source 2
• Microsoft Learn source 3
• Microsoft Learn source 4
• Microsoft Learn source 5
• Microsoft Learn source 6
• Microsoft Learn source 7
• Microsoft Learn source 8