Courseiva

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 226–300

833 questions total · 12pages · All types, answers revealed

Take a mock examExam hub
Page 3

Page 4 of 12

Page 5
226
MCQhard

An application deployed on Kubernetes is experiencing intermittent failures due to network latency. Which resiliency pattern should be implemented to gracefully handle such failures?

A.Circuit breaker
B.Bulkhead
C.Retry
D.Timeout
AnswerC

Retry pattern handles transient failures by reattempting the operation after a delay.

Why this answer

Retry pattern automatically retries failed operations, which is appropriate for transient failures like network latency. Circuit breaker prevents repeated calls to a failing service. Timeout sets a maximum wait.

Bulkhead isolates resources.

Full explanation →
227
Multi-Selecthard

Which TWO of the following are valid components of the Alertmanager configuration? (Select two.)

Select 2 answers
A.group_by
B.prometheus_rules
C.route
D.alert
E.receivers
AnswersC, E

Route defines alert routing tree in Alertmanager.

Why this answer

Alertmanager configuration includes 'route' for routing alerts and 'receivers' for notification channels. 'prometheus_rules' is part of Prometheus configuration, not Alertmanager. 'alert' and 'group_by' are not top-level Alertmanager config keys.

Full explanation →
228
MCQeasy

Which component is the primary entry point for all administrative tasks and API requests in a Kubernetes cluster?

A.kube-controller-manager
B.kube-apiserver
C.etcd
D.kube-scheduler
AnswerB

The API server is the entry point for all REST API calls.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the sole entry point for all administrative tasks and API requests. It exposes the Kubernetes API (over HTTPS), validates and processes RESTful operations (e.g., kubectl commands, pod creation), and serves as the communication gateway between internal components (e.g., etcd, scheduler, controller-manager) and external clients. Without the API server, no administrative action or resource change can be initiated in the cluster.

Exam trap

A common trap is believing that etcd is the primary entry point because it stores all cluster data. However, etcd is a backend storage component and is never accessed directly by users or administrative tools—all reads and writes must pass through the kube-apiserver.

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager is not an entry point for API requests; it runs controller loops (e.g., Node Controller, Replication Controller) that watch the API server for desired state changes and reconcile the current state, but it does not accept external administrative tasks. Option C is wrong because etcd is a distributed key-value store that holds cluster state data, but it is not directly accessible for administrative tasks or API requests—all interactions with etcd must go through the kube-apiserver to ensure consistency and authorization. Option D is wrong because the kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints; it does not serve as an entry point for administrative tasks or API calls, and it only interacts with the API server to read pod specs and write scheduling decisions.

Full explanation →
229
MCQhard

You have a ConfigMap named 'app-config' and a Secret named 'db-password'. You want to mount them into a pod. Which statement is correct?

A.Secrets can be mounted as volumes, but ConfigMaps cannot
B.Both ConfigMaps and Secrets can be mounted as volumes
C.ConfigMaps can be mounted as volumes, but Secrets cannot
D.ConfigMaps and Secrets can only be exposed as environment variables
AnswerB

Both resource types support volume mounting and environment variable injection.

Why this answer

Both ConfigMaps and Secrets are Kubernetes API objects designed to decouple configuration data from container images. They can be mounted as volumes into pods, allowing files to be created in the container's filesystem with the data from the ConfigMap or Secret. This is a core feature for managing configuration and sensitive data in Kubernetes.

Exam trap

CNCF often tests the misconception that Secrets and ConfigMaps have different mounting capabilities, when in fact both support volume mounts and environment variable injection, with the key difference being that Secrets are base64-encoded and intended for sensitive data.

How to eliminate wrong answers

Option A is wrong because ConfigMaps can indeed be mounted as volumes, just like Secrets. Option C is wrong because Secrets can be mounted as volumes, just like ConfigMaps. Option D is wrong because both ConfigMaps and Secrets can be exposed as environment variables AND mounted as volumes, not only as environment variables.

Full explanation →
230
MCQmedium

In GitOps, what is the role of a tool like ArgoCD?

A.To automatically apply changes from a Git repository to a Kubernetes cluster
B.To monitor application performance
C.To create Docker images from source code
D.To manage container registries
AnswerA

ArgoCD is a GitOps operator that ensures the cluster matches the Git repo.

Why this answer

ArgoCD synchronizes the cluster state with the desired state defined in a Git repository.

Full explanation →
231
MCQhard

A cluster administrator needs to ensure that a Deployment named 'frontend' in namespace 'web' is updated with a new image version using a rolling update strategy. The current deployment has 4 replicas. The administrator runs: kubectl set image deployment/frontend frontend=nginx:1.21 -n web. Which of the following describes the expected behavior?

A.The Deployment will create a new ReplicaSet and gradually replace old pods with new ones
B.All existing pods will be deleted immediately and new pods will be created with the new image
C.The command will fail because you cannot update a Deployment using kubectl set image
D.The Deployment's image will be updated, but only the container named 'app' will be affected
AnswerA

This is the default rolling update behavior: a new ReplicaSet is created, and pods are gradually transitioned.

Why this answer

`kubectl set image deployment/frontend frontend=nginx:1.21 -n web` updates the container image in the Deployment's pod template, triggering a rolling update. The Deployment controller creates a new ReplicaSet with the updated image and gradually scales it up while scaling down the old ReplicaSet, ensuring zero downtime and maintaining the desired replica count of 4.

Exam trap

The trap here is that candidates may confuse the container name in the command (which must match the container name in the Deployment spec) with a generic name like 'app', leading them to incorrectly assume only a container named 'app' is affected.

How to eliminate wrong answers

Option B is wrong because it describes a 'Recreate' strategy, not the default 'RollingUpdate' strategy; a rolling update does not delete all pods immediately. Option C is wrong because `kubectl set image` is a valid command for updating container images in Deployments, StatefulSets, and other workloads. Option D is wrong because the command explicitly targets the container named 'frontend' (as specified in the command), not a container named 'app'; only the named container's image is updated.

Full explanation →
232
MCQeasy

Which Kubernetes object provides stable network endpoints and load balancing for a set of pods?

A.Service
B.Deployment
C.ConfigMap
D.Pod
AnswerA

Services provide stable IPs and DNS names with load balancing across pods.

Why this answer

A Service is the correct Kubernetes object because it provides a stable virtual IP (ClusterIP) and DNS name that remains constant even as pods are created or destroyed. It automatically load-balances traffic across the set of pods matching its label selector using iptables or IPVS rules, ensuring reliable network endpoints for clients.

Exam trap

The trap here is that candidates often confuse a Deployment's ability to manage replicas with providing network access, forgetting that only a Service creates a stable, load-balanced network abstraction over pods.

How to eliminate wrong answers

Option B (Deployment) is wrong because a Deployment manages pod replicas and rolling updates, but it does not expose a stable network endpoint or perform load balancing; it relies on a Service for that. Option C (ConfigMap) is wrong because it is used to inject configuration data (key-value pairs) into pods as environment variables or files, not to provide network endpoints or load balancing. Option D (Pod) is wrong because a Pod has a dynamic IP that changes on restart, and it cannot provide stable endpoints or load balancing across multiple pods; a Service abstracts over pods to solve this.

Full explanation →
233
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.

Full explanation →
234
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).

Full explanation →
235
Multi-Selecthard

Which THREE of the following are required for a Kubernetes pod to be considered healthy and ready to serve traffic?

Select 3 answers
A.The startup probe has succeeded.
B.The container is in the Running state.
C.The pod has at least one endpoint in its Service's endpoints list.
D.The readiness probe has succeeded.
E.The liveness probe has succeeded.
AnswersA, B, D

Startup probe indicates the application has started.

Why this answer

A startup probe must succeed before the kubelet considers the container started. Until the startup probe succeeds, the readiness and liveness probes are not active, so the pod cannot be marked healthy or ready. This is defined in the Kubernetes API for startup probes, which delay the start of other probes until the application has initialized.

Exam trap

The KCNA exam often tests the distinction between liveness and readiness probes, and the trap here is that candidates confuse a successful liveness probe (which only indicates the container is alive) with the readiness probe (which specifically controls traffic routing), leading them to incorrectly select option E.

Full explanation →
236
MCQeasy

A cloud-native application is designed with multiple microservices that need to handle a sudden spike in traffic without manual intervention. Which Kubernetes feature best enables this?

A.VerticalPodAutoscaler
B.Cluster Autoscaler
C.HorizontalPodAutoscaler
D.PodDisruptionBudget
AnswerC

Automatically scales pod replicas based on CPU/memory or custom metrics.

Why this answer

The HorizontalPodAutoscaler (HPA) automatically scales the number of pod replicas in a deployment based on observed CPU/memory utilization or custom metrics. This directly addresses the need to handle a sudden traffic spike without manual intervention by adding more pod instances to distribute the load.

Exam trap

CNCF often tests the distinction between scaling pods (HPA) versus scaling nodes (Cluster Autoscaler) versus scaling pod resources (VPA), and the trap here is that candidates confuse 'scaling the application' with 'scaling the cluster infrastructure'.

How to eliminate wrong answers

Option A is wrong because VerticalPodAutoscaler (VPA) adjusts resource requests and limits (CPU/memory) of existing pods, not the number of replicas, so it cannot handle a traffic spike by increasing capacity. Option B is wrong because Cluster Autoscaler adds or removes worker nodes to the cluster, not pods; it works at the infrastructure layer and does not directly scale the application itself. Option D is wrong because PodDisruptionBudget (PDB) limits the number of voluntary disruptions (e.g., node drains) to maintain availability, but it does not scale pods up or down in response to traffic changes.

Full explanation →
237
MCQmedium

An application requires external configuration that varies between environments (dev, staging, prod). Following the 12-factor app methodology, how should this configuration be provided?

A.Use environment variables
B.Store configuration in a config file that is version-controlled
C.Use a centralized database for configuration
D.Hard-code the configuration in the application code
AnswerA

12-factor apps store configuration in environment variables to keep it separate from code.

Why this answer

The 12-factor app methodology recommends storing configuration in environment variables to keep it separate from code and vary per deploy.

Full explanation →
238
Multi-Selecthard

Which THREE of the following are features provided by a service mesh like Istio? (Select THREE.)

Select 3 answers
A.Container image building
B.Traffic routing and load balancing
C.Observability including metrics and distributed tracing
D.Security through mTLS and access policies
E.Database schema migrations
AnswersB, C, D

Service mesh can route traffic based on rules.

Why this answer

Service mesh provides traffic management (routing), observability (metrics, tracing), and security (mTLS, policies).

Full explanation →
239
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.

Full explanation →
240
Multi-Selectmedium

Which TWO of the following are core principles of cloud native architecture according to the CNCF?

Select 2 answers
A.Static scaling based on predefined thresholds
B.Microservices architecture
C.Dynamic orchestration
D.Manual infrastructure management
E.Monolithic deployment
AnswersB, C

Microservices decompose applications into small, independent services, a core cloud native principle.

Why this answer

Options B and C are correct. Microservices architecture and dynamic orchestration are core principles of cloud native architecture according to the CNCF. Option A (static scaling) is not a core principle; cloud native emphasizes dynamic scaling.

Option D (manual infrastructure management) contradicts the principle of automation. Option E (monolithic deployment) is antithetical to the microservices principle. Thus, the correct answers are B and C.

Full explanation →
241
Drag & Dropmedium

Drag and drop the steps to create a ConfigMap from a file in Kubernetes 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

The correct sequence to create a ConfigMap from a file in Kubernetes is: first prepare the configuration file, then create the ConfigMap using kubectl create configmap, next verify the ConfigMap with kubectl get configmaps, then optionally describe it with kubectl describe configmap, and finally use it in a Pod as environment variables or volume mounts. This order ensures the ConfigMap is available and correctly configured before consumption.

Full explanation →
242
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.

Full explanation →
243
MCQmedium

A DevOps team wants to collect logs from all Kubernetes nodes and forward them to a central log storage system. Which tool is specifically designed for lightweight log aggregation and forwarding on Kubernetes nodes?

A.Elasticsearch
B.Prometheus
C.Fluent Bit
D.Grafana
AnswerC

Fluent Bit is a lightweight log forwarder suitable for Kubernetes nodes.

Why this answer

Fluent Bit is a lightweight log processor and forwarder, designed for resource-constrained environments like Kubernetes nodes.

Full explanation →
244
MCQmedium

A development team wants to implement a GitOps workflow for their Kubernetes deployments. Which tool is specifically designed for GitOps on Kubernetes?

A.ArgoCD
B.Helm
C.Jenkins
D.Terraform
AnswerA

Why this answer

ArgoCD is a declarative GitOps tool built specifically for Kubernetes.

Full explanation →
245
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.

Full explanation →
246
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.

Full explanation →
247
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.

Full explanation →
248
MCQeasy

What is the role of an API gateway in a microservices architecture?

A.To schedule pods on nodes
B.To store application configuration
C.To monitor container resource usage
D.To provide a single entry point for external clients to access multiple backend services
AnswerD

The API gateway routes requests to appropriate microservices and can aggregate responses.

Why this answer

An API gateway acts as a single entry point for client requests, handling routing, authentication, rate limiting, and other cross-cutting concerns.

Full explanation →
249
MCQeasy

A development team is containerizing a monolithic application into microservices. Which practice aligns with cloud-native architecture principles?

A.Use a shared database for all microservices to ensure data consistency.
B.Use JSON Web Tokens for authentication between microservices in the same cluster.
C.Design each microservice with its own data store and communicate via APIs.
D.Ensure all microservices have identical resource requests and limits.
AnswerC

Each microservice owning its data store enables independent scaling and evolution.

Why this answer

Cloud-native architecture principles advocate for decentralized data management, where each microservice owns its private data store and exposes functionality via well-defined APIs. This ensures loose coupling, independent scalability, and resilience, as services can evolve without impacting others. The pattern aligns with the Database per Service pattern, a core tenet of microservices design.

Exam trap

CNCF often tests the misconception that 'shared data ensures consistency' (Option A) or that 'identical resource limits simplify management' (Option D), while the correct answer emphasizes data autonomy and API-based communication as the hallmark of cloud-native design.

How to eliminate wrong answers

Option A is wrong because a shared database creates tight coupling between microservices, violating the principle of bounded contexts and making independent deployments and scaling impossible; it also introduces a single point of failure and contention. Option B is wrong because JSON Web Tokens (JWTs) are used for stateless authentication between services, but within the same cluster, internal service-to-service communication should leverage mutual TLS (mTLS) or a service mesh (e.g., Istio) for stronger security, not rely on JWT alone which can be intercepted without transport encryption. Option D is wrong because requiring identical resource requests and limits for all microservices ignores the fact that different services have distinct resource profiles (e.g., CPU-intensive vs. memory-intensive), leading to inefficient cluster utilization and potential throttling or waste.

Full explanation →
250
MCQhard

You create a Deployment with 'replicas: 3' and update the pod template without changing the selector. After the update, you notice that only the new Pods are running, but old Pods have been terminated. What is the default update strategy?

A.OnDelete
B.BlueGreen
C.RollingUpdate
D.Recreate
AnswerC

RollingUpdate gradually replaces Pods; old ones are terminated as new ones become ready.

Why this answer

The default update strategy for a Deployment in Kubernetes is RollingUpdate. When you update the pod template (e.g., changing the container image), the Deployment controller creates new ReplicaSets with the updated template and gradually scales down the old ReplicaSet while scaling up the new one, ensuring zero downtime. Since only new Pods are running and old Pods have been terminated, this confirms the default behavior of a rolling update, which replaces Pods incrementally without manual intervention.

Exam trap

A common trap is assuming the default update strategy is Recreate because it seems simpler, but the actual default is RollingUpdate, which performs gradual, zero-downtime updates.

How to eliminate wrong answers

Option A is wrong because OnDelete is a DaemonSet update strategy, not a Deployment strategy; it requires manual deletion of Pods to trigger updates. Option B is wrong because BlueGreen is not a native Kubernetes Deployment strategy; it is a deployment pattern implemented manually or via tools like Istio, not a default or built-in strategy. Option D is wrong because Recreate is a Deployment strategy that terminates all old Pods before creating new ones, but it is not the default; the default is RollingUpdate, and Recreate would cause downtime, which is not described in the scenario.

Full explanation →
251
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.

Full explanation →
252
MCQhard

A team uses ArgoCD with a Git repository that contains Helm charts. They want ArgoCD to automatically sync when a new image tag is pushed to the container registry. Which approach should they use?

A.Use Flux Image Automation Controller
B.Configure a webhook from the registry to ArgoCD API server
C.Manually update the Helm values and commit
D.Use ArgoCD Image Updater
AnswerD

ArgoCD Image Updater monitors registries and updates the desired state in Git automatically.

Why this answer

ArgoCD Image Updater is the official tool to automatically update image tags in Kubernetes manifests (including Helm values) and commit changes to Git, triggering ArgoCD to sync.

Full explanation →
253
MCQhard

A cloud-native application experiences periodic timeouts when calling a downstream service. The downstream service is running in the same Kubernetes cluster. Which design pattern should be implemented to handle this gracefully?

A.Circuit breaker pattern
B.Bulkhead pattern
C.Retry with exponential backoff
D.Health check endpoint
AnswerA

Prevents cascading failures.

Why this answer

The Circuit Breaker pattern is correct because it prevents cascading failures by monitoring for failures and, once a threshold is exceeded (e.g., 5 consecutive timeouts), it opens the circuit and immediately fails fast without waiting for the downstream service. This allows the application to handle periodic timeouts gracefully by avoiding wasted resources and providing a fallback response, which is critical for cloud-native resilience in Kubernetes.

Exam trap

CNCF often tests the distinction between 'handling' a failure (Circuit Breaker) and 'preventing' a failure (Bulkhead), so candidates mistakenly choose Bulkhead when the question asks for graceful handling of timeouts rather than resource isolation.

How to eliminate wrong answers

Option B (Bulkhead pattern) is wrong because it isolates resources (e.g., thread pools) to prevent one failing component from exhausting shared resources, but it does not address handling periodic timeouts from a downstream service; it focuses on fault isolation, not failure response. Option C (Retry with exponential backoff) is wrong because while it can help with transient failures, periodic timeouts suggest a persistent or overloaded downstream service, and retries can exacerbate the problem by adding load and delaying failure detection. Option D (Health check endpoint) is wrong because it only provides a way to probe the service's liveness or readiness (e.g., via Kubernetes probes), but it does not handle the timeout scenario itself; it is a detection mechanism, not a graceful handling pattern.

Full explanation →
254
MCQmedium

A team wants to visualize metrics from Prometheus in a dashboard. Which tool is commonly used for this purpose?

A.Grafana
B.Alertmanager
C.Jaeger UI
D.Kibana
AnswerA

Grafana integrates natively with Prometheus.

Why this answer

Grafana is the most popular visualization tool for Prometheus metrics, offering rich dashboards.

Full explanation →
255
MCQmedium

What is the smallest deployable unit in Kubernetes that can be created and managed?

A.Deployment
B.Node
C.Container
D.Pod
AnswerD

Pod is the smallest deployable unit.

Why this answer

The Pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of a running process in the cluster and encapsulates one or more containers, shared storage, and a unique network IP. While containers are the runtime units, Kubernetes does not manage containers directly; it manages Pods, which are the atomic deployable and schedulable entities.

Exam trap

A common mistake is to assume a Container is the smallest deployable unit because containers are the runtime entities, but Kubernetes manages Pods, which are the smallest deployable and schedulable objects.

How to eliminate wrong answers

Option A is wrong because a Deployment is a higher-level abstraction that manages ReplicaSets and Pods; it is not the smallest deployable unit. Option B is wrong because a Node is a worker machine (physical or virtual) in the cluster, not a deployable unit — Pods are scheduled onto Nodes. Option C is wrong because a Container is the runtime process, but Kubernetes cannot create or manage a container directly without wrapping it in a Pod; the Pod is the smallest unit that Kubernetes can schedule and manage.

Full explanation →
256
MCQhard

Which of the following kubectl commands would you use to update a Deployment's image to 'nginx:1.21' and record the change in the rollout history?

A.kubectl edit deployment nginx --image=nginx:1.21
B.kubectl set image deployment/nginx nginx=nginx:1.21
C.kubectl set image deployment/nginx nginx=nginx:1.21 --record
D.kubectl patch deployment nginx -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.21"}]}}}}' --record
AnswerC

This updates the image and records the change in the rollout history.

Why this answer

`kubectl set image deployment/nginx nginx=nginx:1.21 --record` updates the container image of the specified deployment and, with the `--record` flag, annotates the change in the rollout history (stored in the `kubernetes.io/change-cause` annotation). This allows you to later inspect the change with `kubectl rollout history deployment/nginx`.

Exam trap

CNCF often tests the `--record` flag as a subtle requirement; candidates may pick option B because it correctly updates the image but forget that the question explicitly asks to record the change in the rollout history.

How to eliminate wrong answers

Option A is wrong because `kubectl edit deployment nginx --image=nginx:1.21` is invalid syntax; `kubectl edit` opens an editor for the resource and does not accept an `--image` flag. Option B is wrong because `kubectl set image deployment/nginx nginx=nginx:1.21` updates the image but does not include the `--record` flag, so the change will not be recorded in the rollout history. Option D is wrong because while `kubectl patch` with the correct JSON patch can update the image and `--record` records it, the question specifically asks for a command to update the image and record the change; option C is the most direct and standard command for this purpose, and option D is unnecessarily complex and less idiomatic for a simple image update.

Full explanation →
257
MCQeasy

What is the primary purpose of a Namespace in Kubernetes?

A.To set resource quotas for the entire cluster
B.To define network policies for pods
C.To manage node affinity rules
D.To isolate resources and provide a scope for names
AnswerD

Namespaces partition resources into logically named groups.

Why this answer

Namespaces in Kubernetes provide a mechanism for isolating groups of resources within a single cluster. They create separate scopes for resource names, meaning that resource names (like Pods or Services) only need to be unique within a Namespace, not across the entire cluster. This allows multiple teams or projects to share a cluster without naming conflicts, and it also enables cluster administrators to apply policies (like ResourceQuotas) and network policies at the Namespace level.

Exam trap

The trap here is that candidates confuse Namespaces with other cluster-level constructs like ResourceQuotas or NetworkPolicies, assuming Namespaces directly enforce limits or rules, when in fact Namespaces only provide the scope for names and isolation, while other objects (like ResourceQuotas, NetworkPolicies, and RBAC) are applied to that scope.

How to eliminate wrong answers

Option A is wrong because setting resource quotas for the entire cluster is not the primary purpose of a Namespace; ResourceQuotas are a separate Kubernetes object that can be applied to a Namespace to limit aggregate resource consumption, but Namespaces themselves do not enforce quotas. Option B is wrong because defining network policies for pods is the job of NetworkPolicy objects, which can be scoped to a Namespace, but the Namespace itself does not define network policies. Option C is wrong because managing node affinity rules is a function of PodSpec fields like nodeSelector and nodeAffinity, which are independent of Namespaces; Namespaces do not control which nodes Pods are scheduled on.

Full explanation →
258
MCQmedium

A team is designing a cloud-native application that requires each microservice to have its own database. This pattern is known as:

A.Saga pattern
B.Database-per-service pattern
C.Shared database pattern
D.CQRS pattern
AnswerB

Each service has its own private database.

Why this answer

The Database-per-service pattern is the correct answer because it ensures each microservice owns and manages its own database, enforcing loose coupling and data encapsulation. This aligns with the cloud-native principle of decentralized data management, where services communicate only via APIs and never access each other's databases directly. It prevents tight coupling at the data layer, which is critical for independent scaling, deployment, and resilience in a microservices architecture.

Exam trap

CNCF often tests the misconception that the Saga pattern defines database ownership, when in fact it is a transaction coordination pattern, not a data isolation strategy.

How to eliminate wrong answers

Option A is wrong because the Saga pattern is a distributed transaction management pattern used to maintain data consistency across multiple services, not a database ownership model. Option C is wrong because the Shared database pattern contradicts the requirement for each microservice to have its own database, as it forces all services to access a single database, creating tight coupling and single points of failure. Option D is wrong because CQRS (Command Query Responsibility Segregation) is a pattern that separates read and write operations into different models or databases, but it does not define per-service database ownership.

Full explanation →
259
MCQhard

A team wants to implement cost monitoring for their Kubernetes clusters. Which approach is most effective?

A.Use cloud provider billing APIs combined with resource utilization data
B.Use kubectl top to get resource usage
C.Estimate costs based on node count
D.Monitor CPU and memory usage with Prometheus
AnswerA

This maps resource consumption to cost.

Why this answer

Cloud provider billing APIs provide actual cost data per resource (e.g., per node, per persistent volume, per network egress), and combining this with resource utilization data (e.g., CPU/memory requests and actual usage from metrics) enables accurate cost allocation per namespace, pod, or workload. This approach directly maps infrastructure spend to Kubernetes abstractions, which is essential for chargeback or showback in multi-tenant clusters.

Exam trap

The trap here is that candidates confuse resource monitoring (CPU/memory) with cost monitoring, assuming that tracking utilization alone (e.g., with Prometheus or kubectl top) is sufficient to understand spending, when in fact cost data requires explicit billing integration.

How to eliminate wrong answers

Option B is wrong because 'kubectl top' only shows current resource usage (CPU/memory) for nodes and pods, not cost data; it lacks any billing context or historical aggregation needed for cost monitoring. Option C is wrong because estimating costs based solely on node count ignores variable costs like storage, network egress, and managed services (e.g., load balancers), leading to inaccurate cost attribution. Option D is wrong because Prometheus monitors resource utilization metrics (CPU, memory, disk I/O) but does not inherently provide cost data; it would need to be combined with pricing information from cloud provider APIs to calculate costs.

Full explanation →
260
Multi-Selectmedium

Which THREE of the following are core principles of cloud native computing as defined by the CNCF? (Select 3)

Select 3 answers
A.Dynamic orchestration
B.Waterfall development
C.Monolithic architecture
D.Microservices
E.Containers
AnswersA, D, E

Dynamic orchestration (e.g., Kubernetes) is a core principle.

Why this answer

The CNCF defines cloud native as using microservices, containers, dynamic orchestration, and DevOps. The three correct options are microservices, containers, and dynamic orchestration. DevOps is also a principle, but the question asks for three; the other options are not core principles.

Full explanation →
261
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.

Full explanation →
262
Multi-Selectmedium

Which TWO are benefits of using a service mesh? (Choose two.)

Select 2 answers
A.Observability of service-to-service communication
B.Automatic database scaling
C.Traffic management (e.g., canary deployments)
D.Container image building
E.Load balancing of external requests
AnswersA, C

Service mesh collects metrics and traces for inter-service calls.

Why this answer

Service mesh provides observability (e.g., metrics, tracing) and traffic management (e.g., routing, retries) between services.

Full explanation →
263
MCQhard

A team uses Flux with the Source Controller and Kustomize Controller. They update a YAML file in Git to change a Deployment's replica count. What describes the synchronization flow?

A.The Source Controller directly applies the manifest to the cluster
B.Flux uses HelmReleases to apply changes
C.The Kustomize Controller fetches the source and applies the rendered manifests
D.Flux requires a manual kubectl apply to sync
AnswerC

Kustomize Controller reconciles the source and applies.

Why this answer

Flux Source Controller fetches changes from Git; Kustomize Controller reconciles the kustomization and applies to the cluster.

Full explanation →
264
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.

Full explanation →
265
MCQmedium

Which tool is specifically designed for distributed tracing and is a Cloud Native Computing Foundation (CNCF) graduated project?

A.Grafana
B.Fluentd
C.Jaeger
D.Prometheus
AnswerC

Jaeger is a graduated CNCF project for distributed tracing.

Why this answer

Jaeger is a CNCF graduated project focused on distributed tracing.

Full explanation →
266
MCQeasy

Which component runs on each worker node and ensures that containers are running as specified in the Pod spec?

A.kubelet
B.kube-proxy
C.kube-scheduler
D.kube-controller-manager
AnswerA

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

Why this answer

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It receives PodSpec definitions (via the API server or a file) and ensures that the containers described in those PodSpecs are running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers, and it reports the node and pod status back to the control plane.

Exam trap

A common trap is confusing the kubelet (a node-level agent that runs on each worker and directly manages containers) with control-plane components like the kube-scheduler or kube-controller-manager, which run on the master node and handle cluster-level decisions.

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 routing and load balancing (e.g., via iptables or IPVS), not container lifecycle management. Option C (kube-scheduler) is wrong because it runs on the control plane and is responsible for assigning pods to nodes based on resource availability and constraints, not for running containers on a node. Option D (kube-controller-manager) is wrong because it runs on the control plane and manages controllers (e.g., ReplicaSet, Node Controller) that maintain desired cluster state, but it does not directly interact with containers on worker nodes.

Full explanation →
267
MCQmedium

Which component of the OpenTelemetry architecture is responsible for receiving data from instrumented applications and processing it before export?

A.OpenTelemetry SDK
B.OpenTelemetry API
C.OpenTelemetry Collector
D.OpenTelemetry exporter
AnswerC

The Collector handles ingestion, processing, and export.

Why this answer

The OpenTelemetry Collector receives, processes, and exports telemetry data.

Full explanation →
268
MCQhard

A Service of type ClusterIP is not resolving DNS names for pods. The pods are running and can communicate with each other via IP addresses. Which component should be checked first?

A.The kubelet on the node where the pod is running
B.The Service's endpoint slices
C.kube-proxy on the nodes
D.CoreDNS pods in the kube-system namespace
AnswerD

CoreDNS provides DNS resolution for cluster services.

Why this answer

DNS name resolution for Services in Kubernetes is handled by CoreDNS, which runs as pods in the kube-system namespace. When a ClusterIP Service fails to resolve DNS names but pods can communicate via IP addresses, the issue is almost certainly with the DNS resolver itself, not with network connectivity or Service endpoints. CoreDNS must be checked first to ensure it is running, has correct configuration, and can query the Kubernetes API for Service records.

Exam trap

A common misconception is that DNS failures are caused by kube-proxy or network proxy issues, when in fact DNS resolution is a separate layer handled by CoreDNS, and candidates should first verify the DNS pods themselves.

How to eliminate wrong answers

Option A is wrong because the kubelet is responsible for managing pod lifecycle and container runtime, not for DNS resolution or Service name resolution. Option B is wrong because endpoint slices define the actual pod IPs backing a Service, but DNS resolution depends on CoreDNS querying the API server, not on the endpoints themselves; if DNS fails, endpoint slices are irrelevant. Option C is wrong because kube-proxy handles network proxy rules for Service traffic (e.g., iptables or IPVS), but DNS name resolution is a separate function performed by CoreDNS; kube-proxy does not resolve DNS names.

Full explanation →
269
MCQeasy

Which of the following best describes the purpose of the CNCF (Cloud Native Computing Foundation)?

A.To develop proprietary cloud native software
B.To define the 12-factor app methodology
C.To host and promote open source cloud native projects
D.To provide certification exams for Kubernetes administrators
AnswerC

Why this answer

The CNCF's mission is to make cloud native computing ubiquitous by fostering and sustaining open source projects.

Full explanation →
270
Multi-Selecteasy

Which TWO of the following tools are commonly used for distributed tracing in cloud-native environments? (Select two.)

Select 2 answers
A.Zipkin
B.Grafana
C.Jaeger
D.Fluentd
E.Prometheus
AnswersA, C

Zipkin is a distributed tracing system.

Why this answer

Jaeger and Zipkin are popular open-source distributed tracing systems.

Full explanation →
271
MCQhard

In PromQL, which function would you use to calculate the per-second rate of increase of a counter over a specified time window?

A.rate()
B.delta()
C.avg_over_time()
D.increase()
AnswerA

rate() is the correct function for per-second rate of a counter.

Why this answer

The rate() function calculates the per-second average rate of increase of a counter over a time range.

Full explanation →
272
MCQhard

A cloud-native application experiences intermittent failures when calling an external API. The team implements a pattern that allows the application to temporarily stop calling the failing API and serve stale data or a fallback response. Which resiliency pattern does this describe?

A.Circuit Breaker pattern
B.Retry pattern
C.Bulkhead pattern
D.Timeout pattern
AnswerA

The circuit breaker opens to stop calls and allows fallback.

Why this answer

The circuit breaker pattern prevents repeated calls to a failing service, allowing the system to degrade gracefully.

Full explanation →
273
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.

Full explanation →
274
Multi-Selectmedium

Which TWO statements correctly describe the purpose of etcd in a Kubernetes cluster?

Select 2 answers
A.It stores the cluster state, including all Kubernetes objects.
B.It manages network rules for Pod-to-Pod communication.
C.It schedules Pods onto nodes based on resource availability.
D.It exposes the Kubernetes API for external access.
E.It is a distributed key-value store that provides high availability and consistency.
AnswersA, E

etcd is the backing store for all cluster data.

Why this answer

Etcd is the primary data store for all Kubernetes cluster state, including the configuration and status of every Kubernetes object (Pods, Services, Deployments, etc.). It stores this information as key-value pairs, and the Kubernetes API server is the only component that reads from and writes to etcd directly. Without etcd, the cluster would have no persistent record of its desired or current state.

Exam trap

CNCF often tests the distinction between the component that stores state (etcd) and the components that use that state (scheduler, controller manager, API server), so the trap here is confusing etcd's role as a passive data store with the active management functions of other control plane components.

Full explanation →
275
Multi-Selectmedium

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

Select 3 answers
A.ClusterIP
B.NodePort
C.LoadBalancer
D.Ingress
E.ExternalName
AnswersA, B, C

ClusterIP exposes the service on a cluster-internal IP; it is the default type.

Why this answer

A ClusterIP service exposes the set of pods on a cluster-internal IP address, making it reachable only from within the cluster. This is the default service type in Kubernetes and is valid for internal communication between workloads. It does not provide external access, but it is a core method for exposing pods as a network service.

Exam trap

CNCF often tests the distinction between service types (ClusterIP, NodePort, LoadBalancer) and other networking objects like Ingress or ExternalName, trapping candidates who think Ingress is a service type or that ExternalName exposes pods.

Full explanation →
276
MCQhard

In OpenTelemetry, what is the purpose of the Collector component?

A.Instrument code automatically
B.Receive, process, and export telemetry data
C.Visualize traces and metrics
D.Aggregate logs from multiple sources
AnswerB

The Collector is a vendor-agnostic pipeline for telemetry data.

Why this answer

The OpenTelemetry Collector is a vendor-agnostic agent or gateway that receives telemetry data (traces, metrics, logs) from instrumented applications, processes it (e.g., batching, filtering, sampling), and exports it to one or more backends (e.g., Jaeger, Prometheus, or any OTLP-compatible system). It decouples data generation from data export, enabling flexible pipeline management without modifying application code.

Exam trap

CNCF often tests the distinction between the Collector's role (data pipeline) and other components like SDKs (instrumentation) or backends (visualization/storage), so candidates mistakenly associate the Collector with auto-instrumentation or visualization.

How to eliminate wrong answers

Option A is wrong because automatic code instrumentation is the role of OpenTelemetry SDKs and auto-instrumentation agents (e.g., Java agent), not the Collector; the Collector does not instrument code. Option C is wrong because visualization of traces and metrics is the responsibility of backend tools like Jaeger UI, Grafana, or Prometheus, not the Collector, which only processes and forwards data. Option D is wrong because while the Collector can handle logs, its primary purpose is not limited to log aggregation; it is a unified pipeline for traces, metrics, and logs, and log aggregation alone is a narrower function often served by tools like Fluentd or Logstash.

Full explanation →
277
Drag & Dropmedium

Drag and drop the steps to create a Kubernetes Namespace and deploy an application into it 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

First create namespace, then deploy resources specifying that namespace, and verify.

Full explanation →
278
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.

Full explanation →
279
MCQmedium

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

A.The pod does not have tolerations for the node's taints and memory is insufficient on other nodes
B.The kube-scheduler is not running
C.The container runtime is not installed on any node
D.The pod's resource requests exceed available resources on all nodes
AnswerA

Why this answer

The event '0/3 nodes are available: 1 node(s) had taint(s) that the pod didn't tolerate, 2 node(s) had insufficient memory' directly indicates that the pod failed scheduling because it lacks required tolerations for a tainted node, and the remaining nodes do not have enough memory to satisfy the pod's resource requests. This matches option A, as the pod's tolerations are missing for the tainted node, and memory is insufficient on the other two nodes.

Exam trap

The CNCF exam often tests the distinction between scheduling failures (like taints and resource insufficiency) and runtime failures (like missing container runtime or scheduler), tricking candidates into picking a generic cause like 'kube-scheduler not running' when the detailed event clearly shows the scheduler is working.

How to eliminate wrong answers

Option B is wrong because if the kube-scheduler were not running, the pod would remain in Pending state but no scheduling events would appear at all; the specific event about taints and insufficient memory proves the scheduler is actively evaluating nodes. Option C is wrong because a missing container runtime would cause the pod to fail at the kubelet level with a different event (e.g., 'failed to create container'), not a scheduling event about taints and memory. Option D is wrong because while insufficient memory is part of the issue, the event explicitly mentions a taint that the pod didn't tolerate, which is a separate scheduling constraint not covered by resource requests alone.

Full explanation →
280
MCQeasy

A Kubernetes administrator is troubleshooting a pod that is stuck in CrashLoopBackOff. The pod's restart count is increasing. Which initial step should the administrator take to diagnose the issue?

A.Run 'kubectl describe pod <pod-name>' to check events
B.Check the Prometheus metrics for the pod's CPU usage
C.Run 'kubectl exec -it <pod-name> -- /bin/sh' to inspect the container
D.Run 'kubectl logs <pod-name>' to view the application logs
AnswerD

Logs often contain error messages that explain why the application is crashing.

Why this answer

When a pod is in CrashLoopBackOff, the immediate priority is to inspect the application logs to understand why the container is failing. `kubectl logs <pod-name>` retrieves the stdout/stderr output from the container, which typically contains error messages, stack traces, or configuration issues that caused the crash. This is the most direct and efficient first step before deeper investigation.

Exam trap

The trap here is that candidates often jump to `kubectl describe pod` (Option A) because it shows events and status, but they overlook that application-level errors are only visible in the container logs, not in the pod events.

How to eliminate wrong answers

Option A is wrong because `kubectl describe pod` shows events and status details, but it does not show the application's runtime logs; it is useful for cluster-level issues (e.g., image pull failures, node problems) but not for application crashes. Option B is wrong because Prometheus metrics are for long-term monitoring and alerting, not for real-time crash diagnosis; CPU usage data will not reveal why a process exited. Option C is wrong because `kubectl exec` requires a running container, but a pod in CrashLoopBackOff has a container that is repeatedly crashing and may not be running at the moment the command is issued, causing the exec to fail.

Full explanation →
281
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.

Full explanation →
282
MCQmedium

Which component runs on every Kubernetes node and ensures that the containers in a pod are running?

A.kube-proxy
B.kube-scheduler
C.kubelet
D.container runtime
AnswerC

The kubelet is the node agent that manages pods.

Why this answer

The kubelet is the primary node agent that runs on every Kubernetes node. It receives PodSpec definitions from the API server and ensures that the containers described in those PodSpecs are running and healthy. It continuously monitors container status and takes corrective actions, such as restarting containers that have failed, making it the correct answer.

Exam trap

The trap here is that candidates often confuse the container runtime (which physically runs containers) with the kubelet (which orchestrates and monitors them), leading them to select 'container runtime' instead of 'kubelet'.

How to eliminate wrong answers

Option A is wrong because kube-proxy is a network proxy that runs on each node, handling network rules and forwarding traffic to pods; it does not manage container lifecycle. Option B is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints; it does not run on worker nodes and does not ensure containers are running. Option D is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it is the kubelet that interacts with the container runtime via the Container Runtime Interface (CRI) to enforce the desired state; the runtime alone does not perform health monitoring or reconciliation.

Full explanation →
283
MCQmedium

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

A.To check if the pod is scheduled on a node
B.To check if the container has started successfully
C.To check if the application is ready to serve traffic
D.To check if the application is still running; if not, restart the container
AnswerD

Liveness probes indicate whether the container is alive.

Why this answer

A liveness probe in Kubernetes is used to determine if a container is still running and healthy. If the probe fails, the kubelet kills the container and restarts it based on the pod's restart policy. This ensures that applications that have entered a deadlock or hung state are automatically recovered without manual intervention.

Exam trap

The trap here is that candidates often confuse liveness probes with readiness probes, mistakenly thinking liveness determines traffic readiness, but liveness is solely about container health and automatic restarts, not service connectivity.

How to eliminate wrong answers

Option A is wrong because checking if a pod is scheduled on a node is the role of the Kubernetes scheduler and is reflected in the pod's status, not a liveness probe. Option B is wrong because checking if a container has started successfully is the purpose of a startup probe, which runs before other probes to allow slow-starting applications time to initialize. Option C is wrong because checking if the application is ready to serve traffic is the purpose of a readiness probe, which controls whether the pod receives traffic from Services, not whether it should be restarted.

Full explanation →
284
MCQeasy

Which of the following is a core principle of cloud native architecture as defined by the CNCF?

A.Monolithic application design
B.Manual scaling of applications
C.Static infrastructure provisioning
D.Microservices packaged in containers
AnswerD

Microservices in containers are a key cloud native principle.

Why this answer

The CNCF defines cloud native architecture as using microservices, containers, dynamic orchestration, and DevOps.

Full explanation →
285
MCQeasy

Which of the following is the correct definition of a Service Level Indicator (SLI)?

A.A formal contract between a service provider and a customer
B.A target value or range for a metric, agreed upon with stakeholders
C.A quantitative measure of a specific aspect of the service's reliability
D.A tool for aggregating logs from multiple sources
AnswerC

An SLI is exactly that: a metric that indicates the level of service.

Why this answer

An SLI is a specific metric that measures a particular aspect of service reliability, such as request latency or error rate.

Full explanation →
286
MCQeasy

Which GitOps tool is specifically designed for Kubernetes and follows the declarative GitOps pattern, continuously reconciling the desired state from a Git repository?

A.ArgoCD
B.Helm
C.Terraform
D.Jenkins
AnswerA

ArgoCD is purpose-built for GitOps on Kubernetes.

Why this answer

ArgoCD is a declarative GitOps continuous delivery tool for Kubernetes that syncs application state with a Git repository.

Full explanation →
287
MCQmedium

A development team wants to deploy a serverless function that triggers when a file is uploaded to an S3 bucket. Which cloud native technology is most appropriate for this scenario?

A.AWS Lambda
B.Helm
C.Knative
D.Istio
AnswerC

Knative is a CNCF incubating project that provides serverless capabilities on Kubernetes, including event-driven functions.

Why this answer

Knative is a Kubernetes-based platform to build, deploy, and manage serverless workloads, including event-driven functions. AWS Lambda is a proprietary service, not a cloud native project.

Full explanation →
288
Drag & Dropmedium

Drag and drop the steps to troubleshoot a Pod stuck in CrashLoopBackOff 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

Start with describe for events, then logs for errors, check resources, verify image/command, then fix and redeploy.

Full explanation →
289
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.

Full explanation →
290
MCQmedium

Which of the following is true about Kubernetes Namespaces?

A.Objects in different namespaces cannot communicate with each other
B.Namespaces allow you to divide cluster resources between multiple users
C.Namespaces are global across all clusters
D.Namespaces provide network isolation by default
AnswerB

Namespaces enable resource quotas and RBAC to separate teams.

Why this answer

Kubernetes Namespaces provide a mechanism for partitioning a single cluster into multiple virtual clusters, enabling resource quota management and access control for different users or teams. This allows administrators to divide cluster resources (e.g., CPU, memory, storage) among multiple users via ResourceQuotas and Role-Based Access Control (RBAC), ensuring isolation of resource usage without requiring separate physical clusters.

Exam trap

A common misconception is that namespaces provide automatic network isolation; however, network isolation requires explicit NetworkPolicy objects, and namespaces only offer logical resource partitioning.

How to eliminate wrong answers

Option A is wrong because objects in different namespaces can communicate with each other by default via DNS (e.g., <service>.<namespace>.svc.cluster.local) or direct IP, unless explicitly restricted by NetworkPolicies. Option C is wrong because namespaces are scoped to a single Kubernetes cluster; they are not global across clusters, and each cluster has its own independent set of namespaces. Option D is wrong because namespaces do not provide network isolation by default; network isolation requires explicit NetworkPolicy resources that define ingress/egress rules, and without them, pods in different namespaces can communicate freely.

Full explanation →
291
Multi-Selectmedium

Which TWO of the following are deployment patterns that can be used to update applications with minimal downtime? (Choose two.)

Select 2 answers
A.DaemonSet deployment
B.Sidecar deployment
C.Recreate deployment
D.Blue-green deployment
E.Canary deployment
AnswersD, E

Blue-green deploys a new version alongside the old and switches traffic after testing.

Why this answer

Blue-green and canary are deployment patterns that reduce downtime by gradually shifting traffic. Rolling update is also a pattern but the question asks for minimal downtime; blue-green and canary are specifically designed for that.

Full explanation →
292
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.

Full explanation →
293
Multi-Selectmedium

Which TWO of the following are key characteristics of cloud-native applications? (Select two.)

Select 2 answers
A.Monolithic architecture
B.Microservices architecture
C.Containerized deployment
D.Manual scaling
E.Long-lived virtual machines
AnswersB, C

Microservices are a core pattern in cloud-native.

Why this answer

Cloud-native applications are designed as microservices and use containers for deployment, enabling scalability and resilience.

Full explanation →
294
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.

Full explanation →
295
Multi-Selecthard

Which TWO of the following are recommended practices for achieving observability in a Kubernetes cluster?

Select 2 answers
A.Use a single centralized logging solution to aggregate logs from all components.
B.Store all debug logs for a minimum of 90 days for compliance.
C.Include correlation IDs in structured logs to enable tracing across services.
D.Disable leader election for monitoring components to reduce complexity.
E.Use Prometheus with a pull-based model to scrape metrics from pods.
AnswersC, E

Correlation IDs help trace requests across microservices.

Why this answer

Including correlation IDs in structured logs is a key observability practice that enables distributed tracing across microservices. In Kubernetes, where requests often traverse multiple pods and services, correlation IDs allow you to link logs from different components into a single transaction flow, which is essential for debugging and understanding system behavior.

Exam trap

CNCF often tests the misconception that centralized logging is always best, but the trap here is that observability emphasizes distributed, resilient data collection over a single monolithic log sink, and that debug logs are not subject to long-term compliance retention like audit logs.

Full explanation →
296
Multi-Selecthard

An administrator wants to perform a rolling update of a Deployment. Which TWO actions will achieve this?

Select 2 answers
A.Run 'kubectl set image deployment/myapp myapp=myapp:v2'
B.Run 'kubectl scale deployment myapp --replicas=0' then 'kubectl scale deployment myapp --replicas=5'
C.Run 'kubectl delete deployment' and then 'kubectl create deployment' with the new image
D.Run 'kubectl rollout undo deployment/myapp'
E.Edit the Deployment YAML to change the image version and run 'kubectl apply -f deployment.yaml'
AnswersA, E

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

Why this answer

'kubectl set image deployment/myapp myapp=myapp:v2' directly updates the container image in the Deployment's pod template, which triggers a rolling update by default. The Deployment controller then creates a new ReplicaSet with the updated image and gradually scales it up while scaling down the old ReplicaSet, ensuring zero downtime.

Exam trap

The trap here is that candidates may confuse scaling (Option B) or deleting/recreating (Option C) with a rolling update, or think that 'rollout undo' (Option D) is a way to update to a new image, when it is actually for reverting to a previous version.

Full explanation →
297
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.

Full explanation →
298
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.

Full explanation →
299
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.

Full explanation →
300
Multi-Selectmedium

Which THREE of the following are valid Kubernetes resource types?

Select 3 answers
A.DockerImage
B.Deployment
C.ConfigMap
D.VirtualMachine
E.Service
AnswersB, C, E

A Deployment is a standard resource.

Why this answer

Deployment is a core Kubernetes resource that manages the lifecycle of Pods and ReplicaSets, providing declarative updates, scaling, and rollback capabilities. It is one of the most commonly used workload resources in Kubernetes, making option B correct.

Exam trap

The KCNA exam often tests whether candidates confuse container image references (like Docker images) with actual Kubernetes API resource types, leading them to incorrectly select DockerImage as a valid resource.

Full explanation →
Page 3

Page 4 of 12

Page 5

All pages

123456789101112

Practice KCNA by domain

Target a specific domain to shore up weak areas.

Kubernetes FundamentalsContainer OrchestrationCloud Native ArchitectureCloud Native ObservabilityCloud Native Application Delivery
See all domains with question counts →