A fleet team ships both linux/amd64 and linux/arm64 builds of a civic mobile-backend image and also stores Helm charts. Why can OCIR hold all of those artifacts?
Select an answer to reveal the explanation.
Short Explanation
OCIR speaks OCI distribution, so Docker images, multi-arch manifest lists, and Helm charts are valid artifacts. Two architectures are one manifest list—not two unrelated SKUs.
Full Explanation
OCIR is OCI-distribution compliant. That standard is not limited to a single-architecture Docker image tarball: registries that speak the distribution API can store Docker images, multi-architecture manifest lists (so one name can resolve to linux/amd64 and linux/arm64 variants of the civic mobile-backend), and other OCI artifacts such as Helm charts. The fleet team can therefore keep container images and charts in the same class of registry service rather than inventing a parallel, non-standard store for each artifact type.
Claiming OCIR only stores single-arch Docker images and that Helm or manifests require a separate Object Storage bucket understates distribution compliance. Saying Helm charts may exist only inside OCI DevOps pipeline stages confuses CI product features with what the registry can store. Multi-arch support does not depend on enabling OCI Service Mesh on the VCN; mesh is a traffic management concern, not the gate for manifest lists in the registry.
Exam caveat: clients must request or understand manifest lists correctly—an older tool that pulls only one platform may surprise you if you expected automatic selection. Operational check: push a multi-arch manifest list and a Helm chart to OCIR, then inspect/pull with a client that shows platform entries and chart references, confirming both artifact kinds appear under the intended repositories.