Images target operating-system and CPU architectures. Native dependencies and build outputs must match the runtime platform.
Before you start
You should understand the difference between an image, a running container and the host. Record where a file, process or network endpoint actually lives before diagnosing a problem. Commands illustrate local experiments; adapt image names and paths to a disposable development environment.
The practical goal is to reason through this situation: An arm64 laptop build may not run unchanged on an amd64 server. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Choose target platforms
Host and container CPU architecture must be compatible with built artifacts.
Step 2: Build each native variant
Dependencies and compiled output must match the intended runtime.
Step 3: Test real runtime behavior
Emulation can hide performance and platform issues.
Worked scenario
An arm64 laptop build may not run unchanged on an amd64 server.
An arm64 laptop produces a native addon that an amd64 server cannot load as-is. A multi-platform manifest selects the correct image variant, but each variant must contain correctly built native dependencies. Publishing a manifest alone does not establish that the application works on both platforms.
Common mistake
Emulation can hide compatibility and performance problems.
Verify the behavior
Run startup and representative operations for every advertised target.
Interview exercise
Publish for two architectures.
Answer and reasoning
Build and test each target, verify native libraries and publish a manifest identifying supported platform variants.
Continue learning
Compare the scenario with the Docker interview questions and test your understanding with the Docker MCQs. For terminology and implementation details, consult the reference material.