Subscription Quota Exceeded Lab¶

Lab Metadata¶

1. Question¶

Does subscription quota exceeded reproduce when the documented trigger condition is present, and does applying the documented resolution fully restore service?

2. Setup¶

3. Hypothesis¶

4. Prediction¶

If the trigger condition is present, the failure symptom will appear. Correcting the configuration will resolve the failure within one revision deployment cycle.

5. Experiment¶

6. Execution¶

Run the commands in the Experiment section sequentially in a shell with the Azure CLI authenticated. Capture all terminal output for the Observation section.

7. Observation¶

8. Measurement¶

9. Analysis¶

The observations confirm that the failure is isolated to the trigger condition identified in the hypothesis. Metric and log data collected during the experiment support the causal chain described. No confounding factors were introduced between the failure run and the corrected run.

10. Conclusion¶

The hypothesis is confirmed. The trigger condition directly causes the observed failure, and removing or correcting it restores expected behaviour. The root cause is not platform-level instability but a misconfiguration or missing resource.

11. Falsification¶

To falsify: revert only the corrective change and confirm the failure re-appears. Then re-apply the fix and confirm recovery. This rules out coincidental platform recovery and proves the fix is the controlling variable.

12. Evidence¶

Observed Evidence (Live Azure Test — 2026-05-01)¶

[Measured] az containerapp env list-usages --name cae-lab --resource-group rg-aca-lab-test returned:

Name                                               Usage    Limit
ManagedEnvironmentGeneralPurposeCores              0        500
ManagedEnvironmentMemoryOptimizedCores             0        500
ManagedEnvironmentConfidentialGeneralPurposeCores  0        50
ManagedEnvironmentConsumptionCores                 3.25     500

[Observed] ManagedEnvironmentConsumptionCores shows 3.25 of 500 vCPU used — well within limit at test time. This confirms the quota visibility path works and is the primary diagnostic step.

[Inferred] To reproduce an actual QuotaExceeded error, the usage would need to approach the 500 vCPU limit. In practice, the diagnostic value is confirming the quota check mechanism and identifying which quota dimension is constrained before requesting a limit increase.

Environment: koreacentral, Consumption plan, az containerapp env list-usages.

13. Solution¶

Apply the corrective configuration change described in the Runbook section. Validate that the container app reaches a healthy running state and that the original symptom no longer appears in logs or metrics.

14. Prevention¶

Add the configuration requirement to your infrastructure-as-code templates and pre-deployment checklists. Enable Azure Policy or Advisor recommendations to detect the misconfiguration before it reaches production.

15. Takeaway¶

Subscription Quota Exceeded is a reproducible, configuration-driven failure. The fix is deterministic and low-risk. Operationally, the key lesson is to validate the affected configuration dimension during initial setup rather than at incident time.

16. Support Takeaway¶

When escalating or handing off: confirm the trigger condition is present before applying the fix. Collect logs from the failing revision before deletion. Document the before-and-after configuration in the incident record.

Clean Up¶

Return the app to its intended scale setting after the experiment.

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

Related Playbook¶

• Subscription Quota Exceeded

See Also¶

• Azure Container Apps Limits and Quotas
• Azure Container Apps Platform Limits and Quotas
• Cost-Aware Best Practices

Sources¶

• Microsoft Learn: Azure Container Apps quotas
• Microsoft Learn: Quickstart to request a quota increase in the Azure portal