A maple-syrup cooperative pushes a grader API image to Azure Container Registry and then waits for HTTPS traffic that never arrives. What role does ACR play versus the compute host?
Select an answer to reveal the explanation.
Short Explanation
ACR is the locked pantry where finished jars sit on the shelf. Someone still has to open a jar and serve it—ACI, Container Apps, or App Service. Pushing to the pantry never turns on the lunch counter.
Full Explanation
Azure Container Registry is a private store for container images. After the maple-syrup cooperative pushes the grader API image, ACR holds the artifact; it does not terminate TLS for the API or accept application HTTPS traffic. A compute host—Azure Container Instances, Azure Container Apps, or App Service—must pull that image and run it before clients see responses.
Treating ACR as if it becomes the live API on first push confuses registry storage with application hosting. ACR also does not replace Container Apps for HTTP microservices; registries and runtimes solve different problems even for a single replica. Pushing a tag does not auto-create an App Service plan or publish port 443—that requires an explicit web app or other host configuration.
Exam caveat: private registries still require the compute identity or credentials to pull. A successful push proves publish rights, not that any host can pull or that ingress is configured.
Operational check: after push, create or update an ACI/Container Apps/App Service instance that references loginServer/repo:tag, confirm a successful pull in logs, and only then hit the application HTTPS endpoint—not the ACR login server FQDN—for functional traffic.