Kubernetes and Cloud Native Associate KCNA KCNA Questions 376–450 | Page 6/13

376

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 subcommand patches the Deployment's pod template with the new image tag, triggering a rolling update that replaces pods gradually while maintaining availability. It satisfies the zero-downtime constraint by honouring the Deployment's rolling update strategy rather than deleting pods outright.

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 →

377

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 implements the Kubernetes Container Runtime Interface, satisfying the stem's requirement for a CRI-compliant runtime. It manages the full container lifecycle — image transfer, storage, and execution — via a daemon, and is the default runtime for most Kubernetes distributions, unlike Docker, which required the deprecated dockershim adapter.

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 →

378

MCQmedium

A Kubernetes cluster runs a DaemonSet named 'node-agent' that must run on every node, including the control-plane node. The control-plane node has a taint 'node-role.kubernetes.io/control-plane:NoSchedule'. The DaemonSet currently does not schedule pods on the control-plane node. Which change to the DaemonSet spec will ensure its pods run on the control-plane node?

A.Add a toleration for the taint 'node-role.kubernetes.io/control-plane:NoSchedule' to the DaemonSet's pod template.

B.Add a node selector to the DaemonSet's pod template that matches the control-plane node's labels.

C.Increase the DaemonSet's 'spec.template.spec.priorityClassName' to a higher priority class.

D.Set the DaemonSet's update strategy to 'OnDelete' so that pods are only created when nodes are added.

AnswerA

Taints repel pods unless the pod has a matching toleration. Adding a toleration for the control-plane taint allows the DaemonSet pods to be scheduled onto that node. DaemonSets do not automatically tolerate control-plane taints, so this explicit toleration is required to run on every node including the control-plane node.

Why this answer

Taints and tolerations work together to control scheduling. A taint on a node repels pods that do not tolerate it. To run DaemonSet pods on a tainted node such as a control-plane node, the pod template must include a toleration for that specific taint.

Other scheduling controls like node selectors or priority classes do not override taints.

Exam trap

The trap here is assuming that DaemonSets automatically tolerate all taints, including control-plane taints, when in fact explicit tolerations are required for tainted nodes.

Full explanation →

379

MCQhard

A pod remains in 'Pending' state. Upon inspecting the pod with 'kubectl describe pod', you see the message '0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate'. What is the most likely cause?

A.The pod is not using a ServiceAccount

B.The node has a disk pressure condition and the pod lacks a toleration

C.The pod's resource requests exceed the node's capacity

D.The pod's container image does not exist

AnswerB

The scheduler's message names the taint node.kubernetes.io/disk-pressure, meaning the node reports disk pressure. Because the pod defines no matching toleration, the scheduler refuses to bind it, leaving it Pending. This matches the stem's constraint exactly.

Why this answer

The message '0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate' indicates the node has a taint of 'disk-pressure' which prevents pod scheduling unless the pod has a matching toleration. Since the pod lacks this toleration, it remains in 'Pending' state. Option B correctly identifies the node's disk pressure condition and the missing toleration as the cause.

Exam trap

In the KCNA exam, it's important to distinguish between taint/toleration errors and resource insufficiency errors. Candidates often mistakenly choose 'resource requests exceed capacity' when the message explicitly mentions a taint, not resource limits.

How to eliminate wrong answers

Option A is wrong because a missing ServiceAccount does not cause a 'Pending' state with a taint-based scheduling failure; it would cause authentication issues at runtime, not scheduling. Option C is wrong because resource requests exceeding node capacity would produce a different message, such as 'Insufficient cpu' or 'Insufficient memory', not a taint-related message. Option D is wrong because a non-existent container image would cause an 'ImagePullBackOff' or 'ErrImagePull' error, not a 'Pending' state with a taint message.

Full explanation →

380

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

With auto-sync enabled, ArgoCD continuously compares the Git-declared desired state against live cluster resources and applies the difference, reconciling the cluster back to Git. This satisfies the GitOps requirement that Git remains the single source of truth.

Why this answer

ArgoCD continuously compares the desired state stored in Git with the live state in the cluster. When a difference (drift) is detected, ArgoCD marks the application as OutOfSync. If auto-sync is enabled, ArgoCD automatically applies the Git manifests to the cluster, reconciling the live state to match Git.

This is the core GitOps principle: Git is the single source of truth, and the cluster is continuously reconciled to it.

Exam trap

KCNA often tests the direction of reconciliation in GitOps, confusing candidates into thinking ArgoCD writes back to Git or halts on drift, when in fact it only syncs the cluster to match Git.

How to eliminate wrong answers

Option A is wrong because ArgoCD does not stop working on drift; it reports the application as OutOfSync and continues monitoring, and may auto-sync if configured. Option C is wrong because ArgoCD never deletes the Git repository; it only reads from Git and writes to the cluster, not the other way around. Option D is wrong because ArgoCD does not modify Git; it only reads Git as the source of truth and applies changes to the cluster, not the reverse.

Full explanation →

381

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

Because the container exits with a non-zero code, the current instance has already terminated, so its live logs are unavailable. The --previous flag retrieves logs from the prior container instance, exposing the crash output needed to diagnose the CrashLoopBackOff.

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 →

382

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

A span represents one logical operation inside a service, bounded by start and end timestamps, and carries trace context linking it to parent and child spans. This satisfies the stem's distributed-tracing definition, distinct from a trace, which is the whole request path.

Why this answer

A span represents a single logical operation within a service, with a start time and end time, forming the basic unit of work in distributed tracing. Spans are nested to form a trace, where the root span represents the overall request and child spans represent downstream calls, database queries, or internal operations.

Exam trap

KCNA often tests the distinction between a span (one operation) and a trace (the full end-to-end transaction), so candidates who pick the 'entire transaction' option confuse the container with its component.

How to eliminate wrong answers

Option A is wrong because a metric that measures request latency is a numeric time-series measurement (e.g., Prometheus histogram), not a span — spans carry contextual metadata (operation name, tags, parent ID) and are the building blocks of traces, not metrics. Option B is wrong because a tool for collecting logs from containers describes log aggregation agents like Fluentd or Fluent Bit, which handle logs, not tracing spans. Option C is wrong because the entire end-to-end transaction across services is a trace, not a span — a trace is composed of multiple spans linked by parent-child relationships, so this option confuses the whole with the part.

Full explanation →

383

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

A ConfigMap mounted as a volume without subPath is updated in place when the ConfigMap changes, and kubelet syncs the projected files periodically. The application reads the mounted file and picks up new values without a restart, meeting the runtime-update constraint.

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 →

384

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

The kube-controller-manager runs the built-in control loops that continuously reconcile observed cluster state with the desired state declared in objects, satisfying the stem's requirement for a component that maintains desired state through controllers. It hosts controllers such as Deployment, ReplicaSet and Node, unlike the API server, which only stores state.

Why this answer

The kube-controller-manager is the component that runs controller processes, which are control loops that watch the shared state of the cluster through the 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 →

385

Multi-Selecteasy

Which TWO components are part of the Kubernetes worker node?

Select 2 answers

A.kube-apiserver

B.etcd

C.kube-scheduler

D.kube-proxy

E.kubelet

AnswersD, E

Kube-proxy runs on every worker node, maintaining network rules that implement Kubernetes Service abstraction, enabling pod-to-pod and external traffic routing. It satisfies the worker node component requirement directly, alongside kubelet and the container runtime, distinguishing node-level networking from control plane functions such as scheduling.

Why this answer

kube-proxy (D) is a worker-node component that maintains network rules on each node to implement the Kubernetes Service abstraction, handling traffic forwarding via iptables/IPVS so Pods can reach Services. kubelet (E) is the primary node agent that runs on every worker node, registering the node with the control plane and managing Pod lifecycle by communicating with the container runtime via CRI. The other options belong to the control plane, not worker nodes: kube-apiserver (A) exposes the Kubernetes REST API and is the front end of the control plane, etcd (B) is the distributed key-value store holding cluster state, and kube-scheduler (C) assigns Pods to nodes from the control plane.

Exam trap

In the CNCF Kubernetes exam (e.g., KCNA), the distinction between control-plane and worker-node components is often tested. Candidates may confuse kube-scheduler or kube-apiserver as worker-node components because they are essential to cluster operation but run only on the control plane.

Full explanation →

386

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

A Service assigns a stable DNS name and virtual IP to a set of pods, letting microservices resolve each other by name regardless of pod churn. It provides the built-in service discovery the scenario requires.

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 →

387

Multi-Selectmedium

A platform engineer is troubleshooting a Pod that is stuck in Pending. The engineer suspects the scheduler cannot place it. Which two commands are appropriate to gather evidence about why the Pod has not been scheduled? (Choose two.)

Select 2 answers

A.`kubectl delete pod <pod-name> --force --grace-period=0` to trigger rescheduling and observe the outcome.

B.`kubectl get events --field-selector involvedObject.name=<pod-name>` to filter cluster events for that Pod.

C.`kubectl describe pod <pod-name>` to inspect Events for FailedScheduling messages.

D.`kubectl exec -it <pod-name> -- /bin/sh` to inspect the container's runtime logs.

E.`kubectl logs <pod-name> --previous` to view logs from the prior container instance.

AnswersB, C

Filtering events by the involved object name narrows the event stream to messages about that Pod, including scheduler warnings. It complements kubectl describe by showing timestamped events across the namespace, which helps confirm whether the failure is persistent or intermittent. This is a valid, non-destructive way to collect scheduling evidence.

Why this answer

The scheduler reports its reasoning through Events, so inspecting kubectl describe pod output and filtering cluster events for the Pod both expose FailedScheduling causes like insufficient resources, taints, or affinity mismatches. Commands that require a running container, rely on previous logs, or delete the Pod do not reveal why scheduling failed and are unsuitable for this diagnosis.

Exam trap

The trap here is reaching for exec or logs on a Pending Pod, when no container has started to produce them.

Full explanation →

388

Multi-Selectmedium

A developer is troubleshooting a Pod that remains in the Pending state and never gets scheduled. The developer suspects the issue is related to node selection constraints. Which two kubectl commands can help identify why the Pod cannot be scheduled? (Choose two.)

Select 2 answers

A.kubectl logs <pod-name>

B.kubectl describe pod <pod-name>

C.kubectl exec -it <pod-name> -- /bin/sh

D.kubectl get events --field-selector involvedObject.name=<pod-name>

E.kubectl top pod <pod-name>

AnswersB, D

kubectl describe pod shows the Pod's status conditions and recent Events, including scheduler messages such as '0/3 nodes are available: 3 node(s) didn't match node selector' or insufficient resources. These Events directly reveal why the scheduler could not place the Pod, making describe the most direct diagnostic for a Pending Pod with a node selection issue.

Why this answer

A Pending Pod has not been scheduled, so diagnostics must come from the control plane rather than the container. kubectl describe pod surfaces scheduler Events and status conditions, and kubectl get events filtered by the Pod name provides the same FailedScheduling reasons in a focused list. Commands that require a running container or metrics pipeline cannot function before scheduling occurs.

Exam trap

The trap here is reaching for logs or exec to debug a Pending Pod, when no container has started and only control-plane events can reveal the scheduling failure.

Full explanation →

389

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 check endpoints let orchestrators such as Kubernetes detect unhealthy instances and restart or remove them from load balancing, directly satisfying the stem's resilience and self-healing requirement. Each microservice exposes liveness and readiness probes, enabling automated recovery without manual intervention, which is fundamental to cloud-native design.

Why this answer

Option C is correct because cloud-native microservices must expose health check endpoints (e.g., HTTP /health or /ready probes) so orchestrators like Kubernetes can perform liveness and readiness checks and automatically restart or route traffic away from unhealthy instances. Option E is correct because designing services around business capabilities (domain-driven design bounded contexts) yields loosely coupled, independently deployable services that align with team ownership and scale autonomously. Option A is wrong because sharing a common database schema creates tight coupling and a single point of failure, contradicting the decentralized data management principle of microservices.

Option B is wrong because configuration should be externalized (e.g., ConfigMaps, environment variables injected at runtime, or a config server) rather than baked into the container image, which harms portability and requires rebuilds for config changes. Option D is wrong because using synchronous HTTP calls for all inter-service communication increases latency and cascading failures; asynchronous messaging and other patterns are recommended where appropriate.

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 →

390

Multi-Selecthard

Which THREE of the following are valid container runtimes that can be used with Kubernetes via the Container Runtime Interface (CRI)? (Select three.)

Select 3 answers

A.rkt

B.containerd

C.Kata Containers

D.Docker

E.CRI-O

AnswersB, C, E

containerd is a CRI-compliant runtime and is widely used in Kubernetes.

Why this answer

B is correct because containerd is a core container runtime that implements the CRI (Container Runtime Interface) directly via its built-in CRI plugin. It was extracted from Docker and is now the default runtime in many Kubernetes distributions, handling image management, container lifecycle, and execution without requiring an external shim.

Exam trap

Kubernetes often tests the misconception that Docker is a valid CRI-compliant runtime, but the trap is that Docker uses containerd under the hood and was removed from Kubernetes as a direct runtime after v1.24, so candidates must recognize that only runtimes with native CRI implementations (like containerd, CRI-O, and Kata Containers) are valid.

Full explanation →

391

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 imperative command creates a Deployment object named nginx and sets its pod template container image to nginx:1.19 via the --image flag, satisfying both the name and image constraints in the stem without requiring a YAML manifest.

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 →

392

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

A Service provides a stable virtual IP and DNS name, load-balancing traffic across the pods selected by its label selector. That abstraction decouples clients from ephemeral pod IPs, directly satisfying the requirement to expose a set of pods as a network service.

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 →

393

MCQmedium

You want to isolate a team's workloads within a Kubernetes cluster so that they cannot see or access resources from other teams. Which feature should you use?

A.Annotations

B.Labels and selectors

C.Resource quotas

D.Namespaces

AnswerD

Namespaces partition a single cluster into logically isolated virtual clusters, scoping namespaced resources and their names so a team's workloads cannot see or access another team's objects. This satisfies the stem's isolation requirement without provisioning separate clusters, though network policies are still needed to restrict cross-namespace traffic.

Why this answer

Namespaces are the Kubernetes abstraction that provides a logical partition of the cluster, enabling multi-tenancy by isolating workloads, resources, and access controls. By default, RBAC policies and network policies can be scoped to a namespace, preventing teams from seeing or accessing resources in other namespaces.

Exam trap

The trap is that candidates confuse labels/selectors (which are for organization and routing within the same namespace) with namespaces (which provide true isolation and multi-tenancy across the cluster). This leads them to select Option B, thinking selectors control visibility, but they only filter resources within a namespace.

How to eliminate wrong answers

Option A is wrong because annotations are key-value metadata attached to objects for non-identifying information (e.g., build versions, contact info) and do not provide any isolation or access control. Option B is wrong because labels and selectors are used for grouping and selecting objects (e.g., for services to target pods), but they do not enforce boundaries or prevent cross-team visibility. Option C is wrong because resource quotas limit aggregate resource consumption (CPU, memory, etc.) within a namespace but do not isolate workloads or restrict access to resources from other teams.

Full explanation →

394

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's autoscaler, via the Pod Autoscaler and Activator, reduces the deployment to zero replicas when no events are pending, eliminating idle compute cost. The revision remains registered so the Activator can cold-start a replica when the next event arrives, matching the stem's zero-pending-events condition.

Why this answer

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

Full explanation →

395

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

Setting `resources.limits.memory` in a container's spec caps the memory the container may consume, so the kubelet enforces the limit and the container is OOM-killed if it exceeds it. This directly satisfies the stem's requirement for a valid resource constraint mechanism within the Pod spec.

Why this answer

Option B is correct because the Pod spec's container definition uses the 'resources.limits' field to declare the maximum amount of a resource the container may consume, so 'resources.limits.memory' sets a hard memory ceiling that the container cannot exceed. Option D is correct because 'resources.requests.cpu' declares the minimum CPU the container is guaranteed for scheduling purposes, and the kubelet uses this value when allocating CPU shares. The other options are invalid field names: 'resources.guarantees.cpu' (A), 'resources.min.memory' (C), and 'resources.max.cpu' (E) do not exist in the Kubernetes API, which only supports 'requests' and 'limits' under 'resources'.

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 →

396

MCQmedium

Which GitOps tools use a pull-based approach to synchronize the desired state in a Git repository with the actual state in a Kubernetes cluster? (Select all that apply.)

A.Flux

B.Terraform

C.Helm

D.ArgoCD

AnswerA, D

Flux runs an in-cluster controller that continuously pulls the Git repository, reconciles the desired manifests against live cluster state and applies drift corrections. This pull-based reconciliation satisfies the requirement for synchronising Git-declared state with the Kubernetes cluster.

Why this answer

Both Flux and ArgoCD are pull-based GitOps tools. Flux pioneered the pull-based pattern, while ArgoCD is also a popular implementation. Therefore, both A and D are correct.

Full explanation →

397

MCQmedium

Which Kubernetes object is used to store non-confidential configuration data that can be consumed by pods?

A.ServiceAccount

B.Secret

C.ConfigMap

D.PersistentVolume

AnswerC

ConfigMaps hold non-confidential key-value configuration data, decoupling it from pod images so containers can consume it via environment variables, command-line arguments, or mounted volumes. This directly satisfies the stem's requirement for storing non-confidential configuration data consumable by pods, unlike Secrets, which are intended for sensitive data.

Why this answer

ConfigMap is the correct Kubernetes object for storing non-confidential configuration data, such as environment variables, command-line arguments, or configuration files, that can be consumed by pods. Unlike Secrets, ConfigMaps store data in plain text and are designed for configuration that does not require encryption, making them ideal for application settings that are not sensitive.

Exam trap

CNCF often tests the distinction between ConfigMaps and Secrets, where candidates mistakenly choose Secrets for all configuration data, forgetting that Secrets are intended only for sensitive information and ConfigMaps are the correct choice for non-confidential data.

How to eliminate wrong answers

Option A is wrong because a ServiceAccount is an identity object used to control pod-level authentication to the Kubernetes API server, not for storing configuration data. Option B is wrong because a Secret is specifically designed for storing sensitive data (e.g., passwords, tokens, SSH keys) and is base64-encoded, not for non-confidential configuration. Option D is wrong because a PersistentVolume is a storage resource abstraction that provides persistent storage to pods, not a mechanism for injecting configuration data.

Full explanation →

398

MCQmedium

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

A.kubelet

B.etcd

C.kube-proxy

D.containerd

AnswerD

containerd is a CRI-compliant container runtime that runs on each node, pulling images and managing container lifecycles for the kubelet. It satisfies the stem's requirement for the node component implementing the Container Runtime Interface, unlike kubelet (orchestrates) or the API server (control plane).

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

399

MCQeasy

Which Kubernetes resource provides a stable IP address and DNS name to access a set of pods?

A.Ingress

B.EndpointSlice

C.Service

D.NetworkPolicy

AnswerC

A Service assigns a stable virtual IP and DNS name, load-balancing traffic to a dynamic set of pods selected by labels. It satisfies the stem's requirement for stable IP and DNS access to a pod set, unlike ephemeral pod IPs.

Why this answer

A Kubernetes Service provides a stable virtual IP address and a DNS name (e.g., my-svc.namespace.svc.cluster.local) that remains constant even as the underlying pods are created, destroyed, or scaled. This abstraction allows clients to reliably reach a set of pods without needing to track individual pod IPs, which are ephemeral. Services use label selectors to dynamically route traffic to matching pods, ensuring high availability and load balancing.

Exam trap

The trap here is that candidates often confuse Ingress (which provides external access) with the internal stable IP/DNS abstraction provided by a Service, or they mistakenly think EndpointSlice (a newer, more scalable replacement for Endpoints) is the resource that offers a stable network identity.

How to eliminate wrong answers

Option A is wrong because Ingress is not a stable IP/DNS resource for pods; it is an API object that manages external HTTP/HTTPS access to Services, typically providing host-based or path-based routing and TLS termination, but it does not itself assign a stable IP or DNS name to a set of pods. Option B is wrong because EndpointSlice is not a stable IP/DNS resource; it is a lower-level object that tracks the actual IP addresses and ports of pods matching a Service's selector, used for scalability and efficiency, but it does not provide a stable endpoint for clients. Option D is wrong because NetworkPolicy is a security resource that controls traffic flow at the IP address or port level (OSI layer 3 or 4) using pod selectors and namespace selectors; it does not provide any IP address or DNS name for accessing pods.

Full explanation →

400

MCQhard

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

A.The container image does not exist

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

C.The pod's readiness probe is failing

D.The pod's liveness probe is failing

AnswerB

Pending means the scheduler cannot bind the pod to a node. Insufficient CPU or memory on every candidate node is the classic cause, since the scheduler filters out nodes lacking requested resources and leaves the pod unscheduled.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

401

MCQhard

A team deploys an application as a StatefulSet with three replicas. They need each Pod to have a stable network identity and its own persistent storage that survives Pod rescheduling. Which two features of StatefulSet satisfy these requirements?

A.A StatefulSet with a ClusterIP Service and hostPath volumes for each Pod

B.A Deployment with a headless Service and a shared PersistentVolume mounted by all replicas

C.A StatefulSet with podManagementPolicy: Parallel and an emptyDir volume per Pod

D.Stable Pod names and a headless Service for network identity, plus volumeClaimTemplates for per-Pod storage

AnswerD

StatefulSet Pods receive stable ordinal names like app-0, app-1, and app-2, and a headless Service provides stable DNS names such as app-0.app.default.svc.cluster.local. volumeClaimTemplates creates a PersistentVolumeClaim for each Pod, ensuring each replica has dedicated storage that persists across rescheduling. Together these features meet both requirements.

Why this answer

StatefulSets provide stable ordinal Pod names and, with a headless Service, stable DNS records for each Pod. volumeClaimTemplates dynamically creates a PersistentVolumeClaim per Pod, giving each replica its own persistent storage that follows the Pod across rescheduling. A Deployment with shared storage or a StatefulSet with emptyDir or hostPath does not meet these requirements.

Exam trap

The trap here is assuming that any Service provides per-Pod DNS names, when only a headless Service does.

Full explanation →

402

MCQeasy

A developer wants to run a single instance of a stateless web application that should be automatically restarted if it fails, but does not require scaling or updates. Which Kubernetes resource is most appropriate?

A.DaemonSet

B.Deployment

C.Pod

D.StatefulSet

AnswerB

A Deployment manages a ReplicaSet, which ensures the desired number of Pod replicas are running. If a Pod fails, the ReplicaSet creates a new one. Deployments also support rolling updates and rollbacks. Even for a single instance, a Deployment provides self-healing and declarative updates, making it the best choice for a stateless application.

Why this answer

A Deployment is the standard controller for stateless applications. It provides self-healing by maintaining the desired replica count, and supports rolling updates. While a Pod can run a container, it lacks automatic rescheduling on node failure.

StatefulSet and DaemonSet serve different purposes and are not appropriate for a simple stateless web app.

Exam trap

The trap here is thinking a bare Pod is sufficient because it has a restartPolicy; however, a Pod does not survive node failures or support updates.

Full explanation →

403

MCQeasy

What is the smallest deployable unit in Kubernetes that you can create and manage?

A.Service

B.Container

C.Pod

D.Deployment

AnswerC

A Pod is the smallest deployable unit Kubernetes creates and manages, wrapping one or more containers that share network and storage. Controllers such as Deployments and ReplicaSets manage Pods rather than replacing them as the atomic unit.

Why this answer

A Pod is the smallest and simplest unit in the Kubernetes object model that you can create and deploy. It represents a single instance of a running process in your cluster and encapsulates one or more containers with shared storage and network resources. While containers are the actual runtime environments, Kubernetes does not manage containers directly; it manages Pods, which are the atomic unit of scheduling and lifecycle management.

Exam trap

The trap here is that candidates confuse the container (the runtime technology) with the Pod (the Kubernetes API object), leading them to select 'Container' because they think of Docker containers as the smallest unit, but Kubernetes abstracts containers into Pods as the atomic deployable unit.

How to eliminate wrong answers

Option A is wrong because a Service is an abstraction that defines a logical set of Pods and a policy to access them; it is not a deployable unit but rather a networking resource that sits on top of Pods. Option B is wrong because a Container is not a Kubernetes API object; Kubernetes manages containers only within the context of a Pod, and you cannot create or manage a standalone container via the Kubernetes API. Option D is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods; it is not the smallest deployable unit but rather a declarative way to manage Pod scaling and updates.

Full explanation →

404

MCQeasy

Which component runs on every worker node and is responsible for ensuring that containers are running in a pod as specified in the PodSpec?

A.container runtime

B.kube-proxy

C.kubelet

D.kube-scheduler

AnswerC

The kubelet is the primary node agent that runs on every worker node, directly satisfying the stem’s constraint of ensuring containers run per the PodSpec. It achieves this by continuously polling the API server for assigned Pods, then using the container runtime (e.g., containerd) to create, start, and restart containers based on the PodSpec’s declared state, thereby enforcing the desired container lifecycle.

Why this answer

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It is responsible for ensuring that containers described in a PodSpec are running and healthy, by interacting with the container runtime (e.g., containerd, CRI-O) to create, start, and monitor pods. The kubelet does not manage containers that were not created by Kubernetes.

Exam trap

The trap here is that candidates confuse the kubelet with the container runtime, assuming the runtime itself reads PodSpecs, when in fact the kubelet is the orchestrator that translates PodSpecs into runtime actions via the CRI.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it does not interpret PodSpecs or enforce desired state — it only executes container lifecycle operations when instructed by the kubelet. Option B is wrong because kube-proxy is a network proxy that runs on each node, handling service-to-pod traffic routing via iptables or IPVS rules, and has no role in container lifecycle management. Option D is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints, but it does not run on worker nodes and does not manage running containers.

Full explanation →

405

MCQhard

A cluster administrator notices that a Deployment's pods are not receiving traffic as expected. The Service selector matches the pod labels. What is a possible cause?

A.The pods have a liveness probe that fails

B.The Deployment replicas are set to zero

C.The pods have a failing readiness probe

D.The Service type is NodePort

AnswerC

A failing readiness probe removes the pod from the Service's endpoint list, so kube-proxy stops forwarding traffic to it even though the selector matches. This mechanism explains why matching pods receive no traffic, satisfying the stem's scenario of unexpected traffic loss.

Why this answer

A failing readiness probe removes the pod's endpoint from the Service's EndpointSlice, so the Service stops routing traffic to that pod even though the pod is running and its labels match the Service selector. This is the most direct reason why a Deployment's pods would not receive traffic despite correct label matching.

Exam trap

The exam often tests the distinction between liveness and readiness probes, trapping candidates who confuse a liveness probe failure (which restarts the pod) with a readiness probe failure (which removes the pod from the Service's endpoint list).

How to eliminate wrong answers

Option A is wrong because a failing liveness probe causes the kubelet to restart the pod, but it does not directly prevent the Service from routing traffic to the pod while it is still running; traffic can still reach a pod with a failing liveness probe until it is terminated. Option B is wrong because if Deployment replicas are set to zero, there are no pods to receive traffic at all, but the question states the pods are not receiving traffic as expected, implying pods exist but traffic is not reaching them. Option D is wrong because a NodePort Service type does not inherently block traffic; it simply exposes the Service on a static port on each node's IP, and traffic can still reach pods as long as the selector matches.

Full explanation →

406

MCQmedium

Which of the following is a correct apiVersion for a Deployment in a modern Kubernetes cluster (v1.19+)?

A.apiVersion: extensions/v1beta1

B.apiVersion: v1

C.apiVersion: apps/v1

D.apiVersion: apps/v1beta1

AnswerC

apps/v1 is the correct apiVersion for Deployments from Kubernetes v1.9 onward, satisfying the stem's v1.19+ constraint. The older extensions/v1beta1 and apps/v1beta1 versions were removed, so manifests using them are rejected by the API server in modern clusters.

Why this answer

`apps/v1` is the stable API version for Deployments in Kubernetes v1.19+, replacing the deprecated `extensions/v1beta1` and `apps/v1beta1` versions. The `apps/v1` API group provides the full set of features for Deployments, including rolling updates, rollbacks, and scaling, and is required for production clusters running v1.19 or later.

Exam trap

The trap here is that candidates may confuse the core `v1` API group (used for Pods) with the `apps/v1` group required for Deployments, or mistakenly think that beta versions like `apps/v1beta1` are still valid in modern clusters.

How to eliminate wrong answers

Option A is wrong because `extensions/v1beta1` was deprecated in Kubernetes v1.16 and removed in v1.22; it is not a valid apiVersion for Deployments in a modern cluster (v1.19+). Option B is wrong because `v1` is the core API group used for resources like Pods, Services, and ConfigMaps, but Deployments belong to the `apps` API group, not the core group. Option D is wrong because `apps/v1beta1` was deprecated in Kubernetes v1.16 and removed in v1.22; the stable `apps/v1` is the only correct version for Deployments in v1.19+.

Full explanation →

407

MCQhard

An application Pod needs to read a database password at runtime. The security team requires that the secret material never be stored in the Pod's container image or in a ConfigMap, and that updates to the secret be reflected in the running container without recreating the Pod. Which approach satisfies these requirements?

A.Bake the password into a private container image and pull it with an imagePullSecret.

B.Pass the password as a command-line argument in the Pod specification.

C.Store the password in a ConfigMap and consume it as an environment variable.

D.Store the password in a Secret and mount it as a volume in the Pod.

AnswerD

A Secret stores sensitive data separately from images and ConfigMaps, and mounting it as a volume projects the value as a file. The kubelet refreshes mounted Secret volumes periodically, so updates to the Secret propagate to the running container without recreating the Pod, provided the application re-reads the file, satisfying both security and live-update requirements.

Why this answer

Kubernetes Secrets keep sensitive data out of images and ConfigMaps. Mounting a Secret as a volume presents the value as a file, and the kubelet periodically refreshes projected Secret volumes so changed values appear in the container filesystem without restarting the Pod. The application must re-read the file to pick up changes, but the platform side meets the security and live-update constraints.

Exam trap

The trap here is assuming that environment-variable injection from a Secret or ConfigMap updates at runtime, when only volume-mounted Secrets are refreshed periodically by the kubelet.

Full explanation →

408

MCQhard

A developer created a Deployment with 5 replicas. After applying the manifest, only 3 pods are Running; the other 2 are Pending. Which is the MOST likely cause?

A.The readiness probe is failing

B.A NetworkPolicy is blocking traffic to the pods

C.The container image is misspelled

D.The nodes do not have enough available CPU or memory to schedule the additional pods

AnswerD

Pending means the scheduler cannot bind the pods to any node. Insufficient allocatable CPU or memory leaves no node satisfying the pod's resource requests, so the remaining two replicas stay unscheduled while three already-placed pods run.

Why this answer

D is correct because when a Pod remains in Pending state, it indicates that the scheduler cannot find a node that satisfies the Pod's resource requests. Since 3 Pods are already running and consuming resources, the remaining 2 Pods cannot be placed if the cluster's nodes lack sufficient allocatable CPU or memory. This is a classic resource-constrained scheduling failure, not a runtime or network issue.

Exam trap

The exam often tests the distinction between Pod lifecycle phases (Pending, Running, Failed) and readiness/liveness probes; the trap here is confusing a scheduling failure (Pending) with a runtime failure (CrashLoopBackOff) or network restriction (NetworkPolicy).

How to eliminate wrong answers

Option A is wrong because a failing readiness probe would cause the Pod to be in Running state but not Ready, not Pending; readiness probes affect service endpoints, not scheduling. Option B is wrong because a NetworkPolicy only controls ingress/egress traffic to Pods that are already running, it does not prevent Pods from being scheduled or starting. Option C is wrong because a misspelled container image would cause an ImagePullBackOff or ErrImagePull error, resulting in a CrashLoopBackOff or waiting state, not a Pending state; Pending means the Pod has not been assigned to a node yet.

Full explanation →

409

MCQeasy

Which Kubernetes control plane component is responsible for maintaining the desired state of the cluster by running controller loops?

A.etcd

B.kube-apiserver

C.kube-controller-manager

D.kube-scheduler

AnswerC

The kube-controller-manager runs the built-in controller loops — ReplicaSet, Deployment, Node and others — that continuously reconcile observed cluster state against the desired state declared in the API server, which is exactly the maintenance role the stem asks for.

Why this answer

The kube-controller-manager is the control plane component that runs controller loops, which are continuous processes that watch the shared state of the cluster through the kube-apiserver and make changes to drive the current state toward the desired state. Each controller (e.g., ReplicaSet, Node, Deployment) is a separate loop that handles a specific aspect of cluster management, ensuring that the actual cluster state matches the desired configuration defined in the API objects.

Exam trap

CNCF often tests the misconception that the kube-apiserver handles all cluster logic, but the trap here is that the kube-apiserver only exposes the API and validates requests, while the actual reconciliation loops that enforce desired state are run exclusively by the kube-controller-manager.

How to eliminate wrong answers

Option A is wrong because etcd is a distributed key-value store that holds all cluster data, but it does not run controller loops or enforce desired state; it is a passive storage backend. Option B is wrong because kube-apiserver is the front-end for the Kubernetes API that validates and processes RESTful requests, but it does not execute controller reconciliation logic; it serves as the communication gateway. Option D is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for maintaining the overall desired state of the cluster via controller loops.

Full explanation →

410

Matchingmedium

Match each Kubernetes storage concept to its description.

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

Concepts

Matches

Request for storage by a user, referencing a PersistentVolume

Describes classes of storage with different QoS, backup policies, etc.

Ephemeral volume that shares a pod's lifecycle

Mounts a file or directory from the host node's filesystem

Container Storage Interface standard for pluggable storage drivers

Why these pairings

The correct matches are: PersistentVolume is a cluster storage resource, PersistentVolumeClaim is a user request for storage, and StorageClass defines storage classes. Two common confusions are swapping PV and PVC definitions.

Full explanation →

411

MCQhard

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

A.Job

B.Deployment

C.CronJob

D.DaemonSet

AnswerA

A Job creates Pods that run to completion, tracking successful completions and retrying failures until the specified count is reached. This satisfies the stem's requirement for a batch workload that processes a queue and then terminates, unlike a Deployment, which maintains continuously running Pods.

Why this answer

A Kubernetes Job is designed for batch processing tasks that run to completion and then terminate. It creates one or more Pods and ensures they successfully finish executing a specific workload, making it the correct choice for processing a queue and then exiting.

Exam trap

The CNCF exam often tests the distinction between one-time batch processing (Job) and scheduled tasks (CronJob), leading candidates to mistakenly choose CronJob when the question specifies a single run that terminates.

How to eliminate wrong answers

Option B is wrong because a Deployment is intended for long-running, stateless applications that should run continuously, not for batch jobs that terminate after completion. Option C is wrong because a CronJob is used for scheduling recurring tasks at specified times, not for a one-time batch job that runs and stops. Option D is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset) in the cluster, typically for cluster-wide services like logging or monitoring, not for a terminating batch job.

Full explanation →

412

MCQmedium

What is the purpose of the circuit breaker pattern in a microservices architecture?

A.To balance load across multiple instances

B.To handle authentication between services

C.To encrypt data in transit

D.To prevent a service from being overwhelmed by requests when it is failing

AnswerD

When a downstream dependency fails, the circuit breaker trips and returns errors or fallbacks immediately, halting calls to the unhealthy service. This stops retry storms and queued requests from overwhelming an already failing service, satisfying the stem's requirement to prevent overload during failure.

Why this answer

The circuit breaker pattern is a stability pattern that monitors for failures and prevents a service from making requests to a failing downstream service, allowing it to recover. When the failure rate exceeds a threshold (e.g., 50% of requests fail within a 10-second sliding window), the circuit 'opens' and subsequent calls fail immediately without consuming resources. This prevents cascading failures and resource exhaustion in distributed systems like Kubernetes or Spring Cloud.

Exam trap

CNCF often tests the distinction between 'preventing overload from a failing service' (circuit breaker) and 'distributing load across healthy instances' (load balancer), so candidates mistakenly pick load balancing when they see 'overwhelmed by requests' in the question.

How to eliminate wrong answers

Option A is wrong because load balancing distributes incoming traffic across healthy instances (e.g., via Round Robin or Least Connections), not preventing overload from a failing service. Option B is wrong because authentication between services is handled by mechanisms like OAuth2, JWT, or mTLS, not by the circuit breaker pattern. Option C is wrong because encrypting data in transit is achieved via TLS/SSL (e.g., HTTPS, gRPC with TLS), not by circuit breakers which operate at the application or network layer to manage fault tolerance.

Full explanation →

413

MCQhard

What is context propagation in distributed tracing?

A.Sampling traces to reduce data volume

B.Visualizing traces in a user interface

C.Carrying trace context (trace ID, span ID) across services

D.Storing trace data in a centralized database

AnswerC

Context propagation is the mechanism that carries trace context, specifically the trace ID and span ID, across service boundaries. Each downstream service continues the same trace rather than starting a new one, which is what makes a distributed trace reconstructable end to end.

Why this answer

Context propagation is the mechanism by which trace context — primarily the trace ID and the current span ID — is passed from one service to the next across network calls, so all spans belonging to the same request are stitched into a single distributed trace. This is typically done via HTTP headers (e.g., W3C `traceparent`) or message metadata. Without it, each service would create an isolated trace and the end-to-end picture would be lost.

Exam trap

The trap is conflating the different pillars of tracing — sampling, storage, visualization, and propagation — and picking a plausible-sounding but functionally distinct option like sampling or storage.

How to eliminate wrong answers

Option A is wrong because sampling is a separate concern — it decides which traces to record to control volume, not how context moves between services. Option B is wrong because visualizing traces in a UI is the job of a tracing backend/frontend (e.g., Jaeger UI, Grafana Tempo), not propagation. Option D is wrong because storing trace data in a centralized database is the storage/backend layer of a tracing system, unrelated to carrying context across service boundaries.

Full explanation →

414

MCQmedium

You notice that a pod is in 'Pending' state for a long time. Which of the following is the most likely cause?

A.The pod's liveness probe is failing.

B.No node has enough CPU or memory to meet the pod's requests.

C.The pod's readiness probe is not configured.

D.The container image does not exist.

AnswerB

The scheduler leaves a pod Pending when no node satisfies its resource requests, since insufficient allocatable CPU or memory prevents binding. Image pull failures or crash loops instead produce ErrImagePull or CrashLoopBackOff, so resource shortfall is the likely cause.

Why this answer

A pod remains in 'Pending' state when the scheduler cannot find a node that satisfies its resource requests. The most common reason is insufficient CPU or memory capacity across all available nodes, preventing the pod from being bound to a node. Unlike probe failures or missing images, which cause 'Running' or 'ImagePullBackOff' states, resource constraints block scheduling entirely.

Exam trap

A common exam trap is confusing scheduling failures (Pending) with runtime failures (CrashLoopBackOff, ImagePullBackOff). Candidates often mistake probe or image issues as causes of the Pending state, but these occur after the pod is scheduled.

How to eliminate wrong answers

Option A is wrong because a failing liveness probe causes the pod to be restarted or enter 'CrashLoopBackOff', not remain in 'Pending' — liveness probes only run after the pod is scheduled and containers start. Option C is wrong because a missing readiness probe does not affect scheduling; it only controls whether the pod receives traffic via Services, and the pod can still be 'Running'. Option D is wrong because a non-existent container image results in 'ImagePullBackOff' or 'ErrImagePull' states, not 'Pending' — the pod must first be scheduled to a node before the kubelet attempts to pull the image.

Full explanation →

415

MCQmedium

A developer needs to provide a pod with a persistent volume that must be mounted by multiple pods simultaneously for read-write access. The underlying storage system supports concurrent writes from multiple nodes. Which volume type should be used?

A.ReadWriteOncePod (RWOP)

B.ReadWriteMany (RWX)

C.ReadOnlyMany (ROX)

D.ReadWriteOnce (RWO)

AnswerB

ReadWriteMany allows a volume to be mounted as read-write by many nodes simultaneously. This matches the requirement of multiple pods needing read-write access. The underlying storage must support RWX, such as NFS, CephFS, or cloud file storage. This is the correct access mode for shared read-write persistent volumes.

Why this answer

The access mode ReadWriteMany (RWX) allows a persistent volume to be mounted as read-write by multiple nodes, enabling multiple pods to write concurrently. This is essential for shared storage scenarios like a shared database or file server. The underlying storage plugin must support RWX; not all storage systems do.

ReadWriteOnce and ReadWriteOncePod are limited to a single node or pod, respectively, and ReadOnlyMany is read-only.

Exam trap

The trap here is confusing ReadWriteOnce with ReadWriteMany, or assuming that ReadWriteOncePod allows multiple pods, when it actually restricts to a single pod.

Full explanation →

416

MCQhard

A cluster administrator is configuring a NetworkPolicy for a set of pods labeled 'role=db' in the 'backend' namespace. The policy should allow ingress only from pods labeled 'role=api' in the 'frontend' namespace, and only on TCP port 6379. Which NetworkPolicy specification correctly enforces this?

A.spec: { podSelector: { matchLabels: { role: db } }, ingress: [ { from: [ { podSelector: { matchLabels: { role: api } } } ], ports: [ { protocol: TCP, port: 6379 } ] } ] }

B.spec: { podSelector: { matchLabels: { role: db } }, ingress: [ { from: [ { namespaceSelector: { matchLabels: { name: frontend } } } ], ports: [ { protocol: TCP, port: 6379 } ] } ] }

C.spec: { podSelector: { matchLabels: { role: db } }, ingress: [ { from: [ { namespaceSelector: { matchLabels: { kubernetes.io/metadata.name: frontend } }, podSelector: { matchLabels: { role: api } } } ], ports: [ { protocol: TCP, port: 6379 } ] } ] }

D.spec: { podSelector: { matchLabels: { role: db } }, ingress: [ { from: [ { namespaceSelector: { matchLabels: { name: frontend } }, podSelector: { matchLabels: { role: api } } } ], ports: [ { protocol: TCP, port: 6379 } ] } ] }

AnswerC

This policy selects pods with 'role=db' in the backend namespace. The ingress rule allows traffic from pods with 'role=api' in namespaces labeled 'kubernetes.io/metadata.name=frontend', which is the standard label automatically applied to namespaces. It restricts to TCP port 6379, correctly enforcing the requirement.

Why this answer

A NetworkPolicy ingress rule can combine namespaceSelector and podSelector to allow traffic from specific pods in specific namespaces. The namespaceSelector must match the namespace's labels; Kubernetes automatically labels namespaces with 'kubernetes.io/metadata.name=<namespace-name>'. The policy must also specify the allowed port.

The correct specification uses the proper namespace label and includes both selectors.

Exam trap

The trap here is using an arbitrary namespace label like 'name: frontend' instead of the automatically applied 'kubernetes.io/metadata.name: frontend', or forgetting to include the podSelector for the source pods.

Full explanation →

417

MCQmedium

A delivery team's manifests are nearly identical across dev, staging, and production, differing only in replica counts, image tags, and resource limits. They want to keep one shared base and apply environment-specific changes without introducing a templating language. Which approach fits best?

A.Store three copies of every manifest in Git and use a CI job to copy the correct directory at deploy time

B.Use Kustomize with a common base and per-environment overlays that patch the differing fields

C.Create three separate Helm charts, one per environment, and maintain them independently

D.Write a sed-based script that rewrites image tags and replica counts in the manifests before applying them

AnswerB

Kustomize keeps one base directory and applies overlays that patch only the fields each environment changes, such as replicas, image tags, and resources. It uses plain YAML with no template syntax, so the shared base stays authoritative and environment differences remain explicit and reviewable.

Why this answer

A single base with per-environment overlays is exactly Kustomize's model: the base holds common resources, and each overlay patches only what differs, using plain YAML rather than templates. This keeps one source of truth while making environment deltas small, explicit, and reviewable in version control.

Exam trap

The trap here is treating environment differences as a reason to duplicate manifests or reach for templating, when overlays patch a shared base without either.

Full explanation →

418

MCQmedium

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

A.Deployment

B.DaemonSet

C.ReplicaSet

D.StatefulSet

AnswerB

A DaemonSet's controller schedules exactly one Pod copy onto every eligible Node, including Nodes added later, and bypasses the scheduler's normal placement logic. That guarantees the required one-Pod-per-Node coverage, which a Deployment or ReplicaSet cannot promise.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

419

MCQeasy

What is the primary purpose of the kube-scheduler in a Kubernetes cluster?

A.Assigning pods to nodes

B.Running container runtime operations

C.Storing the cluster state

D.Exposing the Kubernetes API

AnswerA

The kube-scheduler watches for newly created Pods with no assigned node and selects a suitable node based on resource requests, affinity rules and taints. This satisfies the stem's requirement for the component whose primary purpose is assigning Pods to nodes.

Why this answer

The kube-scheduler is the Kubernetes control plane component responsible for selecting an optimal node for newly created pods that have not yet been assigned to a node. It evaluates constraints such as resource requirements, affinity/anti-affinity rules, and data locality, then binds the pod to the chosen node via the Kubernetes API. This makes assigning pods to nodes its primary and defining purpose.

Exam trap

The exam often tests the distinction between control plane components, so the trap here is confusing the kube-scheduler's role with the kubelet's execution role or the API server's exposure role, leading candidates to pick 'Running container runtime operations' or 'Exposing the Kubernetes API'.

How to eliminate wrong answers

Option B is wrong because running container runtime operations (e.g., pulling images, starting containers) is the responsibility of the kubelet on each node, not the kube-scheduler. Option C is wrong because storing the cluster state is the function of etcd, a distributed key-value store, not the kube-scheduler. Option D is wrong because exposing the Kubernetes API is the role of the kube-apiserver, which is the front-end for the control plane; the scheduler only interacts with the API server to watch for unscheduled pods and update pod bindings.

Full explanation →

420

MCQhard

An application requires that a set of Pods each be assigned a unique DNS name that can be used for peer-to-peer communication. Which Kubernetes resource should be used?

A.Job with a Service

B.DaemonSet with a Service

C.StatefulSet with a Headless Service

D.Deployment with a Service

AnswerC

A StatefulSet with a Headless Service satisfies the unique DNS requirement: each Pod receives a stable, ordinal hostname such as pod-0.service.namespace.svc.cluster.local, resolved directly to the Pod IP rather than a load-balanced ClusterIP. This stable per-Pod identity enables direct peer-to-peer communication, which a Deployment behind a normal Service cannot provide.

Why this answer

A StatefulSet with a Headless Service is correct because StatefulSets assign each Pod a stable, unique network identity (e.g., pod-name-0.service-name.namespace.svc.cluster.local) that persists across rescheduling. A Headless Service (clusterIP: None) disables load balancing and DNS round-robin, allowing direct DNS resolution to individual Pod IPs for peer-to-peer communication. This matches the requirement for unique DNS names for each Pod.

Exam trap

The trap here is that candidates often assume any Service provides unique DNS names, but only a Headless Service combined with a StatefulSet yields per-Pod DNS entries; a regular Service (ClusterIP or NodePort) always load-balances to a single virtual IP.

How to eliminate wrong answers

Option A is wrong because a Job is designed for batch processing tasks that run to completion, not for long-running Pods requiring stable DNS identities; a Service with a Job would still use a regular ClusterIP, which load-balances across Pods and does not provide unique per-Pod DNS names. Option B is wrong because a DaemonSet ensures one Pod per Node but does not guarantee stable, unique DNS names for each Pod; combined with a regular Service, DNS resolves to the Service IP, not individual Pods. Option D is wrong because a Deployment creates identical, interchangeable Pods with no stable identity; a regular Service provides a single DNS name that load-balances across all Pods, not unique per-Pod DNS names.

Full explanation →

421

MCQeasy

A startup wants to minimize downtime during application updates in Kubernetes. Which deployment strategy should they use?

A.RollingUpdate

B.Canary

C.Blue/Green

D.Recreate

AnswerA

RollingUpdate replaces pods incrementally, keeping a proportion of replicas available via maxUnavailable and maxSurge, so the Service always has ready endpoints. This satisfies the requirement to minimise downtime during updates without extra tooling or duplicate environments.

Why this answer

The RollingUpdate strategy is the default in Kubernetes and minimizes downtime by gradually replacing old Pods with new ones while the application remains available. It uses a configurable `maxSurge` and `maxUnavailable` parameters to control the rate of change, ensuring that a specified number of Pods are always serving traffic. This makes it ideal for startups seeking zero-downtime updates without the complexity of additional tooling or infrastructure.

Exam trap

The trap here is that candidates often confuse 'minimizing downtime' with 'risk mitigation' and pick Canary or Blue/Green, but the question specifically asks for the simplest strategy to minimize downtime during updates, which is RollingUpdate by default in Kubernetes.

How to eliminate wrong answers

Option B (Canary) is wrong because while it reduces risk by routing a small percentage of traffic to the new version, it is not primarily designed to minimize downtime during updates; it focuses on validating changes with a subset of users and often requires additional service mesh or ingress configuration. Option C (Blue/Green) is wrong because it minimizes downtime by running two full environments and switching traffic instantly, but it doubles resource costs and is not the simplest or most cost-effective choice for a startup aiming to minimize downtime without extra overhead. Option D (Recreate) is wrong because it terminates all old Pods before creating new ones, causing guaranteed downtime during the update, which directly contradicts the goal of minimizing downtime.

Full explanation →

422

MCQmedium

Which command would you use to get the logs of a pod named 'backend' in the 'production' namespace?

A.kubectl log pod backend -n production

B.kubectl get logs backend -n production

C.kubectl logs -n production pod/backend

D.kubectl logs backend --namespace=production

AnswerC, D

Correct. This command correctly uses `kubectl logs` with the namespace flag and the pod name, optionally prefixed with `pod/`.

Why this answer

Both option C (`kubectl logs -n production pod/backend`) and option D (`kubectl logs backend --namespace=production`) are valid and functionally equivalent. kubectl accepts the pod name with or without the `pod/` prefix, and flags can appear before or after the resource argument. Options A (`kubectl log`, singular) and B (`kubectl get logs`) are invalid commands. Since two options are correct, the question is ambiguous as written.

Exam trap

Common mistakes include using `kubectl get logs` (invalid), using the singular `kubectl log`, or omitting the namespace flag. Note that the `pod/` prefix is optional and valid but not required.

How to eliminate wrong answers

Option A is wrong because the verb is `log` instead of `logs`; `kubectl log` is not a valid command. Option B is wrong because `kubectl get logs` is not a valid subcommand; `get` is used for resources like pods, not logs. Option C is wrong because the syntax `kubectl logs -n production pod/backend` is incorrect; the resource type prefix `pod/` is not used with `kubectl logs` — the correct form is `kubectl logs backend -n production`.

Full explanation →

423

MCQeasy

Which Kubernetes object provides a stable IP address and DNS name for a set of Pods?

A.Ingress

B.ConfigMap

C.Service

D.Deployment

AnswerC

A Service fronts a set of Pods behind a single virtual IP and DNS name, so clients reach a stable endpoint even as individual Pods are replaced. This satisfies the stem's requirement for a stable IP address and DNS name, unlike Pod IPs, which change on recreation.

Why this answer

A Service provides a stable virtual IP address and a DNS name (e.g., my-svc.namespace.svc.cluster.local) that remains constant even as Pods are created or destroyed. This enables reliable network access to a dynamic set of Pods selected via labels, abstracting away Pod IP volatility.

Exam trap

CNCF often tests the misconception that a Deployment provides a stable network identity, when in fact it only manages Pod replicas and their lifecycle, while the Service object is solely responsible for stable IP/DNS abstraction.

How to eliminate wrong answers

Option A is wrong because an Ingress is not an IP/DNS provider for Pods; it is an API object that manages external HTTP/HTTPS routing to Services, typically using a load balancer or reverse proxy, and does not assign a stable IP to Pods directly. Option B is wrong because a ConfigMap is used to store non-confidential configuration data as key-value pairs or files, and it has no networking or IP assignment functionality. Option D is wrong because a Deployment manages the desired state and lifecycle of Pods (e.g., scaling, rolling updates) but does not provide a stable network endpoint; Pods created by a Deployment receive ephemeral IPs that change on restart.

Full explanation →

424

Multi-Selecthard

Which two scenarios would benefit from using a StatefulSet instead of a Deployment? (Choose two.)

Select 2 answers

A.An application that requires persistent storage unique to each instance

B.A database cluster that requires stable network identities

C.A batch job that runs once and exits

D.A stateless web application that can scale horizontally

E.A microservice that can use any available node

AnswersA, B

StatefulSet assigns each replica a stable, ordinal identity and its own PersistentVolumeClaim via volumeClaimTemplates, so storage survives rescheduling and remains bound to that pod. A Deployment's replicas share no such per-instance identity, making it unsuitable when each instance needs persistent storage unique to itself.

Why this answer

Option A is correct because a StatefulSet provides each Pod with a stable, unique identity and its own PersistentVolumeClaim via volumeClaimTemplates, so each replica keeps dedicated persistent storage that survives rescheduling — something a Deployment cannot guarantee since its Pods share no ordinal-based PVC binding. Option B is correct because StatefulSet Pods get predictable, stable DNS names through a headless Service (e.g., pod-0.svc.namespace.svc.cluster.local), which database clusters such as MySQL, PostgreSQL, or etcd need for peer discovery and quorum. Option C is wrong because run-once batch workloads are better handled by a Job (or CronJob), not a StatefulSet or Deployment.

Option D is wrong because stateless horizontally scalable web apps are the canonical use case for a Deployment, which offers rolling updates and replica management without per-Pod identity. Option E is wrong because node-agnostic microservices are stateless by nature and gain nothing from StatefulSet's stable identity or storage guarantees.

Exam trap

The trap here is that candidates may confuse the need for stable network identities (StatefulSet) with the ability to run on any node (Deployment), or mistakenly think batch jobs fit into StatefulSets because they involve 'state' like logs.

Full explanation →

425

MCQmedium

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

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

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

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

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

AnswerC

Each image layer is immutable and content-addressed, so identical layers are stored once and shared by every image referencing them. This deduplication reduces registry storage and speeds up pulls, since unchanged layers need not be transferred again.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

426

MCQmedium

A cluster administrator wants to restrict which nodes a Pod can be scheduled on based on node labels, while also allowing the scheduler to prefer certain nodes but still run elsewhere if needed. Which combination of features should be used?

A.Use `topologySpreadConstraints` with `whenUnsatisfiable: DoNotSchedule` to spread Pods across labeled nodes.

B.Use `taints` on the nodes and `tolerations` on the Pod to define which nodes are preferred.

C.Use `nodeSelector` for a hard requirement and `nodeAffinity` with `preferredDuringSchedulingIgnoredDuringExecution` for soft preferences.

D.Use `podAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` to pin the Pod to nodes with specific labels.

AnswerC

`nodeSelector` provides a simple hard constraint that limits scheduling to nodes with matching labels. `nodeAffinity` with `preferredDuringSchedulingIgnoredDuringExecution` expresses soft preferences that influence scoring but do not block scheduling if no preferred node is available. Combining them gives a hard label requirement plus flexible preference, exactly matching the administrator's goal.

Why this answer

The scenario requires a hard constraint on node labels and a soft preference that still permits scheduling elsewhere. `nodeSelector` enforces the hard label match, while `nodeAffinity` with a preferred rule provides weighted preferences without preventing scheduling. Other mechanisms either constrain by Pod labels, repulse rather than prefer, or focus on spreading, so they do not satisfy both parts of the requirement.

Exam trap

The trap here is mixing up node affinity with pod affinity, or treating taints as a way to prefer nodes rather than to repel Pods.

Full explanation →

427

MCQeasy

What is the primary purpose of structured logging?

A.To format logs in a consistent, machine-readable way for easier processing

B.To compress log files and reduce storage usage

C.To encrypt log data for security purposes

D.To send logs directly to the user's terminal

AnswerA

Structured logging emits events as key-value pairs, typically JSON, so fields like timestamp, level and service are parsed programmatically without regex. This consistent, machine-readable schema satisfies the stem's requirement for easier automated processing, filtering and aggregation across distributed systems.

Why this answer

Structured logging emits log entries as machine-readable data — typically JSON with consistent key-value fields (timestamp, level, service, message, request_id) — rather than free-form text. This makes logs trivially parseable by log processors and query engines, enabling reliable filtering, aggregation, and alerting. The primary purpose is consistent, machine-readable formatting for easier downstream processing.

Exam trap

The trap is confusing the format of logs (structured vs unstructured) with operational concerns like compression, encryption, or output destination, which are handled by separate tooling layers.

How to eliminate wrong answers

Option B is wrong because compression is a storage/transport optimization applied to log files or streams, not the purpose of structured logging — structured logs are often larger than plain text. Option C is wrong because encryption is a security control applied to log data at rest or in transit, orthogonal to log format. Option D is wrong because sending logs to a terminal is a display/output concern; structured logging is about the format of the emitted record, not where it is rendered.

Full explanation →

428

Drag & Dropmedium

Drag and drop the steps to create a Kubernetes deployment using kubectl into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First, define the deployment in a YAML file, then apply it, verify creation, check pods, and optionally expose it as a service.

Full explanation →

429

MCQmedium

A cluster administrator needs to grant a user permission to view Pods in the 'staging' namespace but not in any other namespace. Which combination of Kubernetes objects should be created?

A.A Role and a RoleBinding in the 'staging' namespace

B.A ClusterRole and a RoleBinding in the 'staging' namespace

C.A ClusterRole and a ClusterRoleBinding

D.A Role and a ClusterRoleBinding

AnswerA

A Role defines permissions within a specific namespace, and a RoleBinding grants those permissions to a user within that same namespace. Creating both in the 'staging' namespace limits the user's ability to view Pods to that namespace only, satisfying the requirement.

Why this answer

To grant namespace-scoped permissions, the standard approach is to create a Role that defines the allowed verbs on Pods and a RoleBinding that binds that Role to the user within the 'staging' namespace. This ensures the user can view Pods only in that namespace, following the principle of least privilege.

Exam trap

The trap here is thinking that a ClusterRole and RoleBinding is the only way to grant namespaced access, but a simple Role and RoleBinding is sufficient and more precise.

Full explanation →

430

MCQmedium

You want to view the logs of a container named 'app' inside a pod named 'web-pod-7d4f8'. Which kubectl command should you use?

A.kubectl exec web-pod-7d4f8 -c app -- logs

B.kubectl log web-pod-7d4f8 --container app

C.kubectl logs web-pod-7d4f8 -c app

D.kubectl logs web-pod-7d4f8 app

AnswerC

kubectl logs retrieves stdout/stderr from a single container, and the -c flag selects which container when a pod holds several. Naming web-pod-7d4f8 with -c app satisfies the stem's requirement to target the container named 'app'.

Why this answer

The `kubectl logs` command is the standard way to retrieve container logs in Kubernetes. The `-c` flag specifies the container name within the pod, which is necessary when a pod contains multiple containers. Here, the container is named 'app' inside the pod 'web-pod-7d4f8', so `kubectl logs web-pod-7d4f8 -c app` correctly fetches its logs.

Exam trap

In the KCNA exam, candidates often confuse 'kubectl logs' with 'kubectl exec' or use incorrect flag syntax (e.g., '--container' vs '-c'). Option C is the only correct syntax because 'kubectl logs' requires the pod name and optionally '-c' for container name.

How to eliminate wrong answers

Option A is wrong because `kubectl exec` is used to execute commands inside a running container, not to view logs; the syntax `-- logs` is invalid and would attempt to run a command named 'logs' inside the container. Option B is wrong because the correct subcommand is `kubectl logs`, not `kubectl log`; Kubernetes CLI does not accept 'log' as a valid verb. Option D is wrong because it omits the `-c` flag and instead passes the container name as a positional argument; `kubectl logs` expects the pod name as the first argument and the container name must be specified with `-c` or `--container`, not as a bare argument.

Full explanation →

431

MCQmedium

A Deployment manages ReplicaSets. What is the primary benefit of using a Deployment over directly managing ReplicaSets?

A.Deployments can expose services externally

B.Deployments support rolling updates and rollbacks

C.Deployments automatically configure DNS

D.Deployments provide persistent storage

AnswerB

Deployments add a control layer above ReplicaSets, automatically creating a new ReplicaSet for each pod template change and shifting replicas gradually. This enables rolling updates and rollback to a previous revision, which direct ReplicaSet management does not provide.

Why this answer

The primary benefit of using a Deployment over directly managing ReplicaSets is that Deployments provide declarative updates for Pods and ReplicaSets, including built-in support for rolling updates and rollbacks. This allows you to update the desired state (e.g., a new container image version) and have the Deployment controller automatically orchestrate the transition, while also enabling you to revert to a previous revision if the update fails. Directly managing ReplicaSets would require manual steps to scale down old ReplicaSets and scale up new ones, and it lacks the automated revision history and rollback capabilities that Deployments offer.

Exam trap

CNCF often tests the misconception that Deployments directly manage Pods, but the trap here is that candidates may confuse the Deployment's high-level features (like rolling updates) with other Kubernetes resources (Services, DNS, storage) that handle networking, naming, or data persistence, leading them to pick a wrong answer that describes a capability of a different resource.

How to eliminate wrong answers

Option A is wrong because Deployments do not expose services externally; that is the role of a Service (e.g., NodePort, LoadBalancer) or an Ingress resource. Option C is wrong because Deployments do not automatically configure DNS; DNS resolution for Pods and Services is handled by CoreDNS (or kube-dns) based on Service objects, not Deployments. Option D is wrong because Deployments do not provide persistent storage; persistent storage is managed through PersistentVolumeClaims (PVCs) and StorageClasses, which are referenced by Pods in a Deployment's template, but the Deployment itself does not provision or attach storage.

Full explanation →

432

MCQmedium

Which command would you use to view the logs of a container named 'sidecar' inside a pod named 'app'?

A.kubectl logs app -c sidecar

B.kubectl logs app sidecar

C.kubectl logs sidecar app

D.kubectl logs sidecar -p app

AnswerA

The -c flag selects a specific container within a multi-container pod, so kubectl logs app -c sidecar retrieves output from the sidecar container. Without -c, kubectl would default to the pod's first container, failing the stem's named-container constraint.

Why this answer

The `kubectl logs` command uses the `-c` flag to specify a container name within a pod. When a pod contains multiple containers, you must explicitly indicate which container's logs to retrieve. The syntax `kubectl logs <pod-name> -c <container-name>` is the standard way to view logs from a specific container in a multi-container pod.

Exam trap

The trap is that candidates may assume the container name can be passed as a second positional argument instead of using the `-c` flag.

How to eliminate wrong answers

Option B is wrong because `kubectl logs app sidecar` is invalid syntax; the command expects the pod name first, and the container name must be specified with the `-c` flag, not as a positional argument. Option C is wrong because `kubectl logs sidecar app` reverses the order, treating 'sidecar' as the pod name and 'app' as an unrecognized positional argument, which will fail or produce incorrect output. Option D is wrong because `kubectl logs sidecar -p app` uses the `-p` flag (for previous container logs) incorrectly; the `-p` flag does not accept a container name as its argument, and the pod name 'sidecar' is not the correct pod name in this scenario.

Full explanation →

433

MCQmedium

Which tool is primarily used for distributed tracing in cloud native environments?

A.Grafana

B.Fluentd

C.Jaeger

D.Prometheus

AnswerC

Jaeger is a CNCF distributed tracing system that records and visualises request flows across microservices, using spans and trace context propagation. This makes it the primary tool for diagnosing latency and dependency issues in cloud native environments.

Why this answer

Jaeger is an open-source, CNCF-graduated distributed tracing system originally built by Uber, designed to collect, store, and visualize traces across microservices. It implements the OpenTracing/OpenTelemetry data model and provides a UI for trace analysis, making it the canonical tracing tool in cloud native environments. Its architecture (agents, collectors, query service, storage backends) is purpose-built for distributed tracing.

Exam trap

The trap is mixing up the three observability pillars — metrics (Prometheus), logs (Fluentd), and traces (Jaeger) — and picking a tool from the wrong pillar because it is familiar from dashboards.

How to eliminate wrong answers

Option A is wrong because Grafana is a visualization/dashboarding platform — it can display tracing data (e.g., from Tempo or Jaeger) but is not itself a tracing system. Option B is wrong because Fluentd is a log collection and forwarding tool, part of the logging pipeline, not tracing. Option D is wrong because Prometheus is a metrics monitoring system with a time-series database and pull-based scraping — it handles metrics, not distributed traces.

Full explanation →

434

MCQmedium

A developer creates a Pod with a volume of type emptyDir. The Pod writes data to the volume and then is deleted. What happens to the data?

A.The data remains in the container's filesystem layer and can be recovered by restarting the container.

B.The data persists on the node and can be reused by a new Pod if the same emptyDir name is used.

C.The data is permanently deleted when the Pod is removed.

D.The data is automatically backed up to a PersistentVolume before deletion.

AnswerC

An emptyDir volume is created when a Pod is assigned to a node and exists only for the lifetime of that Pod. When the Pod is deleted, the emptyDir volume and all its data are deleted. This makes it suitable for temporary scratch space, caching, or sharing files between containers in the same Pod.

Why this answer

An emptyDir volume is ephemeral and scoped to the Pod. When the Pod is deleted, the volume is removed from the node, and its data is lost. To retain data beyond the Pod's lifetime, you must use a PersistentVolumeClaim backed by durable storage.

This behavior is fundamental for understanding stateless versus stateful workloads.

Exam trap

The trap here is confusing emptyDir with a PersistentVolume, assuming that data written to any volume persists after Pod deletion, when emptyDir is strictly temporary.

Full explanation →

435

MCQmedium

A platform team is adopting cloud-native principles for a new microservices application. They want to ensure that each service can be independently deployed and scaled without affecting other services. Which design principle BEST supports this goal?

A.Shared monolithic database for all services

B.Centralized orchestration of all service workflows

C.Synchronous request-response communication only

D.Loose coupling between services

AnswerD

Loose coupling allows services to interact through well-defined interfaces without tight dependencies, so changes or scaling of one service do not require coordinated changes in others. This directly enables independent deployment and scaling, which is a core cloud-native principle. Tight coupling would force teams to release services together and scale them in lockstep, defeating the goal.

Why this answer

Loose coupling is fundamental to cloud-native architecture because it allows each microservice to evolve, deploy, and scale independently. When services communicate through stable, well-defined interfaces and avoid shared state, teams can release changes without coordinating across the entire system. This autonomy is essential for rapid iteration and resilience in distributed environments.

Exam trap

The trap here is assuming that any form of communication or shared resource is acceptable as long as services are separate processes, when in fact coupling at the data or orchestration layer can still prevent independent deployment and scaling.

Full explanation →

436

MCQmedium

What does the 'kubectl get pods' command display?

A.Detailed information about a specific pod

B.A list of all pods in the current namespace

C.The YAML definition of a pod

D.The logs of all pods

AnswerB

kubectl get pods queries the API server for Pod objects in the active namespace, returning name, ready status, phase, restarts and age. This satisfies the listing requirement; adding --all-namespaces or -A would broaden scope beyond the current namespace.

Why this answer

The 'kubectl get pods' command lists all pods in the current namespace, providing a summary of their status, restarts, and age. This is the default behavior without specifying a namespace or pod name, making it the primary command for pod discovery and health checks.

Exam trap

The exam often tests the distinction between 'get' (list/summary) and 'describe' (detailed info), so candidates mistakenly think 'get pods' shows detailed pod information.

How to eliminate wrong answers

Option A is wrong because 'kubectl describe pod <name>' provides detailed information about a specific pod, not 'kubectl get pods'. Option C is wrong because 'kubectl get pod <name> -o yaml' outputs the YAML definition of a pod, not the plain 'kubectl get pods' command. Option D is wrong because 'kubectl logs <pod-name>' retrieves logs for a specific pod, and 'kubectl logs --all-containers=true' can target multiple containers, but there is no single command to get logs of all pods simultaneously; 'kubectl get pods' does not display logs.

Full explanation →

437

Multi-Selectmedium

Which THREE of the following are benefits of structured logging? (Select three.)

Select 3 answers

A.Easier querying and filtering

B.More human-readable than plain text

C.Reduced storage requirements

D.Machine-parseable output

E.Consistent field names across services

AnswersA, D, E

Structured logs store fields as discrete key-value pairs rather than free text, so queries can filter on specific attributes without regex parsing. This directly satisfies the stem's benefit of easier querying and filtering across large log volumes.

Why this answer

Structured logging emits events as key-value pairs (typically JSON), so option A is correct because fields like level, service, or trace_id can be queried and filtered directly in tools such as Elasticsearch, Loki, or CloudWatch Logs Insights without fragile regex parsing. Option D is correct because that same machine-parseable format lets log processors, SIEMs, and observability pipelines ingest and index records programmatically and reliably. Option E is correct because adopting a shared schema with consistent field names across services enables correlation and aggregation across distributed systems, which is a core goal of structured logging.

Option B is not a benefit: structured logs are usually less human-readable than free-form plain text, which is why pretty-printers exist. Option C is not a benefit either: JSON key-value output typically increases log size versus terse plain-text lines due to repeated field names and delimiters, so storage requirements usually grow rather than shrink.

Exam trap

KCNA often tests whether candidates understand that structured logging trades human readability and storage efficiency for machine parseability and consistency — the trap is selecting 'more human-readable' or 'reduced storage' as benefits when they are actually drawbacks or unrelated.

Full explanation →

438

MCQmedium

In serverless computing, what is the primary characteristic of Function-as-a-Service (FaaS)?

A.Stateful execution

B.Always running instances

C.Auto-scaling to zero

D.Manual scaling

AnswerC

Auto-scaling to zero means no function instances run while there is no traffic, so the platform provisions capacity only on invocation and releases it afterwards. That scale-to-zero behaviour, with no idle server cost, is the defining characteristic of FaaS.

Why this answer

The defining characteristic of FaaS is that functions are event-driven and the platform automatically scales the number of running instances from zero up to meet demand, then back down to zero when idle. This means you pay only for actual execution time, not for idle capacity. Auto-scaling to zero is what fundamentally separates FaaS from container-as-a-service or VM-based models.

Exam trap

KCNA often tests whether candidates confuse FaaS with containers or PaaS, so the trap is picking 'always running instances' because it sounds like a managed service rather than recognizing that scale-to-zero is the defining FaaS trait.

How to eliminate wrong answers

Option A is wrong because FaaS functions are stateless by design — state must be externalized to a database, cache, or object store, which is what enables the platform to spin instances up and down freely. Option B is wrong because always-running instances describe long-running containers or VMs, not FaaS; FaaS instances exist only during invocation (plus a brief warm period). Option D is wrong because manual scaling is the opposite of the FaaS model — FaaS platforms handle scaling automatically based on incoming events, with no operator intervention required.

Full explanation →

439

MCQmedium

A container image is being pushed to a private registry. What is the correct workflow?

A.Push first, then build

B.Push, tag, build

C.Build, tag, push

D.Tag after push

AnswerC

The image must first be built locally, then tagged with the private registry's repository path and version, then pushed. Tagging before pushing ensures the registry stores the image under the correct name, satisfying the private registry workflow requirement.

Why this answer

The correct container image workflow is build the image from a Dockerfile, tag it with a meaningful name (including registry host, repository, and tag), then push it to the registry. Tagging before pushing is required because the push command references the tagged image name. This sequence ensures the registry receives an image with the intended identifier.

Exam trap

The trap is a simple ordering question where candidates overthink and pick 'push, tag, build' or 'tag after push' — the exam tests whether you know that an image must exist and be tagged before it can be pushed.

How to eliminate wrong answers

Option A is wrong because you cannot push an image that has not been built — there is nothing to push. Option B is wrong because the order is inverted: pushing before building is impossible, and tagging before building is meaningless since no image exists yet. Option D is wrong because tagging after push would mean the pushed image lacks the intended tag (or was pushed under a default/incorrect tag), and the registry would not automatically receive the new tag without a subsequent push.

Full explanation →

440

Multi-Selecthard

Which TWO of the following are true about Kubernetes Pods?

Select 2 answers

A.Containers in a pod always have isolated filesystems

B.A pod is the smallest deployable unit in Kubernetes

C.A pod can contain multiple containers that share the same network namespace

D.Pods are designed to be long-lived and never terminated

E.Each container in a pod gets its own IP address

AnswersB, C

A pod wraps one or more containers sharing a network namespace and storage volumes, and it is the atomic unit Kubernetes schedules, deploys and scales. Every higher-level controller, such as a Deployment or ReplicaSet, ultimately manages pods.

Why this answer

Option B is correct because the Pod is the smallest deployable unit in Kubernetes — you cannot deploy a bare container directly; the kubelet schedules and runs Pods, and every workload object (Deployment, StatefulSet, Job, etc.) ultimately creates Pods. Option C is correct because containers within a single Pod share the same network namespace, meaning they share one IP address and can communicate over localhost, and they can also share volumes for data exchange. Option A is wrong because containers in a Pod can share volumes and, when configured, share process namespace; filesystem isolation is not guaranteed across all containers.

Option D is wrong because Pods are ephemeral by design — they are terminated, deleted, or replaced (e.g., by a ReplicaSet) and are not intended to be long-lived. Option E is wrong because the Pod, not each container, is assigned a single IP address; all containers in the Pod share that one IP.

Exam trap

The trap here is that candidates often confuse Pods with virtual machines, assuming each container gets its own IP and filesystem isolation, when in fact Pods are designed for tight coupling and shared resources.

Full explanation →

441

MCQmedium

An organization wants to implement a serverless function that scales to zero when not in use. Which technology is specifically designed to achieve this on Kubernetes?

A.Knative

B.Prometheus

C.Istio

D.Kubernetes Horizontal Pod Autoscaler (HPA)

AnswerA

Knative's Serving component manages request-driven workloads through its autoscaler, which scales pods down to zero when no traffic arrives and spins up on demand via the Activator. This directly satisfies the stem's scale-to-zero constraint, unlike standard Kubernetes Deployments, which maintain a minimum replica count.

Why this answer

Knative is a Kubernetes-based platform specifically designed to run serverless workloads, and its Serving component includes scale-to-zero as a core feature — pods are removed when there is no traffic and recreated on demand. It builds on Kubernetes primitives but adds the autoscaling and request-driven activation needed for true serverless behavior. This makes it the purpose-built answer for scale-to-zero functions on Kubernetes.

Exam trap

The trap is picking Kubernetes HPA because it sounds like the native scaling solution — candidates forget that HPA cannot scale to zero and lacks request-driven activation, which is the defining serverless requirement.

How to eliminate wrong answers

Option B is wrong because Prometheus is a metrics monitoring and alerting system, not a serverless runtime — it has no function execution or scaling capability. Option C is wrong because Istio is a service mesh providing traffic management, mTLS, and observability, not a serverless platform; it does not scale workloads to zero. Option D is wrong because Kubernetes HPA scales replicas based on metrics but has a minimum replica count of 1 by default and cannot scale to zero — it also does not provide the request-driven activation that serverless requires.

Full explanation →

442

MCQmedium

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

A.DaemonSet

B.Job

C.Deployment

D.StatefulSet

AnswerB

A Job creates one or more pods that run until successful completion, then stops — exactly matching the batch requirement. Unlike a Deployment, which maintains a continuous desired replica count and restarts pods indefinitely, a Job tracks completions and terminates once the queue's 1000 items are processed, satisfying the run-to-completion constraint.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

443

MCQmedium

You have a Kubernetes cluster with multiple namespaces. You need to allow communication only from pods with label 'app: frontend' to pods with label 'app: backend' in the same namespace. Which resource should you use?

A.RBAC Role

B.NetworkPolicy

C.PodSecurityPolicy

D.Service

AnswerB

NetworkPolicy is a namespaced resource applying label selectors to pods, with ingress rules permitting traffic only from pods labelled app: frontend to those labelled app: backend. It enforces the required pod-level segmentation, which plain Services cannot restrict.

Why this answer

NetworkPolicy is a Kubernetes resource that controls ingress and egress traffic between pods based on labels, namespaces, or IP blocks. By defining a NetworkPolicy with a podSelector matching 'app: backend' and an ingress rule that allows traffic only from pods with label 'app: frontend', you can restrict communication to only those pods in the same namespace. This is the correct approach because NetworkPolicy operates at Layer 3/4 (and optionally Layer 7 with Cilium) to enforce network segmentation.

Exam trap

The trap here is that candidates confuse RBAC (which controls API access) with network access control, assuming that a Role or RoleBinding can restrict pod-to-pod traffic, but RBAC has no effect on network-level communication.

How to eliminate wrong answers

Option A is wrong because RBAC Role controls access to Kubernetes API resources (e.g., pods, services) for users or service accounts, not network traffic between pods. Option C is wrong because PodSecurityPolicy (deprecated in v1.21, removed in v1.25) enforces security constraints on pod specifications (e.g., privileged containers, host namespaces), not network communication. Option D is wrong because a Service provides a stable endpoint for accessing a set of pods via DNS or cluster IP, but does not filter or restrict traffic based on source labels.

Full explanation →

444

MCQeasy

Which Kubernetes control plane component is responsible for maintaining the desired state of the cluster by running reconciliation loops?

A.kube-scheduler

B.etcd

C.kube-apiserver

D.kube-controller-manager

AnswerD

kube-controller-manager runs the built-in controllers whose reconciliation loops continuously compare observed cluster state against the desired state declared in objects, then act to close any drift. This directly satisfies the stem's requirement for the component maintaining desired state through reconciliation.

Why this answer

The kube-controller-manager is the control plane component that runs controller processes, each of which watches the current state of the cluster via the kube-apiserver and makes changes to drive the actual state toward the desired state defined in etcd. This reconciliation loop pattern is fundamental to Kubernetes' self-healing behavior, ensuring that resources like deployments, replica sets, and nodes match their specifications.

Exam trap

CNCF often tests the misconception that etcd is responsible for maintaining desired state because it stores the desired state, but the trap is that etcd is only a data store and does not execute reconciliation loops—that is the job of the kube-controller-manager.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning newly created pods to nodes based on resource requirements and policies, not for maintaining desired state via reconciliation loops. Option B is wrong because etcd is a distributed key-value store that holds the cluster's configuration and state data, but it does not run reconciliation logic or enforce desired state. Option C is wrong because kube-apiserver serves as the front-end for the Kubernetes control plane, exposing the REST API and validating requests, but it does not perform continuous reconciliation; it is the gateway through which controllers interact.

Full explanation →

445

MCQmedium

Which of the following best describes 'Infrastructure as Code' (IaC)?

A.Manually configuring servers via SSH

B.Using a scripting language to automate tasks

C.Running containers on a Kubernetes cluster

D.Defining infrastructure resources in a declarative configuration file

AnswerD

Declarative configuration files let you specify the desired end state of infrastructure, and the tool reconciles actual resources to match it. This satisfies IaC's core constraint: infrastructure defined reproducibly in version-controlled code rather than manual provisioning, enabling consistent, repeatable deployments across environments without imperative step-by-step commands.

Why this answer

IaC is fundamentally about declaring the desired end state of infrastructure in machine-readable configuration files (Terraform HCL, CloudFormation YAML, Kubernetes manifests) and letting a tool reconcile reality to match that declaration. Option D captures this declarative model, which is the defining characteristic of modern IaC. The key distinction is that the file describes *what* the infrastructure should look like, not the step-by-step *how*.

Exam trap

KCNA often tests the distinction between declarative (desired-state) and imperative (step-by-step) approaches, so candidates who equate 'automation' or 'scripting' with IaC pick Option B.

How to eliminate wrong answers

Option A is wrong because manually configuring servers via SSH is the antithesis of IaC — it is imperative, undocumented, non-reproducible, and prone to configuration drift. Option B is wrong because scripting (e.g., Bash, Python) is imperative automation: it describes *how* to reach a state, not the desired state itself, and re-running scripts is not idempotent in the way declarative IaC tools are. Option C is wrong because running containers on Kubernetes is a workload orchestration concern, not an infrastructure provisioning methodology — Kubernetes can itself be provisioned *via* IaC, but it is not IaC.

Full explanation →

446

MCQmedium

A development team wants to adopt a cloud-native architecture for a new application. Which set of principles BEST describes the cloud-native approach?

A.Microservices, containers, dynamic orchestration, and DevOps

B.Service-oriented architecture, bare-metal servers, static scaling, and Agile

C.Monolithic applications, virtual machines, manual scaling, and waterfall development

D.Serverless functions, virtual machines, manual provisioning, and ITIL

AnswerA

Microservices decompose the application into independently deployable services, containers package each with its dependencies, dynamic orchestration schedules and scales them across nodes, and DevOps automates delivery. Together these four principles satisfy the stem's cloud-native requirement, distinguishing it from monolithic or lift-and-shift approaches.

Why this answer

Cloud-native is defined by the CNCF as combining containers, microservices, service meshes, immutable infrastructure, and declarative APIs — with dynamic orchestration (Kubernetes) and DevOps culture as the operational backbone. Option A bundles all four pillars correctly: microservices for decomposition, containers for packaging, dynamic orchestration for scheduling/scaling, and DevOps for the cultural/process model. These four elements reinforce each other: containers enable microservices, orchestration makes containers manageable at scale, and DevOps provides the feedback loops.

Exam trap

KCNA often tests whether candidates conflate 'cloud-hosted' with 'cloud-native', so options mixing serverless with VMs or ITIL look plausible to anyone who only skims for buzzwords.

How to eliminate wrong answers

Option B is wrong because bare-metal servers and static scaling are explicitly anti-cloud-native — cloud-native relies on elastic, API-driven infrastructure, not fixed physical hosts. Option C is wrong on every count: monoliths, VMs, manual scaling, and waterfall are the traditional model that cloud-native was designed to replace. Option D is wrong because although serverless functions are cloud-native, pairing them with VMs, manual provisioning, and ITIL (a heavyweight IT service management framework) contradicts the automated, self-service, DevOps-oriented cloud-native philosophy.

Full explanation →

447

MCQeasy

A platform team wants to package a Kubernetes application — including its Deployment, Service, ConfigMap, and default configuration values — into a single versioned artifact that can be installed and rolled back as one unit. Which cloud native tool is purpose-built for this?

A.Kustomize

B.Docker Compose

C.Terraform

D.Helm

AnswerD

Helm is the Kubernetes package manager: it bundles related manifests into a chart, templates them with values, and tracks each install as a revision so rollbacks are a single command. That directly satisfies packaging, versioning, and atomic install/rollback for the described application.

Why this answer

Helm packages the Deployment, Service, ConfigMap, and default values into a chart, renders it with values at install time, and records each install as a numbered revision. That gives the team one versioned artifact plus atomic upgrade and rollback, which the other tools either cannot do or do at a different abstraction layer.

Exam trap

The trap here is assuming any YAML-management tool can package and version an application, when only Helm provides charts plus release revisions and rollback.

Full explanation →

448

MCQmedium

A platform team runs a 20-node Kubernetes cluster. They want a single Pod to run on every node so that a node-exporter agent can collect host metrics. They also want the Pod to be automatically created when a new node joins the cluster. Which workload resource should they use?

A.StatefulSet with podManagementPolicy set to Parallel

B.Deployment with replicas set to 20

C.Job with parallelism set to 20

D.DaemonSet

AnswerD

A DaemonSet ensures that a copy of the specified Pod runs on every eligible node in the cluster. When a new node is added, the DaemonSet controller schedules the Pod onto it automatically. This exactly matches the requirement for a node-level metrics agent that must exist on all 20 nodes without manual intervention.

Why this answer

A DaemonSet is the only workload controller that guarantees one Pod per eligible node and automatically schedules a Pod when a new node joins the cluster. This makes it the correct choice for node-level agents such as log collectors, metrics exporters, or storage daemons. Deployments, StatefulSets, and Jobs do not provide this per-node placement guarantee.

Exam trap

The trap here is assuming that a Deployment with a replica count equal to the number of nodes will place one Pod on each node.

Full explanation →

449

Drag & Dropmedium

Drag and drop the steps to set up a Kubernetes cluster using kubeadm into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First install runtime and Kubernetes tools, then init control plane, add network plugin, and join workers.

Full explanation →

450

Multi-Selectmedium

Which TWO of the following are control plane components? (Select TWO)

Select 2 answers

A.etcd

B.kube-apiserver

C.kube-proxy

D.kubelet

E.Container runtime

AnswersA, B

etcd is the control plane's distributed key-value store, persisting all cluster state and configuration. It runs alongside the API server on control plane nodes, satisfying the stem's requirement for a control plane component rather than a worker node process such as kubelet or kube-proxy.

Why this answer

In Kubernetes, the control plane is the set of components that make global cluster decisions and store cluster state, and etcd (A) is correct because it is the consistent, highly-available key-value store that persists all cluster data, including objects, configuration, and state. The kube-apiserver (B) is also correct because it is the central control plane component that exposes the Kubernetes API, validates and processes REST requests, and is the only component that talks directly to etcd. By contrast, kube-proxy (C) runs on each node and implements Service networking rules via iptables/IPVS, kubelet (D) is the node agent that manages Pods and containers on a worker node, and the container runtime (E) is the node-level software (e.g., containerd, CRI-O) that actually runs containers — all three are node components, not control plane components.

Exam trap

A common mistake is to think that kube-proxy or kubelet are control plane components because they are essential for cluster operation. However, they run on each node and are part of the node-level components, not the control plane.

Full explanation →

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 376–450