CCNA Kcna Container Orchestration Questions — Page 2 of 3

MCQmedium

What is the Open Container Initiative (OCI) responsible for?

A.Certifying Kubernetes administrators

B.Providing a hosted container registry

C.Defining standards for container images and runtimes

D.Managing the Kubernetes source code

AnswerC

OCI oversees the image spec and runtime spec.

Why this answer

The Open Container Initiative (OCI) is a Linux Foundation project that defines open industry standards for container formats and runtimes. Specifically, it maintains the OCI Image Specification (which standardizes the container image format, including layers and configuration) and the OCI Runtime Specification (which defines the lifecycle and interface for container runtimes like runc). This ensures interoperability between different container tools and platforms.

Exam trap

The trap here is that candidates confuse the OCI with the CNCF, assuming the OCI manages Kubernetes or its certification, when in fact the OCI focuses solely on container format and runtime standards, while the CNCF oversees Kubernetes and its ecosystem.

How to eliminate wrong answers

Option A is wrong because certifying Kubernetes administrators is the responsibility of the Cloud Native Computing Foundation (CNCF) through the Certified Kubernetes Administrator (CKA) program, not the OCI. Option B is wrong because providing a hosted container registry is a service offered by cloud providers (e.g., Docker Hub, Amazon ECR, Google Container Registry) or self-hosted solutions, not a function of the OCI. Option D is wrong because managing the Kubernetes source code is the role of the CNCF and the Kubernetes community via the Kubernetes GitHub repository; the OCI focuses on container standards, not Kubernetes-specific code.

Practice this question →

MCQhard

A user runs 'kubectl exec -it pod1 -- /bin/sh' and gets the error: 'error: unable to upgrade connection: container not found ("app")'. The pod has one container named 'app'. What is the most likely cause?

A.The pod is running on a different node

B.The container image does not have /bin/sh

C.The container name is misspelled

D.The pod is in a CrashLoopBackOff state

AnswerD

If the container is crashing repeatedly, it may not be running when exec attempts to connect, resulting in this error.

Why this answer

The error 'unable to upgrade connection: container not found ("app")' indicates that kubectl cannot find a running container named 'app' to attach to. When a pod is in CrashLoopBackOff state, the container repeatedly crashes and restarts, but during the backoff period the container is not running, so kubectl exec cannot locate it. This is the most likely cause because the error specifically mentions the container name, and a CrashLoopBackOff means the container is not in a running state.

Exam trap

The CNCF exam often tests the distinction between errors caused by a missing binary inside the container versus errors caused by the container not being in a running state, leading candidates to incorrectly choose the missing shell option when the error message clearly references the container itself.

How to eliminate wrong answers

Option A is wrong because the node location does not affect kubectl exec; the API server handles the connection upgrade regardless of which node the pod runs on. Option B is wrong because if /bin/sh were missing, the error would be about the command not being found inside the container, not about the container not being found. Option C is wrong because the error message explicitly shows the container name 'app' is being used correctly; a misspelling would cause a different error like 'container "app" is not valid' or the pod would not have been created.

Practice this question →

Multi-Selectmedium

Which TWO statements correctly describe how Kubernetes handles self-healing? (Select two.)

Select 2 answers

A.If a node fails, the ReplicaSet controller automatically recreates the pods on healthy nodes

B.If a container in a pod crashes, the kubelet restarts it according to the pod's restart policy

C.Kubernetes automatically fixes application-level bugs by rolling back to a previous version

D.Kubernetes can automatically resolve OOMKilled errors by increasing memory limits

E.Kubernetes can automatically resolve OOMKilled errors by increasing memory limits

AnswersA, B

The ReplicaSet (or Deployment) controller detects that pods are no longer running and creates replacement pods on available nodes.

Why this answer

The ReplicaSet controller monitors the cluster for node failures and, when a node becomes unhealthy, it creates replacement pods on other healthy nodes to maintain the desired replica count. This is a core self-healing mechanism in Kubernetes that operates at the controller level, independent of the kubelet.

Exam trap

CNCF often tests the distinction between automatic self-healing at the infrastructure level (node/pod restarts) versus manual or policy-driven recovery for application-level issues, leading candidates to incorrectly assume Kubernetes automatically fixes bugs or adjusts resource limits.

Practice this question →

MCQmedium

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

A.To allow kubelet to use different container runtimes without modifying its code

B.To replace Docker as the only supported runtime

C.To define the format of container images

D.To provide a standard API for managing containers across different orchestration platforms

AnswerA

CRI abstracts the container runtime so that kubelet can work with containerd, CRI-O, etc.

Why this answer

The Container Runtime Interface (CRI) is a plugin interface that enables the kubelet to use a wide variety of container runtimes without requiring changes to the core Kubernetes code. By defining a standard set of gRPC APIs for runtime operations (like pod and container lifecycle management), CRI decouples the kubelet from any specific runtime implementation, allowing runtimes like containerd, CRI-O, and Docker (via dockershim, now deprecated) to be used interchangeably.

Exam trap

A common misconception is that CRI is a cross-platform API for container orchestration, when in fact it is a Kubernetes-specific interface designed solely to abstract the container runtime from the kubelet.

How to eliminate wrong answers

Option B is wrong because CRI does not replace Docker; it provides a standard interface that allows runtimes like containerd or CRI-O to be used instead of Docker, but Docker itself was supported through the dockershim adapter (removed in v1.24). Option C is wrong because container image format is defined by the OCI Image Specification, not by CRI; CRI deals with runtime operations, not image format definitions. Option D is wrong because CRI is specific to Kubernetes and its kubelet; it is not designed to provide a standard API for managing containers across different orchestration platforms like Docker Swarm or Apache Mesos.

Practice this question →

MCQeasy

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

A.kube-scheduler

B.kube-controller-manager

C.kubelet

D.kube-apiserver

AnswerB

Correct. It runs controllers that reconcile desired state.

Why this answer

The kube-controller-manager is the component that runs controller processes, which are responsible for regulating the state of the cluster. It continuously watches the current state via the kube-apiserver and takes corrective actions to match the desired state defined in the cluster's control loop, such as ensuring the correct number of pods are running.

Exam trap

CNCF often tests the misconception that the kube-scheduler maintains desired state because it 'schedules' pods, but scheduling is only one part of the control loop; the actual state reconciliation is done by the controller-manager.

How to eliminate wrong answers

Option A is wrong because the kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for maintaining the desired state. Option C is wrong because the kubelet is an agent that runs on each node and ensures containers are running in a pod, but it does not maintain the cluster-wide desired state. Option D is wrong because the kube-apiserver serves as the front-end for the Kubernetes control plane, handling API requests and storing state in etcd, but it does not actively enforce or reconcile the desired state.

Practice this question →

MCQmedium

A DevOps engineer wants to update a Deployment's container image from 'v1' to 'v2' with zero downtime. Which kubectl command should they use?

A.kubectl rollout restart deployment/<name>

B.kubectl patch deployment <name> -p '{"spec":{"template":{"spec":{"containers":[{"name":"<container>","image":"<image>:v2"}]}}}}'

C.kubectl set image deployment/<name> <container>=<image>:v2

D.kubectl edit deployment <name>

AnswerC

This command triggers a rolling update, which by default updates pods gradually with zero downtime.

Why this answer

`kubectl set image` directly updates the container image in a Deployment's pod template, triggering a rolling update that replaces pods incrementally with zero downtime. Kubernetes Deployments manage ReplicaSets to ensure availability during the update, making this the simplest and most reliable command for a controlled image change.

Exam trap

The trap here is that candidates may confuse `kubectl rollout restart` (which only restarts pods with the same image) with `kubectl set image` (which actually changes the image), or assume that any command modifying the Deployment (like patch or edit) inherently provides zero downtime without considering the rolling update mechanism.

How to eliminate wrong answers

Option A is wrong because `kubectl rollout restart` triggers a restart of all pods with the existing image, not an image update; it does not change the container image from 'v1' to 'v2'. Option B is wrong because while a patch can update the image, it requires manually specifying the full container name and image string, which is error-prone and less concise than `kubectl set image`; it also does not inherently enforce a rolling update strategy if the Deployment's update strategy is misconfigured. Option D is wrong because `kubectl edit` opens an interactive editor, which is not suitable for automation or scripting and introduces risk of human error; it does not guarantee zero downtime if the user accidentally changes other fields.

Practice this question →

MCQeasy

Which of the following is a container runtime that implements the Container Runtime Interface (CRI)?

A.containerd

B.Docker

C.runc

D.kubelet

AnswerA

containerd is a high-level container runtime that implements the CRI and is used by Kubernetes.

Why this answer

containerd is a high-level container runtime that directly implements the Container Runtime Interface (CRI) by exposing a gRPC API that kubelet can call to manage pods and containers. It was originally extracted from Docker and is now the default runtime in many Kubernetes distributions, providing image transfer, container lifecycle management, and storage/network attachment without requiring Docker as an intermediary.

Exam trap

CNCF often tests the misconception that Docker is a CRI-compliant runtime, when in fact Docker uses a separate adapter (dockershim) that was removed in Kubernetes v1.24, making containerd the standard CRI implementation.

How to eliminate wrong answers

Option B (Docker) is wrong because Docker does not implement the CRI natively; instead, Kubernetes uses the dockershim (deprecated since v1.24) as a CRI adapter to translate CRI calls into Docker API calls, meaning Docker is not a CRI-compliant runtime itself. Option C (runc) is wrong because runc is a low-level OCI runtime that only creates and runs containers according to the OCI spec; it does not implement the CRI gRPC interface or handle higher-level tasks like image management or pod sandbox creation. Option D (kubelet) is wrong because kubelet is the Kubernetes node agent that acts as a CRI client, not a CRI implementation; it calls the CRI API on a container runtime (like containerd) to manage containers.

Practice this question →

MCQhard

A microservices application has multiple services that need to discover each other by name. Which Kubernetes object provides built-in service discovery via DNS?

A.Ingress

B.Namespace

C.ConfigMap

D.Service

AnswerD

Services are assigned DNS names (e.g., my-svc.namespace.svc.cluster.local).

Why this answer

A Kubernetes Service object provides built-in service discovery via DNS. When a Service is created, the cluster's DNS (typically CoreDNS) automatically assigns it a DNS name in the format `<service>.<namespace>.svc.cluster.local`, allowing other microservices to resolve the Service by name without hardcoding IP addresses or using external service registries.

Exam trap

The trap here is that candidates often confuse Ingress (external routing) with internal DNS-based service discovery, or assume that Namespaces themselves provide DNS resolution, when in fact it is the Service object that triggers DNS record creation.

How to eliminate wrong answers

Option A is wrong because an Ingress is an API object that manages external HTTP/S access to Services, not internal service discovery or DNS resolution between microservices. Option B is wrong because a Namespace is a logical isolation boundary for resources and does not itself provide DNS-based service discovery; it only scopes the DNS names of Services within it. Option C is wrong because a ConfigMap is used to store non-sensitive configuration data as key-value pairs and has no role in DNS resolution or service discovery.

Practice this question →

MCQmedium

Which command would you use to view the logs of a specific container in a multi-container pod, using the short flag?

A.kubectl logs mycontainer -p mypod

B.kubectl logs mypod --container mycontainer

C.kubectl logs mypod -c mycontainer

D.kubectl logs mypod mycontainer

AnswerC

Correct: The short flag `-c` is used to specify the container in a multi-container pod.

Why this answer

The command `kubectl logs mypod -c mycontainer` uses the short flag `-c` to specify the container name in a multi-container pod. The long form `--container` also works, but the exam may specifically expect the short flag syntax. Option A uses `-p` which retrieves logs from a previous instance.

Option D provides the container name as a positional argument, which is incorrect.

Exam trap

The CNCF exam may test that the short flag `-c` is the primary way to specify a container, while being aware that `--container` is also valid.

How to eliminate wrong answers

Option A is wrong because the syntax `kubectl logs mycontainer -p mypod` is invalid; the `-p` flag is used for previous pod logs, not for specifying a container, and the container name must come after the pod name. Option B is wrong because `--container mycontainer` is a valid flag but the order is incorrect—the pod name must come first, and the flag should be `--container` or `-c`, not `--container` after the pod name without a proper flag prefix. Option D is wrong because `kubectl logs mypod mycontainer` treats `mycontainer` as an optional second positional argument for a previous container instance, not as a container selector, and will fail or produce unexpected output in a multi-container pod.

Practice this question →

MCQmedium

Which component is responsible for running containers in a Kubernetes node and implements the Container Runtime Interface (CRI)?

A.kubelet

B.etcd

C.kube-proxy

D.containerd

AnswerD

containerd is a CRI-compliant container runtime that runs and manages containers.

Why this answer

containerd is the correct answer because it is the container runtime that directly manages container lifecycle operations (create, start, stop, delete) on a Kubernetes node and implements the Container Runtime Interface (CRI), which is the gRPC-based protocol that kubelet uses to interact with container runtimes. Kubernetes requires a CRI-compliant runtime, and containerd is a graduated CNCF project that fulfills this role by exposing the CRI API via its `cri` plugin.

Exam trap

CNCF often tests the misconception that kubelet directly runs containers, but in reality kubelet is only the orchestrator agent that delegates to a CRI-compliant runtime like containerd, making containerd the correct answer.

How to eliminate wrong answers

Option A (kubelet) is wrong because kubelet is the node agent that communicates with the control plane and manages pods, but it does not run containers directly—it delegates container operations to a CRI-compliant runtime like containerd. Option B (etcd) is wrong because etcd is a distributed key-value store used for cluster state persistence, not for running containers or implementing CRI. Option C (kube-proxy) is wrong because kube-proxy is a network proxy that handles service routing and load balancing using iptables or IPVS, and it has no role in container runtime operations or the CRI.

Practice this question →

MCQhard

You run 'kubectl get pods' and see that a pod named 'web-frontend' is in 'Pending' state for more than 5 minutes. What is the most likely cause?

A.The container image does not exist

B.There are insufficient resources on any node to schedule the pod

C.The pod's readiness probe is failing

D.The pod's liveness probe is failing

AnswerB

Lack of CPU/memory or other constraints keeps the pod pending.

Why this answer

A pod stuck in 'Pending' state for an extended period typically indicates that the scheduler cannot find a suitable node to run the pod. The most common reason is insufficient resources (CPU, memory, or ephemeral storage) on any available node, causing the scheduler to leave the pod unscheduled. This is confirmed by running 'kubectl describe pod web-frontend' and checking the 'Events' section for 'FailedScheduling' messages.

Exam trap

CNCF often tests the distinction between pod states — candidates confuse 'Pending' (scheduling failure) with image pull errors or probe failures, which occur after scheduling and manifest as different states like 'ImagePullBackOff' or 'CrashLoopBackOff'.

How to eliminate wrong answers

Option A is wrong because if the container image does not exist, the pod would transition to 'ImagePullBackOff' or 'ErrImagePull' state, not remain in 'Pending' — the scheduler would still assign the pod to a node first. Option C is wrong because a failing readiness probe causes the pod to be marked as 'NotReady' but it remains in 'Running' state, not 'Pending'. Option D is wrong because a failing liveness probe triggers container restarts and eventually 'CrashLoopBackOff', but the pod is still scheduled and in 'Running' state, not 'Pending'.

Practice this question →

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Increase the memory limit in the pod's container resource specification

B.Delete and recreate the pod to clear the crash loop

C.Increase the CPU request for the container

D.Delete the namespace and redeploy all workloads

AnswerA

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

The pod is failing with an 'OOMKilled' status, which indicates that the container's memory usage exceeded its configured memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being terminated by the Out-Of-Memory (OOM) killer, resolving the crash loop. This is the most direct and appropriate action to address the resource exhaustion.

Exam trap

The trap here is that candidates may confuse OOMKilled with a generic crash and choose to delete/recreate the pod (Option B), not realizing that the underlying resource limit configuration remains unchanged and will cause the same failure again.

How to eliminate wrong answers

Option B is wrong because deleting and recreating the pod will not resolve the underlying memory limit issue; the new pod will still be subject to the same memory limit and will likely crash again with OOMKilled. Option C is wrong because increasing the CPU request does not affect memory allocation; OOMKilled is a memory-related error, not a CPU issue, and CPU changes will not prevent the container from exceeding its memory limit. Option D is wrong because deleting the entire namespace and redeploying all workloads is an extreme, unnecessary action that does not target the specific memory limit problem and would cause unnecessary disruption to other workloads.

Practice this question →

MCQmedium

You want to ensure that a Pod runs on every Node in the cluster. Which resource should you use?

A.Deployment

B.DaemonSet

C.ReplicaSet

D.StatefulSet

AnswerB

DaemonSets run a Pod on each Node (or a subset if nodeSelector is used).

Why this answer

A DaemonSet ensures that a copy of a Pod runs on every Node in the cluster, including when new Nodes are added. This is the correct resource for cluster-wide services like log collectors, monitoring agents, or kube-proxy, as it automatically schedules a Pod on each Node and respects node taints and tolerations.

Exam trap

CNCF often tests the misconception that a Deployment with a replica count equal to the number of Nodes will achieve the same effect, but candidates overlook that Deployments do not enforce per-Node scheduling and can leave some Nodes empty due to scheduling constraints or resource limits.

How to eliminate wrong answers

Option A is wrong because a Deployment manages a set of identical Pods with a desired replica count, but it does not guarantee placement on every Node; it uses a scheduler to distribute Pods across available Nodes, which may leave some Nodes empty. Option C is wrong because a ReplicaSet is a lower-level resource that ensures a specified number of Pod replicas are running, but it has no mechanism to enforce per-Node scheduling; it is typically used by Deployments for replica management. Option D is wrong because a StatefulSet is designed for stateful applications that require stable, unique network identities and persistent storage, not for running a Pod on every Node; it uses ordinal indexing and can be scheduled on a subset of Nodes.

Practice this question →

MCQmedium

A container image is built from a Dockerfile with multiple layers. Which statement about container image layers is TRUE?

A.Each layer is created by a RUN instruction and can be modified after the image is built

B.Each layer is unique to the image and cannot be shared with other images

C.Layers are read-only and can be reused across different images

D.All layers in a container image are writable at runtime

AnswerC

Image layers are read-only and are shared across images that use the same base or intermediate layers, improving efficiency.

Why this answer

Container image layers are read-only and are stored in a content-addressable storage (e.g., overlayfs, aufs). These layers can be reused across different images when they share the same content hash, which is a fundamental efficiency of Docker's union filesystem. This layer sharing reduces disk usage and speeds up image pulls.

Exam trap

CNCF often tests the misconception that all layers are writable at runtime, but in reality only the container's writable layer is mutable, while the underlying image layers remain read-only.

How to eliminate wrong answers

Option A is wrong because each layer is created by any instruction in the Dockerfile (not just RUN), and layers are immutable after the image is built; they cannot be modified. Option B is wrong because layers are identified by their content hash (SHA256) and are shared between images that use the same base layers, such as multiple images based on the same Ubuntu base. Option D is wrong because at runtime, a thin writable container layer is added on top of the read-only image layers; the image layers themselves remain read-only.

Practice this question →

MCQmedium

You need to run a batch job that processes a queue of 1000 items. The job should run to completion and then terminate. Which Kubernetes resource is BEST suited for this workload?

A.DaemonSet

B.Job

C.Deployment

D.StatefulSet

AnswerB

A Job creates one or more pods and ensures they successfully terminate; ideal for batch workloads.

Why this answer

A Kubernetes Job is designed for batch processing tasks that run to completion and then terminate. It creates one or more Pods and ensures that a specified number of them successfully terminate. For a queue of 1000 items, a Job can be configured with a parallelism value and a completions count to process all items and then exit, making it the ideal resource for this workload.

Exam trap

CNCF often tests the distinction between workloads that run to completion (Jobs) versus those that are expected to run indefinitely (Deployments, DaemonSets), and the trap here is that candidates may choose Deployment because they associate it with 'running a job' in a general sense, without realizing that a Deployment's default behavior is to maintain a desired number of running Pods and restart them if they exit.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on every (or selected) Node in the cluster, which is intended for long-running background services like log collection or monitoring, not for batch jobs that terminate. Option C is wrong because a Deployment manages a set of Pods to run continuously (e.g., web servers) and will restart Pods if they exit, which is the opposite of a batch job that should terminate after completion. Option D is wrong because a StatefulSet is used for stateful applications that require stable network identities and persistent storage (e.g., databases), not for ephemeral batch processing tasks.

Practice this question →

MCQhard

A pod is stuck in the Pending state. Running 'kubectl describe pod <pod-name>' shows the event: '0/3 nodes are available: 1 node had taint {node.kubernetes.io/disk-pressure: }, 2 nodes had taint {node.kubernetes.io/memory-pressure: }'. What is the most likely cause?

A.All nodes have taints that the pod does not have tolerations for

B.The container image is not found in the registry

C.The pod has a resource request that exceeds available capacity on all nodes

D.The pod's liveness probe is failing

AnswerA

The event indicates that each node has a taint (disk-pressure or memory-pressure) and the pod lacks corresponding tolerations.

Why this answer

The pod is stuck in Pending because the scheduler cannot find a node that satisfies its scheduling constraints. The events show that all three nodes have taints (disk-pressure and memory-pressure), and the pod does not have corresponding tolerations to allow it to be scheduled on those nodes. Without tolerations, the pod is not permitted to run on any of the available nodes, leaving it in the Pending state.

Exam trap

CNCF often tests the distinction between taints/tolerations and resource constraints, where candidates mistakenly attribute a Pending state to resource exhaustion when the actual cause is missing tolerations for node taints.

How to eliminate wrong answers

Option B is wrong because a missing container image would cause an ImagePullBackOff or ErrImagePull error, not a Pending state with node taint events. Option C is wrong because resource requests exceeding capacity would produce events like 'Insufficient memory' or 'Insufficient cpu', not taint-related messages. Option D is wrong because a failing liveness probe only affects running pods (causing restarts or CrashLoopBackOff), not pods that have never been scheduled.

Practice this question →

MCQeasy

Which statement accurately describes a key difference between containers and virtual machines?

A.Virtual machines share the host kernel, while containers have their own kernel

B.Both containers and virtual machines require a hypervisor

C.Containers include a full guest operating system

D.Containers share the host OS kernel, while virtual machines include a full guest OS

AnswerD

This is the key difference: containers are lightweight because they share the host kernel.

Why this answer

Containers virtualize at the OS level, sharing the host kernel, while virtual machines (VMs) include a full guest OS with its own kernel, running on a hypervisor. This fundamental architectural difference means containers are lighter and start faster, but VMs provide stronger isolation since each VM has its own kernel and OS instance.

Exam trap

The trap is that candidates often confuse the isolation boundaries between containers and VMs, mistakenly thinking containers have their own kernel (like VMs) or that VMs share the host kernel (like containers). In the context of Kubernetes, containers always share the host OS kernel, while VMs include a full guest OS.

How to eliminate wrong answers

Option A is wrong because it reverses the relationship: virtual machines do NOT share the host kernel (they have their own guest OS kernel), while containers share the host kernel. 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 (Type 1 or Type 2) to manage guest OS instances. Option C is wrong because containers do not include a full guest operating system; they package only the application and its dependencies, relying on the host OS kernel for system calls.

Practice this question →

Multi-Selecteasy

Which TWO of the following are true about container networking basics? (Choose 2)

Select 2 answers

A.Containers can only communicate if they are on the same node

B.Containers on the same host can communicate via a bridge network

C.Each container has its own network namespace

D.Container networking does not require any configuration

E.All containers share the host's IP address

AnswersB, C

A bridge network connects containers to the same L2 network, allowing communication.

Why this answer

Containers utilize network namespaces to isolate their network stack, so each container has its own network namespace (C). On the same host, containers can communicate through a bridge network, which provides connectivity via a virtual switch (B). Option A is false because containers on different nodes can communicate via overlay networks or routing.

Option D is false because container networking typically requires configuration (e.g., Docker's bridge or CNI plugins). Option E is false because containers usually have their own IP addresses within the bridge network, not sharing the host's IP directly.

Practice this question →

Matchingmedium

Match each Kubernetes component to its role in the control plane.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Exposes the Kubernetes API and acts as the front-end

Runs controller processes like Node and Replication controllers

Assigns pods to nodes based on resource availability

Consistent and highly-available key-value store for all cluster data

Interacts with underlying cloud provider's APIs

Why these pairings

The core control plane components are: API Server (central API gateway), etcd (distributed store), and Scheduler (pod-to-node assignment). Common confusions include mixing roles of etcd and the API Server or Scheduler.

Practice this question →

MCQeasy

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

A.To allow kubelet to use different container runtimes

B.To manage persistent storage for containers

C.To provide a network plugin interface for pods

D.To define a standard for container images

AnswerA

CRI abstracts the container runtime so kubelet can work with any CRI-compliant runtime.

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 source code. By defining a standard API (gRPC-based) for runtime operations like pulling images and managing containers, CRI decouples Kubernetes from specific runtime implementations such as containerd, CRI-O, or Docker (via dockershim). This abstraction allows cluster administrators to choose the most suitable runtime for their environment while maintaining compatibility with the Kubernetes control plane.

Exam trap

A common exam trap is confusing the CRI's role in runtime abstraction with storage (CSI) or networking (CNI) interfaces, leading candidates to select options B or C.

How to eliminate wrong answers

Option B is wrong because persistent storage management is handled by the Container Storage Interface (CSI), not the CRI; CRI focuses solely on runtime operations like container lifecycle and image management. Option C is wrong because network plugin interfaces for pods are provided by the Container Network Interface (CNI), which handles IP allocation and network connectivity, not the CRI. Option D is wrong because container image standards are defined by the Open Container Initiative (OCI) image spec, not the CRI; the CRI consumes OCI-compliant images but does not define the image format itself.

Practice this question →

Multi-Selecteasy

Which TWO of the following are characteristics of microservices architecture? (Choose 2)

Select 2 answers

A.All services share the same database

B.Services can be deployed independently

C.Communication between services is often via APIs

D.The entire application is deployed as a single unit

E.Services are tightly coupled

AnswersB, C

Each microservice can be developed, deployed, and scaled independently.

Why this answer

Microservices architecture is defined by the ability to deploy each service independently without affecting other services. This independence enables teams to update, scale, and roll back individual components, which is a core principle of container orchestration platforms like Kubernetes that manage these services as separate units.

Exam trap

The trap here is that candidates confuse microservices with service-oriented architecture (SOA) or mistakenly think that sharing a database or tight coupling is acceptable, when in fact microservices require database-per-service and loose coupling to achieve independent deployability.

Practice this question →

MCQhard

A pod has resource requests of 512Mi memory and 500m CPU, and limits of 1Gi memory and 1 CPU. The node has 4Gi memory and 2 CPU cores. If the pod tries to use 700m CPU, what will happen?

A.The pod will be throttled to 500m CPU

B.The pod will be allowed to use 700m CPU

C.The pod will be evicted from the node

D.The pod will be terminated for exceeding the limit

AnswerB

The pod can use up to the CPU limit (1000m) if the node has capacity.

Why this answer

The pod's CPU request is 500m, and its CPU limit is 1 CPU (1000m). When the pod attempts to use 700m CPU, it is below the limit of 1000m, so it is allowed to burst up to that amount. Kubernetes uses the CPU request for scheduling and the limit for throttling; since 700m is within the limit, no throttling occurs.

The pod is not evicted or terminated because it has not exceeded its memory limit or violated any resource constraints.

Exam trap

The trap here is that candidates confuse CPU requests with limits, thinking that exceeding the request triggers throttling or eviction, when in fact throttling only occurs at the limit and eviction is tied to memory or node pressure, not CPU usage below the limit.

How to eliminate wrong answers

Option A is wrong because throttling to 500m CPU would only occur if the pod exceeded its CPU limit, but 700m is below the 1000m limit, so the pod is allowed to burst. Option C is wrong because eviction happens when a node runs out of resources (e.g., memory pressure) or when a pod exceeds its memory limit, not for CPU usage below the limit. Option D is wrong because termination for exceeding a limit applies only when the pod surpasses its memory limit or violates a hard resource constraint; CPU usage below the limit does not trigger termination.

Practice this question →

MCQeasy

A developer wants to run a one-time task that creates a database schema and then exits. Which Kubernetes workload type is most appropriate?

A.DaemonSet

B.StatefulSet

C.Deployment

D.Job

AnswerD

Jobs run to completion.

Why this answer

A Job is the correct choice because it is designed for finite, one-time tasks that run to completion, such as creating a database schema. Unlike long-running workloads, a Job creates one or more Pods and ensures they terminate successfully after the task finishes, making it ideal for batch processing or initialization tasks.

Exam trap

The trap here is that candidates confuse a one-time task with a Deployment because they think of 'running a container' generically, forgetting that Deployments enforce a restart policy that would keep the task running indefinitely.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on all (or selected) nodes, intended for continuous background services like logging or monitoring, not for one-time tasks. Option B is wrong because a StatefulSet is used for stateful applications requiring stable, unique network identities and persistent storage, such as databases, and is designed for long-running rather than ephemeral tasks. Option C is wrong because a Deployment manages a set of identical Pods with a desired replica count, ensuring they run continuously and are automatically restarted if they exit, which is unsuitable for a task that should exit after completion.

Practice this question →

MCQhard

In a container image built from a Dockerfile, what is the purpose of the CMD instruction?

A.To specify a command that always runs at build time

B.To copy files into the image

C.To provide default arguments for the ENTRYPOINT instruction

D.To define environment variables

AnswerC

CMD can provide default arguments to ENTRYPOINT, or be the main command if ENTRYPOINT is not set.

Why this answer

The CMD instruction in a Dockerfile provides default arguments for the ENTRYPOINT instruction when the container is run. If no ENTRYPOINT is defined, CMD itself serves as the default command to execute. This allows users to override the default behavior at runtime by appending arguments to `docker run`, which replace the CMD values while preserving the ENTRYPOINT.

Exam trap

The KCNA exam often tests the distinction between CMD and RUN, where candidates mistakenly think CMD runs at build time, but the trap is that CMD only defines runtime defaults and is overridable, unlike RUN which executes during image creation.

How to eliminate wrong answers

Option A is wrong because CMD specifies a command that runs at container runtime, not at build time; build-time commands are handled by RUN. Option B is wrong because copying files into the image is the purpose of the COPY or ADD instruction, not CMD. Option D is wrong because defining environment variables is the role of the ENV instruction, not CMD.

Practice this question →

100

MCQeasy

Which Open Container Initiative (OCI) specification defines the format of container images?

A.Runtime Spec

B.Image Spec

C.Container Runtime Interface (CRI)

D.Dockerfile specification

AnswerB

OCI Image Spec standardizes container image format.

Why this answer

The OCI Image Spec defines the format and content of container images, including the manifest, configuration, and layers. This ensures that any OCI-compliant runtime can run images built by any OCI-compliant tool, enabling interoperability across different container platforms.

Exam trap

The trap here is confusing the OCI Runtime Spec (which deals with running containers) with the OCI Image Spec (which deals with packaging images), or mistaking the Kubernetes CRI plugin interface for an OCI standard.

How to eliminate wrong answers

Option A is wrong because the OCI Runtime Spec defines the lifecycle and configuration of running containers (e.g., bundle format, state machine), not the image format. Option C is wrong because the Container Runtime Interface (CRI) is a Kubernetes API for integrating container runtimes (like containerd or CRI-O), not an OCI specification for image format. Option D is wrong because the Dockerfile specification is a Docker-specific build instruction format, not an OCI standard; OCI images are built from layers, not directly from Dockerfiles.

Practice this question →

101

MCQeasy

What is the Container Runtime Interface (CRI)?

A.A tool for building container images

B.A standard for container runtime logs

C.A specification for container images

D.An API between kubelet and container runtime

AnswerD

Correct. CRI allows kubelet to communicate with runtimes like containerd and CRI-O.

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 kubelet. It defines a gRPC API (protocol buffers) for the kubelet to communicate with the container runtime, covering operations like pod lifecycle management and image management. Option D correctly identifies this as the API between the kubelet and the container runtime.

Exam trap

The trap here is that candidates often confuse the CRI with container image specifications (OCI Image Spec) or container runtime tools (like Docker), but the CRI is strictly an API interface between the kubelet and the runtime, not a tool or a specification for images.

How to eliminate wrong answers

Option A is wrong because building container images is the job of tools like Docker Build, Buildah, or Kaniko, not the CRI, which is an interface for runtime orchestration. Option B is wrong because the CRI does not standardize container runtime logs; log management is handled by the kubelet via the logging interface (e.g., using the 'kubectl logs' command) and the container runtime's logging driver. Option C is wrong because container image specifications are defined by the OCI Image Spec (Open Container Initiative), not by the CRI, which focuses on runtime operations like starting and stopping containers.

Practice this question →

102

MCQmedium

An administrator needs to expose a set of pods running a web application on a static port on each node's IP address. Which Service type should they use?

A.ClusterIP

B.NodePort

C.ExternalName

D.LoadBalancer

AnswerB

NodePort opens a specific port on all nodes and routes traffic to the service.

Why this answer

A NodePort service exposes the application on a static port (30000–32767) on every node's IP address, making the pods accessible externally via <NodeIP>:<NodePort>. This matches the requirement to expose pods on a static port on each node's IP address without needing an external load balancer.

Exam trap

CNCF often tests the misconception that NodePort is the only way to expose services externally, but the trap here is confusing NodePort with LoadBalancer, which also provides external access but requires cloud provider integration and does not guarantee a static port on each node.

How to eliminate wrong answers

Option A is wrong because ClusterIP exposes the service only on a cluster-internal IP, making it unreachable from outside the cluster. Option C is wrong because ExternalName maps a service to an external DNS name via CNAME records, not to node IPs or ports. Option D is wrong because LoadBalancer provisions an external cloud load balancer with a public IP, which is overkill and not required for exposing on each node's static port.

Practice this question →

103

MCQmedium

A company is deploying a microservices application on Kubernetes. They want to ensure that configuration data, such as database URLs and feature flags, can be updated without rebuilding container images. Which Kubernetes resource should they use?

A.Secrets

B.Services

C.Deployments

D.ConfigMaps

AnswerD

ConfigMaps store non-sensitive configuration data that can be consumed by pods.

Why this answer

ConfigMaps are the correct Kubernetes resource for decoupling configuration data (like database URLs and feature flags) from container images. They allow you to inject configuration as environment variables or mounted volumes without rebuilding or redeploying the container image, enabling runtime updates.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming that all configuration must be stored in Secrets, but the KCNA exam tests the distinction that ConfigMaps are for non-sensitive data and Secrets are for sensitive data.

How to eliminate wrong answers

Option A is wrong because Secrets are designed for sensitive data (e.g., passwords, tokens) and are not intended for general configuration like database URLs or feature flags; using Secrets for non-sensitive data adds unnecessary complexity and security overhead. Option B is wrong because Services are a networking abstraction that provides stable endpoints for Pods, not a mechanism for storing or injecting configuration data. Option C is wrong because Deployments manage the desired state and lifecycle of Pods (e.g., scaling, rolling updates), but they do not store configuration data; configuration is typically provided via ConfigMaps or Secrets referenced in the Pod spec.

Practice this question →

104

MCQmedium

A.Increase the memory limit in the pod's container resource specification

B.Increase the CPU request for the container

C.Delete the namespace and redeploy all workloads

D.Delete and recreate the pod to clear the crash loop

AnswerA

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

OOMKilled indicates the container was terminated because it exceeded its memory limit. The correct resolution is to increase the memory limit (option A). Option B (increasing CPU request) does not address memory consumption.

Option C (deleting the namespace) is overly destructive and unnecessary. Option D (deleting and recreating the pod) would restart the container but would immediately fail again due to the same memory limit, so it does not resolve the root cause.

Practice this question →

105

MCQmedium

A Kubernetes Deployment manages a set of pods. What is the primary purpose of a Deployment?

A.To declare the desired state for a set of pods and manage rolling updates

B.To store configuration data as key-value pairs

C.To run a batch job to completion

D.To expose a set of pods as a network service

AnswerA

Deployments handle declarative updates.

Why this answer

A Deployment provides declarative updates for Pods and ReplicaSets, enabling rolling updates and rollbacks.

Practice this question →

106

Multi-Selectmedium

Which THREE of the following are core principles of immutable infrastructure? (Choose 3)

Select 3 answers

A.Rollbacks are performed by redeploying a previous image

B.Infrastructure is patched by applying updates to running servers

C.Infrastructure components are never modified after deployment

D.Deployments are reproducible and consistent

E.All changes are made by updating configuration files on running instances

AnswersA, C, D

Since each deployment is a complete image, rollback is simply deploying an older image.

Why this answer

Immutable infrastructure means that components are replaced, not modified. This ensures consistency, reliability, and easy rollbacks. Patching running instances is mutable.

Practice this question →

107

MCQmedium

A developer wants to expose a set of pods running a web application on a stable IP address. Which Kubernetes resource should they create?

A.Service

B.ConfigMap

C.Ingress

D.NetworkPolicy

AnswerA

A Service provides a stable cluster IP and load balancing to pods.

Why this answer

A Service in Kubernetes provides a stable IP address and DNS name to expose a set of pods, abstracting away pod IP changes due to scaling or restarts. It acts as a load balancer across the pods, typically using ClusterIP (default), NodePort, or LoadBalancer types. This directly meets the requirement of exposing pods on a stable IP.

Exam trap

The CNCF exam often tests the distinction between Ingress and Service, where candidates mistakenly choose Ingress for stable IP exposure, but Ingress only provides host/path-based routing and requires a Service to actually reach pods.

How to eliminate wrong answers

Option B (ConfigMap) is wrong because it is used to store configuration data as key-value pairs, not to provide network access or a stable IP to pods. Option C (Ingress) is wrong because it manages external HTTP/HTTPS routing to Services, not a stable IP for pods; it requires a Service to function and does not itself assign an IP. Option D (NetworkPolicy) is wrong because it defines firewall rules for pod-to-pod traffic, not exposure or stable IP assignment.

Practice this question →

108

MCQeasy

Which of the following is a key benefit of using containers over virtual machines?

A.Each container runs its own operating system

B.Containers provide stronger isolation than VMs

C.Containers require hypervisor to run

D.Containers share the host OS kernel

AnswerD

Containers share the host OS kernel, making them lightweight.

Why this answer

Containers share the host operating system kernel, which makes them lightweight and fast to start compared to virtual machines. Each container runs as an isolated user-space process on the same kernel, avoiding the overhead of a separate guest OS per instance. This shared-kernel architecture is a fundamental design principle of containerization technologies like Docker and containerd.

Exam trap

The trap here is that candidates often confuse the lightweight nature of containers with stronger isolation, but the key trade-off is that containers share the host kernel, making them less isolated than VMs, not more.

How to eliminate wrong answers

Option A is wrong because each container does not run its own operating system; containers share the host OS kernel and only include the application and its dependencies. Option B is wrong because containers provide weaker isolation than VMs, as they share the host kernel and rely on kernel namespaces and cgroups, whereas VMs use a hypervisor to provide hardware-level isolation. Option C is wrong because containers do not require a hypervisor to run; they run directly on the host OS using the kernel's container runtime, while VMs require a hypervisor.

Practice this question →

109

MCQhard

A developer creates a Deployment with replicas: 3 and strategy type: RollingUpdate with maxSurge: 1 and maxUnavailable: 1. During a rolling update, the Deployment controller creates a new ReplicaSet. After the new ReplicaSet has 2 pods ready, the node running one of the original ReplicaSet's pods fails. What is the MOST likely number of total pods running after the node failure, assuming no other actions?

A.2 pods running

B.4 pods running

C.3 pods running

D.1 pod running

AnswerA

Before node failure: old ReplicaSet scaled down to 1, new up to 2 (total 3). Node failure kills the old pod, leaving 2 new pods running.

Why this answer

Initially, the Deployment has 3 old pods. The rolling update starts: with maxSurge=1, the controller creates a new pod. Once it's ready, it terminates one old pod to keep desired replicas at 3.

Then it creates another new pod. After the second new pod is ready, it terminates a second old pod. At this point, the new ReplicaSet has 2 ready pods, and the old ReplicaSet has only 1 pod remaining.

The node running that last old pod fails, killing it. Thus, only the 2 new pods are running, giving a total of 2 pods.

Exam trap

Candidates may mistakenly think that the failed pod is immediately replaced by the Deployment controller to maintain the desired replica count, leading to 3 pods (2 new + 1 replacement). They might also overlook that the failed pod is no longer running, incorrectly counting 3 pods (2 new + 1 old). In reality, right after the node failure, only the 2 new pods are running, and the controller has not yet reacted.

How to eliminate wrong answers

Option B (4 pods running) is wrong because the maxSurge: 1 limits the total number of pods during the update to 4 (3 desired + 1 surge), but after the node failure, one pod is lost, and the controller does not create a replacement due to maxUnavailable: 1 already being satisfied. Option C (3 pods running) is wrong because it assumes the original ReplicaSet's pod on the failed node is still counted, but it is terminated by the node failure, and the rolling update has already scaled down one original pod, leaving only 2 pods from the new ReplicaSet. Option D (1 pod running) is wrong because the new ReplicaSet had 2 ready pods before the node failure, and those pods are on other nodes, so they remain running.

Practice this question →

110

Matchingmedium

Match each Kubernetes command (kubectl) to its primary function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

List one or more resources

Show detailed state of a resource

Create or update resources from a file or stdin

Execute a command inside a container

Print logs from a container in a pod

Why these pairings

The correct matches are: kubectl get for listing resources, kubectl describe for detailed info, and kubectl apply for applying configurations. Common confusions include swapping the functions of kubectl delete and kubectl logs.

Practice this question →

111

Multi-Selecthard

Which TWO of the following are true about service discovery in Kubernetes? (Choose 2)

Select 2 answers

A.Ingress resources can be used for internal service discovery

B.Service discovery is only available for pods on the same node

C.Environment variables are injected into pods for each Service

D.Services are assigned a DNS name in the form <service>.<namespace>.svc.cluster.local

E.Headless Services provide a stable virtual IP for service discovery

AnswersC, D

When a pod starts, environment variables are set for each active Service.

Why this answer

Kubernetes provides DNS-based service discovery, where Services get DNS names resolved by CoreDNS. Services also have environment variables injected into pods. Headless Services do not provide a single IP; they return the pod IPs.

Ingress is for external traffic, not internal service discovery.

Practice this question →

112

MCQhard

Which of the following correctly describes the concept of 'immutable infrastructure' in the context of container orchestration?

A.Infrastructure components are recreated from a known good state rather than modified

B.Configuration changes are applied via SSH into running containers

C.Servers are never rebooted

D.Container images are updated in-place by patching existing layers

AnswerA

This is the core idea of immutability.

Why this answer

Immutable infrastructure means that once a container image is built, it is never modified; updates are done by replacing the entire container with a new image.

Practice this question →

113

MCQmedium

A Pod is stuck in 'Pending' state. Which command is most helpful to diagnose the issue?

A.kubectl logs my-pod

B.kubectl get events

C.kubectl describe pod my-pod

D.kubectl top pod my-pod

AnswerC

This shows events and status conditions that indicate why the Pod is pending (e.g., insufficient resources).

Why this answer

'kubectl describe pod my-pod' provides detailed information about the pod's current state, including events, conditions, and resource constraints. When a pod is stuck in 'Pending', it typically means the scheduler cannot place it on a node due to issues like insufficient CPU/memory, persistent volume claims not being bound, or node selector mismatches. The 'describe' command surfaces these specific reasons in the 'Events' section and 'Conditions' field, making it the most direct diagnostic tool.

Exam trap

CNCF often tests the misconception that 'kubectl logs' is the universal debugging command, but for pending pods, logs are unavailable because containers haven't started, making 'kubectl describe' the correct choice for pre-run failures.

How to eliminate wrong answers

Option A is wrong because 'kubectl logs my-pod' retrieves container logs, but a pod in 'Pending' state has not started any containers yet, so there are no logs to fetch; this command is useful only after the pod is running. Option B is wrong because 'kubectl get events' shows cluster-wide events, which can be noisy and may not filter to the specific pod; while it can include scheduling failures, it lacks the pod-specific context and resource details that 'describe' provides. Option D is wrong because 'kubectl top pod my-pod' shows real-time resource usage metrics, which are only available for running pods; a pending pod has no resource consumption data to report.

Practice this question →

114

MCQmedium

A.Increase the CPU request for the container

B.Increase the memory limit in the pod's container resource specification

C.Delete and recreate the pod to clear the crash loop

D.Delete the namespace and redeploy all workloads

AnswerB

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

The OOMKilled status indicates the container was terminated because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, which allows the container to use more memory without being killed by the Out-Of-Memory (OOM) killer. This resolves the root cause by providing sufficient memory for the workload.

Exam trap

The trap here is that candidates confuse CPU and memory resource management, assuming increasing CPU requests can resolve memory-related OOM kills, or they opt for a destructive restart instead of adjusting the resource specification.

How to eliminate wrong answers

Option A is wrong because increasing the CPU request does not address memory exhaustion; CPU and memory are independent resources, and OOMKilled is triggered by memory limits, not CPU. Option C is wrong because deleting and recreating the pod only restarts the container with the same resource limits, so it will immediately crash again due to the same memory constraint. Option D is wrong because deleting the entire namespace and redeploying all workloads is an extreme, unnecessary action that disrupts all other workloads and does not fix the underlying memory limit issue.

Practice this question →

115

MCQeasy

What is the primary difference between a container and a virtual machine (VM)?

A.Containers are slower to start than VMs

B.Containers provide stronger isolation than VMs

C.VMs are more portable than containers

D.Containers share the host OS kernel, whereas VMs include a full guest OS

AnswerD

This is the fundamental difference. Containers virtualize the OS, while VMs virtualize the hardware.

Why this answer

The primary difference is that containers share the host operating system kernel and run as isolated user-space processes, while virtual machines include a full guest OS with its own kernel. This architectural distinction means containers are lightweight and start in seconds, whereas VMs require booting a complete OS. Option D correctly captures this fundamental difference.

Exam trap

The trap here is that candidates often confuse 'isolation strength' with 'lightweight nature' — the CNCF exam tests whether you know that VMs provide stronger isolation via hardware virtualization, not that containers are more secure or isolated.

How to eliminate wrong answers

Option A is wrong because containers are faster to start than VMs, not slower — containers start in milliseconds to seconds since they only need to launch a process, while VMs require booting a full guest OS. Option B is wrong because VMs provide stronger isolation than containers — VMs use a hypervisor to create hardware-level isolation between guest OSes, whereas containers rely on kernel namespaces and cgroups, which share the host kernel and have a weaker security boundary. Option C is wrong because containers are more portable than VMs — a container image bundles only the application and its dependencies, making it portable across any Linux host with the same kernel, while a VM image includes a full OS and is tied to specific hypervisor formats (e.g., OVF, VMDK).

Practice this question →

116

MCQmedium

Which of the following is a valid use case for a DaemonSet?

A.Running a batch job that must complete once

B.Running a stateless web application with multiple replicas

C.Running a stateful application with persistent storage

D.Running a logging agent on every node

AnswerD

DaemonSet ensures the agent runs on each node.

Why this answer

A DaemonSet ensures that a copy of a pod runs on all (or a subset of) nodes in the cluster. This is ideal for infrastructure pods like logging agents (e.g., Fluentd), monitoring agents (e.g., Prometheus Node Exporter), or kube-proxy, which must be present on every node to collect logs or enforce network rules. Option D directly matches this use case.

Exam trap

The trap here is that candidates confuse DaemonSets with Deployments or StatefulSets, assuming any long-running workload fits, but the key differentiator is the 'one pod per node' requirement, not replication count or statefulness.

How to eliminate wrong answers

Option A is wrong because a batch job that must complete once is a use case for a Job or CronJob, not a DaemonSet, which runs continuously on each node. Option B is wrong because a stateless web application with multiple replicas is typically deployed as a Deployment, which manages replicas across nodes without requiring one pod per node. Option C is wrong because a stateful application with persistent storage is best handled by a StatefulSet, which provides stable network identities and persistent storage per pod, unlike a DaemonSet which does not guarantee unique identities or ordered scaling.

Practice this question →

117

MCQeasy

What is the OCI (Open Container Initiative) responsible for?

A.Hosting public container images

B.Providing a default container runtime for Kubernetes

C.Managing container orchestration

D.Defining standards for container images and runtimes

AnswerD

The OCI maintains the Image Spec and Runtime Spec to ensure container compatibility.

Why this answer

The Open Container Initiative (OCI) is a Linux Foundation project that defines open industry standards for container image formats and container runtimes. Its two main specifications are the OCI Image Spec (which standardizes the container image layout, including layers and manifests) and the OCI Runtime Spec (which defines the lifecycle and configuration for running containers). This ensures interoperability between different container tools and platforms, such as Docker, Podman, and containerd.

Exam trap

CNCF often tests the misconception that the OCI is a tool or platform (like a registry or runtime) rather than a standards body, leading candidates to confuse it with Docker Hub or containerd.

How to eliminate wrong answers

Option A is wrong because hosting public container images is the role of container registries like Docker Hub, Quay.io, or Google Container Registry, not the OCI. Option B is wrong because providing a default container runtime for Kubernetes is not the OCI's responsibility; Kubernetes uses container runtimes like containerd or CRI-O, which may implement OCI specs but are not provided by the OCI itself. Option C is wrong because managing container orchestration is the function of orchestrators like Kubernetes, Docker Swarm, or Nomad, not the OCI, which focuses solely on standardization.

Practice this question →

118

MCQmedium

An application requires that a specific set of pods be placed on nodes labeled with 'gpu=true'. Which Kubernetes field should be used in the pod spec to enforce this?

A.nodeSelector

B.topologySpreadConstraints

C.affinity.nodeAffinity

D.tolerations

AnswerA

nodeSelector matches the pod to nodes that have the specified label (e.g., gpu=true).

Why this answer

`nodeSelector` is the simplest and most direct Kubernetes field for constraining a pod to nodes that have a specific label. By setting `nodeSelector: { gpu: 'true' }` in the pod spec, the scheduler will only place the pod on nodes that have the label `gpu=true`. This is a hard constraint that does not support complex expressions but is ideal for the stated requirement.

Exam trap

The trap here is that candidates often confuse `nodeSelector` with `nodeAffinity`, thinking the more advanced field is always required, but the question specifically asks for the field that enforces placement on labeled nodes, and `nodeSelector` is the simplest and correct answer for a straightforward label match.

How to eliminate wrong answers

Option B is wrong because `topologySpreadConstraints` controls how pods are distributed across topology domains (e.g., zones, nodes) to achieve even spreading, not to enforce placement on nodes with a specific label. Option C is wrong because `affinity.nodeAffinity` can also enforce placement on labeled nodes, but it is a more advanced and flexible field that supports both required and preferred rules; the question asks for the field that should be used, and `nodeSelector` is the simplest and most direct answer for a simple label match. Option D is wrong because `tolerations` allow pods to be scheduled on nodes with matching taints, but they do not enforce placement on nodes with a specific label; they only permit scheduling on otherwise tainted nodes.

Practice this question →

119

MCQhard

A pod is running but its container exits with code 137. The pod logs show 'Killed'. What is the most likely cause?

A.The container's CPU limit was exceeded

B.The container's liveness probe failed

C.The container was OOMKilled due to memory limit

D.The node ran out of disk space

AnswerC

Exit code 137 is SIGKILL, often from OOM. The pod status would show OOMKilled.

Why this answer

Exit code 137 (128 + 9) indicates the container was terminated by SIGKILL. Combined with 'Killed' in logs, this is the definitive signature of an OOMKill event, where the Linux kernel's Out-Of-Memory (OOM) killer terminates the container process because it exceeded its memory limit (specified in the pod's resource limits). Kubernetes enforces memory limits via cgroups, and when the container's memory usage surpasses the limit, the OOM killer sends SIGKILL, resulting in exit code 137.

Exam trap

CNCF often tests the distinction between CPU throttling (which does not kill) and OOMKill (which does), and the trap here is that candidates confuse 'Killed' in logs with a generic failure, not recognizing exit code 137 as the specific OOMKill signal.

How to eliminate wrong answers

Option A is wrong because exceeding CPU limits causes CPU throttling (container runs slower) but never triggers a kill or exit code 137; the container continues running. Option B is wrong because a liveness probe failure results in Kubernetes restarting the container with exit code 143 (SIGTERM) or 0, not 137, and the logs would show 'Liveness probe failed' not 'Killed'. Option D is wrong because node disk pressure leads to pod eviction (not container OOM kill) with a different exit code and a Kubernetes event like 'Evicted', not exit code 137 and 'Killed' in container logs.

Practice this question →

120

MCQeasy

A developer wants to ensure that a pod runs only on nodes with SSDs. Which mechanism should be used?

A.Apply a taint to nodes without SSDs and add tolerations to the pod

B.Use pod anti-affinity

C.Add a nodeSelector with disktype: ssd

D.Define a ResourceQuota

AnswerC

nodeSelector ensures pods are scheduled on nodes with the specified label.

Why this answer

`nodeSelector` is a simple and direct mechanism in Kubernetes to constrain a pod to run only on nodes that have a specific label, such as `disktype=ssd`. By labeling nodes with SSDs and adding the corresponding `nodeSelector` in the pod spec, the scheduler ensures the pod is placed exclusively on those nodes. This approach is straightforward and does not require complex scheduling constraints or resource management.

Exam trap

The trap here is that candidates often confuse taints/tolerations with node selection, thinking they can be used to force pods onto specific hardware, when in fact taints repel pods and tolerations allow exceptions, whereas `nodeSelector` or `nodeAffinity` are the correct tools for positive selection.

How to eliminate wrong answers

Option A is wrong because taints and tolerations are used to repel pods from nodes (or allow them to tolerate repulsion), not to positively select nodes with specific hardware; they control which pods can run on a node but do not guarantee a pod will only run on nodes with SSDs. Option B is wrong because pod anti-affinity is used to prevent pods from co-locating on the same node or topology, not to select nodes based on hardware attributes like SSDs. Option D is wrong because a ResourceQuota limits resource consumption within a namespace and cannot influence node selection based on hardware characteristics.

Practice this question →

121

MCQmedium

You have a microservices application deployed as a set of Pods in a Kubernetes cluster. You need to ensure that Pods can discover each other using stable DNS names. Which Kubernetes resource should you create?

A.ConfigMap

B.Ingress

C.Service

D.Deployment

AnswerC

A Service exposes a stable DNS name (e.g., my-service.namespace.svc.cluster.local) for Pods.

Why this answer

A Service of type ClusterIP (the default) provides a stable virtual IP and DNS name (e.g., my-service.namespace.svc.cluster.local) that resolves to the Pods selected by its label selector. This allows Pods to discover each other using consistent DNS names, regardless of Pod IP changes due to scaling or restarts. The kube-dns or CoreDNS addon automatically creates DNS records for Services, enabling service discovery within the cluster.

Exam trap

CNCF often tests the misconception that a Deployment itself provides stable DNS names, but Deployments only manage Pod replicas; the Service resource is required to expose a stable network endpoint and DNS record.

How to eliminate wrong answers

Option A is wrong because a ConfigMap is used to store configuration data as key-value pairs, not to provide network endpoints or DNS names for Pod discovery. Option B is wrong because an Ingress manages external HTTP/HTTPS traffic routing to Services, not internal Pod-to-Pod DNS-based discovery. Option D is wrong because a Deployment manages the desired state and lifecycle of Pods (replicas, updates), but does not create a stable network identity or DNS name for Pods to discover each other.

Practice this question →

122

Multi-Selectmedium

Which TWO of the following are characteristics of a microservices architecture? (Select 2)

Select 2 answers

A.Independent deployment of services

B.Tight coupling between services

C.Loose coupling between services

D.Monolithic codebase

E.Shared database for all services

AnswersA, C

Each microservice can be deployed independently.

Why this answer

Microservices architecture is designed to allow each service to be developed, tested, and deployed independently without affecting other services. This independence is achieved through well-defined APIs and versioning strategies, enabling continuous delivery and rapid iteration. In Kubernetes, for example, each microservice can be packaged as a separate container and deployed via its own Deployment resource, allowing updates to one service without downtime for the entire application.

Exam trap

CNCF often tests the misconception that microservices require a shared database for consistency, but the correct pattern is database-per-service to maintain loose coupling and independent scalability.

Practice this question →

123

MCQmedium

A developer wants to deploy a stateful application that requires stable network identities and persistent storage. Which Kubernetes resource is best suited for this workload?

A.Deployment

B.DaemonSet

C.StatefulSet

D.Job

AnswerC

StatefulSet provides stable, unique network identifiers and persistent storage for stateful applications.

Why this answer

StatefulSet is the correct choice because it is designed specifically for stateful applications that require stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage (via PersistentVolumeClaims that are retained across Pod rescheduling). Unlike Deployments, StatefulSets guarantee ordered deployment, scaling, and termination, which is essential for databases or message queues.

Exam trap

CNCF often tests the misconception that Deployment can handle stateful workloads because it supports PersistentVolumeClaims, but the trap is that Deployment does not guarantee stable network identities or ordered Pod management, which are critical for stateful applications like databases.

How to eliminate wrong answers

Option A is wrong because Deployment is intended for stateless applications and creates Pods with random, ephemeral identities and no guaranteed storage persistence; it does not provide stable network identities. Option B is wrong because DaemonSet ensures that a copy of a Pod runs on each node (or a subset of nodes) for node-level services like logging or monitoring, not for stateful workloads requiring stable identities and persistent storage. Option D is wrong because Job is designed for batch or one-time tasks that run to completion, not for long-running stateful applications that need persistent storage and stable network identities.

Practice this question →

124

MCQeasy

What is the primary benefit of containers over virtual machines?

A.Containers provide stronger isolation than VMs

B.Containers use more disk space than VMs

C.Containers require a hypervisor to run

D.Containers are more portable and lightweight because they share the host OS kernel

AnswerD

Containers share the host kernel and only include the application and dependencies, making them portable and efficient.

Why this answer

Containers are more portable and lightweight than virtual machines because they share the host OS kernel, eliminating the need for a separate guest OS per instance. This shared kernel approach reduces resource overhead (CPU, memory, and disk) and enables faster startup times, as containers only package the application and its dependencies without duplicating the operating system.

Exam trap

The trap here is that candidates often confuse isolation strength with portability, assuming containers are more secure because they are lightweight, but for the CNCF KCNA exam, it's important to understand that VMs provide stronger isolation due to separate kernels and hypervisor-level boundaries, whereas containers are more portable and lightweight.

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than VMs; VMs use a hypervisor to run separate guest OS kernels, offering stronger security boundaries, whereas containers rely on kernel namespaces and cgroups, which share the host kernel. Option B is wrong because containers use less disk space than VMs, as they do not include a full guest OS image and leverage layered filesystems (e.g., overlay2) to share common layers. Option C is wrong because containers do not require a hypervisor; they run directly on the host OS using container runtime engines like containerd or Docker, whereas VMs require a hypervisor (Type 1 or Type 2) to virtualize hardware.

Practice this question →

125

Multi-Selectmedium

Which TWO of the following are valid container runtimes that implement the CRI? (Choose two.)

Select 2 answers

A.Kata Containers

B.CRI-O

C.Docker

D.containerd

E.rkt

AnswersB, D

CRI-O is a CRI-compliant runtime.

Why this answer

CRI-O is a lightweight container runtime specifically designed to implement the Kubernetes Container Runtime Interface (CRI), allowing Kubernetes to use OCI-compliant runtimes directly without relying on Docker. It is a valid CRI implementation because it provides the gRPC-based CRI API server and manages container lifecycle using runc or Kata Containers as the underlying OCI runtime.

Exam trap

CNCF often tests the misconception that Docker is a CRI-compliant runtime because it was historically the default container runtime in Kubernetes, but candidates must remember that Docker uses its own API and was only supported via the now-removed dockershim, making containerd and CRI-O the only correct CRI implementations among the options.

Practice this question →

126

MCQeasy

Which component is responsible for managing the lifecycle of containers on a Kubernetes node?

A.kube-scheduler

B.kube-controller-manager

C.kube-apiserver

D.kubelet

AnswerD

The kubelet runs on each node and ensures containers are running and healthy.

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., Docker, containerd) to manage the container lifecycle—starting, stopping, and monitoring containers based on PodSpecs received from the API server.

Exam trap

CNCF often tests the distinction between control-plane components (scheduler, controller-manager, API server) and node-level agents (kubelet), so the trap here is assuming that container lifecycle management is a control-plane function rather than a node-level responsibility.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning Pods to nodes based on resource availability and constraints, not for managing container lifecycles on a node. Option B is wrong because kube-controller-manager runs controller processes (e.g., ReplicaSet, Deployment controllers) that regulate cluster state, but it does not directly interact with containers on individual nodes. Option C is wrong because kube-apiserver serves as the front-end for the Kubernetes control plane, exposing the Kubernetes API, but it does not manage container lifecycles on nodes; it only provides the interface for kubelet to retrieve Pod specifications.

Practice this question →

127

Multi-Selecthard

Which TWO statements about the Container Runtime Interface (CRI) are correct? (Select 2)

Select 2 answers

A.Docker is the primary CRI implementation

B.CRI is responsible for pulling container images

C.CRI allows Kubernetes to use different container runtimes

D.CRI is an OCI specification

E.containerd and CRI-O are CRI-compliant runtimes

AnswersC, E

CRI is a plugin interface that abstracts the container runtime.

Why this answer

The Container Runtime Interface (CRI) is a plugin interface that enables kubelet to use a variety of container runtimes without needing to recompile Kubernetes. It defines the API between kubelet and the container runtime, allowing runtimes like containerd and CRI-O to be swapped in seamlessly. This abstraction decouples Kubernetes from any single runtime, enabling flexibility and vendor neutrality.

Exam trap

The trap here is that candidates confuse CRI with OCI or assume Docker is still the default CRI implementation, when in fact Docker is not CRI-compliant and was removed as a built-in runtime in Kubernetes 1.24.

Practice this question →

128

Multi-Selectmedium

Which THREE of the following are characteristics of a microservices architecture? (Select 3)

Select 3 answers

A.Services share the same database schema

B.Loose coupling between services

C.Independent deployment of services

D.All services are packaged in a single monolithic deployment

E.Decomposition of application into small, independent services

AnswersB, C, E

Services communicate via APIs, reducing dependencies.

Why this answer

Microservices architecture emphasizes loose coupling, where each service communicates via well-defined APIs (e.g., REST, gRPC) and does not share internal implementation details. This allows services to evolve independently without affecting others, which is a core principle of the architecture.

Exam trap

CNCF often tests the misconception that microservices share a database or are deployed as a single unit, confusing them with monolithic or service-oriented architectures (SOA) that may share schemas.

Practice this question →

129

MCQmedium

A team wants to deploy a batch job that runs once to process a large dataset. The job should run to completion and then terminate. Which Kubernetes resource should be used?

A.DaemonSet

B.CronJob

C.Deployment

D.Job

AnswerD

Job runs pods until completion, ideal for batch processing.

Why this answer

A Job resource is designed for batch processing tasks that run to completion and then terminate. It creates one or more Pods and ensures they successfully finish their work, making it the correct choice for a one-time data processing job.

Exam trap

CNCF often tests the distinction between long-running workloads (Deployments, DaemonSets) and finite tasks (Jobs), so the trap here is confusing a one-time batch job with a CronJob due to the word 'batch' or assuming a Deployment can handle termination.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures a Pod runs on every node (or a subset) for continuous daemon-like services, not for a one-time batch job. Option B is wrong because a CronJob is used for scheduled, recurring tasks, not a single run. Option C is wrong because a Deployment manages long-running, stateless applications with desired replicas and rolling updates, not a terminating batch job.

Practice this question →

130

MCQmedium

What is the concept of 'immutable infrastructure' as applied to Kubernetes?

A.Configuration is stored in environment variables only

B.Containers are rebuilt from the same base image every time

C.Infrastructure components are never replaced; they are updated in place

D.Pods are replaced with new versions rather than being modified

AnswerD

Correct. Immutable infrastructure replaces rather than patches.

Why this answer

Immutable infrastructure in Kubernetes means that instead of modifying running Pods or their containers (e.g., patching a binary or updating a config file in place), you replace the entire Pod with a new version. This is enforced by Kubernetes' declarative model: when you update a Deployment's Pod template, the controller creates new Pods with the new image and terminates the old ones. This ensures consistency, repeatability, and eliminates configuration drift, as every change results in a fresh, identical instance from the same image.

Exam trap

CNCF often tests the distinction between 'immutable' (replace) and 'mutable' (update in place), and the trap here is that candidates confuse the concept with build-time practices (like using the same base image) or configuration injection methods, rather than the core runtime behavior of replacing Pods.

How to eliminate wrong answers

Option A is wrong because storing configuration only in environment variables is a specific pattern (e.g., 12-factor app), but it does not define immutability; immutable infrastructure requires replacing the entire unit, not just how config is injected. Option B is wrong because rebuilding containers from the same base image every time describes a build practice (e.g., using Dockerfile layers), but immutability is about the runtime behavior of replacing Pods, not the image build process. Option C is wrong because it describes mutable infrastructure (e.g., SSHing into a server to apply updates), which is the exact opposite of immutability; immutable infrastructure mandates that components are never updated in place—they are destroyed and recreated.

Practice this question →

131

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 maintains the Image Specification and Runtime Specification.

Why this answer

The OCI defines the image spec and runtime spec, ensuring interoperability between container tools. containerd is an OCI-compliant runtime. Docker images are OCI-compliant. Docker itself is not a runtime spec but a platform that uses runtimes.

Practice this question →

132

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

Jobs create one or more pods and ensure they successfully terminate, ideal for batch processing.

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 →

133

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 is a plugin interface that enables the kubelet to use different container runtimes.

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 →

134

Multi-Selectmedium

Which TWO statements about container images are correct? (Choose two.)

Select 2 answers

A.Container images include a full operating system kernel

B.Container images can be stored in a registry like Docker Hub

C.Container images are built from a series of layers

D.Container images are immutable once built

E.Container images can only be built on Linux

AnswersB, C

Registries store and distribute images.

Why this answer

Container images are built in layers and can be stored in registries. They are not immutable once built (they can be overwritten), and they include only the application and dependencies, not a full OS kernel.

Practice this question →

135

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 controller manager runs controllers that enforce the 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 →

136

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 replaces components instead of modifying them.

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 →

137

MCQhard

A Service of type ClusterIP is created for a Deployment, but Pods in other namespaces cannot reach it. What is the most likely cause?

A.NetworkPolicies are blocking cross-namespace traffic

B.The Pods in other namespaces are using the short Service name without the namespace suffix

C.The Service is not publishing the correct port

D.The Service selector does not match the Pod labels

AnswerB

Cross-namespace access requires the full DNS name including the namespace.

Why this answer

The most likely cause is that Pods in other namespaces are using the short Service name (e.g., `my-service`) without appending the namespace suffix (e.g., `my-service.other-namespace.svc.cluster.local`). Kubernetes DNS resolves short names only within the same namespace; cross-namespace resolution requires the fully qualified domain name (FQDN) or at least the `<service>.<namespace>.svc` form. Without this, the DNS lookup fails, making the Service unreachable from other namespaces.

Exam trap

The trap here is that candidates often assume DNS works globally across namespaces with short names, but Kubernetes DNS only resolves short names within the same namespace by default, requiring the namespace suffix for cross-namespace access.

How to eliminate wrong answers

Option A is wrong because NetworkPolicies are not enabled by default and would require explicit configuration to block cross-namespace traffic; the question states Pods 'cannot reach it' without mentioning any NetworkPolicy, so this is not the most likely cause. Option C is wrong because if the Service were not publishing the correct port, it would affect all clients, not just those in other namespaces, and the question specifically isolates the issue to cross-namespace access. Option D is wrong because if the Service selector did not match the Pod labels, the Service would have no endpoints at all, making it unreachable from any namespace, not just from other namespaces.

Practice this question →

138

MCQmedium

An application running in a Kubernetes pod needs to access a database that is deployed on a VM outside the cluster. The database IP is stable. Which is the best way to expose the database to the pod?

A.Expose the database via Ingress

B.Create a Service of type ExternalName pointing to the database hostname

C.Use a Headless Service

D.Create an EndpointSlice manually with the pod IP

AnswerB

ExternalName service provides a DNS alias to an external resource.

Why this answer

A Service of type ExternalName provides a DNS-based abstraction for external resources, mapping a Kubernetes service name to an external DNS name (the database hostname). This allows the pod to access the database via a stable in-cluster DNS name without needing to manage IP changes or network policies for external endpoints. It is the simplest and most Kubernetes-native way to expose a stable external IP to a pod.

Exam trap

The KCNA exam often tests the misconception that Ingress can handle any external service, but Ingress is strictly for HTTP/HTTPS traffic and cannot expose raw TCP services like databases.

How to eliminate wrong answers

Option A is wrong because Ingress is designed for HTTP/HTTPS traffic routing to internal services, not for exposing external databases (which typically use non-HTTP protocols like TCP). Option C is wrong because a Headless Service is used for stateful applications or service discovery of pod IPs within the cluster, not for pointing to an external resource. Option D is wrong because manually creating an EndpointSlice with the pod IP would require the database to be running as a pod inside the cluster, which contradicts the scenario where the database is on an external VM.

Practice this question →

139

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 →

140

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 kernel and have minimal overhead, making them lightweight.

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 →

141

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

StatefulSets provide ordered, unique pod names and persistent storage per replica.

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 →

142

MCQmedium

A user wants to ensure that a pod is automatically restarted if its main process crashes. Which Kubernetes controller should they use?

A.Deployment

B.Job

C.DaemonSet

D.CronJob

AnswerA

Deployments maintain desired pod count and restart failed pods via ReplicaSet.

Why this answer

A Deployment is the correct controller because it manages a ReplicaSet, which ensures a specified number of pod replicas are running at all times. If the main process in a pod crashes, the ReplicaSet detects the pod failure (via the kubelet's liveness probe or the pod's phase becoming 'Failed') and automatically creates a new pod to replace it, thereby restarting the application. This self-healing behavior is a core feature of Deployments, making them ideal for stateless applications that need continuous availability.

Exam trap

CNCF often tests the misconception that a 'restart' means the same pod is reused, but in Kubernetes, a Deployment (via ReplicaSet) creates a completely new pod, while the 'restartPolicy' field only controls container restarts within the same pod — the trap is confusing pod-level restart (ReplicaSet replacement) with container-level restart (kubelet action).

How to eliminate wrong answers

Option B (Job) is wrong because a Job is designed to run a finite task to completion; it does not automatically restart pods if the main process crashes — instead, it may create a new pod only if the Job's restart policy is set to 'OnFailure', but the Job itself is not intended for long-running, always-on services. Option C (DaemonSet) is wrong because it ensures that a copy of a pod runs on every node (or a subset of nodes), but its primary purpose is node-level services (e.g., logging, monitoring), not automatic restart of a crashed main process in a general-purpose application; while DaemonSets do use a controller that recreates pods on failure, the question asks for a controller that ensures restart for a single application, and DaemonSet is node-scoped, not workload-scoped. Option D (CronJob) is wrong because it runs Jobs on a scheduled basis; it does not provide continuous pod restart — it only creates Jobs at specified times, and the underlying Job's behavior applies, but the CronJob itself does not monitor or restart crashed pods between scheduled runs.

Practice this question →

143

MCQeasy

What is the Container Runtime Interface (CRI)?

A.A plugin interface that allows kubelet to use a variety of container runtimes

B.A specification for container images

C.A registry for storing container images

D.A command-line tool for managing containers

AnswerA

CRI enables kubelet to communicate with runtimes.

Why this answer

The Container Runtime Interface (CRI) is a plugin interface that enables the kubelet to communicate with different container runtimes (e.g., containerd, CRI-O) without needing to know their internal implementation details. It defines a gRPC-based protocol for managing container lifecycles, image operations, and pod sandboxes, allowing Kubernetes to remain runtime-agnostic.

Exam trap

CNCF often tests whether candidates confuse CRI with the OCI runtime spec or with container image formats, so the trap is assuming CRI defines image structure rather than the runtime-kubelet interface.

How to eliminate wrong answers

Option B is wrong because container images are defined by the OCI Image Specification, not by CRI. Option C is wrong because registries (like Docker Hub or Harbor) are storage systems for images, not an interface for runtime integration. Option D is wrong because command-line tools (e.g., crictl) may use CRI under the hood, but CRI itself is an API, not a CLI tool.

Practice this question →

144

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

This command creates a Deployment named nginx with the specified image and replicas.

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 →

145

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 and do not need to boot a guest OS, leading to faster startup times and lower overhead.

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 →

146

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 runs on each node and manages pod lifecycles, including starting containers via the container runtime.

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 →

147

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

This matches the requirement.

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 →

148

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 defines ingress/egress rules for pod communication.

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 →

149

Multi-Selectmedium

Which TWO of the following are valid ways to expose a set of pods as a network service in Kubernetes?

Select 2 answers

A.Service of type NodePort

B.NetworkPolicy

C.Service of type ClusterIP

D.Ingress resource

E.Deployment with replicas

AnswersA, C

NodePort exposes the service on each node's IP at a static port.

Why this answer

A Service of type NodePort exposes a set of pods on a static port on each node's IP address, making the service accessible from outside the cluster. This is a valid Kubernetes resource for exposing pods as a network service, as it creates a mapping from a node port to the ClusterIP and then to the target pods.

Exam trap

The KCNA exam often tests the misconception that Ingress or NetworkPolicy can directly expose pods as a network service, but Ingress requires a Service backend and NetworkPolicy only controls traffic, not exposure.

Practice this question →

150

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

This is the correct syntax to create a Deployment with the given name, image, and replica count.

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 →