CCNA Kcna Container Orchestration Questions — Page 1 of 3

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 provides automated scaling, self-healing, and declarative management, which are not available when running containers manually.

Practice this question →

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 →

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 →

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

Option C is correct because 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 →

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 →

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

The correct command to expose a service with a LoadBalancer type is 'kubectl expose service my-svc --type=LoadBalancer --name=my-svc-lb'. Option A incorrectly uses 'deployment' instead of 'service'; Option B is correct; Option C doesn't specify the type, defaulting to ClusterIP; Option D uses '--port' as a flag but missing '--type' and uses incorrect syntax.

Practice this question →

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 →

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 →

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

Option A is correct because 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 →

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 →

MCQmedium

A developer wants to run a container image locally for testing before deploying to a Kubernetes cluster. Which tool is most appropriate for this task?

A.Ansible

B.Docker

C.Kubernetes

D.Terraform

AnswerB

Docker allows developers to run containers locally with a simple command, suitable for testing.

Why this answer

Docker is a widely used tool for building and running containers locally. While Kubernetes can run containers, it is overkill for local testing of a single container.

Practice this question →

MCQmedium

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

A.Increase the 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 →

Multi-Selectmedium

Which TWO of the following are benefits of container orchestration?

Select 2 answers

A.Ability to run containers without a kernel

B.Manual scaling of containers

C.High availability through self-healing

D.Automated scaling based on demand

E.Simplified network configuration for each container

AnswersC, D

Orchestrators automatically restart failed containers.

Why this answer

Container orchestration provides high availability (self-healing, automated restarts) and scaling (automatically adjusting replicas based on load).

Practice this question →

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 →

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

Cisco 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 →

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 →

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 →

MCQmedium

A pod is in the 'CrashLoopBackOff' state. You run 'kubectl logs mypod' and see an error related to missing environment variables. The pod is part of a Deployment. What is the best way to fix this without recreating the entire Deployment?

A.Use kubectl set env to add the environment variables to the pod

B.Delete the pod and rely on the Deployment to recreate it

C.Update the Deployment's pod template to include the missing environment variables

D.Edit the pod directly using kubectl edit pod mypod

AnswerC

Updating the Deployment's spec triggers a rolling update, creating new pods with the correct environment.

Why this answer

You can update the Deployment's pod template to include the missing environment variables, then perform a rolling update.

Practice this question →

Multi-Selectmedium

Which two of the following are container runtimes that implement the Container Runtime Interface (CRI)? (Choose two.)

Select 2 answers

A.Docker

B.containerd

C.Podman

D.CRI-O

E.runc

AnswersB, D

containerd implements CRI and is a common runtime.

Why this answer

containerd and CRI-O are CRI-compliant container runtimes. Docker is not directly CRI-compatible (uses dockershim, deprecated). runc is a low-level runtime that is used by containerd and CRI-O but is not itself a CRI implementation.

Practice this question →

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

Option C is correct because 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 →

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

High availability and self-healing are key benefits. Manual deployment and static scaling are not benefits of orchestration.

Practice this question →

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

Readiness probes determine whether a container is ready to accept traffic. If the probe fails, the pod is removed from the Service's endpoints. Liveness probes determine if the container is healthy and should be restarted.

Startup probes check if the application has started successfully.

Practice this question →

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 →

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

RollingUpdate with maxSurge=1 and maxUnavailable=0 ensures one pod is updated at a time and the update pauses if the new pod is not healthy.

Practice this question →

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 Job with a specified number of completions and parallelism can run pods to completion, handling failures by restarting or marking as failed.

Practice this question →

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

Option A is correct. Immutable infrastructure means replacing a failed or outdated container with a new one built from a fresh image, rather than patching in place. Option B is mutable (updating in place).

Option C is mutable (SSH for debugging). Option D is mutable (updating packages via exec).

Practice this question →

MCQmedium

You have a Deployment running 3 replicas. You need to update the container image without downtime. Which command updates the image while performing a rolling update?

A.kubectl replace deployment my-deployment --image=nginx:1.25

B.kubectl set image deployment/my-deployment nginx=nginx:1.25

C.kubectl scale deployment my-deployment --image=nginx:1.25

D.kubectl update deployment my-deployment --image=nginx:1.25

AnswerB

This command updates the container image and triggers a rolling update.

Why this answer

The 'kubectl set image' command updates the container image in the Deployment, triggering a rolling update by default.

Practice this question →

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 →

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 →

MCQeasy

Which component in Kubernetes is responsible for managing the lifecycle of pods and ensuring the desired number of replicas are running?

A.Kube-proxy

B.Kubelet

C.Controller Manager

D.ReplicaSet

AnswerD

ReplicaSet ensures a stable set of replica pods running at any given time.

Why this answer

The ReplicaSet is the controller that ensures the specified number of pod replicas are running at any given time.

Practice this question →

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

Option A is correct. In Kubernetes RBAC, permissions are additive. The Role grants get, list, watch on pods.

Listing pods requires 'list' permission, which is granted. Option B is incorrect because there is no deny rule; RBAC is deny by default, but the RoleBinding grants the permission. Option C is incorrect because the ServiceAccount is bound to a Role, which is for a single namespace.

Option D is incorrect; pod listing does not require a ClusterRole.

Practice this question →

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

An empty endpoints list indicates that the service's label selector does not match any pods, or the pods are not ready.

Practice this question →

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

Cisco 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 →

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

Option B is correct because 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 →

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 →

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 →

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

Option B is correct because 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 →

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 →

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

AnswerA

The NetworkPolicy uses podSelector to match pods with label 'app: frontend'. Service A's pod must have this label to be allowed ingress into the backend namespace.

Why this answer

Option A is correct because NetworkPolicies use pod selectors to determine which pods are allowed to send or receive traffic. By default, a NetworkPolicy that allows ingress from pods with label 'app: frontend' will only match pods in the same namespace unless a namespaceSelector is also specified. Since Service A is in a different namespace, the only way to match the ingress rule is to ensure Service A's pod carries the label 'app: frontend'.

This satisfies the podSelector in the NetworkPolicy, allowing traffic from that specific pod to Service B.

Exam trap

CNCF often tests the misconception that NetworkPolicy podSelectors automatically apply across namespaces, when in fact they are namespace-scoped 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 →

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 →

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

Option D is correct because, 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 →

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 scheduler cannot place the pod because no node has enough available CPU to meet the pod's request.

Practice this question →

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 →

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 →

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 →

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

Option A is correct. The OCI aims to standardize container formats and runtimes to ensure interoperability. Option B is incorrect as OCI does not define Kubernetes APIs.

Option C is incorrect because Docker is not an OCI specification. Option D is incorrect because OCI focuses on standards, not a specific product.

Practice this question →

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

Option A is correct. StatefulSet is designed for stateful applications that need stable, unique network identities and persistent storage. Option B (Deployment) is for stateless apps.

Option C (DaemonSet) runs on each node. Option D (Job) is for batch work.

Practice this question →

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 →

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 →

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 →

MCQeasy

What is the primary purpose of a container orchestration platform like Kubernetes?

A.To provide a lightweight runtime for running a single container

B.To automate the deployment, scaling, and management of containerized applications

C.To manage virtual machines and their hypervisors

D.To compile source code into container images

AnswerB

Orchestration platforms handle lifecycle management, scaling, and self-healing of containers across clusters.

Why this answer

Container orchestration platforms automate the deployment, scaling, and management of containerized applications. Option B captures the core purpose: automating deployment, scaling, and management. Option A describes a single container runtime feature.

Option C describes a configuration management tool like Ansible. Option D describes a CI/CD tool.

Practice this question →

Multi-Selectmedium

Which THREE of the following are key benefits of container orchestration? (Choose 3)

Select 3 answers

A.Built-in network isolation between all containers

B.Declarative management using desired state configuration

C.High availability through replication and load balancing

D.Automatic code compilation from source repositories

E.Self-healing capabilities that restart failed containers

AnswersB, C, E

Users define the desired state, and the orchestrator works to achieve and maintain it.

Why this answer

Container orchestration platforms like Kubernetes provide high availability through replication, self-healing by restarting failed containers, and declarative management via desired state configuration. Network isolation is typically provided by network policies but is not a core orchestration benefit.

Practice this question →

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 →

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

Containers share the host OS kernel and run as isolated processes, while VMs include a full guest OS and run on hypervisor-managed virtual hardware.

Practice this question →

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 A, B, and E are correct. Orchestration provides high availability (A), automated scaling (B), and declarative management (E). Option C is incorrect—containers are portable across environments, not tied to a specific cloud.

Option D is incorrect—orchestration abstracts infrastructure, but containers still run on servers.

Practice this question →

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

Option C is correct because 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 →

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 →

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 →

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

Option A is correct because 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 →

MCQmedium

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

A.kubelet

B.CRI-O

C.containerd

D.Docker

AnswerC

containerd is a CRI-compliant container runtime.

Why this answer

containerd is a CRI-compliant runtime that manages containers, while kubelet interacts with it via CRI.

Practice this question →

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 →

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

Option B is correct because 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

Cisco 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 →

MCQmedium

A container image built using a Dockerfile with multiple layers is stored in a registry. When a node pulls this image, which statement about layers is true?

A.Layers that are already cached on the node are reused and only new layers are downloaded

B.Layers are merged into a single layer before download

C.All layers must be downloaded each time the image is pulled

D.Only the topmost layer is downloaded; lower layers are streamed from the registry

AnswerA

This is the core benefit of image layering — efficient caching and reuse.

Why this answer

Container images are composed of layers. If a node already has some layers cached from previous pulls, only the missing layers are downloaded. This saves bandwidth and time.

Practice this question →

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

Readiness probe determines if a pod is ready to serve traffic. If it fails, the pod is removed from Service endpoints.

Practice this question →

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

Pending usually means the scheduler cannot find a node that meets the pod's resource requests or other constraints.

Practice this question →

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 →

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 components are replaced rather than changed in place. Option A (servers are never modified after deployment) and Option D (changes are made by redeploying with a new image) are correct. Option B describes mutable infrastructure; Option C is not a characteristic; Option E is about containers in general but not specifically immutable infrastructure.

Practice this question →

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 →

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

Jobs are designed for batch processing and run pods until successful completion.

Practice this question →

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

A StatefulSet is designed for stateful applications that require stable, unique network identifiers and persistent storage.

Practice this question →

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

Option C is correct because 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 →

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 →

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 →

Multi-Selecthard

Which TWO are characteristics of the microservices architecture that are supported by container orchestration?

Select 2 answers

A.Tight coupling between services to ensure performance

B.Independent deployment of each service

C.Decomposition of an application into small, independent services

D.Monolithic codebase with centralized deployment

E.Use of a single, shared database for all services

AnswersB, C

Each microservice can be deployed, updated, and scaled independently without affecting others.

Why this answer

Options A and D are correct. Microservices decompose an application into loosely coupled services (A) that can be deployed independently (D). Option B is false — microservices should be loose coupling.

Option C is false — microservices favor decentralized data management. Option E is false — microservices are typically small, not monolithic.

Practice this question →

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 decomposition of an application into small, independently deployable services that communicate over well-defined APIs. Option B is correct. Option A describes a monolith; Option C is not a principle; Option D refers to containerization.

Practice this question →