Knowledge + Practice

CCNA Container Orchestration Questions

75 of 173 questions · Page 1/3 · Container Orchestration · Answers revealed

Practice these questions Domain overview All questions

1

MCQeasy

Which of the following is a key benefit of container orchestration compared to running containers manually?

A.Containers use less memory

B.Automatic scaling and self-healing

C.Orchestration eliminates the need for container images

D.Containers run faster when orchestrated

AnswerB

Orchestration platforms like Kubernetes provide automatic scaling and self-healing capabilities.

Why this answer

Container orchestration platforms like Kubernetes provide automatic scaling and self-healing capabilities that are not available when running containers manually. Self-healing automatically restarts failed containers, reschedules them when nodes fail, and replaces containers that fail health checks, while scaling adjusts the number of replicas based on CPU/memory metrics or custom metrics. Manual container management requires operators to monitor and intervene for each failure or load change, making orchestration essential for production-grade reliability and elasticity.

Exam trap

CNCF exams test that orchestration's primary benefits are automation, resilience, and declarative management, not raw speed or memory savings. Avoid choosing options that claim performance or resource improvements.

How to eliminate wrong answers

Option A is wrong because container orchestration does not inherently reduce memory usage; memory consumption depends on the container image and application, not the orchestration layer. Option C is wrong because orchestration still requires container images (e.g., Docker images stored in a registry) to run pods; it does not eliminate the need for images. Option D is wrong because orchestration does not make containers run faster; it adds a small overhead for scheduling and API calls, and performance is determined by the runtime and host OS, not the orchestrator.

Practice this question →

2

Multi-Selecthard

Which THREE are valid container runtimes that implement the Kubernetes CRI? (Choose three.)

Select 3 answers

A.Docker (via dockershim, deprecated)

B.containerd

C.runc

D.CRI-O

E.rkt

AnswersA, B, D

Docker used dockershim to implement CRI, now deprecated.

Why this answer

containerd, CRI-O, and Docker (via dockershim, deprecated) implement CRI. rkt is discontinued and not CRI-compliant; runc is a low-level runtime, not a CRI implementation.

Practice this question →

3

MCQhard

An administrator wants to ensure that a specific pod only runs on nodes that have solid-state drives (SSDs). Nodes with SSDs are labeled with 'disktype=ssd'. Which pod specification field should be used?

A.nodeSelector

B.container resource limits

C.tolerations

D.nodeAffinity

AnswerA

nodeSelector directly matches node labels and is the simplest approach for this requirement.

Why this answer

The `nodeSelector` field in a Pod spec is the simplest and most direct way to constrain a Pod to nodes with specific labels. By setting `nodeSelector: { disktype: ssd }`, the scheduler will only place the Pod on nodes that have the label `disktype=ssd`, which matches the administrator's requirement exactly. This field is a hard constraint that does not support complex expressions, but it is ideal for straightforward label-based node selection.

Exam trap

The trap here is that candidates often confuse `nodeSelector` with `nodeAffinity` and choose `nodeAffinity` because it sounds more powerful, but the question explicitly asks for the field that ensures a specific pod only runs on nodes with SSDs, and `nodeSelector` is the correct, minimal field for a simple label match.

How to eliminate wrong answers

Option B is wrong because container resource limits (e.g., `resources.limits.cpu` and `resources.limits.memory`) control how much CPU and memory a container can consume, not where the Pod is scheduled. Option C is wrong because tolerations are used to allow Pods to schedule on nodes with taints, not to select nodes based on labels; tolerations enable scheduling on tainted nodes but do not actively select nodes by label. Option D is wrong because `nodeAffinity` is a more advanced feature that supports complex label matching (e.g., `requiredDuringSchedulingIgnoredDuringExecution` with `matchExpressions`), but the question asks for the field that should be used, and `nodeSelector` is the simplest and most appropriate for a single label match like `disktype=ssd`.

Practice this question →

4

Multi-Selectmedium

Which TWO of the following are benefits of using a container orchestration platform like Kubernetes? (Select 2)

Select 2 answers

A.Single-node deployment for simplicity

B.Manual scaling of applications

C.Automated scaling based on demand

D.Elimination of all application bugs

E.High availability through automated failover

AnswersC, E

Horizontal Pod Autoscaler scales replicas automatically.

Why this answer

Kubernetes includes a Horizontal Pod Autoscaler (HPA) that automatically adjusts the number of pod replicas based on observed CPU, memory, or custom metrics. This enables applications to scale out during traffic spikes and scale in during low demand, improving resource utilization and responsiveness without manual intervention.

Exam trap

CNCF often tests the distinction between 'benefits' and 'basic features'—candidates may incorrectly select manual scaling (B) as a benefit, but the exam expects you to recognize that automation (C) and high availability (E) are the true advantages of orchestration platforms.

Practice this question →

5

Multi-Selecteasy

Which TWO of the following are benefits of using containers over virtual machines? (Choose 2)

Select 2 answers

A.Containers are more lightweight and start faster than VMs

B.Containers require hypervisor software to run

C.Containers include a full guest operating system

D.Containers are portable across different environments

E.Containers provide stronger isolation than VMs

AnswersA, D

Containers share the host OS kernel and do not need to boot an OS, so they start in seconds.

Why this answer

Containers share the host OS kernel and run as isolated processes, making them lightweight and able to start in milliseconds, unlike VMs which require booting a full guest OS. This efficiency stems from container images being mere megabytes compared to gigabytes for VM images, and containers using cgroups and namespaces for resource management rather than a hypervisor.

Exam trap

The trap here is that candidates confuse container isolation with VM isolation, assuming containers are more secure, when in fact VMs provide stronger isolation due to hardware virtualization, and CNCF often tests this distinction by offering 'stronger isolation' as a distractor.

Practice this question →

6

MCQmedium

A Kubernetes cluster has a Service named 'my-svc' in the 'default' namespace. Which command would correctly expose this service as an external endpoint using a cloud load balancer?

A.kubectl expose deployment my-svc --type=LoadBalancer --name=my-svc-lb

B.kubectl expose service my-svc --name=my-svc-lb

C.kubectl expose service my-svc --port=80 --target-port=8080

D.kubectl expose service my-svc --type=LoadBalancer --name=my-svc-lb

AnswerD

Correctly creates a new LoadBalancer service based on the existing service.

Why this answer

`kubectl expose service my-svc --type=LoadBalancer --name=my-svc-lb` creates a new Service of type LoadBalancer that inherits the selector and port configuration from the existing 'my-svc' Service, which provisions a cloud load balancer (e.g., AWS ELB, GCP TCP/UDP LB) to expose it externally. The `--type=LoadBalancer` flag is essential to request a cloud load balancer, and `--name` specifies the new Service's name to avoid overwriting the original.

Exam trap

The CNCF exam often tests the misconception that `kubectl expose service` without `--type=LoadBalancer` will automatically expose the service externally, when in fact it only creates a ClusterIP Service unless the type is explicitly specified.

How to eliminate wrong answers

Option A is wrong because `kubectl expose deployment my-svc` attempts to expose a Deployment named 'my-svc', but the question specifies a Service named 'my-svc', not a Deployment; exposing a Deployment would create a new Service from scratch, not modify the existing one. Option B is wrong because `kubectl expose service my-svc --name=my-svc-lb` omits `--type=LoadBalancer`, so it creates a new Service of the default type ClusterIP, which is only reachable within the cluster and does not provision an external load balancer. Option C is wrong because `kubectl expose service my-svc --port=80 --target-port=8080` changes the port mapping but does not include `--type=LoadBalancer`, so the resulting Service remains ClusterIP (or inherits the original type) and does not become an external endpoint via a cloud load balancer.

Practice this question →

7

MCQhard

A Kubernetes cluster is experiencing network latency. The team suspects that the number of services and endpoints is causing iptables performance degradation. Which CNI plugin or network policy approach is most likely to improve performance?

A.Switch to Flannel with host-gw backend

B.Use Calico with iptables mode

C.Use an eBPF-based CNI plugin like Cilium

D.Apply a default-deny NetworkPolicy

AnswerC

eBPF bypasses iptables, reducing latency and improving scalability.

Why this answer

C is correct because eBPF-based CNI plugins like Cilium bypass the traditional iptables chains entirely, using a kernel-level BPF (Berkeley Packet Filter) program to handle service load balancing and network policy enforcement. This eliminates the O(n) scaling issue of iptables rules with the number of services and endpoints, significantly reducing latency in large clusters.

Exam trap

The trap here is that candidates often assume any CNI change or network policy adjustment can fix iptables performance, but only eBPF-based solutions fundamentally change the data path to avoid iptables scaling limitations.

How to eliminate wrong answers

Option A is wrong because Flannel with host-gw backend only improves pod-to-pod routing by using direct host routes, but it does not address iptables performance degradation for service load balancing; Flannel still relies on iptables or IPVS for Service ClusterIP forwarding. Option B is wrong because Calico with iptables mode uses the same iptables data path that is already causing performance issues; it would not improve latency and may even worsen it with additional policy rules. Option D is wrong because applying a default-deny NetworkPolicy adds more iptables rules to enforce isolation, which increases the rule count and further degrades iptables performance, the opposite of what is needed.

Practice this question →

8

MCQmedium

You need to run a batch job that processes a queue and then terminates. Which Kubernetes resource should you use?

A.Deployment

B.DaemonSet

C.StatefulSet

D.Job

AnswerD

Jobs ensure a specified number of Pods successfully terminate, ideal for batch processing.

Why this answer

A Job is the correct Kubernetes resource for running a batch process that executes a finite task (e.g., processing a queue) and then terminates. Unlike controllers that maintain a desired state indefinitely, a Job creates one or more Pods and ensures they run to successful completion, after which the Job itself completes and no further Pods are created.

Exam trap

CNCF often tests the misconception that a Deployment can be used for any workload, but the trap here is that a Deployment's restart policy (Always) makes it unsuitable for terminating batch jobs, whereas a Job's restart policy (OnFailure or Never) is specifically designed for finite tasks.

How to eliminate wrong answers

Option A is wrong because a Deployment is designed for long-running, stateless applications that must maintain a desired replica count indefinitely; it will restart Pods upon completion, which is the opposite of a terminating batch job. Option B is wrong because a DaemonSet ensures that a copy of a Pod runs on every (or selected) Node in the cluster, typically for cluster-wide services like logging or monitoring, not for a one-time batch task. Option C is wrong because a StatefulSet is intended for stateful applications that require stable, unique network identities and persistent storage, such as databases, and it maintains a sticky identity across restarts, which is unnecessary and inappropriate for a terminating queue-processing job.

Practice this question →

9

MCQhard

You are designing a microservices application. Which of the following is a key principle of microservices architecture?

A.Services are loosely coupled and can be deployed independently

B.Services are tightly coupled to allow fast communication

C.All services must be written in the same programming language

D.All services must share a common database

AnswerA

This enables agility and scalability.

Why this answer

Microservices architecture is fundamentally defined by loose coupling and independent deployability. Each service encapsulates its own domain logic, communicates via lightweight protocols like HTTP/REST or gRPC, and can be updated, scaled, or deployed without affecting other services. This aligns with the Kubernetes-native pattern of managing each microservice as a separate Deployment or StatefulSet, enabling continuous delivery and resilience.

Exam trap

CNCF often tests the misconception that microservices require a single shared database or a single programming language, confusing microservices with a distributed monolith; the trap here is assuming that 'fast communication' (Option B) justifies tight coupling, when in reality loose coupling is prioritized for resilience and independent deployability.

How to eliminate wrong answers

Option B is wrong because tight coupling contradicts the core principle of microservices; it would create a monolithic dependency graph where a change in one service requires coordinated changes in others, negating the benefits of independent scaling and fault isolation. Option C is wrong because microservices explicitly allow polyglot programming — each service can be written in the language best suited for its task (e.g., Go for high-throughput services, Python for data processing) and communicate over standard protocols. Option D is wrong because sharing a single database creates tight coupling at the data layer, violating service autonomy; each microservice should own its private database (database-per-service pattern) to avoid schema conflicts and enable independent schema evolution.

Practice this question →

10

MCQeasy

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

A.Deployment controller

B.kube-proxy

C.kubelet

D.etcd

AnswerA

The Deployment controller ensures the desired number of pod replicas is running.

Why this answer

The Deployment controller is a core Kubernetes controller that runs as part of the kube-controller-manager. It continuously watches the cluster's current state via the API server and reconciles it with the desired state defined in Deployment objects, ensuring the correct number of Pod replicas are running, updated, and available. This makes it the primary component responsible for maintaining the desired state of the cluster for stateless workloads.

Exam trap

CNCF often tests the misconception that etcd is responsible for maintaining desired state because it stores the desired state, but candidates must remember that etcd is only a data store, not an active controller that reconciles state.

How to eliminate wrong answers

Option B (kube-proxy) is wrong because it is a network proxy that runs on each node, handling service-to-Pod traffic routing using iptables or IPVS rules, not maintaining desired state. Option C (kubelet) is wrong because it is the node agent that ensures containers are running in a Pod as specified by the PodSpec, but it only acts on instructions from the API server and does not maintain the overall desired state of the cluster. Option D (etcd) is wrong because it is a distributed key-value store that holds the cluster's configuration and state data, but it is a passive storage backend and does not actively reconcile or maintain the desired state.

Practice this question →

11

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 CPU request for the container

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

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

D.Delete the namespace and redeploy all workloads

AnswerC

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. Increasing the memory limit in the pod's container resource specification directly addresses the root cause by allowing the container to use more memory before being killed. This is the most appropriate action because the pod was running successfully for days, suggesting a gradual memory growth or a recent workload change rather than a configuration error.

Exam trap

CNCF often tests the misconception that OOMKilled is a CPU issue, leading candidates to incorrectly choose CPU adjustments, or that simply restarting the pod will fix the underlying resource constraint.

How to eliminate wrong answers

Option A is wrong because increasing the CPU request does not affect memory usage; OOMKilled is a memory-related issue, not CPU. Option B is wrong because deleting and recreating the pod would only temporarily restart the container; the same memory limit would still be enforced, and the pod would likely crash again. Option D is wrong because deleting the entire namespace and redeploying all workloads is an extreme, disruptive action that does not address the specific memory limit issue and would cause unnecessary downtime.

Practice this question →

12

MCQmedium

A developer wants to run a containerized application locally for development. Which tool is most appropriate?

A.CRI-O

B.Docker Compose

C.containerd

D.Kubernetes

AnswerB

Ideal for local development with multi-container apps.

Why this answer

Docker Compose is the most appropriate tool for running a containerized application locally during development because it allows you to define and manage multi-container applications using a simple YAML file. It handles container lifecycle, networking, and volume mounts with a single `docker compose up` command, making it ideal for local development workflows where rapid iteration and simplicity are key.

Exam trap

The trap here is that candidates confuse container runtimes (CRI-O, containerd) or orchestration platforms (Kubernetes) with development tools, assuming any container-related technology can run apps locally, but the KCNA exam specifically tests the understanding that Docker Compose is the standard for local multi-container development.

How to eliminate wrong answers

Option A (CRI-O) is wrong because it is a lightweight container runtime designed for Kubernetes, not a tool for local development; it lacks the developer-friendly features like `docker compose up` and is typically used in production clusters. Option C (containerd) is wrong because it is a low-level container runtime that manages container lifecycle but does not provide orchestration or multi-container application definitions; it is a building block for higher-level tools like Docker or Kubernetes, not a development tool. Option D (Kubernetes) is wrong because it is a full-scale container orchestration platform intended for production deployments across clusters; running it locally (e.g., via Minikube or kind) adds unnecessary complexity and overhead compared to Docker Compose for simple development scenarios.

Practice this question →

13

MCQmedium

An application requires stable network identities and persistent storage. Which workload type should be used?

A.Deployment

B.DaemonSet

C.Job

D.StatefulSet

AnswerD

StatefulSets provide stable identities and persistent storage.

Why this answer

StatefulSet is the correct workload type because it provides stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage (via PersistentVolumeClaims that persist across Pod rescheduling). This makes it ideal for stateful applications like databases, where each Pod requires a stable identity and dedicated storage that survives restarts.

Exam trap

The KCNA exam often tests the misconception that Deployments can handle stateful workloads by using PersistentVolumeClaims, but they fail to account for the lack of stable network identities and ordered pod management that StatefulSet provides.

How to eliminate wrong answers

Option A is wrong because Deployment is designed for stateless applications; it creates pods with random, ephemeral identities and does not guarantee stable network names or persistent storage per pod. Option B is wrong because DaemonSet ensures one pod per node, typically for node-level services like logging or monitoring, and does not provide stable identities or persistent storage for stateful workloads. Option C is wrong because Job is intended for batch processing tasks that run to completion, not for long-running stateful services requiring stable identities and persistent storage.

Practice this question →

14

MCQeasy

Which of the following is a benefit of using an orchestrator like Kubernetes?

A.Direct access to the host kernel for performance tuning

B.Guaranteed zero downtime for all updates

C.Automatic scaling based on CPU utilization

D.Manual scaling based on traffic spikes

AnswerC

Horizontal Pod Autoscaler can automatically scale pods based on CPU or custom metrics.

Why this answer

Kubernetes, as a container orchestrator, provides built-in Horizontal Pod Autoscaling (HPA) that automatically adjusts the number of pod replicas based on observed CPU utilization (or custom metrics). This is a core benefit because it allows applications to handle varying load without manual intervention, improving resource efficiency and availability.

Exam trap

The trap here is that candidates confuse 'automatic scaling' with 'manual scaling' or assume Kubernetes guarantees zero downtime, but the exam tests the specific benefit of automated, policy-driven scaling based on metrics like CPU utilization.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not provide direct access to the host kernel; containers share the host kernel via namespaces and cgroups, and direct kernel access would break isolation and security. Option B is wrong because Kubernetes cannot guarantee zero downtime for all updates; while it supports rolling updates and strategies like maxSurge and maxUnavailable to minimize disruption, factors like application bugs or resource constraints can still cause downtime. Option D is wrong because manual scaling based on traffic spikes is not a benefit of using an orchestrator; orchestrators like Kubernetes automate scaling, and manual scaling is a legacy approach that defeats the purpose of orchestration.

Practice this question →

15

MCQeasy

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

A.etcd

B.kube-scheduler

C.Container runtime (e.g., containerd)

D.kubelet

AnswerC

The container runtime is the component that actually runs containers.

Why this answer

The container runtime (e.g., containerd) is the component responsible for actually running containers on a Kubernetes node. It pulls container images, manages container lifecycles, and handles low-level operations such as starting and stopping containers via the CRI (Container Runtime Interface). Without a container runtime, the kubelet cannot launch or manage any containers on the node.

Exam trap

The trap here is that candidates often confuse the kubelet with the container runtime, thinking the kubelet directly runs containers, when in fact the kubelet only orchestrates via the CRI and relies on a separate container runtime to execute them.

How to eliminate wrong answers

Option A is wrong because etcd is a distributed key-value store that holds all cluster data, not a component that runs containers on a node. Option B is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints, but it does not execute containers. Option D is wrong because the kubelet is the node agent that communicates with the container runtime via the CRI to ensure containers are running as expected, but it does not directly run containers itself.

Practice this question →

16

MCQmedium

Which of the following is a benefit of using container orchestration platforms like Kubernetes?

A.Increased network latency

B.Manual scaling of applications

C.Self-healing (automatic restart of failed containers)

D.Tighter coupling between microservices

AnswerC

Kubernetes automatically restarts containers that fail, replaces and reschedules pods when nodes die.

Why this answer

Kubernetes includes a built-in controller (the kubelet and ReplicaSet controller) that continuously monitors the desired state of pods. If a container fails or its process crashes, the kubelet automatically restarts it based on the pod's restart policy (e.g., Always), ensuring high availability without manual intervention. This self-healing capability is a core benefit of container orchestration, reducing downtime and operational overhead.

Exam trap

CNCF often tests the misconception that container orchestration platforms like Kubernetes increase complexity and latency, but the correct answer highlights that they actually automate recovery and improve resilience, not degrade performance.

How to eliminate wrong answers

Option A is wrong because container orchestration platforms like Kubernetes typically reduce network latency through service discovery and intelligent load balancing (e.g., kube-proxy with iptables/IPVS), not increase it. Option B is wrong because Kubernetes enables automatic scaling via Horizontal Pod Autoscaler (HPA) based on CPU/memory metrics or custom metrics, eliminating the need for manual scaling. Option D is wrong because Kubernetes promotes loose coupling between microservices through declarative APIs, service abstractions (ClusterIP), and decoupled communication patterns, not tighter coupling.

Practice this question →

17

Multi-Selectmedium

Which TWO of the following are benefits of using a container orchestration platform like Kubernetes? (Select 2)

Select 2 answers

A.Manual deployment of containers to servers

B.Requirement for a hypervisor on every node

C.Self-healing of failed containers

D.Static infrastructure that never changes

E.Automatic scaling of applications based on demand

AnswersC, E

Orchestration restarts failed containers automatically.

Why this answer

Kubernetes includes a built-in controller loop that continuously monitors the desired state of workloads. If a container or pod fails, the ReplicaSet or StatefulSet controller automatically replaces it by rescheduling a new pod, ensuring application availability without manual intervention.

Exam trap

A common misconception is that container orchestration requires hypervisors or static infrastructure, but the correct understanding is that Kubernetes abstracts the underlying hardware and provides dynamic, self-healing, and auto-scaling capabilities without hypervisors.

Practice this question →

18

MCQmedium

What is the purpose of a readiness probe in a Kubernetes pod?

A.To check if the pod has been scheduled on a node

B.To measure the CPU and memory usage of the container

C.To determine if the container is healthy and should be restarted

D.To determine if the container is ready to serve traffic

AnswerD

Readiness probes indicate when a container is ready to start accepting requests. If it fails, traffic is not sent to the pod.

Why this answer

A readiness probe in Kubernetes determines whether a container inside a pod is ready to start accepting traffic. If the probe fails, the pod is removed from the Service's endpoints, preventing traffic from being routed to an unready container. This is distinct from a liveness probe, which checks if the container is healthy and should be restarted.

Exam trap

The trap here is that candidates often confuse readiness probes with liveness probes, mistakenly thinking both are used for restarting containers, when in fact readiness probes only control traffic routing and do not trigger restarts.

How to eliminate wrong answers

Option A is wrong because checking if a pod has been scheduled on a node is the responsibility of the Kubernetes scheduler and is reflected in the pod's status (e.g., `PodScheduled` condition), not by a readiness probe. Option B is wrong because measuring CPU and memory usage is done via metrics servers or monitoring tools (e.g., `kubectl top`), not by probes; readiness probes only check application-level readiness via HTTP, TCP, or exec commands. Option C is wrong because determining if a container is healthy and should be restarted is the purpose of a liveness probe, not a readiness probe; readiness probes only affect traffic routing, not pod lifecycle.

Practice this question →

19

MCQmedium

An administrator runs 'kubectl get pods' and sees that a pod named 'app-pod' is in 'CrashLoopBackOff'. They run 'kubectl logs app-pod' and see a segmentation fault error. What is the most likely cause?

A.The node is out of memory

B.The container has a configuration error

C.The application code has a bug

D.The readiness probe is misconfigured

AnswerC

Segmentation faults are typically caused by bugs in the application code.

Why this answer

A segmentation fault (segfault) is a specific error caused by a program attempting to access memory it does not have permission to access, typically due to a bug in the application code (e.g., null pointer dereference, buffer overflow). Since the container starts but then crashes repeatedly (CrashLoopBackOff), the segfault indicates the application itself is failing, not the infrastructure or configuration. This is the most direct cause of the pod entering CrashLoopBackOff.

Exam trap

CNCF often tests the distinction between application-level errors (like segfaults) and infrastructure or configuration issues, tempting candidates to blame resource constraints or probe misconfiguration when the logs clearly point to a runtime crash.

How to eliminate wrong answers

Option A is wrong because a node out-of-memory condition would cause the pod to be evicted or fail to schedule, not produce a segmentation fault in the application logs; the kubelet would report an OOMKilled status, not a segfault. Option B is wrong because a configuration error (e.g., missing environment variable, incorrect command) would typically result in an immediate container exit with a non-zero exit code or a startup failure, not a segmentation fault which is a runtime memory access violation. Option D is wrong because a misconfigured readiness probe would cause the pod to be marked as not ready and removed from service endpoints, but the container would continue running and not crash; the logs would show probe failures, not a segfault.

Practice this question →

20

MCQhard

You have a Deployment with three replicas. You want to update the container image but ensure that only one pod is updated at a time, and the update proceeds only if the new pod becomes healthy. Which update strategy should you configure?

A.RollingUpdate with maxSurge=3 and maxUnavailable=1

B.RollingUpdate with maxSurge=1 and maxUnavailable=0

C.Canary deployment via Ingress

D.Recreate strategy

AnswerB

This configuration updates one pod at a time and waits for the new pod to become healthy before proceeding.

Why this answer

A RollingUpdate strategy with maxSurge=1 and maxUnavailable=0 ensures that exactly one new pod is created before any old pod is terminated, and the update only proceeds when the new pod passes its readiness probe (i.e., becomes healthy). This guarantees that at all times during the update, the desired number of replicas (3) are available, and only one pod is updated at a time, matching the requirement.

Exam trap

In the KCNA exam, candidates often misinterpret that maxSurge controls the number of pods updated at a time, when in reality it controls the number of extra pods allowed above the desired count, while maxUnavailable controls the number of pods that can be unavailable during the update; candidates may incorrectly choose Option A thinking maxSurge=1 means one pod at a time, but maxSurge=3 allows three new pods to be created simultaneously, violating the 'only one pod updated at a time' constraint.

How to eliminate wrong answers

Option A is wrong because maxSurge=3 allows up to 3 extra pods to be created simultaneously, which could update multiple pods at once, violating the 'only one pod updated at a time' constraint. Option C is wrong because a Canary deployment via Ingress is a traffic-splitting technique that routes a percentage of traffic to a new version, but it does not inherently control pod update ordering or ensure that only one pod is updated at a time; it is a higher-level routing strategy, not a Deployment update strategy. Option D is wrong because the Recreate strategy terminates all existing pods before creating new ones, causing downtime and violating the requirement that the update proceeds only if the new pod becomes healthy (since all pods are replaced simultaneously).

Practice this question →

21

MCQhard

You need to deploy a batch job that processes a queue and runs to completion. The job should run exactly once and create exactly one pod per work item, but some items may fail. Which Kubernetes resource is best suited?

A.Deployment

B.Job

C.CronJob

D.DaemonSet

AnswerB

A Job is designed for batch processing, ensuring a specified number of pods complete successfully.

Why this answer

A Kubernetes Job is the correct resource for batch processing tasks that run to completion, such as processing a queue where each work item corresponds to a pod. By configuring the `.spec.completions` and `.spec.parallelism` fields, you can ensure exactly one pod per work item and control concurrency. The Job automatically retries failed pods (up to a configurable limit) without restarting the entire batch, making it ideal for handling some failures.

In contrast, a Deployment (A) is for long-running, continuously available services; a CronJob (C) is for scheduled recurring jobs; and a DaemonSet (D) runs a pod on every node for infrastructure tasks. Therefore, Job (B) is the best fit.

Exam trap

The KCNA exam often tests the distinction between batch and long-running workloads, and the trap here is that candidates may confuse a Job with a Deployment because both can create multiple pods, but a Deployment is designed for continuous availability, not one-time execution.

How to eliminate wrong answers

Option A is wrong because a Deployment is intended for long-running, stateless applications that maintain a desired number of replicas, not for batch jobs that run to completion; it would restart pods indefinitely, violating the 'run exactly once' requirement. Option C is wrong because a CronJob schedules Jobs on a time-based schedule, but the question specifies a one-time batch job that processes a queue and runs to completion, not a recurring task. Option D is wrong because a DaemonSet ensures exactly one pod runs on each node in the cluster, which is used for node-level services like logging or monitoring, not for processing a queue with one pod per work item.

Practice this question →

22

MCQmedium

A company wants to adopt immutable infrastructure for its containerized applications. Which practice BEST exemplifies immutability?

A.Developers use kubectl exec to change environment variables in a running pod

B.When a container fails, the orchestrator terminates it and launches a new container from the same image

C.A configuration management tool runs periodically to ensure containers are up-to-date

D.An operator logs into a running container and applies a security patch with apt-get update

AnswerB

Immutable infrastructure treats containers as disposable; failures are handled by replacement, not repair.

Why this answer

Immutable infrastructure means that once a container is deployed from a specific image, it is never modified in place. When a container fails, the orchestrator (e.g., Kubernetes) terminates it and launches a new container from the same image, ensuring consistency and reproducibility. This approach eliminates configuration drift and aligns with the principle that all changes should be made by rebuilding the image, not by altering running instances.

Exam trap

The trap here is that candidates confuse immutability with automation, thinking that any automated update (like a config management tool) is acceptable, when in fact immutability in Kubernetes requires that no changes are made to running containers — only new images are deployed via rolling updates or similar mechanisms.

How to eliminate wrong answers

Option A is wrong because using kubectl exec to change environment variables in a running pod directly modifies the container's state, violating immutability by introducing runtime changes that are not captured in the image. Option C is wrong because a configuration management tool that runs periodically to update containers implies in-place modifications, which contradicts the immutable model where updates should come from deploying new images. Option D is wrong because logging into a running container and applying a security patch with apt-get update mutates the container's filesystem, creating a snowflake server that cannot be reliably reproduced from the original image.

Practice this question →

23

MCQhard

Your organization runs a microservices application in a Kubernetes cluster with 5 worker nodes. Each microservice is deployed as a Deployment with 3 replicas. Recently, users report intermittent timeouts when accessing the frontend service. The frontend communicates with a backend service via ClusterIP. You check the backend pods and find that one of the three replicas is in CrashLoopBackOff. The other two backend pods are healthy. The frontend deployment has no readiness or liveness probes. You notice that the frontend's connection pool to the backend has a timeout of 5 seconds. The crashing backend pod logs show an occasional NullPointerException that causes the container to restart, but the pod becomes ready after restart within 2 seconds. However, the frontend's connection pool does not evict unhealthy connections quickly. What is the best course of action to reduce timeouts?

A.Increase the number of backend replicas to 5 to absorb the failures.

B.Add a readiness probe to the backend Deployment that checks the application health endpoint.

C.Add a liveness probe to the frontend Deployment.

D.Increase the frontend connection pool timeout to 10 seconds.

AnswerB

Readiness probe will remove the pod from the Service endpoints when it is not ready.

Why this answer

The intermittent timeouts occur because the frontend's connection pool holds stale connections to the backend pod that is in CrashLoopBackOff. Although the pod restarts and becomes ready within 2 seconds, the frontend does not detect that the old connection is broken and continues to use it until the 5-second timeout expires. Adding a readiness probe to the backend Deployment ensures that Kubernetes only sends traffic to pods that pass the health check; when the pod fails the probe, it is removed from the ClusterIP's endpoints, preventing the frontend from routing requests to it and thus eliminating the timeouts.

Exam trap

The trap here is that candidates often confuse readiness and liveness probes, thinking a liveness probe is needed to restart the failing backend pod, but the real issue is traffic routing and connection pool management, which a readiness probe solves by removing the unhealthy pod from the service endpoints.

How to eliminate wrong answers

Option A is wrong because simply increasing the number of replicas does not address the root cause—stale connections to a failing pod—and may only mask the problem while wasting resources. Option C is wrong because adding a liveness probe to the frontend Deployment would restart the frontend pod if it becomes unhealthy, but the frontend itself is not crashing; the issue is connection management to the backend. Option D is wrong because increasing the connection pool timeout to 10 seconds would only make the timeouts longer, not prevent them; the frontend would still wait up to 10 seconds on a broken connection instead of quickly failing over.

Practice this question →

24

MCQmedium

Which of the following is a benefit of container orchestration?

A.Requires a hypervisor for each container

B.Manual scaling of containers

C.Static infrastructure with no changes

D.Self-healing of failed containers

AnswerD

Orchestration restarts failed containers automatically.

Why this answer

Container orchestration platforms like Kubernetes provide self-healing capabilities by automatically restarting failed containers, rescheduling them on healthy nodes, and replacing or terminating containers that fail health checks. This ensures high availability and reduces manual intervention, which is a core benefit of orchestration.

Exam trap

CNCF often tests the misconception that container orchestration is only about initial deployment, when in fact its key value is ongoing automated management like self-healing and scaling.

How to eliminate wrong answers

Option A is wrong because container orchestration does not require a hypervisor for each container; containers share the host OS kernel and run as isolated processes, unlike VMs that need a hypervisor. Option B is wrong because container orchestration enables automatic scaling (e.g., horizontal pod autoscaling in Kubernetes), not manual scaling, which would defeat the purpose of automation. Option C is wrong because container orchestration promotes dynamic infrastructure with automated deployment, scaling, and updates, not static infrastructure with no changes.

Practice this question →

25

MCQhard

A pod uses a ServiceAccount that has a RoleBinding to a Role with 'get', 'list', 'watch' on 'pods'. The pod tries to list pods in the same namespace. Will the request succeed?

A.No, because there is a deny rule for pods

B.Yes, because the Role grants 'list' on pods

C.No, because ServiceAccount cannot list pods

D.Yes, but only if the ServiceAccount also has a ClusterRoleBinding

AnswerB

The Role includes 'list' permission, and the binding applies to the same namespace.

Why this answer

In Kubernetes RBAC, permissions are additive. The Role grants 'list' on pods, so the ServiceAccount can list pods. There is no deny rule; RBAC is deny by default, but the permission is explicitly granted.

Option A is incorrect because there is no deny rule for pods. Option C is incorrect because a ServiceAccount can list pods if it has the appropriate RBAC permissions. Option D is incorrect because a ClusterRoleBinding is not required; a RoleBinding in the same namespace is sufficient.

Practice this question →

26

MCQmedium

You are troubleshooting a service that is not accessible from within the cluster. The service has a label selector that matches the pods. You run 'kubectl get endpoints myservice' and see that the ENDPOINTS column is empty. What is the most likely cause?

A.The kube-proxy is not running

B.The service's label selector does not match any pods

C.The service is in a different namespace

D.The service type is LoadBalancer and no external load balancer is provisioned

AnswerB

Endpoints are created for pods matching the selector; if none match, endpoints are empty.

Why this answer

The ENDPOINTS column being empty for a service indicates that the service's label selector does not match any running pods. Kubernetes uses the label selector to dynamically populate the endpoints list; if no pods match, the service has no backends to forward traffic to, making it inaccessible from within the cluster.

Exam trap

Kubernetes often tests the distinction between service endpoint population (which depends on label selectors) and traffic forwarding (which depends on kube-proxy), leading candidates to incorrectly blame kube-proxy when the actual issue is a selector mismatch.

How to eliminate wrong answers

Option A is wrong because if kube-proxy were not running, the service would still have endpoints (as long as pods match the selector), but traffic would not be forwarded; the ENDPOINTS column would not be empty. Option C is wrong because a service in a different namespace would not be accessible by name without a fully qualified name, but the 'kubectl get endpoints' command would still show endpoints if pods in that namespace match the selector. Option D is wrong because a LoadBalancer service without an external load balancer provisioned would still have internal endpoints (the pod IPs) and the ENDPOINTS column would not be empty; the issue is external access, not internal reachability.

Practice this question →

27

Multi-Selecthard

Which TWO of the following are valid methods to expose a set of pods to external traffic in Kubernetes?

Select 2 answers

A.LoadBalancer Service

B.NodePort Service

C.Headless Service

D.ClusterIP Service

E.Ingress

AnswersA, B

Provisions an external load balancer.

Why this answer

A LoadBalancer Service is a valid method to expose pods to external traffic because it provisions an external load balancer (e.g., AWS ELB, GCP LB) that assigns a public IP address, routing external traffic to the Service's ClusterIP and then to the pods. This is a standard Kubernetes Service type defined in the ServiceSpec, making it correct for external exposure.

Exam trap

The KCNA exam often tests the distinction between 'exposing pods' and 'routing traffic' — the trap here is that candidates mistakenly select Ingress as a direct exposure method, when in fact Ingress only defines routing rules and relies on a Service (like NodePort or LoadBalancer) to actually make pods reachable from outside the cluster.

Practice this question →

28

Multi-Selecteasy

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

Select 2 answers

A.Images are always pulled from a private registry

B.Each layer is identified by a unique hash

C.Images can be modified at runtime by writing to the container layer

D.Images are built from a series of read-only layers

E.Images are stored on the host filesystem after being pulled

AnswersB, D

Layers are content-addressable and identified by their digest.

Why this answer

Each layer in a container image is identified by a unique content-addressable hash (typically a SHA-256 digest). This hash is computed from the layer's contents and metadata, ensuring integrity and enabling layer caching and deduplication across images. The hash is used in the image manifest (as defined by the OCI Image Specification) to reference each layer uniquely.

Exam trap

CNCF often tests the misconception that images are stored directly on the host filesystem like regular files, when in reality they are stored in a runtime-managed cache (e.g., /var/lib/docker) and are not directly accessible as ordinary files.

Practice this question →

29

MCQmedium

A pod spec includes a liveness probe that runs 'cat /tmp/healthy'. The probe is configured with initialDelaySeconds: 10, periodSeconds: 5. At what point does the kubelet first execute the probe?

A.Immediately after the pod is created

B.Only when the container is unhealthy

C.5 seconds after the container starts

D.10 seconds after the container starts

AnswerD

The initialDelaySeconds of 10 means the probe is first executed 10 seconds after the container starts.

Why this answer

The kubelet first executes the liveness probe 10 seconds after the container starts because `initialDelaySeconds: 10` tells the kubelet to wait that long before initiating the first probe. The `periodSeconds: 5` only defines the interval between subsequent probes, not the initial delay. This ensures the container has time to start and create the `/tmp/healthy` file before being checked.

Exam trap

The trap here is confusing `initialDelaySeconds` with `periodSeconds`, leading candidates to think the probe runs after 5 seconds (the period) instead of 10 seconds (the initial delay).

How to eliminate wrong answers

Option A is wrong because the kubelet does not execute probes immediately after pod creation; it waits for the container to start and then applies `initialDelaySeconds`. Option B is wrong because liveness probes are executed periodically regardless of container health, not only when the container is unhealthy; the probe itself determines health. Option C is wrong because `periodSeconds: 5` controls the interval between probes after the first one, not the initial delay; the first probe occurs after `initialDelaySeconds`, which is 10 seconds.

Practice this question →

30

MCQmedium

A DevOps team notices that a new deployment of a web application is not receiving traffic even though the pods are running. The deployment has a selector matching the pod labels, and a Service of type ClusterIP exists. What is the most likely cause?

A.The Service's targetPort does not match the container's containerPort.

B.The pods do not have a readiness probe defined.

C.The Service type should be NodePort to receive traffic.

D.The Service is not exposed via an Ingress.

AnswerA

The Service routes traffic to the targetPort, which must match the port the container listens on.

Why this answer

The most likely cause is that the Service's targetPort does not match the container's containerPort. In Kubernetes, a Service routes traffic to pods by forwarding packets to the port specified in the Service's `targetPort` field. If this does not match the `containerPort` defined in the pod's container spec, the traffic will be dropped because the kube-proxy will forward packets to a closed port on the pod, resulting in no connectivity even though the pods are running.

Exam trap

The trap here is that candidates often confuse the Service's `port` (the port the Service listens on) with `targetPort` (the port on the pod), assuming they must match, or they incorrectly attribute the issue to missing readiness probes or Ingress resources.

How to eliminate wrong answers

Option B is wrong because a readiness probe controls whether a pod is considered ready to receive traffic, but its absence does not prevent traffic from being sent to the pod; it simply means the pod will always be considered ready. Option C is wrong because a Service of type ClusterIP is perfectly capable of receiving traffic within the cluster; NodePort is only needed for external access from outside the cluster, not for internal traffic. Option D is wrong because an Ingress is an optional API object for HTTP/HTTPS routing and is not required for a ClusterIP Service to receive traffic; the Service itself can be accessed directly via its cluster IP.

Practice this question →

31

MCQmedium

A Kubernetes cluster has a single control plane node and two worker nodes. The control plane node fails. What is the immediate impact on the workloads running on the worker nodes?

A.All workloads will stop immediately

B.Existing workloads continue running, but no new pods can be scheduled

C.The kubelet on worker nodes will restart all pods

D.Workloads will be automatically migrated to another cluster

AnswerB

The kubelet on worker nodes keeps existing pods running, but the scheduler cannot assign new pods without the control plane.

Why this answer

In Kubernetes, the control plane is responsible for scheduling new pods and maintaining desired state via the API server, controller manager, and scheduler. When the control plane fails, the kubelets on worker nodes continue to run existing pods based on their local state, but the scheduler cannot assign new pods to nodes, and the API server is unavailable for updates or scaling operations.

Exam trap

CNCF often tests the misconception that the control plane is required for all pod operations, leading candidates to assume workloads stop immediately, when in fact the kubelet provides resilience for existing pods.

How to eliminate wrong answers

Option A is wrong because existing workloads are managed by the kubelet on each worker node, which runs pods independently of the control plane; they do not stop immediately. Option C is wrong because the kubelet does not restart all pods upon control plane failure; it only restarts pods that have failed according to its local restart policy, not as a reaction to the control plane being down. Option D is wrong because Kubernetes does not automatically migrate workloads to another cluster; migration requires manual intervention or a multi-cluster management tool like KubeFed or a service mesh.

Practice this question →

32

MCQmedium

What is the purpose of a Readiness Probe in a Kubernetes pod?

A.To ensure the pod is scheduled on a specific node

B.To restart the container if it becomes unresponsive

C.To check if the container is ready to start accepting traffic

D.To check if the container is running

AnswerC

Readiness probe signals readiness to serve.

Why this answer

A Readiness Probe indicates whether a pod is ready to serve traffic; if it fails, the pod is removed from Service endpoints.

Practice this question →

33

MCQhard

You have a microservices application where Service A needs to communicate with Service B running in a different namespace ('backend'). Both namespaces have a NetworkPolicy that denies all ingress by default. You create a NetworkPolicy in the 'backend' namespace allowing ingress from pods with label 'app: frontend'. What else is needed for Service A to reach Service B?

A.Ensure Service A's pod has the label 'app: frontend' on its pod spec

B.Add a similar NetworkPolicy in the 'default' namespace allowing egress to the 'backend' namespace

C.Change the NetworkPolicy to allow all ingress traffic from any source

D.Add a label to the 'default' namespace matching the NetworkPolicy's namespaceSelector

AnswerD

Correct. By adding a label to the 'default' namespace and including a namespaceSelector matching that label in the NetworkPolicy, you allow ingress from pods in the 'default' namespace. Combined with the podSelector for 'app: frontend', this enables Service A to reach Service B.

Why this answer

A NetworkPolicy with only a podSelector in an ingress rule matches pods in the same namespace only. To allow cross-namespace traffic, you must include a namespaceSelector that selects the namespace of the source pods. By adding a label to the 'default' namespace and including a namespaceSelector matching that label in the NetworkPolicy, you enable Service A's pods to be allowed.

Ensure Service A's pod also has the required label 'app: frontend'. Option A is wrong: a podSelector alone only matches pods in the same namespace. Option B is wrong: egress policies are not needed for inbound traffic.

Option C is too permissive and unnecessary.

Exam trap

A common pitfall is to assume that a podSelector in an ingress rule can match pods across namespaces without a namespaceSelector. In reality, a podSelector only matches pods in the same namespace unless combined with a namespaceSelector.

How to eliminate wrong answers

Option B is wrong because egress policies are not required for Service A to reach Service B unless the 'default' namespace has a NetworkPolicy that explicitly denies egress; the question states only ingress is denied by default, so no egress policy is needed. Option C is wrong because it suggests allowing all ingress traffic from any source, which would bypass the intended security restriction and is unnecessary; the existing policy already correctly restricts ingress to pods with the required label. Option D is wrong because namespaceSelector is used to select pods from entire namespaces, not to label the namespace itself; adding a label to the 'default' namespace does not affect the podSelector in the NetworkPolicy, which operates on pod labels, not namespace labels.

Practice this question →

34

MCQeasy

Refer to the exhibit. How many containers are defined in this Pod?

A.2

B.1

C.3

D.0

AnswerA

The YAML defines two containers.

Why this answer

The exhibit shows a Pod manifest with two container definitions under the `containers` field: one named `nginx` and one named `sidecar`. In Kubernetes, the number of containers in a Pod is determined by counting the entries in the `spec.containers` list, not including init containers or ephemeral containers unless explicitly specified. Therefore, the correct answer is 2.

Exam trap

The trap here is that candidates may miscount containers by including init containers or ephemeral containers, or mistakenly think the number of images referenced equals the number of containers, when the manifest explicitly lists only two containers in the `containers` array.

How to eliminate wrong answers

Option B is wrong because it assumes only one container is defined, but the manifest clearly lists two container entries under `spec.containers`. Option C is wrong because it suggests three containers, which would require a third entry in the `containers` list or additional init containers, neither of which is present. Option D is wrong because a Pod must have at least one container to be valid; the manifest explicitly defines two containers, so zero is incorrect.

Practice this question →

35

MCQhard

A Deployment manages 3 replicas of a pod. During a rolling update, one of the new pods enters CrashLoopBackOff. What happens next?

A.The Deployment deletes all pods and recreates them

B.The Deployment automatically reverts to the previous ReplicaSet

C.The Deployment continues the rollout, ignoring the failure

D.The Deployment pauses the rollout and waits for manual intervention

AnswerD

The Deployment controller will not proceed with the update if the new pod fails readiness checks.

Why this answer

By default, a Deployment's rolling update strategy has a `progressDeadlineSeconds` setting (default 600 seconds) and a `maxUnavailable`/`maxSurge` configuration. When a new pod enters CrashLoopBackOff, the Deployment's controller detects that the update is not making progress (the new ReplicaSet cannot reach the desired replica count with healthy pods). After the progress deadline expires, the Deployment marks the rollout as failed and pauses the update, requiring manual intervention (e.g., `kubectl rollout undo` or fixing the pod template).

This behavior is governed by the Deployment controller's reconciliation loop and the `Progressing` condition.

Exam trap

CNCF often tests the misconception that a Deployment automatically rolls back on failure, but in reality, it only pauses after a progress deadline, requiring manual rollback or correction.

How to eliminate wrong answers

Option A is wrong because a Deployment does not delete all pods and recreate them during a rolling update; it incrementally replaces pods by scaling up the new ReplicaSet and scaling down the old one, preserving overall availability. Option B is wrong because the Deployment does not automatically revert to the previous ReplicaSet; it only pauses the rollout after a progress deadline, and an explicit rollback (e.g., `kubectl rollout undo`) is required to revert. Option C is wrong because the Deployment does not ignore the failure; it respects the `progressDeadlineSeconds` and pauses the rollout when progress stalls, such as when a new pod is in CrashLoopBackOff.

Practice this question →

36

MCQmedium

A pod is stuck in 'Pending' state. You run 'kubectl describe pod mypod' and see the event '0/4 nodes are available: 4 Insufficient cpu'. What is the most likely cause?

A.The pod has exceeded its memory limit

B.The pod's image pull is failing

C.None of the nodes have enough CPU resources to satisfy the pod's request

D.The pod's liveness probe is failing

AnswerC

The event indicates insufficient CPU on all nodes.

Why this answer

The '0/4 nodes are available: 4 Insufficient cpu' event directly indicates that the Kubernetes scheduler attempted to place the pod on each of the four nodes but found that none had enough allocatable CPU capacity to satisfy the pod's CPU request (specified in the container's `resources.requests.cpu`). This causes the pod to remain in 'Pending' state because the scheduler cannot find a feasible node.

Exam trap

A common pitfall is confusing resource 'requests' (used for scheduling) with 'limits' (used for throttling/eviction). Candidates may mistakenly think 'Insufficient cpu' refers to CPU limits being exceeded, rather than the scheduler failing to find a node with enough free CPU to meet the request.

How to eliminate wrong answers

Option A is wrong because exceeding a memory limit causes a pod to be terminated (OOMKilled) or evicted, not stuck in 'Pending' state with an 'Insufficient cpu' event. Option B is wrong because image pull failures generate events like 'Failed to pull image' or 'ErrImagePull', not a node-level scheduling failure. Option D is wrong because liveness probe failures occur after the pod is already running (affecting the 'Running' state), not during scheduling when the pod is still 'Pending'.

Practice this question →

37

MCQhard

When using a Service of type ClusterIP, how do pods reach the service?

A.Via the service's cluster IP and port

B.Via the node's IP address and a high port

C.Via an external load balancer

D.Directly via the pod's IP address

AnswerA

Pods connect to the service's cluster IP and port, which kube-proxy forwards to healthy pods.

Why this answer

A Service of type ClusterIP exposes a stable virtual IP (the cluster IP) and port within the cluster. Pods reach the Service by sending traffic to this cluster IP and port, which is then load-balanced by kube-proxy (using iptables, IPVS, or eBPF rules) to one of the backing pod endpoints. This is the default and most fundamental Service type in Kubernetes.

Exam trap

CNCF often tests the misconception that ClusterIP Services are only reachable from within the same pod or node, when in fact they are reachable from any pod in the cluster (across nodes) via the cluster IP, thanks to kube-proxy's distributed routing rules.

How to eliminate wrong answers

Option B is wrong because reaching a Service via the node's IP address and a high port is the behavior of a NodePort Service, not ClusterIP. Option C is wrong because an external load balancer is used by a LoadBalancer Service, which is built on top of NodePort and ClusterIP, not by ClusterIP itself. Option D is wrong because pods do not reach the Service directly via a pod's IP address; that would bypass the Service abstraction and load balancing, and the Service's cluster IP is the intended stable endpoint.

Practice this question →

38

Multi-Selectmedium

Which THREE of the following are true about container lifecycle? (Choose 3)

Select 3 answers

A.A container can be paused and resumed

B.A container can be hibernated to save state to disk

C.A container goes through a 'built' phase before running

D.A container terminates when its main process exits

E.A container can be stopped and later restarted

AnswersA, D, E

Container runtimes support pausing and resuming containers using cgroups freezer.

Why this answer

A container lifecycle includes creation, running, pausing, and stopping. Containers can be started, stopped, and restarted. Containers do not have a 'built' phase; images are built separately.

Containers run processes; they are not designed to be hibernated.

Practice this question →

39

MCQhard

You are asked to deploy a Kubernetes service that exposes a set of pods internally within the cluster only. The service should not be accessible from outside the cluster. Which Service type should you choose?

A.ClusterIP

B.NodePort

C.ExternalName

D.LoadBalancer

AnswerA

ClusterIP provides internal-only access.

Why this answer

ClusterIP is the default Kubernetes Service type that exposes the service on a cluster-internal IP address. This makes the service reachable only from within the cluster, which is exactly what is required for internal-only communication between pods. No external traffic can reach a ClusterIP service unless an ingress controller or proxy is explicitly configured.

Exam trap

CNCF often tests the misconception that ClusterIP is only for inter-pod communication within the same namespace, but it actually works across all namespaces within the cluster, and the trap is that candidates confuse it with NodePort when they think 'internal only' means 'no external access' but forget that NodePort inherently opens external access.

How to eliminate wrong answers

Option B is wrong because NodePort exposes the service on a static port on each node's IP address, making it accessible from outside the cluster via <NodeIP>:<NodePort>. Option C is wrong because ExternalName maps a service to a DNS name (via CNAME records) and does not expose pods internally; it is used to provide an alias for an external service. Option D is wrong because LoadBalancer provisions an external load balancer (e.g., from a cloud provider) and assigns a public IP, making the service accessible from outside the cluster.

Practice this question →

40

MCQeasy

What is the primary purpose of the Open Container Initiative (OCI)?

A.To provide a container runtime called Docker

B.To create a container orchestration platform

C.To define the Kubernetes Container Runtime Interface (CRI)

D.To standardize container image and runtime specifications

AnswerD

OCI develops and maintains standards for container images (image spec) and runtimes (runtime spec) to promote compatibility across tools.

Why this answer

The Open Container Initiative (OCI) is an open governance structure that standardizes container image and runtime specifications. It ensures that any OCI-compliant image can run on any OCI-compliant runtime, promoting interoperability across the container ecosystem. This is the core purpose, not to provide a specific runtime or orchestration tool.

Exam trap

The CNCF exam often tests the distinction between a standard (OCI) and an implementation (Docker, containerd), so candidates mistakenly associate the OCI with Docker or Kubernetes rather than its role as a neutral specification body.

How to eliminate wrong answers

Option A is wrong because Docker is a specific container runtime and toolset, not the purpose of the OCI; the OCI standardizes specifications, not a particular implementation. Option B is wrong because container orchestration platforms like Kubernetes are separate projects; the OCI focuses on low-level image and runtime standards, not orchestration. Option C is wrong because the Kubernetes Container Runtime Interface (CRI) is a Kubernetes-specific plugin interface for runtimes, while the OCI defines the broader industry standard for container formats and runtimes.

Practice this question →

41

MCQhard

You need to run a stateful application that requires stable network identities and persistent storage per pod. Which Kubernetes resource is BEST suited?

A.DaemonSet

B.StatefulSet

C.Job

D.Deployment

AnswerB

StatefulSet provides stable pod identities and ordered deployment/ scaling, ideal for stateful workloads.

Why this answer

StatefulSet is the correct choice because it is specifically designed for stateful applications that require stable, unique network identifiers (e.g., pod names like `web-0`, `web-1`) and persistent storage that persists across pod rescheduling. Each pod in a StatefulSet gets a dedicated PersistentVolumeClaim, and the ordinal index ensures consistent identity, which is critical for databases like Cassandra or MySQL.

Exam trap

A common misconception is that Deployment can handle stateful workloads by using PersistentVolumeClaims, but Deployment pods lack stable identities and ordered startup/shutdown, which are essential for many stateful applications.

How to eliminate wrong answers

Option A is wrong because DaemonSet ensures one pod per node for cluster-wide services (e.g., logging agents), but it does not guarantee stable network identities or per-pod persistent storage. Option C is wrong because Job is intended for batch processing tasks that run to completion, not for long-running stateful applications requiring stable storage and identity. Option D is wrong because Deployment provides stateless, interchangeable pods with random names and shared or ephemeral storage, making it unsuitable for applications that require stable network identities and persistent storage per pod.

Practice this question →

42

Multi-Selectmedium

Which two of the following are characteristics of container images built using OCI standards? (Choose two.)

Select 2 answers

A.They are portable across different container runtimes

B.They are composed of layers that can be cached and reused

C.They include a full guest operating system

D.They can only be run by Docker

E.They require a hypervisor to run

AnswersA, B

OCI standards ensure portability.

Why this answer

OCI images are composed of layers (read-only) and are built from a Dockerfile. They are lightweight and portable across different runtimes. They do not include a guest OS (unlike VMs), and they are not tied to a specific runtime.

Practice this question →

43

MCQhard

A Kubernetes cluster has two nodes: control-plane and worker. The worker node runs several pods. The control-plane node becomes unreachable. What is the immediate impact on the pods running on the worker node?

A.All pods are immediately terminated

B.Pods continue running, but new pods cannot be scheduled

C.Pods are rescheduled to the control-plane node

D.The worker node is automatically cordoned

AnswerB

Existing pods keep running; scheduling requires the scheduler on the control plane.

Why this answer

When the control-plane node becomes unreachable, the kube-controller-manager cannot communicate with the kubelet on the worker node, so it stops performing scheduling and reconciliation. However, the kubelet on the worker node continues to run existing pods based on the last known desired state stored locally, and the pods themselves are managed by the container runtime (e.g., containerd) independently of the control-plane. Therefore, pods continue running normally, but no new pods can be scheduled because the scheduler, which runs on the control-plane, is unavailable.

Exam trap

The trap here is that candidates often assume the control-plane is required for all pod operations, confusing the control-plane's role in scheduling and reconciliation with the kubelet's independent ability to maintain running workloads, leading them to choose immediate termination or automatic rescheduling.

How to eliminate wrong answers

Option A is wrong because pods are not immediately terminated; the kubelet on the worker node continues to maintain running pods even without contact with the control-plane, as the pod lifecycle is managed locally. Option C is wrong because pods cannot be rescheduled to the control-plane node; the control-plane node is typically tainted (e.g., node-role.kubernetes.io/control-plane:NoSchedule) to prevent workload pods from running on it, and the scheduler is unavailable to make such decisions. Option D is wrong because the worker node is not automatically cordoned; cordoning is a manual or scheduler-driven action that marks a node as unschedulable, but the control-plane being unreachable does not trigger an automatic cordon of the worker node.

Practice this question →

44

MCQeasy

Which of the following is a key benefit of container orchestration?

A.Manual scaling of applications

B.Requires manual intervention for pod failures

C.Only supports monolithic applications

D.Automated scaling, self-healing, and declarative management

AnswerD

These are core benefits of orchestration.

Why this answer

Container orchestration platforms like Kubernetes provide automated scaling, self-healing, and declarative management.

Practice this question →

45

MCQeasy

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

A.Containers provide stronger isolation between applications

B.Containers include a full operating system per instance

C.Containers require a hypervisor to run

D.Containers are lightweight and share the host OS kernel

AnswerD

Containers do not include a guest OS, making them more lightweight and faster to start.

Why this answer

Containers are lightweight because they share the host OS kernel, avoiding the overhead of a separate guest OS per instance. Unlike VMs, which require a hypervisor and a full OS for each virtual machine, containers run as isolated processes on the same kernel, enabling faster startup times and higher density. This shared-kernel model is the primary benefit, as it reduces resource consumption and improves efficiency in orchestrated environments like Kubernetes.

Exam trap

The trap here is that candidates confuse 'isolation' with 'security' and assume containers are more secure because they are lightweight, but the primary benefit is resource efficiency, not stronger isolation—VMs actually provide better isolation via hardware virtualization.

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than virtual machines, as they share the host kernel and rely on namespaces and cgroups for process-level separation, whereas VMs use hardware-level virtualization with a hypervisor for stronger isolation. Option B is wrong because containers do not include a full operating system per instance; they package only the application and its dependencies, while the OS kernel is shared from the host. 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 (e.g., runc), whereas VMs require a hypervisor (e.g., KVM, VMware) to virtualize hardware.

Practice this question →

46

MCQeasy

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

A.Containers are slower to start than VMs

B.Containers require a hypervisor to run

C.Containers share the host OS kernel, whereas VMs each have their own guest OS

D.Containers virtualize hardware, while VMs virtualize the operating system

AnswerC

Correct. Containers share the host kernel; VMs have a full guest OS.

Why this answer

The primary difference is that containers share the host operating system kernel, while each virtual machine runs its own complete guest OS. This means containers are lightweight processes with isolated user spaces, whereas VMs include a full OS stack (kernel, drivers, libraries) per instance. This architectural distinction is why containers start in seconds and have minimal overhead, while VMs require booting a guest OS and consume more resources.

Exam trap

Commonly tested misconception: candidates often think containers are 'lightweight VMs' or that they virtualize hardware, when in fact containers share the host kernel and use OS-level virtualization, which is a fundamentally different isolation model.

How to eliminate wrong answers

Option A is wrong because containers are faster to start than VMs — containers start in milliseconds as they are just processes on the host kernel, whereas VMs require booting a full guest OS, which takes seconds to minutes. 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, while VMs require a hypervisor (Type 1 or Type 2) to virtualize hardware. Option D is wrong because it reverses the concepts: containers virtualize the operating system (via OS-level virtualization), while VMs virtualize hardware (via hypervisor and guest OS).

Practice this question →

47

Multi-Selectmedium

Which THREE are benefits of using a container orchestration platform? (Select 3)

Select 3 answers

A.Guarantees zero downtime during deployments

B.Declarative configuration management

C.Automated scaling based on demand

D.Eliminates the need for cloud infrastructure

E.High availability through automatic failover

AnswersB, C, E

Orchestration uses declarative configs (YAML) to define desired state.

Why this answer

Options B, C, and E are correct. Declarative configuration management (B) allows you to define the desired state and the platform ensures it. Automated scaling based on demand (C) adjusts resources automatically.

High availability through automatic failover (E) ensures minimal downtime. Option A is incorrect—orchestration does not guarantee zero downtime. Option D is incorrect—orchestration does not eliminate the need for infrastructure.

Practice this question →

48

Multi-Selecteasy

Which TWO are benefits of using a container orchestration platform like Kubernetes? (Select TWO.)

Select 2 answers

A.Increases application complexity

B.Requires a dedicated hypervisor for each container

C.Automatic service discovery and load balancing

D.Self-healing (automatic restart of failed containers)

E.Manual scaling of applications

AnswersC, D

Kubernetes automatically assigns IPs and a single DNS name for a set of pods and load-balances traffic.

Why this answer

Kubernetes includes built-in service discovery and load balancing. Services in Kubernetes get a stable virtual IP and DNS name, and kube-proxy implements load balancing across pods using iptables or IPVS rules, distributing traffic without manual configuration.

Exam trap

CNCF often tests the distinction between manual and automatic scaling; candidates may incorrectly select manual scaling as a benefit because they confuse it with the ability to scale, but the question asks for benefits of using the platform, which include automation, not manual effort.

Practice this question →

49

MCQeasy

Which of the following is a benefit of container orchestration?

A.Elimination of all security vulnerabilities

B.Self-healing of failed containers

C.Manual scaling of applications

D.Guaranteed zero downtime

AnswerB

Orchestration platforms like Kubernetes automatically restart failed containers.

Why this answer

Container orchestration platforms like Kubernetes provide self-healing capabilities by automatically restarting failed containers, rescheduling them on healthy nodes, and replacing or terminating containers that fail health checks. This ensures that the desired state of the application is maintained without manual intervention, which is a core benefit of orchestration.

Exam trap

CNCF often tests the misconception that orchestration provides absolute guarantees (like zero downtime or complete security), when in reality it provides mechanisms to improve reliability and security but cannot eliminate all risks.

How to eliminate wrong answers

Option A is wrong because container orchestration does not eliminate all security vulnerabilities; it can enforce security policies (e.g., Pod Security Standards, network policies) but cannot remove vulnerabilities in application code or container images. Option C is wrong because container orchestration enables automatic scaling (e.g., Horizontal Pod Autoscaler in Kubernetes), not manual scaling, which is a legacy approach. Option D is wrong because orchestration cannot guarantee zero downtime; it can minimize downtime through rolling updates and self-healing, but factors like node failures, misconfigurations, or resource exhaustion can still cause downtime.

Practice this question →

50

Multi-Selecthard

Which three of the following are benefits of container orchestration? (Choose three.)

Select 3 answers

A.High availability through replication

B.Scaling services up or down

C.Manual deployment of containers to specific hosts

D.Self-healing by restarting failed containers

E.Bare metal performance

AnswersA, B, D

Orchestration ensures replicas are distributed across nodes for availability.

Why this answer

Container orchestration provides high availability via replicas, scaling (both manual and autoscaling), and self-healing (restarting failed containers). Bare metal performance is not a direct benefit of orchestration; it is a characteristic of containers themselves. Manual deployment is the opposite of orchestration.

Practice this question →

51

Multi-Selecthard

Which THREE of the following are benefits of using container orchestration? (Choose three.)

Select 3 answers

A.High availability through automated failover

B.Decomposition of applications into microservices

C.Simplified networking with flat network topology

D.Self-healing by restarting failed containers

E.Automatic scaling of applications based on demand

AnswersA, D, E

Orchestration ensures applications remain available.

Why this answer

Container orchestration platforms like Kubernetes implement automated failover by monitoring container health via liveness probes and rescheduling pods on healthy nodes when a node fails. This ensures that applications remain available even when underlying infrastructure components fail, which is a core benefit of orchestration.

Exam trap

CNCF often tests the distinction between architectural patterns (like microservices) and operational benefits of orchestration, so candidates mistakenly select decomposition as a direct benefit when it is actually a design choice that orchestration supports.

Practice this question →

52

MCQmedium

Which component implements the Container Runtime Interface (CRI) to manage container lifecycle in Kubernetes?

A.kubelet

B.CRI-O

C.containerd

D.Docker

AnswerB, C

CRI-O is a lightweight container runtime specifically designed to implement the CRI, allowing Kubernetes to use any OCI-compliant runtime. It is a valid CRI implementation and is commonly used in Kubernetes clusters.

Why this answer

Both containerd and CRI-O are high-level container runtimes that implement the Container Runtime Interface (CRI) to manage the full lifecycle of containers (create, start, stop, delete) in Kubernetes. They communicate directly with the kubelet via the CRI protocol (gRPC) and handle image management, container execution, and resource isolation using low-level runtimes like runc. In contrast, the kubelet is the agent that calls the CRI but does not implement it itself, and Docker does not directly implement the CRI; it uses containerd internally and previously required the dockershim adapter.

Exam trap

The trap here is that candidates confuse the kubelet (which calls the CRI) with the actual CRI implementation, or they assume Docker itself implements CRI when in fact Docker uses containerd as its runtime and the dockershim was a separate adapter.

How to eliminate wrong answers

Option A is wrong because kubelet is the Kubernetes node agent that acts as the CRI client, not the CRI implementation; it calls the CRI to manage containers but does not itself implement the runtime interface. Option B is wrong because CRI-O is a lightweight CRI implementation, but it is not the component that implements CRI in the default Docker-based setup; CRI-O is an alternative runtime, not the one referenced in the question's correct answer. Option D is wrong because Docker itself does not implement the CRI directly; Docker Engine uses containerd as its underlying runtime, and the kubelet communicates with Docker through the dockershim (deprecated) or directly with containerd, not via Docker's own CRI implementation.

Practice this question →

53

MCQeasy

What is the purpose of a readiness probe in a Kubernetes pod?

A.To measure resource usage of the container

B.To restart the container when it becomes unresponsive

C.To determine if the container is ready to accept traffic

D.To check if the container is still running

AnswerC

Readiness probes control Service membership.

Why this answer

A readiness probe in Kubernetes determines whether a container within a pod is ready to start accepting traffic. If the probe fails, the pod is removed from the Service's endpoints, ensuring that only healthy containers receive requests. This is distinct from liveness probes, which restart containers, and startup probes, which delay other probes until initialization completes.

Exam trap

CNCF often tests the confusion between readiness and liveness probes, where candidates mistakenly think readiness probes restart containers (Option B) instead of controlling traffic admission.

How to eliminate wrong answers

Option A is wrong because resource usage measurement is handled by metrics-server or Prometheus, not by probes; readiness probes only check application readiness via HTTP, TCP, or command execution. Option B is wrong because restarting unresponsive containers is the job of a liveness probe, not a readiness probe; readiness probes only affect traffic routing. Option D is wrong because checking if a container is still running is the function of a liveness probe or the container runtime's process monitoring; readiness probes assume the container is running and instead verify its ability to serve requests.

Practice this question →

54

MCQeasy

Based on the exhibit, why is the pod web-pod not running?

A.A network policy is blocking the image pull.

B.The container image is not available in the registry.

C.The node does not have enough memory.

D.The pod was not scheduled onto a node.

AnswerB

The error 'image not found' confirms the image is missing.

Why this answer

The pod's status indicates an ImagePullBackOff error, which occurs when the kubelet fails to pull the specified container image from the registry. This typically means the image name or tag is incorrect, the registry is unreachable, or the image does not exist in the registry. The exhibit shows the pod is stuck in a waiting state with the reason 'ErrImagePull' or 'ImagePullBackOff', directly pointing to a missing or inaccessible image.

Exam trap

The KCNA exam often tests the distinction between pod scheduling failures (e.g., resource constraints, taints/tolerations) and container runtime failures (e.g., image pull errors), so candidates may confuse a 'Pending' pod with an 'ImagePullBackOff' pod, both of which are not running but have different root causes.

How to eliminate wrong answers

Option A is wrong because network policies in Kubernetes control traffic between pods, not image pull operations; image pulls are handled by the container runtime (e.g., containerd, CRI-O) and are subject to registry authentication and network connectivity, not NetworkPolicy objects. Option C is wrong because a memory shortage on the node would manifest as an OOMKilled or Pod eviction, not an ImagePullBackOff error; the exhibit shows no resource pressure events. Option D is wrong because the pod has been scheduled onto a node (as indicated by the pod status showing a node name), but the container fails to start due to the image pull issue; unscheduled pods would show a 'Pending' status with no node assigned.

Practice this question →

55

MCQeasy

What is the purpose of a readiness probe in a Kubernetes pod?

A.To determine if the pod should be terminated

B.To check if the pod is alive and restart it if not

C.To measure CPU usage of the container

D.To signal that the pod is ready to accept traffic

AnswerD

Correct. Readiness probe controls whether the pod receives traffic.

Why this answer

A readiness probe in Kubernetes determines whether a container inside a pod is ready to start accepting traffic. If the probe fails, the pod is removed from the Service's endpoints, ensuring that only healthy pods receive requests. This is distinct from liveness probes, which check if the container is alive and should be restarted.

Exam trap

The trap here is that candidates often confuse readiness probes with liveness probes, mistakenly thinking both are used for restarting unhealthy containers, when in fact readiness probes only control traffic routing and do not trigger restarts.

How to eliminate wrong answers

Option A is wrong because readiness probes do not determine pod termination; that is the role of the liveness probe or the pod's terminationGracePeriodSeconds. Option B is wrong because checking if the pod is alive and restarting it is the purpose of a liveness probe, not a readiness probe. Option C is wrong because measuring CPU usage is done via metrics servers or resource monitoring tools like Prometheus, not through probes.

Practice this question →

56

MCQmedium

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

A.The pod's liveness probe failed

B.The pod's readiness probe failed

C.Insufficient cluster resources (CPU/memory) to schedule the pod

D.The container image is missing

AnswerC

If no node has enough resources, the pod stays Pending.

Why this answer

A pod stuck in 'Pending' state indicates that the pod has not been scheduled to a node. The most common cause is insufficient cluster resources (CPU/memory), as the Kubernetes scheduler cannot find a node that meets the pod's resource requests. This is a scheduling failure, not a runtime issue.

Exam trap

CNCF often tests the distinction between scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly associate image or probe issues with the Pending state.

How to eliminate wrong answers

Option A is wrong because a liveness probe failure occurs after the pod is running, causing restarts, not a 'Pending' state. Option B is wrong because a readiness probe failure affects service traffic routing, not scheduling; the pod would be running but not ready. Option D is wrong because a missing container image results in an 'ImagePullBackOff' or 'ErrImagePull' state, not 'Pending'; the pod is scheduled but fails to start.

Practice this question →

57

MCQmedium

Which Kubernetes resource should be used to run a one-time task that performs a computation and then exits?

A.DaemonSet

B.StatefulSet

C.Job

D.Deployment

AnswerC

Job is designed for batch processing.

Why this answer

A Kubernetes Job is designed specifically for finite, one-time tasks that run to completion and then exit. Unlike controllers that maintain a desired number of continuously running Pods, a Job creates one or more Pods and tracks their successful termination, making it the correct choice for a computation that should run once and stop.

Exam trap

The trap here is that candidates confuse a Job with a Deployment because both can run containers, but a Deployment is designed for long-running services, not for tasks that should terminate after completion.

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, intended for long-running background services like log collectors or monitoring agents, not for one-time tasks. Option B is wrong because a StatefulSet manages stateful applications with stable, unique network identities and persistent storage, designed for workloads like databases that require ordered deployment and scaling, not ephemeral computations. Option D is wrong because a Deployment manages a ReplicaSet to maintain a desired number of continuously running Pods, supporting rolling updates and self-healing, which is unnecessary overhead for a task that should exit after completion.

Practice this question →

58

Multi-Selectmedium

Which TWO of the following are characteristics of immutable infrastructure? (Select two.)

Select 2 answers

A.Servers are never modified after they are deployed

B.Containers are used exclusively

C.Infrastructure is version-controlled and tested

D.New versions are deployed by replacing the entire server with a new image

E.Configuration updates are applied directly to running servers

AnswersA, D

Immutable infrastructure treats servers as disposable; any change requires redeployment.

Why this answer

Immutable infrastructure means that once a server or container is deployed, it is never modified in place. If a change is needed, a new image is built and deployed, and the old instance is destroyed. This ensures consistency and eliminates configuration drift, which is a core principle of immutable deployments in Kubernetes and cloud-native environments.

Exam trap

Immutable infrastructure is not defined by whether containers are used, but by the principle that infrastructure is never modified after deployment. This is a key concept in cloud-native and Kubernetes environments.

Practice this question →

59

MCQmedium

A developer wants to deploy a stateless web application that should scale to 5 replicas. Each replica must be identical and should be automatically replaced if it fails. Which Kubernetes resource should be used?

A.StatefulSet

B.DaemonSet

C.Deployment

D.ReplicationController

AnswerC

Deployment manages ReplicaSets and provides declarative updates and self-healing.

Why this answer

A Deployment is the correct resource because it manages a ReplicaSet to ensure the desired number of identical, stateless pod replicas (5) are running. It provides declarative updates, self-healing (automatic replacement of failed pods), and scaling capabilities, which directly match the requirement for a stateless web application.

Exam trap

The trap here is that candidates often confuse StatefulSet with Deployment for stateless apps because both can manage multiple replicas, but StatefulSet is specifically for stateful workloads requiring ordered deployment and stable identities, not for identical, interchangeable replicas.

How to eliminate wrong answers

Option A is wrong because StatefulSet is designed for stateful applications that require stable, unique network identities and persistent storage, not for stateless web apps where replicas are identical and can be replaced arbitrarily. Option B is wrong because DaemonSet ensures that a copy of a pod runs on every (or selected) node in the cluster, which is used for cluster-level services like logging or monitoring, not for scaling a stateless web app to a specific replica count. Option D is wrong because ReplicationController is the older, deprecated predecessor of Deployment; it can maintain a desired number of pod replicas but lacks advanced features like rolling updates, declarative management, and is not the recommended resource for modern Kubernetes deployments.

Practice this question →

60

MCQeasy

Which Kubernetes resource is used to run a batch job that runs to completion?

A.DaemonSet

B.StatefulSet

C.Job

D.Deployment

AnswerC

Jobs manage pods that run until completion.

Why this answer

A Kubernetes Job is specifically designed to run a finite task to completion, creating one or more Pods and ensuring they successfully terminate. Unlike controllers that maintain a desired state of running Pods, a Job tracks the number of successful completions and stops when the specified parallelism or completions count is reached.

Exam trap

The trap here is that candidates confuse a Job with a Deployment because both can run Pods, but a Deployment is designed for long-running services with continuous availability, while a Job is the only controller that tracks and terminates upon successful completion.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, intended for long-running services like log collectors or monitoring agents, not for batch jobs that run to completion. Option B is wrong because a StatefulSet manages stateful applications with unique network identities and persistent storage, designed for workloads like databases that require stable identities and ordered deployment, not for ephemeral batch tasks. Option D is wrong because a Deployment manages ReplicaSets to provide declarative updates for stateless applications that should run continuously, ensuring a specified number of replicas are always running, which is the opposite of a job that terminates upon completion.

Practice this question →

61

MCQmedium

A DevOps engineer wants to deploy a stateful application that requires stable network identities and persistent storage. Which Kubernetes resource is most appropriate?

A.DaemonSet

B.StatefulSet

C.Deployment

D.ReplicaSet

AnswerB

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 persist across Pod rescheduling). Unlike Deployments, StatefulSet guarantees ordered, graceful deployment and scaling, which is essential for applications like databases or distributed systems that rely on stable identities.

Exam trap

The trap here is that candidates confuse StatefulSet with Deployment, assuming Deployments can handle stateful workloads by adding persistent volumes, but they overlook the critical need for stable network identities and ordered Pod management that only StatefulSet provides.

How to eliminate wrong answers

Option A (DaemonSet) is wrong because it ensures one Pod per Node for daemon-like workloads (e.g., logging agents, monitoring) and does not provide stable network identities or per-Pod persistent storage. Option C (Deployment) is wrong because it is designed for stateless applications; Pods are interchangeable and get random hostnames, and PersistentVolumeClaims are shared or recreated, breaking identity and storage persistence. Option D (ReplicaSet) is wrong because it is a lower-level resource that only maintains a desired replica count without any guarantees for stable identities, ordered operations, or persistent storage binding.

Practice this question →

62

Multi-Selecthard

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

Select 3 answers

A.OCI is governed solely by Docker Inc.

B.OCI only applies to Linux containers

C.OCI defines the container image format specification

D.OCI standards are vendor-neutral

E.OCI defines a standard for container runtime execution

AnswersC, D, E

OCI image spec defines the format.

Why this answer

The Open Container Initiative (OCI) defines the Image Specification, which standardizes the format and content of container images. This ensures that any OCI-compliant image can be run by any OCI-compliant runtime, enabling interoperability across different container platforms.

Exam trap

CNCF often tests the misconception that OCI is Docker-specific or Linux-only, when in fact it is a vendor-neutral, cross-platform standard governed by the Linux Foundation.

Practice this question →

63

Multi-Selectmedium

Which TWO of the following are benefits of using a container orchestration platform like Kubernetes? (Choose two.)

Select 2 answers

A.Inability to manage container networking

B.Requirement to run applications on a single node

C.Self-healing by restarting failed containers

D.Manual rollback of application versions

E.Automated scaling of applications based on demand

AnswersC, E

Kubernetes restarts failed pods automatically.

Why this answer

Orchestration provides automated scaling and self-healing. Manual scaling and single-node deployment are not benefits.

Practice this question →

64

Multi-Selectmedium

Which TWO of the following are required fields when defining a container in a Kubernetes Pod spec? (Choose 2)

Select 2 answers

A.env

B.image

C.name

D.resources

E.ports

AnswersB, C

The 'image' field specifies the container image to run and is required.

Why this answer

In a Kubernetes Pod spec, the `name` and `image` fields are mandatory for each container definition. The `name` field uniquely identifies the container within the Pod, and the `image` field specifies the container image to run (e.g., `nginx:1.25`). Without these two fields, the Pod creation will fail with a validation error from the Kubernetes API server.

Exam trap

CNCF often tests the misconception that `ports` or `resources` are required because they appear in most example Pod specs, but the KCNA exam expects you to know that only `name` and `image` are mandatory per the Kubernetes API specification.

Practice this question →

65

MCQeasy

Which of the following is a key principle of microservices architecture?

A.Shared database schema for all services

B.Tight coupling between services

C.Loose coupling and independent deployability

D.Building a large, monolithic codebase

AnswerC

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

Why this answer

Microservices architecture emphasizes breaking an application into small, independently deployable services that communicate over well-defined APIs. The correct answer is C: Loose coupling and independent deployability are key principles. Option A (shared database) contradicts the principle of service autonomy.

Option B (tight coupling) is the opposite of what microservices aim for. Option D (monolithic codebase) is what microservices avoid.

Practice this question →

66

Multi-Selecthard

Which THREE are valid ways to perform a rolling update of a Deployment in Kubernetes? (Select THREE.)

Select 3 answers

A.Manually delete all pods and let the Deployment recreate them

B.Change the number of replicas

C.Update the container image to a new version

D.Modify the environment variables in the pod spec

E.Edit the deployment's labels

AnswersC, D, E

Changing the image in the Deployment spec triggers a rolling update.

Why this answer

Changing the container image in a Deployment's pod template triggers a rolling update. Kubernetes compares the current pod template hash with the desired one; when they differ, it creates new ReplicaSets with the updated image and gradually scales down the old ReplicaSet while scaling up the new one, ensuring zero-downtime updates.

Exam trap

KCNA often tests the misconception that only image changes trigger rolling updates, but any modification to the pod template (including environment variables and labels) does so, while scaling replicas or deleting pods does not.

Practice this question →

67

MCQmedium

A pod is stuck in the 'Pending' state. You run 'kubectl describe pod mypod' and see the event: '0/3 nodes are available: 1 node had taint that the pod didn't tolerate, 2 Insufficient cpu.' What is the most likely cause?

A.The pod's liveness probe is failing

B.The pod's resource requests exceed available node capacity and a node taint is not tolerated

C.The pod's container runtime is not installed

D.The pod's image pull secret is missing

AnswerB

The events indicate insufficient CPU and an untolerated taint, preventing scheduling.

Why this answer

The pod is in 'Pending' state because the scheduler cannot find a node that meets its requirements. The event '0/3 nodes are available: 1 node had taint that the pod didn't tolerate, 2 Insufficient cpu' directly indicates that the pod's resource requests exceed the available CPU on two nodes, and the remaining node has a taint that the pod does not tolerate. This matches option B: the pod's resource requests exceed available node capacity and a node taint is not tolerated.

Exam trap

The trap here is that candidates may confuse 'Pending' state with post-scheduling issues like probe failures or image pull errors, but the event message explicitly points to scheduling failures (resource insufficiency and taint intolerance), which are the only reasons a pod remains unscheduled.

How to eliminate wrong answers

Option A is wrong because a failing liveness probe would cause the pod to be restarted or marked as 'CrashLoopBackOff', not stuck in 'Pending' — liveness probes only run after the pod is scheduled and started. Option C is wrong because if the container runtime were not installed, the kubelet would report a 'ContainerRuntimeNotReady' condition, and the pod would not even be considered for scheduling; the scheduler would not produce 'Insufficient cpu' events. Option D is wrong because a missing image pull secret would cause an 'ImagePullBackOff' or 'ErrImagePull' error after the pod is scheduled, not a 'Pending' state with resource-related scheduling failures.

Practice this question →

68

Multi-Selectmedium

Which TWO statements about containers are true compared to virtual machines? (Select TWO.)

Select 2 answers

A.Containers are more lightweight and start faster than VMs

B.Containers include a full guest operating system

C.Containers are more portable across different environments

D.Containers provide stronger isolation than VMs

E.Containers require a hypervisor to run

AnswersA, C

Because they share the host kernel and do not need to boot an OS, containers are lightweight and start quickly.

Why this answer

Containers share the host OS kernel and run as isolated processes, requiring no hypervisor or full OS boot. This makes them lightweight (megabytes vs gigabytes) and allows them to start in milliseconds, whereas VMs must boot a full guest OS, which takes seconds to minutes.

Exam trap

A common pitfall in CNCF exams is believing containers provide stronger isolation than VMs, but VMs offer hardware-level isolation via a hypervisor, while containers rely on kernel-level isolation which is inherently weaker.

Practice this question →

69

Drag & Dropmedium

Drag and drop the steps to update a Kubernetes Secret and ensure Pods use the new value into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Update the Secret, verify, force Pod recreation if needed, wait for new Pods, and verify the new value.

Practice this question →

70

MCQmedium

Which command would you run to get a list of all pods in all namespaces?

A.kubectl get pods --namespace=*

B.kubectl get pods --global

C.kubectl get pods --all-namespaces

D.kubectl get pods --include-uninitialized

AnswerC

This lists pods in all namespaces.

Why this answer

`kubectl get pods --all-namespaces` (or its shorthand `-A`) retrieves pods from every namespace in the cluster. This flag overrides the default behavior of `kubectl get pods`, which only returns pods in the current namespace (usually `default`).

Exam trap

CNCF often tests the misconception that a wildcard or global flag exists for namespace selection, leading candidates to choose `--namespace=*` or `--global` instead of the correct `--all-namespaces` flag.

How to eliminate wrong answers

Option A is wrong because `--namespace=*` is not a valid kubectl syntax; the asterisk wildcard is not supported for namespace selection, and kubectl will return an error. Option B is wrong because `--global` is not a valid kubectl flag; it does not exist and would cause a parsing error. Option D is wrong because `--include-uninitialized` is a deprecated flag that was used in older Kubernetes versions to include pods that had not yet been fully initialized, but it does not affect namespace scope and is no longer supported in recent releases.

Practice this question →

71

Multi-Selecthard

Which THREE of the following are key characteristics of microservices architecture?

Select 3 answers

A.Independent deployment of services

B.Decomposition by business capability

C.Single monolithic codebase

D.Shared database schema across services

E.Loose coupling between services

AnswersA, B, E

Each microservice can be deployed independently.

Why this answer

Microservices architecture mandates that each service can be independently deployed, updated, and scaled without affecting other services. This is achieved through separate deployment pipelines, containerization (e.g., Docker), and orchestration platforms like Kubernetes that manage service lifecycles independently. Independent deployment enables continuous delivery and reduces the blast radius of changes.

Exam trap

A common misconception is that microservices can share a single database or persistent volume in Kubernetes for simplicity. However, each service should own its data to maintain loose coupling and independent deployability within a Kubernetes cluster.

Practice this question →

72

MCQhard

You need to deploy an application that requires exactly one pod per cluster node for logging purposes. Which Kubernetes workload resource should you use?

A.DaemonSet

B.Job

C.StatefulSet

D.Deployment

AnswerA

DaemonSet runs a pod on each node.

Why this answer

A DaemonSet ensures that a copy of a pod runs on every node in the cluster, or on a subset of nodes if a node selector is used. This is the correct resource for deploying a logging agent that must be present on each node to collect logs from that node's containers and system components.

Exam trap

The trap here is that candidates often confuse DaemonSet with Deployment, assuming a Deployment with replicas equal to the node count will achieve the same effect, but Deployments do not guarantee one pod per node and can schedule multiple pods on the same node or leave nodes empty.

How to eliminate wrong answers

Option B (Job) is wrong because a Job creates one or more pods that run to completion and then stop, which is unsuitable for a continuously running logging daemon that must persist on every node. Option C (StatefulSet) is wrong because StatefulSet is designed for stateful applications that require stable, unique network identities and persistent storage, not for ensuring one pod per node. Option D (Deployment) is wrong because a Deployment manages replicas across the cluster without guaranteeing that a pod runs on every node; it uses a scheduler to distribute pods based on resource availability, not node coverage.

Practice this question →

73

MCQmedium

You need to ensure that a set of pods in a Deployment can be reached by other pods using a stable IP address and DNS name. Which Kubernetes object should you use?

A.Service

B.NetworkPolicy

C.Ingress

D.ConfigMap

AnswerA

A Service provides a stable IP and DNS name for a set of pods.

Why this answer

A Service provides a stable IP address and DNS name for a set of pods, abstracting the underlying pod IPs that can change due to scaling or failures. By default, a Service uses a cluster-internal virtual IP and DNS record (e.g., <service-name>.<namespace>.svc.cluster.local) that other pods can resolve, ensuring reliable connectivity without needing to track individual pod IPs.

Exam trap

The trap here is that candidates confuse Ingress (external HTTP routing) with internal service discovery, or think NetworkPolicy provides addressing, when only a Service offers a stable virtual IP and DNS name for pod-to-pod communication.

How to eliminate wrong answers

Option B (NetworkPolicy) is wrong because it defines firewall rules for pod-to-pod traffic, not a stable IP or DNS name. Option C (Ingress) is wrong because it manages external HTTP/HTTPS traffic routing to Services, not internal pod-to-pod communication with a stable IP. Option D (ConfigMap) is wrong because it stores configuration data as key-value pairs, not network endpoints.

Practice this question →

74

MCQmedium

What is the role of etcd in a Kubernetes cluster?

A.It serves as the container runtime

B.It stores cluster state and configuration

C.It provides DNS-based service discovery

D.It schedules pods onto nodes

AnswerB

etcd is the cluster's backing store.

Why this answer

etcd is a distributed, consistent key-value store that serves as Kubernetes' primary datastore for all cluster state and configuration data. It stores objects like pods, services, deployments, secrets, and configmaps, and is the source of truth for the entire cluster. The Kubernetes API server is the only component that communicates directly with etcd, ensuring strong consistency via the Raft consensus protocol.

Exam trap

The trap here is that candidates often confuse etcd with the container runtime or the scheduler because all three are essential components, but only etcd is the persistent, consistent store for cluster state, not a runtime or decision-making component.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O, or Docker) is responsible for pulling images and running containers, not etcd. Option C is wrong because DNS-based service discovery in Kubernetes is provided by CoreDNS (or kube-dns), which resolves service names to cluster IPs, not by etcd. Option D is wrong because pod scheduling onto nodes is performed by the kube-scheduler, which reads node and pod data from etcd via the API server but does not directly interact with etcd.

Practice this question →

75

Drag & Dropmedium

Drag and drop the steps for a rolling update of a Kubernetes Deployment into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Change the image, apply, monitor rollout, verify health, and rollback if issues arise.

Practice this question →

Page 1 of 3 · 173 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Container Orchestration questions.

Start 20-question session