Lab Guides¶

Hands-on troubleshooting labs for Azure Container Apps with deployable infrastructure and scripted failure/recovery flows.

All sample outputs in lab guides are PII-scrubbed and use ca-myapp, cae-myapp, and job-myapp naming.

Available Labs¶

ACR Network Path Series¶

A focused 5-lab series that reproduces the five distinct network paths a Container App can take to reach Azure Container Registry. See the ACR Network Path Selection platform doc for the conceptual taxonomy that names and orders all five paths.

Each lab is independently runnable and documents its specific topology, auth mode (ACR admin credentials for A and C; managed identity for B, D, E), and reproduction date in its own Lab position table and Observed in this lab admonition. Labs A and C cleanly prove fresh-pull behavior because admin credentials remove the control-plane token-exchange confound that the managed-identity labs (B, D, E) call out as [Not Proven] for the broken-window fresh pull.

Suggested Learning Path¶

1. ACR Image Pull Failure
2. Probe and Port Mismatch
3. Revision Failover and Rollback
4. Revision Provisioning Failure
5. Scale Rule Mismatch
6. Managed Identity Key Vault Failure
7. Ingress Target Port Mismatch Lab
8. Traffic Routing and Canary Failure Lab
9. Dapr Integration
10. Observability and Tracing
11. CD Reconnect RBAC Conflict

How to Use These Labs Effectively¶

Use this section when you want a repeatable learning loop (reproduce → observe → fix → verify).

flowchart TD
    A[Choose Lab by Symptom] --> B[Deploy Lab Infrastructure]
    B --> C[Trigger Failure]
    C --> D[Collect Evidence]
    D --> E[Apply Targeted Fix]
    E --> F[Verify Recovery]
    F --> G[Capture Lessons Learned]

Lab Selection Matrix¶

Step-by-Step: Standard Lab Execution Pattern¶

1. Prepare shell variables

   export RG="rg-aca-lab-shared"
   export LOCATION="koreacentral"
   export ACA_ENV_NAME="cae-myapp"
   export APP_NAME="ca-myapp"
   export ACR_NAME="acrmyapp"
   

   Expected output: no output (environment variables set in your shell).

2. Validate CLI context

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

   Command	Why it is used
   az account show ...	Confirms the active Azure subscription context before changes are made.

   Expected output: active subscription metadata and extension upgrade confirmation.

3. Deploy the chosen lab infrastructure

   az deployment group create \
     --name "lab-run" \
     --resource-group "$RG" \
     --template-file "./labs/<lab-name>/infra/main.bicep" \
     --parameters baseName="labrun"
   

   Command	Why it is used
   az deployment group create ...	Deploys the Bicep or ARM template into the target resource group.

   Expected output pattern:

   "provisioningState": "Succeeded"
   

4. Trigger failure and collect signals

   ./labs/<lab-name>/trigger.sh
   ./labs/<lab-name>/verify.sh
   

   Expected output: one or more failure indicators (for example ImagePullBackOff, ProbeFailed, 403 Forbidden, or non-scaling replica count).

5. Apply targeted fix and verify recovery

   # Use the specific fix command from each lab guide
   az containerapp revision list --name "$APP_NAME" --resource-group "$RG" --output table
   

   Command	Purpose
   az containerapp revision list --name "$APP_NAME" --resource-group "$RG" --output table	Lists revisions, so you can see whether rollout state matches the failure pattern.

   Expected output pattern: at least one Healthy revision with intended traffic weight.

6. Clean up resources

   ./labs/<lab-name>/cleanup.sh
   

   Expected output: deletion completed or a Succeeded state for cleanup actions.

Expected vs Actual Investigation Template¶

See Also¶

• Playbooks
• First 10 Minutes: Quick Triage Checklist
• Troubleshooting Methodology

Sources¶

• Azure Container Apps troubleshooting overview
• Azure Container Apps revisions
• Azure Container Apps scale behavior