A developer built city-permits-api:local on a laptop and needs that artifact in OCIR. What is the correct Docker sequence?
Select an answer to reveal the explanation.
Short Explanation
docker push sends whatever name the local image already has. Tag with the fully qualified OCIR path first, then push—that Docker tag is not an OCI resource defined-tag.
Full Explanation
Local builds produce a short name such as city-permits-api:local that only exists on the laptop’s Docker Engine. To place that artifact in OCIR, the developer must docker tag the local image with the fully qualified OCIR path (regional domain, tenancy namespace, repository, version), then docker push that qualified name. Tagging re-labels the same image ID under the remote name; push uploads layers and the manifest to that registry path.
Pushing the local short name alone does not make OCIR “rewrite” it to a regional path—Docker pushes to whatever registry (if any) is implied by the name, and a bare short name is not an OCIR reference. Applying an OCI defined-tag on a tenancy resource is Freeform/Defined tagging for OCI resources, not a Docker image tag and not a substitute for docker tag. docker commit of a running container into OCIR without tagging skips the image-build source of truth and still requires a properly named push target; commit is not how you publish a clean CI artifact.
Exam caveat: retagging does not create a second copy of layers locally—it adds a name pointing at the same image ID until push uploads to the registry. Operational check: docker images should show the same IMAGE ID for city-permits-api:local and the fully qualified OCIR name after tagging; after push, pull that qualified name on another host and confirm the digest matches.