After building a waste-collection scheduling image on a laptop, other hosts and the cluster must run the same artifact. What role does a container registry play?
Select an answer to reveal the explanation.
Short Explanation
A registry is the shared library shelf: you publish the book from your desk, and every other reader borrows the same edition by name instead of photocopying your laptop disk.
Full Explanation
A container registry is the remote store where built images are published so other machines can pull the same named artifact by repository and tag or digest. After the waste-collection scheduling image exists on a laptop, push places those layers where CI agents, sibling developer hosts, and the cluster can retrieve an identical artifact without copying local disk by hand. The registry is the shared shelf in the Docker lifecycle: build locally, publish centrally, pull everywhere that must run the same bytes.
A registry does not replace the Dockerfile or source control as the place application code is edited. It does not start containers by itself—pull retrieves the image, and a runtime starts the process. It is not merely a Kubernetes Dashboard plugin unused outside OKE; registries are general infrastructure, and OCIR is OCI’s managed instance of that architectural role later in the curriculum.
Exam caveat: conceptual registry role comes before OCIR-specific features such as tenancy namespaces or auth helpers—do not confuse “what a registry is” with “which OCI console click.” Operational check: push the scheduling image, pull it on a clean host that never built it, and confirm the image digest matches the published artifact before promoting that digest into cluster manifests.