A developer logs in to OCIR in Phoenix, then tries to push an image whose repository path is in Ashburn. The push fails. What is the most likely registry-auth mistake?
Select an answer to reveal the explanation.
Short Explanation
OCIR is regional. Logging into Phoenix does not unlock an Ashburn repository path. Match the login host to the region that owns the repo.
Full Explanation
OCIR is a regional service. The registry hostname you authenticate against authorizes operations for repositories in that region. A developer who logs in to the Phoenix registry domain and then pushes a repository path that belongs in Ashburn fails because the session is not scoped to the Ashburn regional endpoint that holds (or should hold) that repository. The fix is to docker login to the Ashburn registry domain that matches the image path’s region, then push the fully qualified Ashburn name.
Saying OCIR is global and any regional login unlocks every repository worldwide contradicts the regional control-plane and data-plane model. Claiming Docker ignores the registry host and only checks the digest skips how push routes to a host and how auth is bound to that host. Requiring an internet gateway whenever you use the correct regional host confuses auth mistakes with network path design—wrong-region login fails even on a healthy network; private pulls may use a service gateway, but that is a separate concern from matching login region to repository region.
Exam caveat: the same tenancy can hold repositories in multiple regions; tags and digests are not magically replicated by a single login. Operational check: print the image name you intend to push, confirm its registry domain’s region identifier, docker logout/login to that exact host with a valid auth token, then retry the push and verify the repository appears in the Console for that region.