Summary
On a first devclaw up where the ACA revision activation times out (Operation expired), the container app's system-assigned managed identity never gets the AcrPull role on ACR. Subsequent devclaw deploy calls push the image successfully but the container fails to start with a persistent 401.
Error seen in container system logs
Failed to construct registry secret for registry 'acrXXXXX.azurecr.io'
Error: ACR token exchange endpoint returned error status: 401
Steps to reproduce
- Run
devclaw up in a region/subscription where ACA revision activation times out on first run (e.g. southindia with a cold ACA environment, or any restricted corporate subscription)
- Provision completes (ACR ✓, OpenAI ✓, Storage ✓, ACA env ✓) but revision fails with
Operation expired
- Run
devclaw deploy — image is pushed to ACR but container immediately fails with ACR 401
Root cause
Bicep provisions ACR with adminUserEnabled: false (correct) and the container app is configured to pull via system-assigned managed identity — but the AcrPull role assignment on ACR for the container app's principalId is either missing or not yet propagated when the first revision activation is attempted. When the first azd up doesn't complete cleanly, this RBAC gap is never resolved.
Expected behaviour
Bicep should create an explicit AcrPull role assignment resource scoped to the ACR for the container app's managed identity, with correct dependsOn sequencing so the role is in place before the first revision is activated.
Manual workaround
PRINCIPAL_ID=$(az containerapp show -n <app> -g <rg> --query 'identity.principalId' -o tsv)
ACR_ID=$(az acr show -n <acr> -g <rg> --query 'id' -o tsv)
az role assignment create \
--assignee-object-id $PRINCIPAL_ID \
--assignee-principal-type ServicePrincipal \
--role AcrPull \
--scope $ACR_ID
Environment
- Region:
southindia
- Restricted corporate subscription with Azure Policy assignments active
azd version: latest, az CLI: latest
Summary
On a first
devclaw upwhere the ACA revision activation times out (Operation expired), the container app's system-assigned managed identity never gets theAcrPullrole on ACR. Subsequentdevclaw deploycalls push the image successfully but the container fails to start with a persistent 401.Error seen in container system logs
Steps to reproduce
devclaw upin a region/subscription where ACA revision activation times out on first run (e.g.southindiawith a cold ACA environment, or any restricted corporate subscription)Operation expireddevclaw deploy— image is pushed to ACR but container immediately fails with ACR 401Root cause
Bicep provisions ACR with
adminUserEnabled: false(correct) and the container app is configured to pull via system-assigned managed identity — but theAcrPullrole assignment on ACR for the container app'sprincipalIdis either missing or not yet propagated when the first revision activation is attempted. When the firstazd updoesn't complete cleanly, this RBAC gap is never resolved.Expected behaviour
Bicep should create an explicit
AcrPullrole assignment resource scoped to the ACR for the container app's managed identity, with correctdependsOnsequencing so the role is in place before the first revision is activated.Manual workaround
Environment
southindiaazdversion: latest,azCLI: latest