Kubernetes and Cloud Native Associate KCNA KCNA Questions 451–525 | Page 7/13

451

MCQhard

A pod is stuck in the Pending state. Running 'kubectl describe pod <pod-name>' shows the event: '0/3 nodes are available: 1 node had taint {node.kubernetes.io/disk-pressure: }, 2 nodes had taint {node.kubernetes.io/memory-pressure: }'. What is the most likely cause?

A.All nodes have taints that the pod does not have tolerations for

B.The container image is not found in the registry

C.The pod has a resource request that exceeds available capacity on all nodes

D.The pod's liveness probe is failing

AnswerA

The scheduler cannot bind the pod because every candidate node carries a taint — disk-pressure or memory-pressure — for which the pod declares no matching toleration. Taints repel pods lacking tolerations, so no feasible node remains and the pod stays Pending, exactly matching the "0/3 nodes are available" event.

Why this answer

The pod is stuck in Pending because the scheduler cannot find a node that satisfies its scheduling constraints. The events show that all three nodes have taints (disk-pressure and memory-pressure), and the pod does not have corresponding tolerations to allow it to be scheduled on those nodes. Without tolerations, the pod is not permitted to run on any of the available nodes, leaving it in the Pending state.

Exam trap

CNCF often tests the distinction between taints/tolerations and resource constraints, where candidates mistakenly attribute a Pending state to resource exhaustion when the actual cause is missing tolerations for node taints.

How to eliminate wrong answers

Option B is wrong because a missing container image would cause an ImagePullBackOff or ErrImagePull error, not a Pending state with node taint events. Option C is wrong because resource requests exceeding capacity would produce events like 'Insufficient memory' or 'Insufficient cpu', not taint-related messages. Option D is wrong because a failing liveness probe only affects running pods (causing restarts or CrashLoopBackOff), not pods that have never been scheduled.

Full explanation →

452

MCQmedium

A pod has a liveness probe that returns failure. What action will Kubernetes take?

A.The container will be restarted

B.The service endpoint will be removed

C.The pod will be deleted

D.The pod will be rescheduled to another node

AnswerA

A failing liveness probe signals the container is unhealthy, so the kubelet kills it and restarts it according to the pod's restartPolicy. This differs from a readiness probe, which only removes the pod from Service endpoints without restarting.

Why this answer

When a liveness probe fails, Kubernetes interprets this as the container being in a deadlock or unresponsive state from which it cannot recover without a restart. The kubelet on the node where the pod is running directly restarts the container according to the pod's restart policy (defaulting to Always). This is a container-level action, not a pod-level action, so the pod itself remains on the same node.

Exam trap

The trap here is that candidates confuse liveness probes with readiness probes, assuming a failed liveness probe removes the pod from the service endpoint, when in fact only readiness probes affect traffic routing.

How to eliminate wrong answers

Option B is wrong because service endpoints are removed only when a readiness probe fails, not a liveness probe; readiness probes control traffic routing, while liveness probes control container lifecycle. Option C is wrong because a liveness probe failure does not delete the pod; the pod continues to exist and the container is restarted in place. Option D is wrong because rescheduling to another node only happens if the pod is deleted (e.g., by a node failure or higher-level controller), not from a liveness probe failure; the kubelet handles the restart locally without involving the scheduler.

Full explanation →

453

MCQmedium

Which command would you use to apply a manifest file 'deployment.yaml' to a Kubernetes cluster?

A.kubectl run deployment.yaml

B.kubectl set image deployment.yaml

C.kubectl apply -f deployment.yaml

D.kubectl create -f deployment.yaml

AnswerC

kubectl apply -f deployment.yaml submits the manifest declaratively, creating or updating the resources it defines to match the desired state. Alternatives such as create fail on existing resources, and get or describe only read cluster state.

Why this answer

kubectl apply -f deployment.yaml is the declarative command that creates or updates resources from a manifest file, reconciling the desired state in the file with the cluster's current state. The -f flag specifies the file, and apply is idempotent — running it repeatedly produces the same result. This is the standard way to deploy manifests in Kubernetes.

Exam trap

KCNA often tests the difference between imperative and declarative kubectl commands, so the trap is picking kubectl create -f because it also accepts a file, ignoring that create is not idempotent and fails on re-application.

How to eliminate wrong answers

Option A is wrong because kubectl run is used to create a single pod or deployment imperatively from command-line flags, not to apply a YAML manifest file; passing a filename to it is invalid usage. Option B is wrong because kubectl set image is used to update the container image of an existing workload, not to apply a manifest file. Option D is wrong because kubectl create -f works only for initial creation — it fails with an 'AlreadyExists' error if the resource is already present, so it is not the idiomatic command for ongoing manifest application.

Full explanation →

454

MCQhard

A team uses a CI pipeline that builds a container image, scans it for vulnerabilities, and then pushes it to a registry. The scan reports a critical vulnerability in a library used by the application. The team wants to prevent images with critical vulnerabilities from being deployed to production. Which approach best enforces this policy in a Kubernetes-native way?

A.Enable Pod Security Admission with the restricted profile to block vulnerable images.

B.Use an admission controller such as OPA Gatekeeper to deny Pods that reference images with critical vulnerabilities.

C.Configure the CI pipeline to fail the build if the scan finds critical vulnerabilities.

D.Use a Kubernetes NetworkPolicy to block traffic to Pods running vulnerable images.

AnswerB

OPA Gatekeeper is a Kubernetes admission controller that enforces policies at admission time. By integrating with a vulnerability scanner or using a pre-populated list of vulnerable images, it can deny Pod creation if the image has critical vulnerabilities. This enforces the policy directly in the cluster, preventing deployment regardless of the CI pipeline. It is a Kubernetes-native solution that provides a strong guardrail.

Why this answer

An admission controller like OPA Gatekeeper can intercept Pod creation requests and evaluate them against policies. By integrating with vulnerability scan results, it can deny Pods that reference images with critical vulnerabilities. This enforces the policy at the cluster level, ensuring that even if an image bypasses CI checks, it cannot be deployed.

CI pipeline failure is preventive but not Kubernetes-native enforcement.

Exam trap

The trap here is thinking that CI pipeline failure alone is sufficient; the question specifically asks for a Kubernetes-native enforcement mechanism, which points to admission control.

Full explanation →

455

MCQeasy

What is the purpose of a Namespace in Kubernetes?

A.To assign IP addresses to services

B.To limit the number of pods that can be created

C.To logically isolate resources like pods and services

D.To provide DNS names for pods

AnswerC

Namespaces partition a single cluster's API resources, giving each group its own scope for names, quotas and RBAC. This satisfies the stem's requirement for logical isolation of pods and services, since identically named objects can coexist across separate namespaces.

Why this answer

Namespaces in Kubernetes provide a mechanism for logically isolating resources such as Pods, Services, and Deployments within a cluster. They enable multiple virtual clusters to coexist on the same physical cluster, allowing for resource scoping, access control, and organization by team or environment (e.g., dev, staging, prod). This isolation is fundamental to multi-tenancy and resource management in Kubernetes.

Exam trap

The trap here is that candidates confuse Namespaces with resource quotas or network isolation features, assuming Namespaces themselves enforce limits or IP assignments, when in fact they are purely logical grouping mechanisms that require additional controllers (like ResourceQuota or NetworkPolicy) to enforce constraints.

How to eliminate wrong answers

Option A is wrong because assigning IP addresses to Services is the role of the cluster IP address range and the kube-proxy component, not Namespaces; Namespaces do not manage IP allocation. Option B is wrong because limiting the number of Pods that can be created is achieved through ResourceQuotas or LimitRanges applied to a Namespace, not by the Namespace itself; a Namespace is a logical boundary, not a quota mechanism. Option D is wrong because providing DNS names for Pods is handled by CoreDNS (or kube-dns) and the cluster DNS service, which resolves Pod IPs via headless Services or Pod hostnames, not by Namespaces; Namespaces only affect DNS name scoping (e.g., <service>.<namespace>.svc.cluster.local).

Full explanation →

456

Multi-Selecthard

Which THREE statements about Labels and Selectors are correct?

Select 3 answers

A.Services use selectors to determine which Pods receive traffic

B.Selectors are used by Deployments to identify the Pods they manage

C.Labels can be used to organize and select subsets of objects

D.Labels must be unique within a namespace

E.Annotations are used for identification and selection

AnswersA, B, C

Services match Pods through label selectors, continuously evaluating which Pods satisfy the specified key-value criteria. This satisfies the stem's requirement by describing how traffic routing is decoupled from Pod identity: any Pod bearing matching labels joins the Service's endpoint list, regardless of name, IP address or node placement.

Why this answer

Option A is correct because a Service's spec.selector matches Pod labels, and the kube-proxy/EndpointSlice machinery routes traffic only to Pods whose labels satisfy that selector. Option B is correct because a Deployment (and ReplicaSet) uses spec.selector.matchLabels/matchExpressions to determine which Pods it owns and manages, ensuring it only adopts Pods matching those labels. Option C is correct because labels are arbitrary key/value metadata designed for organizing objects and for grouping/selecting subsets via label selectors (equality- and set-based).

Option D is incorrect because label keys must be unique per object, but labels are not required to be unique across a namespace—many objects can share the same labels. Option E is incorrect because annotations are non-identifying metadata and cannot be used with selectors for selection; only labels are queryable by selectors.

Exam trap

CNCF often tests the distinction between labels and annotations, trapping candidates who assume annotations can also be used for selection, when in fact only labels support selector-based filtering.

Full explanation →

457

MCQhard

You have a multi-container pod with a main application container and a sidecar container that handles log shipping. The sidecar container should start before the main container and stop after the main container finishes. Which pod configuration should you use?

A.Define the sidecar as an init container

B.Use the 'startupOrder' field in the pod spec

C.Kubernetes does not natively guarantee startup and shutdown order among containers in a pod

D.Set the sidecar container's command to a script that waits for the main container's port to become available before starting

AnswerC

Containers in a pod start in parallel and terminate in parallel; ordering is not guaranteed without custom logic.

Why this answer

Kubernetes does not provide any built-in mechanism to control the startup or shutdown order of regular containers within the same pod. All containers in a pod start simultaneously in parallel and terminate independently when the pod is deleted. The only ordering guarantee is that init containers run to completion sequentially before any regular containers start, but they cannot be used for sidecar-style log shipping that must remain running alongside the main container.

Exam trap

Kubernetes does not have a built-in mechanism to order regular container startup/shutdown; the only ordering is through init containers, which run to completion and cannot serve as long-running sidecars.

How to eliminate wrong answers

Option A is wrong because init containers run to completion and terminate before any regular containers start; they are not designed to run as long-lived sidecars that persist alongside the main container. Option B is wrong because there is no 'startupOrder' field in the pod spec; Kubernetes does not expose any such field for controlling container startup sequence. Option D is wrong because while a script could poll for a port, this is a workaround, not a native Kubernetes guarantee, and it does not address shutdown ordering — the sidecar would still be terminated at the same time as the main container during pod deletion.

Full explanation →

458

Multi-Selectmedium

Which three of the following are valid ways to interact with the Kubernetes API? (Select THREE.)

Select 3 answers

A.Using a Kubernetes client library (e.g., client-go)

B.Using the 'kubeadm' command

C.Using the Docker CLI

D.Using kubectl command-line tool

E.Direct HTTP requests to the API server using tools like curl

AnswersA, D, E

Client libraries such as client-go authenticate to the API server and issue REST calls programmatically, letting applications and controllers query or mutate cluster state. This satisfies the stem's requirement for a valid interaction method, alongside kubectl and direct REST calls, because the API server exposes an HTTP endpoint any compliant client can consume.

Why this answer

Option A is correct because Kubernetes provides official client libraries such as client-go (Go), client-python, and client-java that programmatically communicate with the API server via REST, allowing applications and controllers to create, read, update, and delete resources. Option D is correct because kubectl is the standard command-line tool that authenticates to the API server and translates commands like 'kubectl get pods' into REST API calls. Option E is correct because the Kubernetes API server exposes a RESTful HTTP API, so tools like curl can send authenticated requests directly to endpoints such as /api/v1/namespaces/default/pods.

Option B is not a way to interact with the API; kubeadm is a bootstrap tool for initializing clusters and joining nodes, not for querying or managing API resources. Option C is incorrect because the Docker CLI manages containers on a Docker daemon and has no native interface to the Kubernetes API server.

Exam trap

A common pitfall is confusing cluster management tools (like kubeadm) with API interaction tools. kubeadm is used for bootstrapping and managing Kubernetes clusters, not for querying or modifying cluster resources via the API.

Full explanation →

459

MCQeasy

Which command is used to view detailed information about a specific pod?

A.kubectl exec pod -- /bin/sh

B.kubectl logs pod

C.kubectl describe pod

D.kubectl get pod

AnswerC

kubectl describe pod fetches the Pod's full status, events, conditions, container states and resource details from the API server, which is what detailed inspection requires. kubectl logs only shows container output, and kubectl get pod returns a summary.

Why this answer

The `kubectl describe pod` command retrieves detailed information about a specific pod, including its current state, events, labels, annotations, container details, resource limits, and volume mounts. This is the standard Kubernetes command for inspecting the full configuration and lifecycle of a pod object, as opposed to the summary view provided by `kubectl get pod`.

Exam trap

A common mistake is selecting `kubectl get pod` instead of `kubectl describe pod`. While `kubectl get` provides a summary view, `kubectl describe` returns detailed information including events, state, and configuration.

How to eliminate wrong answers

Option A is wrong because `kubectl exec pod -- /bin/sh` is used to execute a command inside a running container within a pod, not to view pod details. Option B is wrong because `kubectl logs pod` retrieves the stdout/stderr logs from a container in the pod, not the pod's metadata or configuration. Option D is wrong because `kubectl get pod` only displays a concise list of pods with basic fields like name, status, and age, without the detailed information that `kubectl describe` provides.

Full explanation →

460

Multi-Selecthard

Which THREE of the following are true about Kubernetes Namespaces?

Select 3 answers

A.PersistentVolumes are namespaced

B.NetworkPolicy can be used to control traffic between pods in different namespaces

C.Nodes are namespaced resources

D.You can apply ResourceQuota to limit resource consumption in a namespace

E.Namespaces are used to isolate resources like Pods and Services

AnswersB, D, E

NetworkPolicy objects are namespaced and select pods by label, so rules can explicitly permit or deny ingress and egress traffic crossing namespace boundaries. This makes cross-namespace pod traffic controllable rather than implicitly open, satisfying the statement about inter-namespace communication.

Why this answer

Option B is correct because NetworkPolicy objects are namespaced and their podSelector rules can reference other namespaces via namespaceSelector, allowing administrators to permit or deny ingress/egress traffic between pods in different namespaces. Option D is correct because ResourceQuota is a namespaced object that caps aggregate resource consumption (e.g., requests.cpu, limits.memory, count/pods) within a single namespace. Option E is correct because namespaces provide logical isolation for namespaced resources such as Pods, Services, Deployments, and ConfigMaps, enabling separate environments or teams to coexist in one cluster.

Option A is incorrect because PersistentVolumes are cluster-scoped resources, not namespaced (only PersistentVolumeClaims are namespaced). Option C is incorrect because Nodes are cluster-scoped resources, not namespaced.

Exam trap

The exam often tests the distinction between cluster-scoped and namespaced resources, and the trap here is that candidates mistakenly think all Kubernetes resources are namespaced, when in fact Nodes, PersistentVolumes, and ClusterRoles are cluster-scoped.

Full explanation →

461

MCQmedium

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

A.Increase the memory limit in the pod's container resource specification

B.Increase the CPU request for the container

C.Delete and recreate the pod to clear the crash loop

D.Delete the namespace and redeploy all workloads

AnswerA

OOMKilled means the kernel terminated the container for exceeding its memory limit, so raising that limit gives the process the headroom it needs. The pod ran for days before failing, indicating a genuine memory ceiling rather than a configuration or image fault.

Why this answer

The pod is in CrashLoopBackOff due to OOMKilled, meaning the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. Increasing the memory limit in the pod's container resource specification allows the container to allocate more memory without being killed, resolving the crash loop. This directly addresses the root cause—insufficient memory limit—without affecting other resources or requiring full redeployment.

Exam trap

A common trap in the CNCF Kubernetes exams is assuming that CrashLoopBackOff always requires pod deletion or restart, but OOMKilled is a resource limit issue that must be fixed by adjusting the memory limit, not by recreating the pod.

How to eliminate wrong answers

Option B is wrong because increasing the CPU request does not affect memory allocation; CPU and memory are independent resources, and OOMKilled is solely a memory issue. Option C is wrong because deleting and recreating the pod only restarts the container with the same memory limit, which will immediately trigger OOMKilled again under the same workload. Option D is wrong because deleting the namespace and redeploying all workloads is an extreme, unnecessary action that disrupts all other resources in the namespace and does not fix the memory limit configuration.

Full explanation →

462

MCQmedium

You run the command 'kubectl get pods -n default' and see no pods listed. However, you are sure there should be pods. What is the most likely cause?

A.The current kubectl context is connected to a different cluster

B.All pods are in the 'kube-system' namespace

C.The kube-apiserver is down

D.The pods are in the 'Pending' state and not listed

AnswerA

kubectl queries whatever cluster the active context points to, so an empty default namespace usually means the context targets a different cluster than the one holding the pods. Switching context with kubectl config use-context reveals the intended workloads.

Why this answer

`kubectl` uses the current context defined in the kubeconfig file to determine which cluster and namespace to communicate with. If the context points to a different cluster (e.g., a test or staging cluster), the `kubectl get pods -n default` command will query that cluster's API server, which may have no pods in the `default` namespace, even though the intended cluster has pods. This is a common misconfiguration when working with multiple clusters.

Exam trap

A common pitfall is assuming an empty pod list means no pods exist, without checking the current kubectl context. Candidates often forget that the context determines which cluster and namespace are being queried.

How to eliminate wrong answers

Option B is wrong because the `-n default` flag explicitly queries the `default` namespace, not `kube-system`; pods in `kube-system` are irrelevant unless the namespace is changed. Option C is wrong because if the kube-apiserver were down, `kubectl` would return a connection error (e.g., 'Unable to connect to the server'), not an empty pod list. Option D is wrong because pods in the 'Pending' state are still listed by `kubectl get pods`; they are not hidden—only their status differs.

Full explanation →

463

MCQeasy

What is the purpose of Alertmanager in Prometheus?

A.Handle alert notifications

B.Visualize metrics

C.Store long-term metrics

D.Collect metrics from targets

AnswerA

Alertmanager receives alerts fired by Prometheus, then deduplicates, groups, and routes them to receivers such as email, Slack, or PagerDuty. It also handles silencing and inhibition, controlling notification delivery rather than evaluating alert rules or storing metrics.

Why this answer

Alertmanager is the component in the Prometheus ecosystem responsible for handling alerts fired by the Prometheus server. It deduplicates, groups, and routes alerts to configured notification channels such as email, PagerDuty, or Slack, ensuring that operators receive actionable notifications without alert fatigue.

Exam trap

The trap here is that candidates confuse Alertmanager with Prometheus itself, thinking it collects or stores metrics, when in fact it is solely a notification routing and deduplication engine.

How to eliminate wrong answers

Option B is wrong because visualizing metrics is the role of Grafana or the Prometheus expression browser, not Alertmanager. Option C is wrong because long-term metrics storage is handled by remote storage integrations (e.g., Thanos, Cortex) or the Prometheus TSDB itself, not Alertmanager. Option D is wrong because collecting metrics from targets is the function of the Prometheus server via its scrape mechanism, not Alertmanager.

Full explanation →

464

MCQmedium

An operations team runs a stateless web application in a Deployment with 3 replicas. They need each Pod to be able to read application configuration from a single source, and updates to that configuration should be reflected in the running Pods without rebuilding the container image. Which Kubernetes resource should they use to store the configuration and inject it as environment variables into the Pods?

A.Secret

B.ConfigMap

C.PersistentVolumeClaim

D.ResourceQuota

AnswerB

ConfigMap holds non-confidential key-value configuration data and can be consumed as environment variables in a Pod. When a ConfigMap is referenced via envFrom or valueFrom in the Pod spec, Kubernetes injects the values at container start. This avoids baking configuration into the image and allows the same image to be reused across environments, which directly matches the team's requirement.

Why this answer

ConfigMap is designed for non-sensitive configuration data and integrates directly with Pods through environment variables or mounted files. Because the team wants configuration decoupled from the container image and injected at runtime, a ConfigMap is the correct choice. The other resources serve storage, secret handling, or quota enforcement and cannot provide general application configuration to the container environment.

Exam trap

The trap here is assuming that Secret is the default way to pass any configuration into a Pod, when Secrets are specifically meant for sensitive values and ConfigMaps for ordinary configuration.

Full explanation →

465

MCQmedium

You want to expose a set of pods running on node port 30080 to external traffic. Which Service type should you use?

A.ExternalName

B.LoadBalancer

C.NodePort

D.ClusterIP

AnswerC

NodePort allocates a static port on every node's IP, so traffic arriving at node port 30080 is forwarded to the backing pods. ClusterIP and LoadBalancer do not expose a fixed node-level port, failing the stated constraint.

Why this answer

(NodePort) is correct because a NodePort service exposes the application on a static port (30080) on each node's IP address, making it accessible from outside the cluster via <NodeIP>:30080. This is the appropriate choice when you need to expose pods to external traffic using a specific port number without requiring a cloud load balancer.

Exam trap

The trap here is that candidates confuse NodePort with LoadBalancer, thinking a cloud load balancer is required for external access, but NodePort directly exposes a static port on the node's IP without any cloud dependency.

How to eliminate wrong answers

Option A (ExternalName) is wrong because it maps a service to a DNS name (e.g., an external CNAME record) and does not expose pods or provide any network connectivity to external traffic; it is used for internal DNS aliasing. Option B (LoadBalancer) is wrong because it provisions an external cloud load balancer (e.g., AWS ELB, GCP LB) which assigns a dynamic external IP and port, not a fixed node port like 30080; it is overkill and does not guarantee the specific port. Option D (ClusterIP) is wrong because it exposes the service only on a cluster-internal IP, reachable only from within the cluster, and cannot be accessed from external traffic without additional components like an ingress or proxy.

Full explanation →

466

MCQeasy

A container in a pod has been restarted multiple times with 'CrashLoopBackOff' state. What does this indicate?

A.The container is using too much memory

B.The container exits with a non-zero exit code soon after starting

C.The container is running but not responding to health checks

D.The container image cannot be pulled

AnswerB

CrashLoopBackOff means the kubelet repeatedly starts the container, sees it terminate, and applies exponential backoff before retrying. A non-zero exit code confirms the process itself fails soon after launch, satisfying the stem's repeated-restart condition rather than an image pull or scheduling fault.

Why this answer

The 'CrashLoopBackOff' state indicates that a container in a pod repeatedly starts, exits with a non-zero exit code, and is then restarted by the kubelet. This loop triggers an exponential backoff delay, preventing the container from staying up. The core issue is that the container process fails almost immediately after starting, not that it is resource-constrained or unresponsive.

Exam trap

A common trap in the CNCF exam is the distinction between 'CrashLoopBackOff' (container exits immediately) and 'ImagePullBackOff' (image cannot be pulled), so candidates mistakenly choose the image pull failure option when they see 'BackOff' in the state name.

How to eliminate wrong answers

Option A is wrong because excessive memory usage typically leads to an 'OOMKilled' state, not 'CrashLoopBackOff', and the container would be terminated by the kernel, not exit on its own. Option C is wrong because a container that is running but not responding to health checks enters a 'CrashLoopBackOff' only if the liveness probe fails repeatedly and the container is restarted; however, the question states the container has been restarted multiple times with 'CrashLoopBackOff', which implies it exits immediately, not that it runs and fails probes. Option D is wrong because an image pull failure results in 'ImagePullBackOff' or 'ErrImagePull', not 'CrashLoopBackOff', as the container never starts.

Full explanation →

467

Multi-Selectmedium

Which THREE of the following are responsibilities of the kube-controller-manager?

Select 3 answers

A.Assigning Pods to Nodes

B.Creating Endpoints objects for Services

C.Monitoring Node health and reacting to Node failures

D.Ensuring the correct number of Pod replicas are running

E.Serving the Kubernetes API

AnswersB, C, D

Endpoint creation belongs to the endpoint controller, which runs inside the kube-controller-manager alongside controllers for nodes, replication and service accounts. It watches Services and their pod selectors, then writes matching Endpoints objects, satisfying the stem's requirement that this be a kube-controller-manager responsibility rather than kubelet or kube-proxy work.

Why this answer

Option B is correct because the kube-controller-manager runs the endpoints controller (and endpointslice controller), which populates Endpoints/EndpointSlice objects for Services by tracking the Pods matching each Service's selector. Option C is correct because the node lifecycle controller inside the kube-controller-manager monitors Node heartbeats/status and applies taints such as node.kubernetes.io/not-ready or unreachable and evicts Pods when Nodes fail. Option D is correct because the ReplicaSet controller (and Deployment/StatefulSet controllers) run in the kube-controller-manager and reconcile the actual number of Pod replicas to the desired count.

Option A is not part of the kube-controller-manager; Pod-to-Node assignment is performed by the kube-scheduler. Option E is not part of the kube-controller-manager; the Kubernetes API is served by kube-apiserver.

Exam trap

The trap here is that candidates confuse the kube-controller-manager's role in 'managing controllers' with the scheduler's role in 'assigning Pods to nodes', or they mistakenly think the controller-manager serves the API because it interacts with the API server.

Full explanation →

468

MCQmedium

A development team deploys a microservice that crashes every few minutes. The deployment uses a single replica, and the pod restarts repeatedly. Which Kubernetes feature should be enabled to ensure the service remains available during failures?

A.Move the deployment to a separate namespace

B.Increase the replicas in the Deployment to at least 2

C.Store the application configuration in a ConfigMap

D.Add a readiness probe to the pod

AnswerB

Increasing replicas to at least 2 keeps the service available because the ReplicaSet controller maintains the desired count, rescheduling pods onto healthy nodes when one crashes. This satisfies the availability constraint, unlike a single replica, which leaves no capacity during restarts. Note that this masks crashes rather than fixing the underlying fault.

Why this answer

Increasing the replicas to at least 2 ensures that if one pod crashes, the other replica(s) can continue serving traffic, maintaining availability. With only a single replica, the service becomes unavailable every time the pod restarts. This is the most direct way to provide redundancy and fault tolerance for a stateless microservice.

Exam trap

The trap here is that candidates often confuse health probes (readiness/liveness) with redundancy; while probes help detect and manage unhealthy pods, they do not provide the multiple running instances needed to maintain availability during a crash.

How to eliminate wrong answers

Option A is wrong because moving the deployment to a separate namespace does not affect pod availability or crash recovery; namespaces are for logical isolation, not high availability. Option C is wrong because storing configuration in a ConfigMap decouples configuration from the container image but does not prevent or recover from pod crashes. Option D is wrong because a readiness probe only controls whether a pod receives traffic; it does not keep the service available if the pod crashes—it merely stops sending traffic to an unhealthy pod, but with a single replica, no other pod exists to handle requests.

Full explanation →

469

MCQeasy

A platform team wants to package a multi-service application into a single distributable artifact that includes Kubernetes manifests, default configuration values, and a version number. Which tool is purpose-built for this task?

A.kubectl

B.Kustomize

C.Docker Compose

D.Helm

AnswerD

Helm packages Kubernetes resources into a chart, a versioned archive containing templated manifests, a values.yaml file for defaults, and Chart.yaml metadata. Installing or upgrading the chart renders templates with supplied values and applies them to the cluster, giving the team a single distributable artifact with a semantic version.

Why this answer

Helm is the package manager for Kubernetes: a chart bundles templated manifests, default values, and metadata into a versioned artifact that can be installed, upgraded, and rolled back as a unit. The other tools either patch existing YAML, talk to the API server, or target a different runtime entirely.

Exam trap

The trap here is assuming any YAML management tool can package and version an application, when only Helm provides a chart format with built-in release versioning.

Full explanation →

470

MCQmedium

What is the primary purpose of the sidecar container in a service mesh?

A.To run application business logic

B.To handle logging and monitoring of the main container

C.To provide persistent storage for the main container

D.To intercept and manage network traffic for the main container

AnswerD

The sidecar proxy runs alongside the main container and transparently intercepts inbound and outbound network traffic, enforcing mTLS, routing, retries and telemetry policies. This offloads service-mesh networking concerns from application code without modifying the main container.

Why this answer

In a service mesh, the sidecar container (typically an Envoy or Linkerd proxy) is injected alongside the main application container to intercept and manage all inbound and outbound network traffic. This allows the service mesh to enforce traffic policies, handle service discovery, implement retries and circuit breaking, and collect telemetry without modifying the application code. The sidecar operates at the network layer (L4/L7), decoupling communication concerns from business logic.

Exam trap

CNCF often tests the misconception that the sidecar's primary role is logging and monitoring, but the correct answer is always traffic interception and management, as that is the core architectural purpose of a service mesh sidecar.

How to eliminate wrong answers

Option A is wrong because the sidecar container does not run application business logic; that is the responsibility of the main container. Option B is wrong because while the sidecar can collect telemetry data as a byproduct of traffic interception, its primary purpose is not logging and monitoring—those are separate concerns often handled by dedicated agents or the control plane. Option C is wrong because persistent storage is provided by volumes or CSI drivers, not by sidecar containers, which are ephemeral and focused on network functions.

Full explanation →

471

MCQeasy

Which statement accurately describes a key difference between containers and virtual machines?

A.Virtual machines share the host kernel, while containers have their own kernel

B.Both containers and virtual machines require a hypervisor

C.Containers include a full guest operating system

D.Containers share the host OS kernel, while virtual machines include a full guest OS

AnswerD

Containers share the host OS kernel, so they carry only the application and its dependencies, making them lightweight. Virtual machines run a complete guest OS with its own kernel atop a hypervisor, consuming far more resources. This kernel-sharing axis is the fundamental architectural difference between the two.

Why this answer

Containers virtualize at the OS level, sharing the host kernel, while virtual machines (VMs) include a full guest OS with its own kernel, running on a hypervisor. This fundamental architectural difference means containers are lighter and start faster, but VMs provide stronger isolation since each VM has its own kernel and OS instance.

Exam trap

The trap is that candidates often confuse the isolation boundaries between containers and VMs, mistakenly thinking containers have their own kernel (like VMs) or that VMs share the host kernel (like containers). In the context of Kubernetes, containers always share the host OS kernel, while VMs include a full guest OS.

How to eliminate wrong answers

Option A is wrong because it reverses the relationship: virtual machines do NOT share the host kernel (they have their own guest OS kernel), while containers share the host kernel. Option B is wrong because containers do not require a hypervisor; they run directly on the host OS using kernel features like cgroups and namespaces, whereas VMs require a hypervisor (Type 1 or Type 2) to manage guest OS instances. Option C is wrong because containers do not include a full guest operating system; they package only the application and its dependencies, relying on the host OS kernel for system calls.

Full explanation →

472

MCQmedium

A microservice logs errors when connecting to the database. The logs show 'connection refused'. Which troubleshooting step should be taken first?

A.Verify the database Service and Endpoints in Kubernetes

B.Scale up the microservice deployment

C.Restart the microservice pod

D.Check the logs of other microservices

AnswerA

'Connection refused' means the client reached a host but nothing accepted the connection, so the Service may have no matching Endpoints. Verifying the Service selector and its Endpoints confirms whether pods are actually registered before investigating DNS, network policy or the database itself.

Why this answer

The 'connection refused' error indicates that the microservice is attempting to connect to a TCP port on the database endpoint, but no process is listening there. In Kubernetes, the first step is to verify that the database Service exists and that its Endpoints object contains the correct pod IPs and port. If the Endpoints are empty or missing, the Service is not routing traffic to any healthy database pod, which directly causes the refusal.

This aligns with the Kubernetes troubleshooting hierarchy: always check the Service and Endpoints before assuming application-level issues.

Exam trap

The trap here is that candidates often jump to restarting the pod or scaling the deployment, assuming the microservice itself is faulty, rather than recognizing that 'connection refused' is a network-level symptom pointing to the target (the database Service/Endpoints) not being available.

How to eliminate wrong answers

Option B is wrong because scaling up the microservice deployment will create more pods that all try to connect to the same unreachable database, multiplying the failure without addressing the root cause. Option C is wrong because restarting the microservice pod will only reattempt the same connection to the same database endpoint, which will still be refused if the database Service or its backing pods are misconfigured. Option D is wrong because checking logs of other microservices is a distraction; the 'connection refused' error is specific to the database connectivity and does not require cross-service log analysis to diagnose.

Full explanation →

473

MCQeasy

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

A.Pod

B.Deployment

C.Node

D.Container

AnswerA

A Pod is the smallest deployable unit Kubernetes creates, schedules and manages, wrapping one or more containers that share a network namespace and storage volumes. This satisfies the stem's constraint that the unit be creatable, schedulable and manageable, unlike individual containers.

Why this answer

A Pod is the smallest and simplest unit in the Kubernetes object model that can be created, scheduled, and managed. It represents a single instance of a running process in the cluster and encapsulates one or more containers with shared storage and network resources. While containers are the underlying runtime, Kubernetes does not schedule containers directly; it schedules Pods as the atomic unit of deployment.

Exam trap

The trap here is that candidates often confuse 'container' as the smallest unit because it is the runtime process, but Kubernetes explicitly treats the Pod as the smallest deployable and schedulable object, not the container.

How to eliminate wrong answers

Option B is wrong because a Deployment is a higher-level abstraction that manages ReplicaSets and Pods, not the smallest deployable unit itself. Option C is wrong because a Node is a worker machine (physical or virtual) in the cluster, not a deployable unit; Pods are scheduled onto Nodes. Option D is wrong because a Container is the runtime process, but Kubernetes schedules and manages Pods, not individual containers; containers must be wrapped in a Pod to be deployed.

Full explanation →

474

MCQeasy

What is Helm's role in Kubernetes?

A.A CI/CD server

B.A package manager for Kubernetes applications

C.A security scanner for container images

D.A monitoring and logging tool

AnswerB

Helm packages Kubernetes manifests into versioned charts, enabling repeatable installs, upgrades and rollbacks of applications and their dependencies. This directly answers the stem's question of Helm's role: it manages the packaging and release lifecycle of Kubernetes applications, rather than scheduling workloads or storing images.

Why this answer

Helm is widely recognized as the package manager for Kubernetes, analogous to apt or yum for Linux. It allows you to define, install, and upgrade even the most complex Kubernetes applications using reusable templates called charts. Charts bundle all necessary Kubernetes manifests and dependencies, enabling consistent deployments across environments.

Exam trap

KCNA often tests the confusion between Helm and CI/CD tools, as both are involved in deployment pipelines, but Helm's core identity is a package manager, not a pipeline orchestrator.

How to eliminate wrong answers

Option A is wrong because a CI/CD server (e.g., Jenkins, GitLab CI) automates build, test, and deployment pipelines, whereas Helm focuses on packaging and managing Kubernetes resources, not orchestrating pipelines. Option C is wrong because security scanning of container images is performed by tools like Trivy, Clair, or Anchore, not Helm; Helm does not analyze image vulnerabilities. Option D is wrong because monitoring and logging are handled by tools like Prometheus, Grafana, and the ELK stack; Helm does not provide observability features.

Full explanation →

475

MCQmedium

An organization uses GitOps with ArgoCD to manage Kubernetes deployments. What is the PRIMARY advantage of this approach over traditional imperative deployment methods?

A.It eliminates the need for any manual approval processes

B.It provides a single source of truth for cluster state through Git

C.It allows developers to directly access the Kubernetes cluster

D.It reduces the number of containers needed in a deployment

AnswerB

Git holds the declarative desired state, and ArgoCD continuously reconciles the cluster to match it. This differs from imperative scripting, which issues one-off commands, because Git becomes the authoritative, auditable source of truth for the cluster.

Why this answer

GitOps uses a Git repository as the single source of truth, enabling declarative configuration, version control, and automated reconciliation. This is the primary advantage over traditional imperative methods. Option A is incorrect because manual approval processes can still be part of a GitOps workflow.

Option C is incorrect because GitOps does not eliminate the need for access controls. Option D is incorrect because GitOps does not directly reduce container count.

Full explanation →

476

MCQeasy

A developer creates a Deployment with 3 replicas. After a few seconds, they run `kubectl get deployments` and see `READY 2/3`. They want to quickly identify why one replica is not ready. Which command should they use to inspect the status of the individual Pods?

A.kubectl describe deployment myapp

B.kubectl get pods -l app=myapp -o wide

C.kubectl get events --field-selector involvedObject.name=myapp

D.kubectl logs deployment/myapp

AnswerB

This command lists all Pods matching the label selector app=myapp, showing their status, restarts, and node assignment. It directly reveals which Pod is not Ready and provides basic details. The -o wide flag adds IP and node information, which can help correlate with node issues. This is the quickest way to see the individual Pod statuses and identify the problematic replica.

Why this answer

To quickly identify which Pod is not ready, listing Pods with the Deployment's label selector and wide output shows each Pod's status and node. This provides an immediate view of which replica is failing and basic context. Describing the Deployment or fetching logs from the Deployment does not show per-Pod readiness.

Filtering events by the Deployment name misses Pod-level events. The correct approach is to query the Pods directly.

Exam trap

The trap here is using a Deployment-level command when the issue is at the Pod level; always inspect the Pods themselves to see individual readiness and status.

Full explanation →

477

Multi-Selecteasy

Which TWO of the following are true about container networking basics? (Choose 2)

Select 2 answers

A.Containers can only communicate if they are on the same node

B.Containers on the same host can communicate via a bridge network

C.Each container has its own network namespace

D.Container networking does not require any configuration

E.All containers share the host's IP address

AnswersB, C

A bridge network on the host connects containers through a virtual switch, letting them reach each other by IP or container name without leaving the host. This satisfies the stem's requirement about same-host container communication.

Why this answer

Option B is correct because containers on the same host can communicate through a bridge network, such as Docker's default bridge, where veth pairs connect container interfaces to a Linux bridge and IP forwarding enables same-host traffic. Option C is correct because each container is created with its own network namespace, giving it separate interfaces, routing tables, and IP addresses isolated from other containers and the host. Option A is incorrect because containers on different nodes can communicate via overlay networks, routing, or service meshes, not only on the same node.

Option D is incorrect because container networking requires configuration such as bridge creation, IP address assignment, port mapping, or CNI plugin setup. Option E is incorrect because containers normally have their own IP addresses within their network namespace, not the host's IP address, unless using host networking mode.

Exam trap

KCNA often tests the misconception that containers always share the host's IP or that networking is automatic, confusing host mode with default bridge mode.

Full explanation →

478

Multi-Selectmedium

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

Select 2 answers

A.Reporting the node's status to the control plane

B.Implementing network rules for services

C.Assigning pods to nodes based on resource availability

D.Storing cluster state in a key-value store

E.Ensuring that containers are running in a pod as specified

AnswersA, E

The kubelet runs on each node and continuously reports node and pod status to the control plane, typically via the API server. This satisfies the stem's requirement by covering the node-level agent's duty to communicate health and capacity information upward.

Why this answer

Option A is correct because the kubelet runs on each node and periodically reports node status (including conditions, capacity, and allocatable resources) to the control plane via the API server, typically through NodeStatus updates. Option E is correct because the kubelet acts as the node agent that watches PodSpecs assigned to its node and ensures the specified containers are running and healthy, restarting them as needed via the container runtime. Option B is incorrect because implementing network rules for services is the job of kube-proxy (using iptables/IPVS), not the kubelet.

Option C is incorrect because assigning pods to nodes is performed by the kube-scheduler, which selects a node based on resource availability and constraints. Option D is incorrect because storing cluster state in a key-value store is the role of etcd, the cluster's backing datastore.

Exam trap

This certification exam often tests the distinction between the kubelet and other control plane components like the kube-scheduler or kube-proxy, so candidates must remember that the kubelet is a node-level agent focused on pod lifecycle and node status, not scheduling or networking.

Full explanation →

479

MCQeasy

Which component runs on every worker node and is responsible for ensuring that containers are running in a pod according to the pod specification?

A.kube-scheduler

B.kubelet

C.container runtime

D.kube-proxy

AnswerB

The kubelet is the node agent that watches the API server for pods bound to its node and drives the container runtime to start, stop and health-check containers to match the pod specification. It runs on every worker node, exactly as the stem requires.

Why this answer

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It registers the node with the API server, watches for PodSpecs assigned to its node, and ensures the containers described in those PodSpecs are running and healthy. It does this by interacting with the container runtime to create, start, and stop containers as needed, and it reports the node and pod status back to the control plane.

Exam trap

The trap here is that candidates confuse the kubelet with the container runtime, thinking the runtime itself reads the pod spec, when in fact the kubelet is the agent that interprets the spec and delegates container operations to the runtime via the Container Runtime Interface (CRI).

How to eliminate wrong answers

Option A is wrong because the kube-scheduler is a control plane component that decides which worker node a new pod should be placed on, but it does not run on worker nodes nor does it manage container lifecycle. Option C is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it is not responsible for reading the pod specification from the API server or ensuring the pod's desired state is maintained; that is the kubelet's job. Option D is wrong because kube-proxy is a network proxy that runs on each node and handles network rules for service traffic (e.g., iptables or IPVS), but it has no role in container lifecycle management or pod specification enforcement.

Full explanation →

480

MCQhard

You have a microservices application with a frontend service that needs to communicate with a backend service running in a different namespace ('backend-ns'). The default namespace for the frontend is 'frontend-ns'. What DNS name should the frontend use to reach the backend service named 'backend-svc'?

A.backend-svc.frontend-ns.svc.cluster.local

B.backend-svc.backend-ns.svc.cluster.local

C.backend-svc.backend-ns.cluster.local

D.backend-svc

AnswerB

The fully qualified domain name resolves cross-namespace because Kubernetes DNS appends the namespace segment between service and svc. Since the frontend sits in frontend-ns while the backend runs in backend-ns, the short name backend-svc alone would fail; specifying backend-ns satisfies the cross-namespace constraint directly.

Why this answer

In Kubernetes, DNS names for services follow the pattern `<service>.<namespace>.svc.cluster.local`. Since the backend service 'backend-svc' is in the 'backend-ns' namespace, the correct DNS name is `backend-svc.backend-ns.svc.cluster.local`. This allows the frontend in 'frontend-ns' to resolve the backend service across namespaces.

Exam trap

The trap here is that candidates often forget the 'svc' subdomain or mistakenly use the frontend's namespace instead of the backend's namespace, leading them to choose A or C, while D is a common shortcut that only works within the same namespace.

How to eliminate wrong answers

Option A is wrong because it uses 'frontend-ns' as the namespace, which would only work if the backend service were in the same namespace as the frontend, but it is in 'backend-ns'. Option C is wrong because it omits the required 'svc' subdomain, making the DNS name invalid for Kubernetes service discovery. Option D is wrong because it omits the namespace and cluster domain entirely, which only works for services in the same namespace and does not resolve across namespaces.

Full explanation →

481

MCQeasy

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

A.Treat logs as event streams

B.Store configuration in the application code

C.Store logs in the local filesystem of each container

D.Use shared filesystems for persistent storage

AnswerA

Treating logs as event streams means the app writes them to stdout as an unbuffered sequence of events, leaving routing, storage and aggregation to the execution environment. This decouples the app from log destinations, matching the 12-factor principle of separation from backing services.

Why this answer

The 12-factor app methodology, a set of best practices for building modern, scalable applications, includes the principle 'Treat logs as event streams.' This means an app should not concern itself with routing or storage of its output stream; instead, it writes logs to stdout/stderr, and the execution environment captures and routes them. This decouples log management from the application, enabling flexibility and scalability.

Exam trap

The trap is confusing log storage with log handling: candidates might think storing logs in the filesystem is acceptable, but 12-factor explicitly advocates treating logs as event streams, not files.

How to eliminate wrong answers

Option B is wrong because storing configuration in application code violates the 12-factor principle of separating config from code; config should be stored in environment variables. Option C is wrong because storing logs in the local filesystem of each container is an anti-pattern; containers are ephemeral, and logs should be streamed to a centralized system. Option D is wrong because using shared filesystems for persistent storage is not a core 12-factor principle; while stateful apps exist, 12-factor apps are designed to be stateless and store state in backing services.

Full explanation →

482

MCQhard

Which of the following is a characteristic of immutable infrastructure?

A.Infrastructure is version-controlled using Git

B.Infrastructure components are never changed after deployment; they are replaced

C.Servers are updated in-place with configuration management tools

D.Containers are used to ensure portability

AnswerB

Immutable infrastructure treats servers as disposable artefacts: once deployed, components are never patched or reconfigured in place. Changes trigger provisioning of replacement instances from a new image, and the old ones are destroyed, eliminating configuration drift.

Why this answer

Immutable infrastructure means that once a component (e.g., a server, container, or VM) is deployed, it is never modified. If an update is needed, the entire component is replaced with a new version. This eliminates configuration drift and ensures consistency across environments, which is a core principle in container orchestration with Kubernetes.

Exam trap

The KCNA exam often tests the misconception that version-controlling infrastructure (Option A) or using containers (Option D) automatically makes infrastructure immutable, but immutability specifically requires that deployed components are never modified—only replaced.

How to eliminate wrong answers

Option A is wrong because while version-controlling infrastructure definitions (e.g., using Git for Terraform or Kubernetes manifests) is a best practice, it is not a defining characteristic of immutability—it is a DevOps practice for infrastructure as code. Option C is wrong because updating servers in-place with configuration management tools (e.g., Ansible, Chef) is the opposite of immutable infrastructure; it represents mutable infrastructure where changes are applied to running instances. Option D is wrong because containers improve portability but do not inherently enforce immutability; containers can be updated in-place (e.g., by exec-ing into a running container) unless explicitly managed as immutable.

Full explanation →

483

MCQeasy

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

A.To check if the container is alive and restart it if not

B.To verify the container's CPU and memory usage

C.To ensure the container can write to persistent storage

D.To check if the container is ready to accept traffic

AnswerD

A readiness probe determines whether the container has finished starting and can serve requests; until it succeeds, the pod is removed from Service endpoints, so no traffic is routed to it. This directly satisfies the stem's requirement of readiness to accept traffic.

Why this answer

A readiness probe in Kubernetes determines whether a container is ready to start accepting traffic. If the probe fails, the container is removed from the Service's endpoints, ensuring no traffic is routed to an unready pod. This is distinct from a liveness probe, which checks if the container is alive and should be restarted.

Exam trap

The exam often tests the confusion between liveness and readiness probes, where candidates mistakenly think a readiness probe restarts the container or that both probes serve the same purpose.

How to eliminate wrong answers

Option A is wrong because it describes a liveness probe, not a readiness probe; a liveness probe restarts the container if it fails, while a readiness probe only controls traffic routing. Option B is wrong because Kubernetes does not use probes to verify CPU or memory usage; resource usage is monitored via metrics servers or resource quotas, not probes. Option C is wrong because readiness probes do not check persistent storage; storage health is typically validated via startup probes or application-level checks, not readiness probes.

Full explanation →

484

MCQeasy

A company wants to ensure that a database pod runs on a node with SSD storage. How should this be achieved?

A.Label SSD nodes with 'disk=ssd' and add a nodeSelector to the pod

B.Set a resource request for local SSD storage in the pod spec

C.Use pod anti-affinity to avoid non-SSD nodes

D.Add a taint to nodes without SSDs and a toleration to the pod

AnswerA

Labelling SSD nodes with `disk=ssd` and adding a matching `nodeSelector` to the pod spec forces the Kubernetes scheduler to bind the database pod only to nodes carrying that label, directly satisfying the SSD-storage placement constraint. Node affinity would also work, but nodeSelector is the simplest mechanism for this exact requirement.

Why this answer

NodeSelector is a field in the Pod spec that constrains which nodes the Pod can be scheduled on, based on node labels. By labeling nodes with SSD storage as 'disk=ssd' and adding a nodeSelector with that label to the Pod, Kubernetes will only schedule the Pod on nodes that have the matching label, ensuring it runs on SSD storage.

Exam trap

The KCNA exam often tests the distinction between scheduling constraints (nodeSelector/node affinity) and repulsion mechanisms (taints/tolerations), trapping candidates who confuse tolerations as a way to select nodes rather than as a way to bypass node restrictions.

How to eliminate wrong answers

Option B is wrong because resource requests for local SSD storage are not supported in the standard Kubernetes resource model; storage is requested via PersistentVolumeClaims, not as a compute resource in the Pod spec. Option C is wrong because pod anti-affinity is used to avoid co-locating Pods on the same node or topology, not to select nodes based on hardware characteristics like SSD storage. Option D is wrong because taints and tolerations are used to repel Pods from nodes unless they have a matching toleration, but they do not actively select nodes with specific hardware; a toleration would allow the Pod to run on non-SSD nodes if they are not tainted, and tainting all non-SSD nodes is impractical and does not guarantee scheduling on SSD nodes.

Full explanation →

485

MCQeasy

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

A.To allow kubelet to use different container runtimes

B.To manage persistent storage for containers

C.To provide a network plugin interface for pods

D.To define a standard for container images

AnswerA

CRI is the abstraction layer between kubelet and container runtimes, defining gRPC endpoints for image and container lifecycle operations. It lets kubelet drive containerd, CRI-O or other compliant runtimes interchangeably, decoupling Kubernetes releases from any single runtime implementation.

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 source code. By defining a standard API (gRPC-based) for runtime operations like pulling images and managing containers, CRI decouples Kubernetes from specific runtime implementations such as containerd, CRI-O, or Docker (via dockershim). This abstraction allows cluster administrators to choose the most suitable runtime for their environment while maintaining compatibility with the Kubernetes control plane.

Exam trap

A common exam trap is confusing the CRI's role in runtime abstraction with storage (CSI) or networking (CNI) interfaces, leading candidates to select options B or C.

How to eliminate wrong answers

Option B is wrong because persistent storage management is handled by the Container Storage Interface (CSI), not the CRI; CRI focuses solely on runtime operations like container lifecycle and image management. Option C is wrong because network plugin interfaces for pods are provided by the Container Network Interface (CNI), which handles IP allocation and network connectivity, not the CRI. Option D is wrong because container image standards are defined by the Open Container Initiative (OCI) image spec, not the CRI; the CRI consumes OCI-compliant images but does not define the image format itself.

Full explanation →

486

MCQhard

In a CI pipeline, image scanning is integrated to detect vulnerabilities. What is the best practice when a critical vulnerability is found in a base image?

A.Fail the pipeline and notify the team to fix the base image

B.Deploy to production and patch later

C.Automatically patch the image in the pipeline

D.Ignore the vulnerability and proceed with deployment

AnswerA

Failing the pipeline blocks the vulnerable image from progressing, forcing remediation of the base image before rebuild. This satisfies the stem's requirement for best practice on detecting a critical base-image vulnerability, preventing insecure artefacts reaching production.

Why this answer

Failing the pipeline on a critical vulnerability in a base image enforces a secure software supply chain by preventing the vulnerable artifact from ever reaching a registry or production. It also triggers the team to remediate at the source — updating the base image tag or rebuilding on a patched parent — rather than masking the issue downstream. This is the standard 'shift-left' security practice recommended by CNCF projects like Trivy, Grype, and Clair.

Exam trap

KCNA often tests the misconception that pipelines should auto-patch images, when the correct practice is to fail fast and fix the base image at its source.

How to eliminate wrong answers

Option B is wrong because deploying a known-critical vulnerability to production violates least-privilege and secure-SDLC principles and creates an exploitable window. Option C is wrong because automatically patching an image mid-pipeline is risky and non-deterministic — it can break reproducibility, invalidate signatures, and bypass review; patching should occur in the base image build, not the consuming pipeline. Option D is wrong because ignoring a critical finding defeats the purpose of scanning and exposes the organization to known CVEs.

Full explanation →

487

MCQeasy

Which CNCF project maturity level indicates that a project has adopted the CNCF Code of Conduct and is considered early-stage?

A.Sandbox

B.Incubating

C.Graduated

D.Experimental

AnswerA

Sandbox is the earliest CNCF maturity level. Projects at this stage must adopt the CNCF Code of Conduct and are described as early-stage experiments, before progressing to Incubating and then Graduated. It directly matches the stem's requirement for the level indicating Code of Conduct adoption and early-stage status.

Why this answer

The CNCF has three maturity levels: sandbox (early-stage), incubating (growing), and graduated (mature). Sandbox projects are early-stage and have accepted the CNCF Code of Conduct.

Full explanation →

488

MCQhard

You notice that a newly created Pod remains in 'Pending' state. Which of the following is the MOST likely cause?

A.The Pod manifest has a syntax error

B.The container image does not exist

C.There are insufficient resources available on any node to meet the Pod's requests

D.The Service does not exist

AnswerC

The scheduler cannot bind a Pod to any node when no node has enough allocatable CPU or memory to satisfy its resource requests, leaving it Pending. Image pull failures or crashes occur after scheduling, producing different states such as ImagePullBackOff or CrashLoopBackOff.

Why this answer

A Pod enters 'Pending' state when it cannot be scheduled onto a node. The most common reason is insufficient CPU, memory, or other resources on any available node to satisfy the Pod's resource requests. The Kubernetes scheduler continuously evaluates node capacity against Pod requests, and if no node can accommodate the Pod, it remains unscheduled in Pending.

Exam trap

The KCNA exam often tests the distinction between scheduling failures (Pending) and runtime failures (ImagePullBackOff, CrashLoopBackOff), leading candidates to confuse image issues or syntax errors with resource constraints.

How to eliminate wrong answers

Option A is wrong because a syntax error in the Pod manifest would cause the API server to reject the manifest at creation time, resulting in an error message, not a Pod stuck in Pending. Option B is wrong because a missing container image would cause the Pod to be scheduled onto a node and then fail with an ImagePullBackOff or ErrImagePull status, not remain in Pending. Option D is wrong because the existence of a Service is irrelevant to Pod scheduling; Pods can run without any Service, and a missing Service does not affect the Pod's lifecycle or scheduling.

Full explanation →

489

Multi-Selecteasy

Which TWO of the following are characteristics of microservices architecture? (Choose 2)

Select 2 answers

A.All services share the same database

B.Services can be deployed independently

C.Communication between services is often via APIs

D.The entire application is deployed as a single unit

E.Services are tightly coupled

AnswersB, C

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

Why this answer

Microservices architecture is defined by the ability to deploy each service independently without affecting other services. This independence enables teams to update, scale, and roll back individual components, which is a core principle of container orchestration platforms like Kubernetes that manage these services as separate units.

Exam trap

The trap here is that candidates confuse microservices with service-oriented architecture (SOA) or mistakenly think that sharing a database or tight coupling is acceptable, when in fact microservices require database-per-service and loose coupling to achieve independent deployability.

Full explanation →

490

MCQhard

A pod has resource requests of 512Mi memory and 500m CPU, and limits of 1Gi memory and 1 CPU. The node has 4Gi memory and 2 CPU cores. If the pod tries to use 700m CPU, what will happen?

A.The pod will be throttled to 500m CPU

B.The pod will be allowed to use 700m CPU

C.The pod will be evicted from the node

D.The pod will be terminated for exceeding the limit

AnswerB

CPU is a compressible resource, so the 700m request is throttled only against the 1 CPU limit, not rejected. Since 700m sits below that ceiling and the node has spare capacity, the pod receives the full 700m.

Why this answer

The pod's CPU request is 500m, and its CPU limit is 1 CPU (1000m). When the pod attempts to use 700m CPU, it is below the limit of 1000m, so it is allowed to burst up to that amount. Kubernetes uses the CPU request for scheduling and the limit for throttling; since 700m is within the limit, no throttling occurs.

The pod is not evicted or terminated because it has not exceeded its memory limit or violated any resource constraints.

Exam trap

The trap here is that candidates confuse CPU requests with limits, thinking that exceeding the request triggers throttling or eviction, when in fact throttling only occurs at the limit and eviction is tied to memory or node pressure, not CPU usage below the limit.

How to eliminate wrong answers

Option A is wrong because throttling to 500m CPU would only occur if the pod exceeded its CPU limit, but 700m is below the 1000m limit, so the pod is allowed to burst. Option C is wrong because eviction happens when a node runs out of resources (e.g., memory pressure) or when a pod exceeds its memory limit, not for CPU usage below the limit. Option D is wrong because termination for exceeding a limit applies only when the pod surpasses its memory limit or violates a hard resource constraint; CPU usage below the limit does not trigger termination.

Full explanation →

491

MCQmedium

A team runs a stateless web application as a Deployment with 4 replicas. They want each replica to be reachable through a single stable virtual IP inside the cluster, and they want the traffic distributed across all healthy replicas. They have already created a Service of type ClusterIP with the correct selector. A new engineer asks what backend object the Service actually targets. What does the Service select?

A.The Deployment object itself, because the Service selector matches the Deployment's labels.

B.The individual Pods whose labels match the Service selector, tracked via EndpointSlices.

C.The ReplicaSet created by the Deployment, because it owns the Pods.

D.The nodes running the Pods, using each node's kubelet port as the backend.

AnswerB

A Service with a selector causes the endpoints controller to create EndpointSlice objects listing the IP addresses of matching, ready Pods. kube-proxy on each node programs iptables or IPVS rules to load-balance traffic to those Pod IPs. The Service's ClusterIP is stable, but the actual backends are the selected Pods, which can change as Pods are created or deleted.

Why this answer

A Service with a selector targets Pods, not Deployments or ReplicaSets. The endpoints controller watches for Pods matching the selector and populates EndpointSlice objects with their IPs and readiness state. kube-proxy then programs load-balancing rules to send traffic to those Pod IPs. This decoupling is why Services remain stable even as Pods are replaced.

Exam trap

The trap here is assuming a Service selects the Deployment or ReplicaSet that owns the Pods, when in fact it selects Pod labels directly.

Full explanation →

492

MCQmedium

A team is using Kustomize to manage configurations for different environments. They want to create a variant of a base deployment that uses a different number of replicas. Which Kustomize feature should they use?

A.Generators

B.Patches

C.Bases

D.Components

AnswerB

Patches apply targeted modifications to a base resource without duplicating it, so the team can override the replica count for a specific environment variant. This satisfies the requirement of deriving an environment-specific variant from shared base configuration, keeping the base reusable while changing only the replicas field.

Why this answer

Patches in Kustomize allow you to modify specific fields of resources from a base or overlay, such as changing the replica count of a Deployment. This is the intended feature for creating variants without duplicating the entire base. Generators create new resources (e.g., ConfigMaps), bases are the starting point, and components are reusable pieces that can be included, but none are designed for modifying existing fields like replica count.

Exam trap

KCNA often tests the purpose of Kustomize features. Candidates may confuse patches with generators or components, not realizing that patches are specifically for modifying existing resources, while generators create new ones.

How to eliminate wrong answers

Option A is wrong because Generators are used to create new resources like ConfigMaps or Secrets, not to modify existing ones. Option C is wrong because Bases are the original resources that you start with; they are not used to apply changes. Option D is wrong because Components are optional pieces that can be added to a Kustomization, but they are not the primary mechanism for modifying fields like replica count; patches are.

Full explanation →

493

MCQeasy

A developer wants to run a one-time task that creates a database schema and then exits. Which Kubernetes workload type is most appropriate?

A.DaemonSet

B.StatefulSet

C.Deployment

D.Job

AnswerD

A Job runs pods to completion and is designed for finite, run-to-completion workloads. This matches the stem's constraint of a one-time task that creates a schema and then exits, unlike a Deployment, which maintains continuous desired-state replicas.

Why this answer

A Job is the correct choice because it is designed for finite, one-time tasks that run to completion, such as creating a database schema. Unlike long-running workloads, a Job creates one or more Pods and ensures they terminate successfully after the task finishes, making it ideal for batch processing or initialization tasks.

Exam trap

The trap here is that candidates confuse a one-time task with a Deployment because they think of 'running a container' generically, forgetting that Deployments enforce a restart policy that would keep the task running indefinitely.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on all (or selected) nodes, intended for continuous background services like logging or monitoring, not for one-time tasks. Option B is wrong because a StatefulSet is used for stateful applications requiring stable, unique network identities and persistent storage, such as databases, and is designed for long-running rather than ephemeral tasks. Option C is wrong because a Deployment manages a set of identical Pods with a desired replica count, ensuring they run continuously and are automatically restarted if they exit, which is unsuitable for a task that should exit after completion.

Full explanation →

494

MCQhard

In a container image built from a Dockerfile, what is the purpose of the CMD instruction?

A.To specify a command that always runs at build time

B.To copy files into the image

C.To provide default arguments for the ENTRYPOINT instruction

D.To define environment variables

AnswerC

CMD supplies default arguments that are passed to the ENTRYPOINT executable when the container starts, and these defaults are overridden if arguments are supplied at runtime. This differs from ENTRYPOINT, which defines the fixed executable itself.

Why this answer

The CMD instruction in a Dockerfile provides default arguments for the ENTRYPOINT instruction when the container is run. If no ENTRYPOINT is defined, CMD itself serves as the default command to execute. This allows users to override the default behavior at runtime by appending arguments to `docker run`, which replace the CMD values while preserving the ENTRYPOINT.

Exam trap

The KCNA exam often tests the distinction between CMD and RUN, where candidates mistakenly think CMD runs at build time, but the trap is that CMD only defines runtime defaults and is overridable, unlike RUN which executes during image creation.

How to eliminate wrong answers

Option A is wrong because CMD specifies a command that runs at container runtime, not at build time; build-time commands are handled by RUN. Option B is wrong because copying files into the image is the purpose of the COPY or ADD instruction, not CMD. Option D is wrong because defining environment variables is the role of the ENV instruction, not CMD.

Full explanation →

495

MCQhard

Which of the following is a key principle of the 12-factor app methodology related to managing configuration?

A.Store configuration in the application code

B.Use environment variables for configuration

C.Embed configuration in the build process

D.Use a configuration file in the application directory

AnswerB

Twelve-factor apps separate configuration from code, storing it in environment variables so the same build deploys unchanged across environments. This satisfies the stem's constraint of managing configuration without hardcoding values or committing environment-specific settings into the codebase.

Why this answer

The 12-factor app methodology's third factor, 'Config,' states that configuration should be stored in the environment (environment variables), not in the code. This separates config from code, allowing the same build to be deployed across environments (dev, staging, prod) without modification. Environment variables are language-agnostic and easily changed per deployment.

Exam trap

KCNA often tests the 12-factor 'Config' factor, catching candidates who confuse environment variables with config files or build-time embedding, missing the core principle of separating config from code for portability.

How to eliminate wrong answers

Option A is wrong because storing configuration in application code violates the 12-factor principle of separating config from code; it makes the build environment-specific and requires code changes to alter config. Option C is wrong because embedding configuration in the build process ties config to a specific build artifact, preventing the same artifact from being promoted across environments — the opposite of the 12-factor goal. Option D is wrong because a configuration file in the application directory is still part of the codebase and is not environment-agnostic; it can be accidentally committed and does not support per-environment overrides as cleanly as environment variables.

Full explanation →

496

Multi-Selecthard

Which TWO of the following are valid reasons to use a DaemonSet instead of a Deployment? (Select 2)

Select 2 answers

A.You need to run exactly one pod per node for log collection

B.You need to deploy a monitoring agent that should run on every node

C.You need to ensure a pod runs on the control-plane node only

D.You need to run a batch job that completes and exits

E.You need to run a stateless web application with multiple replicas

AnswersA, B

A DaemonSet controller schedules one pod onto every node, including nodes added later, which suits per-node agents such as log collectors. A Deployment instead targets a replica count, so coverage per node is not guaranteed.

Why this answer

A DaemonSet ensures that exactly one pod runs on every node (or a subset of nodes) in the cluster. Option A is correct because log collection agents (e.g., Fluentd, Filebeat) must run on each node to capture all container logs, and a DaemonSet guarantees this per-node scheduling. Option B is correct because monitoring agents (e.g., Prometheus Node Exporter, Datadog agent) need to be present on every node to collect host-level metrics, and a DaemonSet is the ideal controller for this use case.

Exam trap

Kubernetes often tests the distinction between DaemonSets and Deployments by presenting scenarios that involve per-node scheduling versus replica management, and the trap here is that candidates confuse 'run on every node' with 'run on a specific node' or 'run a batch job,' leading them to select options C or D incorrectly.

Full explanation →

497

MCQmedium

A Deployment named 'app-deploy' is configured with strategy type: RollingUpdate. You want to update the container image to a new version. What kubectl command should you use?

A.kubectl apply -f updated-deployment.yaml

B.kubectl edit deployment app-deploy

C.kubectl patch deployment app-deploy -p '{"spec":{"template":{"spec":{"containers":[{"name":"app","image":"new:tag"}]}}}}'

D.kubectl set image deployment/app-deploy app=new:tag

AnswerD

The kubectl set image command updates a Deployment's container image in place, triggering the configured RollingUpdate strategy to replace pods gradually. Targeting deployment/app-deploy with the container name and new tag satisfies the stem's requirement to roll out the new version without editing YAML manually.

Why this answer

`kubectl set image` is the dedicated command for updating the container image of an existing deployment without modifying other fields. It directly modifies the deployment's pod template spec to use the new image, triggering a rolling update as defined by the deployment's strategy type.

Exam trap

The trap here is that candidates may think `kubectl apply` or `kubectl edit` are always the correct ways to update a deployment, but the exam tests the understanding that `kubectl set image` is the purpose-built command for updating container images in a deployment without needing a full manifest or interactive editing.

How to eliminate wrong answers

Option A is wrong because `kubectl apply -f updated-deployment.yaml` would work only if you have a YAML file with the updated image, but the question does not mention any file; it asks for a command to update the image directly, and `apply` is not the most direct or intended command for a simple image change. Option B is wrong because `kubectl edit deployment app-deploy` opens an interactive editor to modify the entire deployment manifest, which is overkill and error-prone for a simple image update; it is not the most efficient or recommended command for this task. Option C is wrong because `kubectl patch` can update the image, but the provided JSON patch is syntactically correct yet unnecessarily complex; `kubectl set image` is the simpler, more idiomatic command for this specific operation.

Full explanation →

498

MCQeasy

A platform engineer is explaining the role of the Kubernetes API server in a cloud-native architecture. Which statement BEST describes its primary function?

A.It schedules pods to nodes based on resource availability.

B.It serves as the central management endpoint that validates and processes REST requests for cluster resources.

C.It provides a distributed key-value store for cluster state.

D.It monitors the health of nodes and restarts failed containers.

AnswerB

The Kubernetes API server is the front end of the control plane. It exposes the Kubernetes API, validates and processes REST requests, and updates the cluster state in etcd. All other components interact with it to read or modify resources, making it the central management endpoint.

Why this answer

The Kubernetes API server acts as the central management endpoint for the cluster. It exposes the Kubernetes API, authenticates and authorizes requests, validates resource configurations, and persists state to etcd. Other control plane components and user tools like kubectl communicate exclusively through it, so it is the single point of interaction for cluster operations.

Exam trap

The trap here is attributing scheduling, node health monitoring, or etcd's storage role to the API server, when those are handled by separate control plane components.

Full explanation →

499

Multi-Selecthard

A team is deciding how to isolate workloads across namespaces. Which two statements about Kubernetes Namespaces are accurate? (Choose two.)

Select 2 answers

A.Namespaces provide kernel-level isolation between Pods, equivalent to Linux namespaces used by containers.

B.A NetworkPolicy that selects all Pods in a namespace automatically blocks traffic from other namespaces without additional rules.

C.Deleting a Namespace triggers deletion of the resources it contains, and the Namespace stays in Terminating until finalizers complete.

D.Cluster-scoped resources such as Nodes and PersistentVolumes can be created inside any namespace for organizational clarity.

E.ResourceQuota and LimitRange are namespace-scoped objects used to cap aggregate consumption and set per-container defaults.

AnswersC, E

Namespace deletion is asynchronous: the API server marks the Namespace Terminating and removes its contents, but the object remains until all finalizers and contained resources are cleared. A stuck finalizer on a resource can leave the Namespace terminating indefinitely, which is a common operational issue. This behavior is why namespace deletion should be treated as destructive and potentially slow rather than instantaneous.

Why this answer

Namespace deletion is finalizer-gated and removes contained resources, and ResourceQuota plus LimitRange are the namespaced mechanisms for aggregate caps and per-container defaults. The other statements misstate Kubernetes Namespaces as network isolation, kernel isolation, or a container for cluster-scoped objects, none of which reflects how the API partitions resources.

Exam trap

The trap here is equating Kubernetes Namespaces with Linux namespaces, when the former is only an API-level partition.

Full explanation →

500

Multi-Selectmedium

Which THREE of the following are valid ways to expose a Service to external traffic? (Select exactly three.)

Select 3 answers

A.Ingress

B.ExternalName

C.ClusterIP

D.NodePort

E.LoadBalancer

AnswersA, D, E

Ingress satisfies external exposure by routing HTTP and HTTPS traffic from outside the cluster to Services, using host- or path-based rules defined in an Ingress resource and implemented by an ingress controller. It provides layer 7 load balancing, terminating external requests and forwarding them internally, which meets the requirement for exposing Services to external traffic.

Why this answer

Ingress (A) is correct because an Ingress resource defines HTTP/HTTPS routing rules that expose Services externally through an Ingress controller acting as a layer-7 entry point. NodePort (D) is correct because it allocates a static port on every node's IP (default range 30000-32767), making the Service reachable from outside the cluster via <NodeIP>:<NodePort>. LoadBalancer (E) is correct because it provisions an external load balancer (e.g., via a cloud provider) that distributes traffic to the Service from outside the cluster.

ExternalName (B) is not a way to expose a Service; it merely maps a Service to an external DNS name via a CNAME record without proxying traffic. ClusterIP (C) is not externally accessible since it only assigns an internal virtual IP reachable within the cluster.

Exam trap

Candidates often mistakenly think ExternalName is an external exposure method, but it only creates a DNS alias within the cluster and does not route external traffic.

Full explanation →

501

Multi-Selectmedium

A platform team is standardizing on Kubernetes-native delivery. They want to adopt practices that make releases repeatable and reduce drift between environments. Which two practices best support that goal? (Choose two.)

Select 2 answers

A.Allow engineers to apply ad hoc kubectl edits directly to production when a fix is urgent

B.Package applications as versioned charts or overlays so the same artifact can be promoted across environments

C.Rely on the cluster's current state as the source of truth and reconcile Git from the live objects when they differ

D.Keep all manifests and environment configuration in version control and apply changes only through a reviewed pipeline

E.Maintain separate hand-edited manifest copies per environment and update each one independently

AnswersB, D

A versioned chart or base-with-overlays artifact lets one tested package move from dev to staging to production with only environment-specific values changing. That promotes consistency, makes the promoted revision identifiable, and shrinks the surface where environments can diverge.

Why this answer

Repeatable delivery depends on a single declarative source of truth and a promotable artifact. Keeping manifests and configuration in version control with reviewed pipeline changes, and packaging applications as versioned charts or overlays, together ensure the same tested revision can be promoted and that drift is detectable rather than silently accumulating.

Exam trap

The trap here is treating operational convenience, such as ad hoc production edits or trusting the live cluster, as compatible with repeatability, when both undermine the declarative source of truth.

Full explanation →

502

Multi-Selecthard

Which THREE are responsibilities of the OpenTelemetry project? (Select three.)

Select 3 answers

A.Visualize telemetry data

B.Store long-term telemetry data

C.Provide instrumentation libraries

D.Define a standard for telemetry data

E.Provide a vendor-agnostic Collector

AnswersC, D, E

OpenTelemetry ships language-specific instrumentation libraries that generate telemetry for common frameworks without manual coding, satisfying the stem's requirement for project responsibilities. These libraries emit spans, metrics and logs via the OpenTelemetry API, complementing the specification and collector rather than replacing them.

Why this answer

Option C is correct because OpenTelemetry provides language-specific instrumentation libraries (for Java, Python, Go, JavaScript, .NET, etc.) and APIs/SDKs that generate traces, metrics, and logs. Option D is correct because OpenTelemetry defines vendor-neutral specifications and semantic conventions for telemetry data, including the OTLP wire protocol, so signals are portable across tools. Option E is correct because the OpenTelemetry Collector is a vendor-agnostic component that receives, processes, and exports telemetry via receivers, processors, and exporters.

Option A is not a responsibility of OpenTelemetry itself; visualization is handled by backends such as Jaeger, Prometheus, Grafana, or commercial APM UIs. Option B is also not a responsibility of OpenTelemetry; long-term storage is provided by backend observability platforms, not by the OpenTelemetry project.

Exam trap

KCNA often tests the misconception that OpenTelemetry stores or visualizes data, when it is strictly a collection, standardization, and transport layer.

Full explanation →

503

MCQhard

A cluster administrator notices that a Pod scheduled on a node is stuck in the Pending state. The Pod requests 8 CPU cores, but the node has only 4 allocatable CPU cores. The scheduler logs show a FailedScheduling event with the message 'Insufficient cpu'. Which action will allow the Pod to be scheduled without reducing its CPU request?

A.Create a PriorityClass with a high value and assign it to the Pod to preempt other workloads.

B.Reduce the Pod's CPU request to 4 cores so it fits on the existing node.

C.Add a new node to the cluster that has at least 8 allocatable CPU cores and ensure the Pod's scheduling constraints match that node.

D.Add a toleration to the Pod so it can be scheduled on a tainted node.

AnswerC

The scheduler cannot place the Pod because no node has enough allocatable CPU. Adding a node with sufficient capacity and compatible labels or taints allows the scheduler to bind the Pod there. This addresses the root cause without changing the Pod's resource request. Other options either ignore the capacity shortage or alter the request.

Why this answer

The scheduler filters nodes based on available allocatable resources. A Pod requesting 8 CPU cores cannot fit on a node with only 4 allocatable cores, regardless of taints or priority. Adding a node with sufficient CPU capacity and matching scheduling constraints resolves the issue without altering the Pod's request.

Reducing the request would work but violates the scenario constraint.

Exam trap

The trap here is assuming that preemption or tolerations can overcome a node's total CPU capacity limit.

Full explanation →

504

MCQeasy

What is the primary advantage of using Helm to package a Kubernetes application?

A.It automatically scales applications based on load

B.It enforces security policies on deployments

C.It provides a templating engine to parameterize Kubernetes manifests

D.It manages network policies between services

AnswerC

Helm renders parameterised templates into concrete Kubernetes manifests, letting one chart produce environment-specific YAML through values files. This templating engine satisfies the packaging requirement by removing duplicated manifests and enabling consistent, repeatable deployments across clusters.

Why this answer

Helm's primary advantage is its templating engine, which lets you parameterize Kubernetes manifests with values files so the same chart can be reused across environments (dev, staging, prod) with different configurations. It also provides packaging, versioning, and release management, but templating is the core value proposition. The other options describe functionality handled by other tools.

Exam trap

KCNA often tests the misconception that Helm handles autoscaling or security, when its core role is templating, packaging, and release management.

How to eliminate wrong answers

Option A is wrong because autoscaling is handled by the Horizontal Pod Autoscaler and cluster autoscaler, not Helm. Option B is wrong because security policy enforcement is the domain of OPA Gatekeeper, Kyverno, or Pod Security Admission, not Helm. Option D is wrong because network policy management is done via Kubernetes NetworkPolicy resources or CNI plugins like Calico, not Helm charts.

Full explanation →

505

Multi-Selectmedium

Which TWO of the following are best practices for implementing observability in a cloud-native environment?

Select 2 answers

A.Store all raw observability data indefinitely for forensic analysis

B.Use only metrics and avoid logs to reduce complexity

C.Add unique request IDs to logs for end-to-end tracing correlation

D.Randomly sample all traces and logs to reduce storage

E.Use structured logging (e.g., JSON format) for easier automated parsing

AnswersC, E

Unique request IDs let a single transaction be followed across distributed services, satisfying the stem's cloud-native observability requirement for end-to-end tracing. Because each request carries its own identifier, logs from separate pods and microservices can be correlated without relying on hostnames or timestamps, which are unreliable in ephemeral, dynamically scheduled workloads.

Why this answer

Option C is correct because injecting a unique request ID (correlation ID) into every log entry lets you stitch together events across distributed microservices, load balancers, and queues, enabling true end-to-end tracing correlation in a cloud-native environment where a single request fans out across many ephemeral components. Option E is correct because structured logging in JSON (or similar key-value formats) makes logs machine-readable, so log aggregators like Fluentd, Loki, or Elasticsearch can parse fields automatically, enabling reliable filtering, alerting, and correlation without brittle regex parsing of free-text lines. Option A is wrong because retaining all raw observability data indefinitely is costly and unsustainable; best practice is tiered retention with sampling, aggregation, and lifecycle policies.

Option B is wrong because metrics alone lack the contextual detail needed to diagnose root causes; logs, traces, and metrics are complementary pillars of observability. Option D is wrong because randomly sampling all traces and logs indiscriminately can discard critical error and latency data; sampling should be intelligent (e.g., tail-based, error-biased) rather than uniform across everything.

Exam trap

The KCNA exam often tests the misconception that 'more data is always better' (Option A) or that 'simplifying to one data type is efficient' (Option B), while the correct approach balances cost, performance, and diagnostic value through structured logging and correlation IDs.

Full explanation →

506

MCQeasy

Which Open Container Initiative (OCI) specification defines the format of container images?

A.Runtime Spec

B.Image Spec

C.Container Runtime Interface (CRI)

D.Dockerfile specification

AnswerB

The OCI Image Spec defines the image manifest, configuration, filesystem layers and index format, so it governs how container images are structured and referenced. The Runtime Spec instead covers execution, and the Distribution Spec covers registry interactions.

Why this answer

The OCI Image Spec defines the format and content of container images, including the manifest, configuration, and layers. This ensures that any OCI-compliant runtime can run images built by any OCI-compliant tool, enabling interoperability across different container platforms.

Exam trap

The trap here is confusing the OCI Runtime Spec (which deals with running containers) with the OCI Image Spec (which deals with packaging images), or mistaking the Kubernetes CRI plugin interface for an OCI standard.

How to eliminate wrong answers

Option A is wrong because the OCI Runtime Spec defines the lifecycle and configuration of running containers (e.g., bundle format, state machine), not the image format. Option C is wrong because the Container Runtime Interface (CRI) is a Kubernetes API for integrating container runtimes (like containerd or CRI-O), not an OCI specification for image format. Option D is wrong because the Dockerfile specification is a Docker-specific build instruction format, not an OCI standard; OCI images are built from layers, not directly from Dockerfiles.

Full explanation →

507

Multi-Selectmedium

Which TWO of the following are true about Kubernetes Services? (Select 2)

Select 2 answers

A.Services automatically handle Pod replication and scaling.

B.Services can distribute traffic across Pods using labels and selectors.

C.Services can only expose Pods internally within the cluster.

D.Services provide a stable IP address and DNS name for a set of Pods.

E.Services are required for Pods to have persistent storage.

AnswersB, D

A Service uses label selectors to match a dynamic set of Pod endpoints, then load-balances traffic across them as Pods are added or removed. This satisfies the stem's requirement that Services distribute traffic using labels and selectors rather than fixed IP addresses.

Why this answer

Option B is correct because a Kubernetes Service uses label selectors to identify the set of backing Pods (typically via Endpoints/EndpointSlices) and load-balances traffic across them, providing a single access point regardless of how many Pod replicas exist. Option D is correct because a Service is assigned a stable virtual IP (ClusterIP) and a DNS name (e.g., my-svc.my-namespace.svc.cluster.local) that remain constant even as the underlying Pods are created, deleted, or rescheduled with new IPs. Option A is wrong because replication and scaling are handled by controllers such as ReplicaSets or Deployments, not by Services.

Option C is wrong because Services can also be exposed externally via NodePort, LoadBalancer, or ExternalName types, not only internally. Option E is wrong because persistent storage is provided by PersistentVolumes and PersistentVolumeClaims, which are independent of Services.

Exam trap

A common misconception is that Services handle Pod scaling or replication; in fact, Services only provide stable networking and load balancing to a set of Pods selected by labels.

Full explanation →

508

MCQeasy

A team wants a single stable IP address and DNS name that load-balances traffic across a changing set of backend Pods. The Pods are managed by a Deployment and are regularly replaced during rollouts. Which Kubernetes object should they create to provide this stable virtual IP and DNS entry?

A.A NetworkPolicy

B.A ConfigMap

C.An Ingress resource

D.A Service of type ClusterIP

AnswerD

A ClusterIP Service is assigned a stable virtual IP and a DNS name, and it selects backend Pods by label. As Pods are created or deleted during rollouts, the Service's Endpoints or EndpointSlices are updated, so clients keep using the same address. This directly meets the requirement for stable load-balanced access to a dynamic Pod set.

Why this answer

A Service abstracts a set of Pods behind a stable virtual IP and DNS name, and its label selector keeps the backend list current as Pods come and go. ClusterIP is the default type and is ideal for internal access. Ingress, NetworkPolicy, and ConfigMap serve routing, security, and configuration purposes respectively, and none of them supplies a stable virtual IP for a dynamic Pod set.

Exam trap

The trap here is assuming Ingress replaces a Service, when Ingress normally routes to a Service that provides the stable virtual IP.

Full explanation →

509

MCQmedium

A cluster administrator needs to run a node-level logging agent on every node, including nodes added later. The agent must collect logs from the host filesystem and must run even if a node is cordoned. Which workload resource should be used?

A.A StatefulSet with one replica per node

B.A Job with a parallelism equal to the number of nodes

C.A Deployment with a nodeSelector matching each node's label

D.A DaemonSet

AnswerD

A DaemonSet ensures that a copy of a pod runs on every node in the cluster, and it automatically schedules pods onto nodes added later. Its pods are created by the DaemonSet controller with tolerations that allow them to run on nodes that are cordoned or have standard taints, making it the correct choice for node-level agents such as log collectors.

Why this answer

DaemonSets are purpose-built for per-node workloads. The DaemonSet controller creates a pod on each eligible node and adds new pods when nodes join the cluster. Its default tolerations allow the pods to run on nodes that are unschedulable or carry common taints, which is essential for infrastructure agents like log shippers, monitoring exporters, and CNI plugins that must operate everywhere.

Exam trap

The trap here is choosing a Deployment with a nodeSelector, which can place pods on labeled nodes but does not guarantee one pod per node or cover nodes added later.

Full explanation →

510

MCQmedium

Which service mesh component is responsible for handling inter-service communication as a sidecar proxy?

A.Mixer

B.Pilot

C.Envoy

D.Citadel

AnswerC

Envoy is the high-performance proxy that Istio and similar service meshes deploy as a sidecar container alongside each workload. It intercepts inbound and outbound traffic, applying routing, mTLS and telemetry policies for all inter-service communication.

Why this answer

Envoy is the correct answer because it is the sidecar proxy component in Istio that handles all inter-service communication. It intercepts traffic between microservices and applies routing, load balancing, and security policies defined by the control plane. Envoy runs as a sidecar container alongside each service instance, managing inbound and outbound traffic at the L4/L7 layer.

Exam trap

CNCF often tests the distinction between data-plane and control-plane components, so the trap here is that candidates may confuse Pilot (control plane) with the sidecar proxy that actually handles traffic, or incorrectly associate Mixer with traffic management due to its former role in policy enforcement.

How to eliminate wrong answers

Option A (Mixer) is wrong because Mixer was a deprecated Istio component used for telemetry collection and policy enforcement, not for proxying inter-service traffic; it was removed in Istio 1.5. Option B (Pilot) is wrong because Pilot is the control plane component that translates high-level routing rules into Envoy configuration and distributes them to sidecars, but it does not handle data-plane traffic itself. Option D (Citadel) is wrong because Citadel is the Istio security component responsible for certificate issuance and key management for mTLS, not for proxying service-to-service communication.

Full explanation →

511

MCQmedium

An administrator needs to run a stateful database in Kubernetes that requires a stable network identity, persistent storage that survives pod rescheduling, and ordered deployment and scaling. Which Kubernetes resource should be used to meet these requirements?

A.StatefulSet

B.ReplicaSet

C.Deployment

D.DaemonSet

AnswerA

StatefulSet is designed for stateful applications, providing stable, unique network identifiers (pod name and headless Service), persistent storage through volumeClaimTemplates, and ordered, graceful deployment and scaling. It satisfies the need for a stable identity and durable storage across rescheduling, making it the correct choice for a stateful database.

Why this answer

StatefulSet is the only workload resource that provides stable network identities, persistent storage per replica, and ordered deployment and scaling. Deployments, DaemonSets, and ReplicaSets are designed for stateless or node-wide workloads and do not offer these guarantees. For a stateful database, StatefulSet is the correct and standard Kubernetes solution.

Exam trap

The trap here is assuming that any workload controller can manage stateful applications, when only StatefulSet provides stable identities and persistent storage per pod.

Full explanation →

512

MCQmedium

A pod is stuck in 'Pending' state. After running 'kubectl describe pod', you see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the most likely cause?

A.The pod's CPU request exceeds the available CPU on all nodes

B.The pod is exceeding its memory limit

C.The network plugin is not installed

D.The container image is too large

AnswerA

The scheduler's predicate phase filters nodes by the pod's CPU request against each node's allocatable capacity. All three nodes fail that filter, so no feasible node remains and the pod stays unscheduled. Raising requests or adding capacity resolves it.

Why this answer

The pod is stuck in 'Pending' state because the Kubernetes scheduler cannot find a node that satisfies the pod's resource requirements. The event '0/3 nodes are available: 3 Insufficient cpu' explicitly indicates that every node in the cluster lacks sufficient allocatable CPU capacity to meet the pod's CPU request. This means the sum of CPU requests across all pods on each node, plus the new pod's request, exceeds the node's CPU capacity, causing the scheduler to leave the pod unscheduled.

Exam trap

A common mistake in Kubernetes is confusing resource requests (used for scheduling) with resource limits (used for runtime enforcement). Candidates may incorrectly think a pod stuck in 'Pending' is due to exceeding a limit rather than an unsatisfied request.

How to eliminate wrong answers

Option B is wrong because exceeding a memory limit causes a pod to be terminated (OOMKilled) or restarted, not stuck in 'Pending' state; 'Pending' relates to scheduling, not runtime resource limits. Option C is wrong because a missing network plugin (e.g., CNI) would cause pods to fail with 'CrashLoopBackOff' or 'ContainerCreating' errors, not a scheduling failure due to insufficient CPU. Option D is wrong because a large container image affects image pull time and can cause 'ImagePullBackOff' or 'ErrImagePull' events, but does not prevent the scheduler from assigning the pod to a node; the pod would still be scheduled and then fail during container creation.

Full explanation →

513

MCQhard

Your organization runs a cloud-native e-commerce platform on Kubernetes. The platform consists of several microservices: a frontend service, an order service, a payment service, and a shipping service. All services communicate via HTTP REST APIs. Recently, during a flash sale event, the platform experienced a cascading failure. The order service became overwhelmed with requests and started responding slowly. This caused the frontend service to time out waiting for order responses, and eventually the frontend service crashed due to exhausted thread pools. The payment and shipping services were unaffected because they are called asynchronously via a message queue. You need to redesign the system to prevent such cascading failures in the future. Which approach is the most effective?

A.Scale up the frontend service to handle more concurrent requests

B.Convert all inter-service communication to synchronous calls with retries

C.Increase the timeout values in the frontend service configuration

D.Implement circuit breakers in the frontend service for calls to the order service

AnswerD

Circuit breakers in the frontend trip when order-service calls exceed a failure threshold, failing fast instead of holding threads until timeout. This stops thread-pool exhaustion and the cascading failure, directly addressing the synchronous HTTP dependency that caused the frontend to crash.

Why this answer

Implementing circuit breakers in the frontend service for calls to the order service prevents cascading failures by monitoring failure rates and automatically tripping the circuit when the order service becomes slow or unresponsive. This stops the frontend from exhausting its thread pools waiting for timeouts, allowing it to fail fast and return a fallback response. Circuit breakers are a proven resilience pattern in cloud-native architectures, especially for synchronous HTTP REST calls where latency spikes can propagate.

Exam trap

CNCF often tests the misconception that scaling or increasing timeouts is a sufficient fix for cascading failures, but the trap here is that these options treat symptoms rather than applying the circuit breaker pattern, which is the standard resilience mechanism for synchronous calls in cloud-native systems.

How to eliminate wrong answers

Option A is wrong because scaling up the frontend service only increases the number of concurrent requests it can handle, but does not address the root cause—the order service being overwhelmed—and may actually worsen the cascading failure by allowing more requests to pile up and exhaust thread pools faster. Option B is wrong because converting all inter-service communication to synchronous calls with retries would increase coupling and amplify failures; retries during overload can cause retry storms, further degrading the order service and increasing latency. Option C is wrong because increasing timeout values only delays the inevitable thread pool exhaustion, as the frontend will hold connections longer without reducing the load on the order service, and may lead to resource starvation under sustained high traffic.

Full explanation →

514

MCQhard

A Kubernetes Deployment is configured with 'strategy.type: RollingUpdate'. The team wants to ensure that during an update, no more than 25% of pods are unavailable at any time. Which specification should be added?

A.spec.minReadySeconds: 30

B.spec.replicas: 4

C.strategy.rollingUpdate.maxUnavailable: 25%

D.strategy.rollingUpdate.maxSurge: 25%

AnswerC

Setting `maxUnavailable: 25%` directly caps how many pods may be taken offline during a rolling update, satisfying the stem's requirement that no more than a quarter be unavailable at once. It works alongside `maxSurge` to control update pacing, and belongs under `strategy.rollingUpdate` in the Deployment spec.

Why this answer

In a RollingUpdate strategy, `maxUnavailable` defines the maximum number of pods that can be unavailable during the update relative to the desired replica count, and `maxSurge` defines how many extra pods can be created above the desired count. Setting `strategy.rollingUpdate.maxUnavailable: 25%` directly enforces the requirement that no more than 25% of pods are down at any point. The default is 25%, but the question asks which specification to *add* to guarantee it explicitly.

Exam trap

KCNA often tests the distinction between `maxUnavailable` (how many pods may be down) and `maxSurge` (how many extra pods may exist), so candidates who confuse the two pick Option D.

How to eliminate wrong answers

Option A is wrong because `minReadySeconds` controls how long a newly created pod must be ready before it is considered available — it affects rollout pacing, not the maximum number of unavailable pods. Option B is wrong because `replicas: 4` only sets the desired pod count; it says nothing about availability during an update. Option D is wrong because `maxSurge` controls how many *extra* pods can be created above the desired count during a rollout — it governs over-provisioning, not unavailability.

Full explanation →

515

MCQmedium

Which control plane component is responsible for persisting the entire cluster state?

A.kube-controller-manager

B.etcd

C.kube-apiserver

D.kube-scheduler

AnswerB

etcd is the distributed key-value store that holds all cluster state, including object definitions, configuration and metadata. The API server reads and writes exclusively through it, making etcd the sole control plane component responsible for persisting the entire cluster state.

Why this answer

etcd is the distributed key-value store that serves as the single source of truth for the entire cluster state, including all objects (Pods, Services, ConfigMaps, etc.) and their desired and current status. The kube-apiserver is the only component that directly communicates with etcd, ensuring that all state changes are persisted durably and consistently. Without etcd, the cluster would have no record of its configuration or running workloads.

Exam trap

A common trap is to think the kube-apiserver persists state because it is the central API gateway, but in reality, the API server is stateless and relies entirely on etcd for durable storage.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager is a control loop that watches the shared state through the API server and makes changes to move the current state toward the desired state; it does not persist any data itself. Option C is wrong because kube-apiserver is the front-end for the control plane that validates and processes REST requests, but it delegates all persistent storage to etcd and does not store data locally. Option D is wrong because kube-scheduler is responsible for assigning Pods to Nodes based on resource availability and constraints; it reads cluster state from the API server but never writes or persists any state.

Full explanation →

516

MCQmedium

A team is designing a Kubernetes cluster for a production workload that requires high availability. They have three worker nodes in different availability zones. Which statement about scheduling Pods is correct?

A.Use nodeSelector to assign Pods to nodes in different zones.

B.Add tolerations for the zone taint.

C.Use podAntiAffinity with a requiredDuringSchedulingIgnoredDuringExecution rule.

D.Define a Pod topology spread constraint with topologyKey: topology.kubernetes.io/zone.

AnswerD

A topology spread constraint with topologyKey topology.kubernetes.io/zone distributes Pods across availability zones, so replicas are not concentrated in one zone. This satisfies the high-availability requirement by ensuring zone-level failure does not take down every Pod.

Why this answer

A Pod topology spread constraint with `topologyKey: topology.kubernetes.io/zone` explicitly instructs the scheduler to distribute Pods evenly across the specified failure domains (availability zones). This ensures that if one zone fails, the remaining zones still have running Pods, achieving high availability for the production workload.

Exam trap

The KCNA exam often tests the distinction between mechanisms that merely allow placement (tolerations, nodeSelector) versus those that enforce distribution (topology spread constraints), leading candidates to confuse permission with active scheduling policy.

How to eliminate wrong answers

Option A is wrong because `nodeSelector` only matches Pods to nodes with specific labels, but it does not enforce distribution across zones; Pods could still be scheduled on a single zone if all matching nodes are there. Option B is wrong because tolerations allow Pods to be scheduled on tainted nodes (e.g., zone-specific taints), but they do not guarantee spread across zones; they merely permit scheduling on nodes that would otherwise repel the Pod. Option C is wrong because `podAntiAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` prevents Pods from being co-located on the same node (or topology), but it does not ensure balanced distribution across zones; it only avoids placing replicas together, which could still result in all replicas landing in one zone if only one zone has enough nodes.

Full explanation →

517

Multi-Selecteasy

Which TWO components run on every worker node in a Kubernetes cluster?

Select 2 answers

A.kube-scheduler

B.kubelet

C.etcd

D.kube-proxy

E.kube-apiserver

AnswersB, D

The kubelet runs as an agent on every worker node, receiving PodSpecs from the control plane and ensuring the described containers are running and healthy via the container runtime. It is a node-level, not control-plane, component.

Why this answer

kubelet (B) is correct because it is the primary node agent that runs on every worker node, registering the node with the API server and managing pod lifecycles by ensuring containers described in PodSpecs are running and healthy. kube-proxy (D) is also correct because it runs on every worker node to maintain network rules (via iptables, IPVS, or nftables) that implement Kubernetes Service abstraction and enable pod-to-pod and external communication. In contrast, kube-scheduler (A), etcd (C), and kube-apiserver (E) are control plane components that typically run on master/control-plane nodes, not on every worker node, so they do not belong in this answer.

Exam trap

CNCF often tests the distinction between control plane components and worker node components, trapping candidates who assume that all core Kubernetes components (like kube-scheduler or etcd) run on every node.

Full explanation →

518

Matchingmedium

Match each cloud native concept to its definition.

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

Concepts

Matches

Lightweight, standalone executable package that includes everything needed

Architectural style that structures an app as a collection of loosely coupled services

Automated configuration, coordination, and management of containers

Approach where servers are never modified after deployment; replaced instead

Specifying the desired state, letting the system achieve and maintain it

Why these pairings

The correct matches are: Microservices with loosely coupled services, Service Mesh with service-to-service communication, Serverless with cloud provider managing resources, and Orchestration with automated management. Common confusions include swapping definitions between Microservices and Service Mesh, or between Serverless and Orchestration.

Full explanation →

519

MCQmedium

A platform team runs a Kubernetes cluster where the kubelet and container runtime expose metrics on each node. The team wants to collect node-level CPU and memory metrics into Prometheus without deploying a separate exporter on every node. Which component should they configure Prometheus to scrape?

A.The kubelet's built-in cAdvisor endpoint

B.kube-state-metrics

C.The Kubernetes API server's /metrics endpoint

D.The container runtime's CRI logging socket

AnswerA

The kubelet exposes cAdvisor metrics on its /metrics endpoint, which includes node-level and container-level CPU and memory usage. Prometheus can scrape this endpoint on each node without deploying an additional exporter. This directly meets the requirement because the kubelet is already present on every node and surfaces the needed resource metrics through its built-in cAdvisor integration.

Why this answer

The kubelet already runs on every node and exposes cAdvisor metrics, including node and container CPU and memory usage, through its /metrics endpoint. Prometheus can scrape this endpoint directly, so no separate per-node exporter is required. Other listed components either report object state, control-plane request metrics, or logs, none of which provide the node resource metrics needed here.

Exam trap

The trap here is assuming that kube-state-metrics reports resource usage, when it actually reports the state of Kubernetes API objects rather than node or container CPU and memory consumption.

Full explanation →

520

MCQmedium

A developer runs `kubectl get pods` and notices that one Pod is stuck in the `Pending` state. The Pod's resource requests are modest, and the node has sufficient CPU and memory. Which of the following is the MOST likely reason the Pod is not being scheduled?

A.The Pod's service account does not exist.

B.The Pod's container image is not available in the registry.

C.The Pod's liveness probe is failing.

D.The Pod has a nodeSelector that does not match any node's labels.

AnswerD

A nodeSelector restricts scheduling to nodes with matching labels. If no node has the specified label, the scheduler cannot place the Pod, leaving it Pending. Other factors like resource availability are not the issue here, so this is the most likely cause.

Why this answer

The scheduler assigns Pods to nodes based on resource requests, node selectors, affinity rules, and taints/tolerations. When a Pod remains Pending despite adequate resources, a nodeSelector mismatch is a common cause. The scheduler cannot find a node that satisfies the label constraint, so it leaves the Pod unscheduled until a suitable node becomes available or the selector is corrected.

Exam trap

The trap here is assuming that Pending always means insufficient resources, while ignoring scheduling constraints like nodeSelector or affinity.

Full explanation →

521

MCQeasy

A developer wants to monitor the health of a Kubernetes deployment by checking if the number of ready replicas matches the desired replicas. Which metric from kube-state-metrics should they query?

A.kube_deployment_status_replicas_ready

B.kube_deployment_spec_replicas

C.kube_node_status_condition

D.kube_pod_container_status_running

AnswerA

`kube_deployment_status_replicas_ready` exposes the count of ready replicas directly from the Deployment's status, satisfying the requirement to compare ready against desired replicas. Pairing it with `kube_deployment_spec_replicas` gives the desired count, enabling an alert when readiness diverges from the specification.

Why this answer

`kube_deployment_status_replicas_ready` directly exposes the number of ready replicas for a Deployment, which can be compared against `kube_deployment_spec_replicas` to determine if the desired state matches the actual healthy state. This metric is emitted by kube-state-metrics, which generates Prometheus-compatible metrics from Kubernetes API objects, making it the standard choice for monitoring Deployment health.

Exam trap

The trap here is that candidates might confuse metrics that show pod state (like `kube_pod_container_status_running`) with Deployment-level readiness, not realizing that a pod can be running but not ready, and that the correct metric must reflect the Deployment's own status field.

How to eliminate wrong answers

Option B is wrong because `kube_deployment_spec_replicas` only shows the desired number of replicas as defined in the Deployment spec, not the actual ready count, so it cannot alone indicate health. Option C is wrong because `kube_node_status_condition` tracks node-level conditions (e.g., Ready, DiskPressure) and has no relation to Deployment replica health. Option D is wrong because `kube_pod_container_status_running` counts containers in Running state, not ready replicas of a Deployment, and does not account for readiness probes or desired replica counts.

Full explanation →

522

MCQeasy

Which component of the control plane is the only one that directly interacts with etcd?

A.kube-apiserver

B.kube-controller-manager

C.kube-scheduler

D.kubelet

AnswerA

The kube-apiserver is the sole control plane component that reads from and writes to etcd, serving as the only gateway to cluster state. Controllers and schedulers watch and mutate resources exclusively through it, satisfying the constraint that no other component holds a direct etcd connection.

Why this answer

The kube-apiserver is the only component of the Kubernetes control plane that directly interacts with etcd. It acts as the front-end for the control plane, exposing the Kubernetes API, and all reads and writes to the cluster's state stored in etcd must go through the API server. Other components like the kube-controller-manager and kube-scheduler only communicate with etcd indirectly via the kube-apiserver, never directly.

Exam trap

The trap here is that candidates often assume the kube-controller-manager or kube-scheduler directly access etcd because they manage cluster state, but in reality they only interact with etcd indirectly through the kube-apiserver.

How to eliminate wrong answers

Option B is wrong because the kube-controller-manager watches and reconciles cluster state by making API calls to the kube-apiserver, not by directly querying or writing to etcd. Option C is wrong because the kube-scheduler assigns pods to nodes by communicating with the kube-apiserver to update pod bindings, and it never directly accesses etcd. Option D is wrong because kubelet is a node-level agent that interacts only with the kube-apiserver (e.g., to report node status or watch for pod assignments) and has no direct connection to etcd.

Full explanation →

523

Multi-Selectmedium

Which TWO of the following are valid uses of Kubernetes Namespaces? (Select 2)

Select 2 answers

A.Setting CPU and memory limits at the namespace level

B.Enforcing network policies per namespace

C.Providing logical separation between different environments (e.g., dev, staging, prod) within the same cluster

D.Isolating node resources for different workloads

E.Enabling RBAC authentication for users in a namespace

AnswersB, C

Network policies are namespaced resources, so applying a NetworkPolicy within a namespace scopes ingress and egress rules to the pods it selects there, satisfying the requirement to isolate traffic between teams sharing a cluster. This is a genuine namespace use, unlike cluster-wide concerns such as node affinity or storage provisioning.

Why this answer

Option B is correct because Kubernetes NetworkPolicy objects are namespaced resources, so network policies are defined and applied per namespace to control ingress and egress traffic for the pods within that namespace. Option C is correct because namespaces provide logical partitioning of cluster resources, allowing teams to run dev, staging, and prod workloads in the same physical cluster with separate names, quotas, and access controls. Option A is not correct because CPU and memory limits are set on Pods/Containers (via resources.requests/limits) or enforced cluster-wide per namespace using ResourceQuota and LimitRange objects, not as a namespace-level setting itself.

Option D is not correct because namespaces do not isolate node resources; node-level isolation is achieved through taints, tolerations, node affinity, or separate node pools. Option E is not correct because namespaces do not provide authentication; RBAC handles authorization, while authentication is performed by the API server via tokens, certificates, or external identity providers, with RoleBindings scoped to a namespace.

Exam trap

CNCF often tests the misconception that namespaces can enforce resource limits directly, when in fact ResourceQuotas and LimitRanges are the mechanisms that operate within a namespace, not the namespace itself.

Full explanation →

524

MCQmedium

In a service mesh architecture, which component is responsible for intercepting and managing traffic between microservices?

A.Control plane

B.API gateway

C.Service registry

D.Sidecar proxy

AnswerD

A sidecar proxy runs alongside each microservice instance, transparently intercepting all inbound and outbound network traffic. This satisfies the service mesh requirement for per-service traffic management, since the sidecar enforces routing, retries, mutual TLS and telemetry policies without modifying application code.

Why this answer

In a service mesh, the sidecar proxy is deployed alongside each microservice instance and transparently intercepts all inbound and outbound network traffic. It enforces policies, collects telemetry, and manages routing without requiring changes to the application code. The control plane configures these proxies but does not handle the actual data path.

Exam trap

KCNA often tests the distinction between the control plane (management) and data plane (traffic interception), causing candidates to incorrectly choose the control plane as the component that handles traffic.

How to eliminate wrong answers

Option A is wrong because the control plane only manages and configures the sidecar proxies (e.g., distributing policies, service discovery data), but it does not sit in the data path to intercept traffic. Option B is wrong because an API gateway handles north-south traffic (external clients to services) and is not the component that intercepts east-west traffic between microservices inside the mesh. Option C is wrong because a service registry only maintains a list of available service instances for discovery; it does not intercept or manage traffic.

Full explanation →

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 451–525