A maple cooperative pushes a new image over the same :latest tag in ACR, but the App Service container web app still runs yesterday’s bits. What should the developer do?
Select an answer to reveal the explanation.
Short Explanation
Moving the :latest sticker on the warehouse shelf does not automatically swap the jar already on the store counter. App Service keeps running what it already pulled until you restart or tell it to pull again. A moved tag is not a deploy by itself.
Full Explanation
Pushing a new image over the same :latest tag in Azure Container Registry does not automatically refresh an App Service container web app that already pulled yesterday’s bits. The maple cooperative must restart the web app, update the container setting, or rely on a configured webhook or continuous-deployment pull so the host actually fetches the newly pushed image. Moving the :latest sticker on the warehouse shelf does not swap the jar already sitting on the store counter.
Assuming App Service always polls :latest every sixty seconds with no further action is unsafe and usually wrong for this scenario. Converting the web app to ZipDeploy of source because “mutable tags never work with App Service containers” abandons a valid container model; the issue is pull and refresh behavior, not an absolute ban on tags. Deleting the App Service plan and recreating it in another region whenever :latest moves is extreme operational theater and unnecessary for an image refresh.
Exam caveat: prefer unique tags or digests in production so each deployment is an explicit setting change. If you must use mutable tags, document the restart or webhook step as part of the release checklist every time the tag moves.
Operational check: push a new image to :latest, confirm the web app still serves old content and an old digest, restart the app or trigger the ACR webhook / update container settings, then verify the running digest matches the new ACR manifest.