Knowledge + Practice

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 301–375

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

Take a mock exam Exam hub

Page 5 of 12

301

Multi-Selectmedium

Which THREE are core principles of the Twelve-Factor App methodology?

Select 3 answers

A.Store config in codebase for traceability

B.Explicitly declare and isolate dependencies

C.Tight coupling to backing services

D.Treat logs as event streams

E.One codebase tracked in revision control, many deploys

AnswersB, D, E

Dependencies declared in manifest.

Why this answer

The Twelve-Factor App methodology mandates that dependencies must be explicitly declared and isolated via a dependency declaration manifest (e.g., Gemfile, package.json, requirements.txt) and a dependency isolation tool (e.g., Bundler, npm, pip). This ensures that the application never implicitly depends on system-wide packages, eliminating 'it works on my machine' issues and guaranteeing consistent behavior across all environments.

Exam trap

CNCF often tests the misconception that storing configuration in the codebase provides traceability, but the Twelve-Factor App explicitly forbids this to maintain strict separation of config from code and avoid accidental exposure of secrets.

Full explanation →

302

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.

Full explanation →

303

MCQmedium

A DevOps engineer has created a ConfigMap named 'app-config' with some configuration data. They want to make that data available as environment variables in a pod. Which field in the pod spec should they use to achieve this?

A.spec.volumes

B.spec.containers[].volumeMounts

C.spec.containers[].envFrom

D.spec.containers[].env

AnswerC

envFrom takes a list of configMapRef or secretRef to populate environment variables.

Why this answer

The `envFrom` field in the container spec allows you to inject all key-value pairs from a ConfigMap (or Secret) as environment variables into the container. This is the most direct and efficient way to expose ConfigMap data as environment variables without needing to specify each key individually.

Exam trap

The trap here is that candidates often confuse `envFrom` with `env` or `volumeMounts`, thinking that mounting a ConfigMap as a volume or using individual `env` entries is the only way to expose its data, but `envFrom` is the specific field designed for bulk injection of ConfigMap keys as environment variables.

How to eliminate wrong answers

Option A is wrong because `spec.volumes` defines volumes at the pod level, not environment variables; it is used for mounting data as files. Option B is wrong because `spec.containers[].volumeMounts` mounts a volume into a container's filesystem, not into environment variables. Option D is wrong because `spec.containers[].env` is used to set individual environment variables explicitly, but it does not automatically pull all data from a ConfigMap; it requires manual mapping of each key using `valueFrom`.

Full explanation →

304

MCQmedium

Which Kubernetes controller ensures that a specified number of pod replicas are running at all times?

A.ReplicaSet

B.Job

C.ReplicationController

D.DaemonSet

AnswerA

Why this answer

A ReplicaSet is the Kubernetes controller that ensures a specified number of pod replicas are running at all times. It uses a label selector to match pods and maintains the desired replica count by creating or deleting pods as needed. ReplicaSet is the successor to ReplicationController and is primarily used by Deployments to manage pod scaling and self-healing.

Exam trap

CNCF often tests the distinction between ReplicaSet and ReplicationController, trapping candidates who think ReplicationController is still the primary controller for replica management, when in fact ReplicaSet is the modern, recommended controller.

How to eliminate wrong answers

Option B is wrong because a Job controller is designed to run a specified number of pods to completion, not to maintain a continuous replica count. Option C is wrong because ReplicationController is the older, deprecated controller that also ensures a specified number of pod replicas, but it has been superseded by ReplicaSet with more flexible label selectors; however, the question asks for the current correct answer, and ReplicaSet is the standard. Option D is wrong because a DaemonSet ensures that a copy of a pod runs on every node (or a subset of nodes), not a specified number of replicas cluster-wide.

Full explanation →

305

MCQeasy

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

A.Shared database schema for all services

B.Tight coupling between services

C.Loose coupling and independent deployability

D.Building a large, monolithic codebase

AnswerC

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

Why this answer

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

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

Full explanation →

306

Multi-Selecthard

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

Select 3 answers

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

B.Change the number of replicas

C.Update the container image to a new version

D.Modify the environment variables in the pod spec

E.Edit the deployment's labels

AnswersC, D, E

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

Why this answer

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

Exam trap

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

Full explanation →

307

MCQmedium

When creating a Deployment, you want to ensure that only a certain number of pods run at a time across all nodes. Which field in the Deployment spec controls this?

A.spec.replicas

B.spec.selector

C.spec.minReadySeconds

D.spec.template

AnswerA

spec.replicas sets the desired number of pods.

Why this answer

The `spec.replicas` field in a Deployment spec defines the desired number of identical Pod replicas that should be running at any given time. This field directly controls the count of Pods across all nodes in the cluster, ensuring that exactly that many Pods are maintained by the ReplicaSet controller. Option A is correct because it is the only field that sets the target Pod count.

Exam trap

The trap here is that candidates confuse `spec.replicas` with `spec.selector`, thinking the selector controls the number of Pods, but the selector only determines which Pods are managed, not how many.

How to eliminate wrong answers

Option B is wrong because `spec.selector` defines a label query used to identify which Pods the Deployment manages, not the number of Pods. Option C is wrong because `spec.minReadySeconds` controls the minimum time a Pod must be ready before it is considered available, not the number of Pods. Option D is wrong because `spec.template` defines the Pod template (containers, volumes, etc.) used to create new Pods, not the desired count.

Full explanation →

308

MCQmedium

A developer has created a Deployment with 3 replicas. The application should be reachable from other Pods within the same cluster. Which Kubernetes resource should be used to provide a stable network endpoint?

A.Ingress

B.Service

C.PersistentVolumeClaim

D.ConfigMap

AnswerB

Services provide stable endpoints for Pod communication.

Why this answer

A Service provides a stable network endpoint (ClusterIP) that load-balances traffic across the Pod replicas, abstracting away Pod IP changes due to restarts or scaling. This allows other Pods within the cluster to reach the application reliably using the Service's DNS name, without needing to track individual Pod IPs.

Exam trap

CNCF often tests the misconception that an Ingress is required for any network access, but the trap here is that Ingress is only for external (north-south) traffic, while internal Pod-to-Pod communication uses a Service.

How to eliminate wrong answers

Option A is wrong because an Ingress is an API object that manages external HTTP/HTTPS access to Services, not internal cluster communication; it requires a Service to route traffic to Pods. Option C is wrong because a PersistentVolumeClaim is used to request storage resources, not to provide a network endpoint for Pod-to-Pod communication. Option D is wrong because a ConfigMap is used to inject configuration data (e.g., environment variables, files) into Pods, not to expose a stable network address.

Full explanation →

309

MCQmedium

What is the primary function of a service mesh like Istio?

A.To build container images

B.To handle inter-service communication with features like traffic control and security

C.To manage container orchestration

D.To provide persistent storage for stateful applications

AnswerB

Service mesh adds a dedicated infrastructure layer for managing service-to-service communication.

Why this answer

A service mesh provides observability, traffic management, and security for microservices communication.

Full explanation →

310

MCQmedium

You need to store a sensitive database password in Kubernetes. Which resource should you use?

A.PersistentVolume

B.ConfigMap

C.ServiceAccount

D.Secret

AnswerD

Secret is intended for sensitive data.

Why this answer

A Secret is the correct Kubernetes resource for storing sensitive data like database passwords because it encodes the data in base64 and is designed to be consumed securely by pods, with access controlled via RBAC. Unlike ConfigMaps, Secrets are not intended for non-sensitive configuration and provide a layer of separation for confidential information.

Exam trap

The most common mistake is selecting ConfigMap instead of Secret, because both can hold key-value data, but Secret is designed for sensitive information and provides base64 encoding as a basic security measure, while ConfigMap is for non-sensitive configuration.

How to eliminate wrong answers

Option A is wrong because a PersistentVolume is a storage abstraction for persistent data (e.g., files) and is not designed to store small, sensitive configuration values like passwords. Option B is wrong because a ConfigMap stores non-sensitive configuration data in plain text (or base64 if manually encoded) and lacks the security context and RBAC controls that Secrets provide for sensitive information. Option C is wrong because a ServiceAccount is an identity for pods to authenticate to the Kubernetes API server, not a resource for storing secrets or passwords.

Full explanation →

311

MCQmedium

A pod is experiencing high memory usage. The administrator wants to enforce that the pod is terminated if it exceeds a memory limit and restarted automatically, but also wants to guarantee a minimum amount of memory for the pod. Which resource specification should be used in the container definition?

A.spec.containers[].resources.requests.memory only

B.spec.containers[].resources.limits.memory and requests.cpu

C.spec.containers[].resources.limits.memory only

D.spec.containers[].resources.requests.memory and limits.memory

AnswerD

Requests guarantee the minimum; limits cap the maximum. If memory exceeds limits, the pod is OOMKilled and restarted.

Why this answer

Setting both `requests.memory` and `limits.memory` guarantees a minimum memory allocation (the request) while enforcing a hard cap (the limit). If the pod exceeds the memory limit, it is terminated (OOMKilled) and, if part of a Deployment or StatefulSet, the controller automatically restarts it. This satisfies the requirement for both guaranteed minimum and enforced maximum with automatic restart.

Exam trap

CNCF often tests the misconception that setting only `limits.memory` is sufficient for both guarantee and enforcement, but without `requests.memory` the pod has no guaranteed minimum and may be evicted under node pressure, failing the 'guarantee a minimum' requirement.

How to eliminate wrong answers

Option A is wrong because `requests.memory` only sets the minimum guaranteed memory but does not enforce any upper limit; the pod could consume unlimited memory and cause node instability. Option B is wrong because `limits.memory` and `requests.cpu` do not address memory limits at all — `requests.cpu` only guarantees CPU, not memory, so the pod could still exceed memory without being terminated. Option C is wrong because `limits.memory` alone enforces a hard cap but does not guarantee a minimum memory allocation; the pod could be starved or evicted if the node is under pressure, failing the 'guarantee a minimum amount of memory' requirement.

Full explanation →

312

MCQhard

A microservice application is experiencing high latency during traffic spikes. The team identifies that the database connection pool is exhausted. They want to implement a pattern that helps decouple the microservice from direct database connections and smooth out traffic bursts. Which design pattern should they apply?

A.Bulkhead pattern

B.Circuit Breaker pattern

C.Queue-based Load Leveling pattern

D.Retry pattern

AnswerC

A message queue buffers requests, decouples services, and smooths traffic spikes.

Why this answer

The Queue-based Load Leveling pattern uses a message queue (e.g., RabbitMQ, Amazon SQS) as a buffer between the microservice and the database. When traffic spikes occur, requests are queued and processed at a manageable rate, preventing the database connection pool from being exhausted. This decouples the service from direct database connections and smooths out bursts, directly addressing the latency issue.

Exam trap

CNCF often tests the distinction between patterns that handle failures (Circuit Breaker, Retry) versus patterns that manage load (Queue-based Load Leveling), and the trap here is that candidates confuse 'smoothing traffic bursts' with 'preventing repeated failures,' leading them to pick the Circuit Breaker or Retry pattern incorrectly.

How to eliminate wrong answers

Option A is wrong because the Bulkhead pattern isolates resources (e.g., thread pools) within a service to prevent cascading failures, but it does not buffer traffic spikes or decouple from database connections. Option B is wrong because the Circuit Breaker pattern monitors for failures and opens the circuit to stop requests temporarily, but it does not smooth out traffic bursts or prevent connection pool exhaustion during spikes. Option D is wrong because the Retry pattern automatically retries failed operations, but it can exacerbate connection pool exhaustion by adding more load during traffic spikes, not decouple or level the load.

Full explanation →

313

MCQmedium

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

A.The pod's liveness probe is failing

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

C.The pod's container runtime is not installed

D.The pod's image pull secret is missing

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

314

MCQmedium

In distributed tracing, what is a 'span'?

A.A metric measuring request latency

B.A single logical operation within a trace

C.A collection of related traces

D.A log entry with trace context

AnswerB

A span represents one operation, such as a function call or a request.

Why this answer

A span represents a unit of work in a distributed system, often a single operation like an HTTP request or database call.

Full explanation →

315

MCQmedium

A developer creates a Deployment with 3 replicas. The developer runs 'kubectl get pods' immediately after creation and sees that only 1 pod is in Running state, and the other 2 are Pending. What is the most likely reason for this?

A.The cluster does not have enough resources (CPU/memory) to schedule the additional pods

B.The Deployment's YAML has a syntax error

C.The container image is not available on the worker nodes

D.The kubelet on the node is not running

AnswerA

If nodes lack sufficient resources, new pods remain Pending until resources become available or are released.

Why this answer

When a Pod remains in Pending state, it indicates that the scheduler cannot find a suitable node to place it. The most common cause is insufficient cluster resources (CPU or memory) to accommodate the additional Pods, as the scheduler checks node allocatable resources against Pod resource requests. With 2 out of 3 Pods pending, the cluster likely has enough resources for only one replica, leaving the others unscheduled.

Exam trap

CNCF often tests the distinction between Pod lifecycle phases — Pending means scheduling failure, not image or runtime issues — so candidates mistakenly associate Pending with image pull errors or node problems rather than resource insufficiency.

How to eliminate wrong answers

Option B is wrong because a syntax error in the Deployment YAML would cause the API server to reject the resource creation entirely, resulting in no Pods being created at all, not a mix of Running and Pending Pods. Option C is wrong because if the container image were unavailable, the Pods would transition to ImagePullBackOff or ErrImagePull state, not remain Pending — Pending means scheduling hasn't occurred yet. Option D is wrong because if the kubelet were not running on a node, that node would be marked as NotReady, but the scheduler would still attempt to schedule Pods to other nodes; the issue here is that no node has enough resources, not that a node is offline.

Full explanation →

316

Multi-Selectmedium

Which two of the following are valid ways to expose a Deployment externally to the internet? (Select TWO)

Select 2 answers

A.Create a Service of type ClusterIP

B.Create an Ingress resource

C.Create a Service of type LoadBalancer

D.Create a Headless Service

E.Create a Service of type NodePort

AnswersC, E

LoadBalancer provisions an external load balancer and assigns a public IP.

Why this answer

A Service of type LoadBalancer provisions an external load balancer (e.g., in cloud environments like AWS, GCP, or Azure) that assigns a public IP or DNS name, making the Deployment directly accessible from the internet. This is a standard method for exposing services externally in Kubernetes.

Exam trap

The trap here is that candidates often confuse Ingress as a standalone external exposure method, forgetting that Ingress requires a backing Service (typically NodePort or LoadBalancer) to actually route traffic from the internet.

Full explanation →

317

Multi-Selectmedium

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

Select 2 answers

A.Containers are more lightweight and start faster than VMs

B.Containers include a full guest operating system

C.Containers are more portable across different environments

D.Containers provide stronger isolation than VMs

E.Containers require a hypervisor to run

AnswersA, C

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

Why this answer

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

Exam trap

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

Full explanation →

318

MCQmedium

Which component is responsible for aggregating metrics from Kubernetes nodes and exposing them to the metrics API?

A.Prometheus Server

B.Grafana

C.metrics-server

D.Fluentd

AnswerC

Correct. The metrics-server is a cluster-wide aggregator of resource usage data.

Why this answer

The metrics-server is the correct component because it is specifically designed to collect resource metrics (CPU and memory) from the kubelet on each node via the Summary API and expose them through the Kubernetes Metrics API. This allows tools like `kubectl top` and the Horizontal Pod Autoscaler to access real-time resource usage without requiring a full monitoring stack.

Exam trap

The trap here is that candidates often confuse Prometheus (a full monitoring system) with the metrics-server (a lightweight, Kubernetes-native component for the Metrics API), assuming Prometheus is required for `kubectl top` or HPA when in fact the metrics-server is the dedicated and simpler solution.

How to eliminate wrong answers

Option A is wrong because Prometheus Server is a full monitoring and alerting system that scrapes metrics from various endpoints, but it is not the component responsible for aggregating metrics from nodes and exposing them to the Kubernetes Metrics API; it typically scrapes the metrics-server or kubelet directly. Option B is wrong because Grafana is a visualization and dashboarding tool that queries data sources like Prometheus or metrics-server, but it does not aggregate or expose metrics to the Metrics API. Option D is wrong because Fluentd is a log collector and forwarder used for log aggregation, not for collecting or exposing resource metrics to the Kubernetes Metrics API.

Full explanation →

319

MCQeasy

An organization wants to adopt a cloud-native approach for its new application. Which characteristic is most important for the application to be considered cloud-native?

A.It stores all state in local files on the container filesystem.

B.It is designed to be resilient, scalable, and manageable in a dynamic environment.

C.It runs as a single monolithic process for simplicity.

D.It is deployed exclusively on on-premises infrastructure.

AnswerB

Resilience, scalability, and manageability are core cloud-native characteristics.

Why this answer

Cloud-native applications are fundamentally defined by their ability to operate in dynamic, distributed environments. They leverage principles like microservices, containerization, and orchestration (e.g., Kubernetes) to achieve resilience, scalability, and manageability. This characteristic is the core tenet of cloud-native architecture as defined by the CNCF, enabling the app to handle failures gracefully and scale on demand.

Exam trap

CNCF often tests the misconception that cloud-native simply means 'running in containers' or 'using Kubernetes,' but the defining characteristic is the architectural property of being resilient, scalable, and manageable in a dynamic environment, not the deployment technology itself.

How to eliminate wrong answers

Option A is wrong because storing state in local container filesystems violates the cloud-native principle of statelessness; containers are ephemeral, and local state is lost on restart, making the application non-resilient and unscalable. Option C is wrong because a monolithic process contradicts the cloud-native preference for microservices, which allow independent scaling, deployment, and fault isolation; monoliths become bottlenecks in dynamic environments. Option D is wrong because cloud-native applications are designed to be infrastructure-agnostic and typically run in multi-cloud or hybrid environments, not exclusively on-premises; being tied to on-premises infrastructure limits portability and cloud benefits.

Full explanation →

320

MCQeasy

In GitOps with ArgoCD, what does 'self-healing' refer to?

A.Automatically scaling applications based on metrics

B.Automatically restarting failed pods

C.Automatically reverting manual changes to match the Git repository

D.Automatically updating the Git repository when changes are made in the cluster

AnswerC

Self-healing ensures the cluster state continuously matches the Git repository, undoing any drift.

Why this answer

Self-healing automatically reverts any manual changes made to the live cluster state back to the desired state defined in Git, ensuring configuration drift is corrected.

Full explanation →

321

MCQhard

A pod has resource requests: cpu: 250m, memory: 512Mi and limits: cpu: 500m, memory: 1Gi. If the container tries to use 600m CPU and 700Mi memory, what will happen?

A.The container will be allowed to use the extra resources because limits are only soft constraints

B.The container will be throttled for CPU and may be terminated if it continues to exceed the limit

C.The container will be throttled for CPU, but will not be killed because memory is within limits

D.The container will be killed immediately because it exceeded its CPU limit

AnswerC

CPU above limit -> throttled; memory below limit -> no OOM kill.

Why this answer

CPU is a compressible resource: exceeding the CPU limit (500m) causes throttling, not termination. Memory is a non-compressible resource, and since the container's memory usage (700Mi) is below its limit (1Gi), it will not be killed. The container will be CPU-throttled but allowed to continue running.

Exam trap

The trap here is that candidates often confuse compressible (CPU) and non-compressible (memory) resources, incorrectly assuming that exceeding any limit leads to termination, whereas CPU only causes throttling and memory causes termination.

How to eliminate wrong answers

Option A is wrong because Kubernetes limits are hard constraints enforced by the kubelet and container runtime, not soft constraints; exceeding CPU limits causes throttling, and exceeding memory limits can cause termination. Option B is wrong because while the container will be throttled for CPU, it will not be terminated solely for exceeding the CPU limit; termination only occurs for memory limit violations or other OOM scenarios. Option D is wrong because CPU limits do not cause immediate termination; the container is throttled at the cgroup level, and only memory limit violations lead to OOM kills.

Full explanation →

322

MCQhard

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 4 Insufficient memory'. What is the most likely cause?

A.All nodes have taints that the pod cannot tolerate

B.The pod's liveness probe is failing

C.The container image is not found

D.The pod requires more memory than any node can allocate

AnswerD

The error indicates no node has enough available memory.

Why this answer

The error message '0/4 nodes are available: 4 Insufficient memory' directly indicates that the pod's memory request exceeds the allocatable memory on every node in the cluster. The Kubernetes scheduler evaluates resource requests (spec.containers[].resources.requests.memory) against node capacity, and if no node can satisfy the request, the pod remains in Pending state.

Exam trap

Kubernetes certification exams often test the distinction between scheduling failures (Pending) and runtime errors (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly associate image or probe issues with Pending state instead of recognizing the scheduler's resource check.

How to eliminate wrong answers

Option A is wrong because taints and tolerations produce a different error message, such as '0/4 nodes are available: 4 node(s) had taint {key:value} that the pod didn't tolerate', not 'Insufficient memory'. Option B is wrong because a failing liveness probe would cause the pod to be restarted or become CrashLoopBackOff, not stuck in Pending; Pending occurs before the pod is scheduled to a node. Option C is wrong because an image-not-found error results in ErrImagePull or ImagePullBackOff after scheduling, not a Pending state with a scheduling failure message.

Full explanation →

323

MCQhard

A DevOps engineer wants to ensure that a critical application pod is rescheduled on a different node if its current node fails. The pod should be scheduled with a preference for nodes in a specific availability zone but can run elsewhere if needed. Which scheduling mechanism should be used?

A.Use a StatefulSet with podAntiAffinity.

B.Use a Deployment with a preferred nodeAffinity rule.

C.Run a static pod defined in the kubelet configuration.

D.Create a DaemonSet with a nodeSelector for the zone.

AnswerB

Correct; Deployment ensures rescheduling via ReplicaSet, nodeAffinity provides preference.

Why this answer

A Deployment with a preferred nodeAffinity rule is correct because it allows the pod to be rescheduled on a different node if the current node fails, while expressing a preference for nodes in a specific availability zone. The 'preferred' (soft) rule ensures scheduling flexibility—the pod can run elsewhere if no zone-matching nodes are available—which aligns with the requirement for high availability without strict zone constraints.

Exam trap

The trap here is that candidates confuse 'preferred' (soft) nodeAffinity with 'required' (hard) nodeAffinity, or mistakenly think DaemonSets or StatefulSets are needed for node failure recovery, when a simple Deployment with a soft scheduling preference is the correct mechanism for zone-aware rescheduling.

How to eliminate wrong answers

Option A is wrong because a StatefulSet with podAntiAffinity controls pod placement relative to other pods (e.g., spreading replicas across nodes), not rescheduling behavior after node failure, and does not express zone preference. Option C is wrong because a static pod is managed directly by the kubelet on a specific node and cannot be rescheduled to a different node if that node fails—it is tied to the node's lifecycle. Option D is wrong because a DaemonSet runs exactly one pod per node by default, which is not suitable for a single critical application pod, and nodeSelector enforces a hard constraint (not a preference) that would prevent scheduling if no zone-matching nodes exist.

Full explanation →

324

Drag & Dropmedium

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

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

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

Full explanation →

325

Multi-Selecthard

Which THREE of the following are benefits of using an event-driven architecture? (Choose three.)

Select 3 answers

A.Simpler debugging and tracing

B.Better resilience through decoupled components

C.Improved scalability through asynchronous processing

D.Reduced need for monitoring

E.Loose coupling between services

AnswersB, C, E

Failure in one component does not directly affect others.

Why this answer

Event-driven architecture enables loose coupling, scalability, and asynchronous processing.

Full explanation →

326

MCQhard

A pod is running but you need to view the contents of a file '/var/log/app.log' inside the container to debug an issue. Which kubectl command allows you to do this without modifying the pod?

A.kubectl logs pod-name -c container-name --tail=100

B.kubectl cp pod-name:/var/log/app.log -

C.kubectl exec pod-name -- cat /var/log/app.log

D.kubectl attach pod-name

AnswerC

Executes 'cat' inside the container to display the file.

Why this answer

`kubectl exec pod-name -- cat /var/log/app.log` runs the `cat` command inside the container without modifying the pod or its state. This allows you to view the file contents directly from the container's filesystem, which is essential for debugging when the application logs are not written to stdout/stderr and thus not accessible via `kubectl logs`.

Exam trap

The trap here is that candidates often confuse `kubectl logs` with reading arbitrary files, assuming it can retrieve any log file, when in fact it only captures container stdout/stderr streams, while `kubectl exec` is the correct tool for accessing files inside a container.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` only retrieves logs written to the container's stdout/stderr streams, not arbitrary files like `/var/log/app.log`. Option B is wrong because `kubectl cp` is used to copy files between a pod and the local machine, but the syntax shown (`kubectl cp pod-name:/var/log/app.log -`) is incomplete and would fail; the correct usage requires a local destination path, and even then it modifies the pod's filesystem only if copying into the pod, but here it attempts to copy out, which does not modify the pod but the command as given is invalid. Option D is wrong because `kubectl attach` attaches to the container's main process (usually PID 1) and streams its stdout/stderr, which does not allow you to read an arbitrary file and typically interferes with the running process.

Full explanation →

327

Multi-Selecthard

Which three components are part of the Kubernetes control plane? (Select THREE)

Select 3 answers

A.etcd

B.kube-apiserver

C.kube-proxy

D.kube-controller-manager

E.kubelet

AnswersA, B, D

etcd stores cluster state.

Why this answer

etcd is a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data. It stores the entire cluster state, including configuration, secrets, and metadata, and is a core component of the control plane because the API server reads from and writes to it to maintain cluster integrity.

Exam trap

CNCF often tests the distinction between control plane and worker node components, and the trap here is that candidates confuse kube-proxy or kubelet as control plane components because they are essential to cluster operation, but they actually run on every node and are not part of the control plane.

Full explanation →

328

MCQhard

A team uses Argo Rollouts for progressive delivery. They configure a canary rollout with a traffic split of 20% to the new version. After verification, the rollout automatically increases traffic to 100%. Which Argo Rollout manifest field controls this gradual traffic increase?

A.strategy.canary.trafficRouting

B.strategy.canary.steps

C.template.spec.containers

D.spec.replicas

AnswerB

Why this answer

The steps field in an Argo Rollout defines the sequence of canary steps, including traffic percentages. Option B (strategy.canary.steps) is correct. Option A (strategy.canary.trafficRouting) configures how traffic routing is done (e.g., with a service mesh).

Option C (spec.replicas) sets the total replicas. Option D (template.spec.containers) defines containers.

Full explanation →

329

MCQeasy

Which Kubernetes control plane component is responsible for maintaining the desired state of the cluster, such as ensuring the correct number of pods are running?

A.kube-controller-manager

B.kube-apiserver

C.kube-scheduler

D.etcd

AnswerA

The controller manager runs controllers (e.g., replication controller) to ensure the current state matches the desired state.

Why this answer

The kube-controller-manager is the control plane component that runs controller processes, including the Replication Controller, which is responsible for ensuring that the desired number of pod replicas are running at all times. It continuously watches the state of the cluster via the kube-apiserver and makes adjustments to reconcile the current state with the desired state defined in the cluster's configuration.

Exam trap

CNCF often tests the distinction between the component that stores state (etcd) and the component that actively reconciles state (kube-controller-manager), leading candidates to mistakenly choose etcd because it holds the desired state data.

How to eliminate wrong answers

Option B is wrong because the kube-apiserver is the front-end for the Kubernetes control plane that exposes the Kubernetes API, handling authentication, authorization, and API requests, but it does not directly manage the desired state of pods or other resources. Option C is wrong because the kube-scheduler is responsible for assigning newly created pods to nodes based on resource availability and constraints, not for maintaining the desired number of running pods. Option D is wrong because etcd is a distributed key-value store that holds the cluster's configuration and state data, but it is a data store, not a controller that actively reconciles desired state.

Full explanation →

330

MCQhard

An application requires a unique identifier per replica, stored in an environment variable. Which Kubernetes resource should be used to inject this identifier into each pod without manual updates?

A.Deployment with pod anti-affinity to schedule each pod on a different node.

B.StatefulSet with an environment variable derived from the pod name.

C.DaemonSet with a node name environment variable.

D.Job with a completion index environment variable.

AnswerB

StatefulSet pods have stable, unique names (e.g., myapp-0).

Why this answer

A StatefulSet provides stable, unique network identities and ordered pod naming (e.g., pod-0, pod-1). The pod name can be exposed as an environment variable using the Downward API or Kubernetes hostname field, giving each replica a unique identifier without manual updates. Deployments create identical pods with no ordering, DaemonSets run one pod per node, and Jobs are for batch processing, so only a StatefulSet meets the requirement.

Full explanation →

331

MCQmedium

Which of the following is a key principle of the 12-factor app methodology?

A.Treat logs as event streams

B.Bind services at build time

C.Use local disk storage for persistence

D.Store configuration in the codebase

AnswerA

Logs should be emitted as event streams and not be concerned with routing or storage.

Why this answer

The 12-factor app includes the principle of treating logs as event streams, not as files.

Full explanation →

332

MCQmedium

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

A.kubectl get pods --namespace=*

B.kubectl get pods --global

C.kubectl get pods --all-namespaces

D.kubectl get pods --include-uninitialized

AnswerC

This lists pods in all namespaces.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

333

MCQeasy

Which DORA metric measures the percentage of deployments that cause a failure in production?

A.Deployment Frequency

B.Mean Time to Recovery (MTTR)

C.Change Failure Rate

D.Lead Time for Changes

AnswerC

This measures the percentage of changes that result in a failure in production.

Why this answer

Change Failure Rate is the percentage of changes that result in a failure (e.g., service degradation, rollback). It is one of the four key DORA metrics.

Full explanation →

334

Multi-Selecthard

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

Select 3 answers

A.Independent deployment of services

B.Decomposition by business capability

C.Single monolithic codebase

D.Shared database schema across services

E.Loose coupling between services

AnswersA, B, E

Each microservice can be deployed independently.

Why this answer

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

Exam trap

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

Full explanation →

335

MCQmedium

In a blue-green deployment strategy, at any given time, only one environment (blue or green) is active. What is the primary advantage of this approach?

A.Gradual traffic shifting to detect issues early

B.Instant rollback by switching traffic back to the previous environment

C.Minimal resource consumption by using only one environment

D.No need for load balancers or ingress controllers

AnswerB

Why this answer

Blue-green deployments allow instant rollback by switching traffic back to the previous environment. This is the primary advantage: if issues arise in the new version, you can immediately revert by pointing the router/load balancer to the old environment. Option A describes gradual traffic shifting, which is characteristic of canary deployments, not blue-green.

Option C is incorrect because blue-green requires two full environments, doubling resource consumption. Option D is false because a load balancer or ingress controller is essential to switch traffic between the two environments.

Full explanation →

336

MCQeasy

Which of the following is NOT one of the three pillars of observability in cloud-native environments?

A.Metrics

B.Traces

C.Security

D.Logs

AnswerC

Security is not one of the three pillars.

Why this answer

The three pillars are logs, metrics, and traces. Security is not one of them, though it is important.

Full explanation →

337

MCQhard

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

A.DaemonSet

B.Job

C.StatefulSet

D.Deployment

AnswerA

DaemonSet runs a pod on each node.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

338

MCQmedium

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

A.Service

B.NetworkPolicy

C.Ingress

D.ConfigMap

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

339

MCQmedium

What is the role of etcd in a Kubernetes cluster?

A.It serves as the container runtime

B.It stores cluster state and configuration

C.It provides DNS-based service discovery

D.It schedules pods onto nodes

AnswerB

etcd is the cluster's backing store.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

340

Multi-Selectmedium

Which TWO components are part of the Kubernetes control plane?

Select 2 answers

A.kube-proxy

B.kubelet

C.etcd

D.kube-apiserver

E.container runtime

AnswersC, D

etcd is the control plane's key-value store.

Why this answer

C (etcd) is correct because it is the distributed key-value store that holds all cluster data, including configuration, state, and metadata. D (kube-apiserver) is correct because it is the front-end for the control plane, exposing the Kubernetes API and handling all RESTful requests for cluster operations.

Exam trap

The KCNA exam often tests the misconception that kubelet or kube-proxy are control plane components because they are essential for cluster operation, but they actually run on every node as part of the data plane.

Full explanation →

341

MCQhard

Which of the following is a benefit of using an API gateway pattern?

A.It reduces the number of microservices needed

B.It replaces the need for a service mesh

C.It provides a single entry point for clients and handles cross-cutting concerns

D.It stores application state

AnswerC

API gateway centralizes routing, auth, rate limiting, etc.

Why this answer

API gateway can offload cross-cutting concerns like authentication from individual microservices.

Full explanation →

342

Drag & Dropmedium

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

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

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

Full explanation →

343

MCQmedium

You run 'kubectl get pods' and see a Pod in the 'Pending' state. Which of the following is a likely cause?

A.No node meets the requested CPU or memory resources

B.The application crashed due to a bug

C.The container image is missing

D.The Pod has been deleted

AnswerA

Insufficient resources on any node can cause Pending state.

Why this answer

A Pod enters the 'Pending' state when it cannot be scheduled onto a node. The most common reason is that no node in the cluster has sufficient available CPU or memory resources to satisfy the Pod's resource requests. The Kubernetes scheduler continuously evaluates nodes against Pod resource requirements, and if none match, the Pod remains unscheduled in Pending.

Exam trap

The trap here is confusing 'Pending' (scheduling failure) with 'CrashLoopBackOff' (runtime failure) or 'ImagePullBackOff' (image pull failure), leading candidates to pick a wrong answer about application or image issues.

How to eliminate wrong answers

Option B is wrong because an application crash due to a bug would cause the Pod to enter a CrashLoopBackOff or Error state, not Pending. Option C is wrong because a missing container image would result in an ImagePullBackOff or ErrImagePull state, not Pending. Option D is wrong because a deleted Pod would not appear in the output of 'kubectl get pods' at all; it would be removed from the API server.

Full explanation →

344

MCQhard

A cloud-native application uses a service mesh (Istio) for traffic management. The team notices increased latency in inter-service communication. Which likely cause should be investigated first?

A.Kubernetes Network Policies blocking traffic

B.Misconfigured sidecar proxy settings

C.Application code is not optimized for the mesh

D.mTLS encryption overhead

AnswerB

Can cause significant latency.

Why this answer

In Istio, the sidecar proxy (Envoy) intercepts all inbound and outbound traffic for the application container. Misconfigured proxy settings—such as incorrect timeouts, retry policies, or circuit breaker thresholds—can introduce significant latency by causing unnecessary retries, connection delays, or queueing. This is the most common and immediate cause of increased latency in a service mesh, as the data plane is directly in the request path.

Exam trap

CNCF often tests the misconception that mTLS encryption is a major source of latency, but in practice its overhead is negligible compared to misconfigured proxy settings that directly impact request handling.

How to eliminate wrong answers

Option A is wrong because Kubernetes Network Policies operate at the IP/port level and would block traffic entirely rather than cause increased latency; they do not introduce gradual performance degradation. Option C is wrong because application code optimization is a separate concern—the service mesh handles traffic management at the infrastructure layer, and unoptimized code would cause latency regardless of the mesh. Option D is wrong because mTLS encryption overhead in Istio is minimal (typically under 5% latency increase) and is a known, accepted cost of zero-trust security; it would not be the first suspect for a noticeable latency spike.

Full explanation →

345

MCQmedium

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

A.To manage service-to-service communication within a cluster

B.To replace DNS for service discovery

C.To act as a single entry point for external clients

D.To directly connect databases to clients

AnswerC

Why this answer

An API gateway acts as a single entry point for clients, routing requests to appropriate microservices and providing cross-cutting concerns like authentication and rate limiting.

Full explanation →

346

MCQmedium

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

A.Certifying Kubernetes administrators

B.Providing a hosted container registry

C.Defining standards for container images and runtimes

D.Managing the Kubernetes source code

AnswerC

OCI oversees the image spec and runtime spec.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

347

Multi-Selectmedium

Which TWO of the following are benefits of using a Deployment over managing ReplicaSets directly? (Choose two.)

Select 2 answers

A.Support for stateful workloads

B.Declarative scaling

C.Direct access to pod IP addresses

D.Automatic rolling updates and rollbacks

E.Ability to run a pod on every node

AnswersB, D

Deployments allow you to declaratively set replica count.

Why this answer

Deployments provide a higher-level abstraction that manages ReplicaSets, enabling declarative scaling by simply updating the `replicas` field in the Deployment manifest. This allows Kubernetes to automatically adjust the number of pods without manual ReplicaSet edits, ensuring the desired state is maintained.

Exam trap

A common misconception is that Deployments are suitable for stateful workloads or provide direct pod networking, when in fact StatefulSets and Services are the correct solutions for those needs.

Full explanation →

348

Multi-Selecthard

Which THREE of the following are important considerations when defining SLOs (Service Level Objectives)? (Select three.)

Select 3 answers

A.They should include an error budget

B.They must be aligned with business impact

C.They must be based on measurable SLIs

D.They define a target percentage over a time window

E.They should minimize infrastructure cost

AnswersB, C, D

SLOs should reflect what matters to users and business.

Why this answer

SLOs should be based on SLIs, define a target (e.g., 99.9%), and include a measurement window. Cost is not a direct consideration for SLO definition.

Full explanation →

349

Multi-Selectmedium

Which TWO statements are true about cloud-native architecture?

Select 2 answers

A.Applications are typically monolithic for simplicity

B.Infrastructure is treated as immutable

C.Manual scaling is the default approach

D.Services can be scaled independently

E.Stateful components are preferred for performance

AnswersB, D

Immutable infrastructure provides consistency.

Why this answer

Immutable infrastructure (e.g., replacing servers rather than patching) ensures consistency and reduces configuration drift, a key cloud-native principle. Option D is correct because microservices in cloud-native architectures are designed to be independently scalable, allowing efficient resource use. Option A is wrong because cloud-native applications typically use microservices, not monolithic architectures.

Option C is wrong because cloud-native environments favor automated scaling (horizontal pod autoscaling, etc.) over manual scaling. Option E is wrong because stateful components introduce complexity and are generally avoided unless necessary; stateless components are preferred for scalability and resilience.

Full explanation →

350

MCQhard

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

A.The pod is running on a different node

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

C.The container name is misspelled

D.The pod is in a CrashLoopBackOff state

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

351

MCQeasy

What is the primary purpose of a liveness probe in a container?

A.To check resource usage like CPU and memory

B.To check if the container is still alive; restart if not

C.To check if the container is ready to serve traffic

D.To check if the pod is scheduled on the correct node

AnswerB

Correct. Liveness probes restart containers that become unresponsive.

Why this answer

The primary purpose of a liveness probe is to determine whether a container is still running and healthy. If the probe fails, the kubelet kills the container and restarts it according to the pod's restart policy, ensuring self-healing. This is distinct from readiness probes, which control traffic routing, and resource checks, which are handled by metrics servers or cAdvisor.

Exam trap

The trap here is that candidates confuse liveness probes with readiness probes, often selecting option C because both involve health checks, but liveness probes manage container lifecycle while readiness probes manage traffic routing.

How to eliminate wrong answers

Option A is wrong because checking resource usage like CPU and memory is the job of the metrics server or cAdvisor, not a liveness probe; liveness probes only test application responsiveness via HTTP, TCP, or exec commands. Option C is wrong because checking if the container is ready to serve traffic is the purpose of a readiness probe, which controls whether the pod is added to Service endpoints; a liveness probe does not affect traffic routing. Option D is wrong because checking if the pod is scheduled on the correct node is handled by the Kubernetes scheduler and node affinity rules, not by a liveness probe, which operates at the container level within an already-scheduled pod.

Full explanation →

352

Multi-Selectmedium

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

Select 2 answers

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

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

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

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

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

AnswersA, B

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

Why this answer

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

Exam trap

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

Full explanation →

353

MCQmedium

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

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

B.To replace Docker as the only supported runtime

C.To define the format of container images

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

354

MCQhard

A StatefulSet named 'web' with 3 replicas is deployed in the 'production' namespace. The first two pods are running, but the third pod 'web-2' is pending with the error shown. What is the most likely cause?

A.The StatefulSet requires a headless Service that does not exist

B.The pod anti-affinity rule prevents more than one pod per node, and there are only 3 nodes

C.The pod has a resource request that cannot be satisfied by any node

D.There are not enough nodes in the cluster to schedule the third pod

AnswerB

The scheduler cannot place web-2 because all nodes already have a pod from the same set.

Why this answer

The error indicates that the third pod 'web-2' is pending due to a scheduling conflict. Pod anti-affinity rules, when configured with a 'requiredDuringSchedulingIgnoredDuringExecution' policy, prevent more than one pod from the same StatefulSet from being scheduled on the same node. With only 3 nodes available and the first two pods already occupying distinct nodes, the third pod cannot be placed, causing it to remain pending.

Exam trap

The KCNA exam often tests the distinction between resource constraints and scheduling constraints (like anti-affinity), leading candidates to mistakenly choose 'not enough nodes' when the real issue is a rule that prevents using all available nodes.

How to eliminate wrong answers

Option A is wrong because a headless Service is required for stable network identities in a StatefulSet, but its absence would cause DNS resolution failures, not a scheduling/pending error. Option C is wrong because resource requests that cannot be satisfied would produce an 'Insufficient cpu' or 'Insufficient memory' event, not a generic pending error tied to node count. Option D is wrong because the cluster has exactly 3 nodes, which matches the replica count; the issue is not the number of nodes but the anti-affinity rule preventing co-location on the same node.

Full explanation →

355

MCQmedium

You need to run a batch job that processes a queue and then terminates. Which Kubernetes resource is most appropriate?

A.StatefulSet

B.Job

C.Deployment

D.DaemonSet

AnswerB

Jobs run Pods that perform a task and then terminate.

Why this answer

A Job is the correct resource because it is designed to run a specified number of pods to completion and then terminate, making it ideal for batch processing tasks like processing a queue. Unlike controllers that maintain a desired state indefinitely, a Job ensures the pod runs successfully to completion, even if the pod fails and needs to be restarted, and then stops.

Exam trap

CNCF often tests the distinction between controllers that maintain a desired state (Deployment, StatefulSet, DaemonSet) versus controllers that run to completion (Job), and the trap here is assuming that any workload that processes data must use a Deployment because it's the most common controller.

How to eliminate wrong answers

Option A is wrong because a StatefulSet is used for stateful applications that require stable, unique network identifiers and persistent storage, not for batch jobs that terminate. Option C is wrong because a Deployment is designed to maintain a desired number of replica pods running continuously, not to run a task to completion and then stop. Option D is wrong because a DaemonSet ensures that a copy of a pod runs on every node (or a subset of nodes) in the cluster, typically for cluster-level services like logging or monitoring, not for one-off batch processing.

Full explanation →

356

MCQeasy

A DevOps engineer needs to expose a set of pods running an HTTP API to external clients. The pods are stateless and should be load-balanced. Which Kubernetes resource should they use?

A.StatefulSet with a headless Service

B.Ingress resource without a Service

C.Service of type ClusterIP

D.Service of type LoadBalancer

AnswerD

LoadBalancer exposes the service externally and provides load balancing.

Why this answer

A Service of type LoadBalancer is the correct choice because it provisions an external load balancer (e.g., an AWS ELB or Azure LB) that distributes incoming traffic across the pods, exposing the stateless HTTP API to external clients. This resource automatically assigns a public IP and handles load balancing without requiring manual proxy configuration, making it ideal for external access to stateless workloads.

Exam trap

The trap here is that candidates often confuse 'exposing to external clients' with internal-only services, leading them to pick ClusterIP (C) or assume Ingress (B) can work without a Service, while the question explicitly requires load balancing for stateless pods, making LoadBalancer the direct and correct answer.

How to eliminate wrong answers

Option A is wrong because a StatefulSet is designed for stateful applications (e.g., databases) that require stable network identities and persistent storage, not for stateless HTTP APIs, and a headless Service does not provide load balancing or external exposure. Option B is wrong because an Ingress resource cannot function without a backing Service; it requires a Service (typically of type NodePort or LoadBalancer) to route traffic to pods, and it does not itself expose pods directly. Option C is wrong because a Service of type ClusterIP is only reachable within the cluster's internal network (e.g., via cluster IP 10.0.0.1) and cannot be accessed by external clients without additional components like a proxy or Ingress.

Full explanation →

357

MCQeasy

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

A.kube-scheduler

B.kube-controller-manager

C.kubelet

D.kube-apiserver

AnswerB

Correct. It runs controllers that reconcile desired state.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

358

MCQmedium

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

A.kubectl rollout restart deployment/<name>

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

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

D.kubectl edit deployment <name>

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

359

MCQeasy

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

A.containerd

B.Docker

C.runc

D.kubelet

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

360

MCQeasy

Which CNCF project is primarily focused on providing a unified way to define and manage cloud-native applications using declarative configuration stored in Git?

A.Helm

B.ArgoCD

C.Prometheus

D.Envoy

AnswerB

ArgoCD is a declarative GitOps CD tool for Kubernetes that synchronizes application state with Git repositories.

Why this answer

GitOps uses Git as the single source of truth for declarative infrastructure and application configuration. ArgoCD is a CNCF graduated project that implements GitOps for Kubernetes. Flux is also a GitOps tool but ArgoCD is more widely recognized as the primary GitOps project.

Full explanation →

361

MCQmedium

In GitOps with ArgoCD, what happens when the desired state in Git differs from the live state in the cluster?

A.ArgoCD reports an error and stops working

B.ArgoCD syncs the cluster to match Git if auto-sync is enabled

C.ArgoCD deletes the Git repository

D.ArgoCD automatically reverts the changes in Git

AnswerB

Auto-sync ensures cluster state matches Git.

Why this answer

ArgoCD detects drift and can automatically sync the cluster to match Git, enabling self-healing.

Full explanation →

362

MCQmedium

A team observes that a Pod is stuck in CrashLoopBackOff. The Pod runs a single container with an entrypoint that exits with non-zero code after a few seconds. The team wants to inspect the container's logs to understand why it is crashing. Which command should they use?

A.kubectl get pods

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

C.kubectl describe pod <pod-name>

D.kubectl exec -it <pod-name> -- sh

AnswerB

Shows logs from the previous container instance, useful for crash logs.

Why this answer

The `kubectl logs <pod-name> --previous` command retrieves the logs from the previous instance of a crashed container. Since the Pod is in CrashLoopBackOff, the current container has already exited, and the `--previous` flag accesses the logs of the last terminated container, which contains the crash output (e.g., the non-zero exit code and error messages). This is the direct way to see why the entrypoint failed.

Exam trap

CNCF often tests the distinction between `kubectl logs` (which shows container output) and `kubectl describe pod` (which shows events and status), leading candidates to choose describe when they need actual log content.

How to eliminate wrong answers

Option A is wrong because `kubectl get pods` only lists the Pods and their statuses (e.g., CrashLoopBackOff), but does not provide any logs or crash details. Option C is wrong because `kubectl describe pod <pod-name>` shows the Pod's metadata, events, and container status (including restart count and last exit code), but it does not show the container's stdout/stderr logs, which are needed to understand the crash reason. Option D is wrong because `kubectl exec -it <pod-name> -- sh` attempts to open a shell in a running container, but the container is crashing and not running, so the exec command will fail with an error like 'cannot exec into a container in a crashed state'.

Full explanation →

363

MCQmedium

In the context of distributed tracing, what is a 'span'?

A.A metric that measures request latency

B.A tool for collecting logs from containers

C.The entire end-to-end transaction across services

D.A single logical operation within a service, with a start and end time

AnswerD

Correct. A span represents one operation, such as a database call or an HTTP request handler.

Why this answer

A span is the fundamental building block of a trace, representing a single unit of work in a distributed system.

Full explanation →

364

MCQhard

An application requires that configuration data be mounted as a file inside the container. The data may change at runtime, and the application should automatically read the updated values without restarting. Which approach should be used?

A.Store the configuration in a Secret and mount it using subPath

B.Use a ConfigMap mounted as a volume without subPath

C.Use a PersistentVolumeClaim to store the configuration

D.Store the configuration in an environment variable from a ConfigMap

AnswerB

When mounted as a volume without subPath, the files are updated via symlinks, and the application can read the new content if it watches for changes.

Why this answer

Mounting a ConfigMap as a volume (without subPath) creates a symlink-based mount that automatically updates when the ConfigMap changes. The kubelet periodically syncs the ConfigMap data and updates the symlinks, allowing the application to read the new values without a restart. This satisfies the requirement for runtime configuration updates without container restart.

Exam trap

A common trap is the misconception that subPath mounts support live updates, when in fact they create a static file binding that prevents automatic propagation of ConfigMap changes.

How to eliminate wrong answers

Option A is wrong because using subPath creates a direct file mount that does not support automatic updates; the file content is fixed at mount time and requires a pod restart to reflect changes. Option C is wrong because a PersistentVolumeClaim is used for persistent storage, not for configuration data that needs to be updated at runtime, and it does not provide automatic update capabilities. Option D is wrong because environment variables from a ConfigMap are injected at container startup and cannot be updated at runtime without restarting the container.

Full explanation →

365

MCQeasy

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

A.kube-apiserver

B.kube-scheduler

C.kube-controller-manager

D.etcd

AnswerC

Correct. It runs controller processes like node controller, replication controller, etc.

Why this answer

The kube-controller-manager is the component that runs controller processes, which are control loops that watch the shared state of the cluster through the kube-apiserver and make changes to drive the current state toward the desired state. It bundles together controllers such as the Node Controller, Replication Controller, and Endpoint Controller, each responsible for specific aspects of cluster state management.

Exam trap

CNCF often tests the misconception that the kube-apiserver is responsible for maintaining desired state because it is the central API gateway, but the actual enforcement is done by controllers within the kube-controller-manager.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the front-end for the Kubernetes control plane that exposes the Kubernetes API, handling authentication, authorization, and validation of API requests, but it does not run controllers to maintain desired state. Option B is wrong because kube-scheduler is responsible for assigning newly created pods to nodes based on resource requirements and constraints, not for running controllers that maintain cluster state. Option D is wrong because etcd is a distributed key-value store that serves as Kubernetes' backing store for all cluster data, but it does not execute controller logic or enforce desired state.

Full explanation →

366

MCQhard

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

A.Ingress

B.Namespace

C.ConfigMap

D.Service

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

367

MCQmedium

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

A.kubectl logs mycontainer -p mypod

B.kubectl logs mypod --container mycontainer

C.kubectl logs mypod -c mycontainer

D.kubectl logs mypod mycontainer

AnswerC

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

368

MCQeasy

What is the primary purpose of a container registry in a CI/CD pipeline?

A.To store source code

B.To store and distribute container images

C.To manage Kubernetes secrets

D.To run unit tests

AnswerB

Container registries are designed to store and distribute container images, enabling deployment in Kubernetes.

Why this answer

A container registry stores built container images and provides a mechanism to push and pull images. It is a central component in the CI/CD workflow for image distribution.

Full explanation →

369

Matchingmedium

Match each Kubernetes security concept to its definition.

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

Concepts

Matches

Identity for processes running in a pod

Role-based access control to authorize API requests

Specifies how groups of pods are allowed to communicate

Deprecated but formerly controlled security-sensitive pod settings

Stores sensitive data like passwords and tokens

Why these pairings

RBAC and NetworkPolicy are fundamental security mechanisms. ServiceAccount provides identity. The distractors confuse RBAC with secrets management and NetworkPolicy with user access control.

Full explanation →

370

Multi-Selecthard

Which TWO practices are recommended for designing cloud-native microservices? (Choose 2)

Select 2 answers

A.Share a common database schema across all services.

B.Store configuration in environment variables inside the container image.

C.Implement health check endpoints for each service.

D.Use synchronous HTTP calls for all inter-service communication.

E.Design services around business capabilities.

AnswersC, E

Health checks enable orchestration platforms to manage service lifecycle.

Why this answer

Health check endpoints (e.g., /healthz or /ready) are a fundamental pattern in cloud-native microservices. They allow orchestration platforms like Kubernetes to perform liveness and readiness probes, ensuring that traffic is only routed to healthy instances and that unhealthy pods are automatically restarted. This aligns with the cloud-native principle of designing for resilience and self-healing.

Exam trap

The trap here is that candidates often confuse 'configuration in environment variables' (which is acceptable when injected at runtime) with 'storing configuration inside the container image' (which is an anti-pattern), leading them to incorrectly select Option B.

Full explanation →

371

MCQeasy

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

A.Deployment

B.Service

C.Container

D.Pod

AnswerD

A Pod encapsulates one or more containers, storage, and network.

Why this answer

The Pod is the smallest and simplest unit in the Kubernetes object model, representing a single instance of a running process in the cluster. A Pod encapsulates one or more containers, shared storage, and a unique cluster IP, and it is the atomic unit of scheduling, scaling, and management. Deployments and Services are higher-level abstractions that manage Pods, not the smallest deployable unit themselves.

Exam trap

A common misconception in Kubernetes is that a container is the smallest unit due to Docker's influence, but Kubernetes abstracts containers into Pods as the atomic scheduling and management unit.

How to eliminate wrong answers

Option A is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods, providing declarative updates and rollback capabilities; it is not the smallest deployable unit. Option B is wrong because a Service is an abstraction that defines a logical set of Pods and a policy to access them, typically via a stable IP and DNS name; it is a networking abstraction, not a deployable workload unit. Option C is wrong because a Container is a runtime instance of a container image, but in Kubernetes, containers always run inside a Pod; a container cannot be created or managed directly by the Kubernetes API — the Pod is the smallest unit that can be scheduled and managed.

Full explanation →

372

MCQeasy

Which command creates a Deployment named 'nginx' from the 'nginx:1.19' image?

A.kubectl run nginx --image=nginx:1.19

B.kubectl create deployment nginx --image=nginx:1.19

C.kubectl start deployment nginx --image=nginx:1.19

D.kubectl apply -f nginx-deployment.yaml

AnswerB

This creates a Deployment named nginx with the specified image.

Why this answer

The `kubectl create deployment` command is the standard Kubernetes imperative method to create a Deployment resource, and specifying `--image=nginx:1.19` directly sets the container image for the pod template. This command generates a Deployment object that manages a ReplicaSet with the specified image, ensuring declarative updates and rollback capabilities.

Exam trap

The trap here is that candidates confuse `kubectl run` (which creates a Pod, not a Deployment) with `kubectl create deployment`, especially since older versions of `kubectl run` could create Deployments, but the current behavior defaults to Pod creation unless the `--generator` flag is used.

How to eliminate wrong answers

Option A is wrong because `kubectl run` creates a standalone Pod (or in newer versions a Deployment with `--generator=deployment/v1beta1` deprecated), not a Deployment resource; it does not provide the same lifecycle management, scaling, or rolling update features as a Deployment. Option C is wrong because `kubectl start deployment` is not a valid kubectl command; the correct imperative verb is `create`, not `start`. Option D is wrong because while `kubectl apply -f nginx-deployment.yaml` can create a Deployment, it requires a pre-existing YAML manifest file, not a direct image specification, and the question asks for the command that creates a Deployment from the image directly.

Full explanation →

373

MCQeasy

Which resource in Kubernetes is used to expose a set of pods as a network service?

A.Pod

B.Deployment

C.Service

D.Ingress

AnswerC

Provides stable IP and DNS name for pods.

Why this answer

A Service in Kubernetes provides a stable network endpoint (IP address and DNS name) to expose a set of pods, which are ephemeral and can be replaced. Services use selectors to identify target pods and load-balance traffic across them, enabling reliable communication within or outside the cluster.

Exam trap

CNCF often tests the misconception that a Deployment can expose pods as a network service, but a Deployment only manages pod lifecycle and replicas, not network exposure.

How to eliminate wrong answers

Option A is wrong because a Pod is the smallest deployable unit in Kubernetes and has its own IP address, but it is ephemeral and cannot provide a stable network endpoint for a set of pods. Option B is wrong because a Deployment manages the desired state of replica sets and pods, but it does not expose them as a network service; it is a controller, not a networking abstraction. Option D is wrong because an Ingress is a higher-level resource that provides HTTP/HTTPS routing rules to Services, but it does not directly expose pods as a network service; it relies on a Service to do so.

Full explanation →

374

MCQhard

In a serverless architecture using Knative, what happens when a function finishes processing an event and there are no pending events?

A.The function instance is automatically scaled down to zero replicas

B.The function instance is terminated and the container image is deleted

C.The function continues to run but stops listening for events

D.The function instance remains running for a configurable idle timeout

AnswerA

Knative supports auto-scaling to zero when there are no incoming requests.

Why this answer

Knative scales the function to zero replicas when idle, which is a key feature of serverless platforms.

Full explanation →

375

Multi-Selectmedium

Which two of the following are valid ways to set resource constraints on a container in a Pod spec?

Select 2 answers

A.Specify 'resources.guarantees.cpu' for CPU guarantees

B.Specify 'resources.limits.memory' for maximum memory

C.Specify 'resources.min.memory' for minimum memory

D.Specify 'resources.requests.cpu' for minimum CPU

E.Specify 'resources.max.cpu' for CPU limits

AnswersB, D

Limits cap resource usage.

Why this answer

'resources.limits.memory' is the valid Kubernetes field to set the maximum amount of memory a container can use. When a container exceeds this limit, it may be terminated or OOM-killed by the kubelet. This is a core concept in Kubernetes resource management for ensuring predictable application behavior.

Exam trap

The trap here is that candidates confuse the naming convention of Kubernetes resource fields (e.g., 'limits' vs 'max', 'requests' vs 'min' or 'guarantees'), leading them to choose plausible-sounding but non-existent keys like 'resources.max.cpu' or 'resources.guarantees.cpu'.

Full explanation →

Page 5 of 12

All pages

1 2 3 4 5 6 7 8 9 10 11 12

Practice KCNA by domain

Target a specific domain to shore up weak areas.

Kubernetes Fundamentals Container Orchestration Cloud Native Architecture Cloud Native Observability Cloud Native Application Delivery

See all domains with question counts →