KCNA - Kubernetes Fundamentals (44% of the exam) - Section 1.4
Describe containers, container images, and the runtime standards Kubernetes depends on.
Image layers and registries, the OCI image and runtime specifications, the Container Runtime Interface, and runtimes such as containerd and CRI-O. Also the practical distinction between a container image and a running container.
A developer asks what the Open Container Initiative (OCI) image specification actually standardises, as opposed to the OCI runtime specification. Which statement correctly distinguishes the image specification's role?
AIt defines the gRPC API the kubelet uses to pull images from a registry
BIt defines the format for packaging an image as layers, a manifest, and a configuration so any tool can build, store, and pull itcheck_circle Correct
CIt defines how a running container is isolated at runtime using namespaces and cgroups
DIt defines how registries authenticate users and enforce image signing policies
The OCI image specification standardises the image artifact format (layers, manifest, config) so images are portable across tools and registries. The OCI image specification describes how an image is packaged as a set of content-addressable layers plus a manifest and configuration, which is what allows an image built by one tool to be stored in any registry and run by any conformant runtime.
Why A is wrong: This conflates the OCI image spec with the Container Runtime Interface; image pulling is coordinated through CRI, and the OCI image spec does not define any kubelet gRPC API.
Why B is correct: The OCI image spec standardises the on-disk and registry format (layers, manifest, config), which is exactly what makes images portable across build tools, registries, and runtimes.
Why C is wrong: Namespace and cgroup isolation is a runtime concern closer to the OCI runtime spec and the kernel, not the image format, so this describes the wrong OCI specification.
Why D is wrong: Authentication and signing are handled by registry and supply-chain tooling rather than the OCI image spec, which describes the image artifact format itself, not access control.
Answers that look right on this material and are not. Each one is a distractor from a different question in the KCNA bank for this domain.
The image specification defines how the kubelet schedules Pods, while the runtime specification defines how Services route traffic to Pods
errorWhy it is wrong: Scheduling and Service routing are Kubernetes concerns, which makes this sound plausible, but neither OCI specification addresses them.
Docker Engine, which the kubelet now drives directly as its built-in default runtime
errorWhy it is wrong: Tempting because Docker was historically common, but the kubelet no longer includes a built-in shim for Docker Engine, and Docker Engine is not itself a CRI implementation the kubelet drives directly.
The Container Runtime Interface, which the kubelet uses to talk to each runtime
errorWhy it is wrong: CRI is a plausible choice because it also enables runtime interchangeability, but it standardises the kubelet-to-runtime API, not the portable format of the image itself.