CCNA Kcna Container Orchestration Questions — Page 3 of 3

151

Multi-Selecthard

Which THREE of the following are true about the Open Container Initiative (OCI)? (Choose 3)

Select 3 answers

A.Docker is an OCI runtime specification

B.OCI is governed by the Cloud Native Computing Foundation (CNCF)

C.OCI defines both an image spec and a runtime spec

D.containerd is an OCI-compliant container runtime

E.Docker images are OCI-compliant

AnswersC, D, E

The OCI publishes two separate specifications: the Image Specification, covering image layout and manifests, and the Runtime Specification, covering container execution. This satisfies the requirement for a true statement, and is the axis distinguishing OCI from earlier vendor-specific formats.

Why this answer

Option C is correct because the Open Container Initiative publishes two core specifications: the OCI Image Format Specification (defining image manifests, configs, and layers) and the OCI Runtime Specification (defining how to run an unpacked filesystem bundle, e.g., via runc). Option D is correct because containerd is a widely used OCI-compliant container runtime that implements the OCI runtime spec through runc and can pull/run OCI images. Option E is correct because Docker images follow the OCI Image Format Specification (Docker helped create the OCI and its image format is compatible with OCI images).

Option A is incorrect because Docker is a container platform/engine, not an OCI runtime specification; the OCI runtime spec is implemented by runtimes like runc. Option B is incorrect because the OCI is an independent Linux Foundation project, not governed by the CNCF (though CNCF projects like containerd are OCI-compliant).

Exam trap

KCNA often tests the misconception that Docker owns or defines the OCI standards, when in reality OCI is a separate Linux Foundation project and Docker is merely one implementation that consumes those specs.

Practice this question →

152

MCQmedium

A company wants to run a batch job that processes data and then terminates. Which Kubernetes resource should they use?

A.CronJob

B.Job

C.Deployment

D.DaemonSet

AnswerB

A Job runs pods to completion and stops retrying once the specified successful completions are reached, which suits a finite batch workload that must terminate. Unlike a Deployment, which maintains a continuous desired replica count, a Job is designed for run-to-completion tasks.

Why this answer

A Job is the correct Kubernetes resource for a batch job that processes data and then terminates. Unlike controllers that maintain a desired state (like Deployments), a Job creates one or more Pods and ensures they run to successful completion. Once the specified number of Pods terminate successfully, the Job is considered complete and does not restart the Pods, making it ideal for one-off or finite processing tasks.

Exam trap

CNCF often tests the distinction between controllers that maintain a desired state (Deployment, DaemonSet) versus controllers that run to completion (Job, CronJob), and the trap here is that candidates may confuse a CronJob with a Job, forgetting that CronJob adds a scheduling layer for periodic execution, not for a single run.

How to eliminate wrong answers

Option A is wrong because a CronJob is designed for scheduling recurring tasks on a time-based schedule (e.g., every hour), not for a single batch job that runs once and terminates. Option C is wrong because a Deployment is meant to run a set of Pods continuously, ensuring a specified number of replicas are always running; it will restart Pods if they exit, which is the opposite of a terminating batch job. Option D is wrong because a DaemonSet ensures that a copy of a Pod runs on every (or selected) node in the cluster, typically for long-running system services like log collectors or monitoring agents, not for one-off batch processing.

Practice this question →

153

MCQeasy

What is the purpose of the 'kubectl scale' command?

A.To update the container image of a Deployment

B.To delete a resource

C.To view the logs of a pod

D.To change the number of replicas in a Deployment

AnswerD

kubectl scale adjusts the replica count declared in a Deployment, StatefulSet or ReplicaSet, letting operators increase or decrease running Pod instances to match load. Changing replicas in a Deployment is precisely the mechanism the command provides for horizontal capacity adjustment.

Why this answer

The 'kubectl scale' command is used to change the number of replicas in a Deployment, StatefulSet, ReplicaSet, or ReplicationController. This allows you to horizontally scale the application by increasing or decreasing the desired replica count, which the controller then reconciles by creating or terminating pods.

Exam trap

Candidates often confuse 'kubectl scale' (changing replica count) with 'kubectl set image' or 'kubectl rollout' (updating pod template).

How to eliminate wrong answers

Option A is wrong because updating the container image of a Deployment is done with 'kubectl set image' or 'kubectl edit', not 'kubectl scale'. Option B is wrong because deleting a resource is performed with 'kubectl delete', not 'kubectl scale'. Option C is wrong because viewing the logs of a pod is done with 'kubectl logs', not 'kubectl scale'.

Practice this question →

154

Multi-Selecthard

A Kubernetes administrator is troubleshooting a Pod that is stuck in the Pending state. The Pod has a resource request of cpu: 2 and memory: 4Gi. Which two commands are most appropriate to identify why the Pod cannot be scheduled? (Choose two.)

Select 2 answers

A.kubectl logs <pod-name> --previous

B.kubectl rollout restart deployment <deployment-name>

C.kubectl exec -it <pod-name> -- /bin/sh

D.kubectl describe pod <pod-name>

E.kubectl get nodes -o custom-columns=NAME:.metadata.name,CPU:.status.allocatable.cpu,MEM:.status.allocatable.memory

AnswersD, E

The describe output includes the Events section at the bottom, which shows scheduler messages such as '0/5 nodes are available: 5 Insufficient cpu' or taint/toleration failures. This is the fastest way to see the scheduler's reasoning for a Pending Pod. It directly addresses the scenario by revealing why the Pod cannot be placed.

Why this answer

The describe command surfaces scheduler events that explain why the Pod is Pending, and querying node allocatable resources shows whether any node has enough CPU and memory. Together they confirm resource shortfalls or constraint mismatches. Logs and exec require a running container, and a rollout restart does not diagnose scheduling failures.

Exam trap

The trap here is reaching for kubectl logs or kubectl exec on a Pending Pod, even though those commands require a running container.

Practice this question →

155

MCQeasy

What is the primary purpose of the Container Runtime Interface (CRI) in Kubernetes?

A.To store container images in a registry

B.To define the format of container images

C.To manage container network interfaces

D.To provide a standard interface between the kubelet and container runtimes

AnswerD

CRI decouples the kubelet from specific container runtimes, letting containerd, CRI-O or others plug in without kubelet code changes. This abstraction satisfies the stem's requirement for a standard interface, enabling runtime swaps independently of Kubernetes releases.

Why this answer

The Container Runtime Interface (CRI) is a plugin protocol that enables the kubelet to use any OCI-compliant container runtime (e.g., containerd, CRI-O) without needing to recompile Kubernetes. It defines gRPC APIs for runtime and image service operations, abstracting the runtime implementation from the kubelet's pod lifecycle management.

Exam trap

CNCF often tests the distinction between CRI (runtime abstraction) and CNI (network abstraction), so the trap here is confusing container runtime management with container networking, leading candidates to pick Option C.

How to eliminate wrong answers

Option A is wrong because storing container images in a registry is the function of a container registry (e.g., Docker Hub, Amazon ECR), not the CRI; the CRI's image service pulls images from registries but does not store them. Option B is wrong because defining the format of container images is the responsibility of the OCI Image Specification, not the CRI; the CRI consumes images in that format but does not define it. Option C is wrong because managing container network interfaces is the role of the Container Network Interface (CNI), not the CRI; the CRI focuses on runtime and image operations, while CNI handles network attachment.

Practice this question →

156

MCQeasy

Which component in Kubernetes is responsible for maintaining the desired state of the cluster?

A.kube-scheduler

B.kube-proxy

C.kube-controller-manager

D.kubelet

AnswerC

The kube-controller-manager runs control loops that watch cluster state and reconcile actual state toward the desired state declared in objects. Kubelet manages only pod lifecycle on one node, and the scheduler merely assigns pods, so neither maintains cluster-wide desired state.

Why this answer

The kube-controller-manager is the component that runs controller processes, which are control loops that watch the shared state of the cluster through the API server and make changes to move the current state toward the desired state. It is responsible for ensuring that the cluster's actual state matches the desired state defined in Kubernetes objects such as Deployments, ReplicaSets, and StatefulSets.

Exam trap

CNCF often tests the distinction between the kube-controller-manager and the kubelet, where candidates mistakenly think the kubelet maintains the cluster's desired state because it manages containers on a node, but the kubelet only ensures the pod's containers are healthy on its local node, not the cluster-wide desired state.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and scheduling policies, not for maintaining the desired state of the cluster. Option B is wrong because kube-proxy is a network proxy that runs on each node and implements part of the Kubernetes Service concept by maintaining network rules, not for maintaining desired state. Option D is wrong because kubelet is an agent that runs on each node and ensures containers are running in a pod as expected, but it only manages the state on its specific node and does not maintain the overall desired state of the cluster.

Practice this question →

157

MCQhard

A cluster administrator is configuring a Pod with a container that requires 2 CPU cores and 4Gi of memory. The administrator sets resource requests to 2 CPU and 4Gi memory, and limits to 4 CPU and 8Gi memory. The Pod is scheduled to a node with 4 CPU and 8Gi memory available. What happens when the container attempts to use 3 CPU and 6Gi memory?

A.The container runs normally because usage is within the limits.

B.The container is restarted by the kubelet because it exceeded its request.

C.The container is throttled to 2 CPU and OOM killed for memory.

D.The container is evicted from the node due to resource overcommit.

AnswerA

The container's resource limits are 4 CPU and 8Gi memory. Using 3 CPU and 6Gi memory is below these limits, so the container is not throttled or killed. Requests guarantee scheduling, while limits cap usage. Since the node has enough resources, the container operates without restriction.

Why this answer

Resource requests are used by the scheduler to place pods, while limits define the maximum resources a container can consume. When usage is between requests and limits, the container continues running without throttling or termination. Only exceeding CPU limits causes throttling, and exceeding memory limits triggers an OOM kill.

Exam trap

The trap here is confusing requests with limits, or assuming that exceeding a request triggers throttling or eviction, when requests are only for scheduling.

Practice this question →

158

MCQhard

Which of the following best describes immutable infrastructure?

A.Servers that are updated in-place with configuration management tools

B.Infrastructure that is version-controlled and deployed using blue/green deployments

C.Infrastructure components that are replaced rather than changed after deployment

D.Infrastructure that uses only read-only file systems

AnswerC

Immutable infrastructure means servers and components are never patched or reconfigured in place; instead a new versioned instance is provisioned from an image and swapped in, then the old one destroyed. This eliminates configuration drift, satisfying the replace-rather-than-change definition the stem asks for.

Why this answer

Immutable infrastructure is a pattern where components (servers, containers, etc.) are never modified after deployment. Instead, any change requires building a new instance from a golden image or template and replacing the old one. This eliminates configuration drift and ensures consistency, which is a core principle in container orchestration with tools like Kubernetes, where Pods are replaced rather than patched in place.

Exam trap

The trap here is that candidates confuse immutable infrastructure with specific deployment patterns (blue/green) or security features (read-only filesystems), rather than recognizing the core principle of replacement over modification.

How to eliminate wrong answers

Option A is wrong because it describes mutable infrastructure, where configuration management tools (e.g., Ansible, Chef) apply updates in-place, directly contradicting the immutable principle of replacement. Option B is wrong because while version-controlled infrastructure and blue/green deployments are often used with immutable infrastructure, they are deployment strategies, not the defining characteristic of immutability itself. Option D is wrong because read-only file systems are a security hardening technique that can be part of an immutable design, but they are not the core definition; immutable infrastructure focuses on the lifecycle of the entire component, not just the filesystem state.

Practice this question →

159

Multi-Selectmedium

Which THREE are benefits of using container orchestration platforms like Kubernetes?

Select 3 answers

A.High availability through automatic container restart and replication

B.Automatic scaling of container replicas based on resource usage

C.Self-healing by replacing failed containers without manual intervention

D.Simplified application development by eliminating the need for code changes

E.Elimination of the need for monitoring and logging

AnswersA, B, C

Replication controllers and ReplicaSets maintain the declared replica count, and Kubernetes restarts or reschedules failed containers automatically. This delivers high availability without manual intervention, satisfying the benefit of automatic restart and replication across the cluster.

Why this answer

Option A is correct because Kubernetes provides high availability by automatically restarting failed containers and maintaining the desired number of replicas across nodes, ensuring workloads remain available even when individual containers or nodes fail. Option B is correct because Kubernetes supports automatic scaling of container replicas through mechanisms like the Horizontal Pod Autoscaler, which adjusts replica counts based on observed CPU, memory, or custom metrics. Option C is correct because Kubernetes performs self-healing by detecting failed containers, pods, or nodes and replacing or rescheduling them without manual intervention, restoring the declared desired state.

Option D is not a benefit of orchestration because Kubernetes manages deployment and runtime concerns, not application source code, so developers still must write and modify code as needed. Option E is incorrect because orchestration platforms do not eliminate monitoring and logging; they integrate with tools like Prometheus, Grafana, and the ELK stack, and observability remains essential for operating containerized workloads.

Exam trap

A common pitfall is the misconception that orchestration platforms like Kubernetes automate everything, including application code changes and monitoring setup, when in reality they only automate operational tasks like scaling and recovery, leaving code adaptation and observability configuration to the user.

Practice this question →

160

Multi-Selectmedium

Which TWO statements accurately describe the concept of immutable infrastructure in the context of container orchestration? (Select two.)

Select 2 answers

A.Configuration changes can be applied via SSH into the container

B.Container images are versioned and promoted through environments without modification

C.When an update is needed, a new container image is built and deployed, and old containers are destroyed

D.Containers are updated in place by executing commands inside running containers

E.Stateful applications require mutable infrastructure

AnswersB, C

Immutable infrastructure promotes the same image through development, staging, and production without changes, ensuring consistency.

Why this answer

Immutable infrastructure treats container images as immutable artifacts that are versioned and promoted through environments (e.g., dev, staging, prod) without modification. This ensures consistency and reproducibility, as the same image is deployed across all stages without patching or altering it in place.

Exam trap

CNCF often tests the distinction between mutable and immutable patterns by presenting options that describe in-place updates (like SSH or exec commands) as valid, which candidates mistakenly accept if they confuse operational debugging with infrastructure management.

Practice this question →

161

MCQeasy

What is a primary benefit of using containers over virtual machines?

A.Containers provide stronger isolation than VMs

B.Containers can run any operating system kernel

C.Containers are lightweight and share the host OS kernel

D.Containers require a hypervisor to run

AnswerC

Containers share the host OS kernel, so they carry no guest operating system per instance. This eliminates the hypervisor and full OS overhead that virtual machines require, giving faster startup and higher density on the same hardware.

Why this answer

Containers virtualize at the operating system level, sharing the host OS kernel while running in isolated user-space instances. This eliminates the need for a full guest OS per workload, making containers significantly more lightweight in terms of memory, disk usage, and startup time compared to virtual machines, which each require a separate kernel and hypervisor.

Exam trap

CNCF often tests the misconception that containers provide stronger isolation than VMs, when in fact VMs offer hardware-enforced isolation via the hypervisor, and containers rely on software-enforced kernel isolation, which is weaker.

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than VMs; VMs use a hypervisor to enforce hardware-level isolation between guest kernels, while containers rely on kernel features like namespaces and cgroups, which share the host kernel and have a larger attack surface. Option B is wrong because containers cannot run any operating system kernel; they must use the same kernel as the host OS (e.g., Linux containers on a Linux host), and running a different kernel (e.g., Windows containers on Linux) requires a VM layer. Option D is wrong because containers do not require a hypervisor to run; they run directly on the host OS using container runtime engines like Docker or containerd, whereas VMs require a hypervisor (Type 1 or Type 2) to manage guest operating systems.

Practice this question →

162

MCQeasy

What is a key advantage of containers compared to virtual machines?

A.Containers provide stronger isolation than VMs

B.Containers are lightweight and share the host OS kernel

C.Containers include a full guest operating system

D.Containers require hypervisor software to run

AnswerB

Containers share the host operating system kernel, so each container packages only the application and its dependencies rather than a full guest OS. This removes per-instance kernel overhead, making containers smaller and faster to start than virtual machines.

Why this answer

Containers are lightweight because they share the host operating system kernel, avoiding the overhead of a separate guest OS per instance. Unlike VMs, which each include a full OS and require hypervisor mediation, containers run as isolated user-space processes on the same kernel, enabling faster startup times and higher density. This kernel sharing is the fundamental architectural advantage that makes containers more resource-efficient than virtual machines.

Exam trap

The trap here is that candidates often confuse 'isolation' with 'security' and assume containers are more secure because they are lightweight, but the CNCF exam tests the understanding that VMs provide stronger isolation via separate kernels and hypervisor-enforced boundaries.

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than VMs, as they share the host kernel and rely on kernel namespaces and cgroups for separation, whereas VMs use a hypervisor to provide hardware-level isolation with separate kernels. Option C is wrong because containers do not include a full guest operating system; they package only the application and its dependencies, leveraging the host OS kernel. Option D is wrong because containers do not require hypervisor software to run; they run directly on the host OS using the container runtime (e.g., containerd, Docker), while hypervisors are needed for VMs.

Practice this question →

163

MCQeasy

Which command would you use to view the logs of a specific container in a pod?

A.kubectl logs <pod-name>

B.kubectl logs <container-name>

C.kubectl logs <pod-name> -c <container-name>

D.kubectl describe pod <pod-name>

AnswerC

The -c flag scopes log retrieval to the named container within a multi-container pod, which is the constraint the stem implies. Without it, kubectl logs defaults to the pod's first container, returning the wrong output.

Why this answer

`kubectl logs <pod-name> -c <container-name>` explicitly targets a specific container within a pod. In Kubernetes, a pod can host multiple containers, and without the `-c` flag, `kubectl logs` defaults to the first container in the pod spec, which may not be the intended one. This command is essential for multi-container pods where each container has its own log stream.

Exam trap

The trap here is that candidates often assume `kubectl logs <pod-name>` works universally, forgetting that multi-container pods require the `-c` flag to specify the container, which Kubernetes frequently tests to assess understanding of pod-level vs. container-level operations.

How to eliminate wrong answers

Option A is wrong because `kubectl logs <pod-name>` only works for single-container pods; in multi-container pods, it either returns an error or defaults to the first container, not allowing selection of a specific container. Option B is wrong because `kubectl logs <container-name>` is not a valid syntax; the command requires a pod name as the primary argument, and a container name is only specified via the `-c` flag. Option D is wrong because `kubectl describe pod <pod-name>` shows pod metadata, events, and container statuses, but does not display container logs; it is used for debugging pod configuration, not for retrieving log output.

Practice this question →

164

MCQmedium

A developer wants to deploy a stateful application that requires stable network identities and persistent storage per pod instance. Which Kubernetes resource is most appropriate?

A.DaemonSet

B.Job

C.Deployment

D.StatefulSet

AnswerD

StatefulSet assigns each pod a stable ordinal hostname and a dedicated PersistentVolumeClaim via volumeClaimTemplates, preserving identity and storage across restarts. Deployments give interchangeable pods with shared or ephemeral volumes, so they cannot satisfy the per-instance persistence constraint.

Why this answer

StatefulSet is the correct choice because it is specifically designed for stateful applications that require stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage per pod instance (via PersistentVolumeClaims that are not shared across replicas). Unlike Deployments, StatefulSet maintains a sticky identity for each pod, ensuring that on rescheduling, the pod retains its name, network identity, and bound storage.

Exam trap

CNCF often tests the misconception that a Deployment with PersistentVolumeClaims is sufficient for stateful workloads, but the trap is that Deployments do not guarantee stable network identities or ordered pod naming, which are critical for applications like databases that rely on hostname-based clustering.

How to eliminate wrong answers

Option A (DaemonSet) is wrong because it ensures exactly one pod runs on each node, which is ideal for node-level agents (e.g., log collectors, monitoring daemons), not for stateful applications needing stable identities and per-instance storage. Option B (Job) is wrong because it is designed for batch or one-off tasks that run to completion, not for long-running stateful services that require persistent storage and stable network identities. Option C (Deployment) is wrong because it treats pods as ephemeral and interchangeable; while it supports persistent storage via PersistentVolumeClaims, it does not guarantee stable network identities or ordered pod naming, so a rescheduled pod gets a new name and IP, breaking stateful expectations.

Practice this question →

165

MCQhard

A developer creates a Pod with a single container that writes logs to stdout. The Pod is running, but the developer wants to view the last 50 lines of logs from that container and have the command keep streaming new output. Which kubectl command accomplishes this?

A.kubectl logs mypod -c app --tail=50 -f

B.kubectl logs mypod --since=50 -f

C.kubectl describe pod mypod --tail=50 -f

D.kubectl logs mypod --tail=50 --follow=false

AnswerA

This command targets the container named app in the Pod, limits the initial output to the last 50 lines with --tail=50, and follows the log stream with -f. It satisfies both requirements: showing recent history and streaming new entries. The -c flag is necessary only if the Pod has multiple containers, but it is valid and precise here.

Why this answer

The kubectl logs command retrieves container output. The --tail flag limits the number of historical lines, and -f or --follow streams subsequent entries. Combining them gives the last 50 lines plus live updates.

The -c flag selects a container when more than one exists. Other flags such as --since use time durations, and describe is unrelated to log retrieval.

Exam trap

The trap here is confusing --tail, which counts lines, with --since, which takes a time duration.

Practice this question →

166

MCQeasy

Which command is used to create a Deployment that runs an nginx container with 3 replicas?

A.kubectl create pod nginx --image=nginx --replicas=3

B.kubectl run nginx --image=nginx --replicas=3

C.kubectl create deployment nginx --image=nginx --replicas=3

D.kubectl scale deployment nginx --replicas=3

AnswerC

The `--replicas=3` flag on `kubectl create deployment` directly satisfies the stem's three-replica constraint, while `--image=nginx` specifies the container image. This imperative command generates the Deployment manifest server-side, so no YAML file is needed to achieve the required nginx workload at the stated scale.

Why this answer

`kubectl create deployment` is the standard Kubernetes command to create a Deployment resource, and the `--replicas=3` flag directly sets the desired replica count to 3. This command creates a Deployment that manages a ReplicaSet to ensure three nginx pods are running and maintained.

Exam trap

The trap here is that candidates confuse `kubectl run` (which creates a pod, not a deployment with replicas) with `kubectl create deployment`, or they mistakenly think `kubectl scale` can create a deployment, when it only modifies an existing one.

How to eliminate wrong answers

Option A is wrong because `kubectl create pod` does not exist; pods are created imperatively with `kubectl run` or declaratively via a manifest, and `--replicas` is not a valid flag for pod creation. Option B is wrong because `kubectl run` creates a single pod (or a deployment in older versions, but not with `--replicas`); the `--replicas` flag is not supported by `kubectl run` in current Kubernetes versions. Option D is wrong because `kubectl scale deployment` modifies an existing Deployment's replica count, but it does not create a new Deployment; the question asks for creating a Deployment, not scaling an existing one.

Practice this question →

167

MCQeasy

What is a key benefit of container orchestration platforms like Kubernetes?

A.Containers are tightly coupled to the underlying hardware

B.Each container runs its own operating system kernel

C.Containers can only run on a single host

D.Self-healing capabilities automatically restart failed containers

AnswerD

Kubernetes controllers continuously reconcile actual state against desired state; when a container or pod fails, the ReplicaSet creates a replacement automatically. This self-healing loop restores the declared replica count without manual intervention, the benefit described.

Why this answer

Kubernetes provides self-healing capabilities through controllers like ReplicaSets and Deployments, which continuously monitor the desired state of containers. If a container fails or becomes unresponsive, the control plane automatically restarts or reschedules it, ensuring high availability without manual intervention. This is a core benefit of container orchestration platforms, as it abstracts away the operational overhead of managing individual container lifecycles.

Exam trap

A common misconception is that container orchestration is primarily about scaling or deployment, but the key differentiator is the automated recovery and health management that distinguishes orchestration from simple container runtimes.

How to eliminate wrong answers

Option A is wrong because containers are not tightly coupled to underlying hardware; they are abstracted from the host OS via namespaces and cgroups, enabling portability across different infrastructure. Option B is wrong because containers share the host operating system kernel, unlike virtual machines that each run their own kernel; this is a fundamental characteristic of containerization. Option C is wrong because orchestration platforms like Kubernetes are designed to schedule containers across multiple hosts in a cluster, enabling distributed deployment and scaling.

Practice this question →

168

MCQeasy

What is a key benefit of using containers over virtual machines for application deployment?

A.Containers can only run on Linux

B.Containers require a hypervisor to run

C.Containers provide stronger isolation than VMs

D.Containers are more lightweight and start faster than VMs

AnswerD

Containers share the host OS kernel rather than each running a full guest operating system, so they carry no hypervisor overhead and need far less memory and disk. This architectural difference lets container instances start in seconds, directly satisfying the requirement for lightweight, fast-starting deployment compared with virtual machines.

Why this answer

Containers share the host OS kernel and run as isolated processes, requiring no separate guest OS per instance. This makes them significantly more lightweight and faster to start than VMs, which must boot a full guest OS. For application deployment, this translates to higher density, lower resource overhead, and near-instant startup times.

Exam trap

The trap here is that candidates often confuse 'stronger isolation' with 'better security' and pick Option C, not realizing that VMs actually provide stronger isolation due to separate kernels and hardware virtualization, while containers are designed for lightweight efficiency, not maximum isolation.

How to eliminate wrong answers

Option A is wrong because containers are not limited to Linux; Windows containers run on Windows Server and Docker Desktop supports both Linux and Windows containers via appropriate runtimes. Option B is wrong because containers do not require a hypervisor; they run directly on the host OS using kernel features like cgroups and namespaces, whereas VMs require a hypervisor to virtualize hardware. Option C is wrong because VMs provide stronger isolation than containers; each VM has its own separate kernel and hardware virtualization, while containers share the host kernel, making isolation weaker by design.

Practice this question →

169

MCQeasy

Which component is responsible for running containers on a Kubernetes node?

A.kube-controller-manager

B.kube-proxy

C.kube-apiserver

D.kubelet

AnswerD

The kubelet is the node agent that receives PodSpecs from the control plane and instructs the container runtime to start, stop and monitor containers. It satisfies the stem's constraint of running containers on a node, whereas the API server, scheduler and controller manager operate at cluster level.

Why this answer

The kubelet is the primary node agent that runs on each Kubernetes node. It is responsible for ensuring that containers are running in a Pod as expected, by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers based on PodSpecs received from the API server.

Exam trap

The trap here is that candidates often confuse kubelet with kube-controller-manager, thinking the controller manager handles node-level container operations, but the kubelet is the only component that directly manages containers on the node.

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager runs controller processes (like Node Controller, Replication Controller) at the control plane level, not on worker nodes, and does not directly manage containers. Option B is wrong because kube-proxy is a network proxy that handles network rules and service load balancing on each node, but it does not run or manage containers. Option C is wrong because kube-apiserver is the front-end of the Kubernetes control plane that exposes the Kubernetes API; it validates and processes RESTful requests but does not execute container lifecycle operations on nodes.

Practice this question →

170

MCQmedium

You are writing a Deployment YAML (apps/v1) for a stateless web application. The application should have 3 replicas and use rolling updates with maxSurge=1 and maxUnavailable=0. Which field should you set under spec.strategy?

A.type: Recreate

B.type: Canary

C.type: OnDelete

D.type: RollingUpdate with rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }

AnswerD

RollingUpdate is the only strategy type supporting maxSurge and maxUnavailable. Setting maxSurge: 1 and maxUnavailable: 0 adds one new pod before terminating any old pod, guaranteeing three available replicas throughout the rollout, exactly as the stem requires.

Why this answer

The Deployment's `spec.strategy.type` must be set to `RollingUpdate` to enable a controlled, incremental update of pods. The `rollingUpdate` field then allows you to specify `maxSurge: 1` (one extra pod above the desired count during update) and `maxUnavailable: 0` (ensure all existing pods remain available during the update), which is the exact configuration for a zero-downtime rolling update with a single surge pod.

Exam trap

CNCF often tests the misconception that `maxSurge` and `maxUnavailable` are top-level fields under `spec.strategy`, when in fact they must be nested inside `rollingUpdate` and the `type` must explicitly be set to `RollingUpdate`.

How to eliminate wrong answers

Option A is wrong because `type: Recreate` terminates all existing pods before creating new ones, which violates the requirement for a rolling update with `maxSurge` and `maxUnavailable` settings. Option B is wrong because `Canary` is not a valid Deployment strategy type in the `apps/v1` API; it is a separate deployment pattern often implemented via service mesh or progressive delivery tools, not a native Kubernetes Deployment field. Option C is wrong because `OnDelete` is a strategy type used by StatefulSets (not Deployments) and only triggers pod replacement when a pod is manually deleted, which does not support automated rolling updates or the specified surge/unavailable parameters.

Practice this question →

171

MCQmedium

An administrator needs to store a database password for a Pod to consume as an environment variable. The password must be stored securely and not exposed in the Pod specification. Which Kubernetes resource should the administrator create?

A.A ConfigMap

B.A Secret

C.A PersistentVolumeClaim

D.A ServiceAccount

AnswerB

A Secret is designed to hold sensitive data such as passwords, tokens, or keys. It can be mounted as a volume or exposed as an environment variable without embedding the value in the Pod spec. By referencing the Secret in the Pod spec, the administrator keeps the password out of the manifest, matching the security requirement.

Why this answer

Secrets are the Kubernetes resource for storing sensitive data and can be referenced in Pod specs as environment variables or mounted volumes. ConfigMaps are for non-sensitive configuration, PersistentVolumeClaims provide storage, and ServiceAccounts provide API identities. Only a Secret meets the requirement of secure, out-of-manifest password storage.

Exam trap

The trap here is assuming ConfigMaps are suitable for any configuration, including passwords, when they are not designed for sensitive data.

Practice this question →

172

MCQmedium

You need to run a batch job that processes data every hour and exits upon completion. Which Kubernetes resource should you use?

A.Deployment

B.Job

C.DaemonSet

D.CronJob

AnswerD

A CronJob creates Jobs on a repeating schedule, so it runs the batch workload hourly and each Job's pod exits once processing completes. It satisfies both constraints: the hourly recurrence and the requirement that the process terminate rather than run continuously like a Deployment.

Why this answer

The correct choice is CronJob. While a Job is designed to run a finite task to completion, the requirement to run 'every hour' indicates a recurring schedule. A CronJob creates Jobs on a specified schedule, so it is the appropriate resource to use.

The Job itself will run and exit, but the CronJob manages the schedule.

Exam trap

A common pitfall is focusing on the phrase 'exits upon completion' and choosing Job, forgetting that the question specifies a recurring schedule (every hour). CronJob is the scheduler that creates Jobs at specified times; without it, the Job would only run once.

How to eliminate wrong answers

Option A is wrong because a Deployment is intended for long-running, stateless applications that should never exit; it continuously restarts Pods to maintain a desired replica count, which would cause the batch job to run repeatedly rather than exit upon completion. Option C is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, typically for cluster-level services like logging or monitoring, not for a batch job that runs once per hour and exits. Option D is wrong because a CronJob is used to schedule Jobs on a recurring basis (e.g., every hour), but the question specifies that the batch job 'processes data every hour and exits upon completion' — the resource that actually runs and exits is a Job, while the CronJob is the scheduler that creates the Job; the question asks for the resource that runs the workload, not the scheduler.

Practice this question →

173

MCQhard

An administrator needs to ensure that Pods from two different Deployments cannot communicate with each other. Which Kubernetes resource should be used?

A.NetworkPolicy

B.RBAC Role

C.PodSecurityPolicy

D.ResourceQuota

AnswerA

NetworkPolicy selects Pods by label and defines ingress and egress rules, so denying traffic between the two Deployments' label sets isolates them. It operates at layer 3/4 within the cluster, which RBAC or namespaces alone cannot enforce.

Why this answer

NetworkPolicy is the correct resource because it acts as a firewall for Kubernetes Pods, controlling ingress and egress traffic at the IP address and port level using layer 3/4 rules. By applying a NetworkPolicy that denies all traffic between the Pods of the two Deployments (e.g., using podSelector and ingress/egress rules with an empty `from` or `to` block), the administrator can enforce network isolation. This is the native Kubernetes mechanism for restricting Pod-to-Pod communication within a cluster.

Exam trap

The trap here is that candidates confuse NetworkPolicy with RBAC or PodSecurityPolicy, mistakenly thinking that authorization or security contexts can control network traffic, when in fact only NetworkPolicy (with a compatible CNI) provides layer 3/4 isolation.

How to eliminate wrong answers

Option B (RBAC Role) is wrong because RBAC controls authorization for Kubernetes API operations (e.g., creating Pods, reading Secrets) and does not manage network traffic between Pods. Option C (PodSecurityPolicy) is wrong because it defines security constraints on Pods (e.g., privileged containers, host namespaces) but has no effect on network communication between Pods. Option D (ResourceQuota) is wrong because it limits aggregate resource consumption (CPU, memory, storage) per namespace and cannot restrict network connectivity between Pods.

Practice this question →

174

MCQmedium

An administrator wants to allow a Pod to consume a ConfigMap named app-config as environment variables, but only the keys DB_HOST and DB_PORT. The ConfigMap contains additional keys. Which Pod spec snippet correctly injects only those two keys as environment variables?

A.env: - name: DB_HOST value: app-config.DB_HOST - name: DB_PORT value: app-config.DB_PORT

B.envFrom: - configMapRef: name: app-config

C.env: - name: DB_HOST valueFrom: configMapKeyRef: name: app-config key: DB_HOST - name: DB_PORT valueFrom: configMapKeyRef: name: app-config key: DB_PORT

D.volumeMounts: - name: config mountPath: /etc/config volumes: - name: config configMap: name: app-config

AnswerC

Using valueFrom with configMapKeyRef allows selecting individual keys from a ConfigMap. Each env entry names the environment variable and references a specific key. This injects only DB_HOST and DB_PORT and ignores other keys. It is the precise way to map selected ConfigMap keys into environment variables.

Why this answer

To inject specific ConfigMap keys as environment variables, each env entry must use valueFrom.configMapKeyRef with the ConfigMap name and key. This maps only the chosen keys. envFrom injects all keys, volume mounts expose keys as files, and the value field sets literal strings. The scenario requires selective environment variable injection.

Exam trap

The trap here is confusing envFrom, which imports all keys, with valueFrom.configMapKeyRef, which selects individual keys.

Practice this question →

175

Multi-Selectmedium

A platform engineer is troubleshooting a Pod that stays in the Pending phase. Which two conditions can legitimately cause a Pod to remain Pending? (Choose two.)

Select 2 answers

A.No node in the cluster has sufficient allocatable CPU or memory to satisfy the Pod's resource requests.

B.The Pod's liveness probe is failing repeatedly.

C.A nodeSelector or node affinity rule matches no nodes in the cluster.

D.The container's application process exits with a non-zero exit code.

E.The Pod's image tag does not exist in the registry.

AnswersA, C

Insufficient allocatable resources on all candidate nodes is a classic cause of Pending status. The scheduler cannot bind the Pod to any node because its resource requests cannot be satisfied, so the Pod remains unscheduled. Examining scheduler events and node allocatable capacity reveals this condition directly.

Why this answer

Pending means the Pod has been accepted by the API server but not yet scheduled to a node. The two legitimate causes here are scheduling constraints: insufficient allocatable CPU or memory across candidate nodes, and node affinity or nodeSelector rules that match no nodes. Image pull failures, probe failures, and application crashes occur after scheduling and therefore do not produce a Pending phase.

Exam trap

The trap here is conflating container runtime failures such as image pull errors and probe failures with scheduling failures, when only scheduling constraints leave a Pod in Pending.

Practice this question →

176

MCQmedium

Which command correctly creates a Deployment named 'web-app' with the image 'nginx:1.21' and 3 replicas?

A.kubectl apply deployment web-app --image=nginx:1.21 --replicas=3

B.kubectl run web-app --image=nginx:1.21 --replicas=3

C.kubectl create deployment web-app --image=nginx:1.21 --replicas=3

D.kubectl create deployement web-app --image=nginx:1.21 --replicas=3

AnswerC

`kubectl create deployment` generates the Deployment manifest imperatively, and the `--replicas=3` flag sets `.spec.replicas` directly, satisfying the stem's three-replica constraint. The `--image=nginx:1.21` flag populates the container spec with the exact pinned tag, so a single command yields the named 'web-app' Deployment.

Why this answer

`kubectl create deployment` is the imperative command specifically designed to create a Deployment resource in Kubernetes. The `--image` flag specifies the container image, and `--replicas=3` sets the desired number of pod replicas, which matches the requirement exactly.

Exam trap

CNCF often tests the distinction between `kubectl run` (which creates a Pod, not a Deployment) and `kubectl create deployment` (which creates a Deployment with replica management), leading candidates to mistakenly choose `kubectl run` when replicas are required.

How to eliminate wrong answers

Option A is wrong because `kubectl apply` requires a manifest file or stdin input; it does not accept `--image` or `--replicas` flags directly, and the syntax `apply deployment` is invalid. Option B is wrong because `kubectl run` creates a Pod (or a Deployment only in older versions with certain flags), but it does not support the `--replicas` flag; it is used for ad-hoc pods, not multi-replica Deployments. Option D is wrong because `deployement` is a misspelling of `deployment`, which causes a command syntax error; Kubernetes CLI commands are case-sensitive and must match the exact resource name.

Practice this question →

177

MCQeasy

Which of the following describes the Open Container Initiative (OCI) image specification?

A.A standard for container images and runtimes

B.A specification for container orchestration

C.A specification for container storage

D.A specification for container networking

AnswerA

The OCI image specification defines a vendor-neutral format for container images, covering the manifest, configuration, and filesystem layers. This satisfies the stem's requirement for a standardised image definition, distinct from runtime concerns, which the separate OCI runtime specification addresses. It enables portability across compliant registries and engines.

Why this answer

The Open Container Initiative (OCI) image specification defines a standard format for container images, ensuring that any OCI-compliant image can be run by any OCI-compliant runtime (e.g., runc, crun). This specification covers the image manifest, filesystem layers, and configuration, enabling interoperability across different container platforms like Docker, Podman, and containerd. Option A is correct because the OCI specifically standardizes both the image format and the runtime behavior, not higher-level orchestration or infrastructure concerns.

Exam trap

CNCF often tests the distinction between OCI (image/runtime) and CNI/CSI (networking/storage), so the trap here is that candidates confuse the OCI specification with other container ecosystem standards like CNI or CSI due to similar acronyms and overlapping container contexts.

How to eliminate wrong answers

Option B is wrong because container orchestration is the domain of tools like Kubernetes, Docker Swarm, and Nomad, which manage scheduling, scaling, and service discovery—not the OCI image specification. Option C is wrong because container storage is addressed by separate standards like the Container Storage Interface (CSI), which defines how storage systems are exposed to containerized workloads, not by the OCI image spec. Option D is wrong because container networking is governed by the Container Network Interface (CNI), which specifies how network plugins configure network interfaces for containers, whereas the OCI image spec focuses solely on image and runtime standards.

Practice this question →

178

MCQhard

A developer creates a Deployment with 3 replicas. After updating the pod template, they run 'kubectl rollout status deployment/my-deployment' and see that the rollout is stuck. Which command should they use to investigate the rollout history?

A.kubectl get events

B.kubectl describe deployment my-deployment

C.kubectl rollout history deployment/my-deployment

D.kubectl logs deployment/my-deployment

AnswerC

The rollout history subcommand queries the Deployment's recorded revisions, showing each revision number and change-cause annotation. This reveals whether a bad revision or stalled progression caused the stuck rollout, directly satisfying the need to investigate rollout history.

Why this answer

'kubectl rollout history' is the dedicated command to view the revision history of a Deployment, including the changes made to the pod template in each revision. When a rollout is stuck, this command helps identify which revision caused the issue and allows you to roll back to a previous stable revision. The other commands provide general debugging information but do not specifically show the rollout history.

Exam trap

CNCF often tests the distinction between commands that show current state (describe, get events) versus commands that show historical state (rollout history), trapping candidates who confuse 'investigating the rollout history' with general troubleshooting.

How to eliminate wrong answers

Option A is wrong because 'kubectl get events' shows cluster-wide events (e.g., pod scheduling failures, image pull errors) but does not display the revision history of a Deployment's rollouts. Option B is wrong because 'kubectl describe deployment' shows the current state and conditions of the Deployment (including rollout status) but does not list the historical revisions or changes to the pod template. Option D is wrong because 'kubectl logs' is used to fetch logs from a running container, not to inspect Deployment revision history; it cannot be used directly on a Deployment object and requires a pod name.

Practice this question →

179

Multi-Selectmedium

Which TWO statements about Docker Compose and Kubernetes are correct?

Select 2 answers

A.Kubernetes is only used in production environments

B.Docker Compose and Kubernetes use the same YAML manifest format

C.Kubernetes provides built-in auto-scaling and self-healing capabilities

D.Docker Compose is designed for single-host container orchestration

E.Docker Compose supports multi-node clustering out-of-the-box

AnswersC, D

Kubernetes reconciles desired state through controllers: the ReplicaSet controller replaces failed pods, while the Horizontal Pod Autoscaler scales replicas based on CPU or custom metrics. This satisfies the stem's requirement for built-in auto-scaling and self-healing, capabilities Docker Compose lacks natively.

Why this answer

Option C is correct because Kubernetes natively provides controllers such as the Horizontal Pod Autoscaler (HPA) for auto-scaling and ReplicaSets/Deployments with liveness and readiness probes for self-healing, restarting or rescheduling failed pods automatically. Option D is correct because Docker Compose orchestrates containers on a single Docker host using a docker-compose.yml file and the docker compose CLI, without any native multi-node scheduling. Option A is wrong because Kubernetes is also widely used in development, testing, edge, and CI environments, not only production.

Option B is wrong because although both use YAML, their manifest schemas differ: Compose uses keys like services, image, and ports, while Kubernetes uses apiVersion, kind, metadata, and spec. Option E is wrong because Docker Compose has no built-in multi-node clustering; Docker Swarm or Kubernetes are needed for that.

Exam trap

A common misconception is that Docker Compose and Kubernetes use the same YAML format, but they are distinct schemas with different top-level keys and resource definitions. Candidates may confuse 'docker-compose.yml' with Kubernetes manifests.

Practice this question →

180

MCQmedium

A team deploys a microservice that requires sticky sessions. The service runs on Kubernetes with multiple replicas. Which Kubernetes resource should be used to ensure requests from a client are consistently routed to the same pod?

A.Headless Service

B.Service with sessionAffinity: ClientIP

C.Ingress with default settings

D.Deployment with hostNetwork: true

AnswerB

Setting sessionAffinity: ClientIP on the Service makes kube-proxy route repeated requests from the same client IP to the same backend pod, satisfying the sticky session requirement across multiple replicas without an Ingress or external load balancer.

Why this answer

Setting `sessionAffinity: ClientIP` on a Kubernetes Service ensures that all requests from the same client IP are routed to the same Pod. This is the standard Kubernetes mechanism for implementing sticky sessions without requiring changes to the application or ingress layer.

Exam trap

CNCF often tests the misconception that Ingress or Headless Services can handle session affinity by default, but only a Service with `sessionAffinity: ClientIP` provides this at the Kubernetes networking layer without additional configuration.

How to eliminate wrong answers

Option A is wrong because a Headless Service does not provide load balancing or session affinity; it returns the IPs of all Pods directly, requiring the client to handle routing. Option C is wrong because an Ingress with default settings does not maintain session affinity; it typically passes traffic to a Service without any stickiness, and Ingress controllers like NGINX require additional annotations (e.g., `nginx.ingress.kubernetes.io/affinity`) to enable sticky sessions. Option D is wrong because `hostNetwork: true` binds the Pod directly to the node's network stack, bypassing Kubernetes service networking entirely, and does not provide any session affinity mechanism.

Practice this question →

181

MCQeasy

A developer wants to run a single instance of a stateless web application in a Kubernetes cluster. The application does not need to maintain state or have a stable network identity. Which workload resource is the most appropriate to use?

A.Deployment

B.StatefulSet

C.DaemonSet

D.Job

AnswerA

A Deployment is ideal for stateless applications as it manages ReplicaSets and provides declarative updates, scaling, and self-healing. It allows you to define the desired state, and the Deployment controller ensures the actual state matches, handling pod creation and replacement automatically. This is the standard choice for stateless web applications.

Why this answer

A Deployment is the standard Kubernetes resource for managing stateless applications. It provides declarative updates, scaling, and self-healing by managing ReplicaSets. For a stateless web application that does not require stable identities or persistent storage, a Deployment offers the right balance of simplicity and functionality, ensuring the application remains available and can be updated seamlessly.

Exam trap

The trap here is confusing stateless and stateful workloads; Deployments are for stateless, while StatefulSets are for stateful applications requiring stable identities.

Practice this question →

182

MCQmedium

You have a Kubernetes cluster with multiple nodes. You need to ensure that a pod runs on a node that has an SSD. How should you achieve this?

A.Manually edit kube-scheduler configuration

B.Use a DaemonSet to run the pod on all nodes

C.Use a nodeSelector with the label 'disktype: ssd'

D.Use a toleration for the node

AnswerC

nodeSelector constrains scheduling by matching pod requirements against node labels. Labelling SSD nodes with disktype=ssd and setting that selector in the pod spec forces the scheduler to place the pod only on nodes carrying that label.

Why this answer

NodeSelector is the simplest and most direct way to constrain a Pod to run only on nodes that have a specific label, such as 'disktype=ssd'. When you add a nodeSelector field to the Pod spec, the kube-scheduler filters nodes that do not have the matching label, ensuring the Pod lands on a node with an SSD.

Exam trap

The trap here is confusing tolerations (which allow scheduling onto tainted nodes) with node selection mechanisms like nodeSelector or nodeAffinity, leading candidates to pick D when they need a label-based constraint.

How to eliminate wrong answers

Option A is wrong because manually editing the kube-scheduler configuration is unnecessary and overly complex; node scheduling constraints are handled via Pod spec fields like nodeSelector, nodeAffinity, or taints/tolerations, not by modifying the scheduler itself. Option B is wrong because a DaemonSet runs a copy of the Pod on every node (or a subset defined by nodeSelector), but the question asks to ensure the Pod runs on a node with an SSD, not on all nodes. Option D is wrong because tolerations are used to allow Pods to schedule onto nodes with matching taints, not to select nodes based on labels like 'disktype=ssd'; tolerations alone do not guarantee placement on a specific node type.

Practice this question →

183

MCQmedium

A cluster administrator needs to schedule a pod that requires 4 CPU cores and 16Gi of memory on a node with sufficient resources. The pod also must tolerate a taint on a dedicated node. Which combination of pod spec fields must be set to ensure the pod lands on the correct node?

A.resources.limits and nodeSelector

B.tolerations and resources.limits

C.affinity and resources.limits

D.resources.requests and tolerations

AnswerD

resources.requests tells the scheduler the minimum CPU and memory needed, so it only considers nodes with enough allocatable capacity. tolerations allow the pod to be scheduled onto a node with a matching taint, overriding the default eviction behaviour. Together they ensure the pod is placed on a node that both fits the resource requirements and is permitted by the taint.

Why this answer

The scheduler uses resource requests to filter nodes that have enough allocatable CPU and memory. Tolerations are required to permit scheduling onto a node with a taint. Limits and nodeSelector do not satisfy the dual requirement of resource fit and taint tolerance.

Therefore, the pod must specify both requests and tolerations.

Exam trap

The trap here is confusing resource limits with requests; limits do not influence scheduling decisions, only requests do.

Practice this question →

184

MCQmedium

A cluster administrator needs to run a node-level log-shipping agent on every node, including nodes added later, and wants the agent to tolerate the control-plane taint. Which workload API object is the most appropriate choice?

A.A StatefulSet with podAntiAffinity requiring one Pod per node.

B.A ReplicaSet with replicas equal to the current node count.

C.A Deployment with a nodeSelector for each existing node name.

D.A DaemonSet with a toleration for the control-plane taint.

AnswerD

A DaemonSet ensures that a copy of a Pod runs on every eligible node and automatically schedules new Pods onto nodes that join the cluster. Adding a toleration for the control-plane taint lets the agent also run on control-plane nodes. This directly matches the requirement for continuous node-level coverage across existing and future nodes.

Why this answer

A DaemonSet is designed for node-level agents such as log shippers, monitoring exporters, and CNI plugins. It places one Pod on each node that matches scheduling constraints and automatically covers nodes that join later. Combining it with a toleration for the control-plane taint allows the agent to run on control-plane nodes as well, satisfying the administrator's full-coverage requirement.

Exam trap

The trap here is treating a Deployment or ReplicaSet as a one-Pod-per-node mechanism, when only a DaemonSet automatically maintains node-level coverage including newly added nodes.

Practice this question →

185

Multi-Selectmedium

Which TWO of the following correctly describe the difference between Docker Compose and Kubernetes? (Choose 2)

Select 2 answers

A.Docker Compose can manage containers across multiple hosts

B.Docker Compose is suitable for production-grade deployments

C.Kubernetes provides built-in auto-scaling and self-healing

D.Kubernetes supports rolling updates and rollbacks

E.Both Docker Compose and Kubernetes use the same YAML format

AnswersC, D

Kubernetes offers features like HorizontalPodAutoscaler and ReplicaSet controllers for auto-scaling and self-healing.

Why this answer

Docker Compose is designed for single-host container orchestration with a simple YAML file, while Kubernetes is a multi-host container orchestration platform with advanced features like auto-scaling and self-healing.

Practice this question →

186

Multi-Selecthard

Which THREE of the following are true about the Container Runtime Interface (CRI)? (Choose 3)

Select 3 answers

A.Docker natively implements the CRI

B.CRI is part of the Open Container Initiative (OCI)

C.CRI allows kubelet to communicate with different container runtimes

D.containerd implements the CRI

E.CRI-O is a lightweight runtime designed for Kubernetes

AnswersC, D, E

CRI is the abstraction layer between kubelet and container runtimes, defining gRPC services (RuntimeService, ImageService) so kubelet can drive containerd, CRI-O or others without runtime-specific code. This directly satisfies the stem's requirement that CRI enables kubelet to communicate with different container runtimes.

Why this answer

Option C is correct because the Container Runtime Interface is precisely the gRPC API that kubelet uses to talk to a container runtime, decoupling Kubernetes from any single runtime implementation. Option D is correct because containerd ships a built-in CRI plugin (enabled by default) that lets kubelet use containerd directly as a CRI-compliant runtime. Option E is correct because CRI-O is a lightweight OCI-compliant container runtime built specifically to serve as a Kubernetes CRI implementation.

Option A is not correct because Docker does not natively implement CRI; the historical dockershim adapter was needed to bridge kubelet to Docker, and it has since been removed. Option B is not correct because CRI is a Kubernetes project specification, not part of the Open Container Initiative, which instead defines the OCI runtime and image specifications.

Exam trap

KCNA often tests the misconception that Docker is a CRI runtime or that CRI is an OCI standard — candidates must distinguish Kubernetes' CRI from OCI's image/runtime specs.

Practice this question →

187

MCQhard

An administrator wants to ensure that a pod only runs on nodes that have a specific GPU. Which mechanism should be used to achieve this?

A.Node affinity with requiredDuringSchedulingIgnoredDuringExecution

B.Tolerations and taints

C.Pod anti-affinity

D.ResourceQuota

AnswerA

Node affinity with requiredDuringSchedulingIgnoredDuringExecution enforces a hard scheduling rule, so the pod is placed only on nodes whose labels match the specified GPU. This satisfies the constraint that the pod must run exclusively on GPU-equipped nodes.

Why this answer

Node affinity with `requiredDuringSchedulingIgnoredDuringExecution` is the correct mechanism because it allows you to specify hard constraints that a pod must be scheduled on a node with a specific label (e.g., `gpu-type: nvidia-tesla`). This ensures the pod is only placed on nodes that have the required GPU hardware, as the scheduler will enforce the rule during scheduling and ignore it after the pod is running.

Exam trap

Kubernetes often tests the distinction between node affinity (attracting pods to nodes) and taints/tolerations (repelling pods from nodes), leading candidates to mistakenly choose tolerations when the requirement is to ensure a pod runs only on nodes with a specific resource.

How to eliminate wrong answers

Option B is wrong because tolerations and taints are used to repel pods from nodes (unless they tolerate the taint), not to attract pods to nodes with specific hardware; they control which pods can be scheduled on a node, not which nodes a pod must run on. Option C is wrong because pod anti-affinity is used to prevent pods from being co-located on the same node or topology (e.g., for high availability), not to enforce placement on nodes with specific resources like GPUs. Option D is wrong because a ResourceQuota limits the total resources (e.g., CPU, memory) consumed by all pods in a namespace, but it cannot constrain a pod to run only on nodes with a specific GPU.

Practice this question →

188

MCQmedium

Which Kubernetes resource is best suited for running a batch processing job that must complete successfully exactly once?

A.DaemonSet

B.Deployment

C.CronJob

D.Job

AnswerD

A Job creates one or more pods and tracks successful completions, restarting pods only until the required count succeeds. This directly satisfies the stem's "complete successfully exactly once" constraint, unlike a Deployment or ReplicaSet, which maintain continuous availability rather than terminating after completion.

Why this answer

A Kubernetes Job is designed specifically for batch processing tasks that need to run to completion exactly once. It creates one or more Pods and ensures that a specified number of them successfully terminate, making it ideal for workloads like data processing or backups that must finish without retries or restarts.

Exam trap

CNCF often tests the distinction between one-time batch processing (Job) and recurring scheduled tasks (CronJob), so candidates mistakenly choose CronJob when the question specifies 'exactly once' rather than 'on a schedule'.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, which is used for continuous background services like logging or monitoring, not for one-time batch jobs. Option B is wrong because a Deployment manages a set of Pods to maintain a desired number of replicas running indefinitely, with rolling updates and self-healing, which is unsuitable for a job that must complete and not restart. Option C is wrong because a CronJob is used for scheduling recurring tasks on a time-based schedule, not for a one-time batch job that must run exactly once.

Practice this question →

189

Multi-Selectmedium

Which TWO of the following are true about the Open Container Initiative (OCI)?

Select 2 answers

A.OCI requires the use of containerd

B.OCI defines the Dockerfile format

C.OCI is a Linux Foundation project

D.OCI specifies the image format and runtime specification

E.OCI defines the Container Runtime Interface (CRI)

AnswersC, D

OCI is hosted under the Linux Foundation.

Why this answer

The Open Container Initiative (OCI) is a Linux Foundation project that was established to create open industry standards around container formats and runtimes. It operates under the Linux Foundation's governance to ensure vendor-neutral specifications.

Exam trap

The trap here is that candidates often confuse OCI with Kubernetes-specific components like CRI or assume OCI mandates a particular runtime like containerd, when in fact OCI is a vendor-neutral standard that does not enforce any specific implementation.

Practice this question →

190

MCQeasy

Which of the following is an example of immutable infrastructure?

A.SSH into a server to apply patches

B.Manually installing packages on a running container

C.Using configuration management tools to update software on running servers

D.Rebuilding a server from a pre-baked image and replacing the old one

AnswerD

Immutable infrastructure means servers are never patched in place. Instead, a new server is built from a pre-baked image and swapped in for the old one, which is then destroyed. This replacement model is the defining characteristic.

Why this answer

Immutable infrastructure means that once a server or container is deployed, it is never modified in place. Instead, any change requires building a new image and redeploying. Option D describes exactly this: rebuilding from a pre-baked image and replacing the old server, which is the core pattern of immutability in container orchestration (e.g., Kubernetes rolling updates or Recreate deployments).

Exam trap

CNCF often tests the misconception that configuration management tools (like Ansible or Puppet) are inherently immutable, but they are actually used for mutable infrastructure because they apply changes to running systems rather than replacing them entirely.

How to eliminate wrong answers

Option A is wrong because SSHing into a server to apply patches is a classic mutable infrastructure pattern — it modifies a running system in place, which breaks the immutability principle. Option B is wrong because manually installing packages on a running container directly alters its filesystem and state, making it mutable and unreproducible from the original image. Option C is wrong because using configuration management tools (like Ansible or Chef) to update software on running servers still mutates the live environment, which is the opposite of the immutable approach where changes are made only at the image build stage.

Practice this question →

191

MCQmedium

A Kubernetes cluster runs a critical application in a pod. The operations team wants to receive an alert if the application's main process stops responding to HTTP requests on port 8080 at path /healthz. They need Kubernetes to automatically restart the pod if the health check fails. Which type of probe should they configure?

A.startupProbe

B.httpProbe

C.livenessProbe

D.readinessProbe

AnswerC

A liveness probe checks if the container is still running and responsive. If the liveness probe fails, the kubelet kills the container and restarts it according to the pod's restart policy. This is exactly what the team needs: automatic restart upon health check failure to recover from unresponsive states.

Why this answer

A liveness probe is used to determine if a container is alive and healthy. When it fails, the kubelet restarts the container, which helps recover from deadlocks or unresponsive states. Configuring an HTTP liveness probe on port 8080 at /healthz will cause Kubernetes to periodically send HTTP GET requests; if the response is not successful, the container is restarted, meeting the alert and restart requirement.

Exam trap

The trap here is confusing liveness and readiness probes; liveness restarts the container on failure, while readiness only controls traffic routing without restarting.

Practice this question →

192

MCQmedium

A pod is in the 'Pending' state. Which of the following is a likely cause?

A.The liveness probe is failing

B.The container image is not found in the registry

C.No node has sufficient resources to run the pod

D.The container exited with OOMKilled

AnswerC

The scheduler cannot bind the pod to any node because each candidate lacks allocatable CPU or memory to satisfy the pod's resource requests. Unschedulable pods remain Pending with a FailedScheduling event, so insufficient node capacity is the direct cause here.

Why this answer

A pod enters the 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is insufficient cluster resources (CPU, memory, or ephemeral storage) on any available node to satisfy the pod's resource requests. The Kubernetes scheduler continuously evaluates node resource availability and will leave the pod in Pending until a suitable node is found or the request times out.

Exam trap

CNCF often tests the distinction between pod scheduling failures (Pending) and runtime failures (CrashLoopBackOff, OOMKilled, ImagePullBackOff), tempting candidates to confuse post-scheduling errors with pre-scheduling conditions.

How to eliminate wrong answers

Option A is wrong because a failing liveness probe causes the pod to be restarted (CrashLoopBackOff) or marked as Unhealthy, but does not prevent the pod from being scheduled; the pod must first be Running for probes to execute. Option B is wrong because an image not found in the registry results in an ImagePullBackOff or ErrImagePull error, which occurs after the pod is scheduled to a node, not while it is still in Pending. Option D is wrong because OOMKilled (exit code 137) is a container termination reason that occurs after the pod is Running, not during the scheduling phase; it would be visible in the pod status as CrashLoopBackOff or Terminated.

Practice this question →

193

MCQeasy

A team runs a stateless API as a Deployment with six replicas across three nodes. They need a stable virtual IP and DNS name that load-balances TCP traffic to the ready replicas from other Pods in the same cluster. Which resource should they create?

A.A Service of type ClusterIP with a selector matching the Pod labels.

B.A Service of type NodePort with externalTrafficPolicy: Local.

C.An Ingress resource with a path rule for /api.

D.A NetworkPolicy that allows ingress from the API namespace.

AnswerA

A ClusterIP Service provides a stable virtual IP and DNS name inside the cluster and load-balances connections to Pods whose labels match the selector. It only includes endpoints that pass readiness checks, which fits the requirement for TCP access to ready replicas. This is the standard in-cluster exposure mechanism for a stateless API.

Why this answer

A ClusterIP Service is the native Kubernetes way to give a set of Pods a stable in-cluster virtual IP and DNS name, with kube-proxy load-balancing connections across ready endpoints. NodePort, Ingress, and NetworkPolicy serve different purposes: external node-level exposure, HTTP routing, and traffic filtering, respectively. For internal TCP load balancing to ready replicas, a ClusterIP Service with a matching selector is correct.

Exam trap

The trap here is selecting NodePort or Ingress for internal-only TCP access, when a ClusterIP Service already provides a stable virtual IP and DNS name inside the cluster.

Practice this question →

194

Multi-Selecthard

Which TWO statements accurately describe Kubernetes scheduling?

Select 3 answers

A.The kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints.

B.Tolerations allow a pod to be scheduled on a node with matching taints.

C.A pod with no resource requests will always be scheduled on the node with the most available resources.

D.Node affinity allows a pod to specify preferred or required nodes for scheduling.

E.Taints are applied to pods to prevent them from being scheduled on certain nodes.

AnswersA, B, D

Correct because the kube-scheduler assigns pods to nodes based on resource availability and constraints.

Why this answer

The kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints. Node affinity allows a pod to specify preferred or required nodes for scheduling. Tolerations are applied to pods and allow the scheduler to schedule pods onto nodes with matching taints (though they do not guarantee scheduling).

Taints are applied to nodes, not pods, to repel pods that do not tolerate them. A pod with no resource requests can be scheduled on any node with sufficient capacity, not necessarily the one with the most resources.

Exam trap

The KCNA exam often tests the distinction between taints (applied to nodes) and tolerations (applied to pods), and the trap here is confusing the direction of the relationship — candidates may incorrectly think taints are applied to pods to prevent scheduling on certain nodes.

Practice this question →

195

MCQeasy

Which of the following is a key difference between containers and virtual machines?

A.Containers share the host OS kernel; VMs run a separate guest OS

B.Both containers and VMs share the host kernel

C.Containers have a full guest OS, VMs share the host kernel

D.Containers require a hypervisor, VMs do not

AnswerA

Containers share the host's kernel and isolate processes, so they carry no guest OS. VMs each run a complete guest operating system on virtualised hardware. This architectural difference explains containers' smaller footprint and faster startup compared with VMs.

Why this answer

The key difference is that containers virtualize at the operating system level, sharing the host OS kernel via namespaces and cgroups, while each virtual machine runs a full, separate guest OS on top of a hypervisor. This architectural distinction means containers are more lightweight and start faster, but VMs provide stronger isolation because they do not share the host kernel.

Exam trap

CNCF often tests the misconception that containers and VMs are fundamentally similar in kernel sharing, leading candidates to choose Option B, which incorrectly claims both share the host kernel.

How to eliminate wrong answers

Option B is wrong because it states both containers and VMs share the host kernel; in reality, VMs run a separate guest OS with its own kernel and do not share the host kernel. Option C is wrong because it reverses the relationship: containers do not have a full guest OS—they share the host kernel—while VMs run a full guest OS. Option D is wrong because it claims containers require a hypervisor and VMs do not; in fact, VMs require a hypervisor (Type 1 or Type 2) to manage guest OSes, while containers run directly on the host OS without a hypervisor.

Practice this question →

196

MCQmedium

A Kubernetes cluster has a Deployment running three replicas of an application. You need to update the container image to a new version with zero downtime. Which approach is most appropriate?

A.Use 'kubectl set image deployment/<name> <container>=<new-image>' to trigger a rolling update

B.Manually delete each pod and rely on the ReplicaSet to recreate them with the new image

C.Delete the Deployment and recreate it with the new image

D.Scale the Deployment to zero and then scale back up with the new image

AnswerA

Setting the image on the Deployment triggers a rolling update, which incrementally replaces pods while respecting readiness probes and maxUnavailable, so traffic continues throughout. This satisfies the zero-downtime constraint, unlike recreating pods or editing a ReplicaSet directly.

Why this answer

`kubectl set image deployment/<name> <container>=<new-image>` triggers a rolling update, which is the default update strategy for Deployments. This gradually replaces old pods with new ones, ensuring that the desired number of replicas is always available, thus achieving zero downtime.

Exam trap

CNCF often tests the misconception that manually deleting pods or scaling to zero is a valid zero-downtime strategy, but these actions cause service disruption because they do not maintain the desired number of available replicas during the update.

How to eliminate wrong answers

Option B is wrong because manually deleting pods does not update the Deployment's pod template; the ReplicaSet will recreate pods using the old image, not the new one. Option C is wrong because deleting the Deployment causes a period of unavailability until the new Deployment is created and pods are scheduled, violating zero downtime. Option D is wrong because scaling to zero removes all pods, causing downtime, and scaling back up with a new image requires a separate update step, which is not a zero-downtime approach.

Practice this question →

197

MCQeasy

What is the purpose of the Container Runtime Interface (CRI)?

A.To manage container networking

B.To define a standard for container images

C.To orchestrate multi-container pods

D.To allow kubelet to communicate with different container runtimes

AnswerD

CRI is the abstraction layer defining gRPC interfaces that let kubelet manage containers without embedding runtime-specific code, so containerd, CRI-O and others plug in interchangeably. This satisfies the stem's requirement for kubelet communicating with different container runtimes.

Why this answer

The Container Runtime Interface (CRI) is a plugin interface that enables the kubelet to use a variety of container runtimes without needing to recompile the Kubernetes components. It defines the API for creating, starting, stopping, and deleting containers, allowing the kubelet to communicate with runtimes like containerd, CRI-O, or Docker (via dockershim, now deprecated). Option D is correct because the CRI's primary purpose is to abstract the runtime implementation from the kubelet, enabling interoperability.

Exam trap

The trap here is that candidates confuse the CRI with the CNI or OCI, assuming the CRI manages networking or image standards, when in fact it strictly defines the runtime API for container lifecycle operations.

How to eliminate wrong answers

Option A is wrong because container networking is managed by the Container Network Interface (CNI), not the CRI. Option B is wrong because container image standards are defined by the Open Container Initiative (OCI) image spec, not the CRI. Option C is wrong because orchestrating multi-container pods is a core function of the kubelet and the Kubernetes control plane, not the CRI; the CRI only handles the low-level runtime operations for individual containers within a pod.

Practice this question →

198

Multi-Selecthard

A DevOps engineer is designing a Kubernetes architecture for a stateful application that requires stable network identities and persistent storage across pod rescheduling. The engineer needs to choose the appropriate Kubernetes resource types to meet these requirements. Which two resources should the engineer use? (Choose two.)

Select 2 answers

A.DaemonSet

B.StatefulSet

C.ConfigMap

D.Deployment

E.PersistentVolumeClaim

AnswersB, E

A StatefulSet provides stable, unique network identifiers (e.g., pod-0, pod-1) and stable storage through VolumeClaimTemplates. It is designed for stateful applications that require ordered deployment, scaling, and persistent volumes per pod. This directly meets the requirement for stable identities and storage across rescheduling.

Why this answer

StatefulSet is the workload controller that provides stable network identities and ordered management for stateful applications. PersistentVolumeClaim, when used in a StatefulSet's volumeClaimTemplates, ensures each pod gets its own persistent storage that survives rescheduling. Together, they meet the requirements for stable identity and persistent data.

Exam trap

The trap here is confusing stateless and stateful workload controllers, or assuming that a Deployment can provide stable identities when it cannot.

Practice this question →

199

MCQmedium

A developer creates a Pod with a single container that writes logs to stdout. The Pod is scheduled and running, but the developer needs to view the logs from the past hour. Which kubectl command should the developer use?

A.kubectl get events --field-selector involvedObject.name=mypod

B.kubectl describe pod mypod

C.kubectl logs mypod --since=1h

D.kubectl exec mypod -- cat /var/log/app.log

AnswerC

The kubectl logs command retrieves container logs, and the --since flag limits output to logs generated within a relative duration. Using --since=1h returns only entries from the last hour, exactly matching the requirement. It works for a single-container Pod without needing a container name.

Why this answer

Container logs are captured from stdout and stderr by the container runtime and exposed through kubectl logs. The --since flag filters entries by relative time, so --since=1h returns exactly the last hour. Describing the Pod, executing commands inside the container, or listing events all fail to retrieve the application's stdout logs.

Exam trap

The trap here is assuming kubectl describe or kubectl get events includes application logs, when they only show metadata and cluster events.

Practice this question →

200

MCQhard

Which Kubernetes resource can be used to define network policies that control traffic between pods?

A.Service

B.PodSecurityPolicy

C.NetworkPolicy

D.Ingress

AnswerC

NetworkPolicy is the native Kubernetes API object that selects pods via label selectors and defines ingress and egress rules, so it directly satisfies the requirement to control traffic between pods. It operates at layer 3/4 and requires a CNI plugin that enforces the policies.

Why this answer

NetworkPolicy is a Kubernetes resource that defines how groups of pods are allowed to communicate with each other and other network endpoints. It works by specifying ingress and egress rules using pod selectors, namespace selectors, and IP blocks, and is enforced by a network plugin (CNI) that supports it, such as Calico or Cilium.

Exam trap

CNCF often tests the misconception that Ingress or Service can restrict pod-to-pod traffic, but Ingress only handles external HTTP/HTTPS traffic and Service only provides connectivity, not policy enforcement.

How to eliminate wrong answers

Option A is wrong because a Service is an abstraction that exposes a set of pods as a network service, but it does not control traffic between pods via rules; it only provides stable endpoints and load balancing. Option B is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) controls security-sensitive aspects of pod specification (e.g., privilege escalation, host namespaces), not network traffic between pods. Option D is wrong because an Ingress manages external HTTP/HTTPS traffic to services inside the cluster, not east-west traffic between pods.

Practice this question →

201

MCQhard

Your application consists of a frontend and a backend. The frontend needs to communicate with the backend using a stable DNS name. The backend is deployed as a Deployment with 3 replicas. Which Kubernetes resource should you create to provide a stable DNS name for the backend?

A.EndpointSlice

B.Service of type NodePort

C.Ingress

D.Service of type ClusterIP

AnswerD

A ClusterIP Service assigns a stable virtual IP and DNS name, load-balancing across the Deployment's three pod replicas. Pod IPs change on restart, so the Service abstraction provides the consistent in-cluster DNS name the frontend requires.

Why this answer

A Service of type ClusterIP provides a stable virtual IP and DNS name (e.g., my-service.namespace.svc.cluster.local) that load-balances traffic across the backend Pods. This is the correct resource because the frontend only needs a stable DNS name for internal cluster communication, and ClusterIP is the default Service type that fulfills this requirement without exposing the backend externally.

Exam trap

CNCF often tests the misconception that a Service of type NodePort is required for any DNS-based communication, but the trap here is that ClusterIP is the correct choice for internal cluster DNS stability, while NodePort is only needed for external access.

How to eliminate wrong answers

Option A is wrong because EndpointSlice is a resource that tracks network endpoints (IPs and ports) for a Service, but it does not provide a DNS name or stable endpoint itself. Option B is wrong because a Service of type NodePort exposes the backend on a static port on every Node's IP, which is intended for external access and introduces unnecessary exposure and complexity for internal-only communication. Option C is wrong because Ingress is an API object that manages external HTTP/HTTPS routing to Services, not a resource that provides a stable DNS name for internal cluster communication.

Practice this question →

202

MCQmedium

What is the difference between a liveness probe and a readiness probe?

A.Liveness probe checks if the container is ready to serve traffic

B.Readiness probe indicates if the container is healthy; liveness indicates if it should be restarted

C.Liveness probe indicates if the container is alive; if it fails, the container is restarted

D.Both probes serve the same purpose but with different endpoints

AnswerC

The liveness probe checks whether the container is running; failure triggers a restart to recover from deadlocks or crashes. This differs from the readiness probe, which controls traffic routing, so the stated restart behaviour correctly describes liveness.

Why this answer

A liveness probe determines if a container is still running (alive). If the liveness probe fails, Kubernetes restarts the container based on the `restartPolicy`. This is distinct from a readiness probe, which checks if a container is ready to accept traffic and removes it from Service endpoints if it fails.

Exam trap

The trap here is that candidates confuse the purpose of liveness and readiness probes, often thinking liveness controls traffic routing or that readiness triggers restarts, when in fact liveness governs restarts and readiness governs traffic inclusion.

How to eliminate wrong answers

Option A is wrong because it describes the function of a readiness probe, not a liveness probe; a liveness probe checks if the container is alive, not if it is ready to serve traffic. Option B is wrong because it reverses the roles: a readiness probe indicates if the container is ready to serve traffic, while a liveness probe indicates if it is healthy (alive) and should be restarted on failure. Option D is wrong because the two probes serve different purposes—liveness for restarting unhealthy containers, readiness for traffic routing—and they can use different endpoints (e.g., `/healthz` vs `/ready`).

Practice this question →

203

Multi-Selectmedium

Which TWO statements about containers compared to virtual machines are correct? (Select 2)

Select 2 answers

A.Containers have lower overhead than virtual machines

B.Containers are lightweight and share the host OS kernel

C.Virtual machines share the host OS kernel

D.Each container runs its own operating system kernel

E.Virtual machines provide weaker isolation than containers

AnswersA, B

Containers share the host kernel rather than virtualising hardware, so each container avoids booting a full guest OS. This eliminates hypervisor and duplicate-kernel overhead, giving faster start-up and denser packing on the same node — directly satisfying the lower-overhead comparison the question asks for.

Why this answer

Option A is correct because containers do not run a full guest OS or hardware emulation layer; they are just isolated processes on the host kernel, so CPU, memory, and storage overhead is significantly lower than running a hypervisor plus a complete VM. Option B is correct because containers are lightweight by design and share the host operating system kernel through features like namespaces and cgroups, rather than booting their own kernel. Option C is incorrect because virtual machines do not share the host OS kernel; each VM runs its own guest OS and kernel on virtualized hardware.

Option D is incorrect because it is containers, not VMs, that share the host kernel; each container does not run its own operating system kernel. Option E is incorrect because VMs generally provide stronger isolation than containers, since the hypervisor separates each VM from the host and from other VMs, whereas containers share the same kernel.

Exam trap

The trap is confusing the isolation and kernel-sharing characteristics of containers and VMs, leading candidates to incorrectly believe VMs share the host kernel or that containers have their own kernel.

Practice this question →

204

MCQhard

You have a microservices application where Service A needs to discover the IP of Service B. Both services run in the same Kubernetes cluster. Which approach is the most Kubernetes-native way for Service A to reach Service B?

A.Use the Kubernetes DNS service to resolve the Service name 'service-b'

B.Use an external service registry like Consul or etcd

C.Hardcode the cluster IP of Service B in the configuration of Service A

D.Use environment variables injected by the Kubernetes API into each pod

AnswerA

Kubernetes DNS resolves a Service name to its stable ClusterIP, letting Service A reach Service B without hard-coded pod IPs. This satisfies the requirement for a Kubernetes-native discovery mechanism, since DNS-based Service resolution is built into the cluster rather than added externally.

Why this answer

Kubernetes has a built-in DNS service (typically CoreDNS) that automatically creates DNS records for Services. When Service A resolves the name 'service-b' (or 'service-b.<namespace>.svc.cluster.local'), the DNS returns the cluster IP of Service B's Service object, which then load-balances traffic to the healthy Pods. This is the most Kubernetes-native approach because it leverages the platform's own service discovery mechanism without external dependencies.

Exam trap

The trap here is that candidates may think environment variables (Option D) are the primary Kubernetes-native method, but the exam emphasizes DNS as the modern, recommended approach, while environment variables are a legacy fallback with limitations.

How to eliminate wrong answers

Option B is wrong because using an external service registry like Consul or etcd adds unnecessary complexity and is not Kubernetes-native; Kubernetes already provides DNS-based service discovery. Option C is wrong because hardcoding the cluster IP of Service B is fragile — cluster IPs can change if the Service is recreated, and this approach does not handle scaling or Pod restarts. Option D is wrong because while Kubernetes does inject environment variables (e.g., SERVICE_B_SERVICE_HOST) for Services created before the Pod, this method is deprecated, less reliable (depends on Pod creation order), and does not update dynamically if the Service IP changes.

Practice this question →

205

MCQmedium

You are designing a microservices application that requires each service to be independently deployable and scalable. The services communicate over HTTP and need service discovery. Which orchestration feature BEST addresses the need for service discovery?

A.Kubernetes Service

B.Horizontal Pod Autoscaler

C.ConfigMap

D.PersistentVolume

AnswerA

A Kubernetes Service assigns a stable DNS name and virtual IP that load-balances across the backing pods, so services locate each other without tracking ephemeral pod IPs. This directly satisfies the HTTP service-discovery requirement while keeping each deployment independently scalable.

Why this answer

Kubernetes Service is the correct choice because it provides a stable network endpoint (IP address and DNS name) for a set of pods, enabling service discovery via DNS or environment variables. This allows microservices to locate and communicate with each other over HTTP without hardcoding IP addresses, which is essential for independent deployability and scalability.

Exam trap

A common trap in CNCF exams is confusing the Horizontal Pod Autoscaler (HPA), which scales pods, with the Kubernetes Service, which provides stable network endpoints for service discovery. Remember: HPA handles scaling, Service handles discovery.

How to eliminate wrong answers

Option B (Horizontal Pod Autoscaler) is wrong because it only adjusts the number of pod replicas based on CPU/memory metrics, not service discovery. Option C (ConfigMap) is wrong because it is used for injecting configuration data (e.g., environment variables) into pods, not for network endpoint resolution. Option D (PersistentVolume) is wrong because it provides storage abstraction for stateful workloads, not network-level service location.

Practice this question →

206

MCQhard

A user creates a Service of type ClusterIP with a selector matching pods labeled 'app: myapp'. However, a pod named 'myapp-pod' with label 'app: myapp' is not receiving traffic. What is a possible reason?

A.The Service type should be NodePort

B.The pod is in a different namespace

C.The pod's readiness probe is failing

D.The pod's container port is not defined

AnswerC

A failing readiness probe marks the pod NotReady, so the Endpoints controller excludes its IP from the Service's endpoint list. The selector matches correctly, but ClusterIP only forwards to ready endpoints, so traffic never reaches the pod.

Why this answer

A failing readiness probe causes the pod to be removed from the Service's Endpoints list, even if the pod is running and matches the selector. The kubelet checks the readiness probe periodically; if it fails, the pod is marked as not ready, and the Service controller removes its IP from the Endpoints object, preventing traffic from being forwarded to it.

Exam trap

The CNCF-KCNA exam often tests the distinction between liveness and readiness probes; the trap here is that candidates assume a running pod automatically receives traffic, overlooking that readiness probes explicitly gate traffic admission.

How to eliminate wrong answers

Option A is wrong because changing the Service type to NodePort would expose the Service externally but does not affect internal traffic routing to a pod that is not receiving traffic due to readiness issues; the core problem is pod readiness, not Service type. Option B is wrong because a Service only selects pods within its own namespace; if the pod were in a different namespace, it would not match the selector at all, and the question states the pod has the matching label, implying it is in the same namespace. Option D is wrong because while defining a container port is a best practice, it is not required for traffic to reach the pod; the Service can forward traffic to any port the pod listens on, and the absence of a container port definition does not prevent the pod from receiving traffic if the port is known.

Practice this question →

207

MCQmedium

You create a Service of type ClusterIP with the name 'my-service' in the 'default' namespace. What DNS name resolves to the service's cluster IP from a pod in the same namespace?

A.my-service.default.svc.cluster.local

B.my-service.svc.cluster.local

C.my-service.default.cluster.local

D.my-service.cluster.local

AnswerA

Kubernetes DNS resolves Services as <service>.<namespace>.svc.cluster.local. With the Service named my-service in the default namespace, that fully qualified name resolves to its cluster IP, and the shorter form my-service also works from within the same namespace.

Why this answer

Kubernetes DNS resolves a Service's ClusterIP using the fully qualified domain name (FQDN) format `<service>.<namespace>.svc.cluster.local`. Since the Service 'my-service' is in the 'default' namespace, a pod in the same namespace can reach it via `my-service.default.svc.cluster.local`. The DNS query returns the ClusterIP of the Service, allowing pods to communicate with it reliably.

Exam trap

The trap here is that candidates often forget the mandatory 'svc' subdomain in the FQDN, mistakenly thinking the namespace directly precedes 'cluster.local', or they omit the namespace entirely when the Service is in the same namespace as the pod.

How to eliminate wrong answers

Option B is wrong because it omits the namespace component; the correct FQDN must include the namespace (e.g., 'default') before 'svc'. Option C is wrong because it uses 'cluster.local' instead of 'svc.cluster.local'; the 'svc' subdomain is mandatory for Service DNS records. Option D is wrong because it drops both the namespace and the 'svc' subdomain, resulting in an incomplete and unresolvable DNS name.

Practice this question →

208

MCQmedium

A Kubernetes administrator needs to restrict inbound traffic to a set of pods. Only pods with the label 'app: frontend' in the same namespace should be allowed to reach the pods on TCP port 8080. Which resource should be used?

A.Ingress

B.PodSecurityPolicy

C.ServiceAccount

D.NetworkPolicy

AnswerD

NetworkPolicy selects pods via label selectors and defines ingress rules permitting only labelled sources on specified ports. It satisfies the stem's requirement to restrict inbound traffic to TCP 8080 from pods labelled app: frontend within the same namespace.

Why this answer

NetworkPolicy is the correct resource because it is a Kubernetes-native object that defines how groups of pods are allowed to communicate with each other and other network endpoints. By specifying a pod selector matching 'app: frontend' and an ingress rule allowing TCP port 8080, you can restrict inbound traffic to only those pods with that label in the same namespace.

Exam trap

The trap here is that candidates confuse Ingress (external HTTP routing) with NetworkPolicy (internal pod-to-pod traffic control), leading them to choose Ingress when the question explicitly restricts inbound traffic within the same namespace.

How to eliminate wrong answers

Option A is wrong because Ingress is an API object that manages external HTTP/S traffic to services, not pod-to-pod traffic within the cluster. Option B is wrong because PodSecurityPolicy is a cluster-level resource that controls security-sensitive aspects of pod specification (e.g., privilege escalation, host namespaces), not network traffic rules. Option C is wrong because a ServiceAccount provides an identity for processes running in a pod to authenticate to the Kubernetes API server, it does not enforce network-level access controls.

Practice this question →

209

Multi-Selecthard

Which THREE of the following are correct statements about Kubernetes Deployments?

Select 3 answers

A.Deployments support canary deployments natively

B.A Deployment manages ReplicaSets

C.A Deployment directly manages Pods

D.The default update strategy is RollingUpdate

E.Deployment supports rolling back to an earlier revision

AnswersB, D, E

A Deployment owns and manages ReplicaSets, creating a new ReplicaSet for each revision while retaining older ones. This ownership hierarchy is what enables declarative scaling and rollouts, since the Deployment controller reconciles desired replica counts through the ReplicaSet it governs.

Why this answer

Option B is correct because a Deployment does not manage Pods directly; it creates and manages ReplicaSets, which in turn manage the Pods, enabling versioned rollouts. Option D is correct because the default .spec.strategy.type for a Deployment is RollingUpdate, which gradually replaces old Pods with new ones to avoid downtime. Option E is correct because Deployments retain revision history (controlled by .spec.revisionHistoryLimit) and support kubectl rollout undo to roll back to a previous revision.

Option A is not correct because Deployments do not natively support canary deployments; canary releases require additional tooling or manual manipulation of replicas/selectors. Option C is not correct because Deployments manage ReplicaSets, not Pods directly.

Exam trap

The KCNA exam often tests the misconception that Deployments directly manage Pods, when in fact they manage ReplicaSets, and that canary deployments are a built-in feature of Deployments, whereas they require external traffic management.

Practice this question →

210

MCQmedium

A pod is in CrashLoopBackOff. You check the logs and see 'Error: container process not found'. What is the most likely cause?

A.The pod has insufficient memory

B.The liveness probe is misconfigured

C.The container's entrypoint or command is incorrect

D.The container image is missing

AnswerC

An incorrect entrypoint or command means the runtime cannot locate the executable to start, so the container exits immediately and Kubernetes restarts it repeatedly, producing CrashLoopBackOff. The log message 'container process not found' directly indicates the specified binary is missing or misnamed.

Why this answer

The container's entrypoint or command may be misconfigured, causing the container to exit immediately.

Practice this question →