How do you manage multi-arch container images under a single tag?

WHAT THIS TESTS: This question probes whether you understand the OCI distribution spec and how modern registries handle platform-specific artifacts under a single tag. At the senior level, interviewers want to see that you know the difference between an image index, also called a manifest list, and a single manifest, and that you can reason about build performance, cache invalidation, and registry storage costs across architectures.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, explain that a single tag resolves to an image index, also called a manifest list, which contains descriptors for each supported platform including architecture and OS. Second, describe how Docker Buildx acts as a builder driver that can target multiple platforms in one build command, typically using QEMU user-mode emulation for interpreted builds or native cross-compilation toolchains for compiled languages. Third, clarify that the registry does not store one monolithic image; it stores separate layer blobs and per-arch manifests, with the index sitting above them. Fourth, note that the Docker client or Kubernetes kubelet requests a specific platform via headers, and the registry returns the matching manifest from the index so only relevant layers are pulled.

COMMON WRONG ANSWERS: Red flags include saying you build one fat image containing both amd64 and arm64 binaries, or that the tag is just a renamed tarball with everything inside. Another mistake is claiming that Buildx merges layers into a single digest; in reality each architecture has its own digest and config. Candidates also stumble by ignoring the registry's role in content negotiation, or by suggesting manifest lists are optional Docker-specific hacks rather than part of the OCI spec.

LIKELY FOLLOW-UPS: Interviewers often push deeper with questions about cache efficiency across platforms, how to handle architecture-specific base images, or what happens when a requested platform is missing from the manifest list. They may also ask about CI pipeline design, such as whether to build all architectures in one job or use a matrix of native runners, and how to sign multi-arch images with Cosign or Notary.

ONE CONCRETE EXAMPLE: Imagine you run docker buildx build --platform linux/amd64,linux/arm64 -t myapp:v1 --push . on an amd64 CI runner. Buildx spins up two build contexts, one native and one via QEMU for arm64. It produces two images with different digests, pushes all layer blobs to the registry, then creates and pushes a manifest list tagged myapp:v1. When an arm64 node in your EKS cluster pulls myapp:v1, the container runtime requests linux/arm64, the registry returns the arm64 manifest, and the node downloads only the arm64 layers. The amd64 layers never traverse the network.