Kubernetes and Cloud Native Associate KCNA KCNA Questions 826–900 | Page 12/13

826

MCQmedium

A development team wants to implement GitOps for their Kubernetes deployments using ArgoCD. Which ArgoCD component is responsible for monitoring the Git repository for changes and syncing the desired state to the cluster?

A.Repo Server

B.API Server

C.Application Controller

D.Redis Server

AnswerC

The Application Controller continuously polls the Git repository, compares the desired manifests against live cluster state, and triggers sync when drift is detected. It satisfies the stem's requirement for the component that monitors Git and reconciles changes, unlike the API Server (which serves requests) or the repo server (which renders manifests).

Why this answer

The Application Controller in ArgoCD is responsible for monitoring the Git repository for changes and syncing the desired state to the Kubernetes cluster. It continuously compares the live state of applications with the desired state defined in Git and takes corrective actions to reconcile them.

Exam trap

KCNA often tests the roles of ArgoCD components, and candidates may confuse the Repo Server's role (fetching manifests) with the Application Controller's role (syncing), leading to wrong answers.

How to eliminate wrong answers

Option A is wrong because the Repo Server is responsible for cloning and parsing Git repositories to generate Kubernetes manifests, but it does not monitor for changes or sync. Option B is wrong because the API Server exposes the ArgoCD API and handles authentication, but it does not perform the sync. Option D is wrong because Redis is used for caching, not for monitoring or syncing.

Full explanation →

827

MCQeasy

A team runs a stateless API as a Deployment with six replicas across three nodes. They need a stable virtual IP and DNS name that load-balances TCP traffic to the ready replicas from other Pods in the same cluster. Which resource should they create?

A.A Service of type ClusterIP with a selector matching the Pod labels.

B.A Service of type NodePort with externalTrafficPolicy: Local.

C.An Ingress resource with a path rule for /api.

D.A NetworkPolicy that allows ingress from the API namespace.

AnswerA

A ClusterIP Service provides a stable virtual IP and DNS name inside the cluster and load-balances connections to Pods whose labels match the selector. It only includes endpoints that pass readiness checks, which fits the requirement for TCP access to ready replicas. This is the standard in-cluster exposure mechanism for a stateless API.

Why this answer

A ClusterIP Service is the native Kubernetes way to give a set of Pods a stable in-cluster virtual IP and DNS name, with kube-proxy load-balancing connections across ready endpoints. NodePort, Ingress, and NetworkPolicy serve different purposes: external node-level exposure, HTTP routing, and traffic filtering, respectively. For internal TCP load balancing to ready replicas, a ClusterIP Service with a matching selector is correct.

Exam trap

The trap here is selecting NodePort or Ingress for internal-only TCP access, when a ClusterIP Service already provides a stable virtual IP and DNS name inside the cluster.

Full explanation →

828

MCQmedium

You need to store a database password securely and make it available to a Pod as an environment variable. Which Kubernetes resource should you create?

A.Secret

B.PersistentVolume

C.ConfigMap

D.ServiceAccount

AnswerA

A Secret stores sensitive data such as passwords separately from pod specs, and it can be injected into a container as an environment variable via envFrom or valueFrom.secretKeyRef, satisfying the stem's secure storage and environment variable constraints.

Why this answer

Secrets are designed to store sensitive data, such as passwords, and can be exposed to Pods via environment variables or volumes.

Full explanation →

829

MCQmedium

A release manager asks how a GitOps controller such as Argo CD decides whether an application is in sync. Which statement accurately describes that behavior?

A.It watches container image registries and marks the application in sync whenever a newer image tag is published

B.It checks whether all Pods report Ready and marks the application in sync once every replica passes its readiness probe

C.It compares the manifests rendered from the Git repository against the live objects in the cluster and reports drift when they differ

D.It queries the Kubernetes API for the latest applied annotation and considers the application in sync when that annotation is present

AnswerC

Argo CD renders the desired manifests from Git and diffs them against the live cluster objects, marking the application OutOfSync when the two diverge. Depending on sync policy, it can surface the drift for review or automatically reconcile the cluster back to the Git-declared state.

Why this answer

GitOps defines the desired state in Git, so a controller determines sync by rendering that desired state and diffing it against the live cluster objects. Divergence produces an OutOfSync status that a human can review or an automated policy can reconcile, keeping the cluster aligned with the repository.

Exam trap

The trap here is confusing runtime health signals like image publication or Pod readiness with configuration agreement between Git and the live cluster.

Full explanation →

830

MCQeasy

Which kubectl command would you use to view detailed information about a pod named 'web-pod' in the 'default' namespace?

A.kubectl describe pod web-pod

B.kubectl get pod web-pod

C.kubectl logs web-pod

D.kubectl exec web-pod -- env

AnswerA

kubectl describe pod web-pod queries the API server for the pod's full status, including events, conditions, container states, and recent scheduling failures. It defaults to the current namespace, so the default namespace requires no extra flag.

Why this answer

The `kubectl describe pod web-pod` command retrieves detailed information about the specified pod, including its current status, events, container details, resource limits, and labels. This is the correct command for viewing comprehensive metadata and state information beyond the basic summary provided by `kubectl get`.

Exam trap

The trap here is that candidates confuse `kubectl get` with `kubectl describe`, assuming that `get` provides all details, when in fact `get` only shows a terse summary and `describe` is required for the full object dump and event history.

How to eliminate wrong answers

Option B is wrong because `kubectl get pod web-pod` only returns a concise summary of the pod's name, status, restarts, and age, not the detailed information requested. Option C is wrong because `kubectl logs web-pod` fetches the container's stdout/stderr logs, not the pod's configuration or status details. Option D is wrong because `kubectl exec web-pod -- env` runs the `env` command inside the pod's container to list environment variables, which is unrelated to viewing the pod's detailed metadata.

Full explanation →

831

MCQhard

Which of the following best describes the GitOps pattern?

A.Imperative commands applied to the cluster and tracked in Git

B.Using Git as a backup for Kubernetes manifests

C.Using Git hooks to trigger CI/CD pipelines

D.Declarative configuration stored in Git, with automated deployment via a controller

AnswerD

GitOps stores the entire desired state declaratively in Git as the single source of truth, and a controller running in the cluster continuously reconciles live state to match it, automating deployment without manual kubectl or pipeline pushes.

Why this answer

GitOps is a pattern where the entire system's desired state is declared in a Git repository, and an automated controller (such as Argo CD or Flux) continuously reconciles the live cluster state with that declarative configuration. This ensures that Git is the single source of truth, and any drift from the declared state is automatically corrected without manual intervention.

Exam trap

CNCF often tests the misconception that GitOps is simply about storing YAML files in Git or using Git as a trigger for CI/CD, when the defining characteristic is the automated reconciliation loop that enforces the desired state from Git.

How to eliminate wrong answers

Option A is wrong because GitOps relies on declarative configuration, not imperative commands; imperative commands (like kubectl run) are applied directly and are not idempotent or easily reconciled, violating the core GitOps principle of desired state stored in Git. Option B is wrong because Git is not used merely as a backup; it is the single source of truth for the desired state, and the controller actively enforces that state, not just stores copies. Option C is wrong because Git hooks are external triggers for CI/CD pipelines, but GitOps uses a pull-based model where the controller inside the cluster watches the Git repository for changes, not a push-based pipeline triggered by hooks.

Full explanation →

832

MCQeasy

Which Kubernetes control plane component is the entry point for all REST API requests?

A.kube-controller-manager

B.kube-apiserver

C.kube-scheduler

D.etcd

AnswerB

The kube-apiserver exposes the Kubernetes REST API and is the sole entry point through which all clients, including kubectl and internal components, submit requests. This satisfies the stem's requirement for the control plane's API entry point.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the sole entry point for all REST API requests. It validates and processes API calls (e.g., via kubectl, client libraries, or internal components) before persisting state to etcd or triggering other controllers. No other component directly exposes an API endpoint for external or internal management operations.

Exam trap

Some may mistakenly think etcd is the entry point because it stores all cluster data, but the apiserver is the only component that directly interfaces with etcd and exposes the Kubernetes API.

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager runs controller loops (e.g., Node Controller, Replication Controller) but does not expose a REST API; it relies on the kube-apiserver to watch and update resources. Option C is wrong because the kube-scheduler is responsible for assigning pods to nodes based on resource constraints and policies, not for handling API requests; it communicates with the apiserver to bind pods. Option D is wrong because etcd is a distributed key-value store used for cluster state persistence, not an API entry point; it is accessed only by the kube-apiserver via the etcd API (gRPC), never directly by users or other components.

Full explanation →

833

Multi-Selecteasy

Which TWO of the following are benefits of using a multi-cloud strategy? (Select TWO.)

Select 2 answers

A.Reduced network latency

B.Improved resilience and disaster recovery

C.Avoiding vendor lock-in

D.Simplified compliance

E.Increased vendor lock-in

AnswersB, C

Distributing workloads across independent cloud providers removes a single point of failure, so an outage at one vendor cannot take down the whole estate. This directly satisfies the stem's resilience and disaster-recovery benefit, since failover targets sit on separate infrastructure with no shared control plane.

Why this answer

A multi-cloud strategy distributes workloads across multiple cloud providers, so if one provider experiences an outage, applications can failover to another provider, improving overall resilience and disaster recovery. Option C is correct because using multiple cloud providers prevents dependency on a single vendor's proprietary services, avoiding vendor lock-in and giving you leverage for pricing and feature negotiations.

Exam trap

The trap here is that candidates confuse multi-cloud with hybrid cloud, assuming multi-cloud automatically improves latency or simplifies compliance, when in fact multi-cloud often increases complexity in both areas.

Full explanation →

834

MCQmedium

A pod is stuck in Pending state. Which of the following is the MOST likely reason?

A.There are insufficient resources on any available node

B.The pod is still being initialized

C.The container image is missing

D.The pod has crashed and is restarting

AnswerA

The scheduler cannot bind a Pod when no node has enough allocatable CPU or memory to satisfy its requests, leaving it Pending indefinitely. Insufficient node resources is the most frequent cause of unschedulable Pods, matching the stem's Pending symptom.

Why this answer

Pending means the pod has not been scheduled to a node, often due to insufficient resources or node constraints.

Full explanation →

835

MCQmedium

A company is running a microservices application on a Kubernetes cluster. They have noticed that one of the services, 'payment-api', is experiencing intermittent high latency. The team wants to identify the root cause without modifying the application code. Which approach should they take?

A.Monitor CPU and memory metrics from kube-state-metrics and correlate with latency.

B.Increase log verbosity for all services and search for error messages.

C.Implement distributed tracing using tools like Jaeger or Zipkin to trace requests across services.

D.Check node-level metrics using Prometheus Node Exporter.

AnswerC

Distributed tracing tracks request flow and identifies slow components.

Why this answer

Distributed tracing with tools like Jaeger or Zipkin allows you to follow a single request as it traverses multiple microservices, identifying exactly which service or call introduces latency. This approach does not require code changes (if the service mesh or sidecar proxy handles instrumentation) and is specifically designed to pinpoint performance bottlenecks in distributed systems, unlike CPU/memory metrics or log analysis which cannot trace a request's end-to-end path.

Exam trap

CNCF often tests the distinction between observability tools that provide request-level context (distributed tracing) versus aggregate resource metrics (kube-state-metrics, Node Exporter) or unstructured logs, leading candidates to mistakenly choose CPU/memory correlation or log analysis for pinpointing intermittent latency in a microservices architecture.

How to eliminate wrong answers

Option A is wrong because kube-state-metrics provides resource utilization data (CPU, memory) per pod or container, but high latency in a microservice is often caused by network delays, database contention, or upstream service failures—not necessarily correlated with local resource usage; correlation does not imply causation and cannot trace the request path. Option B is wrong because increasing log verbosity for all services generates massive volumes of unstructured data and relies on error messages that may not appear during intermittent latency spikes; logs lack the context of a specific request's journey across services, making root cause identification inefficient and often impossible. Option D is wrong because node-level metrics from Prometheus Node Exporter only show host-level resource usage (e.g., disk I/O, network bandwidth) and cannot reveal which microservice or request is causing latency within the cluster; they are useful for infrastructure troubleshooting but not for application-level distributed tracing.

Full explanation →

836

MCQhard

A platform engineer is designing a multi-tenant cluster. They want to ensure that a specific team's workloads can only be scheduled onto nodes labeled `team=blue`, and that workloads from other teams cannot be scheduled there. The team's Pods should not run on any other nodes. Which combination of Kubernetes features should the engineer use to enforce this?

A.NetworkPolicy applied to the team's namespace with a node selector.

B.Pod affinity rules alone, using requiredDuringSchedulingIgnoredDuringExecution.

C.nodeSelector on the Pods plus taints and tolerations on the nodes.

D.ResourceQuota and LimitRange applied to the team's namespace.

AnswerC

nodeSelector or nodeAffinity attracts the team's Pods to nodes labeled team=blue, while a taint such as dedicated=blue:NoSchedule on those nodes repels Pods that lack the matching toleration. Together they provide both attraction and repulsion, ensuring only the intended Pods land on those nodes and that those Pods go nowhere else. This is the standard pattern for dedicated node pools.

Why this answer

Dedicated node pools are implemented by combining attraction and repulsion. nodeSelector or nodeAffinity pulls the team's Pods toward nodes labeled team=blue, while a taint on those nodes, paired with a toleration on the Pods, keeps other workloads away. Neither feature alone provides full isolation: nodeSelector without a taint lets others share the node, and a taint without nodeSelector lets the team's Pods land elsewhere.

Exam trap

The trap here is thinking that nodeSelector alone provides isolation, when it only attracts Pods and does not repel others from the node.

Full explanation →

837

MCQmedium

A developer needs to update a running Deployment's container image from 'nginx:1.21' to 'nginx:1.23' with minimal downtime and the ability to roll back if the new version fails. Which kubectl command should be used?

A.kubectl edit deployment my-deployment

B.kubectl apply -f updated-deployment.yaml

C.kubectl patch deployment my-deployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.23"}]}}}}'

D.kubectl set image deployment/my-deployment nginx=nginx:1.23

AnswerD

The `kubectl set image` command triggers a rolling update of the Deployment, which incrementally replaces Pods running `nginx:1.21` with `nginx:1.23` while keeping the ReplicaSet available. This satisfies the minimal-downtime requirement because the controller maintains at least the desired number of healthy Pods during the transition. Additionally, the previous ReplicaSet is retained, enabling a rollback via `kubectl rollout undo` if the new image fails.

Why this answer

`kubectl set image` directly updates the container image of a running Deployment, triggering a rolling update that replaces pods gradually to minimize downtime. This command also preserves the Deployment's rollout history, enabling a simple `kubectl rollout undo` to roll back if the new image fails.

Exam trap

This question tests the misconception that any imperative command (like `edit` or `patch`) is equivalent for updating images, but the trap here is that `kubectl set image` is the simplest, most reliable imperative command specifically designed for this task, while other options introduce unnecessary complexity or risk of configuration drift.

How to eliminate wrong answers

Option A is wrong because `kubectl edit` opens an interactive editor, which is error-prone and not scriptable, and it does not inherently provide a clean rollout history for rollback. Option B is wrong because `kubectl apply` uses a declarative approach that may overwrite other changes in the live configuration if the YAML file is not fully synchronized, and it requires an updated file, adding unnecessary overhead. Option C is wrong because `kubectl patch` directly modifies the pod template spec, but it is more complex and error-prone than the dedicated `set image` command, and it does not automatically leverage the Deployment's rollout history for rollback.

Full explanation →

838

MCQeasy

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

A.kube-scheduler

B.etcd

C.kube-controller-manager

D.kube-apiserver

AnswerC

kube-controller-manager runs the built-in controllers — node, replication, endpoints and service account controllers — each watching resource state through the API server and reconciling actual state toward the declared desired state. This continuous control loop is precisely the mechanism the stem asks for when it specifies maintaining desired cluster state.

Why this answer

The kube-controller-manager is the control plane 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 bring the current state closer to the desired state. It bundles together multiple controllers (e.g., Node Controller, Replication Controller, Endpoint Controller, Service Account Controller) that each handle a specific aspect of cluster management, ensuring the cluster's actual state matches the user-defined desired state.

Exam trap

A common misconception is that etcd is responsible for maintaining the desired state because it stores the desired state. However, etcd is only a passive data store, while the kube-controller-manager is the active component that performs the actual reconciliation to enforce that state.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning newly created pods to nodes based on resource availability, policies, and constraints, not for maintaining the desired state via controllers. Option B is wrong because etcd is a distributed key-value store that serves as the cluster's backing store for all cluster data, but it does not run controllers or actively reconcile state; it only stores and retrieves the desired and current state. Option D is wrong because kube-apiserver is the front-end for the Kubernetes control plane that exposes the Kubernetes API, handles authentication, authorization, and validation of API requests, but it does not run the controller loops that enforce desired state.

Full explanation →

839

Multi-Selecthard

Which TWO statements accurately describe Kubernetes scheduling?

Select 3 answers

A.The kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints.

B.Tolerations allow a pod to be scheduled on a node with matching taints.

C.A pod with no resource requests will always be scheduled on the node with the most available resources.

D.Node affinity allows a pod to specify preferred or required nodes for scheduling.

E.Taints are applied to pods to prevent them from being scheduled on certain nodes.

AnswersA, B, D

Correct because the kube-scheduler assigns pods to nodes based on resource availability and constraints.

Why this answer

The kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints. Node affinity allows a pod to specify preferred or required nodes for scheduling. Tolerations are applied to pods and allow the scheduler to schedule pods onto nodes with matching taints (though they do not guarantee scheduling).

Taints are applied to nodes, not pods, to repel pods that do not tolerate them. A pod with no resource requests can be scheduled on any node with sufficient capacity, not necessarily the one with the most resources.

Exam trap

The KCNA exam often tests the distinction between taints (applied to nodes) and tolerations (applied to pods), and the trap here is confusing the direction of the relationship — candidates may incorrectly think taints are applied to pods to prevent scheduling on certain nodes.

Full explanation →

840

MCQmedium

Which component is responsible for ensuring that the containers in a pod are running as specified?

A.kube-apiserver

B.kube-controller-manager

C.kubelet

D.kube-proxy

AnswerC

The kubelet runs on each node as the primary agent, receiving PodSpecs and directly managing container lifecycles through the container runtime. It continuously reconciles actual container state against the declared specification, restarting or reporting containers that deviate, which satisfies the requirement that containers run as specified.

Why this answer

The kubelet is the primary node agent that runs on each worker node. It receives PodSpec definitions from the API server (or from a local file/HTTP source for static pods) and ensures that the containers described in those PodSpecs are actually running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) via the CRI to start, stop, and restart containers as needed, continuously reconciling the actual state with the desired state.

Exam trap

The trap here is that candidates often confuse the kube-controller-manager's role in managing controllers (like Deployments) with the actual node-level execution of containers, leading them to pick Option B instead of the kubelet.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the front-end for the Kubernetes control plane, exposing the REST API and validating/processing requests, but it does not directly manage container lifecycle on nodes. Option B is wrong because kube-controller-manager runs controller processes (like ReplicaSet or Node controllers) that make global decisions about cluster state, but it does not directly interact with containers on a node; it delegates execution to the kubelet. Option D is wrong because kube-proxy is a network proxy that handles service-to-pod routing and load balancing using iptables or IPVS rules, not container lifecycle management.

Full explanation →

841

MCQeasy

Which of the following is a key difference between containers and virtual machines?

A.Containers share the host OS kernel; VMs run a separate guest OS

B.Both containers and VMs share the host kernel

C.Containers have a full guest OS, VMs share the host kernel

D.Containers require a hypervisor, VMs do not

AnswerA

Containers share the host's kernel and isolate processes, so they carry no guest OS. VMs each run a complete guest operating system on virtualised hardware. This architectural difference explains containers' smaller footprint and faster startup compared with VMs.

Why this answer

The key difference is that containers virtualize at the operating system level, sharing the host OS kernel via namespaces and cgroups, while each virtual machine runs a full, separate guest OS on top of a hypervisor. This architectural distinction means containers are more lightweight and start faster, but VMs provide stronger isolation because they do not share the host kernel.

Exam trap

CNCF often tests the misconception that containers and VMs are fundamentally similar in kernel sharing, leading candidates to choose Option B, which incorrectly claims both share the host kernel.

How to eliminate wrong answers

Option B is wrong because it states both containers and VMs share the host kernel; in reality, VMs run a separate guest OS with its own kernel and do not share the host kernel. Option C is wrong because it reverses the relationship: containers do not have a full guest OS—they share the host kernel—while VMs run a full guest OS. Option D is wrong because it claims containers require a hypervisor and VMs do not; in fact, VMs require a hypervisor (Type 1 or Type 2) to manage guest OSes, while containers run directly on the host OS without a hypervisor.

Full explanation →

842

MCQmedium

A Kubernetes cluster has a Deployment running three replicas of an application. You need to update the container image to a new version with zero downtime. Which approach is most appropriate?

A.Use 'kubectl set image deployment/<name> <container>=<new-image>' to trigger a rolling update

B.Manually delete each pod and rely on the ReplicaSet to recreate them with the new image

C.Delete the Deployment and recreate it with the new image

D.Scale the Deployment to zero and then scale back up with the new image

AnswerA

Setting the image on the Deployment triggers a rolling update, which incrementally replaces pods while respecting readiness probes and maxUnavailable, so traffic continues throughout. This satisfies the zero-downtime constraint, unlike recreating pods or editing a ReplicaSet directly.

Why this answer

`kubectl set image deployment/<name> <container>=<new-image>` triggers a rolling update, which is the default update strategy for Deployments. This gradually replaces old pods with new ones, ensuring that the desired number of replicas is always available, thus achieving zero downtime.

Exam trap

CNCF often tests the misconception that manually deleting pods or scaling to zero is a valid zero-downtime strategy, but these actions cause service disruption because they do not maintain the desired number of available replicas during the update.

How to eliminate wrong answers

Option B is wrong because manually deleting pods does not update the Deployment's pod template; the ReplicaSet will recreate pods using the old image, not the new one. Option C is wrong because deleting the Deployment causes a period of unavailability until the new Deployment is created and pods are scheduled, violating zero downtime. Option D is wrong because scaling to zero removes all pods, causing downtime, and scaling back up with a new image requires a separate update step, which is not a zero-downtime approach.

Full explanation →

843

MCQmedium

Which of the following is a way to provide configuration data to a pod without baking it into the container image?

A.Using a ConfigMap

B.Using an annotation

C.Using a Secret

D.Using a PersistentVolume

AnswerA

A ConfigMap holds non-confidential key-value configuration that can be consumed as environment variables, command-line arguments or mounted files, decoupling settings from the container image. This lets the same image run across environments with different configuration, satisfying the stem's constraint.

Why this answer

A ConfigMap is a Kubernetes API object used to decouple configuration artifacts from container images, allowing you to inject configuration data (e.g., environment variables, command-line arguments, or configuration files) into pods without rebuilding the image. This is the standard way to provide non-sensitive configuration data to pods at runtime, as defined in the Kubernetes documentation.

Exam trap

Candidates often select Secret because they think all configuration data should be secure, but ConfigMap is intended for non-sensitive data.

How to eliminate wrong answers

Option B is wrong because an annotation is metadata attached to a Kubernetes object (like a pod) for non-identifying information, such as tooling hints or build details; it is not designed to be consumed as configuration data by the pod's containers. Option C is wrong because while a Secret can provide configuration data (e.g., passwords, tokens), it is specifically intended for sensitive information and is not the general-purpose mechanism for non-sensitive configuration; the question asks for a way to provide configuration data without baking it into the image, and both ConfigMap and Secret can do that, but ConfigMap is the correct answer for non-sensitive data. Option D is wrong because a PersistentVolume is a storage resource that provides persistent storage to pods via a PersistentVolumeClaim, not a mechanism for injecting configuration data like environment variables or files.

Full explanation →

844

Multi-Selecthard

Which THREE of the following are components of the OpenTelemetry project? (Select three)

Select 3 answers

A.OpenTelemetry Agent

B.OpenTelemetry API

C.OpenTelemetry SDK

D.OpenTelemetry Collector

E.OpenTelemetry Exporter

AnswersB, C, D

The OpenTelemetry API defines vendor-neutral interfaces for instrumenting code to emit traces, metrics and logs, decoupling telemetry generation from any backend. It satisfies the stem's requirement for a genuine project component, sitting alongside the SDK and Collector as one of OpenTelemetry's core building blocks.

Why this answer

The OpenTelemetry API (option B) is a core component that defines the interfaces and instrumentation primitives (Tracer, Meter, Logger) that application code uses to generate telemetry, independent of any implementation. The OpenTelemetry SDK (option C) is the concrete implementation of that API, providing the processing pipeline (span processors, samplers, exporters, resource detection) that turns API calls into exportable telemetry. The OpenTelemetry Collector (option D) is a standalone, vendor-agnostic service that receives, processes, and exports telemetry data via receivers, processors, and exporters, and is a distinct official component of the project.

Option A is incorrect because there is no product called the 'OpenTelemetry Agent'; the project ships an SDK and the Collector, not an agent by that name. Option E is incorrect because an exporter is a subcomponent within the SDK or Collector pipeline, not a top-level OpenTelemetry project component.

Exam trap

KCNA often tests whether candidates confuse the OpenTelemetry Collector with a non-existent 'Agent' component, or mistake pluggable exporters for a core project pillar.

Full explanation →

845

MCQmedium

A cluster administrator needs to grant a CI/CD service account permission to create and delete Pods only within the staging namespace, while denying access in all other namespaces. Which Kubernetes authorization mechanism should be used?

A.A PodSecurityPolicy scoped to the staging namespace

B.A NetworkPolicy with a namespaceSelector targeting staging

C.A ClusterRole and ClusterRoleBinding

D.A Role and RoleBinding in the staging namespace

AnswerD

A Role defines permissions within a single namespace, and a RoleBinding grants those permissions to a subject such as a ServiceAccount in that namespace. Creating the Role and RoleBinding in staging limits the CI/CD service account to Pod operations there, leaving other namespaces unaffected, which matches the principle of least privilege.

Why this answer

Role-based access control scopes permissions either cluster-wide or to a namespace. A Role paired with a RoleBinding in staging grants the service account permission to act on Pods only in that namespace. A ClusterRoleBinding would widen access to every namespace, while NetworkPolicy and PodSecurityPolicy address network filtering and Pod security admission respectively, not API authorization.

Exam trap

The trap here is choosing a ClusterRole with a ClusterRoleBinding because it is convenient, forgetting that a ClusterRoleBinding always grants cluster-wide access rather than namespace-scoped access.

Full explanation →

846

Multi-Selecthard

Which TWO of the following are correct about the 'kubectl apply' command compared to 'kubectl create'? (Select exactly two.)

Select 2 answers

A.kubectl apply requires the --save-config flag to record the last-applied-configuration annotation

B.kubectl apply cannot be used on resources that already exist

C.kubectl apply can create objects but not update them

D.kubectl apply can accept a directory of YAML files with -f

E.kubectl apply uses a declarative approach and can update existing objects

AnswersD, E

Both apply and create accept -f, and that flag works with a directory path, recursively processing every YAML file inside. This lets you apply a whole manifest set in one command, satisfying the directory requirement in the stem.

Why this answer

Option D is correct because 'kubectl apply -f <directory>' accepts a directory path and recursively applies all YAML/JSON manifests it contains, just like 'kubectl create -f' does. Option E is correct because 'kubectl apply' is the declarative management command: it creates the object if it does not exist and patches/updates it if it does, using the last-applied-configuration annotation to compute a three-way merge. Option A is wrong because '--save-config' is not required for apply; apply itself records the kubectl.kubernetes.io/last-applied-configuration annotation automatically (the flag is mainly used with 'kubectl create' to enable later apply).

Option B is wrong because apply is specifically designed to work on existing resources, updating them in place. Option C is wrong because apply both creates new objects and updates existing ones.

Exam trap

The trap here is that candidates often confuse `kubectl apply` with `kubectl create`, mistakenly thinking `apply` cannot update existing resources or that it requires extra flags to record configuration history, when in fact `apply` is inherently declarative and updates are its primary strength.

Full explanation →

847

MCQeasy

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

A.To manage container networking

B.To define a standard for container images

C.To orchestrate multi-container pods

D.To allow kubelet to communicate with different container runtimes

AnswerD

CRI is the abstraction layer defining gRPC interfaces that let kubelet manage containers without embedding runtime-specific code, so containerd, CRI-O and others plug in interchangeably. This satisfies the stem's requirement for kubelet communicating with different container runtimes.

Why this answer

The Container Runtime Interface (CRI) is a plugin interface that enables the kubelet to use a variety of container runtimes without needing to recompile the Kubernetes components. It defines the API for creating, starting, stopping, and deleting containers, allowing the kubelet to communicate with runtimes like containerd, CRI-O, or Docker (via dockershim, now deprecated). Option D is correct because the CRI's primary purpose is to abstract the runtime implementation from the kubelet, enabling interoperability.

Exam trap

The trap here is that candidates confuse the CRI with the CNI or OCI, assuming the CRI manages networking or image standards, when in fact it strictly defines the runtime API for container lifecycle operations.

How to eliminate wrong answers

Option A is wrong because container networking is managed by the Container Network Interface (CNI), not the CRI. Option B is wrong because container image standards are defined by the Open Container Initiative (OCI) image spec, not the CRI. Option C is wrong because orchestrating multi-container pods is a core function of the kubelet and the Kubernetes control plane, not the CRI; the CRI only handles the low-level runtime operations for individual containers within a pod.

Full explanation →

848

Multi-Selectmedium

Which TWO of the following are responsibilities of the kubelet? (Select 2)

Select 2 answers

A.Registering the node with the cluster and reporting node status

B.Ensuring that containers defined in PodSpecs are running and healthy

C.Scheduling pods onto nodes based on resource availability

D.Creating and managing network iptables rules for Services

E.Storing cluster configuration data

AnswersA, B

The kubelet runs on each node and, via its node registration and status-reporting duties, creates the Node object and periodically posts node conditions and capacity to the API server. This satisfies the stem's requirement for a genuine kubelet responsibility, distinct from control-plane scheduling.

Why this answer

Option A is correct because the kubelet is the node agent that registers its node with the API server (via a Node object) and continuously reports node status, including conditions and capacity, through the node status heartbeat mechanism. Option B is correct because the kubelet watches for PodSpecs assigned to its node and ensures the described containers are started and running, performing liveness, readiness, and startup probes to maintain container health. Option C is incorrect because pod scheduling is the responsibility of the kube-scheduler, which selects nodes based on resource availability and constraints, not the kubelet.

Option D is incorrect because Service iptables/IPVS rules are programmed by kube-proxy, not the kubelet. Option E is incorrect because cluster configuration data is stored in etcd, the cluster's key-value datastore, not managed by the kubelet.

Exam trap

A common exam trap is confusing the kubelet (node agent) with the kube-scheduler (pod placement). Candidates mistakenly assign scheduling duties to the kubelet because it is the component that actually runs the pods.

Full explanation →

849

MCQhard

A user reports that they cannot connect to a Service from within the cluster. The Service is of type ClusterIP. Running 'kubectl get endpoints service-name' shows no endpoints. What is the most likely cause?

A.The Service is not associated with a namespace

B.The Service is exposed on the wrong port

C.The kube-proxy is not running on the node

D.The Service's pod selector does not match any running pods

AnswerD

A ClusterIP Service routes traffic only to pods whose labels match its selector; an empty endpoint list means no pod satisfied that selector. Since the stem shows no endpoints, the selector likely mismatches the running pods' labels, so kube-proxy has no backend addresses to forward to.

Why this answer

A ClusterIP Service with no endpoints almost always means its label selector does not match any running pods. The endpoints controller populates the Endpoints object by matching the Service's selector against pod labels; if no pods match, the list is empty and traffic cannot be routed. This is the most common cause of the reported symptom.

Exam trap

KCNA often tests the relationship between Service selectors and pod labels, so candidates who focus on network-level causes (kube-proxy, ports) instead of the selector mismatch pick the wrong answer.

How to eliminate wrong answers

Option A is wrong because every Service in Kubernetes is associated with a namespace (default if unspecified); a Service cannot exist without a namespace, so this is not a valid cause. Option B is wrong because an incorrect port would cause connection failures but would not result in an empty endpoints list; the endpoints would still be populated. Option C is wrong because if kube-proxy were not running, the Service would still have endpoints; the failure would be in traffic routing, not endpoint discovery.

Full explanation →

850

Multi-Selecthard

A DevOps engineer is designing a Kubernetes architecture for a stateful application that requires stable network identities and persistent storage across pod rescheduling. The engineer needs to choose the appropriate Kubernetes resource types to meet these requirements. Which two resources should the engineer use? (Choose two.)

Select 2 answers

A.DaemonSet

B.StatefulSet

C.ConfigMap

D.Deployment

E.PersistentVolumeClaim

AnswersB, E

A StatefulSet provides stable, unique network identifiers (e.g., pod-0, pod-1) and stable storage through VolumeClaimTemplates. It is designed for stateful applications that require ordered deployment, scaling, and persistent volumes per pod. This directly meets the requirement for stable identities and storage across rescheduling.

Why this answer

StatefulSet is the workload controller that provides stable network identities and ordered management for stateful applications. PersistentVolumeClaim, when used in a StatefulSet's volumeClaimTemplates, ensures each pod gets its own persistent storage that survives rescheduling. Together, they meet the requirements for stable identity and persistent data.

Exam trap

The trap here is confusing stateless and stateful workload controllers, or assuming that a Deployment can provide stable identities when it cannot.

Full explanation →

851

MCQmedium

A team runs a Kubernetes cluster with Prometheus scraping application metrics. They want Prometheus to automatically discover new pods and scrape their metrics endpoints as pods are created and destroyed. Which Kubernetes resource should they configure Prometheus to use for this dynamic discovery?

A.The kubelet's embedded cAdvisor endpoint on each node

B.A static list of pod IPs in the Prometheus configuration file

C.Kubernetes API server via Prometheus's kubernetes_sd_configs

D.A ConfigMap that lists all pod names and namespaces

AnswerC

Prometheus's kubernetes_sd_configs allows it to query the Kubernetes API server to discover targets such as pods, services, and endpoints. This enables automatic scraping of new pods as they appear, without manual configuration. It is the standard method for dynamic service discovery in Kubernetes environments, making it the correct choice for this scenario.

Why this answer

Prometheus can dynamically discover targets in Kubernetes by integrating with the Kubernetes API server through kubernetes_sd_configs. This allows it to watch for pod creation and deletion events and automatically add or remove scrape targets. Static configurations or ConfigMaps require manual intervention and do not adapt to the dynamic nature of Kubernetes workloads, so they are unsuitable for this use case.

Exam trap

The trap here is assuming that any Kubernetes resource can be watched by Prometheus for discovery, when only specific service discovery mechanisms like kubernetes_sd_configs are designed for that purpose.

Full explanation →

852

Multi-Selecthard

Which TWO of the following are examples of context propagation mechanisms used in distributed tracing?

Select 2 answers

A.HTTP headers

B.Environment variables

C.Database queries

D.Shared filesystem

E.gRPC metadata

AnswersA, E

Headers like traceparent are used to propagate trace context across HTTP calls.

Why this answer

HTTP headers, such as the `traceparent` and `tracestate` headers defined in the W3C Trace Context specification, are the standard mechanism for propagating trace context across service boundaries in distributed tracing. When a service receives an incoming HTTP request, it extracts the trace ID and span ID from these headers to continue the same trace. This allows trace data to be correlated across multiple microservices as the request flows through the system.

Exam trap

CNCF often tests the distinction between static configuration mechanisms (like environment variables or shared filesystems) and dynamic, in-band propagation mechanisms (like HTTP headers and gRPC metadata) that travel with each request.

Full explanation →

853

Multi-Selectmedium

Which TWO of the following are valid Prometheus metric types? (Select two)

Select 2 answers

A.Set

B.Counter

C.Timer

D.Meter

E.Gauge

AnswersB, E

A Counter is a cumulative Prometheus metric that only increases or resets to zero on restart, suitable for totals such as requests served. PromQL's rate() and increase() functions operate on counters, distinguishing them from gauges, histograms, and summaries.

Why this answer

Option B (Counter) is correct because Prometheus defines Counter as a core metric type: a cumulative value that only increases (or resets to zero on restart), typically used for counts like total requests or errors, and queried with rate()/increase(). Option E (Gauge) is also correct because Prometheus defines Gauge as a metric type representing a value that can arbitrarily go up and down, such as temperature, memory usage, or current queue depth. The other options are not Prometheus metric types: Set, Timer, and Meter are metric abstractions found in other monitoring libraries/systems (for example, Dropwizard Metrics or Micrometer), not in the Prometheus client data model, whose four types are Counter, Gauge, Histogram, and Summary.

Exam trap

KCNA often tests whether candidates confuse Prometheus metric types with StatsD (Set, Timer) or OpenTelemetry (Meter) terminology, so memorizing the exact four Prometheus types is essential.

Full explanation →

854

MCQmedium

You need to store a database password securely and expose it to a Pod as an environment variable. Which Kubernetes resource should you use?

A.Service

B.PersistentVolumeClaim

C.Secret

D.ConfigMap

AnswerC

A Secret stores sensitive data such as passwords separately from Pod specifications, and can be injected into containers as environment variables via envFrom or valueFrom. This satisfies the stem's requirement to store the database password securely while exposing it as an environment variable.

Why this answer

A Secret is the correct Kubernetes resource for storing sensitive data like database passwords because it encodes the value in base64 and can be injected into a Pod as an environment variable. Unlike ConfigMaps, Secrets are designed for confidential information and support optional encryption at rest when etcd is configured accordingly.

Exam trap

Many candidates mistakenly assume that ConfigMaps are suitable for all configuration data, including passwords. However, Secrets are specifically designed for sensitive information and support optional encryption at rest, whereas ConfigMaps store data in plain text.

How to eliminate wrong answers

Option A is wrong because a Service is a network abstraction that exposes a set of Pods as a stable endpoint, not a storage mechanism for sensitive data. Option B is wrong because a PersistentVolumeClaim is used to request persistent storage volumes for Pods, not for storing small secret values like passwords. Option D is wrong because a ConfigMap stores non-sensitive configuration data in plain text and is not intended for secrets; using it for a password would expose the value in clear text.

Full explanation →

855

MCQmedium

A developer needs to deploy a stateless application with three replicas and ensure that updates are rolled out with zero downtime. Which Kubernetes resource is most appropriate?

A.Deployment

B.StatefulSet

C.Job

D.DaemonSet

AnswerA

A Deployment manages a ReplicaSet that maintains three identical, interchangeable pods and performs rolling updates, replacing pods gradually so service stays available. Statelessness suits this model; StatefulSet would add unnecessary stable identities and ordering guarantees.

Why this answer

A Deployment is the correct resource because it manages a ReplicaSet to ensure the desired number of pod replicas (three) are running, and it supports rolling updates with configurable strategies (e.g., maxSurge and maxUnavailable) to achieve zero-downtime updates. Stateless applications are ideal for Deployments since pods are interchangeable and can be replaced without data loss.

Exam trap

The trap here is that candidates might choose StatefulSet because they associate 'replicas' with stateful workloads, but the question explicitly states 'stateless application,' making Deployment the correct choice for rolling updates with zero downtime.

How to eliminate wrong answers

Option B is wrong because StatefulSet is designed for stateful applications requiring stable, unique network identities and persistent storage, not for stateless apps, and its rolling update behavior is more conservative (e.g., pod ordinal ordering) but still can achieve zero downtime; however, it is not the most appropriate for a stateless app. Option C is wrong because a Job is intended for batch or one-time tasks that run to completion, not for continuously running stateless applications with multiple replicas or rolling updates. Option D is wrong because a DaemonSet ensures one pod per node (or a subset) for cluster-wide services like logging or monitoring, not for deploying a specific number of replicas (three) across the cluster.

Full explanation →

856

MCQeasy

A developer runs `kubectl create configmap app-config --from-literal=LOG_LEVEL=debug` and then creates a Pod that references this ConfigMap as a volume. After the ConfigMap is updated with `kubectl edit configmap app-config` to change LOG_LEVEL to info, the application inside the running Pod still reads LOG_LEVEL=debug. What is the most likely reason?

A.ConfigMaps mounted as volumes are immutable after Pod creation; the Pod must be deleted and recreated to pick up changes.

B.ConfigMap volumes are updated automatically, but the application must be designed to reload the file; the kubelet sync period may cause a delay.

C.The ConfigMap was created in a different namespace than the Pod, so the volume mount silently falls back to the original literal value.

D.Environment variables sourced from ConfigMaps are updated live, but volume-mounted ConfigMaps are cached indefinitely by the container runtime.

AnswerB

When a ConfigMap is mounted as a volume, the kubelet periodically syncs the projected volume, so the file on disk is eventually updated. However, the application must watch for file changes and reload the configuration; many applications read the file only at startup. A delay up to the kubelet sync period and cache TTL can also occur, so the old value may still be seen temporarily.

Why this answer

The key fact is that volume-mounted ConfigMaps are eventually updated on disk by the kubelet, but the application must detect and reload the change. Environment variables from ConfigMaps are fixed at container start. The observed stale value is therefore explained by the application not reloading the file, possibly combined with the kubelet sync interval.

This is a common operational nuance.

Exam trap

The trap here is assuming that updating a ConfigMap immediately changes what a running application sees, when volume updates are eventual and environment variables are static.

Full explanation →

857

Multi-Selectmedium

Which TWO of the following are valid Prometheus metric types? (Select two.)

Select 2 answers

A.Log

B.Counter

C.Event

D.Histogram

E.Trace

AnswersB, D

Counter metrics only increase monotonically, resetting solely on process restart, which satisfies Prometheus's requirement for cumulative time-series data such as request totals. This monotonic behaviour distinguishes it from gauges, which rise and fall freely, and makes Counter one of the four valid Prometheus metric types alongside Gauge, Histogram and Summary.

Why this answer

Option B (Counter) is correct because Counter is one of the four core Prometheus metric types, representing a cumulative value that only increases (or resets to zero on restart), such as http_requests_total. Option D (Histogram) is also correct because Histogram is a core Prometheus metric type that samples observations into configurable buckets and exposes _bucket, _sum, and _count series, commonly used for request durations or response sizes. The other options do not belong: Log (A) and Trace (E) are observability signal categories (logs and distributed traces) rather than Prometheus metric types, and Event (C) is not a Prometheus metric type—Prometheus has Gauge and Summary as its other two types, but neither is listed here.

Exam trap

KCNA often tests whether candidates confuse observability signal types (logs, metrics, traces) with Prometheus metric types, so options like 'Log' and 'Trace' look plausible but are not Prometheus metric primitives.

Full explanation →

858

Multi-Selecteasy

Which two statements about Pods are true? (Select TWO)

Select 2 answers

A.A Pod can only contain one container

B.Containers in the same Pod share the same network namespace

C.A Pod is automatically recreated if its Node fails

D.A Pod is the smallest deployable unit in Kubernetes

E.Pods are always created directly by users

AnswersB, D

Containers within one Pod share a single network namespace, so they share an IP address and port space and communicate via localhost. This satisfies the shared-networking statement, distinguishing Pods from separate containers that each hold their own network stack.

Why this answer

Option B is correct because all containers within a single Pod share the same network namespace, meaning they share the same IP address and port space and can communicate with each other via localhost. Option D is correct because the Pod is the smallest deployable unit in Kubernetes; you cannot deploy or schedule a single container directly without wrapping it in a Pod. Option A is incorrect because a Pod can contain multiple containers (e.g., sidecar, ambassador, or adapter patterns) that are co-scheduled and co-located.

Option C is incorrect because a Pod is not automatically recreated if its Node fails; only Pods managed by a controller such as a ReplicaSet or Deployment are rescheduled and recreated. Option E is incorrect because users typically create Pods indirectly through controllers like Deployments, ReplicaSets, or StatefulSets, and bare Pods created directly are not rescheduled if they fail.

Exam trap

A common misconception is that a Pod is the smallest unit of scheduling and that it is automatically recreated on node failure, but the trap here is that Pods themselves are ephemeral and rely on controllers (such as ReplicaSets or Deployments) for recovery, not automatic recreation by the scheduler.

Full explanation →

859

MCQmedium

A team uses Argo CD to manage a production cluster. A developer commits a change to the Git repository that declares a Deployment with three replicas, but someone later manually scales the Deployment to five replicas using kubectl. What does Argo CD report and do by default?

A.It reports the application as OutOfSync and, with auto-sync enabled, reverts the live Deployment to three replicas.

B.It updates the Git repository to record five replicas so the declared state matches the cluster.

C.It ignores the manual change until the next Git commit touches the same Deployment.

D.It reports the application as Synced because the Deployment still exists and is healthy.

AnswerA

Argo CD continuously compares the desired state in Git with the live state in the cluster. The manual scale to five replicas diverges from the declared three, so the app shows OutOfSync. If automated sync is enabled, Argo CD applies the Git state and scales the Deployment back to three replicas, enforcing Git as the source of truth.

Why this answer

Argo CD enforces Git as the single source of truth. A manual scale creates drift, which Argo CD detects as OutOfSync, and with automated sync enabled it applies the Git manifest to restore the declared replica count, undoing the out-of-band change.

Exam trap

The trap here is thinking Argo CD syncs the cluster to Git only when Git changes, when it also detects and corrects drift from manual cluster edits.

Full explanation →

860

MCQmedium

A developer creates a Pod with a single container that writes logs to stdout. The Pod is scheduled and running, but the developer needs to view the logs from the past hour. Which kubectl command should the developer use?

A.kubectl get events --field-selector involvedObject.name=mypod

B.kubectl describe pod mypod

C.kubectl logs mypod --since=1h

D.kubectl exec mypod -- cat /var/log/app.log

AnswerC

The kubectl logs command retrieves container logs, and the --since flag limits output to logs generated within a relative duration. Using --since=1h returns only entries from the last hour, exactly matching the requirement. It works for a single-container Pod without needing a container name.

Why this answer

Container logs are captured from stdout and stderr by the container runtime and exposed through kubectl logs. The --since flag filters entries by relative time, so --since=1h returns exactly the last hour. Describing the Pod, executing commands inside the container, or listing events all fail to retrieve the application's stdout logs.

Exam trap

The trap here is assuming kubectl describe or kubectl get events includes application logs, when they only show metadata and cluster events.

Full explanation →

861

MCQeasy

Which kubectl command would you use to view the detailed state of a pod named 'web-pod' in the 'default' namespace?

A.kubectl logs web-pod

B.kubectl get pod web-pod

C.kubectl describe pod web-pod

D.kubectl exec web-pod -- /bin/sh

AnswerC

`kubectl describe pod web-pod` retrieves the pod's full status via the API server, showing events, container states, conditions and resource details — exactly the "detailed state" the stem requests. Unlike `get`, which returns summary columns, `describe` aggregates the diagnostic context needed to inspect a specific pod in the default namespace.

Why this answer

`kubectl describe pod web-pod` retrieves a detailed, multi-section view of the pod's current state, including events, conditions, container statuses, and resource usage. This command is specifically designed for deep inspection of a Kubernetes resource, unlike `kubectl get` which shows a summary, or `kubectl logs` which shows container output.

Exam trap

The trap here is that candidates confuse `kubectl get` (which shows a summary) with `kubectl describe` (which shows detailed state), especially when the question asks for 'detailed state' — CNCF often tests this distinction by making the summary command look plausible at first glance.

How to eliminate wrong answers

Option A is wrong because `kubectl logs web-pod` fetches the stdout/stderr logs from the pod's containers, not the pod's detailed state or configuration. Option B is wrong because `kubectl get pod web-pod` outputs a concise, one-line summary of the pod (name, ready status, restarts, age) without the detailed events, conditions, or container-level information. Option D is wrong because `kubectl exec web-pod -- /bin/sh` opens an interactive shell inside the pod's primary container, which is used for debugging or running commands inside the container, not for viewing the pod's state.

Full explanation →

862

MCQeasy

A developer creates a pod that needs to securely access a database password stored in the cluster. Which Kubernetes resource should be used to inject the password as an environment variable?

A.Secret

B.ServiceAccount

C.ConfigMap

D.PersistentVolumeClaim

AnswerA

A Secret stores sensitive values such as the database password and can be injected into a pod as an environment variable, keeping credentials out of the image and manifest while granting the pod secure access.

Why this answer

A Secret is the correct Kubernetes resource for injecting sensitive data like a database password into a Pod as an environment variable. Secrets store base64-encoded data and are designed specifically for confidential information, unlike ConfigMaps which store non-sensitive configuration. When mounted as environment variables, Secrets ensure the password is not exposed in plaintext in the Pod specification or image layers.

Exam trap

CNCF often tests the distinction between ConfigMaps and Secrets, trapping candidates who assume ConfigMaps can handle sensitive data because both resources can inject environment variables, but Secrets are the only secure choice for passwords.

How to eliminate wrong answers

Option B (ServiceAccount) is wrong because a ServiceAccount provides an identity for Pods to authenticate to the Kubernetes API server, not a mechanism to store or inject sensitive data like passwords. Option C (ConfigMap) is wrong because ConfigMaps are intended for non-sensitive configuration data; storing a password in a ConfigMap would violate security best practices and expose the secret in plaintext. Option D (PersistentVolumeClaim) is wrong because a PVC is used to request storage resources from a PersistentVolume, not to inject environment variables or store secrets.

Full explanation →

863

MCQhard

Which Kubernetes resource can be used to define network policies that control traffic between pods?

A.Service

B.PodSecurityPolicy

C.NetworkPolicy

D.Ingress

AnswerC

NetworkPolicy is the native Kubernetes API object that selects pods via label selectors and defines ingress and egress rules, so it directly satisfies the requirement to control traffic between pods. It operates at layer 3/4 and requires a CNI plugin that enforces the policies.

Why this answer

NetworkPolicy is a Kubernetes resource that defines how groups of pods are allowed to communicate with each other and other network endpoints. It works by specifying ingress and egress rules using pod selectors, namespace selectors, and IP blocks, and is enforced by a network plugin (CNI) that supports it, such as Calico or Cilium.

Exam trap

CNCF often tests the misconception that Ingress or Service can restrict pod-to-pod traffic, but Ingress only handles external HTTP/HTTPS traffic and Service only provides connectivity, not policy enforcement.

How to eliminate wrong answers

Option A is wrong because a Service is an abstraction that exposes a set of pods as a network service, but it does not control traffic between pods via rules; it only provides stable endpoints and load balancing. Option B is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) controls security-sensitive aspects of pod specification (e.g., privilege escalation, host namespaces), not network traffic between pods. Option D is wrong because an Ingress manages external HTTP/HTTPS traffic to services inside the cluster, not east-west traffic between pods.

Full explanation →

864

MCQmedium

You have a Deployment named 'web-app' with 3 replicas. You need to scale it to 5 replicas. Which kubectl command should you use?

A.kubectl create deployment web-app --replicas=5

B.kubectl scale deployment web-app --replicas=5

C.kubectl edit deployment web-app --replicas=5

D.kubectl describe deployment web-app

AnswerB

kubectl scale deployment web-app --replicas=5 updates the Deployment's spec.replicas field, causing the controller to reconcile from three to five pods. This satisfies the scaling requirement declaratively, unlike editing individual pods, which the ReplicaSet would not treat as desired state.

Why this answer

The `kubectl scale` command is the correct way to adjust the replica count of an existing Deployment. It directly modifies the `spec.replicas` field in the Deployment's desired state, instructing the ReplicaSet controller to create or delete Pods to match the new count. Option B uses the correct syntax `kubectl scale deployment web-app --replicas=5` to achieve this.

Exam trap

The trap here is that candidates confuse `kubectl create` with `kubectl scale`, thinking they can reuse the create command with a different replica count to update an existing Deployment, when in fact `create` is only for initial creation and will fail or overwrite the resource.

How to eliminate wrong answers

Option A is wrong because `kubectl create deployment` creates a new Deployment from scratch, not scaling an existing one; using `--replicas=5` would create a new Deployment named 'web-app' (or fail if it already exists), overwriting the original configuration and ignoring the existing 3 replicas. Option C is wrong because `kubectl edit deployment` opens an interactive editor for manual YAML/JSON modification, not a direct scaling command; the `--replicas` flag is not valid with `edit`, and the user would need to manually change the `spec.replicas` field, which is inefficient and error-prone. Option D is wrong because `kubectl describe deployment` only displays the current state and details of the Deployment, including its replica count, but does not perform any scaling action.

Full explanation →

865

MCQeasy

Which tool is used to manage infrastructure as code and can provision resources across multiple cloud providers?

A.Helm

B.Terraform

C.Ansible

D.AWS CloudFormation

AnswerB

Terraform's declarative HCL configuration and provider plugin architecture let a single workflow provision resources across AWS, Azure and GCP, satisfying the multi-cloud requirement. Its state file tracks real infrastructure, enabling idempotent planning and applying, unlike single-provider tools such as CloudFormation or ARM templates.

Why this answer

Terraform is the correct tool because it is an open-source infrastructure as code (IaC) software tool by HashiCorp that uses declarative configuration files (HCL) to provision and manage resources across multiple cloud providers (AWS, Azure, GCP, etc.) via provider plugins. Unlike single-cloud tools, Terraform's provider architecture allows it to manage heterogeneous environments consistently, making it the standard multi-cloud IaC solution.

Exam trap

CNCF often tests the distinction between configuration management tools (Ansible) and infrastructure provisioning tools (Terraform), leading candidates to pick Ansible because they associate 'automation' with infrastructure, but Ansible lacks native multi-cloud resource lifecycle management and state tracking.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes that deploys and manages applications on Kubernetes clusters using charts, not a tool for provisioning infrastructure across multiple cloud providers. Option C is wrong because Ansible is primarily a configuration management and automation tool that uses procedural playbooks (YAML) and agentless SSH/PowerShell connections, but it is not designed as a declarative IaC tool for multi-cloud resource provisioning; it focuses on state enforcement on existing servers rather than resource lifecycle management. Option D is wrong because AWS CloudFormation is a native AWS service that provisions resources only within the AWS ecosystem using JSON/YAML templates, and it cannot manage resources across other cloud providers like Azure or GCP.

Full explanation →

866

MCQmedium

A company is adopting a multi-cloud strategy to avoid vendor lock-in. Which pattern BEST supports deploying applications across different cloud providers with minimal changes?

A.Use a hybrid cloud approach with a single cloud for all workloads

B.Deploy applications using Kubernetes on each cloud

C.Use each cloud provider's native services directly

D.Write application code that checks the cloud provider and adapts

AnswerB

Kubernetes abstracts compute, networking and storage behind a consistent API, so the same manifests and workloads run on any conformant cluster. This directly satisfies the stem's vendor lock-in constraint: portability across providers comes from the open API surface, not from provider-specific services.

Why this answer

Deploying applications using Kubernetes on each cloud provides a consistent orchestration and API layer across providers, so workloads can be moved with minimal changes. Kubernetes abstracts compute, networking, and storage through standard primitives (Pods, Services, PVCs), reducing provider-specific coupling. This is the core pattern for portable multi-cloud deployments.

Exam trap

KCNA often tests the misconception that using native cloud services or provider-detection code achieves portability — candidates miss that Kubernetes provides the abstraction layer that minimizes changes across clouds.

How to eliminate wrong answers

Option A is wrong because a hybrid cloud with a single cloud for all workloads is not multi-cloud and does not avoid vendor lock-in. Option C is wrong because using each cloud provider's native services directly maximizes lock-in by tying the application to proprietary APIs. Option D is wrong because writing code that detects the cloud provider and adapts creates provider-specific branches, increasing complexity and coupling rather than minimizing changes.

Full explanation →

867

MCQhard

Your application consists of a frontend and a backend. The frontend needs to communicate with the backend using a stable DNS name. The backend is deployed as a Deployment with 3 replicas. Which Kubernetes resource should you create to provide a stable DNS name for the backend?

A.EndpointSlice

B.Service of type NodePort

C.Ingress

D.Service of type ClusterIP

AnswerD

A ClusterIP Service assigns a stable virtual IP and DNS name, load-balancing across the Deployment's three pod replicas. Pod IPs change on restart, so the Service abstraction provides the consistent in-cluster DNS name the frontend requires.

Why this answer

A Service of type ClusterIP provides a stable virtual IP and DNS name (e.g., my-service.namespace.svc.cluster.local) that load-balances traffic across the backend Pods. This is the correct resource because the frontend only needs a stable DNS name for internal cluster communication, and ClusterIP is the default Service type that fulfills this requirement without exposing the backend externally.

Exam trap

CNCF often tests the misconception that a Service of type NodePort is required for any DNS-based communication, but the trap here is that ClusterIP is the correct choice for internal cluster DNS stability, while NodePort is only needed for external access.

How to eliminate wrong answers

Option A is wrong because EndpointSlice is a resource that tracks network endpoints (IPs and ports) for a Service, but it does not provide a DNS name or stable endpoint itself. Option B is wrong because a Service of type NodePort exposes the backend on a static port on every Node's IP, which is intended for external access and introduces unnecessary exposure and complexity for internal-only communication. Option C is wrong because Ingress is an API object that manages external HTTP/HTTPS routing to Services, not a resource that provides a stable DNS name for internal cluster communication.

Full explanation →

868

Multi-Selectmedium

Which THREE of the following are DORA metrics?

Select 3 answers

A.Mean time to restore (MTTR)

B.Lead time for changes

C.Deployment frequency

D.Code coverage

E.Number of deployments per developer

AnswersA, B, C

Mean time to restore is a DORA metric, measuring how quickly service is restored after an incident, satisfying the stem's requirement for a recognised DORA measure. DORA's four keys comprise deployment frequency, lead time for changes, change failure rate and time to restore, so MTTR qualifies directly.

Why this answer

The four DORA (DevOps Research and Assessment) metrics are deployment frequency, lead time for changes, mean time to restore (MTTR), and change failure rate. Option A, mean time to restore (MTTR), is correct because it measures how quickly service is restored after an incident or failed deployment, one of the core DORA reliability metrics. Option B, lead time for changes, is correct because it measures the time from code commit to code running successfully in production, a core DORA throughput metric.

Option C, deployment frequency, is correct because it measures how often an organization successfully releases to production, the other core DORA throughput metric. Option D, code coverage, is not a DORA metric; it is a code-quality/testing metric that does not appear in the DORA set. Option E, number of deployments per developer, is not a DORA metric; DORA measures deployment frequency at the team/service level, not per individual developer.

Exam trap

CNCF often tests candidates by including plausible but non-DORA metrics like code coverage or deployment counts, exploiting the misconception that any useful DevOps metric qualifies as a DORA metric, when in fact only the four specific metrics (deployment frequency, lead time for changes, mean time to restore, and change failure rate) are officially defined.

Full explanation →

869

Multi-Selecteasy

Which TWO of the following are responsibilities of the kubelet on a worker node?

Select 2 answers

A.Storing cluster state in etcd

B.Scheduling Pods onto the node

C.Implementing network rules for Services

D.Ensuring containers are running as specified in the PodSpec

E.Registering the node with the control plane

AnswersD, E

The kubelet acts as the node agent, watching the API server for PodSpecs bound to its node and starting, stopping and health-checking the corresponding containers. This directly satisfies the stem's requirement that containers run as specified in the PodSpec.

Why this answer

Option D is correct because the kubelet is the node agent that watches for PodSpecs assigned to its node and actively reconciles the actual container state to match the desired state, restarting or starting containers via the container runtime (e.g., containerd or CRI-O) so they run as specified. Option E is correct because the kubelet registers its node with the control plane by creating/updating the Node object through the API server, and it periodically reports node status and heartbeats. Option A is wrong because etcd is the cluster's distributed key-value store, written to by the API server, not by the kubelet.

Option B is wrong because Pod scheduling is performed by the kube-scheduler, which selects a node and binds the Pod; the kubelet only runs Pods already assigned to it. Option C is wrong because Service network rules (iptables/IPVS or eBPF load-balancing) are implemented by the kube-proxy, not the kubelet.

Exam trap

The trap here is that candidates often confuse the kubelet's role with that of kube-proxy or the scheduler, especially because the kubelet does interact with the API server and manages Pod lifecycle, but it does not perform scheduling or network rule enforcement.

Full explanation →

870

MCQhard

A Pod is in 'CrashLoopBackOff' state. You run 'kubectl logs <pod>' and see an error that the application cannot bind to port 8080 because the port is already in use. What is the most likely cause?

A.The container's health check is misconfigured

B.The container runtime is not installed

C.The Pod's resource limits are too low

D.Another process inside the container is already using port 8080

AnswerD

A second process within the same container has already bound port 8080, so the application's bind attempt fails with EADDRINUSE and the container exits, triggering CrashLoopBackOff. This satisfies the stem's constraint: the conflict occurs inside the container's network namespace, not from another Pod or Service.

Why this answer

The 'CrashLoopBackOff' state indicates the container repeatedly starts, fails, and is restarted by the kubelet. The error message 'port is already in use' means the application inside the container cannot bind to port 8080 because another process within the same container's network namespace is already listening on that port. This is a classic application-level conflict, not a Kubernetes configuration issue.

Exam trap

The trap here is that candidates may confuse a container-level port conflict with a Kubernetes-level port conflict (e.g., hostPort or NodePort collision), but the error originates from inside the container's own network namespace, not from the host or cluster networking layer.

How to eliminate wrong answers

Option A is wrong because a misconfigured health check (e.g., liveness or readiness probe) would cause the Pod to be restarted due to probe failures, but the specific error 'port is already in use' is not a probe-related message; it is a bind system call failure. Option B is wrong because if the container runtime were not installed, the Pod would never reach the 'Running' state, let alone 'CrashLoopBackOff'; the kubelet would fail to start the container entirely. Option C is wrong because insufficient resource limits (CPU/memory) would cause the container to be OOMKilled or throttled, resulting in 'OOMKilled' or 'CrashLoopBackOff' with resource-related errors, not a 'port already in use' bind error.

Full explanation →

871

MCQmedium

You have a pod that needs to securely access a database password. Which Kubernetes resource should you use to store the password?

A.ServiceAccount

B.Secret

C.ConfigMap

D.PersistentVolume

AnswerB

Secrets store sensitive data such as passwords separately from pod specs and images, and can be mounted or injected as environment variables. This satisfies the need for secure access to the database credential rather than embedding it in plain ConfigMaps.

Why this answer

A Kubernetes Secret is specifically designed to store sensitive data, such as database passwords, in a base64-encoded format. Secrets can be mounted as volumes or exposed as environment variables in a pod, ensuring the password is not stored in plaintext in the pod specification or container image.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming both can store sensitive data, but ConfigMaps store data in plaintext and lack the security features of Secrets, such as encryption at rest and RBAC controls.

How to eliminate wrong answers

Option A is wrong because a ServiceAccount is an identity for processes running in a pod, used for authentication to the Kubernetes API server, not for storing sensitive data like passwords. Option C is wrong because a ConfigMap is intended for non-confidential configuration data, such as environment variables or configuration files, and does not provide encryption or security for sensitive values. Option D is wrong because a PersistentVolume is a storage resource for persistent data in a cluster, not a mechanism for storing secrets or passwords.

Full explanation →

872

Multi-Selecthard

Which three of the following are true about etcd in Kubernetes?

Select 3 answers

A.etcd stores all cluster state, including Pods, ConfigMaps, and Secrets

B.etcd is a relational database

C.etcd is a distributed, consistent key-value store

D.etcd can be used as a message queue

E.etcd supports watches to monitor changes to keys

AnswersA, C, E

etcd is the sole persistent backing store for the Kubernetes API server, holding every object's serialised state — Pods, ConfigMaps, Secrets and more — in a consistent, watchable key-value store. This satisfies the stem's requirement that cluster state, including those three resource types, resides in etcd.

Why this answer

Option A is correct because etcd is the backing store for the Kubernetes API server, persisting the entire cluster state — every object such as Pods, ConfigMaps, Secrets, Deployments, and ServiceAccounts — as serialized data under keys like /registry/pods. Option C is correct because etcd is architecturally a distributed, strongly consistent key-value store built on the Raft consensus algorithm, which guarantees linearizable reads and writes across its cluster members. Option E is correct because etcd exposes a watch API that lets clients subscribe to a key or key range and receive streaming notifications whenever those keys change, which is exactly how the Kubernetes API server drives its informers and controllers.

Option B is wrong because etcd is not relational: it has no tables, schemas, joins, or SQL, only a flat hierarchical keyspace. Option D is wrong because etcd is not a message queue; it offers no publish/subscribe topics, consumer groups, or delivery guarantees like RabbitMQ or Kafka, and using it as one is an anti-pattern.

Exam trap

The trap here is that candidates may confuse etcd's watch functionality with message queuing, or incorrectly assume that any database with key-value storage is relational, leading them to select options B or D.

Full explanation →

873

MCQmedium

What is the difference between a liveness probe and a readiness probe?

A.Liveness probe checks if the container is ready to serve traffic

B.Readiness probe indicates if the container is healthy; liveness indicates if it should be restarted

C.Liveness probe indicates if the container is alive; if it fails, the container is restarted

D.Both probes serve the same purpose but with different endpoints

AnswerC

The liveness probe checks whether the container is running; failure triggers a restart to recover from deadlocks or crashes. This differs from the readiness probe, which controls traffic routing, so the stated restart behaviour correctly describes liveness.

Why this answer

A liveness probe determines if a container is still running (alive). If the liveness probe fails, Kubernetes restarts the container based on the `restartPolicy`. This is distinct from a readiness probe, which checks if a container is ready to accept traffic and removes it from Service endpoints if it fails.

Exam trap

The trap here is that candidates confuse the purpose of liveness and readiness probes, often thinking liveness controls traffic routing or that readiness triggers restarts, when in fact liveness governs restarts and readiness governs traffic inclusion.

How to eliminate wrong answers

Option A is wrong because it describes the function of a readiness probe, not a liveness probe; a liveness probe checks if the container is alive, not if it is ready to serve traffic. Option B is wrong because it reverses the roles: a readiness probe indicates if the container is ready to serve traffic, while a liveness probe indicates if it is healthy (alive) and should be restarted on failure. Option D is wrong because the two probes serve different purposes—liveness for restarting unhealthy containers, readiness for traffic routing—and they can use different endpoints (e.g., `/healthz` vs `/ready`).

Full explanation →

874

Multi-Selectmedium

Which TWO statements about Kubernetes Services are correct?

Select 2 answers

A.A Service can expose only one container port

B.A Service can only route traffic to pods on the same node as the Service

C.The default Service type is ClusterIP

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

E.A Service of type NodePort exposes the service only on the node where the pod is running

AnswersC, D

If no type is specified, ClusterIP is used.

Why this answer

The default Service type in Kubernetes is ClusterIP, which exposes the Service on a cluster-internal IP address. This means the Service is only reachable from within the cluster, providing a stable internal endpoint for pod-to-pod communication without external exposure.

Exam trap

The KCNA exam often tests the misconception that a Service can only expose one port or that NodePort is node-specific, when in fact multiple ports are supported and NodePort opens the port on every node in the cluster.

Full explanation →

875

MCQmedium

What is the function of kube-proxy on a worker node?

A.It ensures the desired number of pods are running

B.It runs the container runtime

C.It reports node status to the control plane

D.It implements part of the Kubernetes Service concept by managing network rules

AnswerD

kube-proxy watches Services and Endpoints via the API server, then programs iptables or IPVS rules on each node to load-balance traffic to backing pods. This implements the Service abstraction's virtual IP and routing behaviour at the data plane.

Why this answer

kube-proxy runs on each worker node and is responsible for implementing the Kubernetes Service abstraction by managing network rules (e.g., iptables, IPVS, or userspace mode). It watches the API server for Service and EndpointSlice changes and configures local packet filtering or forwarding rules to route traffic to the correct backend pods, enabling load balancing and service discovery.

Exam trap

A common misconception is that kube-proxy handles pod lifecycle or node health reporting, when in fact those are kubelet responsibilities. Candidates often confuse the 'proxy' name with general node management.

How to eliminate wrong answers

Option A is wrong because ensuring the desired number of pods are running is the function of the ReplicaSet controller and the kubelet, not kube-proxy. Option B is wrong because running the container runtime (e.g., containerd, CRI-O) is the responsibility of the kubelet, which interacts with the CRI, while kube-proxy handles network proxying. Option C is wrong because reporting node status to the control plane is a core function of the kubelet, which sends NodeStatus updates via the Kubernetes API, not kube-proxy.

Full explanation →

876

Multi-Selectmedium

Which TWO statements about containers compared to virtual machines are correct? (Select 2)

Select 2 answers

A.Containers have lower overhead than virtual machines

B.Containers are lightweight and share the host OS kernel

C.Virtual machines share the host OS kernel

D.Each container runs its own operating system kernel

E.Virtual machines provide weaker isolation than containers

AnswersA, B

Containers share the host kernel rather than virtualising hardware, so each container avoids booting a full guest OS. This eliminates hypervisor and duplicate-kernel overhead, giving faster start-up and denser packing on the same node — directly satisfying the lower-overhead comparison the question asks for.

Why this answer

Option A is correct because containers do not run a full guest OS or hardware emulation layer; they are just isolated processes on the host kernel, so CPU, memory, and storage overhead is significantly lower than running a hypervisor plus a complete VM. Option B is correct because containers are lightweight by design and share the host operating system kernel through features like namespaces and cgroups, rather than booting their own kernel. Option C is incorrect because virtual machines do not share the host OS kernel; each VM runs its own guest OS and kernel on virtualized hardware.

Option D is incorrect because it is containers, not VMs, that share the host kernel; each container does not run its own operating system kernel. Option E is incorrect because VMs generally provide stronger isolation than containers, since the hypervisor separates each VM from the host and from other VMs, whereas containers share the same kernel.

Exam trap

The trap is confusing the isolation and kernel-sharing characteristics of containers and VMs, leading candidates to incorrectly believe VMs share the host kernel or that containers have their own kernel.

Full explanation →

877

MCQmedium

A DevOps engineer notices that after a Helm upgrade, the new pods are crash looping with 'ImagePullBackOff'. What is the most likely cause?

A.The pod's liveness probe is misconfigured

B.The Helm chart has a wrong image tag

C.The service account lacks permissions

D.The deployment's resource requests exceed node capacity

AnswerB

ImagePullBackOff means the kubelet cannot pull the specified image, most commonly because the tag referenced in the chart does not exist in the registry. A Helm upgrade that changed the image tag would produce exactly this crash-looping symptom.

Why this answer

The 'ImagePullBackOff' error indicates that Kubernetes is unable to pull the container image from the registry. The most common cause during a Helm upgrade is a misconfigured or incorrect image tag in the Helm chart's values or templates, which causes the kubelet to fail when attempting to pull the specified image. This is distinct from runtime issues like probe failures or resource constraints, which would manifest as different error states.

Exam trap

CNCF often tests the distinction between pre-start errors (ImagePullBackOff, ErrImagePull) and runtime errors (CrashLoopBackOff, probe failures), so candidates mistakenly associate any pod failure with liveness probes or resource constraints rather than image availability.

How to eliminate wrong answers

Option A is wrong because a misconfigured liveness probe would cause the pod to be restarted or killed after starting (e.g., 'CrashLoopBackOff' with a running container), not an 'ImagePullBackOff' which occurs before the container can even start. Option C is wrong because service account permissions affect API access (e.g., for listing secrets or interacting with the Kubernetes API), not the ability to pull container images from a registry; image pull failures are governed by image pull secrets and registry authentication, not RBAC on the cluster. Option D is wrong because resource requests exceeding node capacity would result in a 'Pending' or 'Unschedulable' pod status, not 'ImagePullBackOff', which is a pull-time error unrelated to scheduling.

Full explanation →

878

MCQmedium

Which component of the metrics-server provides resource metrics like CPU and memory usage?

A.kube-apiserver

B.metrics-server

C.kubelet

D.Prometheus

AnswerB

The metrics-server aggregates kubelet Summary API data from each node and exposes it through the Metrics API, which is what serves CPU and memory usage figures. It is the component itself, not a client or storage backend, satisfying the resource-metrics requirement.

Why this answer

The metrics-server is the component that collects and provides resource metrics such as CPU and memory usage in a Kubernetes cluster. It aggregates metrics from kubelets via the Summary API and exposes them through the Kubernetes API for use by Horizontal Pod Autoscaler and kubectl top. It is the canonical source for core resource metrics in KCNA-level Kubernetes.

Exam trap

KCNA often tests the distinction between kubelet (node-level metrics source), metrics-server (cluster aggregator), and Prometheus (external monitoring) — candidates confuse the raw source with the API-serving component.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the API front end that serves requests but does not itself collect or store resource metrics — it relies on the metrics-server or other adapters. Option C is wrong because kubelet runs on each node and exposes raw cAdvisor metrics, but it is not the cluster-wide component that provides aggregated resource metrics to the API. Option D is wrong because Prometheus is a third-party monitoring system that can scrape metrics but is not the built-in Kubernetes component that supplies CPU/memory metrics to the API.

Full explanation →

879

MCQhard

You have a microservices application where Service A needs to discover the IP of Service B. Both services run in the same Kubernetes cluster. Which approach is the most Kubernetes-native way for Service A to reach Service B?

A.Use the Kubernetes DNS service to resolve the Service name 'service-b'

B.Use an external service registry like Consul or etcd

C.Hardcode the cluster IP of Service B in the configuration of Service A

D.Use environment variables injected by the Kubernetes API into each pod

AnswerA

Kubernetes DNS resolves a Service name to its stable ClusterIP, letting Service A reach Service B without hard-coded pod IPs. This satisfies the requirement for a Kubernetes-native discovery mechanism, since DNS-based Service resolution is built into the cluster rather than added externally.

Why this answer

Kubernetes has a built-in DNS service (typically CoreDNS) that automatically creates DNS records for Services. When Service A resolves the name 'service-b' (or 'service-b.<namespace>.svc.cluster.local'), the DNS returns the cluster IP of Service B's Service object, which then load-balances traffic to the healthy Pods. This is the most Kubernetes-native approach because it leverages the platform's own service discovery mechanism without external dependencies.

Exam trap

The trap here is that candidates may think environment variables (Option D) are the primary Kubernetes-native method, but the exam emphasizes DNS as the modern, recommended approach, while environment variables are a legacy fallback with limitations.

How to eliminate wrong answers

Option B is wrong because using an external service registry like Consul or etcd adds unnecessary complexity and is not Kubernetes-native; Kubernetes already provides DNS-based service discovery. Option C is wrong because hardcoding the cluster IP of Service B is fragile — cluster IPs can change if the Service is recreated, and this approach does not handle scaling or Pod restarts. Option D is wrong because while Kubernetes does inject environment variables (e.g., SERVICE_B_SERVICE_HOST) for Services created before the Pod, this method is deprecated, less reliable (depends on Pod creation order), and does not update dynamically if the Service IP changes.

Full explanation →

880

MCQhard

A CI pipeline scans container images for vulnerabilities. The scan report shows a critical vulnerability in a base image layer. What is the most efficient way to remediate this issue?

A.Update the base image to a patched version and rebuild the application image

B.Use a runtime security tool to block exploitation

C.Apply a security patch directly to the running container

D.Ignore the vulnerability if the application code is not affected

AnswerA

The vulnerability originates in the base image layer, so patching application code cannot remove it. Replacing the base image with a patched tag and rebuilding propagates the fix through every derived layer in one pass.

Why this answer

The most efficient remediation for a vulnerability in a base image layer is to update the base image to a patched version and rebuild the application image. This addresses the root cause by replacing the vulnerable layer with a fixed one, ensuring that all future deployments are secure. It also aligns with immutable infrastructure practices, where containers are rebuilt rather than patched at runtime.

Exam trap

KCNA often tests the misconception that runtime security or patching running containers can substitute for rebuilding images, but the exam expects understanding of immutable infrastructure and root-cause remediation.

How to eliminate wrong answers

Option B is wrong because runtime security tools can block exploitation but do not remediate the vulnerability itself; the vulnerable code remains in the image. Option C is wrong because applying a patch directly to a running container is not persistent and violates immutable infrastructure principles; the patch would be lost on container restart. Option D is wrong because ignoring the vulnerability based on application code assumptions is risky; the base image layer may be exploited through other vectors, and compliance requirements often mandate remediation.

Full explanation →

881

MCQhard

A pod has resource requests set to 'cpu: 500m' and 'memory: 256Mi'. The node has 2 CPU cores and 4Gi memory. How many pods with the same resource requests can be scheduled on that node, assuming no other pods?

A.2

B.4

C.8

D.16

AnswerB

Scheduling is governed by requests, not limits. Memory allows 4Gi ÷ 256Mi = 16 pods; CPU allows 2000m ÷ 500m = 4 pods. The CPU request is the binding constraint, so exactly 4 pods fit on the node.

Why this answer

Each pod requests 0.5 CPU cores (500m) and 256 MiB of memory. The node has 2 CPU cores, so the CPU limit allows 2 / 0.5 = 4 pods. The node has 4 GiB of memory (4096 MiB), so the memory limit allows 4096 / 256 = 16 pods.

The tighter constraint is CPU, which permits exactly 4 pods. Option B is correct.

Exam trap

Candidates often mistakenly calculate the maximum number of pods based on memory (16) instead of CPU (4), since memory appears less restrictive. However, CPU is the tighter constraint in this scenario.

How to eliminate wrong answers

Option A is wrong because it assumes only 2 pods can fit, likely confusing the 2 CPU cores with the number of pods without dividing by the per-pod request of 500m. Option C is wrong because 8 pods would require 8 * 500m = 4 CPU cores, which exceeds the node's 2 cores. Option D is wrong because 16 pods would require 16 * 500m = 8 CPU cores, far beyond the node's capacity, even though memory alone could support 16 pods.

Full explanation →

882

MCQmedium

You need to securely store a database password for use by a Pod. Which Kubernetes resource should you use?

A.Secret

B.PersistentVolumeClaim

C.ServiceAccount

D.ConfigMap

AnswerA

Secrets hold sensitive data such as passwords, tokens and keys, base64-encoded and mountable into pods as volumes or environment variables. They keep credentials out of image layers and plain pod specs, satisfying the secure storage requirement.

Why this answer

A Secret is the correct Kubernetes resource for storing sensitive data like database passwords because it encodes the value in base64 and can be mounted as a volume or injected as an environment variable into a Pod. Unlike ConfigMaps, Secrets are designed for confidential information and support optional encryption at rest when enabled in the cluster. This ensures the password is not stored in plaintext in the Pod specification or version control.

Exam trap

CNCF often tests the misconception that ConfigMaps are suitable for all configuration data, including sensitive values, but the KCNA exam expects you to know that Secrets are the dedicated resource for confidential information like passwords and API keys.

How to eliminate wrong answers

Option B (PersistentVolumeClaim) is wrong because it is used to request storage volumes for Pods, not to store sensitive configuration data like passwords. Option C (ServiceAccount) is wrong because it provides an identity for Pods to authenticate with the Kubernetes API server, not a mechanism for storing secrets. Option D (ConfigMap) is wrong because it is intended for non-sensitive configuration data; storing a password in a ConfigMap would expose it in plaintext and violate security best practices.

Full explanation →

883

MCQmedium

A platform team needs to ensure that a critical StatefulSet pod always runs on a specific node that has local NVMe storage. The node is labeled `disktype=nvme`. Which Kubernetes scheduling mechanism should they use to guarantee this placement?

A.nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution

B.Taints and tolerations on the node

C.nodeName field in the Pod spec

D.podAffinity with preferredDuringSchedulingIgnoredDuringExecution

AnswerA

This is correct because requiredDuringSchedulingIgnoredDuringExecution enforces a hard constraint: the pod will only be scheduled on a node matching the specified label selector. In this scenario, the team can specify a nodeAffinity rule requiring the label disktype=nvme, ensuring the StatefulSet pod always lands on the node with local NVMe storage. This satisfies the guarantee requirement without manual intervention.

Why this answer

The requirement is a guaranteed placement on a node with a specific label. nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution enforces a hard rule that the pod must be scheduled on a node matching the label selector. This is the standard, declarative way to pin pods to nodes based on labels, and it works well with StatefulSets. Other options either provide only soft preferences, do not attract pods, or bypass the scheduler in a non-idiomatic way.

Exam trap

The trap here is confusing taints and tolerations with node selection: tolerations only allow a pod to be scheduled on a tainted node, but they do not require the pod to go there.

Full explanation →

884

Multi-Selectmedium

Which TWO of the following are characteristics of a Namespace in Kubernetes?

Select 2 answers

A.Namespaces are required for all Kubernetes objects

B.Namespaces provide network isolation by default

C.Resource names must be unique within a namespace, but can be reused across namespaces

D.Namespaces allow multiple virtual clusters within a physical cluster

E.Deleting a namespace deletes all objects inside it

AnswersC, D

Namespaced object names are scoped to their namespace, so two namespaces may each contain a pod named web. Cluster-scoped resources such as nodes and PersistentVolumes are exempt, which is why the uniqueness boundary is the namespace.

Why this answer

Option D is correct because a Kubernetes Namespace partitions a single physical cluster into multiple virtual clusters, letting teams or projects share the same underlying nodes and control plane while keeping their objects logically separated. Option C is correct because object names (for namespaced resources such as Pods, Services, and Deployments) must be unique within a given namespace, yet the same name can be reused in a different namespace since the namespace scopes the name. Option A is wrong because many Kubernetes objects are cluster-scoped and do not live in a namespace, such as Nodes, PersistentVolumes, StorageClasses, and ClusterRoles.

Option B is wrong because namespaces do not provide network isolation by default; Pods in different namespaces can communicate freely unless a NetworkPolicy is applied. Option E is wrong because although deleting a namespace typically garbage-collects its contents, that is a consequence of deletion rather than a defining characteristic of a namespace, and it is not one of the two marked correct answers.

Exam trap

CNCF often tests the misconception that Namespaces provide built-in network isolation, but in reality, they only offer logical grouping; network segmentation requires explicit NetworkPolicy resources.

Full explanation →

885

MCQhard

A pod in the 'default' namespace cannot reach a pod in the 'backend' namespace by service name 'db-service'. Both namespaces exist and the service is running. What is the most likely cause?

A.The pod does not have network policy allowing cross-namespace traffic

B.The service is not exposed on a port

C.The kube-proxy is not running

D.The pod is using the wrong service name format for cross-namespace access

AnswerD

Cross-namespace DNS resolution requires the fully qualified domain name `db-service.backend.svc.cluster.local`; a bare service name resolves only within the pod's own namespace. Since the stem confirms both namespaces and the service exist, the wrong name format is the most likely cause of the failed lookup.

Why this answer

D is correct because in Kubernetes, a pod in one namespace cannot reach a service in another namespace using just the service name (e.g., 'db-service'). Cross-namespace service discovery requires the fully qualified DNS name in the format <service>.<namespace>.svc.cluster.local (e.g., 'db-service.backend.svc.cluster.local'). Using only the service name resolves within the same namespace, causing the connection to fail.

Exam trap

The trap here is that candidates assume service names are globally unique across namespaces, but Kubernetes DNS scopes them to the namespace, so cross-namespace access requires the fully qualified domain name (FQDN).

How to eliminate wrong answers

Option A is wrong because network policies are not enabled by default and are not required for basic DNS-based cross-namespace communication; the issue here is DNS resolution, not network policy. Option B is wrong because if the service were not exposed on a port, it would not be reachable even within its own namespace, and the question states the service is running, implying it has a defined port. Option C is wrong because kube-proxy handles traffic routing within the cluster, but the failure occurs at the DNS resolution stage, not at the routing layer; if kube-proxy were not running, intra-namespace service access would also fail.

Full explanation →

886

MCQhard

A team wants to deploy a workload that must run on every node in a Kubernetes cluster, including new nodes added later. Which resource type should they use?

A.Deployment

B.Job

C.DaemonSet

D.StatefulSet

AnswerC

A DaemonSet ensures one pod replica runs on every eligible node, and the controller automatically schedules pods onto nodes added later. This matches the requirement for cluster-wide coverage including future nodes, unlike Deployments or StatefulSets.

Why this answer

A DaemonSet ensures that a copy of a specific pod runs on every node in the cluster, including nodes added later. This is ideal for cluster-wide services like log collectors, monitoring agents, or network plugins that must run on all nodes.

Exam trap

KCNA often tests the difference between workload types, and candidates may confuse DaemonSet with Deployment, thinking Deployments can ensure one pod per node.

How to eliminate wrong answers

Option A is wrong because a Deployment manages replicated pods but does not guarantee one pod per node; it schedules pods based on available resources. Option B is wrong because a Job runs pods to completion for batch tasks, not continuously on every node. Option D is wrong because a StatefulSet is for stateful applications requiring stable identities and persistent storage, not for running on every node.

Full explanation →

887

MCQhard

A team is building a serverless application using Knative. They want the application to scale to zero when idle. Which Knative resource type should they use?

A.Knative Serving

B.Knative Trigger

C.Knative Build

D.Knative Eventing

AnswerA

Knative Serving provides request-driven autoscaling, including scale-to-zero, by routing traffic through the Activator and manipulating Kubernetes Deployments via the autoscaler. This directly satisfies the stem's idle scale-to-zero constraint, which Knative Eventing and other resource types cannot deliver.

Why this answer

Knative Serving is the component that manages request-driven workloads and provides scale-to-zero (and scale-from-zero) capabilities. It deploys containerized services with automatic scaling based on incoming requests, including scaling down to zero replicas when idle.

Exam trap

KCNA often tests the Serving vs Eventing boundary — candidates pick Eventing or Trigger because 'serverless' sounds event-driven, but scale-to-zero for request-driven apps is a Serving feature.

How to eliminate wrong answers

Option B is wrong because a Knative Trigger is an Eventing construct that connects an event source to a subscriber (a Broker/Trigger pattern), not a compute resource with scale-to-zero. Option C is wrong because Knative Build was a deprecated build component (superseded by Tekton) for building container images, not for running serverless workloads. Option D is wrong because Knative Eventing handles event routing, brokering, and delivery — it does not provide request-driven autoscaling or scale-to-zero for application workloads.

Full explanation →

888

MCQhard

A pod in the 'default' namespace has the following YAML snippet: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 What is the effect of the fsGroup field?

A.It restricts the pod to run only on nodes with that group ID.

B.It sets the group ID for any volumes mounted into the pod.

C.It defines the group ID for the pod's service account.

D.It sets the group ID for the container's main process.

AnswerB

fsGroup applies a supplementary group ID to all processes in the pod and changes ownership of mounted volume contents, so files become group-writable. This satisfies the stem's question about volume group ownership, distinct from runAsGroup, which sets the primary group for the container process itself.

Why this answer

The `fsGroup` field in a Pod's security context sets the group ID (GID) that will be used for ownership of any volumes mounted into the pod. When a volume is mounted, Kubernetes recursively changes the group ownership of the volume's files to the specified GID (2000 in this case) and makes them readable and writable by that group. This ensures that processes running in the container, which may have a different primary group (3000 from `runAsGroup`), can still access the volume files if they are members of the fsGroup.

Exam trap

A common trap is confusing the role of `runAsGroup` (which sets the primary GID of the container process) with `fsGroup` (which sets the group ownership of mounted volumes), leading candidates to incorrectly select option D.

How to eliminate wrong answers

Option A is wrong because `fsGroup` does not restrict pod scheduling to nodes with a specific group ID; node affinity or taints/tolerations control node selection. Option C is wrong because the pod's service account group ID is unrelated to `fsGroup`; service accounts are managed via Kubernetes RBAC and do not have a group ID field in the security context. Option D is wrong because the group ID for the container's main process is set by `runAsGroup`, not `fsGroup`; `fsGroup` only affects volume file ownership, not the process's GID.

Full explanation →

889

MCQeasy

Which of the following is a primary goal of the Cloud Native Computing Foundation (CNCF)?

A.To develop the Kubernetes container orchestration platform

B.To host proprietary cloud-native solutions

C.To foster and sustain the cloud-native ecosystem of open source projects

D.To provide commercial support for Kubernetes

AnswerC

The CNCF exists to foster and sustain the cloud-native ecosystem by hosting open source projects such as Kubernetes, Prometheus and Envoy under neutral vendor governance. This differs from standards bodies that publish specifications only; the foundation actively nurtures project maturity through graduated tiers.

Why this answer

The CNCF is a vendor-neutral foundation under the Linux Foundation whose primary mission is to foster and sustain the cloud-native ecosystem by hosting and nurturing open source projects such as Kubernetes, Prometheus, Envoy, and containerd. It provides governance, legal, and marketing support to projects rather than developing them directly. This makes option C the correct description of its core goal.

Exam trap

KCNA often tests the distinction between the CNCF as a neutral foundation that hosts projects versus organizations that develop or commercially support them, so candidates must not confuse hosting with development.

How to eliminate wrong answers

Option A is wrong because Kubernetes was originally developed by Google and then donated to the CNCF; the CNCF hosts and governs the project but does not develop it. Option B is wrong because the CNCF explicitly hosts open source, vendor-neutral projects and does not support proprietary solutions. Option D is wrong because commercial support for Kubernetes is provided by vendors and service providers, not by the CNCF itself, which is a non-profit foundation.

Full explanation →

890

MCQmedium

Which tool is specifically designed for distributed tracing and was originally developed by Uber?

A.Prometheus

B.Loki

C.Grafana

D.Jaeger

AnswerD

Jaeger was created at Uber for distributed tracing, propagating context across services to reconstruct request flows and latencies. This satisfies the stem's specific origin requirement, distinguishing it from Zipkin and from metrics-only tools such as Prometheus.

Why this answer

Jaeger is an open source distributed tracing system originally developed by Uber and later donated to the CNCF, where it became a graduated project. It is designed to monitor and troubleshoot microservices-based distributed systems by tracing requests across service boundaries. This makes Jaeger the correct answer for a tool specifically built for distributed tracing and originating from Uber.

Exam trap

KCNA often tests the specific origin and purpose of observability tools, and candidates commonly confuse Jaeger with Prometheus or Grafana because all are CNCF-related observability projects.

How to eliminate wrong answers

Option A is wrong because Prometheus is a metrics monitoring and alerting toolkit, not a distributed tracing system, although it is also a CNCF project. Option B is wrong because Loki is a log aggregation system developed by Grafana Labs, focused on logs rather than traces. Option C is wrong because Grafana is a visualization and dashboarding platform that can display tracing data but is not itself a distributed tracing backend.

Full explanation →

891

MCQhard

In a GitOps workflow, a team uses ArgoCD. A developer manually changes a Deployment's replica count in the cluster via kubectl. ArgoCD has self-healing enabled. What will happen?

A.ArgoCD creates a new Deployment with the manual change

B.ArgoCD updates the Git repository to reflect the manual change

C.ArgoCD ignores the change because it was made manually

D.ArgoCD reverts the replica count to the value in Git

AnswerD

With self-healing enabled, ArgoCD's reconciliation loop detects the live replica count diverging from the Git-declared manifest and syncs the cluster back, overwriting the manual kubectl change. Git stays authoritative, so the Deployment returns to its committed replica count.

Why this answer

With self-healing enabled, ArgoCD continuously monitors the cluster for drift. When a manual change is made via kubectl, ArgoCD detects that the live state no longer matches the desired state defined in Git. It then automatically reverts the change to bring the cluster back into sync with the Git repository.

Full explanation →

892

MCQmedium

You are designing a microservices application that requires each service to be independently deployable and scalable. The services communicate over HTTP and need service discovery. Which orchestration feature BEST addresses the need for service discovery?

A.Kubernetes Service

B.Horizontal Pod Autoscaler

C.ConfigMap

D.PersistentVolume

AnswerA

A Kubernetes Service assigns a stable DNS name and virtual IP that load-balances across the backing pods, so services locate each other without tracking ephemeral pod IPs. This directly satisfies the HTTP service-discovery requirement while keeping each deployment independently scalable.

Why this answer

Kubernetes Service is the correct choice because it provides a stable network endpoint (IP address and DNS name) for a set of pods, enabling service discovery via DNS or environment variables. This allows microservices to locate and communicate with each other over HTTP without hardcoding IP addresses, which is essential for independent deployability and scalability.

Exam trap

A common trap in CNCF exams is confusing the Horizontal Pod Autoscaler (HPA), which scales pods, with the Kubernetes Service, which provides stable network endpoints for service discovery. Remember: HPA handles scaling, Service handles discovery.

How to eliminate wrong answers

Option B (Horizontal Pod Autoscaler) is wrong because it only adjusts the number of pod replicas based on CPU/memory metrics, not service discovery. Option C (ConfigMap) is wrong because it is used for injecting configuration data (e.g., environment variables) into pods, not for network endpoint resolution. Option D (PersistentVolume) is wrong because it provides storage abstraction for stateful workloads, not network-level service location.

Full explanation →

893

MCQhard

A developer needs to inject configuration data into a pod as environment variables and also mount a configuration file into a volume. The data should be decoupled from the pod specification and easily updatable without rebuilding the container image. Which Kubernetes resource should be used?

A.Secret

B.PersistentVolumeClaim

C.Downward API

D.ConfigMap

AnswerD

ConfigMap is intended for non-confidential configuration data in key-value pairs. It can be consumed as environment variables, command-line arguments, or configuration files in a volume. It decouples configuration from pod specifications, allowing updates without rebuilding images. This exactly matches the requirement to inject configuration data and mount a configuration file, making ConfigMap the correct choice.

Why this answer

ConfigMap is the standard Kubernetes resource for storing non-sensitive configuration data. It can be consumed as environment variables or mounted as files, and it separates configuration from pod definitions, allowing updates without image rebuilds. Secret is for sensitive data, Downward API for metadata, and PersistentVolumeClaim for storage, so ConfigMap is the correct answer.

Exam trap

The trap here is confusing ConfigMap with Secret; while both can inject data, ConfigMap is for non-sensitive configuration and is the appropriate choice when sensitivity is not mentioned.

Full explanation →

894

Multi-Selectmedium

Which TWO of the following are valid ways to assign a pod to a specific node?

Select 2 answers

A.nodeSelector

B.affinity: nodeAntiAffinity

C.tolerations

D.nodeName

E.podSelector

AnswersA, D

nodeSelector matches pods to nodes via labels, satisfying the requirement to pin a pod to a specific node. You add a label to the target node, then reference it under `spec.nodeSelector` in the pod manifest; the scheduler only places the pod on nodes carrying that exact label.

Why this answer

Option A (nodeSelector) is correct because it is a field in the pod spec that matches against node labels, causing the scheduler to place the pod only on nodes carrying the specified label key/value pairs. Option D (nodeName) is correct because setting spec.nodeName bypasses the scheduler entirely and directly binds the pod to the named node, which is a valid (if low-level) way to assign a pod to a specific node. Option B (affinity: nodeAntiAffinity) is incorrect because node anti-affinity repels pods from nodes matching certain labels rather than assigning a pod to a specific node.

Option C (tolerations) is incorrect because tolerations only allow a pod to be scheduled onto nodes with matching taints; they do not target a specific node. Option E (podSelector) is incorrect because podSelector is used in resources like NetworkPolicy, PodDisruptionBudget, and topology spread constraints to select pods, not to assign a pod to a node.

Exam trap

CNCF often tests the distinction between mechanisms that *constrain* scheduling (like nodeSelector and nodeAffinity) versus mechanisms that *permit* scheduling (like tolerations), and candidates mistakenly think tolerations can force a pod to a specific node when they only allow it to be scheduled on tainted nodes.

Full explanation →

895

MCQmedium

What is the primary role of the OpenTelemetry Collector?

A.To replace Prometheus for metric collection

B.To receive, process, and export telemetry data

C.To store traces and metrics long-term

D.To generate traces for applications

AnswerB

The Collector receives telemetry through receivers, processes it with processors, and exports it via exporters, acting as a vendor-neutral pipeline. This satisfies the stem's requirement to receive, process and export telemetry data as its primary function.

Why this answer

The OpenTelemetry Collector is a vendor-agnostic component that receives telemetry data (traces, metrics, logs), processes it (e.g., batching, filtering, enriching), and exports it to one or more backends. Its primary role is to decouple instrumentation from backend systems, providing a flexible pipeline for telemetry data. It does not replace Prometheus, store data long-term, or generate traces.

Exam trap

KCNA often tests the misconception that the OpenTelemetry Collector stores or generates telemetry data, when in fact it is a pipeline component that receives, processes, and exports data to backend systems.

How to eliminate wrong answers

Option A is wrong because the Collector does not replace Prometheus; it can receive metrics from Prometheus and export them to various backends, but Prometheus remains a monitoring system with its own storage and query capabilities. Option C is wrong because the Collector does not store telemetry long-term; it forwards data to backends like Jaeger, Prometheus, or commercial APMs that handle storage. Option D is wrong because the Collector does not generate traces; traces are generated by instrumented applications using OpenTelemetry SDKs, and the Collector only processes and exports them.

Full explanation →

896

MCQeasy

What is the purpose of container image scanning in a CI/CD pipeline?

A.To ensure the image is stored in a registry

B.To measure the image size and optimize it

C.To verify the image tag follows naming conventions

D.To identify security vulnerabilities in the image

AnswerD

Scanning inspects image layers and installed packages against vulnerability databases, flagging known CVEs before deployment. This directly satisfies the pipeline's need to catch insecure dependencies and base images early, preventing vulnerable artefacts from reaching the cluster.

Why this answer

Container image scanning in a CI/CD pipeline analyzes the image layers for known security vulnerabilities (CVEs) in OS packages, libraries, and application dependencies. It is a core DevSecOps practice that shifts security left, catching issues before the image is deployed to production.

Exam trap

KCNA often tests the confusion between image scanning (security vulnerability detection) and other pipeline steps like image optimization, tagging, or registry storage — candidates may pick a plausible-sounding but non-security answer.

How to eliminate wrong answers

Option A is wrong because ensuring the image is stored in a registry is a function of the push step in the pipeline, not scanning. Option B is wrong because measuring image size is an optimization concern, not a security scanning purpose — though some scanners report layer sizes, that is not their primary goal. Option C is wrong because verifying tag naming conventions is a policy enforcement or linting step, not vulnerability scanning.

Full explanation →

897

MCQhard

You run 'kubectl logs my-pod' and see: "Error from server (BadRequest): container "my-container" in pod "my-pod" is waiting to start: PodInitializing". What does this mean?

A.The container is running but producing no output

B.The container runtime is failing to start the container

C.The container has crashed and is restarting

D.The Pod is in the process of initializing and logs are not yet available

AnswerD

The BadRequest arises because the container is still in the PodInitializing phase, so its log stream does not exist yet. Init containers or image pulls must finish before the kubelet starts the main container, at which point 'kubectl logs' will return output.

Why this answer

The error 'PodInitializing' indicates that the pod's init containers are still running or the main container is waiting for init containers to complete. During this phase, the container has not started, so logs are not yet available. Option D correctly identifies that the pod is initializing and logs cannot be retrieved until the container enters the 'Running' state.

Exam trap

The trap here is that candidates confuse 'PodInitializing' with a container runtime failure or crash loop, when in fact it is a normal waiting state caused by init containers or pod initialization, not an error condition.

How to eliminate wrong answers

Option A is wrong because 'PodInitializing' means the container has not started, so it cannot be running or producing output. Option B is wrong because the error does not indicate a runtime failure; it simply means the container is waiting to start, which is a normal part of the pod lifecycle when init containers are executing. Option C is wrong because a crash loop would show 'CrashLoopBackOff' or 'Error' status, not 'PodInitializing', which is a transient state before the container starts.

Full explanation →

898

MCQeasy

An operations team wants a workload that runs exactly one Pod on every node in the cluster, including nodes added later, typically for log forwarding and node monitoring. Which Kubernetes workload resource is designed for this?

A.StatefulSet

B.DaemonSet

C.Job

D.Deployment

AnswerB

DaemonSet is purpose-built to run a copy of a Pod on every eligible node, and the DaemonSet controller automatically creates Pods for nodes that join the cluster later. It is the standard choice for node-level agents such as log shippers, monitoring exporters, and CNI or storage daemons. Taints and node selectors can scope which nodes receive the Pod, which is why control-plane nodes often need explicit tolerations.

Why this answer

A DaemonSet ensures one Pod per eligible node and extends coverage automatically as nodes join, which matches the requirement for log forwarding and node monitoring. Unlike replica-count workloads, it is node-centric rather than count-centric, and it honors taints, tolerations, and node selectors to decide which nodes receive the agent Pod.

Exam trap

The trap here is confusing count-based controllers such as Deployments with node-based coverage, which only DaemonSet guarantees.

Full explanation →

899

MCQmedium

Which of the following is NOT a responsibility of the kubelet on a worker node?

A.Performing liveness and readiness probes

B.Starting and stopping containers based on PodSpecs

C.Implementing network rules for Services

D.Reporting node and pod status to the control plane

AnswerC

Service network rules are implemented by kube-proxy, which programs iptables or IPVS rules on each node. The kubelet instead manages Pod lifecycle, volumes, and container runtime interaction, so network rule implementation falls outside its responsibilities.

Why this answer

The kubelet is the primary node agent that runs on each worker node, responsible for ensuring containers are running in a Pod as specified by the PodSpec. It performs liveness and readiness probes, starts and stops containers, and reports node and pod status to the control plane. Implementing network rules for Services, such as iptables or IPVS rules, is the responsibility of the kube-proxy, not the kubelet.

Exam trap

The trap here is that candidates often confuse the kubelet's role with kube-proxy's role, assuming the kubelet handles all networking on the node, including Service traffic routing.

How to eliminate wrong answers

Option A is wrong because the kubelet is responsible for executing liveness and readiness probes against containers and taking action based on their results (e.g., restarting containers). Option B is wrong because the kubelet directly manages container lifecycle by communicating with the container runtime (e.g., containerd, CRI-O) to start and stop containers as defined in the PodSpec. Option D is wrong because the kubelet periodically reports the node's condition and the status of each Pod to the API server via the NodeStatus and PodStatus updates.

Full explanation →

900

Multi-Selecthard

A team is designing a Kubernetes observability stack and wants to use Prometheus for metrics. They need to understand how Prometheus collects and stores time series data. Which TWO of the following statements accurately describe Prometheus? (Choose two.)

Select 2 answers

A.Prometheus requires a distributed consensus protocol to ensure data consistency across all nodes.

B.Prometheus pulls metrics from targets by scraping HTTP endpoints at regular intervals.

C.Prometheus automatically discovers and scrapes all pods in a cluster without any configuration.

D.Prometheus can only collect metrics that are pushed to it by applications using a proprietary SDK.

E.Prometheus stores data in a local time-series database optimized for append-only writes.

AnswersB, E

Prometheus uses a pull-based model, actively scraping configured targets over HTTP at defined intervals. This is a core design characteristic and is how it collects metrics from exporters, kubelets, and instrumented applications. The statement accurately reflects the scraping mechanism, so it is one of the correct descriptions of how Prometheus operates in a Kubernetes observability stack.

Why this answer

Prometheus is a pull-based monitoring system that scrapes HTTP endpoints and stores samples in a local append-only time-series database. It does not depend on distributed consensus, does not require proprietary SDKs, and does not automatically scrape all pods without configuration. The two accurate statements describe its core collection and storage mechanisms, which are essential to understand when designing a Kubernetes observability stack.

Exam trap

The trap here is assuming that Prometheus is a distributed system with automatic cluster-wide discovery, when it is actually a single-node scraper that requires explicit configuration and stores data locally.

Full explanation →

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 826–900