Manifest lists and multi-arch images

WHAT THIS TESTS This checks your grasp of how the registry and runtime cooperate to make one tag portable across CPU architectures.

A GOOD ANSWER COVERS A manifest list, called an image index in the OCI spec, is a top-level document that does not itself contain layers. Instead it lists child manifest descriptors, each annotated with a platform such as linux/amd64 or linux/arm64 and each pointing at a full image manifest by digest. When a client pulls redis:7, it sends its platform information, and the registry or client selects the child manifest matching the host os and architecture, then pulls only that variant's layers. This lets maintainers publish one tag that transparently resolves to the right image everywhere. Tools like docker buildx build the per-arch images and assemble the index. The selected image is byte-specific per architecture; nothing is translated at runtime.

COMMON WRONG ANSWERS Thinking one image runs on all CPUs unchanged. Believing the registry transcodes or emulates architectures automatically. Confusing the manifest list with a single image manifest. Assuming the tag points directly at layers.

LIKELY FOLLOW-UPS How does buildx create a manifest list? What happens if no matching platform exists? How does emulation via qemu relate? What is the difference between the OCI image index and the Docker manifest list?

ONE CONCRETE EXAMPLE A maintainer runs docker buildx build --platform linux/amd64,linux/arm64 -t org/app:7 --push. The registry stores two image manifests plus an index tagged app:7. An Apple Silicon laptop pulling app:7 receives the arm64 manifest and its layers; an x86 server pulling the same tag receives the amd64 variant. Each host runs native code, and developers never specify the architecture explicitly.