A ferry-kiosk team created an Azure Container Registry, but ACI still cannot find ticket-ui because nothing matches the pull reference the host was given. What is the publish contract the runtime uses?
Select an answer to reveal the explanation.
Short Explanation
Creating the registry is like opening a warehouse. ACI still needs the exact shelf address: loginServer/repository:tag. The warehouse name alone does not locate ticket-ui.
Full Explanation
Runtimes pull images by fully qualified reference, not by Azure nesting metadata. After the ferry-kiosk team creates an ACR, ACI still needs the exact loginServer/repository:tag (or digest) that was pushed—for example myregistry.azurecr.io/ticket-ui:1.4.2. That publish contract is what the host resolves when starting the container group.
A subscription ID is not an image namespace; many registries can exist in one subscription and none are addressed by subscription alone. A resource group name likewise does not identify a repository or tag inside the registry. The Dockerfile path on a developer laptop is irrelevant at pull time—ACI does not read local Dockerfiles over SMB to invent an image reference.
Exam caveat: repository names are case-sensitive in practice for matching what was pushed, and the tag or digest must exist. Creating an empty repository name in conversation is not the same as a successful push of that reference.
Operational check: run az acr repository show-tags --name REGISTRY_NAME --repository ticket-ui, copy the exact login server from az acr show, compose the full reference in the ACI image property, and confirm the group reaches a running state with pull success in the event log.