Free KCNA Mock Exam Sample Questions

10 KCNA practice questions with full explanations on every option. Original questions written against the current CNCF curriculum.

Container Orchestration

Q1. What does the CRI (Container Runtime Interface) do in Kubernetes?

Reveal answer and explanations
  1. A Encrypts container traffic

    Incorrect. Encryption is a separate security concern.

  2. B Defines an interface between kubelet and container runtimes

    Correct. CRI is a plugin interface that allows kubelet to work with different container runtimes like containerd, CRI-O, etc.

  3. C Manages container images on registry servers and handles pull authentication

    Incorrect. The CRI is the gRPC contract between the kubelet and the container runtime on a node; registry authentication and image management are handled by the runtime itself plus the kubelet's image-pull credentials, outside the CRI surface.

  4. D Schedules containers on nodes

    Incorrect. The scheduler assigns Pods; kubelet uses CRI to start containers.

Container Orchestration

Q2. Why use multi-stage builds for container images?

Reveal answer and explanations
  1. A To support multiple container runtimes

    Incorrect. Multi-stage builds are not primarily about supporting multiple container runtimes.

  2. B To enable parallel image builds

    Incorrect. They may improve caching, but the key pattern is separating build and runtime contents.

  3. C To run multiple containers simultaneously

    Incorrect. Container count at runtime is controlled by Pod or workload specs; multi-stage builds are about Dockerfile build stages and final image contents.

  4. D To reduce final image size by separating build dependencies from runtime dependencies

    Correct. Multi-stage builds keep build dependencies out of the final image, reducing size and attack surface.

Container Orchestration

Q3. What is containerd?

Reveal answer and explanations
  1. A A container image repository

    Incorrect. Registries store images; containerd runs them.

  2. B A networking plugin for containers that implements the CNI specification

    Incorrect. containerd doesn't handle networking.

  3. C An OCI-compliant container runtime that manages containers

    Correct. containerd is an industry-standard OCI-compliant container runtime that manages container lifecycle.

  4. D A Kubernetes distribution

    Incorrect. containerd is a runtime, not a Kubernetes distribution.

Container Orchestration

Q4. One app can run from a static binary, while another needs CA certs and runtime libraries but no shell. How do scratch and distroless differ?

Reveal answer and explanations
  1. A Distroless is empty, while scratch includes common Linux debugging tools

    Incorrect. scratch is the empty starting point; distroless is not a debugging-tool image.

  2. B Scratch is only for stateful apps, while distroless is only for stateless apps

    Incorrect. The distinction is image contents, not stateful versus stateless application design.

  3. C Scratch and distroless are identical names for the same base image

    Incorrect. They are different approaches to minimal container base images.

  4. D scratch is empty; distroless adds runtime deps without shell/package manager

    Correct. scratch is Docker's empty base image, while distroless images include only the runtime dependencies needed to run the application and omit package managers and shells.

Container Orchestration

Q5. What is the purpose of this Dockerfile instruction? ```dockerfile FROM ```

Reveal answer and explanations
  1. A To expose ports from the container

    Incorrect. `EXPOSE` documents container ports; `FROM` selects the base image layer for the build.

  2. B To specify the base image to build upon

    Correct. FROM specifies the parent/base image that the new image builds on, starting the image layer chain.

  3. C To copy files into the image

    Incorrect. COPY or ADD instructions copy files.

  4. D To set the working directory inside the image

    Incorrect. Setting the working directory inside the image is what `WORKDIR` does; `FROM` declares the base image that the build starts from and is a different Dockerfile instruction with its own semantics.

Container Orchestration

Q6. An upgraded cluster no longer supports PodSecurityPolicy. What replaced PSP for built-in Pod admission controls?

Reveal answer and explanations
  1. A SecurityContext settings without admission enforcement

    Incorrect. SecurityContext fields define what a Pod requests, but a cluster still needs admission enforcement if it wants to require a Pod security profile.

  2. B NetworkPolicy objects

    Incorrect. NetworkPolicy controls traffic, not Pod security admission.

  3. C RBAC RoleBindings by themselves

    Incorrect. RBAC controls API permissions, not Pod spec security profiles by itself.

  4. D Pod Security Admission using Pod Security Standards

    Correct. PodSecurityPolicy was removed, and Kubernetes uses Pod Security Admission with Pod Security Standards for built-in Pod security enforcement.

Container Orchestration

Q7. What is the difference between a container image layer and a container instance?

Reveal answer and explanations
  1. A They are the same thing

    Incorrect. An image layer is a static, content-addressable filesystem layer stored in a registry, while a container instance is a runtime process created by the runtime from an image; the lifecycle and storage characteristics differ.

  2. B Layers only exist in registries; instances only exist on nodes

    Incorrect. Image layers are content-addressable artefacts that live wherever an image is stored — registries, node image caches, or in-memory builds — and are not exclusive to registries; container instances run on a node but can be paused, checkpointed, or replicated across nodes by higher-level controllers.

  3. C Layers are immutable filesystem snapshots in an image; an instance is a running container from that image

    Correct. Image layers are immutable stacked filesystems; a running container instance gets a read-write layer on top.

  4. D A layer is a read-write copy; an instance is read-only

    Incorrect. The properties are inverted: image layers are read-only and shared between containers, while a running container's writable layer is the per-instance read-write overlay added on top of the read-only image layers.

Container Orchestration

Q8. What does container runtime sandboxing provide?

Reveal answer and explanations
  1. A Stronger isolation with gVisor, Kata, or lightweight VMs

    Correct. Sandboxing runtimes add stronger isolation boundaries, often through user-space kernels or lightweight VMs.

  2. B Encrypting every container-to-container connection by default

    Incorrect. Network encryption is a separate concern from runtime sandboxing.

  3. C Limiting network bandwidth for each Pod

    Incorrect. Bandwidth limiting is not the definition of runtime sandboxing.

  4. D Using the same host kernel isolation without any extra runtime boundary

    Incorrect. Standard host-kernel isolation is the baseline that sandboxing aims to strengthen.

Container Orchestration

Q9. What is the CNI (Container Network Interface)?

Reveal answer and explanations
  1. A A service discovery mechanism

    Incorrect. Service discovery in Kubernetes is provided by the `Service` resource and CoreDNS, not by the CNI plugin; the CNI plugin allocates Pod IPs and wires Pod networking, leaving discovery to higher-level constructs.

  2. B A specification for container networking plugins

    Correct. CNI is a specification defining how container networking plugins integrate with orchestrators.

  3. C A tool for encrypting container communication and managing TLS handshakes

    Incorrect. TLS encryption between Pods is a service-mesh or application-level concern (mTLS via Linkerd, Istio, Cilium, etc.); the CNI specification deliberately focuses on connectivity and IPAM, not transport encryption.

  4. D Kubernetes built-in networking for Pods

    Incorrect. Kubernetes requires CNI plugins; it's not built-in.

Container Orchestration

Q10. A baseline requires containers to write only to mounted volumes, not the image filesystem. What is the purpose of the readOnlyRootFilesystem SecurityContext setting in this scenario?

Reveal answer and explanations
  1. A To make only the /root home directory of the image filesystem read-only while leaving the rest writable

    Incorrect. The setting applies to the entire container root filesystem, not just the /root home directory.

  2. B To make the container's root filesystem read-only, allowing writes only to explicitly mounted writable volumes

    Correct. readOnlyRootFilesystem makes the container root filesystem read-only, forcing writes to explicitly mounted writable volumes such as an emptyDir or a PersistentVolumeClaim.

  3. C To disable container logging

    Incorrect. It does not disable logging; applications can still write to mounted log destinations or stdout/stderr.

  4. D To encrypt the container's filesystem

    Incorrect. Filesystem encryption is a separate storage/security control.

Take the full timed KCNA mock exam90 minutes · free with account