Free Linux Foundation KCNA Practice Exam with Questions & Answers | Set: 3

containerdis a widely adopted, industry-standard container runtime known for simplicity, robustness, and portability, soCis correct. containerd originated as a core component extracted from Docker and has become a common runtime across Kubernetes distributions and managed services. It implements container lifecycle management (image pull, unpack, container execution, snapshotting) and typically delegates low-level container execution to an OCI runtime like runc.

In Kubernetes, kubelet communicates with container runtimes through CRI. containerd provides a CRI plugin (or can be integrated via CRI implementations) that makes it a first-class choice for Kubernetes nodes. This aligns with the runtime landscape after dockershim removal: Kubernetes users commonly run containerd or CRI-O as the node runtime.

Option A (CRI-O) is also a CRI-focused runtime and is valid in Kubernetes contexts, but the phrasing “industry-standard … emphasis on simplicity, robustness, and portability” is strongly associated with containerd’s positioning and broad cross-platform adoption beyond Kubernetes. Option B (LXD) is a system container manager (often associated with LXC) and not the standard Kubernetes runtime in mainstream CRI discussions. Option D (kata-runtime) is associated with Kata Containers, which focuses on stronger isolation by running containers inside lightweight VMs; that is a security-oriented sandbox approach rather than a simplicity/portability “industry standard” baseline runtime.

From a cloud-native operations point of view, containerd’s popularity comes from its stable API, strong ecosystem support, and alignment with OCI standards. It integrates cleanly with image registries, supports modern snapshotters, and is heavily used in production by many Kubernetes providers. Therefore, the best verified answer isC: containerd.

=========

Bis correct: anephemeral containeris a temporary container you can add to anexisting Podfortroubleshooting and debuggingwithout restarting the Pod. This capability is especially useful when a running container image is minimal (distroless) and lacks debugging tools like sh, curl, or ps. Instead of rebuilding the workload image or disrupting the Pod, you attach an ephemeral container that includes the tools you need, then inspect processes, networking, filesystem mounts, and runtime behavior.

Ephemeral containers are not part of the original Pod spec the same way normal containers are. They are added via a dedicated subresource and are generally not restarted automatically like regular containers. They are meant for interactive investigation, not for ongoing workload functionality.

Why the other options are incorrect:

Ddescribesinit containers, which run before app containers start and are used for setup tasks.

Cresembles the “sidecar” concept (a supporting container that runs alongside the main container), but sidecars are normal containers defined in the Pod spec, not ephemeral containers.

Ais not a definition; ephemeral containers are not “root by design” (they can run with various security contexts depending on policy), and they aren’t limited to infosec use cases.

In Kubernetes operations, ephemeral containers complement kubectl exec and logs. If the target container is crash-looping or lacks a shell, exec may not help; adding an ephemeral container provides a safe and Kubernetes-native debugging path. So, the accurate definition isB.

=========

D (RollingUpdate)is correct. In Kubernetes, the Deployment resource’s default update strategy isRollingUpdate, which replaces Podsgraduallyrather than all at once. This supports zero-downtime updates when the workload is properly configured (sufficient replicas, correct readiness probes, and appropriate maxUnavailable / maxSurge settings). As new Pods come up and become Ready, old Pods are terminated in a controlled way, keeping the service available throughout the rollout.

RollingUpdate’s “zero downtime” is achieved by maintaining capacity while transitioning between versions. For example, with multiple replicas, Kubernetes can create new Pods, wait for readiness, then scale down old Pods, ensuring traffic continues to flow to healthy instances. Readiness probes are critical: they prevent traffic from being routed to a Pod until it’s actually ready to serve.

Why other options are not the Kubernetes-native “strategy” answer here:

Recreate (B)explicitly stops old Pods before starting new ones, causing downtime for most services.

Canary (A)andBlueGreen (C)are real deployment patterns, but in “Kubernetes-native deployment strategy” terms, the built-in Deployment strategies areRollingUpdateandRecreate. Canary/BlueGreen typically require additional tooling/controllers (service mesh, ingress controller features, or progressive delivery operators) to manage traffic shifting between versions.

So, for a Kubernetes-native strategy that supports zero-downtime updates, the correct and verified choice isRollingUpdate (D).

=========

BothDeploymentsandStatefulSetsare Kubernetes workload controllers that manage a set of Pods created from a Pod template, meaning they manage Pods based on anidentical container specification(a shared Pod template). That is whyAis correct. In both cases, you declare a desired state (replicas, container images, environment variables, volumes, probes, etc.) in spec.template, and the controller ensures the cluster converges toward that state by creating, updating, or replacing Pods.

The differences are what make the other options incorrect.OnDeleteupdate strategy is associated with StatefulSets (it’s one of their update strategies), but it is not a shared, defining behavior across both controllers, so B is not “in common.”Ordered, graceful deployment and scalingis a hallmark of StatefulSets (ordered pod creation/termination and stable identities) rather than Deployments, so C is not shared.Sticky identity per Pod(stable network identity and stable storage identity per replica, commonly via StatefulSet + headless Service) is specifically a StatefulSet characteristic, not a Deployment feature, so D is not common.

A useful way to think about it is: both controllers managereplicas of a Pod template, but they differ in semantics. Deployments are designed primarily forstatelessworkloads and typically focus on rolling updates and scalable replicas where any instance is interchangeable. StatefulSets are designed forstatefulworkloads and add identity and ordering guarantees: each replica gets a stable name (like db-0, db-1) and often stable PersistentVolumeClaims.

So the shared commonality the question is testing is the basic workload-controller pattern: both controllers manage Pods created from a common template (identical container spec). Therefore,Ais the verified answer.

=========

In Kubernetes, the standard way to execute a command inside a running container iskubectl exec, which is whyAis correct. kubectl exec calls the Kubernetes API (API server), which then coordinates with thekubeleton the target node to run the requested command inside the container using the container runtime’s exec mechanism. The -- separator is important: it tells kubectl that everything after -- is the command to run in the container rather than flags for kubectl itself.

This is fundamentally different from docker exec. In Kubernetes, you don’t normally target containers through Docker/CRI tools directly because Kubernetes abstracts the runtime behind CRI. Also, “Docker” might not even be installed on nodes in modern clusters (containerd/CRI-O are common). So optionBis not the Kubernetes-native approach and often won’t work.

kubectl run (option C) is for creating a new Pod (or generating workload resources), not for executing a command in an existing container. kubectl attach (option D) attaches your terminal to a running container’s process streams (stdin/stdout/stderr), which is useful for interactive sessions, but it does not execute an arbitrary new command like exec does.

In real usage, you often specify the container when a Pod has multiple containers: kubectl exec -it -c -- /bin/sh. This is common for debugging, verifying config files mounted from ConfigMaps/Secrets, testing DNS resolution, or checking network connectivity from within the Pod network namespace. Because exec uses the API and kubelet, it respects Kubernetes access control (RBAC) and audit logging—another reason it’s the correct operational method.

=========

Edge and IoT environments often have constraints that differ from traditional datacenters: limited CPU/RAM, intermittent connectivity, smaller footprints, and a desire for simpler operations.k3sis a well-known lightweight Kubernetes distribution designed specifically to run in these environments, makingBthe correct answer.

What makes k3s “lightweight” is that it packages Kubernetes components in a simplified way and reduces operational overhead. It typically uses a single binary distribution and can run with an embedded datastore option for smaller installations (while also supporting external datastores for HA use cases). It streamlines dependencies and is aimed at faster installation and reduced resource consumption, which is ideal for edge nodes, IoT gateways, small servers, labs, and development environments.

By contrast,OpenShiftis a Kubernetes distribution focused on enterprise platform capabilities, with additional security defaults, integrated developer tooling, and a larger operational footprint—excellent for many enterprises but not “built for IoT and edge” as the defining characteristic.RKE(Rancher Kubernetes Engine) is a Kubernetes installer/engine used to deploy Kubernetes, but it’s not specifically the lightweight edge-focused distribution in the way k3s is. “k1s” is not a standard, widely recognized Kubernetes distribution name in this context.

From a cloud native architecture perspective, edge Kubernetes distributions extend the same declarative and API-driven model to places where you want consistent operations across cloud, datacenter, and edge. You can apply GitOps patterns, standard manifests, and Kubernetes-native controllers across heterogeneous footprints. k3s provides that familiar Kubernetes experience while optimizing for constrained environments, which is why it has become a common choice for edge/IoT Kubernetes deployments.

=========

Helmis the Kubernetes package manager used to streamline installing and managing applications, soBis correct. Helm packages Kubernetes resources intocharts, which contain templates, default values, and metadata. When you install a chart, Helm renders templates into concrete manifests and applies them to the cluster. Helm also tracks a “release,” enabling upgrades, rollbacks, and consistent lifecycle operations across environments.

This is why Helm is widely used for complex applications that require multiple Kubernetes objects (Deployments/StatefulSets, Services, Ingresses, ConfigMaps, RBAC, CRDs). Rather than manually maintaining many YAML files per environment, teams can parameterize configuration with values and reuse the same chart across dev/stage/prod with different overrides.

Option A (apt) and option D (brew) are OS package managers (Debian/Ubuntu and macOS/Linuxbrew respectively), not Kubernetes application managers. Option C (service) is a Linux service manager command pattern and not relevant here.

In cloud-native delivery pipelines, Helm often integrates with GitOps and CI/CD: the pipeline builds an image, updates chart values (image tag/digest), and deploys via Helm or via GitOps controllers that render/apply Helm charts. Helm also supports chart repositories and versioning, making it easier to standardize deployments and manage dependencies.

So, the verified tool for streamlined Kubernetes app install/management isHelm (B).

=========

Thekubeletis the primary node agent in Kubernetes. It runs on every worker node (and often on control-plane nodes too if they run workloads) and is responsible for ensuring that containers described byPodSpecsare actually running and healthy on that node. The kubelet continuously watches the Kubernetes API (via the control plane) for Pods that have been scheduled to its node, then it collaborates with the node’s container runtime (through CRI) to pull images, create containers, start them, and manage their lifecycle. It also mounts volumes, configures the Pod’s networking (working with the CNI plugin), and reports Pod and node status back to the API server.

Option D captures the core: “an agent on each node that makes sure containers are running in a Pod.” That includes executing probes (liveness, readiness, startup), restarting containers based on the Pod’s restartPolicy, and enforcing resource constraints in coordination with the runtime and OS.

Why the other options are wrong: A describes the Kubernetes Dashboard (or similar UI tools), not kubelet. B describeskube-proxy, which programs node-level networking rules (iptables/ipvs/eBPF depending on implementation) to implement Service virtual IP behavior. C describes thekube-scheduler, which selects a node for Pods that do not yet have an assigned node.

A useful way to remember kubelet’s role is:scheduler decides where,kubelet makes it happen there. Once the scheduler binds a Pod to a node, kubelet becomes responsible for reconciling “desired state” (PodSpec) with “observed state” (running containers). If a container crashes, kubelet will restart it according to policy; if an image is missing, it will pull it; if a Pod is deleted, it will stop containers and clean up. This node-local reconciliation loop is fundamental to Kubernetes’ self-healing and declarative operation model.

=========

The verified correct answer isD (the container runtime). On a Kubernetes node, thecontainer runtime(such as containerd or CRI-O) is the component that actuallyexecutes containers—it creates container processes, manages their lifecycle, pulls images, and interacts with the underlying OS primitives (namespaces, cgroups) through an OCI runtime like runc. In that direct sense, the runtime is what “runs workloads.”

It’s important to distinguish responsibilities. Thekubelet(A) is the node agent thatorchestrateswhat should run on the node: it watches the API server for Pods assigned to the node and then asks the runtime to start/stop containers accordingly. Kubelet is essential for node management, but it does not itself execute containers; it delegates execution to the runtime via CRI.kube-proxy(B) handles Service traffic routing rules (or is replaced by other dataplanes) and does not run containers.kube-apiserver(C) is a control plane component that stores and serves cluster state; it is not a node workload runner.

So, in the execution chain: scheduler assigns Pod → kubelet sees Pod assigned → kubelet calls runtime via CRI → runtime launches containers. When troubleshooting “containers won’t start,” you often inspect kubelet logs and runtime logs because the runtime is the component that can fail image pulls, sandbox creation, or container start operations.

Therefore, the best answer to “which node component is responsible to run workloads” isthe container runtime, optionD.

=========

A Kubernetesnode componentis a component that runs on worker nodes to support Pods and node-level networking/operations. Among the options,kube-proxyis a node component, soCis correct.

kube-proxy runs on each node and implements parts of the KubernetesServicenetworking model. It watches the API server for Service and endpoint updates and then programs node networking rules (iptables/IPVS, or equivalent) so traffic sent to a Service IP/port is forwarded to one of the backend Pod endpoints. This is essential for stable virtual IPs and load distribution across Pods.

Why the other options are not node components:

kube-scheduleris acontrol planecomponent; it assigns Pods to nodes but does not run on every node as part of node functionality.

kubectlis a client CLI tool used by humans/automation; it is not a cluster component.

etcdis the control plane datastore; it stores cluster state and is not a per-node workload component.

Operationally, kube-proxy can be replaced by some modern CNI/eBPF dataplanes, but in classic Kubernetes architecture it remains the canonical node-level component for Service rule programming. Understanding which components are node vs control plane is key for troubleshooting: node issues involve kubelet/runtime/kube-proxy/CNI; control plane issues involve API server/scheduler/controller-manager/etcd.

So, the verified node component in this list iskube-proxy (C).

=========