[Bug] `azd deploy` overwrites App Service container settings it doesn't own (e.g. `acrUserManagedIdentityID`)

[qiaozha]

Summary

azd deploy's core step re-serializes an App Service's container configuration from azd's own model and does a replace, not a merge. Any site setting azd isn't aware of is dropped on every deploy.

What happens

The casualty is our ACR-pull identity wiring, set at provision time (Bicep):

• acrUseManagedIdentityCreds=true
• acrUserManagedIdentityID=<user-assigned MI clientId>

Failure chain:

1. azd deploy backend -> core deploy re-serializes container config -> acrUserManagedIdentityID cleared
2. platform falls back to a system-assigned identity that doesn't exist on the site
3. next ACR image pull has no valid credential -> 503 (image pull failure)

Current workaround

backend-postdeploy.ts -> repinAcrPullIdentity():

• re-applies acrUseManagedIdentityCreds=true and acrUserManagedIdentityID=<MI clientId> via az webapp config container set
• restarts the site
• idempotent — runs on every azd deploy backend because the wipe recurs each time

Ask

Either:

• Preserve unknown App Service settings across azd deploy (don't drop keys azd didn't set), or
• expose an explicit "merge, don't replace" option for site/container config.

Either would let us delete repinAcrPullIdentity.

---

Context: encountered while deploying a multi-component AI/chat service (App Service + Function App + Logic App + Foundry hosted agent) end-to-end with azd provision/deploy in Azure/azure-sdk-tools tools/sdk-ai-bots/deployment. We currently work around this with a TypeScript hook.