Kubernetes and Cloud Native Associate KCNA KCNA Questions 526–600 | Page 8/13

526

MCQeasy

What is the Container Runtime Interface (CRI)?

A.A tool for building container images

B.A standard for container runtime logs

C.A specification for container images

D.An API between kubelet and container runtime

AnswerD

CRI is the abstraction layer kubelet calls to start, stop and inspect containers, decoupling Kubernetes from any specific runtime. It satisfies the stem's requirement by defining the gRPC API between kubelet and runtimes such as containerd or CRI-O, so runtimes can be swapped without recompiling kubelet.

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 kubelet. It defines a gRPC API (protocol buffers) for the kubelet to communicate with the container runtime, covering operations like pod lifecycle management and image management. Option D correctly identifies this as the API between the kubelet and the container runtime.

Exam trap

The trap here is that candidates often confuse the CRI with container image specifications (OCI Image Spec) or container runtime tools (like Docker), but the CRI is strictly an API interface between the kubelet and the runtime, not a tool or a specification for images.

How to eliminate wrong answers

Option A is wrong because building container images is the job of tools like Docker Build, Buildah, or Kaniko, not the CRI, which is an interface for runtime orchestration. Option B is wrong because the CRI does not standardize container runtime logs; log management is handled by the kubelet via the logging interface (e.g., using the 'kubectl logs' command) and the container runtime's logging driver. Option C is wrong because container image specifications are defined by the OCI Image Spec (Open Container Initiative), not by the CRI, which focuses on runtime operations like starting and stopping containers.

Full explanation →

527

MCQhard

You have a Kubernetes cluster with a Deployment that uses a PersistentVolumeClaim (PVC) to store application data. The PVC is bound to a PersistentVolume (PV) with a Retain reclaim policy. You delete the Deployment and the PVC. What happens to the underlying storage?

A.The PV is immediately available for binding to a new PVC because the data is automatically wiped.

B.The PV remains, but it is in a Released state and cannot be bound to a new PVC until manually reclaimed.

C.The PV is automatically deleted, and the storage is released.

D.The PV is deleted, but the underlying storage is retained and must be manually cleaned up.

AnswerB

When a PVC is deleted, the PV's reclaim policy determines its fate. With Retain, the PV moves to a Released state, and the underlying storage is preserved. The PV is not available for new claims because it still holds data and requires manual intervention: an administrator must delete the PV and either clean up or reuse the storage. This prevents accidental data loss and allows for data recovery.

Why this answer

With a Retain reclaim policy, deleting a PVC does not delete the PV or the underlying storage. The PV transitions to a Released state, preserving data and preventing automatic rebinding. An administrator must manually delete the PV and clean up the storage before it can be reused.

This is different from the Delete policy, which dynamically deletes the PV and storage.

Exam trap

The trap here is confusing the Retain reclaim policy with the Delete policy, assuming that the PV is deleted or automatically made available.

Full explanation →

528

MCQeasy

Which command is used to view detailed information about a specific pod, including events and conditions?

A.kubectl logs pod

B.kubectl describe pod

C.kubectl exec pod

D.kubectl get pod

AnswerB

kubectl describe pod retrieves a single Pod's full state, including container statuses, conditions and the recent event stream from the API server. This satisfies the requirement to see events and conditions, which kubectl get pod alone does not display.

Why this answer

The `kubectl describe pod` command retrieves detailed information about a specific pod, including its current state, metadata, labels, annotations, container details, resource limits, and a chronological list of events and conditions (e.g., PodScheduled, Initialized, Ready, ContainersReady). This makes it the correct tool for viewing comprehensive pod status and lifecycle events.

Exam trap

The trap here is that candidates often confuse `kubectl get pod` (which shows a summary) with `kubectl describe pod` (which shows full details and events), leading them to choose the 'get' option when the question explicitly asks for 'detailed information including events and conditions'.

How to eliminate wrong answers

Option A is wrong because `kubectl logs pod` only streams or retrieves the console output (stdout/stderr) from a container within a pod, not the pod's metadata, conditions, or events. Option C is wrong because `kubectl exec pod` runs a command inside a container of the pod for interactive debugging, not for viewing pod details or events. Option D is wrong because `kubectl get pod` outputs a concise, tabular summary of pods (name, status, restarts, age) without the detailed conditions, events, or full configuration that `describe` provides.

Full explanation →

529

MCQmedium

In a multi-cloud architecture, what is a common use case for a service mesh?

A.To enable secure service-to-service communication across clusters

B.To synchronize Kubernetes resources across clouds

C.To provide cloud-agnostic block storage

D.To provide a single ingress gateway for all clouds

AnswerA

A service mesh provides mutual TLS, identity-based authorisation and traffic policy between workloads, extending these controls across Kubernetes clusters on different providers. That directly satisfies the multi-cloud constraint, where native cluster networking cannot span providers, so cross-cluster service-to-service communication needs a consistent, encrypted data plane.

Why this answer

A service mesh, such as Istio or Linkerd, provides a dedicated infrastructure layer for handling service-to-service communication. In a multi-cloud architecture, its common use case is to enable secure, observable, and resilient communication between services running in different Kubernetes clusters across clouds, using mutual TLS (mTLS) for encryption and traffic policies for routing.

Exam trap

CNCF often tests the misconception that a service mesh is a general-purpose tool for all cross-cloud operations, when in reality it is specifically designed for service-to-service communication (east-west traffic) and does not handle resource synchronization, storage, or ingress gateway functions.

How to eliminate wrong answers

Option B is wrong because synchronizing Kubernetes resources across clouds is typically done by tools like Karmada, Cluster API, or Terraform, not by a service mesh, which focuses on network traffic management. Option C is wrong because cloud-agnostic block storage is provided by storage abstraction layers like CSI (Container Storage Interface) drivers or solutions like Rook/Ceph, not by a service mesh, which operates at Layer 7 (HTTP/gRPC) and Layer 4 (TCP). Option D is wrong because a single ingress gateway for all clouds is the role of a multi-cluster ingress controller or global load balancer (e.g., NGINX Ingress Controller with external-dns), while a service mesh handles east-west traffic between services, not north-south ingress traffic.

Full explanation →

530

MCQeasy

A cluster administrator deploys a web application as a Deployment named 'web' with 4 replicas. Users report that requests to the application sometimes reach a Pod that is still starting up and not ready to serve traffic. Which Kubernetes object should the administrator configure to ensure only ready Pods receive traffic?

A.A startup probe on the Pod template

B.A readiness probe on the Pod template

C.A PodDisruptionBudget on the Deployment

D.A liveness probe on the Pod template

AnswerB

A readiness probe determines whether a container is ready to accept traffic. When a Pod is not ready, the kubelet sets its Ready condition to False, and the Endpoints controller removes its IP from the Service's endpoints. This directly prevents traffic from reaching starting or unhealthy Pods, matching the administrator's goal.

Why this answer

Readiness probes control whether a Pod's IP is included in a Service's endpoints. When the probe fails, the Pod is marked NotReady and removed from load balancing. Liveness probes restart containers, startup probes delay other probes, and PodDisruptionBudgets govern voluntary evictions.

Only a readiness probe directly ensures traffic goes solely to Pods ready to serve requests.

Exam trap

The trap here is confusing liveness probes, which restart containers, with readiness probes, which control Service endpoint membership.

Full explanation →

531

Multi-Selectmedium

Which THREE are key benefits of using a service mesh in a cloud-native architecture? (Choose 3)

Select 3 answers

A.Persistent storage management for stateful applications.

B.Mutual TLS (mTLS) encryption between services.

C.Automatic horizontal scaling of pods.

D.Observability through distributed tracing and metrics.

E.Traffic management such as canary deployments and circuit breaking.

AnswersB, D, E

Mutual TLS encrypts service-to-service traffic in both directions, with each side verifying the other's certificate. This satisfies the stem's cloud-native security benefit: identity-based authentication and confidentiality for east-west traffic without application code changes, replacing plaintext inter-pod communication with cryptographically verified channels.

Why this answer

Option B is correct because a service mesh like Istio or Linkerd transparently provisions mutual TLS (mTLS) between sidecar proxies, giving every service-to-service call strong identity-based encryption and authentication without application code changes. Option D is correct because service meshes emit uniform telemetry from their sidecars — distributed traces (e.g., via Envoy and Zipkin/Jaeger), request metrics (latency, error rates, throughput), and access logs — providing consistent observability across heterogeneous services. Option E is correct because the mesh's control plane configures traffic routing rules that enable canary releases, blue/green rollouts, retries, timeouts, and circuit breaking at the proxy layer.

Option A is not a service mesh benefit; persistent storage for stateful workloads is handled by CSI drivers, PersistentVolumes, and StatefulSets, not by the mesh data plane. Option C is also not a mesh function; automatic horizontal pod scaling is performed by the Kubernetes Horizontal Pod Autoscaler (HPA) based on metrics, independent of the service mesh.

Exam trap

CNCF often tests the misconception that a service mesh provides infrastructure-level features like storage or scaling, when in reality it is strictly a Layer 4/7 networking and security abstraction that operates independently of compute or storage resources.

Full explanation →

532

MCQmedium

A cluster administrator needs to run a critical system daemon that must continue running even when a node is marked as unschedulable for maintenance. The DaemonSet Pods should tolerate the node's taint. Which taint should the DaemonSet Pod tolerate to achieve this?

A.node.kubernetes.io/unreachable

B.node.kubernetes.io/unschedulable

C.node.kubernetes.io/not-ready

D.node.kubernetes.io/memory-pressure

AnswerB

When a node is cordoned using kubectl cordon, Kubernetes adds the taint node.kubernetes.io/unschedulable:NoSchedule. To allow DaemonSet Pods to continue running on that node, the Pod template must include a toleration for this taint. This is the correct taint to tolerate for maintenance scenarios where you want existing Pods to keep running but prevent new scheduling.

Why this answer

Cordoning a node adds the taint node.kubernetes.io/unschedulable:NoSchedule. To keep DaemonSet Pods running on that node during maintenance, the Pod template must tolerate this taint. The other taints represent different node conditions and do not address the unschedulable state.

Exam trap

The trap here is assuming that tolerating not-ready or unreachable taints would allow Pods to run on cordoned nodes, but only the unschedulable taint is added during cordon.

Full explanation →

533

MCQmedium

An administrator needs to expose a set of pods running a web application on a static port on each node's IP address. Which Service type should they use?

A.ClusterIP

B.NodePort

C.ExternalName

D.LoadBalancer

AnswerB

NodePort exposes a Service on a static port on every node's IP address, forwarding traffic to the backing pods. This matches the requirement for a fixed port reachable via each node, unlike ClusterIP or LoadBalancer.

Why this answer

A NodePort service exposes the application on a static port (30000–32767) on every node's IP address, making the pods accessible externally via <NodeIP>:<NodePort>. This matches the requirement to expose pods on a static port on each node's IP address without needing an external load balancer.

Exam trap

CNCF often tests the misconception that NodePort is the only way to expose services externally, but the trap here is confusing NodePort with LoadBalancer, which also provides external access but requires cloud provider integration and does not guarantee a static port on each node.

How to eliminate wrong answers

Option A is wrong because ClusterIP exposes the service only on a cluster-internal IP, making it unreachable from outside the cluster. Option C is wrong because ExternalName maps a service to an external DNS name via CNAME records, not to node IPs or ports. Option D is wrong because LoadBalancer provisions an external cloud load balancer with a public IP, which is overkill and not required for exposing on each node's static port.

Full explanation →

534

MCQmedium

A company is deploying a microservices application on Kubernetes. They want to ensure that configuration data, such as database URLs and feature flags, can be updated without rebuilding container images. Which Kubernetes resource should they use?

A.Secrets

B.Services

C.Deployments

D.ConfigMaps

AnswerD

ConfigMaps store non-confidential key-value configuration separately from pod specifications, so database URLs and feature flags can be mounted as volumes or injected as environment variables and updated without rebuilding the image. Secrets serve credentials, while Deployments and Services handle workloads and networking.

Why this answer

ConfigMaps are the correct Kubernetes resource for decoupling configuration data (like database URLs and feature flags) from container images. They allow you to inject configuration as environment variables or mounted volumes without rebuilding or redeploying the container image, enabling runtime updates.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming that all configuration must be stored in Secrets, but the KCNA exam tests the distinction that ConfigMaps are for non-sensitive data and Secrets are for sensitive data.

How to eliminate wrong answers

Option A is wrong because Secrets are designed for sensitive data (e.g., passwords, tokens) and are not intended for general configuration like database URLs or feature flags; using Secrets for non-sensitive data adds unnecessary complexity and security overhead. Option B is wrong because Services are a networking abstraction that provides stable endpoints for Pods, not a mechanism for storing or injecting configuration data. Option C is wrong because Deployments manage the desired state and lifecycle of Pods (e.g., scaling, rolling updates), but they do not store configuration data; configuration is typically provided via ConfigMaps or Secrets referenced in the Pod spec.

Full explanation →

535

Multi-Selectmedium

Which TWO actions can improve the DORA metric 'Mean Time to Recovery (MTTR)'?

Select 2 answers

A.Increasing deployment frequency

B.Slowing down the release cycle

C.Using feature flags to disable faulty code quickly

D.Adding more manual approval steps

E.Implementing automated rollback on health check failure

AnswersC, E

Feature flags let operators disable faulty code paths at runtime, restoring service without redeploying or rolling back artefacts. This directly shortens the time between failure detection and recovery, satisfying the MTTR improvement by removing the build-and-deploy delay from remediation.

Why this answer

Option C is correct because feature flags decouple deployment from release, letting you toggle off a faulty code path at runtime without a full redeploy, which directly shortens the time from failure detection to service restoration. Option E is correct because automated rollback triggered by health check failures removes human latency from the recovery path, restoring the last known-good version as soon as an unhealthy state is detected. Option A is incorrect because deployment frequency is a separate DORA metric (deployment frequency) and does not by itself reduce recovery time.

Option B is incorrect because slowing the release cycle reduces deployment frequency and delays fixes, which typically worsens MTTR. Option D is incorrect because adding manual approval steps inserts human delay into remediation, increasing rather than decreasing MTTR.

Exam trap

KCNA often tests whether candidates conflate deployment frequency with recovery speed, so options like 'increase deployment frequency' or 'slow the release cycle' look like reliability improvements but do not address MTTR.

Full explanation →

536

MCQhard

In a YAML manifest for a Deployment, which field defines the number of pod replicas?

A.spec.strategy.replicas

B.metadata.replicas

C.spec.replicas

D.spec.template.replicas

AnswerC

Within a Deployment manifest, spec.replicas is the integer field declaring how many identical pod instances the ReplicaSet should maintain. It sits under spec alongside selector and template, directly answering the stem's request for the replica-count field.

Why this answer

In a Kubernetes Deployment manifest, the `spec.replicas` field is the correct place to define the desired number of pod replicas. This field is a top-level attribute under the Deployment's `spec` object, and the ReplicaSet controller uses this integer value to ensure the specified number of Pods are running at all times.

Exam trap

The trap here is that candidates confuse the `spec.replicas` field with `spec.template` or `metadata`, or incorrectly assume that replica count is nested under `strategy` or `template`, leading them to pick A, B, or D.

How to eliminate wrong answers

Option A is wrong because `spec.strategy.replicas` does not exist; the `strategy` field defines the update strategy (e.g., RollingUpdate or Recreate), not replica count. Option B is wrong because `metadata.replicas` is not a valid field; `metadata` contains labels, annotations, and the resource name, not replica configuration. Option D is wrong because `spec.template.replicas` is invalid; the `template` field describes the Pod template (e.g., containers, volumes) and does not include a replicas field.

Full explanation →

537

MCQeasy

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

A.To manage Kubernetes secrets

B.To store source code and trigger builds

C.To run CI/CD pipelines

D.To host container images for deployment

AnswerD

A registry stores and versions container images, letting pipeline stages pull the exact artefact for deployment. This satisfies the stem's deployment need: the built image is pushed once, then retrieved by orchestrators, decoupling build output from runtime hosts.

Why this answer

A container registry is a centralized repository that stores and distributes container images, typically organized by repository and tagged by version. In a CI/CD pipeline, the build stage produces an image, pushes it to the registry, and the deployment stage pulls it from the registry onto the target runtime. Option D captures this hosting/distribution role precisely.

Exam trap

KCNA often tests whether candidates confuse the registry (stores images) with the CI server (runs pipelines) or the VCS (stores source), so options describing build triggering or pipeline execution look plausible.

How to eliminate wrong answers

Option A is wrong because Kubernetes secrets are managed by the Kubernetes API (Secret objects, often backed by etcd or an external secrets manager like Vault) — a container registry stores images, not cluster secrets. Option B is wrong because source code hosting and build triggering are the job of a version control system (GitHub, GitLab) and CI server (Jenkins, GitHub Actions), not a registry. Option C is wrong because running CI/CD pipelines is the function of a CI/CD orchestrator; a registry is a passive artifact store that pipelines push to and pull from.

Full explanation →

538

MCQhard

You have a Deployment with the following rollout strategy: rollingUpdate: maxSurge: 1, maxUnavailable: 0. What behavior does this configuration enforce?

A.The rollout will terminate all old pods at once and then create new ones

B.The rollout will create all new pods first, then delete all old pods

C.The rollout will terminate one old pod before creating a new one

D.The rollout will create one additional pod before terminating the old pod, ensuring zero downtime

AnswerD

maxSurge: 1 lets the Deployment add one pod above the desired count, while maxUnavailable: 0 forbids dropping below it. The controller therefore starts a new pod and waits for it to become Ready before terminating an old one, guaranteeing zero downtime.

Why this answer

The rolling update strategy `maxSurge: 1, maxUnavailable: 0` ensures that during the rollout, one additional pod is created above the desired replica count before any existing pod is terminated. This guarantees that the total number of available pods never drops below the desired count, achieving zero downtime. The `maxUnavailable: 0` setting prevents any pod from being taken down until a new one is ready, while `maxSurge: 1` allows one extra pod to be created temporarily.

Exam trap

The trap in this question is that candidates often mistakenly think 'maxSurge: 1, maxUnavailable: 0' allows one old pod to be terminated before a new one starts (like a 'one-by-one' strategy). In reality, 'maxUnavailable: 0' forces a new pod to be created and become ready before any existing pod is removed, ensuring zero downtime. This is Kubernetes-specific and differs from simpler rolling update strategies.

How to eliminate wrong answers

Option A is wrong because terminating all old pods at once would violate `maxUnavailable: 0`, which explicitly prohibits any pods from being unavailable during the update. Option B is wrong because creating all new pods first would exceed the `maxSurge: 1` limit, which only allows one extra pod above the desired count, not a full parallel creation. Option C is wrong because terminating one old pod before creating a new one would temporarily reduce the available pod count below the desired replicas, violating `maxUnavailable: 0`; the correct behavior is to create a new pod first (surge) before terminating the old one.

Full explanation →

539

MCQmedium

A platform team runs a Kubernetes cluster with the OpenTelemetry Collector deployed as a DaemonSet. They want to collect node-level metrics such as CPU and memory usage from every node without modifying application code. Which receiver should they configure in the Collector's pipeline?

A.otlp receiver

B.prometheus receiver

C.hostmetrics receiver

D.jaeger receiver

AnswerC

The hostmetrics receiver is designed to collect host-level metrics such as CPU, memory, disk, and network usage from the node where the Collector runs. Since the Collector is deployed as a DaemonSet, one instance runs on each node, allowing hostmetrics to gather node-level metrics without any application instrumentation or code changes, exactly matching the requirement.

Why this answer

The hostmetrics receiver is purpose-built for collecting host-level metrics such as CPU, memory, disk, and network usage. When the OpenTelemetry Collector is deployed as a DaemonSet, each node runs a Collector instance, so hostmetrics can gather metrics from every node without application changes. Other receivers either require additional exporters, handle different telemetry types, or do not actively scrape node metrics.

Exam trap

The trap here is assuming that any receiver can collect node metrics, when only hostmetrics is designed for that specific purpose.

Full explanation →

540

MCQeasy

A platform team runs a multi-tenant Kubernetes cluster for several product groups. They want each group's workloads to be logically isolated from one another, with separate quota limits and separate RBAC bindings, while still sharing the same cluster control plane and worker nodes. Which Kubernetes construct BEST provides this isolation boundary?

A.NetworkPolicy

B.Node affinity rule

C.Namespace

D.PodDisruptionBudget

AnswerC

A Namespace is the built-in Kubernetes mechanism for partitioning a single cluster into virtual sub-clusters. ResourceQuota and LimitRange objects are scoped to a namespace, and RoleBinding/ClusterRoleBinding subjects can be limited to a namespace, so each product group gets its own quota and permission boundary without provisioning a separate control plane. This directly matches the requirement of logical isolation with shared infrastructure.

Why this answer

Namespaces are the standard way to carve one Kubernetes cluster into logical partitions for multiple teams. They scope names for objects, act as the boundary for ResourceQuota and LimitRange, and are the natural target for RoleBinding subjects, so separate groups get separate quotas and permissions while sharing the control plane and nodes. The other constructs address scheduling, traffic filtering, or eviction behaviour rather than tenancy.

Exam trap

The trap here is assuming that a Namespace provides hard security isolation, when it is really an administrative and naming boundary that needs NetworkPolicy and RBAC layered on top.

Full explanation →

541

MCQmedium

In an event-driven architecture using a message broker, which component is responsible for receiving events and forwarding them to subscribed services?

A.Service mesh

B.Message broker

C.API gateway

D.Load balancer

AnswerB

A message broker receives published events and routes them to subscribed services, decoupling producers from consumers. This directly satisfies the stem's requirement for the component that accepts incoming events and forwards them onward, rather than generating, storing or processing them itself.

Why this answer

In event-driven architecture, the message broker (Kafka, RabbitMQ, NATS, Pulsar) is the intermediary that receives published events and routes them to subscribers based on topics, queues, or routing keys. It decouples producers from consumers, buffers events, and handles delivery semantics. Option B names this component directly.

Exam trap

KCNA often tests whether candidates confuse the message broker (asynchronous event routing) with the API gateway (synchronous API fronting) or service mesh (service-to-service networking), so all three look like 'traffic' components.

How to eliminate wrong answers

Option A is wrong because a service mesh (Istio, Linkerd) handles service-to-service networking concerns — mTLS, traffic shifting, retries, observability — at the sidecar/proxy layer, not event routing between producers and consumers. Option C is wrong because an API gateway (Kong, Apigee) fronts synchronous HTTP/REST/gRPC APIs, handling auth, rate limiting, and routing for request/response traffic, not asynchronous event distribution. Option D is wrong because a load balancer distributes incoming connections across backend instances; it does not implement publish/subscribe semantics, topic routing, or event persistence.

Full explanation →

542

MCQmedium

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

A.Secret

B.ServiceAccount

C.ConfigMap

D.PersistentVolume

AnswerC

A ConfigMap holds non-confidential key-value configuration data that Pods consume as environment variables, command-line arguments or mounted files. This satisfies the stem's requirement for storing non-sensitive configuration, distinguishing it from Secrets, which are intended for sensitive data such as credentials.

Why this answer

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

Exam trap

Kubernetes often tests the distinction between ConfigMap and Secret, trapping candidates who assume all configuration data must be stored in Secrets, ignoring that ConfigMap is the correct choice for non-sensitive data.

How to eliminate wrong answers

Option A is wrong because Secret is specifically designed to store sensitive data (e.g., passwords, tokens, SSH keys) and is base64-encoded, not plaintext, making it unsuitable for non-sensitive configuration. Option B is wrong because ServiceAccount is an identity object used to control pod-level authentication to the Kubernetes API, not for storing configuration data. Option D is wrong because PersistentVolume is a storage resource that provides persistent storage volumes to pods, not a mechanism for injecting configuration data like key-value pairs or files.

Full explanation →

543

MCQmedium

A team uses a Deployment with 3 replicas and a RollingUpdate strategy. They update the container image. During the update, one of the new pods fails to start. What will happen by default?

A.The update pauses, keeping the remaining old replicas running

B.The entire update is rolled back and all old pods are deleted

C.The Deployment automatically rolls back to the previous image

D.The failed pod is terminated and not retried

AnswerA

The rolling update stops when a new pod fails, ensuring availability of old pods.

Why this answer

By default, a Deployment with a RollingUpdate strategy uses a `maxUnavailable` of 25% and a `maxSurge` of 25%. When a new pod fails to start (e.g., CrashLoopBackOff or ImagePullBackOff), the ReplicaSet controller will not create additional new pods beyond the surge limit, and the update will effectively pause because the new ReplicaSet cannot reach its desired replica count. The old ReplicaSet remains running with its existing pods, ensuring availability is maintained.

Exam trap

The KCNA exam often tests the misconception that a failed pod in a rolling update triggers an automatic rollback or deletion, when in fact the default behavior is to pause the update and keep old replicas running until the issue is resolved manually.

How to eliminate wrong answers

Option B is wrong because the Deployment does not automatically roll back or delete old pods; it only pauses the rollout, leaving old replicas running. Option C is wrong because a failed pod does not trigger an automatic rollback to the previous image; rollback requires manual intervention or a specific `kubectl rollout undo` command. Option D is wrong because the failed pod is not simply terminated and not retried; the ReplicaSet controller will retry creating the pod indefinitely (with exponential backoff) until the image issue is resolved or the rollout is manually paused.

Full explanation →

544

MCQmedium

A user runs 'kubectl get pods -n default' but receives an error: 'Error from server (Forbidden): pods is forbidden: User cannot list resource pods in API group'. What is the most likely cause?

A.The pod does not exist in the namespace

B.The user's kubeconfig file is corrupted

C.The user lacks RBAC permissions to list pods

D.The API server is down

AnswerC

The Forbidden error names the user and the verb 'list' on pods, which is exactly what RBAC authorises. Authentication succeeded, so the cause is a missing Role or ClusterRole binding granting list on pods in the default namespace.

Why this answer

The error message 'Error from server (Forbidden): pods is forbidden: User cannot list resource pods in API group' directly indicates that the Kubernetes RBAC (Role-Based Access Control) system has denied the request. The user's current context in their kubeconfig does not have a Role or ClusterRole binding that grants the 'list' verb on 'pods' in the 'v1' API group (core group). This is a standard authorization failure, not a connectivity or resource existence issue.

Exam trap

The trap here is that candidates confuse a missing resource (NotFound) with a permissions error (Forbidden), or assume the API server is down when the error is actually a structured RBAC denial. The CNCF exam often tests the distinction between authentication failures (401 Unauthorized) and authorization failures (403 Forbidden).

How to eliminate wrong answers

Option A is wrong because if the pod did not exist in the namespace, the error would be 'Error from server (NotFound): pods not found', not a Forbidden error. Option B is wrong because a corrupted kubeconfig file would typically produce errors like 'invalid configuration' or 'unable to read client-cert', not a structured Forbidden response from the API server. Option D is wrong because if the API server were down, the user would receive a connection refused or timeout error, not a structured HTTP 403 Forbidden response with RBAC details.

Full explanation →

545

MCQmedium

A Kubernetes Deployment manages a set of pods. What is the primary purpose of a Deployment?

A.To declare the desired state for a set of pods and manage rolling updates

B.To store configuration data as key-value pairs

C.To run a batch job to completion

D.To expose a set of pods as a network service

AnswerA

A Deployment declares the desired state for its ReplicaSet and pods, then the controller reconciles actual state towards it, enabling declarative scaling and rolling updates with rollback. This satisfies the stem's need to manage a set of pods and update them without downtime.

Why this answer

A Kubernetes Deployment declares the desired state for a set of pods and manages rolling updates and rollbacks. It ensures that the specified number of pod replicas are running and provides declarative updates to the application, which is its primary purpose.

Exam trap

The trap is confusing a Deployment with other Kubernetes objects like ConfigMaps, Jobs, or Services; candidates must remember that a Deployment is specifically for managing the desired state and updates of pods, not for configuration, batch processing, or networking.

How to eliminate wrong answers

Option B is wrong because storing configuration data as key-value pairs is the purpose of a ConfigMap, not a Deployment. Option C is wrong because running a batch job to completion is the purpose of a Job or CronJob, not a Deployment. Option D is wrong because exposing a set of pods as a network service is the purpose of a Service, not a Deployment.

Full explanation →

546

Multi-Selectmedium

Which THREE of the following are core principles of immutable infrastructure? (Choose 3)

Select 3 answers

A.Rollbacks are performed by redeploying a previous image

B.Infrastructure is patched by applying updates to running servers

C.Infrastructure components are never modified after deployment

D.Deployments are reproducible and consistent

E.All changes are made by updating configuration files on running instances

AnswersA, C, D

Because servers are never patched in place, reverting means destroying the current instances and launching fresh ones from the previously validated image. This satisfies the stem's rollback principle: recovery is a redeployment of an artefact, not an in-place repair of running infrastructure.

Why this answer

Option A is correct because in immutable infrastructure you never repair a running instance; to roll back you simply redeploy the previously built and validated image (e.g., a prior AMI, container image tag, or VM template), which restores the known-good state deterministically. Option C is correct because the defining rule of immutability is that once an instance or component is deployed it is never modified in place — no SSH patching, no config edits — so any change requires replacing it with a new artifact. Option D is correct because immutable patterns rely on versioned, codified artifacts (e.g., Packer-built images, IaC templates, container registries) so that the same build produces identical, reproducible deployments across environments.

Option B is not correct because patching running servers is the mutable, in-place model that immutable infrastructure explicitly rejects. Option E is not correct because editing configuration files on running instances is also an in-place mutation, whereas immutable practice bakes configuration into a new image and redeploys it.

Exam trap

KCNA often tests the misconception that 'updating config files on running servers' or 'patching in place' is compatible with immutability — candidates must recognize that any in-place modification violates the principle.

Full explanation →

547

MCQmedium

A cluster administrator examines a node and notices that the kubelet is running, but the node's status shows 'NotReady'. The administrator runs 'systemctl status containerd' on the node and finds the service is inactive. Which component's failure most directly explains the node's 'NotReady' condition?

A.containerd

B.CoreDNS

C.kube-apiserver

D.kube-proxy

AnswerA

The container runtime (containerd) is required by kubelet to create and run pod sandboxes. When containerd is inactive, kubelet cannot start containers, and its node status condition becomes NotReady because the runtime is unreachable. Restarting containerd typically restores the node to Ready.

Why this answer

The kubelet relies on a container runtime to manage pod sandboxes and containers. When containerd is inactive, kubelet cannot perform its core duties, and the node's Ready condition becomes false. Other components like kube-proxy or CoreDNS may affect networking or DNS, but they do not determine node readiness.

Exam trap

The trap here is assuming that any control plane or networking component failure causes NotReady, when the node's readiness is primarily gated by kubelet and the container runtime.

Full explanation →

548

MCQhard

A ClusterIP Service named 'db-service' in namespace 'prod' selects pods with label 'app: database'. A pod in the same cluster needs to reach this service using DNS. What is the fully qualified domain name (FQDN) for the service?

A.db-service.cluster.local

B.db-service.prod.svc.cluster.local

C.db-service.svc.cluster.local

D.db-service.prod.cluster.local

AnswerB

Kubernetes DNS resolves ClusterIP Services as `<service>.<namespace>.svc.cluster.local`, so `db-service.prod.svc.cluster.local` satisfies the stem's same-cluster requirement, combining the service name with its `prod` namespace. The `svc` segment denotes the Service record type, and `cluster.local` is the default cluster domain suffix.

Why this answer

The correct FQDN for a Kubernetes Service follows the pattern <service-name>.<namespace>.svc.cluster.local. Since the 'db-service' ClusterIP Service is in the 'prod' namespace, the FQDN is 'db-service.prod.svc.cluster.local'. This allows any pod in the cluster to resolve the service's cluster IP via DNS, using the cluster domain 'cluster.local' by default.

Exam trap

The trap here is that candidates often forget the 'svc' subdomain or the namespace component, leading them to pick options like 'db-service.cluster.local' or 'db-service.svc.cluster.local', which are only valid for services in the default namespace or are incomplete.

How to eliminate wrong answers

Option A is wrong because it omits the namespace and the 'svc' subdomain, resulting in 'db-service.cluster.local', which is not a valid Kubernetes service DNS name. Option C is wrong because it includes 'svc' but omits the namespace 'prod', leading to 'db-service.svc.cluster.local', which would only work if the service were in the 'default' namespace. Option D is wrong because it uses 'prod.cluster.local' instead of 'prod.svc.cluster.local', missing the mandatory 'svc' component that distinguishes service DNS records from pod DNS records.

Full explanation →

549

MCQmedium

Which of the following is a benefit of using a service mesh?

A.Simplified storage management

B.Automatic scaling of applications

C.Enhanced observability and traffic control

D.Direct database access

AnswerC

A service mesh provides mutual TLS, traffic routing and telemetry at the sidecar proxy layer, giving consistent observability and fine-grained traffic control across services without changing application code. That combination of visibility and control is the benefit the question asks for.

Why this answer

A service mesh (Istio, Linkerd, Consul Connect) injects sidecar proxies alongside application pods to intercept all service-to-service traffic, providing uniform mTLS, traffic shifting, retries, circuit breaking, and rich telemetry (latency, error rates, request tracing) without application code changes. Option C correctly identifies the two headline benefits: enhanced observability and traffic control. These capabilities are delivered at the infrastructure layer, transparently to the application.

Exam trap

KCNA often tests whether candidates attribute application-level concerns (scaling, storage, database access) to the service mesh, so options like 'automatic scaling' look plausible because the mesh does expose metrics that *feed* autoscalers.

How to eliminate wrong answers

Option A is wrong because storage management is handled by Kubernetes storage primitives (PersistentVolumes, StorageClasses, CSI drivers) or dedicated storage solutions — a service mesh does not manage storage. Option B is wrong because automatic scaling is the job of the Horizontal Pod Autoscaler, Vertical Pod Autoscaler, or KEDA — a service mesh can inform scaling decisions via metrics but does not itself scale workloads. Option D is wrong because direct database access is an application/data-layer concern; a service mesh operates at the network layer between services and does not provide database connectivity.

Full explanation →

550

Multi-Selecthard

Which TWO of the following are valid ways to expose a Service to external traffic?

Select 2 answers

A.ExternalName

B.Headless

C.LoadBalancer

D.NodePort

E.ClusterIP

AnswersC, D

A LoadBalancer Service provisions an external cloud load balancer that routes inbound traffic to the backing pods. This exposes the Service beyond the cluster, unlike ClusterIP, which remains reachable only internally within the cluster network.

Why this answer

NodePort (D) is correct because it exposes a Service on each cluster node's IP at a static port in the 30000–32767 range, allowing external clients to reach the Service via <NodeIP>:<NodePort>. LoadBalancer (C) is correct because it builds on NodePort and provisions an external load balancer (e.g., via a cloud provider) that routes external traffic to the Service's endpoints. ExternalName (A) is not a way to expose a Service to external traffic; it simply returns a CNAME DNS record pointing to an external hostname without proxying traffic.

Headless (B) sets clusterIP: None and returns pod IPs directly via DNS, which is used for direct pod discovery, not external exposure. ClusterIP (E) is the default internal-only Service type, reachable only from within the cluster, so it does not expose the Service externally.

Exam trap

A common pitfall is assuming ExternalName or Headless Services provide external exposure. ExternalName only provides an internal DNS alias, while Headless is for internal pod discovery. Only NodePort and LoadBalancer directly expose the Service externally.

Full explanation →

551

MCQmedium

A developer wants to expose a set of pods running a web application on a stable IP address. Which Kubernetes resource should they create?

A.Service

B.ConfigMap

C.Ingress

D.NetworkPolicy

AnswerA

A Service provides a stable virtual IP and DNS name that fronts a dynamically changing set of pod endpoints, selected by labels. Pods themselves are ephemeral, so the Service abstraction delivers the persistent address the web application requires.

Why this answer

A Service in Kubernetes provides a stable IP address and DNS name to expose a set of pods, abstracting away pod IP changes due to scaling or restarts. It acts as a load balancer across the pods, typically using ClusterIP (default), NodePort, or LoadBalancer types. This directly meets the requirement of exposing pods on a stable IP.

Exam trap

The CNCF exam often tests the distinction between Ingress and Service, where candidates mistakenly choose Ingress for stable IP exposure, but Ingress only provides host/path-based routing and requires a Service to actually reach pods.

How to eliminate wrong answers

Option B (ConfigMap) is wrong because it is used to store configuration data as key-value pairs, not to provide network access or a stable IP to pods. Option C (Ingress) is wrong because it manages external HTTP/HTTPS routing to Services, not a stable IP for pods; it requires a Service to function and does not itself assign an IP. Option D (NetworkPolicy) is wrong because it defines firewall rules for pod-to-pod traffic, not exposure or stable IP assignment.

Full explanation →

552

MCQeasy

Which of the following is a key benefit of using containers over virtual machines?

A.Each container runs its own operating system

B.Containers provide stronger isolation than VMs

C.Containers require hypervisor to run

D.Containers share the host OS kernel

AnswerD

Containers share the host's kernel and isolate only user space via namespaces and cgroups, so they carry no guest OS. Virtual machines each run a full kernel, making containers far lighter to start and denser to pack.

Why this answer

Containers share the host operating system kernel, which makes them lightweight and fast to start compared to virtual machines. Each container runs as an isolated user-space process on the same kernel, avoiding the overhead of a separate guest OS per instance. This shared-kernel architecture is a fundamental design principle of containerization technologies like Docker and containerd.

Exam trap

The trap here is that candidates often confuse the lightweight nature of containers with stronger isolation, but the key trade-off is that containers share the host kernel, making them less isolated than VMs, not more.

How to eliminate wrong answers

Option A is wrong because each container does not run its own operating system; containers share the host OS kernel and only include the application and its dependencies. Option B is wrong because containers provide weaker isolation than VMs, as they share the host kernel and rely on kernel namespaces and cgroups, whereas VMs use a hypervisor to provide hardware-level isolation. Option C is wrong because containers do not require a hypervisor to run; they run directly on the host OS using the kernel's container runtime, while VMs require a hypervisor.

Full explanation →

553

MCQeasy

A platform engineer needs to run a one-time batch job that processes a dataset and then exits. The job must run exactly once and not be restarted if it completes successfully. Which Kubernetes resource should be used?

A.DaemonSet

B.CronJob

C.Deployment

D.Job

AnswerD

A Job creates one or more Pods and ensures that a specified number of them successfully terminate. It is designed for run-to-completion workloads. By default, it does not restart Pods after successful completion, making it ideal for a one-time batch process that must finish and exit.

Why this answer

A Job is the correct resource for run-to-completion workloads. It creates Pods that are expected to terminate successfully, and it does not restart them after successful completion. Deployments, CronJobs, and DaemonSets are designed for different use cases: long-running services, scheduled tasks, and node-level agents, respectively.

Exam trap

The trap here is confusing a Job with a CronJob; a CronJob is for scheduled recurring tasks, not a single immediate execution.

Full explanation →

554

Multi-Selectmedium

Which TWO statements about Kubernetes namespaces are true?

Select 2 answers

A.All Kubernetes objects are namespaced.

B.Namespaces automatically isolate services in different namespaces from communicating.

C.Namespaces provide network isolation between pods by default.

D.Namespaces are used to divide cluster resources between multiple users or teams.

E.Resource quotas can be applied to a namespace to limit aggregate resource consumption.

AnswersD, E

Correct; namespaces provide logical isolation.

Why this answer

Namespaces are a fundamental mechanism in Kubernetes for dividing cluster resources among multiple users or teams, enabling multi-tenancy and resource management through policies like Role-Based Access Control (RBAC) and ResourceQuotas. Option E is correct because ResourceQuotas are Kubernetes objects that can be applied to a namespace to enforce aggregate limits on CPU, memory, and other resources, preventing any single team from exhausting cluster capacity.

Exam trap

The trap here is that candidates confuse namespaces with network isolation, assuming that simply placing resources in different namespaces automatically blocks cross-namespace traffic, when in fact Kubernetes allows all pod-to-pod communication across namespaces by default and requires explicit NetworkPolicy rules to restrict it.

Full explanation →

555

MCQmedium

According to the 12-factor app methodology, how should an application store configuration that varies between deployments (e.g., database connection strings)?

A.In a configuration file that is version-controlled

B.In a database table

C.In environment variables

D.Hard-coded in the application code

AnswerC

Storing configuration in environment variables satisfies the 12-factor requirement to strictly separate config from code, since values vary per deployment without code changes. Environment variables are language- and OS-agnostic, avoid committing credentials to version control, and allow the same build artefact to be promoted unchanged across environments.

Why this answer

The 12-factor app recommends strict separation of config from code, storing config in environment variables.

Full explanation →

556

MCQmedium

A developer wants to run a stateless web application with 5 replicas and ensure that when a new version is released, Pods are updated one by one with no downtime. Which Kubernetes resource is best suited?

A.Job

B.DaemonSet

C.StatefulSet

D.Deployment

AnswerD

Deployment manages stateless workloads through ReplicaSets, supporting rolling updates that replace Pods incrementally rather than all at once. This satisfies the zero-downtime requirement: the rollout proceeds one Pod at a time while remaining replicas keep serving traffic, and it maintains the desired count of five throughout.

Why this answer

A Deployment is the correct resource because it is designed for managing stateless, replicated applications with declarative updates. It supports rolling updates (configurable via `strategy.type: RollingUpdate`), which update Pods one by one, ensuring zero downtime by gradually replacing old Pods with new ones while maintaining the desired replica count.

Exam trap

The trap here is that candidates may confuse StatefulSet with Deployment because both support rolling updates, but StatefulSet is specifically for stateful workloads requiring ordered Pod identity and persistent storage, not for stateless web apps where Pods are ephemeral and interchangeable.

How to eliminate wrong answers

Option A is wrong because a Job is used for running batch or one-off tasks to completion, not for continuously running stateless web applications or managing rolling updates. Option B is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes), which is intended for node-level services like logging or monitoring, not for scaling a stateless web app with a fixed replica count. Option C is wrong because a StatefulSet is designed for stateful applications that require stable, unique network identities and persistent storage (e.g., databases), and its rolling update behavior is more conservative (e.g., ordered, graceful shutdown) but it is not the best fit for a stateless web app where Pods are interchangeable.

Full explanation →

557

MCQmedium

Which CNCF project is at the 'Graduated' maturity level and is widely used for container orchestration?

A.Kubernetes

B.Prometheus

C.Envoy

D.Helm

AnswerA

Kubernetes is the CNCF's flagship Graduated project, having reached that maturity level in 2018. It satisfies the container orchestration constraint directly: it schedules, deploys and scales containers across clusters. No other CNCF project combines Graduated status with orchestration at this scale of adoption.

Why this answer

Kubernetes is the correct answer because it is the CNCF Graduated project specifically designed and widely adopted for container orchestration. It automates deployment, scaling, and management of containerized applications, making it the de facto standard in cloud-native environments. Note that Prometheus, Envoy, and Helm are also CNCF Graduated projects, but they serve different functions (monitoring, service proxy/networking, and package management respectively), not container orchestration.

Exam trap

CNCF often tests the distinction between a project's maturity level and its function. The trap here is that candidates may assume any popular CNCF project (like Prometheus or Envoy) is used for orchestration, when in fact Kubernetes is the project that fulfills that specific role. Remember that maturity level (Graduated) and function (orchestration) are separate attributes.

How to eliminate wrong answers

Option B (Prometheus) is wrong because, although it is a Graduated CNCF project, it is a monitoring and alerting toolkit, not a container orchestration platform. Option C (Envoy) is wrong because it is a Graduated CNCF project but functions as a high-performance proxy and service mesh data plane, not an orchestrator. Option D (Helm) is wrong because it is a package manager for Kubernetes (Incubating maturity level), not a container orchestration tool itself.

Full explanation →

558

Multi-Selecteasy

Which TWO of the following are characteristics of a Kubernetes Pod?

Select 2 answers

A.Pods can only run a single container

B.Pods are the smallest deployable units in Kubernetes

C.Containers within a Pod share the same network namespace

D.Pods are designed to be long-lived and rarely replaced

E.Pods are typically replicated by a Deployment or ReplicaSet

AnswersB, C

A Pod groups one or more containers sharing a network namespace and storage volumes, and is the atomic unit Kubernetes schedules and deploys. This satisfies the stem's requirement for a Pod characteristic: it is the smallest deployable unit.

Why this answer

Option B is correct because the Pod is the smallest and most basic deployable object in Kubernetes — you cannot deploy a container directly; it must be wrapped in a Pod, which represents a single instance of a running process in the cluster. Option C is correct because all containers in a Pod share the same network namespace, meaning they share one IP address and port space and can communicate with each other via localhost, and they can also share storage volumes. Option A is incorrect because a Pod can run one or multiple containers (e.g., sidecar, ambassador, or adapter patterns), not only a single container.

Option D is incorrect because Pods are ephemeral by design — they are not intended to be long-lived; they are created, terminated, and replaced rather than repaired in place. Option E is incorrect as a defining characteristic of a Pod itself: replication is performed by higher-level controllers such as Deployments or ReplicaSets, which manage Pods but are not properties of the Pod object.

Exam trap

CNCF often tests the misconception that Pods are long-lived or that they can only run a single container, confusing Pods with virtual machines or containers themselves, while the key exam point is that Pods are the smallest deployable unit and share network namespaces.

Full explanation →

559

Matchingmedium

Match each Kubernetes command (kubectl) to its primary function.

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

Concepts

Matches

List one or more resources

Show detailed state of a resource

Create or update resources from a file or stdin

Execute a command inside a container

Print logs from a container in a pod

Why these pairings

The correct matches are: kubectl get for listing resources, kubectl describe for detailed info, and kubectl apply for applying configurations. Common confusions include swapping the functions of kubectl delete and kubectl logs.

Full explanation →

560

MCQeasy

A developer wants to run a one-time batch job that processes a dataset and then exits. The job must complete successfully and not be restarted after completion. Which Kubernetes resource should be used?

A.Deployment

B.StatefulSet

C.Job

D.CronJob

AnswerC

A Job creates one or more pods and ensures that a specified number of them successfully terminate. It is designed for batch processing, where the workload runs to completion and then stops. Once the pods complete successfully, the Job is considered finished, and no further pods are created. This matches the requirement for a one-time batch job that exits after processing.

Why this answer

Job is the correct resource for batch workloads that run to completion. It ensures that a specified number of pods finish successfully and then stops creating new ones. CronJob is for scheduled recurring tasks, while Deployment and StatefulSet are for long-running services that restart on exit.

Thus, Job best fits the one-time batch processing requirement.

Exam trap

The trap here is confusing Job with CronJob, or assuming that any controller can handle run-to-completion workloads.

Full explanation →

561

Multi-Selecthard

Which TWO of the following are true about service discovery in Kubernetes? (Choose 2)

Select 2 answers

A.Ingress resources can be used for internal service discovery

B.Service discovery is only available for pods on the same node

C.Environment variables are injected into pods for each Service

D.Services are assigned a DNS name in the form <service>.<namespace>.svc.cluster.local

E.Headless Services provide a stable virtual IP for service discovery

AnswersC, D

The kubelet injects environment variables for each active Service into newly created pods, exposing host and port values such as <SVCNAME>_SERVICE_HOST. This satisfies service discovery without DNS, though variables only reflect Services existing at pod creation time.

Why this answer

Option C is correct because Kubernetes injects environment variables (such as <SERVICE_NAME>_SERVICE_HOST and <SERVICE_NAME>_SERVICE_PORT) into every pod for each Service that exists at the time the pod is created, providing one built-in discovery mechanism. Option D is correct because CoreDNS (the cluster DNS add-on) assigns each Service a fully qualified domain name of the form <service>.<namespace>.svc.cluster.local, which pods resolve to reach the Service's ClusterIP. Option A is not correct because Ingress resources handle external HTTP/HTTPS routing into the cluster, not internal service discovery.

Option B is not correct because Service discovery works cluster-wide across all nodes, not just for pods on the same node. Option E is not correct because a headless Service (clusterIP: None) deliberately has no virtual IP; it returns individual pod IPs via DNS records instead of a stable ClusterIP.

Exam trap

The trap is confusing Ingress (external HTTP routing) with internal service discovery, and misremembering headless Services as providing a virtual IP when they actually return pod IPs directly.

Full explanation →

562

MCQhard

A team wants to deploy a stateful application that requires each pod to have a unique, stable network identity and persistent storage that persists across rescheduling. Which Kubernetes resource is most appropriate?

A.DaemonSet

B.Deployment

C.StatefulSet

D.Job

AnswerC

StatefulSet assigns each pod a stable ordinal hostname and its own PersistentVolumeClaim via volumeClaimTemplates, so identity and storage survive rescheduling. Deployments give pods random names and share or recreate storage, failing the stable-identity and persistence constraints the stem requires.

Why this answer

StatefulSet is the correct choice because it provides each pod with a unique, stable network identity (via a predictable hostname derived from the StatefulSet name and ordinal index) and dedicated persistent storage that persists across rescheduling. This is achieved through a headless Service and PersistentVolumeClaims (PVCs) that are bound to each pod's identity, ensuring that when a pod is rescheduled, it reattaches to the same storage and retains its network identity.

Exam trap

A common mistake is to think that a Deployment can be used for stateful workloads because it supports PersistentVolumeClaims. However, Deployment does not guarantee stable pod identities or ordered pod creation/termination, which are essential for stateful applications like databases.

How to eliminate wrong answers

Option A (DaemonSet) is wrong because it ensures one pod per node, not unique stable identities or persistent storage per pod; it is designed for node-level services like logging agents. Option B (Deployment) is wrong because it creates pods with random, ephemeral hostnames and does not guarantee stable network identities or persistent storage; it is intended for stateless applications where pods are interchangeable. Option D (Job) is wrong because it runs a finite task to completion and does not provide persistent storage or stable network identities; it is used for batch processing, not long-running stateful applications.

Full explanation →

563

MCQmedium

You run 'kubectl get pods' and see a pod with status 'Pending'. Which is the most likely cause?

A.The pod's container has crashed

B.The scheduler cannot find a node that meets the pod's resource requirements

C.The container image is not found

D.The pod has been deleted by a controller

AnswerB

A Pending status means the pod has been accepted by the API server but no node has been bound to it. The kube-scheduler assigns pods to nodes, and when no node satisfies the pod's CPU, memory, or affinity constraints, it remains unscheduled and reports Pending.

Why this answer

A pod with status 'Pending' indicates that the pod has been accepted by the cluster but is not yet running. The most common cause is that the Kubernetes scheduler cannot find a node that satisfies the pod's resource requests (CPU, memory) or other constraints (node selector, taints/tolerations, affinity rules). The scheduler continuously evaluates nodes and if none match, the pod remains in Pending state until a suitable node becomes available.

Exam trap

The CNCF's KCNA exam often tests the distinction between pod lifecycle phases (Pending, Running, Succeeded, Failed, Unknown) and common error states (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly associate 'Pending' with image or runtime issues rather than scheduling failures.

How to eliminate wrong answers

Option A is wrong because a container crash would result in a 'CrashLoopBackOff' or 'Error' status, not 'Pending'. Option C is wrong because an unfound container image would cause an 'ImagePullBackOff' or 'ErrImagePull' status, not 'Pending'. Option D is wrong because if a pod is deleted by a controller, it would simply disappear from the list; 'Pending' is a lifecycle phase before the pod is scheduled, not a deletion state.

Full explanation →

564

MCQhard

Which of the following correctly describes the concept of 'immutable infrastructure' in the context of container orchestration?

A.Infrastructure components are recreated from a known good state rather than modified

B.Configuration changes are applied via SSH into running containers

C.Servers are never rebooted

D.Container images are updated in-place by patching existing layers

AnswerA

Immutable infrastructure replaces servers and containers wholesale from a versioned image rather than patching running instances. In orchestration, this means pods are destroyed and rescheduled from a known good artefact, so configuration drift cannot accumulate and rollbacks are simply redeployments.

Why this answer

Immutable infrastructure means that instead of modifying running servers or containers, you replace them entirely with new instances built from a known good image. In container orchestration, this is achieved by building a new container image, deploying it as a new pod/replica set, and tearing down the old ones. This eliminates configuration drift and makes rollbacks deterministic.

Exam trap

The trap is confusing immutability with 'never changing' or 'never rebooting' — candidates may pick option C because they think immutable means static, but the correct definition is about replacement rather than in-place modification.

How to eliminate wrong answers

Option B is wrong because SSHing into running containers to apply configuration changes is the opposite of immutable infrastructure — it introduces mutable state and drift. Option C is wrong because immutability does not mean servers are never rebooted; reboots can happen as part of replacement, but the key is that the instance is recreated, not patched in place. Option D is wrong because updating container images in-place by patching existing layers is not how container images work — layers are immutable by design, and any change requires building a new image.

Full explanation →

565

MCQhard

A cluster administrator wants to ensure that a specific pod only runs on nodes that have an SSD for local storage. The nodes with SSDs have the label 'disk-type: ssd'. How should the administrator configure the pod to enforce this constraint?

A.Add a toleration for node.kubernetes.io/disk-type: ssd

B.Add a nodeSelector with 'disk-type: ssd' to the pod spec

C.Use a readiness probe to check for SSD

D.Add an annotation 'disk-type: ssd' to the pod

AnswerB

A nodeSelector with `disk-type: ssd` in the pod spec makes the scheduler place the pod only on nodes carrying that exact label, directly satisfying the SSD constraint. Unlike taints, tolerations or affinity, nodeSelector is a hard requirement evaluated at scheduling time, so pods stay Pending rather than landing on non-SSD nodes.

Why this answer

The `nodeSelector` field in a Pod spec is the standard Kubernetes mechanism for constraining a Pod to run only on nodes that match specific labels. By setting `nodeSelector: { disk-type: ssd }`, the scheduler will ensure the Pod is placed exclusively on nodes with that label, enforcing the administrator's requirement.

Exam trap

The trap here is that candidates confuse tolerations (for taints) with node selectors (for labels), or think annotations or probes can influence scheduling, when only `nodeSelector` or node affinity directly control node placement based on labels.

How to eliminate wrong answers

Option A is wrong because tolerations are used to allow Pods to run on nodes with taints, not to select nodes based on labels; a toleration for `node.kubernetes.io/disk-type: ssd` would be meaningless as this is not a well-known taint key. Option C is wrong because a readiness probe checks whether a container is ready to serve traffic, not the hardware characteristics of the node; it cannot enforce node selection. Option D is wrong because annotations are metadata for non-identifying information and are not used by the scheduler for node placement decisions.

Full explanation →

566

MCQeasy

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

A.To distribute traffic across multiple instances

B.To stop cascading failures by preventing calls to a failing service

C.To encrypt communication between services

D.To automatically retry failed requests

AnswerB

A circuit breaker monitors calls to a dependency; once failures cross a threshold it trips open, returning errors immediately instead of queuing requests. This halts the propagation of failures through call chains, preventing one failing service from exhausting threads and cascading across the microservice estate.

Why this answer

The circuit breaker pattern wraps calls to a remote service and monitors for failures. When failures exceed a threshold, the breaker 'opens' and subsequent calls fail fast (or return a fallback) instead of being attempted, preventing a single failing dependency from exhausting threads/connections and cascading failures across the microservice graph. This is the core purpose: fault isolation and preventing cascading failures.

Exam trap

KCNA often tests the confusion between resilience patterns — candidates pick 'retry' or 'load balancing' because those also sound like ways to handle failures, but the circuit breaker's defining trait is stopping calls to a failing service to prevent cascading failure.

How to eliminate wrong answers

Option A is wrong because distributing traffic across instances is load balancing (e.g., via a load balancer or client-side LB), not circuit breaking. Option C is wrong because encrypting inter-service communication is handled by TLS/mTLS, not by a circuit breaker. Option D is wrong because automatic retries are a separate resilience pattern (retry with backoff); in fact, retries can worsen cascading failures, which is why circuit breakers are often paired with them.

Full explanation →

567

MCQmedium

A developer wants to run a batch job that processes a large dataset. The job should run to completion, and if the Pod fails, it should be retried up to 4 times before being marked as failed. Which Kubernetes resource and configuration should be used?

A.A Deployment with replicas set to 5 and restartPolicy set to Always

B.A CronJob with schedule set to a future time and backoffLimit set to 4

C.A Pod with restartPolicy set to Never and no controller

D.A Job with backoffLimit set to 4 and restartPolicy set to OnFailure

AnswerD

A Job is designed for run-to-completion workloads. Setting backoffLimit to 4 allows up to 4 retries after a failure, and restartPolicy: OnFailure ensures the container is restarted within the same Pod on failure. This combination meets the requirement of retrying up to 4 times. The Job controller will mark the Job as failed after the backoffLimit is exceeded.

Why this answer

The requirement is a run-to-completion workload with limited retries. A Job is the correct resource, and backoffLimit specifies the number of retries before marking the Job as failed. Setting restartPolicy to OnFailure allows the container to restart within the Pod on failure, which is necessary for retries to occur.

Deployments and bare Pods do not provide completion semantics, and CronJobs are for scheduled tasks, not immediate one-time jobs.

Exam trap

The trap here is confusing the retry behavior of a Job with that of a Deployment; Deployments restart containers indefinitely and never complete, so they cannot satisfy a batch job requirement.

Full explanation →

568

MCQeasy

A developer needs to store non-confidential configuration data, such as a database hostname and port, that can be consumed by multiple Pods in a namespace. The data should be decoupled from the Pod specification to allow updates without rebuilding images. Which Kubernetes resource is designed for this purpose?

A.ConfigMap

B.ServiceAccount

C.PersistentVolumeClaim

D.Secret

AnswerA

A ConfigMap is specifically designed to hold non-confidential configuration data as key-value pairs. It can be consumed by Pods via environment variables, command-line arguments, or volume mounts. This decouples configuration from the Pod spec, allowing updates without image changes.

Why this answer

ConfigMaps are the standard Kubernetes resource for storing non-confidential configuration data. They allow you to separate configuration from container images, making applications more portable and easier to manage. Pods can reference ConfigMaps as environment variables, command-line arguments, or files in a volume.

This enables dynamic updates to configuration without redeploying Pods, depending on how the ConfigMap is consumed.

Exam trap

The trap here is assuming that Secrets should be used for any configuration data, but Secrets are meant for sensitive information, not general configuration.

Full explanation →

569

Multi-Selecthard

Which THREE of the following practices are essential for a secure cloud native CI/CD pipeline?

Select 3 answers

A.Sign container images and verify signatures during deployment

B.Store secrets in plain text in the pipeline configuration

C.Use a single long-lived service account for all pipeline steps

D.Scan container images for vulnerabilities before deployment

E.Apply least-privilege IAM roles to pipeline components

AnswersA, D, E

Signing images at build time and verifying signatures at admission ensures only artefacts produced by trusted pipeline identities reach the cluster, blocking tampered or substituted images. This satisfies the supply-chain integrity requirement of a secure cloud-native CI/CD pipeline.

Why this answer

Option A is correct because signing container images (e.g., with Sigstore Cosign or Docker Content Trust/Notary) and verifying those signatures at deploy time ensures only trusted, untampered artifacts are admitted, protecting against supply-chain tampering. Option D is correct because scanning images for known CVEs (e.g., with Trivy, Grype, or Clair) before deployment catches vulnerable base images and dependencies early, preventing exploitable workloads from reaching production. Option E is correct because applying least-privilege IAM roles to pipeline components limits the blast radius if a build step or runner is compromised, granting each stage only the permissions it needs.

Option B is wrong because storing secrets in plain text in pipeline configuration exposes credentials to anyone with repo or log access; secrets should be kept in a managed vault or secret store and injected at runtime. Option C is wrong because a single long-lived service account shared across all pipeline steps violates least privilege and separation of duties, and long-lived credentials increase the risk and impact of credential theft.

Exam trap

CNCF often tests the misconception that storing secrets in plain text is acceptable if the pipeline is 'internal' or 'trusted,' but the KCNA exam emphasizes that secrets must never be stored in plain text in any CI/CD configuration.

Full explanation →

570

Multi-Selectmedium

Which TWO of the following are core principles of the 12-factor app? (Choose 2.)

Select 2 answers

A.Shared state

B.Manual deployment

C.Dependencies

D.Singleton processes

E.Config

AnswersC, E

The dependencies principle requires applications to explicitly declare and isolate dependencies via a manifest, so nothing is assumed present on the host. This satisfies the stem's requirement for a core 12-factor principle, enabling reproducible builds across environments.

Why this answer

Option C (Dependencies) is correct because the 12-factor app's Dependencies principle requires applications to explicitly declare and isolate all dependencies via a dependency declaration manifest (e.g., requirements.txt, Gemfile, package.json) and a dependency isolation tool (e.g., virtualenv, Bundler), so the app never relies on implicit system-wide packages. Option E (Config) is correct because the Config principle mandates storing configuration in environment variables rather than in code or checked-in files, keeping config strictly separate from the codebase so the same build can be deployed across environments. The unmarked options do not belong: Shared state (A) contradicts the stateless processes principle, which requires sharing nothing between processes and externalizing state to backing services; Manual deployment (B) contradicts the Build/Release/Run and CI/CD automation principles; and Singleton processes (D) contradicts the concurrency principle, which favors scaling out via multiple stateless processes rather than relying on a single long-lived instance.

Exam trap

The trap is that 'shared state' and 'singleton processes' sound like reasonable architectural choices, but 12-factor explicitly rejects both in favor of stateless, horizontally scalable processes.

Full explanation →

571

MCQmedium

A Pod is stuck in 'Pending' state. Which command is most helpful to diagnose the issue?

A.kubectl logs my-pod

B.kubectl get events

C.kubectl describe pod my-pod

D.kubectl top pod my-pod

AnswerC

`kubectl describe pod` surfaces the scheduler's events, including `FailedScheduling` messages such as insufficient CPU, memory, or unsatisfied node affinity. This directly addresses the Pending constraint, since Pending means no node has been assigned, and the Events section names the exact reason scheduling failed.

Why this answer

'kubectl describe pod my-pod' provides detailed information about the pod's current state, including events, conditions, and resource constraints. When a pod is stuck in 'Pending', it typically means the scheduler cannot place it on a node due to issues like insufficient CPU/memory, persistent volume claims not being bound, or node selector mismatches. The 'describe' command surfaces these specific reasons in the 'Events' section and 'Conditions' field, making it the most direct diagnostic tool.

Exam trap

CNCF often tests the misconception that 'kubectl logs' is the universal debugging command, but for pending pods, logs are unavailable because containers haven't started, making 'kubectl describe' the correct choice for pre-run failures.

How to eliminate wrong answers

Option A is wrong because 'kubectl logs my-pod' retrieves container logs, but a pod in 'Pending' state has not started any containers yet, so there are no logs to fetch; this command is useful only after the pod is running. Option B is wrong because 'kubectl get events' shows cluster-wide events, which can be noisy and may not filter to the specific pod; while it can include scheduling failures, it lacks the pod-specific context and resource details that 'describe' provides. Option D is wrong because 'kubectl top pod my-pod' shows real-time resource usage metrics, which are only available for running pods; a pending pod has no resource consumption data to report.

Full explanation →

572

MCQmedium

A developer created a Deployment with image 'myapp:v1' and then ran 'kubectl set image deployment/myapp myapp=myapp:v2'. What is the effect of this command?

A.It updates the Service selector to point to pods with the new image.

B.It updates the Deployment's pod template to use the new image, triggering a rolling update.

C.It creates a new Deployment named 'v2' with the new image.

D.It immediately restarts all pods with the new image.

AnswerB

The set image command patches the Deployment's pod template with myapp:v2. The Deployment controller then creates a new ReplicaSet and progressively shifts Pods from the old to the new template, performing a rolling update that maintains availability throughout.

Why this answer

The `kubectl set image deployment/myapp myapp=myapp:v2` command updates the pod template within the Deployment's specification to use the new image `myapp:v2`. This change triggers a rolling update, where the Deployment controller creates new pods with the updated image and gradually terminates old pods, ensuring zero downtime. The command does not affect Services, create new Deployments, or restart pods immediately without a rolling update strategy.

Exam trap

CNCF often tests the distinction between updating a Deployment's pod template (which triggers a rolling update) versus directly restarting pods or modifying Services, leading candidates to mistakenly think the command affects Service selectors or creates a new Deployment.

How to eliminate wrong answers

Option A is wrong because `kubectl set image` only modifies the Deployment's pod template; it does not update Service selectors, which are used to route traffic to pods based on labels, not image versions. Option C is wrong because the command updates the existing Deployment's pod template in place, not creating a new Deployment; Kubernetes Deployments are versioned through their pod template changes, not by creating separate Deployment objects. Option D is wrong because the command does not immediately restart all pods; it updates the desired state in the Deployment's pod template, and the Deployment controller performs a rolling update according to the `strategy` field (defaulting to RollingUpdate), which gradually replaces pods rather than restarting them all at once.

Full explanation →

573

MCQeasy

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

A.kube-controller-manager

B.etcd

C.kube-apiserver

D.kube-scheduler

AnswerA

The kube-controller-manager runs the built-in controller loops — such as Deployment, ReplicaSet and Node controllers — that continuously reconcile observed cluster state with the declared desired state, satisfying the requirement for a component that maintains desired state.

Why this answer

The kube-controller-manager is the component that runs controller loops to regulate the state of the cluster. Each controller (e.g., Node Controller, Replication Controller) watches the shared state via the API server and makes changes to drive the actual cluster state toward the desired state defined in the control plane. This is the core mechanism for self-healing and maintaining declarative configuration.

Exam trap

CNCF often tests the misconception that the API server (kube-apiserver) is responsible for maintaining desired state because it is the central hub, but the API server only serves the API and stores state in etcd, while the actual reconciliation is done by the controller-manager's loops.

How to eliminate wrong answers

Option B (etcd) is wrong because etcd is a distributed key-value store used for cluster data persistence, not for running controller loops; it stores the desired and current state but does not reconcile them. Option C (kube-apiserver) is wrong because the API server is the front-end for the Kubernetes control plane that validates and processes RESTful requests, but it does not execute controller logic or maintain desired state through loops. Option D (kube-scheduler) is wrong because the scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for running controller loops to maintain desired state.

Full explanation →

574

MCQeasy

A developer wants to store non-sensitive configuration data, such as a database hostname and port, that multiple pods in different namespaces will consume as environment variables. The data must be reusable and not hardcoded in pod specs. Which Kubernetes resource is most appropriate?

A.An emptyDir volume

B.A ConfigMap

C.A downward API volume

D.A Secret with type Opaque

AnswerB

ConfigMaps are designed to hold non-confidential configuration data in key-value pairs. They can be consumed as environment variables, command-line arguments, or configuration files in volumes. Since the data is non-sensitive and needs to be reused across pods in different namespaces, a ConfigMap is the correct and idiomatic choice.

Why this answer

ConfigMaps are the standard Kubernetes object for storing non-confidential configuration data in key-value form. They decouple configuration from pod specifications, allowing the same data to be consumed by multiple pods across namespaces. Pods can reference ConfigMaps as environment variables, command-line arguments, or mounted files.

This promotes reusability and avoids hardcoding values in pod definitions.

Exam trap

The trap here is selecting a Secret for non-sensitive data because it also stores key-value pairs, but Secrets are meant for confidential information and add unnecessary complexity for plain configuration.

Full explanation →

575

MCQmedium

You deploy a web application as a Deployment with 3 replicas. Each pod runs an Nginx container that listens on port 80. You need to make the application accessible from outside the cluster on a stable IP address that does not change even if nodes are replaced. Which Service type should you use?

A.ExternalName

B.ClusterIP

C.NodePort

D.LoadBalancer

AnswerD

LoadBalancer Services provision an external load balancer (typically from a cloud provider) that provides a stable, externally accessible IP address. This IP remains consistent even if cluster nodes are replaced or scaled, because the load balancer abstracts the backend nodes. It routes traffic to the Service's ClusterIP and then to the pods, meeting the requirement for external stable access.

Why this answer

A LoadBalancer Service is designed to expose an application externally with a stable IP address, typically via a cloud provider's load balancer. It abstracts the underlying nodes, so the external IP remains unchanged even if nodes are replaced. ClusterIP is internal-only, NodePort uses node IPs and a static port but not a stable external IP, and ExternalName is for mapping to external DNS names.

Exam trap

The trap here is assuming that NodePort provides a stable external IP, but it actually exposes the service on each node's IP, which can change when nodes are replaced.

Full explanation →

576

MCQmedium

A cluster administrator needs to run a Pod that requires access to a raw block device on a specific node. The Pod must be scheduled only on nodes labeled disktype=ssd, and it must tolerate a taint hardware=gpu:NoSchedule that exists on those nodes. Which combination of Pod spec fields is required?

A.nodeSelector: disktype=ssd and tolerations for hardware=gpu:NoSchedule

B.tolerations for hardware=gpu:NoSchedule and podAntiAffinity against disktype=ssd

C.nodeName set to the specific node name and tolerations for hardware=gpu:NoSchedule

D.affinity: nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution for disktype=ssd, and no tolerations

AnswerA

nodeSelector restricts scheduling to nodes with the matching label, and the toleration allows the Pod to be placed on nodes tainted with hardware=gpu:NoSchedule. Both are required because the label narrows the candidate nodes and the toleration prevents the taint from repelling the Pod. This combination satisfies the scheduling constraints.

Why this answer

The Pod needs both a node selection mechanism and a toleration. nodeSelector with disktype=ssd restricts scheduling to labeled nodes, and the toleration for hardware=gpu:NoSchedule allows placement on those tainted nodes. Neither alone is sufficient: without the selector, the Pod could land on non-SSD nodes; without the toleration, the taint would block scheduling.

Exam trap

The trap here is thinking that a toleration alone attracts a Pod to a tainted node, when it only permits scheduling on such nodes.

Full explanation →

577

MCQeasy

Which Kubernetes object is used to logically isolate resources within a cluster, such as for separating environments like dev and prod?

A.ClusterRole

B.ResourceQuota

C.Node

D.Namespace

AnswerD

Namespaces provide a logical partition within a single cluster, scoping names, resource quotas and RBAC so teams or environments like dev and prod stay isolated. They satisfy the requirement for logical resource isolation without provisioning separate clusters.

Why this answer

D is correct because a Namespace is the Kubernetes object designed to logically isolate resources within a single cluster. By creating separate Namespaces for environments like dev and prod, you can apply distinct policies, quotas, and access controls without needing multiple physical clusters.

Exam trap

The trap here is that candidates often confuse Namespaces with other cluster-scoped or resource-limiting objects, mistakenly thinking a ClusterRole or ResourceQuota can provide logical isolation, when in fact Namespaces are the fundamental building block for environment separation.

How to eliminate wrong answers

Option A is wrong because a ClusterRole is a cluster-scoped RBAC object that defines permissions across the entire cluster, not a mechanism for isolating resources or environments. Option B is wrong because a ResourceQuota is an object that sets hard limits on resource consumption (e.g., CPU, memory) within a specific Namespace, but it does not itself create logical isolation or separate environments. Option C is wrong because a Node is a worker machine (physical or virtual) that runs Pods; it is a compute resource, not an object for logically separating environments within a cluster.

Full explanation →

578

Multi-Selecthard

Which THREE of the following are valid ways to assign a pod to a specific node? (Choose three.)

Select 3 answers

A.Setting the 'nodeName' field in the pod spec

B.Using 'affinity' with 'nodeAffinity' rules

C.Using 'nodeSelector' with label matching

D.Using a ServiceAccount

E.Setting the 'clusterName' field

AnswersA, B, C

Setting nodeName directly bypasses the scheduler, binding the Pod to that named node at creation. It satisfies the requirement for assigning a Pod to a specific node, though it skips scheduling checks such as resource fit and taints.

Why this answer

Option A is correct because setting the 'nodeName' field directly in the pod spec bypasses the scheduler and binds the pod to that exact node by name. Option B is correct because 'nodeAffinity' rules under 'affinity' let the scheduler place the pod on nodes matching label expressions, including required and preferred constraints. Option C is correct because 'nodeSelector' matches node labels and constrains the scheduler to only nodes carrying the specified labels.

Option D is not a placement mechanism; a ServiceAccount provides an identity for pods to authenticate to the API server, not to select a node. Option E is invalid because 'clusterName' is not a pod spec field used for node assignment and has no scheduling effect.

Exam trap

Candidates often confuse direct node assignment (nodeName) with scheduling constraints (nodeSelector, nodeAffinity). ServiceAccount and clusterName do not affect node placement.

Full explanation →

579

MCQeasy

In the context of the 12-factor app methodology, which factor emphasizes storing configuration in environment variables?

A.Backing services

B.Dependencies

C.Config

D.Codebase

AnswerC

The Config factor requires configuration that varies between deployments — credentials, endpoints, feature flags — to be stored in environment variables rather than committed to code. This keeps the same build artefact portable across environments without code changes.

Why this answer

The Config factor in the 12-factor app methodology states that configuration should be stored in environment variables, not in code or config files. This allows the same codebase to be deployed across environments by injecting different configurations at runtime.

Exam trap

KCNA often tests the confusion between similar-sounding factors like Config and Backing services, causing candidates to overlook the specific emphasis on environment variables for configuration.

How to eliminate wrong answers

Option A is wrong because Backing services refers to treating external services (databases, queues) as attached resources, not configuration storage. Option B is wrong because Dependencies refers to explicitly declaring and isolating dependencies, not configuration. Option D is wrong because Codebase refers to having a single codebase tracked in version control, not configuration management.

Full explanation →

580

MCQeasy

A developer needs to run a one-off database migration job in a Kubernetes cluster and ensure it completes successfully before a new application version is rolled out. Which Kubernetes resource should be used for the migration task?

A.A Job with a restartPolicy of OnFailure and a backoffLimit.

B.A Deployment with a single replica and no Service.

C.A CronJob with a schedule of every minute.

D.A DaemonSet scheduled on every node.

AnswerA

A Job runs Pods to completion and is designed for finite tasks like migrations. Setting restartPolicy to OnFailure lets the container retry on failure, and backoffLimit caps retries before the Job is marked failed. Completion status can gate the application rollout, ensuring the migration succeeds before new code starts.

Why this answer

A Job is the Kubernetes controller for finite, run-to-completion work. With OnFailure restarts and a backoffLimit, it retries transient errors and eventually reports success or failure, giving the rollout a reliable gate before the new application version starts.

Exam trap

The trap here is choosing a controller that keeps Pods running, when the migration needs a finite task that reports completion.

Full explanation →

581

MCQmedium

A team wants to ensure that at least 99.9% of all requests to their application complete within 500ms over a 30-day window. How should this requirement be classified?

A.Service Level Agreement (SLA)

B.Service Level Objective (SLO)

C.Service Level Indicator (SLI)

D.Key Performance Indicator (KPI)

AnswerB

An SLO is a measurable reliability target, such as 99.9% of requests completing within 500ms over 30 days, that a service aims to achieve. This satisfies the stem's latency and availability threshold, whereas an SLA is a contractual commitment and an SLI is the raw measurement.

Why this answer

An SLO is a target value or range for a service level measured by an SLI — here, '99.9% of requests under 500ms over 30 days' is exactly a target threshold on a measured metric. It is the internal reliability goal that teams commit to and track. An SLA, by contrast, is a contractual agreement with consequences (credits, penalties) if the SLO is missed.

Exam trap

The trap here is conflating SLO with SLA — candidates often pick SLA because it sounds like the formal requirement, but the question describes an internal measurable target, which is an SLO.

How to eliminate wrong answers

Option A is wrong because an SLA is a formal, often contractual commitment between a provider and customer that specifies consequences for missing targets — the question describes an internal target, not a contract. Option C is wrong because an SLI is the actual measured value (e.g., the percentage of fast requests), not the target threshold itself. Option D is wrong because a KPI is a broader business or operational metric used to gauge success, not the specific reliability target tied to an SLI.

Full explanation →

582

MCQeasy

Which CNCF project maturity level indicates that a project has successfully adopted the CNCF governance and is considered stable for production use?

A.Incubating

B.Experimental

C.Graduated

D.Sandbox

AnswerC

Graduated status confirms a project has adopted CNCF governance and proven production stability through broad adoption and a completed security audit. This satisfies the stem's requirement for a maturity level indicating stable, production-ready use, distinguishing it from Incubating and Sandbox projects.

Why this answer

The Graduated maturity level is the highest in the CNCF project lifecycle, indicating that a project has both successfully adopted CNCF governance and is considered stable for production use. To achieve Graduated, a project must meet rigorous criteria including adoption by multiple end users, a defined governance structure, and completion of a security audit. This distinguishes it from lower maturity levels such as Sandbox (early-stage) and Incubating (growing but not yet stable).

Exam trap

CNCF often tests the distinction between Sandbox and Incubating, where candidates mistakenly think Sandbox implies production readiness, but Sandbox is explicitly for early-stage projects that have not yet demonstrated stability or adopted full CNCF governance.

How to eliminate wrong answers

Option A is wrong because Incubating is an intermediate stage where projects have shown initial adoption and are working toward graduation, but they are not yet considered fully stable for production use. Option B is wrong because Experimental is not a CNCF maturity level; the CNCF uses Sandbox, Incubating, and Graduated, while Experimental is a term used by other foundations or early-stage projects outside the CNCF. Option D is wrong because Sandbox is the entry-level stage for early-stage projects that are not yet ready for production use and have not fully adopted CNCF governance.

Full explanation →

583

MCQhard

A Deployment has a strategy of RollingUpdate with maxSurge=1 and maxUnavailable=0. The Deployment manages 3 replicas. The image is updated. What happens during the update?

A.All 3 new Pods are created, and then the old ones are terminated all at once

B.One new Pod is created, and once it is ready, one old Pod is terminated. This repeats until all Pods are updated.

C.All 3 old Pods are terminated simultaneously before new ones start

D.The update fails because maxUnavailable cannot be 0

AnswerB

With maxUnavailable=0, no old Pod may be removed until a replacement is ready, so the controller adds one new Pod (maxSurge=1) first. Once that Pod passes readiness, one old Pod terminates, repeating until all three run the new image.

Why this answer

The RollingUpdate strategy with maxSurge=1 and maxUnavailable=0 ensures that during the update, exactly one new Pod is created above the desired replica count (surge of 1) while keeping all existing Pods running (maxUnavailable=0). Once the new Pod reaches the Ready state, one old Pod is terminated, maintaining the desired 3 replicas throughout the process. This cycle repeats until all Pods are updated, guaranteeing zero downtime.

Exam trap

A common misconception is that maxUnavailable=0 prevents any Pod termination, but in a RollingUpdate with maxSurge>0, old Pods are terminated only after new ones are ready, ensuring zero downtime while the update proceeds.

How to eliminate wrong answers

Option A is wrong because it describes a Recreate strategy, not a RollingUpdate; with maxSurge=1, only one new Pod is created at a time, not all three simultaneously. Option C is wrong because terminating all old Pods before starting new ones violates maxUnavailable=0, which prohibits any Pods from being unavailable during the update. Option D is wrong because maxUnavailable=0 is a valid and commonly used setting to ensure zero downtime; the update does not fail as long as there is capacity to surge (maxSurge>0).

Full explanation →

584

MCQeasy

In a CI/CD pipeline, what is the difference between continuous delivery and continuous deployment?

A.Continuous delivery requires manual approval for production deployment; continuous deployment automates it

B.Continuous delivery automatically deploys to production; continuous deployment does not

C.There is no difference; the terms are used interchangeably

D.Continuous deployment runs tests; continuous delivery does not

AnswerA

Continuous delivery stops short of production, requiring a manual approval gate before release; continuous deployment removes that gate and pushes every passing change automatically. This distinction satisfies the stem's requirement to differentiate the two practices by their production approval step.

Why this answer

Continuous delivery automates the build, test, and staging deployment so that every change is release-ready, but the final push to production requires a manual approval or button click. Continuous deployment goes one step further and automatically releases every validated change to production without human intervention. The distinction is purely about whether production deployment is gated by a human.

Exam trap

KCNA often tests the delivery-vs-deployment distinction by swapping their definitions — the key discriminator is the manual approval gate in continuous delivery, which candidates frequently misattribute to continuous deployment.

How to eliminate wrong answers

Option B is wrong because it reverses the definitions — continuous delivery does not automatically deploy to production, and continuous deployment is the one that does. Option C is wrong because the terms describe genuinely different pipeline behaviors, even though they share the same CI foundation. Option D is wrong because both continuous delivery and continuous deployment run automated tests; testing is part of CI and is not the differentiator between the two.

Full explanation →

585

Multi-Selectmedium

Which THREE of the following are important security practices in a container image CI/CD pipeline?

Select 3 answers

A.Hardcoding credentials in the image

B.Running containers as root user

C.Signing images to ensure integrity

D.Using minimal base images to reduce attack surface

E.Scanning images for vulnerabilities in the CI pipeline

AnswersC, D, E

Cryptographic signing with tools such as Cosign or Notation attaches a verifiable signature to the image digest, letting the admission controller reject tampered or unsigned artefacts before deployment. This satisfies the stem's integrity requirement, ensuring only images built by the trusted pipeline are admitted to the cluster.

Why this answer

Option C is correct because cryptographically signing container images (e.g., with Docker Content Trust/Notary or Sigstore cosign) lets the pipeline and runtime verify image integrity and provenance, preventing tampered or unauthorized images from being deployed. Option D is correct because using minimal base images (such as distroless, Alpine, or scratch) removes unnecessary packages, shells, and libraries, directly shrinking the attack surface and reducing the number of exploitable CVEs. Option E is correct because integrating vulnerability scanning (e.g., Trivy, Clair, or Grype) into the CI pipeline catches known CVEs in OS packages and dependencies before the image is published, enabling early remediation.

Option A is wrong because hardcoding credentials in an image bakes secrets into layers where they can be extracted, violating secret-management best practices. Option B is wrong because running containers as root grants excessive privileges and increases the impact of a container escape, whereas least-privilege non-root users are recommended.

Exam trap

KCNA often tests container security by including obvious anti-patterns (hardcoded credentials, running as root) as distractors — candidates must recognize these as insecure practices rather than legitimate options.

Full explanation →

586

MCQeasy

What is the purpose of a Kubernetes Service?

A.To provide a stable endpoint for a set of pods

B.To store configuration data as key-value pairs

C.To manage rolling updates of container images

D.To schedule pods onto nodes

AnswerA

A Service's clusterIP and DNS name remain fixed while pod IPs change on restart or rescheduling, so traffic reaches whichever pods currently match the selector. This decouples clients from ephemeral pod lifecycles, satisfying the requirement for a stable endpoint.

Why this answer

A Kubernetes Service provides a stable, virtual IP address and DNS name that acts as a consistent endpoint for accessing a set of pods, even as pods are created, destroyed, or rescheduled. This abstraction decouples clients from the ephemeral nature of pod IPs, enabling reliable communication within the cluster. Services use label selectors to dynamically route traffic to the appropriate pods, and they support multiple types (ClusterIP, NodePort, LoadBalancer) to expose applications internally or externally.

Exam trap

The trap here is that candidates often confuse a Service with a Deployment, thinking both manage pod lifecycle, but a Service only provides network abstraction and does not handle pod creation, scaling, or updates.

How to eliminate wrong answers

Option B is wrong because storing configuration data as key-value pairs is the purpose of a ConfigMap or Secret, not a Service. Option C is wrong because managing rolling updates of container images is handled by a Deployment or StatefulSet controller, not a Service. Option D is wrong because scheduling pods onto nodes is the responsibility of the Kubernetes Scheduler, which uses resource requests, constraints, and affinity rules, while a Service only handles network abstraction and traffic routing.

Full explanation →

587

MCQeasy

A developer creates a Pod with the following YAML snippet: spec: containers: - name: web image: nginx ports: - containerPort: 80 The Pod is running, but the developer cannot reach it from another Pod in the same namespace using the Pod's IP address. Which command should the developer run first to verify that the container process is listening on port 80?

A.kubectl describe pod <pod-name>

B.kubectl logs <pod-name>

C.kubectl get pod <pod-name> -o yaml

D.kubectl exec -it <pod-name> -- netstat -tuln

AnswerD

Running netstat inside the container shows which ports are listening. If the nginx process is bound to port 80, the output will include a LISTEN entry for 0.0.0.0:80 or :::80. This directly verifies whether the application is listening and helps distinguish application issues from network policy or Service misconfiguration.

Why this answer

The correct first step is to check listening sockets inside the container. Because the Pod is running but unreachable, the issue could be the application not listening on the expected port. Using kubectl exec with netstat (or ss) inside the container provides direct evidence of whether the process is bound to port 80, guiding further troubleshooting.

Exam trap

The trap here is relying on containerPort in the Pod spec as proof that the application listens on that port, when containerPort is only metadata and does not configure the application.

Full explanation →

588

MCQmedium

Which of the following is a valid use case for a DaemonSet?

A.Running a batch job that must complete once

B.Running a stateless web application with multiple replicas

C.Running a stateful application with persistent storage

D.Running a logging agent on every node

AnswerD

A DaemonSet guarantees one pod replica per node, automatically scheduling onto new nodes as they join. This satisfies the stem's requirement of running a logging agent on every node, since node-level log collection demands continuous coverage across the whole cluster rather than a fixed replica count.

Why this answer

A DaemonSet ensures that a copy of a pod runs on all (or a subset of) nodes in the cluster. This is ideal for infrastructure pods like logging agents (e.g., Fluentd), monitoring agents (e.g., Prometheus Node Exporter), or kube-proxy, which must be present on every node to collect logs or enforce network rules. Option D directly matches this use case.

Exam trap

The trap here is that candidates confuse DaemonSets with Deployments or StatefulSets, assuming any long-running workload fits, but the key differentiator is the 'one pod per node' requirement, not replication count or statefulness.

How to eliminate wrong answers

Option A is wrong because a batch job that must complete once is a use case for a Job or CronJob, not a DaemonSet, which runs continuously on each node. Option B is wrong because a stateless web application with multiple replicas is typically deployed as a Deployment, which manages replicas across nodes without requiring one pod per node. Option C is wrong because a stateful application with persistent storage is best handled by a StatefulSet, which provides stable network identities and persistent storage per pod, unlike a DaemonSet which does not guarantee unique identities or ordered scaling.

Full explanation →

589

MCQeasy

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

A.Hosting public container images

B.Providing a default container runtime for Kubernetes

C.Managing container orchestration

D.Defining standards for container images and runtimes

AnswerD

The Open Container Initiative publishes the image-spec and runtime-spec, giving a vendor-neutral format for container images and a standard lifecycle for runtimes. This directly satisfies the stem's ask: OCI governs interoperability standards for images and runtimes, not orchestration, networking or storage, which Kubernetes and CNI/CSI handle separately.

Why this answer

The Open Container Initiative (OCI) is a Linux Foundation project that defines open industry standards for container image formats and container runtimes. Its two main specifications are the OCI Image Spec (which standardizes the container image layout, including layers and manifests) and the OCI Runtime Spec (which defines the lifecycle and configuration for running containers). This ensures interoperability between different container tools and platforms, such as Docker, Podman, and containerd.

Exam trap

CNCF often tests the misconception that the OCI is a tool or platform (like a registry or runtime) rather than a standards body, leading candidates to confuse it with Docker Hub or containerd.

How to eliminate wrong answers

Option A is wrong because hosting public container images is the role of container registries like Docker Hub, Quay.io, or Google Container Registry, not the OCI. Option B is wrong because providing a default container runtime for Kubernetes is not the OCI's responsibility; Kubernetes uses container runtimes like containerd or CRI-O, which may implement OCI specs but are not provided by the OCI itself. Option C is wrong because managing container orchestration is the function of orchestrators like Kubernetes, Docker Swarm, or Nomad, not the OCI, which focuses solely on standardization.

Full explanation →

590

MCQmedium

A user reports that they can access a service by its ClusterIP but not by its DNS name from within the cluster. What is the most likely cause?

A.The CoreDNS pod is not running or is misconfigured

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

C.The service is of type NodePort

D.The service selector does not match any pods

AnswerA

ClusterIP access works because kube-proxy rules route directly to Pod IPs, bypassing DNS. Name resolution depends entirely on CoreDNS, so a stopped or misconfigured CoreDNS pod breaks cluster DNS lookups while leaving ClusterIP connectivity intact.

Why this answer

Accessing a service by ClusterIP works because it relies on iptables/IPVS rules managed by kube-proxy, which are independent of DNS. However, DNS name resolution within the cluster is handled by CoreDNS, which translates service names to ClusterIPs. If CoreDNS is not running or misconfigured, DNS queries for the service name will fail, while direct ClusterIP access remains functional.

This is the most likely cause because the symptom specifically points to a DNS resolution failure.

Exam trap

The CNCF exam often tests the distinction between network-level connectivity (ClusterIP via kube-proxy) and service discovery (DNS via CoreDNS), trapping candidates who assume any connectivity issue must involve kube-proxy or pod matching.

How to eliminate wrong answers

Option B is wrong because kube-proxy is responsible for implementing the ClusterIP-based network rules (iptables/IPVS) that allow direct ClusterIP access; if kube-proxy were not running, ClusterIP access would also fail, not just DNS. Option C is wrong because the service type (NodePort, ClusterIP, etc.) does not affect DNS resolution; NodePort merely exposes the service on a node port, but DNS still resolves the service name to its ClusterIP. Option D is wrong because if the service selector does not match any pods, the service would have no endpoints, and both ClusterIP access and DNS resolution would fail (DNS would still resolve, but connections would be refused); the symptom of working ClusterIP access proves endpoints exist.

Full explanation →

591

MCQmedium

A development team is adopting a GitOps workflow for their Kubernetes applications. They want to ensure that the cluster state always matches the desired state defined in Git. Which component is responsible for continuously reconciling the cluster with the Git repository?

A.kube-scheduler

B.GitOps operator such as Argo CD or Flux

C.Container runtime

D.Kubernetes API server

AnswerB

A GitOps operator runs in the cluster and continuously monitors the Git repository for changes. It compares the desired manifests with the live cluster state and applies any differences, ensuring reconciliation. This automated sync is the core of GitOps and directly satisfies the requirement for continuous reconciliation with Git.

Why this answer

GitOps relies on an operator like Argo CD or Flux that runs in the cluster and continuously reconciles the live state with the desired state stored in Git. This automated sync ensures that any drift is corrected, providing a declarative and version-controlled deployment model.

Exam trap

The trap here is assuming that core Kubernetes components like the API server or scheduler handle external Git reconciliation, when in fact GitOps requires a dedicated operator to pull and apply desired state from Git.

Full explanation →

592

MCQhard

A developer creates a Pod with a single container that writes data to /data. The Pod spec includes a volume of type hostPath with path /mnt/data. After the Pod is deleted, the developer notices that the data persists on the node. What is the primary reason for this behavior?

A.hostPath volumes are not deleted when the Pod is deleted; they persist on the node's filesystem.

B.The Pod's restartPolicy is set to Always, which causes the volume to be recreated after deletion.

C.The volume is backed by a PersistentVolume that retains data even after the Pod is deleted.

D.The kubelet caches volume data in memory and writes it back to the hostPath after Pod deletion.

AnswerA

hostPath volumes mount a file or directory from the host node's filesystem into the Pod. The data written to the hostPath persists beyond the Pod's lifecycle because it is stored on the node itself. Deleting the Pod does not remove the host directory or its contents.

Why this answer

hostPath volumes directly mount a node's filesystem path into a Pod. Data written to that path is stored on the node and remains there even after the Pod is deleted. This is why the data persists, as the node's directory is not automatically cleaned up by Kubernetes.

Exam trap

The trap here is assuming that all volumes are deleted with the Pod, or that hostPath volumes behave like emptyDir volumes.

Full explanation →

593

MCQmedium

An application requires that a specific set of pods be placed on nodes labeled with 'gpu=true'. Which Kubernetes field should be used in the pod spec to enforce this?

A.nodeSelector

B.topologySpreadConstraints

C.affinity.nodeAffinity

D.tolerations

AnswerA

nodeSelector matches pods to nodes using label key-value pairs, so specifying `gpu: "true"` restricts scheduling to nodes carrying that exact label. This directly satisfies the stem's requirement to enforce placement on `gpu=true` nodes, since the scheduler filters out any node lacking the matching label.

Why this answer

`nodeSelector` is the simplest and most direct Kubernetes field for constraining a pod to nodes that have a specific label. By setting `nodeSelector: { gpu: 'true' }` in the pod spec, the scheduler will only place the pod on nodes that have the label `gpu=true`. This is a hard constraint that does not support complex expressions but is ideal for the stated requirement.

Exam trap

The trap here is that candidates often confuse `nodeSelector` with `nodeAffinity`, thinking the more advanced field is always required, but the question specifically asks for the field that enforces placement on labeled nodes, and `nodeSelector` is the simplest and correct answer for a straightforward label match.

How to eliminate wrong answers

Option B is wrong because `topologySpreadConstraints` controls how pods are distributed across topology domains (e.g., zones, nodes) to achieve even spreading, not to enforce placement on nodes with a specific label. Option C is wrong because `affinity.nodeAffinity` can also enforce placement on labeled nodes, but it is a more advanced and flexible field that supports both required and preferred rules; the question asks for the field that should be used, and `nodeSelector` is the simplest and most direct answer for a simple label match. Option D is wrong because `tolerations` allow pods to be scheduled on nodes with matching taints, but they do not enforce placement on nodes with a specific label; they only permit scheduling on otherwise tainted nodes.

Full explanation →

594

MCQeasy

An administrator is troubleshooting a cluster and runs `kubectl get pods -n kube-system`. They see a Pod named `kube-apiserver-controlplane` running on the control plane node. Which statement best describes the role of this component?

A.It schedules Pods onto nodes by evaluating resource requests and node affinity.

B.It stores and serves the cluster's API, acting as the front end for all control plane communication.

C.It watches for changes to desired state and reconciles them by creating or deleting Pods.

D.It runs the container runtime and manages the lifecycle of containers on each node.

AnswerB

The kube-apiserver exposes the Kubernetes API and is the only component that talks directly to etcd. All other components, including kubelet, kube-scheduler, and controllers, communicate through it. It validates and persists objects, performs admission control, and serves REST endpoints for kubectl and clients. This makes it the central hub of the control plane.

Why this answer

The kube-apiserver is the central control plane component that exposes the Kubernetes API and is the sole client of etcd. It authenticates, authorizes, validates, and persists requests, and all other components interact with the cluster through it. Scheduling, container runtime management, and controller reconciliation are handled by separate components, not by the API server.

Exam trap

The trap here is conflating the API server with the scheduler or controller manager, since all three are control plane components that appear in kube-system.

Full explanation →

595

MCQmedium

Which component runs on every worker node and ensures that containers are running in a Pod as specified in the Pod manifest?

A.kube-controller-manager

B.container runtime

C.kubelet

D.kube-proxy

AnswerC

The kubelet is the node agent that watches the API server for pods bound to its node, then starts, monitors and restarts containers via the container runtime to match the manifest. It runs on every worker node.

Why this answer

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It receives Pod specifications (Pod manifests) from the API server, either directly or via the kube-apiserver, and ensures that the containers described in those manifests are running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers as needed.

Exam trap

The trap here is that candidates often confuse the container runtime with the kubelet, thinking the runtime directly reads Pod manifests, when in fact the kubelet is the orchestrator that interprets the manifest and delegates container operations to the runtime via the CRI.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager runs on the control plane, not on worker nodes; it manages controllers like the ReplicaSet controller and Node controller, but does not directly ensure containers are running on a specific node. Option B is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for actually running containers, but it does not interpret Pod manifests or enforce the desired state; it only executes commands from the kubelet via the Container Runtime Interface (CRI). Option D is wrong because kube-proxy runs on each node but handles network proxying and service load balancing (e.g., iptables or IPVS rules), not container lifecycle management.

Full explanation →

596

MCQmedium

A developer creates a Deployment with 'replicas: 3'. After applying the manifest, only 2 pods are running. Which command would help identify why the third pod was not created?

A.kubectl logs deployment/my-deployment

B.kubectl get pods -o wide

C.kubectl get events --all-namespaces

D.kubectl describe deployment my-deployment

AnswerD

This command shows deployment events and status that reveal issues.

Why this answer

`kubectl describe deployment my-deployment` provides a detailed status of the Deployment, including the ReplicaSet events, pod template, and any conditions (e.g., `Available`, `Progressing`) that explain why the desired 3 replicas are not met. It surfaces errors like insufficient resources, failed scheduling, or image pull failures that prevent the third pod from being created.

Exam trap

The trap here is that candidates often choose `kubectl get events` (Option C) thinking it shows all cluster events, but they overlook that `kubectl describe deployment` already includes relevant events for that specific resource, making it the most targeted and efficient diagnostic tool for replica count discrepancies.

How to eliminate wrong answers

Option A is wrong because `kubectl logs deployment/my-deployment` is not a valid command; logs can only be retrieved from individual pods, not from a Deployment object, and even if corrected to target a pod, it would show application logs, not the reason for missing replicas. Option B is wrong because `kubectl get pods -o wide` only lists existing pods with additional details like node IPs, but it does not reveal why a pod was never created or why the ReplicaSet failed to reach the desired count. Option C is wrong because `kubectl get events --all-namespaces` shows events across all namespaces, which is overly broad and may obscure the specific Deployment-related events; while events can help, the most direct and efficient command for diagnosing a Deployment’s replica shortfall is `kubectl describe deployment`.

Full explanation →

597

MCQhard

A pod is in CrashLoopBackOff state. 'kubectl logs pod' shows 'Error: cannot connect to database at db-service:5432'. The database Service exists and is reachable from other pods. What is the most likely cause?

A.The kube-proxy is not functioning

B.The pod's resource limits are too low

C.The database pod is not running

D.The application's configuration has incorrect database connection details

AnswerD

Since the database Service resolves and is reachable from other pods, DNS and networking are fine; the crash stems from the application's own connection settings, such as a wrong hostname, port, or credentials in its configuration.

Why this answer

The error 'cannot connect to database at db-service:5432' while the Service is reachable from other pods strongly indicates the application's configuration (e.g., wrong hostname, port, credentials, or database name) is incorrect. Since other pods can reach the database, the issue is isolated to this pod's config, not cluster networking or the database itself. This is a classic misconfiguration scenario.

Exam trap

KCNA often tests troubleshooting logic where candidates overlook that the problem is isolated to one pod's configuration when the Service is reachable from others, instead blaming cluster-wide components like kube-proxy or the database pod.

How to eliminate wrong answers

Option A is wrong because if kube-proxy were broken, other pods would also fail to reach the Service, but the question states the database is reachable from other pods. Option B is wrong because low resource limits would typically cause OOMKills or throttling, not a specific 'cannot connect' error. Option C is wrong because the database Service is reachable from other pods, implying the database pod is running.

Full explanation →

598

MCQmedium

A platform team is designing a system that must continue serving requests for a product catalog even if the recommendation service becomes unavailable. The recommendation service calls the catalog service to fetch item details, and when it fails, the catalog service should keep responding to user traffic. Which cloud-native architecture principle BEST describes the required behavior for the catalog service?

A.Storing all catalog and recommendation data in a single shared relational database

B.Vertical scaling of the recommendation service to handle peak load

C.Loose coupling through asynchronous, queue-based communication

D.Design for failure and graceful degradation of non-critical dependencies

AnswerD

Designing for failure means assuming dependencies can become unavailable and ensuring the core function still works. The catalog service must serve user traffic even when the recommendation service fails, so it should treat that dependency as non-critical and degrade gracefully instead of failing entirely. This directly matches the stated requirement.

Why this answer

The catalog service must remain available even when the recommendation service fails. That requires treating the recommendation dependency as non-critical and designing for failure, so the catalog service can degrade gracefully rather than propagate the failure. The other choices either change communication style, scale the wrong service, or introduce tighter coupling, none of which satisfies the requirement.

Exam trap

The trap here is assuming that any resilience pattern, such as asynchronous messaging, automatically satisfies a requirement that specifically calls for tolerating a failed dependency.

Full explanation →

599

MCQeasy

Which command would you use to view the current state of all Pods in the default namespace?

A.kubectl describe pods

B.kubectl get pods

C.kubectl list pods

D.kubectl show pods

AnswerB

`kubectl get pods` queries the Kubernetes API server for Pod objects in the active namespace, which defaults to `default`, returning their current phase and status. It satisfies the stem's requirement to view all Pods in that namespace without extra flags, unlike commands needing `-n` or `--all-namespaces`.

Why this answer

The `kubectl get pods` command retrieves and displays the current state of all Pods in the default namespace. It is the standard imperative command for listing Kubernetes resources, showing key fields like NAME, READY, STATUS, RESTARTS, and AGE.

Exam trap

The trap here is that candidates may confuse `kubectl get` with non-existent verbs like `list` or `show`, or mistakenly think `describe` is used for listing all resources, when `describe` is actually for detailed inspection of specific resources.

How to eliminate wrong answers

Option A is wrong because `kubectl describe pods` provides detailed information about one or more Pods (including events and container details) but does not give a concise list of all Pods and their states. Option C is wrong because `kubectl list pods` is not a valid kubectl command; the correct verb for listing resources is `get`. Option D is wrong because `kubectl show pods` is not a valid kubectl command; kubectl does not support a `show` subcommand for resources.

Full explanation →

600

MCQhard

An application requires that a pod must not be scheduled on the same node as another pod from the same Deployment. Which configuration should be used?

A.Node affinity with requiredDuringSchedulingIgnoredDuringExecution

B.Pod affinity with a preferredDuringSchedulingIgnoredDuringExecution

C.Pod anti-affinity with requiredDuringSchedulingIgnoredDuringExecution and topologyKey: kubernetes.io/hostname

D.Taints and tolerations

AnswerC

Required pod anti-affinity with topologyKey kubernetes.io/hostname makes the scheduler treat each node as a distinct failure domain, so no two pods sharing the Deployment's label can land on the same host. The requiredDuringSchedulingIgnoredDuringExecution rule enforces this as a hard constraint rather than a preference.

Why this answer

Pod anti-affinity with `requiredDuringSchedulingIgnoredDuringExecution` enforces a hard constraint that prevents two pods from the same Deployment from being scheduled on the same node. The `topologyKey: kubernetes.io/hostname` specifies that the anti-affinity rule applies at the node level, ensuring each pod is placed on a distinct host. This directly meets the requirement that a pod must not be scheduled on the same node as another pod from the same Deployment.

Exam trap

A common pitfall in Kubernetes exams is confusing pod affinity (which attracts pods to the same node) with pod anti-affinity (which repels them). Option B uses `preferredDuringSchedulingIgnoredDuringExecution` which is a soft preference, not a hard requirement, and it uses affinity instead of anti-affinity, so it would actually encourage pods to be together, not apart.

How to eliminate wrong answers

Option A is wrong because node affinity controls pod-to-node placement based on node labels, not pod-to-pod relationships; it cannot prevent two pods from the same Deployment from landing on the same node. Option B is wrong because pod affinity with `preferredDuringSchedulingIgnoredDuringExecution` is a soft preference, not a hard requirement, and it attracts pods to the same node rather than spreading them apart. Option D is wrong because taints and tolerations control which nodes a pod can be scheduled on (by repelling pods unless they tolerate the taint), but they do not enforce anti-affinity between pods of the same Deployment.

Full explanation →

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 526–600