A botanical-garden team wants a Container Apps revision to refresh when a new tag lands in Azure Container Registry. What can ACR contribute, and what can it not do alone?
Select an answer to reveal the explanation.
Short Explanation
An ACR webhook is a doorbell: “new jar on the shelf.” Something else—your deploy hook or Container Apps revision update—still has to answer the door. The registry never runs the garden’s app for you.
Full Explanation
ACR can notify; it cannot be the application runtime. For the botanical-garden team, an ACR webhook fires when a new tag is pushed, giving Container Apps (or a pipeline) a signal to create or activate a new revision. The registry’s contribution stops at storage plus that notify-on-push event—it does not host HTTP traffic or swap live revisions by itself.
Enabling ACR “as the runtime” so tags become HTTPS endpoints misunderstands the product boundary: ACR is not Container Apps. Geo-replication alone replicates image content across regions; it neither notifies nor redeploys Container Apps revisions on push. Image manifests describe filesystem layers and config, not Container Apps revision objects, so ACR cannot swap traffic by reading a revision out of a manifest.
Exam caveat: webhook delivery must reach an endpoint you control (Azure Function, Logic App, or CI listener) that then calls Container Apps APIs. A webhook without a subscriber changes nothing in production.
Operational check: create an ACR webhook on push for the garden repository, push a new tag, confirm the webhook receives a 2xx from your handler, and verify a new Container Apps revision is created or activated that references the new tag.