Linux Foundation Kubernetes and Cloud Native Associate KCNA Exam Questions

Answer : A

Kubernetes provides ''virtual clusters'' within a single physical cluster primarily through Namespaces, so A is correct. Namespaces are a logical partitioning mechanism that scopes many Kubernetes resources (Pods, Services, Deployments, ConfigMaps, Secrets, etc.) into separate environments. This enables multiple teams, applications, or environments (dev/test/prod) to share a cluster while keeping their resource names and access controls separated.

Namespaces are often described as ''soft multi-tenancy.'' They don't provide full isolation like separate clusters, but they do allow administrators to apply controls per namespace:

RBAC rules can grant different permissions per namespace (who can read Secrets, who can deploy workloads, etc.).

ResourceQuotas and LimitRanges can enforce fair usage and prevent one namespace from consuming all cluster resources.

NetworkPolicies can isolate traffic between namespaces (depending on the CNI).

Containers are runtime units inside Pods and are not ''virtual clusters.'' Hypervisors are virtualization components for VMs, not Kubernetes partitioning constructs. cgroups are Linux kernel primitives for resource control, not Kubernetes virtual cluster constructs.

While there are other ''virtual cluster'' approaches (like vcluster projects) that create stronger virtualized control planes, the built-in Kubernetes mechanism referenced by this question is namespaces. Therefore, the correct answer is A: Namespaces.

=========

Answer : B

B is correct: an ephemeral container is a temporary container you can add to an existing Pod for troubleshooting and debugging without 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:

D describes init containers, which run before app containers start and are used for setup tasks.

C resembles 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.

A is 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 is B.

=========

Answer : D

D is correct: the mandatory top-level fields for creating a Kubernetes object manifest are apiVersion, kind, metadata, and (for most objects you create) spec. These fields establish what the object is and what you want Kubernetes to do with it.

apiVersion tells Kubernetes which API group/version schema to use (e.g., apps/v1, v1). This determines valid fields and behavior.

kind identifies the resource type (e.g., Pod, Deployment, Service).

metadata contains identifying information like name, namespace, and labels/annotations used for organization, selection, and automation.

spec describes the desired state. Controllers and the kubelet reconcile actual state to match spec.

Why other choices are wrong:

status is not a mandatory input field. It's generally written by Kubernetes controllers and reflects observed state (conditions, readiness, assigned node, etc.). Users typically do not set status when creating objects.

template is not a universal top-level field. It exists inside some resources (notably Deployment.spec.template), but it's not a required top-level field across Kubernetes objects.

It's true that some resources can be created without a spec (or with minimal fields), but in the exam-style framing---''mandatory fields... using a YAML file''---the canonical expected set is exactly the four in D. This aligns with how Kubernetes documentation and examples present manifests: identify the API schema and kind, give object metadata, and declare desired state.

Therefore, apiVersion + metadata + kind + spec is the only option that includes only the mandatory fields, making D the verified correct answer.

=========

Answer : A

Rook is a Kubernetes storage operator that helps manage and automate storage systems in a Kubernetes-native way, so A is correct. The key phrase in the question is ''storage operator ... self-scale, self-heal.'' Operators extend Kubernetes by using controllers to reconcile a desired state. Rook applies that model to storage, commonly by managing storage backends like Ceph (and other systems depending on configuration).

With an operator approach, you declare how you want storage to look (cluster size, pools, replication, placement, failure domains), and the operator works continuously to maintain that state. That includes operational behaviors that feel ''self-healing'' such as reacting to failed storage Pods, rebalancing, or restoring desired replication counts (the exact behavior depends on the backend and configuration). The important KCNA-level idea is that Rook uses Kubernetes controllers to automate day-2 operations for storage in a way consistent with Kubernetes' reconciliation loops.

The other options do not match the question: ''Kubernetes

'' is the orchestrator itself, not a storage operator. ''Helm'' is a package manager for Kubernetes apps---it can install storage software, but it is not an operator that continuously reconciles and self-manages. ''CSI'' (Container Storage Interface) is an interface specification that enables pluggable storage drivers; CSI drivers provision and attach volumes, but CSI itself is not a ''storage operator'' with the broader self-managing operator semantics described here.

So, for ''storage operator that can help with self-* behaviors,'' Rook is the correct choice.

=========

Answer : D

A Kubernetes node must have a container runtime to run Pods, so D is correct. Kubernetes schedules Pods to nodes, but the actual execution of containers is performed by a runtime such as containerd or CRI-O. The kubelet communicates with that runtime via the Container Runtime Interface (CRI) to pull images, create sandboxes, and start/stop containers. Without a runtime, the node cannot launch container processes, so Pods cannot transition into running state.

Options A and B confuse networking kernel settings with runtime requirements. iptables bridged traffic visibility and IPv4 forwarding can be relevant for node networking, but they do not replace the need for a container runtime. Networking and container execution are separate layers: you need networking for connectivity, and you need a runtime for running containers.

Option C is also incorrect and muddled. Container runtimes are not deprecated; rather, Kubernetes removed the built-in Docker shim integration from kubelet in favor of CRI-native runtimes. CRI is an interface, not ''something you install instead of a runtime.'' In practice you install a CRI-compatible runtime (containerd/CRI-O), which implements CRI endpoints that kubelet talks to.

Operationally, the runtime choice affects node behavior: image management, logging integration, performance characteristics, and compatibility. Kubernetes installation guides explicitly list installing a container runtime as a prerequisite for worker nodes. If a cluster has nodes without a properly configured runtime, workloads scheduled there will fail to start (often stuck in ContainerCreating/ImagePullBackOff/Runtime errors).

Therefore, the only fully correct statement is D: each node needs a container runtime to run Pods.

=========

Answer : D

Kubernetes provides automated rollouts and rollbacks for workloads by default (via controllers like Deployments), so D is correct. In Kubernetes, application delivery is controller-driven: you declare the desired state (new image, new config), and controllers reconcile the cluster toward that state. Deployments implement rolling updates, gradually replacing old Pods with new ones while respecting availability constraints. Kubernetes tracks rollout history and supports rollback to previous ReplicaSets when an update fails or is deemed unhealthy.

This is a core orchestration capability: it reduces manual intervention and makes change safer. Rollouts use readiness checks and update strategies to avoid taking the service down, and kubectl rollout status/history/undo supports day-to-day release operations.

The other options are not ''default Kubernetes orchestration features'':

Kubernetes is not a portable operating system (A). It's a platform for orchestrating containers on top of an OS.

Kubernetes does not provide filesystem redundancy by itself (B). Storage redundancy is handled by underlying storage systems and CSI drivers (e.g., replicated block storage, distributed filesystems).

Kubernetes does not include a built-in container image registry (C). You use external registries (Docker Hub, ECR, GCR, Harbor, etc.). Kubernetes pulls images but does not host them as a core feature.

So the correct ''provided by default'' orchestration feature in this list is the ability to safely manage application updates via automated rollouts and rollbacks.

=========

Answer : A

A StatefulSet commonly requires a headless Service, so A is the correct answer. In Kubernetes, StatefulSets are designed for workloads that need stable identities, stable network names, and often stable storage per replica. To support that stable identity model, Kubernetes typically uses a headless Service (spec.clusterIP: None) to provide DNS records that map directly to each Pod, rather than load-balancing behind a single virtual ClusterIP.

With a headless Service, DNS queries return individual endpoint records (the Pod IPs) so that each StatefulSet Pod can be addressed predictably, such as pod-0.service-name.namespace.svc.cluster.local. This is critical for clustered databases, quorum systems, and leader/follower setups where members must discover and address specific peers. The StatefulSet controller then ensures ordered creation/deletion and preserves identity (pod-0, pod-1, etc.), while the headless Service provides discovery for those stable hostnames.

CronJobs run periodic Jobs and don't require stable DNS identity for multiple replicas. Deployments manage stateless replicas and normally use a standard Service that load-balances across Pods. DaemonSets run one Pod per node, and while they can be exposed by Services, they do not intrinsically require headless discovery.

So while you can use a headless Service for other designs, StatefulSet is the workload type most associated with ''requires a headless Service'' due to how stable identities and per-Pod addressing work in Kubernetes.