Check the registry support boundary before retrying a private ACI image pull

Source facts

Microsoft says ACI supports image pulls from registries without a public IP only through Azure Container Registry with a private endpoint and managed identity. Non-ACR private registries remain unsupported even when network connectivity exists. An unsuccessful image pull is retried before deployment eventually fails, and the container group’s events expose pull and failure information. Microsoft Learn.

Applicability

Apply this diagnosis to an Azure Container Instances image pull from a registry with no public IP. Separate this architecture restriction from a misspelled image name, missing artifact or an unrelated runtime problem.

DSE recommendation

Confirm the registry type before expanding network access or repeating deployment. Record the registry endpoint, intended image identity and the supported authentication arrangement. If the design uses a non-ACR private registry, raise the unsupported architecture with the application owner and plan an approved image-publication route. Do not expose a private registry publicly just to test whether the deployment succeeds. Keep any registry migration separate from the immediate failure investigation.

Verification

Inspect the failed group’s pull events and correlate them with the intended registry and image. In an authorized pilot of the supported ACR design, confirm that the expected artifact is obtained through the approved private endpoint and identity. Retain deployment and registry evidence together. A successful reachability probe should not be reported as proof that ACI supports the selected private-registry architecture.

Official references

Microsoft Learn: Troubleshoot common issues.