Kubernetes and Cloud Native Associate KCNA KCNA Questions 76–150 | Page 2/13

MCQmedium

In OpenTelemetry, which component is responsible for receiving, processing, and exporting telemetry data from multiple sources?

A.OpenTelemetry Collector

B.OpenTelemetry SDK

C.OpenTelemetry Exporter

D.OpenTelemetry API

AnswerA

The OpenTelemetry Collector receives telemetry via receivers, processes it through processors such as batching, then exports it to backends. This satisfies the stem's requirement to handle data from multiple sources, acting as a vendor-neutral pipeline between instrumented services and observability platforms.

Why this answer

The OpenTelemetry Collector is a vendor-agnostic proxy that can receive, process, and export telemetry data from multiple sources. It supports various receivers (e.g., OTLP, Jaeger, Prometheus) to ingest data, processors to modify or filter it, and exporters to send it to backends. This central component decouples instrumentation from backends, enabling flexible pipelines.

Exam trap

KCNA often tests the distinction between the Collector and other OpenTelemetry components, and candidates may confuse the Collector with the SDK or exporter, forgetting that the Collector is the only component designed to receive, process, and export data from multiple sources.

How to eliminate wrong answers

Option B is wrong because the OpenTelemetry SDK is a library used within applications to generate and emit telemetry data, not a standalone service for receiving from multiple sources. Option C is wrong because an exporter is a component within the Collector or SDK that sends data to a backend; it does not receive or process data from multiple sources. Option D is wrong because the OpenTelemetry API is a set of interfaces for instrumenting code, not a component that receives, processes, or exports telemetry.

Full explanation →

MCQmedium

A developer runs `kubectl apply -f pod.yaml` against a cluster running Kubernetes v1.29. The Pod manifest sets `spec.restartPolicy: Always` and `spec.containers[0].name: app`. The Pod starts successfully but the developer wants to change the container image from `nginx:1.24` to `nginx:1.25`. They edit the YAML file and re-run `kubectl apply -f pod.yaml`. What is the result?

A.The apply succeeds but the change is silently ignored because Pods are managed by the kubelet.

B.The apply fails with an error indicating that the Pod spec is invalid or cannot be updated.

C.The existing Pod is patched in place and the container image is updated without restarting the Pod.

D.The Pod is deleted and recreated with the new image because Pods are immutable.

AnswerB

Most fields of a running Pod's spec, including the container image, are immutable. The API server rejects the update attempt with a validation error stating that the field is immutable. To change the image you must delete and recreate the Pod, or manage it through a Deployment or similar controller that handles replacement for you.

Why this answer

Pods have a largely immutable spec once created. Changing the container image via `kubectl apply` is rejected by the API server with an immutable-field error. The intended workflow for image updates is to use a controller such as a Deployment, which creates a new ReplicaSet and new Pods.

For a bare Pod, you must delete it and recreate it with the new image.

Exam trap

The trap here is assuming that `kubectl apply` can mutate any field of a live Pod, when in fact most Pod spec fields including the container image are immutable.

Full explanation →

MCQhard

In Prometheus, what is the purpose of the Alertmanager component?

A.To scrape metrics from targets

B.To provide a graphical dashboard for metrics

C.To manage, group, and route alerts to notification channels like email or Slack

D.To store historical metrics data long-term

AnswerC

Alertmanager receives alerts fired by Prometheus, then deduplicates, groups, and routes them to receivers such as email, Slack, or PagerDuty. It also handles silencing and inhibition, preventing notification floods during outages. This satisfies the stem's requirement to manage, group, and route alerts to notification channels.

Why this answer

Alertmanager is a separate component from the Prometheus server that receives alerts generated by Prometheus alerting rules. Its core purpose is to deduplicate, group, and route those alerts to the correct receiver—such as email, Slack, PagerDuty, or a webhook—based on routing rules and labels. It also handles silencing and inhibition to reduce noise during incidents, which is essential for effective on-call alerting.

Exam trap

KCNA often tests the misconception that Alertmanager is responsible for generating alerts or storing metrics, when in fact it only handles routing and notification after Prometheus evaluates alerting rules.

How to eliminate wrong answers

Option A is wrong because scraping metrics from targets is the job of the Prometheus server itself, which pulls metrics over HTTP from configured scrape targets; Alertmanager does not scrape. Option B is wrong because graphical dashboards are provided by tools like Grafana or Prometheus's own expression browser, not by Alertmanager, which has only a basic UI for viewing and silencing alerts. Option D is wrong because long-term storage of historical metrics is handled by Prometheus's local time-series database (TSDB) or remote storage integrations like Thanos, Cortex, or Mimir; Alertmanager does not store metrics.

Full explanation →

Multi-Selecthard

Which three components are part of the Kubernetes control plane?

Select 3 answers

A.kube-controller-manager

B.kube-proxy

C.kube-scheduler

D.kube-apiserver

E.kubelet

AnswersA, C, D

The kube-controller-manager runs the control loops that reconcile cluster state, including the ReplicaSet controller. It is hosted on the control plane, not worker nodes, satisfying the question's requirement for a genuine control plane component alongside the API server and scheduler.

Why this answer

The Kubernetes control plane consists of the components that make global cluster decisions and expose the cluster API. Option D, kube-apiserver, is correct because it is the front end of the control plane, serving the Kubernetes API over HTTPS and persisting cluster state in etcd. Option C, kube-scheduler, is correct because it watches for newly created Pods with no assigned node and selects a node for them based on resource requirements, affinity, and taints/tolerations.

Option A, kube-controller-manager, is correct because it runs the built-in controller loops (such as node, replication, endpoints, and service account controllers) that drive the cluster toward its desired state. Option B, kube-proxy, is not part of the control plane; it is a node-level component that maintains network rules (iptables/IPVS) for Service load balancing. Option E, kubelet, is also not part of the control plane; it is the node agent that registers the node and manages Pod containers via the container runtime.

Exam trap

A common mistake is to include kube-proxy or kubelet as control plane components because they are essential to cluster operation, but they actually run on every node and are not part of the control plane.

Full explanation →

Multi-Selectmedium

Which TWO of the following are benefits of container orchestration?

Select 2 answers

A.Ability to run containers without a kernel

B.Manual scaling of containers

C.High availability through self-healing

D.Automated scaling based on demand

E.Simplified network configuration for each container

AnswersC, D

Orchestrators automatically restart failed containers.

Why this answer

Container orchestration platforms like Kubernetes implement self-healing mechanisms through controllers such as ReplicaSets and StatefulSets. These controllers continuously monitor the desired state of pods and automatically restart, reschedule, or replace containers that fail, crash, or become unresponsive, ensuring high availability without manual intervention.

Exam trap

The trap here is that candidates confuse the ability to run containers without a kernel (Option A) with the concept of container isolation, but containers always depend on the host kernel, and Kubernetes orchestration does not change that.

Full explanation →

MCQmedium

A developer wants to run a containerized application locally for development. Which tool is most appropriate?

A.CRI-O

B.Docker Compose

C.containerd

D.Kubernetes

AnswerB

Docker Compose defines and runs multi-container applications from a single YAML file, orchestrating linked services, networks and volumes with one command. For local development requiring several cooperating containers, this satisfies the need to start the whole stack together rather than managing each container individually.

Why this answer

Docker Compose is the most appropriate tool for running a containerized application locally during development because it allows you to define and manage multi-container applications using a simple YAML file. It handles container lifecycle, networking, and volume mounts with a single `docker compose up` command, making it ideal for local development workflows where rapid iteration and simplicity are key.

Exam trap

The trap here is that candidates confuse container runtimes (CRI-O, containerd) or orchestration platforms (Kubernetes) with development tools, assuming any container-related technology can run apps locally, but the KCNA exam specifically tests the understanding that Docker Compose is the standard for local multi-container development.

How to eliminate wrong answers

Option A (CRI-O) is wrong because it is a lightweight container runtime designed for Kubernetes, not a tool for local development; it lacks the developer-friendly features like `docker compose up` and is typically used in production clusters. Option C (containerd) is wrong because it is a low-level container runtime that manages container lifecycle but does not provide orchestration or multi-container application definitions; it is a building block for higher-level tools like Docker or Kubernetes, not a development tool. Option D (Kubernetes) is wrong because it is a full-scale container orchestration platform intended for production deployments across clusters; running it locally (e.g., via Minikube or kind) adds unnecessary complexity and overhead compared to Docker Compose for simple development scenarios.

Full explanation →

MCQeasy

Which CNCF project is classified as a 'graduated' project?

A.Linkerd

B.K3s

C.Knative

D.Backstage

AnswerA

Linkerd reached CNCF graduated status, the highest maturity tier, reflecting production adoption, security audits and a stable governance process. Other service meshes remain at incubating or sandbox level, so graduation is the axis distinguishing it here.

Why this answer

Linkerd is a CNCF graduated project, having reached that maturity level in July 2021. It is a service mesh that provides observability, security, and reliability for Kubernetes workloads. Graduated status means the project has demonstrated production adoption, a healthy contributor base, and a stable governance model.

Exam trap

KCNA often tests the distinction between CNCF maturity levels — candidates confuse incubating projects like Knative and Backstage with graduated ones, or assume any popular project is graduated.

How to eliminate wrong answers

Option B is wrong because K3s is a lightweight Kubernetes distribution that is a CNCF sandbox project (it was accepted into sandbox in 2021 and has not graduated). Option C is wrong because Knative is a CNCF incubating project, not graduated. Option D is wrong because Backstage is also a CNCF incubating project (accepted in 2022), not graduated.

Full explanation →

MCQmedium

An application requires stable network identities and persistent storage. Which workload type should be used?

A.Deployment

B.DaemonSet

C.Job

D.StatefulSet

AnswerD

StatefulSet assigns each pod a stable, ordinal hostname and its own PersistentVolumeClaim, so network identity and storage survive rescheduling. Deployments give pods random names and share or lose volumes, failing the persistence and stable-identity requirement.

Why this answer

StatefulSet is the correct workload type because it provides stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage (via PersistentVolumeClaims that persist across Pod rescheduling). This makes it ideal for stateful applications like databases, where each Pod requires a stable identity and dedicated storage that survives restarts.

Exam trap

The KCNA exam often tests the misconception that Deployments can handle stateful workloads by using PersistentVolumeClaims, but they fail to account for the lack of stable network identities and ordered pod management that StatefulSet provides.

How to eliminate wrong answers

Option A is wrong because Deployment is designed for stateless applications; it creates pods with random, ephemeral identities and does not guarantee stable network names or persistent storage per pod. Option B is wrong because DaemonSet ensures one pod per node, typically for node-level services like logging or monitoring, and does not provide stable identities or persistent storage for stateful workloads. Option C is wrong because Job is intended for batch processing tasks that run to completion, not for long-running stateful services requiring stable identities and persistent storage.

Full explanation →

MCQmedium

A CI pipeline builds a container image and tags it only as latest before pushing to a registry. A release engineer needs to deploy a specific, immutable version and be able to roll back to a known good build. What is the best practice to adopt?

A.Keep using latest but enable imagePullPolicy: Always on all Pods.

B.Push images to multiple registries and deploy from whichever responds fastest.

C.Tag images with the build timestamp and deploy the newest tag each time.

D.Tag each image with the Git commit SHA and deploy that immutable tag.

AnswerD

A Git commit SHA is unique and immutable, so the same tag always refers to the same image digest. Deploying that tag makes the running version auditable and reproducible, and rolling back means redeploying a previous SHA tag. This avoids the ambiguity of latest, which can point to different images over time.

Why this answer

Immutable, traceable tags let a deployment reference an exact build and make rollback deterministic. A Git commit SHA uniquely identifies the source revision, so the same tag always resolves to the same image content, unlike latest or timestamp-based tags.

Exam trap

The trap here is believing imagePullPolicy: Always makes latest safe, when the tag itself remains mutable and unsuitable as a release identifier.

Full explanation →

MCQeasy

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

A.kube-scheduler

B.kube-controller-manager

C.etcd

D.kube-apiserver

AnswerC

etcd is the distributed key-value store holding all cluster objects, configurations and state. The API server reads and writes exclusively through it, making etcd the single source of truth. This persistence role satisfies the stem's requirement for the control plane component responsible for persisting cluster state.

Why this answer

etcd is the distributed key-value store that acts as the single source of truth for the entire Kubernetes cluster. It stores all cluster state data, including configuration, secrets, and the desired state of every object, ensuring consistency and durability. The kube-apiserver is the only component that directly interacts with etcd, enforcing a strict serialization of writes to prevent corruption.

Exam trap

The trap here is that candidates often confuse the kube-apiserver as the storage backend, but it merely validates requests and writes to etcd. The etcd cluster is the actual persistent state store.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for persisting state. Option B is wrong because kube-controller-manager runs controller loops that reconcile the actual cluster state with the desired state stored in etcd, but it does not persist data itself. Option D is wrong because kube-apiserver is the front-end that validates and processes API requests, but it delegates the actual persistence of cluster state to etcd via gRPC calls.

Full explanation →

Multi-Selecthard

Which THREE are typical characteristics of a cloud-native application?

Select 3 answers

A.Long startup times due to heavy initialization

B.Vulnerable to cascading failures

C.Packaged as lightweight containers

D.Designed for horizontal scaling

E.Built using microservices architecture

AnswersC, D, E

Lightweight containers bundle the application and its dependencies into a single immutable image, so it starts consistently across any host. This satisfies the stem's cloud-native expectation of rapid, portable deployment and horizontal scaling, unlike monolithic virtual machines that carry a full guest operating system.

Why this answer

Option C is correct because cloud-native applications are typically packaged as lightweight containers (e.g., Docker images orchestrated by Kubernetes), which enables portability, fast startup, and consistent deployment across environments. Option D is correct because cloud-native design favors horizontal scaling—adding more stateless instances behind a load balancer—rather than scaling up a single large server, allowing elasticity to match demand. Option E is correct because cloud-native applications are commonly built using a microservices architecture, where loosely coupled, independently deployable services communicate over lightweight protocols such as HTTP/REST or gRPC.

Option A is not typical, since cloud-native apps aim for fast startup and rapid initialization to support scaling and resilience. Option B is not a characteristic but a risk; cloud-native patterns like circuit breakers, retries, and bulkheads are used specifically to prevent cascading failures.

Exam trap

CNCF often tests the misconception that cloud-native apps are just 'apps in the cloud' rather than specifically requiring containerization, microservices, and horizontal scaling; candidates may mistakenly associate long startup times or fragility with cloud-native, when those are anti-patterns.

Full explanation →

MCQhard

You are implementing an API gateway pattern for a set of microservices. Which of the following is a typical responsibility of an API gateway?

A.Managing container lifecycle and scaling

B.Directly accessing databases to serve requests

C.Storing application state and session data

D.Enforcing authentication and rate limiting

AnswerD

API gateways centralise cross-cutting concerns for microservices, including authentication, authorisation, rate limiting, and request routing. Enforcing authentication and rate limiting is a canonical gateway responsibility, offloading these tasks from individual services rather than duplicating them in each.

Why this answer

An API gateway sits in front of microservices and centralizes cross-cutting concerns such as authentication, authorization, rate limiting, request routing, and TLS termination. Enforcing authentication and rate limiting is a canonical gateway responsibility because it offloads these concerns from individual services. This lets each microservice focus on business logic while the gateway handles policy uniformly.

Exam trap

KCNA often tests the boundary between gateway responsibilities (routing, auth, rate limiting) and orchestrator responsibilities (container lifecycle, scaling), so candidates confuse the API gateway with Kubernetes control-plane functions.

How to eliminate wrong answers

Option A is wrong because container lifecycle management and scaling are the job of an orchestrator like Kubernetes (kubelet, scheduler, HPA), not an API gateway. Option B is wrong because a gateway routes requests to services; it should not directly access databases, which would break service encapsulation and the database-per-service pattern. Option C is wrong because storing application state and session data belongs to stateful stores (databases, Redis) or the services themselves — gateways are typically stateless request proxies.

Full explanation →

MCQeasy

Which of the following is a benefit of using an orchestrator like Kubernetes?

A.Direct access to the host kernel for performance tuning

B.Guaranteed zero downtime for all updates

C.Automatic scaling based on CPU utilization

D.Manual scaling based on traffic spikes

AnswerC

Kubernetes Horizontal Pod Autoscaler adjusts replica counts based on observed CPU utilisation against defined targets, adding or removing pods automatically. This removes manual capacity intervention, satisfying the benefit of responding to load changes without operator action.

Why this answer

Kubernetes, as a container orchestrator, provides built-in Horizontal Pod Autoscaling (HPA) that automatically adjusts the number of pod replicas based on observed CPU utilization (or custom metrics). This is a core benefit because it allows applications to handle varying load without manual intervention, improving resource efficiency and availability.

Exam trap

The trap here is that candidates confuse 'automatic scaling' with 'manual scaling' or assume Kubernetes guarantees zero downtime, but the exam tests the specific benefit of automated, policy-driven scaling based on metrics like CPU utilization.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not provide direct access to the host kernel; containers share the host kernel via namespaces and cgroups, and direct kernel access would break isolation and security. Option B is wrong because Kubernetes cannot guarantee zero downtime for all updates; while it supports rolling updates and strategies like maxSurge and maxUnavailable to minimize disruption, factors like application bugs or resource constraints can still cause downtime. Option D is wrong because manual scaling based on traffic spikes is not a benefit of using an orchestrator; orchestrators like Kubernetes automate scaling, and manual scaling is a legacy approach that defeats the purpose of orchestration.

Full explanation →

Multi-Selectmedium

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

Select 2 answers

A.container runtime

B.kube-apiserver

C.kubelet

D.etcd

E.kube-proxy

AnswersB, D

kube-apiserver is the control plane component exposing the Kubernetes API; every kubectl request and internal component interaction flows through it, and it validates and persists objects to etcd. It is therefore part of the control plane.

Why this answer

The Kubernetes control plane consists of components that make global cluster decisions and store cluster state. Option B, kube-apiserver, is correct because it is the central management endpoint that exposes the Kubernetes API, validates and processes REST requests, and is the front end through which all other components communicate. Option D, etcd, is correct because it is the consistent, highly-available key-value store that persists all cluster data, including object specs and state, and is the backing store for the API server.

The unmarked options are node-level components, not control plane components: the container runtime (A) executes containers on each node, kubelet (C) is the node agent that manages pods and containers on a node, and kube-proxy (E) implements Service networking rules on each node.

Exam trap

Candidates often confuse kubelet or kube-proxy (which run on every node) as part of the control plane because they are essential for cluster operation, but they are not control plane components.

Full explanation →

Drag & Dropmedium

Drag and drop the steps to perform a backup of etcd in a Kubernetes cluster into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Access the node, save snapshot, verify, store securely, and restore when necessary.

Full explanation →

MCQhard

A Kubernetes cluster runs a critical application that must be highly available. The application consists of three pods managed by a Deployment. To ensure the application remains accessible during a node failure, which configuration should be applied?

A.Set podAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution to enforce pods on different nodes.

B.Set nodeAffinity to require pods to run on specific nodes.

C.Set topologySpreadConstraints with maxSkew: 1 and whenUnsatisfiable: ScheduleAnyway.

D.Set podAntiAffinity to prefer scheduling pods on different nodes.

AnswerA

requiredDuringSchedulingIgnoredDuringExecution makes the anti-affinity a hard rule. The scheduler will not place two pods with the matching labels on the same node. This ensures that the three pods are spread across at least three nodes, so a single node failure only affects one pod, maintaining availability. This is the strongest guarantee for spreading pods.

Why this answer

To guarantee that pods are spread across different nodes, a hard pod anti-affinity rule is needed. requiredDuringSchedulingIgnoredDuringExecution enforces that no two pods with the specified labels can be on the same node. This ensures that a single node failure does not take down all replicas. Soft anti-affinity, topology spread with ScheduleAnyway, and node affinity do not provide the same hard guarantee.

Exam trap

The trap here is confusing preferred anti-affinity or topology spread with ScheduleAnyway as sufficient for high availability; only hard requirements guarantee spreading.

Full explanation →

MCQhard

A team is designing a cloud-native system that must maintain high availability across multiple cloud regions. The application uses Kubernetes clusters in each region. Which approach best ensures that the system can tolerate a full region failure while minimizing complexity?

A.Deploy a single Kubernetes cluster spanning all regions

B.Use a global load balancer with active-passive regional failover

C.Run active-active in all regions with synchronous data replication

D.Implement manual failover procedures documented in runbooks

AnswerB

A global load balancer with active-passive regional failover keeps one region serving traffic and redirects to the standby on failure, tolerating a full region outage with far less operational complexity than active-active multi-region state replication.

Why this answer

A global load balancer with active-passive regional failover provides a straightforward way to route traffic to a healthy secondary region when the primary fails, without the complexity of multi-region Kubernetes control planes or synchronous replication. This approach leverages DNS-based or anycast routing to detect region failure and redirect traffic, ensuring high availability while keeping the operational overhead low.

Exam trap

CNCF often tests the misconception that active-active with synchronous replication is always the best for high availability, but the trap here is that it introduces unnecessary complexity and cost for most use cases, while active-passive with a global load balancer offers a simpler, production-proven alternative for tolerating region failures.

How to eliminate wrong answers

Option A is wrong because a single Kubernetes cluster spanning multiple regions introduces significant latency, network partitioning risks, and control plane complexity, as Kubernetes is not designed for跨区域 single clusters and would violate the recommended failure domain boundaries. Option C is wrong because active-active with synchronous data replication across regions adds substantial latency, cost, and complexity, and is typically unnecessary for most applications; it also requires careful handling of conflict resolution and network reliability. Option D is wrong because manual failover procedures are slow, error-prone, and cannot meet the high availability requirements of a cloud-native system that must tolerate a full region failure automatically.

Full explanation →

MCQhard

An administrator runs `kubectl get pods -n finance` and sees a Pod named `report-0` that is Running but not Ready. The Pod's container has a readiness probe configured with `httpGet` on path `/healthz` port 8080. Logs show the application is running and serving requests on port 8080. Which condition most likely explains why the Pod is Running but not Ready?

A.The Pod's liveness probe has failed repeatedly and kubelet is restarting the container, which temporarily reports not ready.

B.The Pod has no resource requests, so the scheduler has not fully allocated CPU and the readiness gate remains closed.

C.The Pod is using a hostPath volume that is not writable, causing the readiness probe to fail at the filesystem level.

D.The readiness probe endpoint `/healthz` returns a non-2xx status code or times out, so kubelet marks the container as not ready.

AnswerD

Kubelet periodically calls the readiness probe, and any non-success response or timeout causes the container to be marked not ready. The Pod remains Running because the process is alive, but it is excluded from Service endpoints until the probe succeeds. This perfectly matches a Running yet unready Pod whose application otherwise serves traffic.

Why this answer

Readiness probes determine whether a container should receive traffic. When the HTTP GET to `/healthz` fails or times out, kubelet marks the container not ready while leaving the process running, producing exactly the Running-but-not-Ready state. Liveness failures cause restarts, and scheduling or storage issues do not selectively block readiness in the way described.

Exam trap

The trap here is assuming a Running Pod is automatically Ready, when readiness depends on probe success.

Full explanation →

MCQmedium

A pod is in the 'CrashLoopBackOff' state. You run 'kubectl logs mypod' and see an error related to missing environment variables. The pod is part of a Deployment. What is the best way to fix this without recreating the entire Deployment?

A.Use kubectl set env to add the environment variables to the pod

B.Delete the pod and rely on the Deployment to recreate it

C.Update the Deployment's pod template to include the missing environment variables

D.Edit the pod directly using kubectl edit pod mypod

AnswerC

Updating the Deployment's spec triggers a rolling update, creating new pods with the correct environment.

Why this answer

The Deployment's pod template defines the desired state for its ReplicaSet. Updating the template to include the missing environment variables causes the Deployment to perform a rolling update, creating new pods with the correct configuration. This is the declarative, Kubernetes-native approach that maintains the Deployment's lifecycle management.

Note that `kubectl set env deployment/<name> KEY=value` is also a valid imperative way to update the Deployment's pod template and trigger the same rolling update; it is not the same as editing the pod directly.

Exam trap

Kubernetes often tests the misconception that you can fix a pod's configuration by editing the pod directly, when in fact the Deployment's controller will replace or reconcile those changes, making a template update the durable fix. Be careful not to confuse editing a pod directly with updating the Deployment's pod template imperatively via `kubectl set env`.

How to eliminate wrong answers

Option A is wrong because 'kubectl set env' modifies the environment of a running pod, but the pod is in CrashLoopBackOff and will be recreated from the Deployment's template; the change is ephemeral and not persisted. Option B is wrong because deleting the pod only triggers the ReplicaSet to recreate it from the same faulty template, resulting in the same CrashLoopBackOff. Option D is wrong because editing the pod directly with 'kubectl edit pod' only changes the live pod object, which is not managed by the Deployment; the ReplicaSet will revert the pod to the template's specification upon any reconciliation.

Full explanation →

MCQmedium

A developer creates a Pod with a container that writes data to /var/log/app.log inside the container. The Pod is deleted and recreated, and the log file is gone. Which Kubernetes volume type would preserve the log file across Pod restarts on the same node?

A.configMap

B.hostPath

C.secret

D.emptyDir

AnswerB

A hostPath volume mounts a directory from the host node's filesystem into the Pod. If the container writes to that mounted directory, the data remains on the node even after the Pod is deleted. When the Pod is recreated on the same node, the hostPath volume is reattached and the log file persists.

Why this answer

hostPath mounts a node-local directory into the Pod, so data written there survives Pod deletion and is available when a new Pod is scheduled to the same node. emptyDir is ephemeral and tied to the Pod, while configMap and secret are read-only configuration mechanisms, not persistent storage for application logs.

Exam trap

The trap here is confusing emptyDir with persistent storage; emptyDir is deleted when the Pod is removed, even though it is writable.

Full explanation →

MCQhard

A team is deploying a microservice application on Kubernetes. They want to ensure that during rolling updates, the new version of the service receives traffic only after the readiness probe succeeds. However, they observe that the old pods are terminated before the new pods are ready, causing a brief downtime. Which configuration change should they make to the Deployment to prevent this?

A.Set spec.strategy.rollingUpdate.minReadySeconds to 0

B.Set spec.strategy.rollingUpdate.maxSurge=0 and maxUnavailable=1

C.Add a liveness probe to the container spec

D.Set spec.strategy.rollingUpdate.maxSurge=1 and maxUnavailable=0

AnswerD

Setting maxUnavailable to 0 guarantees no old pod is removed until a replacement passes its readiness probe, while maxSurge=1 permits one extra pod above the desired replica count so the new version can start alongside the old. This directly satisfies the stem's requirement that traffic shifts only after readiness succeeds, eliminating the brief downtime.

Why this answer

Setting maxSurge=1 and maxUnavailable=0 ensures that during a rolling update, Kubernetes creates a new pod (surge) before terminating any old pod, and never allows the available pod count to drop below the desired replica count. Combined with a readiness probe, the new pod only receives traffic after it passes readiness, so the old pod is not removed until the new one is ready — eliminating the downtime.

Exam trap

KCNA often tests the interaction between maxSurge/maxUnavailable and readiness probes; candidates who focus only on the probe (C) or who pick maxUnavailable=1 (B) miss that the rollout strategy parameters control whether old pods are terminated before new ones are ready.

How to eliminate wrong answers

Option A is wrong because minReadySeconds=0 means a pod is considered ready immediately after its readiness probe passes, with no additional stabilization window; it does not prevent old pods from being terminated early and can actually make rollouts faster but less safe. Option B is wrong because maxSurge=0 and maxUnavailable=1 allows one pod to be unavailable at a time, meaning an old pod can be terminated before a new one is ready — this is exactly the configuration that causes the observed downtime. Option C is wrong because a liveness probe detects and restarts unhealthy containers; it does not control rollout ordering or prevent premature termination of old pods, and adding one does not address the maxSurge/maxUnavailable settings.

Full explanation →

MCQmedium

A developer needs a Pod to read configuration values and credentials separately, where non-sensitive settings should update without restarting the Pod and secrets should be mounted as files. Which pairing of Kubernetes objects best fits this requirement?

A.Secret for both the settings and the credentials, consumed via environment variables.

B.ConfigMap for both, with the credentials stored in a separate key and mounted as a volume.

C.ConfigMap for the non-sensitive settings and Secret for the credentials, both consumed as volumes.

D.ConfigMap for the settings and a downward API volume for the credentials.

AnswerC

ConfigMap holds non-sensitive key-value configuration and Secret holds sensitive data; both can be mounted as volumes so the files refresh when the API objects change, satisfying the no-restart requirement for the non-sensitive settings. Volume-mounted updates propagate to the Pod's filesystem on the kubelet's sync period, though applications must re-read the files. This pairing matches the stated separation of concerns exactly.

Why this answer

The requirement splits non-sensitive settings that must refresh live from credentials that must be handled securely, and the ConfigMap-plus-Secret pairing consumed as volumes satisfies both. Volume-mounted ConfigMaps update on the kubelet sync interval, while Secret volumes keep credentials out of environment dumps and allow tighter RBAC.

Exam trap

The trap here is reaching for environment variables, which are frozen at container start and never reflect later ConfigMap or Secret changes.

Full explanation →

Multi-Selectmedium

Which two of the following are container runtimes that implement the Container Runtime Interface (CRI)? (Choose two.)

Select 2 answers

A.Docker

B.containerd

C.Podman

D.CRI-O

E.runc

AnswersB, D

containerd implements CRI and is a common runtime.

Why this answer

containerd is a core container runtime that implements the Container Runtime Interface (CRI), which is the Kubernetes API for integrating container runtimes. It was originally extracted from Docker and is now a graduated CNCF project, providing a stable CRI-compatible interface for managing container lifecycles.

Exam trap

The exam often tests the misconception that Docker is a CRI-compliant runtime, when in fact it required the now-removed dockershim, and that runc is a CRI implementation rather than a low-level OCI runtime.

Full explanation →

MCQhard

You have a Deployment that manages 3 replicas. You want to perform a rolling update with a maximum of 2 Pods unavailable during the update. Which field should you set in the Deployment spec?

A.spec.strategy.rollingUpdate.maxUnavailable

B.spec.minReadySeconds

C.spec.strategy.rollingUpdate.maxSurge

D.spec.replicas

AnswerA

Setting `spec.strategy.rollingUpdate.maxUnavailable` to 2 directly caps how many Pods may be unavailable mid-rollout, satisfying the stem's constraint. The Deployment's default RollingUpdate strategy already replaces Pods incrementally, so this field governs the disruption ceiling; `maxSurge` instead controls extra Pods created above the replica count.

Why this answer

The `maxUnavailable` field in `spec.strategy.rollingUpdate.maxUnavailable` specifies the maximum number of Pods that can be unavailable during a rolling update. Setting it to 2 allows up to 2 Pods to be taken down at a time, ensuring that at least 1 Pod remains available (since the Deployment has 3 replicas). This field directly controls the availability tolerance during the update process.

Exam trap

The trap here is that candidates often confuse `maxUnavailable` with `maxSurge`, mistakenly thinking that `maxSurge` controls how many Pods can be down, when in fact `maxSurge` controls how many extra Pods can be created above the desired count.

How to eliminate wrong answers

Option B is wrong because `spec.minReadySeconds` controls how long a newly created Pod must be ready before it is considered available, but it does not limit the number of Pods that can be unavailable during an update. Option C is wrong because `spec.strategy.rollingUpdate.maxSurge` controls the maximum number of Pods that can be created above the desired replica count during an update, not the number of Pods that can be unavailable. Option D is wrong because `spec.replicas` sets the desired number of Pods for the Deployment, but it does not control the availability constraints during a rolling update.

Full explanation →

100

MCQmedium

You have a Pod with a container that needs to read sensitive data such as a database password. Which Kubernetes resource should you use to store this data?

A.PersistentVolume

B.Secret

C.ServiceAccount

D.ConfigMap

AnswerB

Secrets store sensitive data such as database passwords separately from Pod specifications and container images, base64-encoding values for API transport. Mounting a Secret as a volume or exposing it through environment variables lets the container read the credential at runtime without hard-coding it, satisfying the requirement to hold sensitive data securely.

Why this answer

A Secret is the correct Kubernetes resource for storing sensitive data like database passwords because it encodes the data in base64 and is designed to be consumed by Pods via environment variables or volume mounts. Unlike ConfigMaps, Secrets are intended for confidential information and can be encrypted at rest using etcd encryption providers or KMS.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, thinking both are interchangeable for configuration, but Secrets are the only resource intended for sensitive data, while ConfigMaps are for non-sensitive plaintext data.

How to eliminate wrong answers

Option A is wrong because a PersistentVolume is a storage abstraction for persistent data (e.g., files, databases), not for storing sensitive configuration like passwords; it lacks built-in mechanisms for confidentiality or encoding. Option C is wrong because a ServiceAccount is an identity resource used for Pod-to-API authentication and RBAC, not for storing arbitrary secret data. Option D is wrong because a ConfigMap stores non-sensitive configuration data in plain text and is not designed for secrets; using it for passwords would expose them in clear text in etcd and logs.

Full explanation →

101

MCQmedium

Which of the following is a benefit of using container orchestration platforms like Kubernetes?

A.Increased network latency

B.Manual scaling of applications

C.Self-healing (automatic restart of failed containers)

D.Tighter coupling between microservices

AnswerC

Kubernetes continuously reconciles desired state against actual state via its control loop; when a container or node fails, the ReplicaSet controller recreates the pod automatically. This self-healing restarts failed containers without human intervention, directly delivering the availability benefit the question asks about.

Why this answer

Kubernetes includes a built-in controller (the kubelet and ReplicaSet controller) that continuously monitors the desired state of pods. If a container fails or its process crashes, the kubelet automatically restarts it based on the pod's restart policy (e.g., Always), ensuring high availability without manual intervention. This self-healing capability is a core benefit of container orchestration, reducing downtime and operational overhead.

Exam trap

CNCF often tests the misconception that container orchestration platforms like Kubernetes increase complexity and latency, but the correct answer highlights that they actually automate recovery and improve resilience, not degrade performance.

How to eliminate wrong answers

Option A is wrong because container orchestration platforms like Kubernetes typically reduce network latency through service discovery and intelligent load balancing (e.g., kube-proxy with iptables/IPVS), not increase it. Option B is wrong because Kubernetes enables automatic scaling via Horizontal Pod Autoscaler (HPA) based on CPU/memory metrics or custom metrics, eliminating the need for manual scaling. Option D is wrong because Kubernetes promotes loose coupling between microservices through declarative APIs, service abstractions (ClusterIP), and decoupled communication patterns, not tighter coupling.

Full explanation →

102

MCQhard

In Istio, which component is responsible for enforcing traffic policies and collecting telemetry data at the pod level?

A.Mixer

B.Envoy proxy

C.Pilot

D.Citadel

AnswerB

Envoy is the sidecar proxy injected into each pod, and it is the data-plane component that applies the traffic policies pushed by istiod and emits the telemetry (metrics, logs, traces) for that workload. This satisfies the pod-level enforcement and collection requirement.

Why this answer

Envoy proxy is the correct answer because in Istio, each pod is deployed with an Envoy sidecar proxy that intercepts all inbound and outbound traffic. This proxy enforces traffic policies (e.g., routing rules, fault injection, rate limiting) and collects telemetry data (e.g., metrics, logs, traces) at the pod level, sending it to the observability backends. The sidecar model ensures policy enforcement and telemetry collection happen without modifying the application code.

Exam trap

CNCF often tests the misconception that Mixer is still the primary policy enforcement and telemetry component, but the trap here is that Mixer was deprecated and removed; candidates who haven't kept up with Istio's evolution may incorrectly select Mixer (Option A) instead of recognizing that Envoy now handles both roles via in-proxy extensions.

How to eliminate wrong answers

Option A is wrong because Mixer was a separate Istio component responsible for access control and telemetry preprocessing, but it was deprecated in Istio 1.5 and removed in later versions; telemetry and policy enforcement are now handled directly by Envoy proxies via WebAssembly extensions and the Telemetry API. Option C is wrong because Pilot is the control plane component that translates high-level traffic rules into Envoy configuration (e.g., xDS APIs) and distributes them to proxies, but it does not enforce policies or collect telemetry at the pod level. Option D is wrong because Citadel is the security component that manages certificate issuance and mTLS key rotation (using SPIFFE identities), but it does not handle traffic policy enforcement or telemetry collection.

Full explanation →

103

Multi-Selectmedium

Which TWO of the following are benefits of using a container orchestration platform like Kubernetes? (Select 2)

Select 2 answers

A.Manual deployment of containers to servers

B.Requirement for a hypervisor on every node

C.Self-healing of failed containers

D.Static infrastructure that never changes

E.Automatic scaling of applications based on demand

AnswersC, E

Kubernetes continuously reconciles desired state against actual state, restarting or rescheduling containers whose liveness probes fail or whose nodes die. This automated remediation removes manual intervention, directly delivering the self-healing benefit the question asks you to identify.

Why this answer

Option C is correct because Kubernetes continuously reconciles desired state with actual state: its controllers (e.g., ReplicaSet, Deployment) detect crashed or unhealthy pods via liveness/readiness probes and restart or reschedule them, providing self-healing. Option E is correct because Kubernetes supports automatic scaling through the Horizontal Pod Autoscaler (HPA), which adjusts replica counts based on metrics such as CPU utilization or custom metrics, and the Cluster Autoscaler, which adds or removes nodes as demand changes. Option A is wrong because orchestration automates container scheduling and deployment rather than requiring manual placement.

Option B is wrong because Kubernetes runs containers via a container runtime (containerd, CRI-O) on each node and does not require a hypervisor. Option D is wrong because orchestration platforms are designed for dynamic, declarative infrastructure that changes as workloads and scaling demands evolve.

Exam trap

A common misconception is that container orchestration requires hypervisors or static infrastructure, but the correct understanding is that Kubernetes abstracts the underlying hardware and provides dynamic, self-healing, and auto-scaling capabilities without hypervisors.

Full explanation →

104

Multi-Selectmedium

Which TWO of the following are valid Kubernetes resource types that can be used to store configuration data or secrets?

Select 2 answers

A.Secret

B.Volume

C.PersistentVolumeClaim

D.ServiceAccount

E.ConfigMap

AnswersA, E

Secret is a native Kubernetes object storing sensitive data such as passwords, tokens and certificates, base64-encoded and mounted as volumes or environment variables. It satisfies the configuration-data-or-secrets constraint alongside ConfigMap, keeping credentials separate from pod specifications.

Why this answer

Option A (Secret) is correct because a Secret is a native Kubernetes API object specifically designed to hold sensitive configuration data such as passwords, tokens, and TLS keys, storing values as base64-encoded data or stringData. Option E (ConfigMap) is correct because a ConfigMap is the standard Kubernetes resource for storing non-confidential configuration data as key-value pairs that pods can consume via environment variables, command-line arguments, or mounted files. Option B (Volume) is not a configuration store; it is an abstraction for storage that a pod mounts, and while a ConfigMap or Secret can be projected into a Volume, the Volume itself holds filesystem data, not configuration objects.

Option C (PersistentVolumeClaim) is a request for persistent storage bound to a PersistentVolume, used for durable data rather than configuration or secret storage. Option D (ServiceAccount) provides an identity for processes running in a pod and is used for RBAC authentication/authorization, not for storing arbitrary configuration data or secrets.

Exam trap

CNCF often tests the misconception that Volumes or PersistentVolumeClaims can store configuration data or secrets, but they are storage abstractions for arbitrary data, not the dedicated key-value resources (ConfigMap and Secret) designed for configuration and secrets management.

Full explanation →

105

MCQmedium

An administrator runs 'kubectl get pods' and sees that a pod named 'app-pod' is in 'CrashLoopBackOff'. They run 'kubectl logs app-pod' and see a segmentation fault error. What is the most likely cause?

A.The node is out of memory

B.The container has a configuration error

C.The application code has a bug

D.The readiness probe is misconfigured

AnswerC

A segmentation fault indicates the application process accessed invalid memory, which is a defect within the application code itself. CrashLoopBackOff results because Kubernetes repeatedly restarts the container after each crash, confirming the code bug as the cause.

Why this answer

A segmentation fault (segfault) is a specific error caused by a program attempting to access memory it does not have permission to access, typically due to a bug in the application code (e.g., null pointer dereference, buffer overflow). Since the container starts but then crashes repeatedly (CrashLoopBackOff), the segfault indicates the application itself is failing, not the infrastructure or configuration. This is the most direct cause of the pod entering CrashLoopBackOff.

Exam trap

CNCF often tests the distinction between application-level errors (like segfaults) and infrastructure or configuration issues, tempting candidates to blame resource constraints or probe misconfiguration when the logs clearly point to a runtime crash.

How to eliminate wrong answers

Option A is wrong because a node out-of-memory condition would cause the pod to be evicted or fail to schedule, not produce a segmentation fault in the application logs; the kubelet would report an OOMKilled status, not a segfault. Option B is wrong because a configuration error (e.g., missing environment variable, incorrect command) would typically result in an immediate container exit with a non-zero exit code or a startup failure, not a segmentation fault which is a runtime memory access violation. Option D is wrong because a misconfigured readiness probe would cause the pod to be marked as not ready and removed from service endpoints, but the container would continue running and not crash; the logs would show probe failures, not a segfault.

Full explanation →

106

Multi-Selectmedium

Which TWO statements about GitOps are correct?

Select 2 answers

A.GitOps requires a container registry

B.Git is the single source of truth for desired system state

C.The cluster state is automatically reconciled with the Git repository

D.GitOps eliminates the need for CI pipelines

E.Changes are made directly to the cluster using kubectl

AnswersB, C

Git stores the declarative desired state, and an automated controller continuously reconciles the live cluster towards that committed state, satisfying GitOps's requirement for a single authoritative source. This enables versioned, auditable changes and rollback via Git history, rather than imperative cluster commands.

Why this answer

Option B is correct because GitOps fundamentally uses Git as the single source of truth: the desired state of the system (manifests, Helm charts, Kustomize overlays) is declaratively stored and versioned in a Git repository, and that repository is the authoritative reference for what should be deployed. Option C is correct because a GitOps operator (such as Argo CD or Flux) continuously watches the Git repository and the cluster, automatically reconciling the live cluster state to match the desired state declared in Git, correcting any drift. Option A is not required: GitOps can deploy non-containerized resources and does not mandate a container registry, though one is often used alongside it.

Option D is wrong because CI pipelines are still needed to build, test, and produce artifacts, even though GitOps handles the continuous delivery/deployment portion. Option E is wrong because GitOps explicitly forbids direct imperative changes via kubectl; all changes must flow through Git commits and pull requests so the repository remains the source of truth.

Exam trap

KCNA often tests the misconception that GitOps is synonymous with CI/CD or requires specific tooling like container registries, when the defining characteristics are simply Git as source of truth and automated reconciliation.

Full explanation →

107

MCQhard

In a microservices application, you want to prevent cascading failures by limiting the number of concurrent requests to a downstream service. Which resilience pattern should you implement?

A.Circuit breaker

B.Timeout pattern

C.Bulkhead pattern

D.Retry pattern

AnswerC

The bulkhead pattern isolates resources into separate pools, so each downstream service receives a bounded number of concurrent requests. When one service saturates its pool, others continue unaffected, preventing the cascading failure the stem describes. Circuit breaking and retries address different failure modes.

Why this answer

The bulkhead pattern isolates resources by limiting the number of concurrent calls to a downstream service, so that a slow or failing dependency cannot exhaust the caller's thread pool or connection pool and cause cascading failures. In microservices, bulkheads partition thread pools, connection pools, or instances per dependency (e.g., Hystrix thread pool isolation), so one degraded service only saturates its own compartment. This directly matches the requirement of limiting concurrent requests to a downstream service.

Exam trap

KCNA often tests the confusion between bulkhead (limit concurrency/isolation) and circuit breaker (stop calls after failures); candidates pick circuit breaker because both address cascading failures, but only bulkhead limits concurrent requests.

How to eliminate wrong answers

Option A is wrong because a circuit breaker trips after a failure threshold is reached and stops calls entirely; it reacts to failures rather than limiting concurrency to prevent resource exhaustion. Option B is wrong because a timeout only bounds how long a single call waits before being abandoned; it does not cap the number of concurrent in-flight requests. Option D is wrong because retry re-attempts failed calls, which actually increases load on a struggling downstream service and can worsen cascading failures.

Full explanation →

108

MCQhard

An administrator manages a cluster where a Namespace named 'analytics' contains a ResourceQuota that limits pods to 10. A developer applies a manifest containing a ReplicaSet with replicas: 12 in that Namespace. The ReplicaSet controller creates the first 10 Pods successfully, but the remaining 2 Pods are rejected. Which statement best describes what the developer will observe and why?

A.The ReplicaSet scales itself down to 10 replicas and reports a status condition indicating the quota was exceeded.

B.The ReplicaSet status shows fewer ready replicas than desired, and the events for the ReplicaSet include quota-related failures for the denied Pods.

C.The API server accepts all 12 Pods but marks 2 of them with a Failed phase due to the quota, and the ReplicaSet ignores those Pods.

D.The 2 extra Pods are created but remain in a Pending state until quota becomes available, and the ReplicaSet reports 12 ready replicas.

AnswerB

When a ResourceQuota is exceeded, the API server rejects the Pod create request during admission, so only 10 Pods exist. The ReplicaSet controller keeps reconciling toward 12 and records warning events such as 'FailedCreate' with a message about exceeding quota. Its status shows ready and available replicas below the desired count, which matches this observation.

Why this answer

ResourceQuota is enforced by an admission controller in the API server, so Pod creation requests beyond the allowed count are rejected outright. The ReplicaSet controller continues to reconcile toward 12 replicas, records FailedCreate events describing the quota violation, and reports status with fewer ready replicas than desired. No extra Pod objects are persisted, and the ReplicaSet spec is not automatically lowered.

Exam trap

The trap here is believing that quota-denied Pods are created in a Pending or Failed phase, when they are actually rejected before being stored.

Full explanation →

109

Matchingmedium

Match each Kubernetes object to its typical use case.

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

Concepts

Matches

Ensures a copy of a pod runs on all or selected nodes

Manages stateful applications with unique network identities

Runs a finite task to completion

Runs jobs on a time-based schedule

Automatically scales pod replicas based on CPU/memory metrics

Why these pairings

Correct matches: Deployment manages stateless apps with rolling updates; StatefulSet handles stateful apps with stable identities; DaemonSet runs a pod on every node. Common confusions: mixing Deployment with DaemonSet (one per node vs. stateless management) and StatefulSet with Jobs (stateful vs. batch).

Full explanation →

110

MCQeasy

Which deployment strategy updates pods incrementally, replacing old pods with new ones while ensuring availability?

A.Canary deployment

B.Blue-green deployment

C.Recreate

D.Rolling update

AnswerD

A rolling update replaces pods incrementally, using maxSurge and maxUnavailable to keep a portion of old replicas serving traffic until new ones pass readiness checks. This satisfies the availability constraint by avoiding the downtime a recreate strategy would cause.

Why this answer

The Rolling update strategy is the correct answer because it incrementally replaces old pods with new ones while maintaining application availability. In Kubernetes, a rolling update updates pods one by one (or in small batches), ensuring that a specified number of pods remain available throughout the process. This is achieved by gradually scaling down the old ReplicaSet and scaling up the new one, controlled by parameters like `maxSurge` and `maxUnavailable` in the Deployment spec.

Exam trap

CNCF often tests the distinction between deployment strategies by confusing candidates with 'Canary deployment' because it also involves gradual traffic shifting, but the key difference is that Canary does not replace pods incrementally—it runs both versions concurrently and requires external traffic routing.

How to eliminate wrong answers

Option A is wrong because a Canary deployment routes a small percentage of traffic to a new version before a full rollout, but it does not incrementally replace pods; it runs both versions simultaneously and requires traffic management (e.g., via a service mesh or ingress). Option B is wrong because a Blue-green deployment creates a completely new environment (green) alongside the old one (blue) and switches traffic all at once, rather than updating pods incrementally. Option C is wrong because the Recreate strategy terminates all old pods before creating new ones, causing downtime and violating the availability requirement.

Full explanation →

111

Multi-Selecteasy

Which TWO of the following are valid ways to view the logs of a pod named 'my-pod'?

Select 2 answers

A.kubectl describe pod my-pod

B.kubectl exec my-pod -- cat /var/log/app.log

C.kubectl logs my-pod

D.kubectl run my-pod -- logs

E.kubectl attach my-pod

AnswersB, C

kubectl exec runs a command inside the container, so cat reads the application's log file directly from the container filesystem. This satisfies the stem's requirement for a valid way to view my-pod's logs, though it depends on the file path existing and the container including cat.

Why this answer

Option B is correct because kubectl exec my-pod -- cat /var/log/app.log runs the cat command inside the container of the pod, directly reading the application log file at that path, which is a valid way to view logs when the app writes to a file rather than stdout. Option C is correct because kubectl logs my-pod retrieves the stdout/stderr output captured by the container runtime for the pod's (default) container, which is the standard Kubernetes logging mechanism. Option A is not a log-viewing method: kubectl describe pod my-pod shows metadata, status, events, and container specs, not the application's log stream.

Option D is invalid syntax and semantics: kubectl run creates a new pod from an image and does not accept a 'logs' subcommand to read an existing pod's logs. Option E is wrong because kubectl attach my-pod attaches the terminal to a running container's process (stdin/stdout of PID 1), which is interactive and not a log-retrieval command.

Exam trap

The trap here is that candidates may confuse `kubectl describe` (which shows pod events and status) with `kubectl logs` (which shows actual application output), or assume `kubectl attach` can retrieve past logs when it only connects to the live process stream.

Full explanation →

112

MCQhard

You have a Deployment with three replicas. You want to update the container image but ensure that only one pod is updated at a time, and the update proceeds only if the new pod becomes healthy. Which update strategy should you configure?

A.RollingUpdate with maxSurge=3 and maxUnavailable=1

B.RollingUpdate with maxSurge=1 and maxUnavailable=0

C.Canary deployment via Ingress

D.Recreate strategy

AnswerB

RollingUpdate with maxSurge=1 and maxUnavailable=0 replaces pods incrementally: one new pod is created while all existing replicas stay available, and the rollout advances only once that pod passes its readiness probe. This satisfies the constraints of updating a single pod at a time and gating progress on new-pod health.

Why this answer

A RollingUpdate strategy with maxSurge=1 and maxUnavailable=0 ensures that exactly one new pod is created before any old pod is terminated, and the update only proceeds when the new pod passes its readiness probe (i.e., becomes healthy). This guarantees that at all times during the update, the desired number of replicas (3) are available, and only one pod is updated at a time, matching the requirement.

Exam trap

In the KCNA exam, candidates often misinterpret that maxSurge controls the number of pods updated at a time, when in reality it controls the number of extra pods allowed above the desired count, while maxUnavailable controls the number of pods that can be unavailable during the update; candidates may incorrectly choose Option A thinking maxSurge=1 means one pod at a time, but maxSurge=3 allows three new pods to be created simultaneously, violating the 'only one pod updated at a time' constraint.

How to eliminate wrong answers

Option A is wrong because maxSurge=3 allows up to 3 extra pods to be created simultaneously, which could update multiple pods at once, violating the 'only one pod updated at a time' constraint. Option C is wrong because a Canary deployment via Ingress is a traffic-splitting technique that routes a percentage of traffic to a new version, but it does not inherently control pod update ordering or ensure that only one pod is updated at a time; it is a higher-level routing strategy, not a Deployment update strategy. Option D is wrong because the Recreate strategy terminates all existing pods before creating new ones, causing downtime and violating the requirement that the update proceeds only if the new pod becomes healthy (since all pods are replaced simultaneously).

Full explanation →

113

Multi-Selectmedium

Which THREE of the following are valid ways to create a Kubernetes resource using kubectl?

Select 3 answers

A.kubectl exec -it pod-name -- /bin/bash

B.kubectl run nginx --image=nginx

C.kubectl logs pod-name

D.kubectl create -f pod.yaml

E.kubectl apply -f deployment.yaml

AnswersB, D, E

`kubectl run` creates a Pod imperatively, satisfying the stem's requirement for a valid resource-creation method. It submits the resource directly to the API server without a manifest file, unlike declarative `kubectl apply -f`. This imperative approach works for Pods, though newer kubectl versions restrict it to that resource type.

Why this answer

Option B (kubectl run nginx --image=nginx) is correct because kubectl run creates a new resource (historically a Pod, and in newer versions a Pod via the run command) directly from the command line using the specified container image. Option D (kubectl create -f pod.yaml) is correct because kubectl create is an imperative command that builds a resource from a manifest file, here a Pod defined in pod.yaml. Option E (kubectl apply -f deployment.yaml) is correct because kubectl apply declaratively creates or updates the resource defined in deployment.yaml, making it a valid way to create a Kubernetes resource.

Option A (kubectl exec -it pod-name -- /bin/bash) is incorrect because exec opens an interactive shell inside an existing container and does not create any resource. Option C (kubectl logs pod-name) is incorrect because logs only retrieves container log output from an existing Pod and has no resource-creation capability.

Exam trap

CNCF often tests the distinction between commands that create resources versus commands that interact with existing resources, so candidates may mistakenly think `kubectl exec` or `kubectl logs` can create resources because they are common kubectl commands.

Full explanation →

114

MCQmedium

A DevOps engineer has created a ConfigMap named 'app-config' and wants to use it to set environment variables in a pod. Which field in the pod spec should reference the ConfigMap?

A.spec.containers[].command

B.spec.containers[].env.name

C.spec.containers[].volumeMounts

D.spec.containers[].envFrom

AnswerD

envFrom bulk-imports every key-value pair from the referenced ConfigMap as environment variables, matching the goal of setting variables from 'app-config'. The env field only maps individual keys via valueFrom, so it cannot consume the whole ConfigMap in one reference.

Why this answer

`spec.containers[].envFrom` allows you to inject all key-value pairs from a ConfigMap (or Secret) as environment variables into a container in a single declaration. This field supports a `configMapRef` that references the ConfigMap by name, making it the appropriate spec field for bulk environment variable injection.

Exam trap

The trap here is that candidates confuse `envFrom` (bulk injection) with `env[].valueFrom.configMapKeyRef` (single key injection) or think `volumeMounts` can set environment variables, when it only mounts data as files.

How to eliminate wrong answers

Option A is wrong because `spec.containers[].command` defines the container's entrypoint command, not environment variables; it cannot reference a ConfigMap. Option B is wrong because `spec.containers[].env.name` is only the key name within an individual `env` entry; the ConfigMap reference would go in `env[].valueFrom.configMapKeyRef`, not in `name`. Option C is wrong because `spec.containers[].volumeMounts` is used to mount ConfigMaps as files or directories in the container's filesystem, not to set environment variables.

Full explanation →

115

MCQeasy

Which service mesh component is typically deployed as a sidecar proxy alongside application containers?

A.Kiali

B.Istiod

C.Prometheus

D.Envoy proxy

AnswerD

Envoy is the data-plane proxy that service meshes such as Istio inject as a sidecar container beside each application pod. It intercepts inbound and outbound traffic to enforce routing, mTLS and telemetry policies, satisfying the sidecar proxy role described.

Why this answer

Envoy proxy is the most common sidecar proxy in service meshes like Istio and Linkerd. Istiod is the control plane component, Kiali is a visualization tool, and Prometheus is a monitoring system.

Full explanation →

116

MCQmedium

An administrator wants to update the image of a Deployment named 'my-app' from 'nginx:1.19' to 'nginx:1.20' with a rolling update strategy. They want to ensure that during the update, the number of unavailable pods never exceeds 1. Which field should they set in the Deployment spec?

A.spec.replicas

B.spec.minReadySeconds

C.spec.strategy.rollingUpdate.maxSurge

D.spec.strategy.rollingUpdate.maxUnavailable

AnswerD

maxUnavailable caps how many replicas may be unavailable during a rolling update, so setting it to 1 guarantees availability never drops below desired minus one. maxSurge instead controls extra pods created above the desired count.

Why this answer

`spec.strategy.rollingUpdate.maxUnavailable` controls the maximum number of Pods that can be unavailable during a rolling update. Setting this to 1 ensures that at most one Pod is unavailable at any time, meeting the administrator's requirement. This field is part of the Deployment's rolling update strategy and directly governs the availability guarantee during the update process.

Exam trap

The trap here is that candidates often confuse `maxSurge` with `maxUnavailable`, mistakenly thinking that controlling how many extra Pods are created (surge) also limits unavailable Pods, but `maxSurge` only caps the number of Pods above the desired count, not the number that can be unavailable.

How to eliminate wrong answers

Option A is wrong because `spec.replicas` defines the desired number of Pod replicas, not the availability constraints during an update. Option B is wrong because `spec.minReadySeconds` controls how long a newly created Pod must be ready before it is considered available, but it does not limit the number of unavailable Pods during a rolling update. Option C is wrong because `spec.strategy.rollingUpdate.maxSurge` controls the maximum number of Pods that can be created above the desired replica count during an update, not the number of unavailable Pods.

Full explanation →

117

MCQeasy

What is the primary purpose of a continuous integration (CI) pipeline in cloud native application delivery?

A.To provision infrastructure resources

B.To automatically deploy code to production

C.To build and test code changes automatically

D.To manage container images in a registry

AnswerC

A CI pipeline automatically builds and tests each code change on commit, giving fast feedback on integration errors and regressions. This satisfies the stem's cloud native delivery scenario, where frequent small merges require automated verification rather than manual, release-time testing.

Why this answer

CI automates building and testing code changes to catch integration issues early, ensuring that code is always in a deployable state.

Full explanation →

118

MCQhard

A Deployment is configured with 'replicas: 5' and a rolling update strategy. During an update, you notice that the number of available pods drops to 3 momentarily. Which field in the Deployment spec can be adjusted to control the minimum number of pods available during a rolling update?

A.spec.strategy.rollingUpdate.maxSurge

B.spec.strategy.rollingUpdate.maxUnavailable

C.spec.minReadySeconds

D.spec.replicas

AnswerB

maxUnavailable sets how many replicas may be unavailable during a rolling update, directly governing the floor of available pods. Lowering it from the default 25% (which permits 3 of 5) to 0 or 1 keeps at least 4 pods serving throughout the rollout.

Why this answer

`spec.strategy.rollingUpdate.maxUnavailable` defines the maximum number (or percentage) of Pods that can be unavailable during a rolling update. With `replicas: 5`, setting `maxUnavailable: 2` would allow at most 2 Pods to be unavailable at any time, ensuring that at least 3 Pods remain available — which matches the observed drop to 3. This field directly controls the minimum number of available Pods during the update process.

Exam trap

The exam often tests the distinction between `maxSurge` and `maxUnavailable` by describing a scenario where Pods drop below the desired count, leading candidates to mistakenly choose `maxSurge` because they confuse 'extra Pods above desired' with 'minimum Pods available'.

How to eliminate wrong answers

Option A is wrong because `maxSurge` controls the maximum number of Pods that can be created above the desired replica count during a rolling update, not the minimum number of available Pods. Option C is wrong because `minReadySeconds` defines the minimum duration a Pod must be ready before it is considered available, but it does not control the number of Pods that can be unavailable during the update. Option D is wrong because `spec.replicas` sets the desired number of Pods for the Deployment, but it does not control the availability constraints during a rolling update; it only defines the target count.

Full explanation →

119

MCQhard

You need to deploy a batch job that processes a queue and runs to completion. The job should run exactly once and create exactly one pod per work item, but some items may fail. Which Kubernetes resource is best suited?

A.Deployment

B.Job

C.CronJob

D.DaemonSet

AnswerB

A Job creates one or more pods that run to completion, tracking successful completions and retrying failed pods until the specified count succeeds. This matches the batch queue-processing requirement where each work item runs exactly once and failures are retried.

Why this answer

A Kubernetes Job is the correct resource for batch processing tasks that run to completion, such as processing a queue where each work item corresponds to a pod. By configuring the `.spec.completions` and `.spec.parallelism` fields, you can ensure exactly one pod per work item and control concurrency. The Job automatically retries failed pods (up to a configurable limit) without restarting the entire batch, making it ideal for handling some failures.

In contrast, a Deployment (A) is for long-running, continuously available services; a CronJob (C) is for scheduled recurring jobs; and a DaemonSet (D) runs a pod on every node for infrastructure tasks. Therefore, Job (B) is the best fit.

Exam trap

The KCNA exam often tests the distinction between batch and long-running workloads, and the trap here is that candidates may confuse a Job with a Deployment because both can create multiple pods, but a Deployment is designed for continuous availability, not one-time execution.

How to eliminate wrong answers

Option A is wrong because a Deployment is intended for long-running, stateless applications that maintain a desired number of replicas, not for batch jobs that run to completion; it would restart pods indefinitely, violating the 'run exactly once' requirement. Option C is wrong because a CronJob schedules Jobs on a time-based schedule, but the question specifies a one-time batch job that processes a queue and runs to completion, not a recurring task. Option D is wrong because a DaemonSet ensures exactly one pod runs on each node in the cluster, which is used for node-level services like logging or monitoring, not for processing a queue with one pod per work item.

Full explanation →

120

MCQmedium

A company wants to adopt immutable infrastructure for its containerized applications. Which practice BEST exemplifies immutability?

A.Developers use kubectl exec to change environment variables in a running pod

B.When a container fails, the orchestrator terminates it and launches a new container from the same image

C.A configuration management tool runs periodically to ensure containers are up-to-date

D.An operator logs into a running container and applies a security patch with apt-get update

AnswerB

Immutability means containers are never patched or modified in place. Terminating the failed container and starting a fresh one from the identical image preserves the immutable artefact, satisfying the constraint that running instances are replaced rather than mutated.

Why this answer

Immutable infrastructure means that once a container is deployed from a specific image, it is never modified in place. When a container fails, the orchestrator (e.g., Kubernetes) terminates it and launches a new container from the same image, ensuring consistency and reproducibility. This approach eliminates configuration drift and aligns with the principle that all changes should be made by rebuilding the image, not by altering running instances.

Exam trap

The trap here is that candidates confuse immutability with automation, thinking that any automated update (like a config management tool) is acceptable, when in fact immutability in Kubernetes requires that no changes are made to running containers — only new images are deployed via rolling updates or similar mechanisms.

How to eliminate wrong answers

Option A is wrong because using kubectl exec to change environment variables in a running pod directly modifies the container's state, violating immutability by introducing runtime changes that are not captured in the image. Option C is wrong because a configuration management tool that runs periodically to update containers implies in-place modifications, which contradicts the immutable model where updates should come from deploying new images. Option D is wrong because logging into a running container and applying a security patch with apt-get update mutates the container's filesystem, creating a snowflake server that cannot be reliably reproduced from the original image.

Full explanation →

121

Multi-Selecthard

A company is adopting cloud-native architecture and wants to improve the resilience of its applications. Which TWO of the following are core principles of cloud-native architecture that directly contribute to resilience? (Choose two.)

Select 2 answers

A.Store all application state in a single centralized database.

B.Design for failure and automate recovery.

C.Manually scale resources based on peak load forecasts.

D.Use monolithic deployments to simplify troubleshooting.

E.Implement observability with metrics, logs, and traces.

AnswersB, E

Designing for failure means assuming that components will fail and building systems that can detect and recover from failures automatically. This principle directly enhances resilience by minimizing downtime and manual intervention. It is a fundamental tenet of cloud-native architecture, often implemented through health checks, self-healing, and chaos engineering.

Why this answer

Designing for failure and automating recovery, along with implementing observability, are core cloud-native principles that directly enhance resilience. Designing for failure ensures that systems can withstand component outages and recover automatically, while observability provides the visibility needed to detect and respond to issues. Together, they enable applications to maintain availability and performance in dynamic environments.

Exam trap

The trap here is assuming that manual scaling or centralized databases contribute to resilience, when they actually increase fragility.

Full explanation →

122

MCQeasy

Which Kubernetes component is responsible for ensuring that the desired number of pod replicas is running in the cluster?

A.kubelet

B.kube-scheduler

C.kube-controller-manager

D.kube-apiserver

AnswerC

The kube-controller-manager runs the ReplicaSet controller, which continuously reconciles observed pod counts against the desired replica count declared in the spec. Kubelet manages containers on individual nodes, and the scheduler only assigns pending pods to nodes; neither maintains replica totals.

Why this answer

The kube-controller-manager runs controller processes, including the Replication Controller, which is responsible for ensuring that the desired number of pod replicas are running at all times. It watches the current state via the API server and takes corrective actions (e.g., creating or deleting pods) to match the desired replica count defined in the ReplicaSet or Deployment.

Exam trap

The trap here is that candidates often confuse the kube-scheduler's role of placing pods with the controller-manager's role of maintaining the desired count, leading them to select the scheduler when the question is about replica management.

How to eliminate wrong answers

Option A is wrong because kubelet is the node agent that runs on each worker node and ensures containers are running in a pod, but it does not manage replica counts across the cluster. Option B is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for maintaining replica counts. Option D is wrong because kube-apiserver is the front-end for the Kubernetes control plane, handling RESTful API requests and validation, but it does not actively enforce desired replica counts.

Full explanation →

123

MCQmedium

Which Kubernetes object can be used to store sensitive data, such as passwords or API keys, and inject them into pods?

A.PersistentVolume

B.ServiceAccount

C.Secret

D.ConfigMap

AnswerC

Secrets store sensitive values such as passwords and API keys as base64-encoded data, kept separate from the image. They can be mounted as volumes or exposed as environment variables, satisfying the requirement to inject credentials into pods without embedding them in the container.

Why this answer

A Secret is the dedicated Kubernetes object for storing sensitive data like passwords, API keys, and tokens. Secrets store data as base64-encoded strings and can be injected into pods as environment variables or mounted as volumes, with optional encryption at rest via etcd or KMS.

Exam trap

The trap is that candidates might think ConfigMap is appropriate for secrets because it also injects data into pods, but ConfigMap stores data in plaintext (base64 is encoding, not encryption) and is intended for non-sensitive configuration. Additionally, Secrets are not encrypted by default unless etcd encryption or KMS is configured, so they are not inherently secure.

How to eliminate wrong answers

Option A is wrong because a PersistentVolume is a storage abstraction for persistent data (e.g., NFS, iSCSI) and is not designed for injecting sensitive configuration into pods. Option B is wrong because a ServiceAccount provides an identity for pod-to-API-server authentication, not for storing or injecting secrets. Option D is wrong because a ConfigMap stores non-sensitive configuration data in plaintext (base64-encoded but not encrypted) and should not be used for passwords or API keys.

Full explanation →

124

MCQmedium

A Deployment is configured with 'replicas: 3'. After a node failure, only 2 pods are running. What component ensures that a new pod is scheduled to restore the desired replica count?

A.kube-scheduler

B.kube-controller-manager

C.kubelet

D.kube-proxy

AnswerB

The kube-controller-manager runs the ReplicaSet controller, whose reconciliation loop detects that observed replicas (2) fall below the desired count (3) and creates a replacement pod. The scheduler then places it, restoring the declared replica count after the node failure.

Why this answer

The kube-controller-manager runs the ReplicaSet controller, which detects the mismatch and creates a new pod.

Full explanation →

125

MCQhard

A user reports that they cannot connect to a database service named 'db-service' from another pod in the same namespace. The service selector matches the database pod's labels. Which command would you run FIRST to troubleshoot the service's endpoints?

A.kubectl describe pod db-service

B.kubectl get endpoints db-service

C.kubectl exec -it <some-pod> -- curl db-service

D.kubectl logs db-service

AnswerB

Checking endpoints first reveals whether the Service has any backing pod IPs. If the selector matches but endpoints are empty, the cause lies with pod readiness or port naming rather than connectivity, directing further troubleshooting efficiently.

Why this answer

`kubectl get endpoints db-service` directly shows whether the service has any endpoints (i.e., pod IPs) associated with it. If the endpoints list is empty, it indicates that the service's label selector is not matching any pods, which is the most common cause of connectivity failure. This is the fastest way to verify the fundamental prerequisite for service-to-pod traffic.

Exam trap

The trap here is that candidates often jump to connectivity tests (like curl) or pod logs, forgetting that the service must first have endpoints; the exam tests whether you know to verify the selector-to-pod match at the endpoint level before assuming network issues.

How to eliminate wrong answers

Option A is wrong because `kubectl describe pod db-service` would fail since 'db-service' is a service name, not a pod name; even if you used the correct pod name, describing a pod does not reveal the service's endpoint status. Option C is wrong because `kubectl exec -it <some-pod> -- curl db-service` tests connectivity from within the cluster, but it assumes the service already has endpoints; running this first could waste time if the issue is that no endpoints exist. Option D is wrong because `kubectl logs db-service` is invalid (logs require a pod name, not a service name) and even if applied to a pod, logs would not show the service's endpoint state.

Full explanation →

126

MCQmedium

You need to inspect the logs of a container named 'app' in a pod called 'web-1'. Which kubectl command should you use?

A.kubectl logs web-1 --container app

B.kubectl logs web-1 -c app

C.kubectl logs app web-1

D.kubectl logs -p web-1 app

AnswerB

Correct. The `-c` flag is the short form for `--container` and is the standard syntax shown in kubectl help. Both A and B are valid commands.

Why this answer

Option B is correct. The `kubectl logs` command uses the `-c` flag to specify a container within a multi-container pod. The pod name must be specified first, followed by the container flag.

Option A uses the long form `--container`, which is also valid syntax, but this single-choice question expects the short flag `-c` as the standard answer. Option C incorrectly places the container name as the first argument (kubectl logs app web-1). Option D uses the `-p` flag, which is for viewing logs of a previous container instance, not for selecting a container by name.

Exam trap

CNCF often tests the argument order of `kubectl logs` and the use of `-c` to specify a container. While `--container` is also a valid flag, the exam may expect the short flag `-c` when a single answer is required. Ensure the pod name comes before the container flag.

How to eliminate wrong answers

Option A is wrong because it uses the `--container` flag with an equals sign, which is syntactically incorrect; the correct flag is `-c` or `--container` followed by a space and the container name. Option C is wrong because it reverses the argument order, placing the container name before the pod name, which kubectl interprets as an attempt to fetch logs from a pod named 'app' with a container named 'web-1', leading to an error. Option D is wrong because the `-p` flag is used to get logs from a previous instance of a container (e.g., after a crash), not to specify the container name, and the argument order is incorrect.

Full explanation →

127

MCQeasy

A platform engineer runs `kubectl get pods -n web` and sees a pod stuck in the `Pending` phase. The pod's `nodeName` field is empty, and no events about image pulling appear. Which Kubernetes component is most directly responsible for assigning this pod to a node?

A.kubelet

B.kube-scheduler

C.kube-controller-manager

D.kube-proxy

AnswerB

The kube-scheduler watches for newly created pods that have no node assigned, then selects a suitable node based on resource requests, affinity rules, taints, and other constraints. Because the pod has an empty nodeName and is not yet running, the scheduler is the component that must bind it to a node before the kubelet on that node can start it.

Why this answer

A pod enters the Pending phase when it has been accepted by the API server but not yet bound to a node. The kube-scheduler continuously watches for such pods and selects a node that satisfies resource requests, affinity, taints, and tolerations. Once it binds the pod, the kubelet on that node takes over and starts the containers, moving the pod toward Running.

Exam trap

The trap here is assuming the kube-controller-manager places pods on nodes because it manages replica counts, when node binding is exclusively the kube-scheduler's responsibility.

Full explanation →

128

MCQmedium

Which of the following is a core component of the three pillars of observability?

A.Alerting

B.SLIs

C.Logs

D.Dashboards

AnswerC

Logs are one of the three pillars of observability, alongside metrics and traces. They record discrete, timestamped events with contextual detail, enabling retrospective debugging of why a system behaved as it did, which metrics and traces alone cannot fully explain.

Why this answer

The three pillars of observability are logs, metrics, and traces. Logs are discrete, timestamped records of events that provide detailed context about what happened in a system, making them a foundational pillar. Alerting, SLIs, and dashboards are downstream consumers or derived artifacts built on top of these pillars, not pillars themselves.

Exam trap

KCNA often tests whether candidates confuse observability data sources (logs, metrics, traces) with observability tooling and derived signals (dashboards, alerts, SLIs), so candidates who pick 'Alerting' or 'Dashboards' mistake consumption layers for foundational pillars.

How to eliminate wrong answers

Option A is wrong because alerting is a notification mechanism triggered by thresholds on metrics or logs — it is a consumer of observability data, not a source pillar. Option B is wrong because SLIs (Service Level Indicators) are quantitative measures of service performance derived from metrics, not a primary observability data type. Option D is wrong because dashboards are visualization layers that aggregate and display metrics, logs, and traces — they are presentation tooling, not a data pillar.

Full explanation →

129

MCQmedium

You have a Deployment running 3 replicas. You need to update the container image without downtime. Which command updates the image while performing a rolling update?

A.kubectl replace deployment my-deployment --image=nginx:1.25

B.kubectl set image deployment/my-deployment nginx=nginx:1.25

C.kubectl scale deployment my-deployment --image=nginx:1.25

D.kubectl update deployment my-deployment --image=nginx:1.25

AnswerB

kubectl set image patches the Deployment's pod template, triggering the default RollingUpdate strategy, which replaces pods incrementally so the 3-replica service stays available. It names the container (nginx) and new tag directly, satisfying the no-downtime constraint without editing YAML.

Why this answer

`kubectl set image` triggers a rolling update on the Deployment, updating the container image gradually without downtime. Kubernetes automatically manages the rollout by creating new Pods with the new image and terminating old ones, ensuring the desired replica count is maintained throughout the process.

Exam trap

The trap is that candidates may confuse `kubectl set image` with non-existent or incorrect commands like `kubectl update` or `kubectl replace`, or mistakenly think `kubectl scale` can change images. In Kubernetes, only `kubectl set image` (or `kubectl edit`/`kubectl apply` with a modified manifest) triggers a rolling update for container images.

How to eliminate wrong answers

Option A is wrong because `kubectl replace` is used to replace a resource from a file or stdin, not to update an image directly; it would require a full YAML/JSON definition and does not inherently perform a rolling update. Option C is wrong because `kubectl scale` only changes the replica count of a Deployment, not the container image; the `--image` flag is not valid for the scale command. Option D is wrong because `kubectl update` is not a valid kubectl command; the correct imperative command for updating images is `kubectl set image`.

Full explanation →

130

MCQeasy

Which component is the primary entry point for all administrative tasks and API requests in a Kubernetes control plane?

A.kube-apiserver

B.etcd

C.kube-scheduler

D.kube-controller-manager

AnswerA

kube-apiserver exposes the REST API that every administrative tool and internal component calls, validating and persisting objects to etcd. It is the sole entry point for kubectl requests and control-plane communication, satisfying the stem's requirement for the primary administrative entry point.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the only component that directly interacts with etcd. All administrative tasks (via kubectl), API requests from pods, and internal control plane components (scheduler, controller-manager) must pass through the kube-apiserver, which validates and processes them before persisting state or triggering actions.

Exam trap

A common misconception is that etcd is the primary entry point because it stores all cluster data, but the trap is that etcd is a backend storage layer with no direct API exposure to users or external components. The kube-apiserver is the only component that exposes the Kubernetes API and handles all administrative requests.

How to eliminate wrong answers

Option B (etcd) is wrong because etcd is a distributed key-value store used for persistent cluster state, not an entry point for API requests; it is accessed only by the kube-apiserver. Option C (kube-scheduler) is wrong because it only handles pod-to-node assignment decisions and does not expose an API endpoint for administrative tasks. Option D (kube-controller-manager) is wrong because it runs controller loops to maintain desired state but does not serve as an API gateway; it receives its instructions from the kube-apiserver.

Full explanation →

131

MCQhard

You create a Deployment with 'replicas: 3' and update the pod template to use a new image. After the rollout, you notice that the new ReplicaSet has 3 pods but they are all failing with 'CrashLoopBackOff'. You want to rollback to the previous working revision. Which command should you run?

A.kubectl set image deployment/my-deployment nginx=nginx:1.21

B.kubectl delete deployment/my-deployment --cascade=false

C.kubectl rollout undo deployment/my-deployment

D.kubectl rollout pause deployment/my-deployment

AnswerC

rollout undo reverts the Deployment to its previous ReplicaSet revision, restoring the last working image and clearing the CrashLoopBackOff caused by the bad template change. It directly satisfies the requirement to return to the prior working revision.

Why this answer

`kubectl rollout undo deployment/my-deployment` reverts the Deployment to the previous revision, which is the standard Kubernetes method to roll back a failed rollout. This command restores the pod template from the last working ReplicaSet, effectively undoing the change that caused the CrashLoopBackOff.

Exam trap

The trap here is that candidates confuse `kubectl rollout undo` with `kubectl set image` or `kubectl rollout pause`, thinking that manually setting the old image or pausing the rollout will revert the changes, but only `undo` actually triggers a rollback to a previous revision in the Deployment's history.

How to eliminate wrong answers

Option A is wrong because `kubectl set image deployment/my-deployment nginx=nginx:1.21` manually updates the image again, which does not roll back to a previous revision and may repeat the same failure if the new image is also broken. Option B is wrong because `kubectl delete deployment/my-deployment --cascade=false` deletes the Deployment but leaves its pods orphaned, which does not restore the previous working state and can cause resource leaks. Option D is wrong because `kubectl rollout pause deployment/my-deployment` only pauses the rollout, preventing further changes but not reverting to a previous working revision; the failing pods remain in CrashLoopBackOff.

Full explanation →

132

MCQhard

You have a Deployment with image: myapp:v1. You update the image to myapp:v2 using 'kubectl set image deployment/myapp myapp=myapp:v2'. The rollout status shows 'Waiting for rollout to finish: 0 out of 3 new replicas have been updated...'. What is the most likely cause of this behavior?

A.The command syntax is incorrect; you should use 'kubectl set image deployment/myapp myapp:v2'

B.The new Pods are crashing due to a missing command

C.The Deployment's update strategy is set to 'Recreate'

D.The new image myapp:v2 does not exist or cannot be pulled from the registry

AnswerD

New pods stay unscheduled or stuck in ImagePullBackOff when the container runtime cannot fetch myapp:v2, so no new replicas become ready and the rollout stalls at zero updated. A missing or inaccessible image tag directly explains the reported waiting status.

Why this answer

The rollout is stuck waiting for new replicas to become ready, which typically happens when the container image cannot be pulled. The message '0 out of 3 new replicas have been updated' indicates that the ReplicaSet is attempting to create Pods with the new image, but the Pods are failing to start. The most common cause is that the image tag 'myapp:v2' does not exist in the registry or cannot be accessed due to authentication or network issues, preventing the kubelet from pulling it.

Exam trap

The trap here is that candidates often assume a syntax error (Option A) or a Pod crash (Option B) when the real issue is a missing or inaccessible image, which is a common cause of stuck rollouts in Kubernetes.

How to eliminate wrong answers

Option A is wrong because the command syntax 'kubectl set image deployment/myapp myapp=myapp:v2' is correct; the format is 'container-name=image:tag', not 'deployment-name image:tag'. Option B is wrong because a missing command would cause a CrashLoopBackOff, not a stuck rollout with zero new replicas updated; the rollout would still show progress but with restart counts. Option C is wrong because the 'Recreate' strategy kills all old Pods before creating new ones, which would show 'Waiting for rollout to finish: 0 out of 3 new replicas have been updated...' only if the new Pods fail to start, but the message itself is typical of a RollingUpdate strategy that is stuck; 'Recreate' would not show this specific message because it does not update replicas incrementally.

Full explanation →

133

Multi-Selecthard

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

Select 3 answers

A.Ingress

B.NodePort

C.LoadBalancer

D.ClusterIP

E.ExternalName

AnswersA, B, C

Ingress defines HTTP and HTTPS routing rules that map external hostnames and paths to internal Services, satisfying layer-7 external exposure through a single entry point. An ingress controller such as NGINX must be deployed to fulfil those rules.

Why this answer

Ingress (A) is a valid method because it exposes HTTP/HTTPS routes from outside the cluster to Services within the cluster using an Ingress resource backed by an Ingress controller. NodePort (B) is valid because it exposes a Service on each node's IP at a static port in the 30000–32767 range, making it reachable externally via <NodeIP>:<NodePort>. LoadBalancer (C) is valid because it provisions an external load balancer (e.g., via a cloud provider) that routes external traffic to the Service, typically building on NodePort and ClusterIP.

ClusterIP (D) is not correct because it only exposes the Service on an internal cluster IP reachable solely within the cluster. ExternalName (E) is not correct because it merely maps a Service to an external DNS name via a CNAME record and does not expose or proxy external traffic to pods.

Exam trap

A common misconception is that ClusterIP can be used for external access because it has an IP address, but it is strictly internal unless combined with a proxy or port-forwarding mechanism.

Full explanation →

134

MCQmedium

Which Prometheus metric type is best suited to count the number of HTTP requests received?

A.Gauge

B.Histogram

C.Summary

D.Counter

AnswerD

Counters are monotonically increasing metrics that only go up or reset to zero on restart, making them ideal for cumulative counts such as total HTTP requests received. Use rate() or increase() to derive per-second request rates from the counter.

Why this answer

A Counter is a Prometheus metric type that represents a cumulative value that only increases (or resets to zero on restart). It is the correct choice for counting total HTTP requests received because the value monotonically increases over time. PromQL's rate() and increase() functions are designed to work with counters to compute per-second rates.

Exam trap

KCNA often tests the misconception that Histogram or Summary is needed for request counting because they also expose a _count — candidates overlook that Counter is the purpose-built type for monotonically increasing totals.

How to eliminate wrong answers

Option A is wrong because a Gauge represents a value that can go up or down arbitrarily (e.g., current memory usage or temperature) — it is not suitable for cumulative counts. Option B is wrong because a Histogram samples observations (like request durations) into configurable buckets and provides sum and count, but it is used for distributions, not simple request counting. Option C is wrong because a Summary is similar to a Histogram but calculates quantiles over a sliding time window on the client side — it is for latency/percentile tracking, not raw request counts.

Full explanation →

135

MCQmedium

A Deployment named 'myapp' is managing a ReplicaSet. You need to update the application image to version 2.0. What is the recommended approach?

A.Scale down the Deployment to 0 replicas, then scale up with the new image

B.Update the Deployment's pod template image to version 2.0

C.Delete the existing ReplicaSet and create a new one with the updated image

D.Directly update the pods in the ReplicaSet by using 'kubectl edit pod'

AnswerB

Editing the Deployment's pod template image triggers a rolling update: the Deployment controller creates a new ReplicaSet and scales it up while scaling the old one down, giving versioned, reversible rollouts rather than editing the ReplicaSet directly.

Why this answer

The recommended approach to update a Deployment's application image is to modify the pod template in the Deployment specification. The Deployment controller then automatically performs a rolling update, creating a new ReplicaSet with the updated image and gradually scaling down the old ReplicaSet, ensuring zero-downtime updates and maintaining desired replica count.

Exam trap

CNCF often tests the misconception that you must directly manipulate ReplicaSets or pods to update an application, when in fact the Deployment abstraction is designed to handle all updates through its pod template, and any direct changes to underlying resources are either reverted or break the declarative model.

How to eliminate wrong answers

Option A is wrong because scaling down to 0 replicas and then scaling up with a new image causes an unnecessary service disruption and does not leverage the Deployment's built-in rolling update mechanism, which is designed for seamless updates. Option C is wrong because manually deleting the existing ReplicaSet and creating a new one bypasses the Deployment controller's management, losing revision history and the ability to roll back; the Deployment should manage ReplicaSets automatically. Option D is wrong because directly editing pods in a ReplicaSet is ineffective, as the ReplicaSet controller will immediately revert any changes to match its pod template, and this approach does not update the Deployment's desired state.

Full explanation →

136

MCQhard

A team wants to use feature flags to control the rollout of a new feature in a Kubernetes-deployed microservice. Which tool is specifically designed for managing feature flags in cloud-native applications?

A.Helm

B.LaunchDarkly

C.Kustomize

D.Argo Rollouts

AnswerB

LaunchDarkly is a dedicated feature-management platform, streaming flag evaluations to SDKs so toggles update without redeploying pods. It satisfies the stem's cloud-native rollout constraint directly, whereas general CI/CD or service-mesh tooling lacks native flag targeting, percentage rollouts and audit trails.

Why this answer

LaunchDarkly is a feature management platform specifically designed for managing feature flags in cloud-native applications. It allows for controlled rollouts and A/B testing. Argo Rollouts focuses on progressive delivery (canary, blue-green deployments), not feature flags.

Helm is a package manager for Kubernetes. Kustomize is for configuration management. Therefore, option B (LaunchDarkly) is correct.

Full explanation →

137

MCQmedium

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

A.It provides a single entry point for client requests and handles cross-cutting concerns

B.It replaces the need for service meshes

C.It stores application state

D.It performs service-to-service communication

AnswerA

An API gateway fronts the services, so clients call one stable endpoint instead of tracking individual service addresses. It centralises cross-cutting concerns such as authentication, rate limiting, routing and TLS termination, decoupling clients from service topology.

Why this answer

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

Full explanation →

138

MCQmedium

A cluster administrator wants to allow a Pod to access the Kubernetes API to list Pods in its own namespace. Which authentication and authorization mechanism should be used to grant the Pod the necessary permissions?

A.Create a ServiceAccount, bind it to a Role with a RoleBinding, and use the ServiceAccount token in the Pod.

B.Configure the Pod to use client certificate authentication with a certificate signed by the cluster CA.

C.Set the Pod's hostNetwork to true and use the node's kubelet credentials.

D.Use a static token file on the API server and mount it into the Pod.

AnswerA

ServiceAccounts provide an identity for Pods. A Role defines permissions within a namespace, and a RoleBinding grants those permissions to the ServiceAccount. The Pod can then use the mounted ServiceAccount token to authenticate to the API server and perform actions allowed by the Role.

Why this answer

ServiceAccounts are the standard way to provide an identity for Pods. Combined with RBAC, you can create a Role with the necessary permissions and bind it to the ServiceAccount using a RoleBinding. The Pod automatically receives a token that it can use to authenticate to the API server.

Exam trap

The trap here is thinking that any authentication method works for Pods; ServiceAccounts are specifically designed for this purpose and integrate with RBAC.

Full explanation →

139

MCQmedium

A team uses Helm to manage their Kubernetes applications. They need to upgrade a release and want to reuse the values from the previous release while overriding a specific value. Which helm command should they use?

A.helm upgrade --reset-values my-release ./charts/app --set image.tag=v2

B.helm upgrade --reuse-values my-release ./charts/app --set image.tag=v2

C.helm upgrade --atomic my-release ./charts/app --set image.tag=v2

D.helm upgrade --history-max 5 my-release ./charts/app --set image.tag=v2

AnswerB

The --reuse-values flag merges the previous release's computed values with the new --set overrides, satisfying the requirement to retain prior configuration while changing only image.tag. Without it, Helm would reset unspecified values to chart defaults.

Why this answer

The --reuse-values flag tells Helm to reuse the last release's values and merge any provided overrides. This is the correct approach to preserve existing values while updating a specific one.

Full explanation →

140

MCQmedium

A company wants to adopt a GitOps workflow for managing their Kubernetes clusters. Which two tools are specifically designed for implementing GitOps on Kubernetes?

A.Flux

B.ArgoCD

C.Terraform

D.Jenkins

E.Helm

AnswerA, B

Flux is a CNCF GitOps operator that continuously reconciles Kubernetes cluster state against a Git repository, pulling declarative manifests. It is purpose-built for Kubernetes GitOps, satisfying the stem's requirement for a tool specifically designed for that workflow.

Why this answer

Flux (A) and ArgoCD (B) are the two tools specifically designed for GitOps on Kubernetes, as both run as controllers inside the cluster and continuously reconcile the cluster's live state with the desired state declared in a Git repository. Flux watches Git repositories and applies manifests automatically, while ArgoCD provides a declarative, Git-based continuous delivery model with drift detection and sync. Terraform (C) is an infrastructure-as-code provisioning tool that applies changes on demand rather than continuously reconciling from Git, so it is not a dedicated GitOps operator.

Jenkins (D) is a general-purpose CI automation server, and Helm (E) is a Kubernetes package manager for templating and releasing manifests, neither of which implements GitOps reconciliation on its own.

Full explanation →

141

MCQhard

A Kubernetes cluster runs a critical application that must be updated with zero downtime. The team wants to gradually shift traffic from the old version to the new version over a period of time. Which deployment pattern is MOST appropriate?

A.Rolling update

B.Recreate deployment

C.Blue-green deployment

D.Canary deployment

AnswerD

Canary deployment routes a small, controlled slice of live traffic to the new version while the old version serves the remainder, then progressively shifts weight as health metrics confirm stability. This satisfies the gradual traffic-shift and zero-downtime constraints without exposing all users to risk.

Why this answer

Canary deployment is the most appropriate pattern for gradually shifting traffic from an old version to a new version over time. It involves deploying the new version to a small subset of users or servers, then incrementally increasing traffic while monitoring for issues. This allows zero-downtime updates and minimizes risk by limiting exposure.

Rolling update replaces instances in batches but does not provide the same gradual, controlled traffic shifting with the ability to pause or rollback based on metrics.

Exam trap

KCNA often tests the distinction between rolling update and canary deployment — candidates may confuse the two, but canary specifically involves gradual traffic shifting with monitoring, while rolling update is about replacing instances in batches.

How to eliminate wrong answers

Option A is wrong because a rolling update replaces pods incrementally but does not allow fine-grained traffic control or gradual shifting based on user segments; it also cannot easily pause or rollback mid-rollout. Option B is wrong because a recreate deployment terminates all old pods before starting new ones, causing downtime, which violates the zero-downtime requirement. Option C is wrong because blue-green deployment switches all traffic at once from blue to green, which is not gradual and does not shift traffic over a period of time.

Full explanation →

142

MCQeasy

Which of the following is NOT one of the three pillars of observability?

A.Metrics

B.Logs

C.Traces

D.Alerts

AnswerD

Alerts are a downstream response mechanism built on observability data, not a source of it. The three pillars are logs, metrics, and traces; alerting consumes these signals through rules, so it does not itself constitute a pillar.

Why this answer

The three pillars of observability are metrics, logs, and traces. Metrics are numeric measurements aggregated over time, logs are timestamped records of discrete events, and traces follow a request's path through distributed systems. Alerts are not a pillar; they are a downstream action or notification triggered by conditions derived from the pillars.

Therefore, alerts is the correct answer as the item that is NOT a pillar.

Exam trap

The trap is that alerts feel like a core part of observability because they are prominent in monitoring tools, but the exam expects you to recognize the three data types that provide observability, not the actions taken on them.

How to eliminate wrong answers

Option A is wrong because metrics are indeed one of the three pillars, providing quantitative data such as CPU usage or request rates. Option B is wrong because logs are a core pillar, capturing detailed event data for debugging and auditing. Option C is wrong because traces are the third pillar, essential for understanding request flow and latency in microservices.

Option D is correct because alerts are a response mechanism built on top of observability data, not a fundamental data type.

Full explanation →

143

MCQmedium

In a multi-cloud scenario, an organization wants to avoid vendor lock-in by abstracting infrastructure provisioning. Which tool is specifically designed to manage infrastructure as code across multiple cloud providers?

A.Helm

B.Istio

C.Terraform

D.ArgoCD

AnswerC

Terraform uses provider plugins to translate a single HCL configuration into each cloud's native API calls, managing state across AWS, Azure and GCP. This provider abstraction lets the organisation provision identical infrastructure on multiple clouds, directly avoiding vendor lock-in.

Why this answer

Terraform is a declarative infrastructure-as-code tool that uses provider plugins to manage resources across AWS, Azure, GCP, and many other platforms from a single configuration language (HCL). Its provider model and state file make it the canonical choice for multi-cloud, vendor-neutral infrastructure provisioning. This directly addresses the requirement to avoid vendor lock-in by abstracting provisioning.

Exam trap

KCNA often tests the boundary between Kubernetes-ecosystem tools (Helm, Istio, ArgoCD) and general infrastructure-as-code tools (Terraform) — candidates pick Helm because it 'manages infrastructure' in a loose sense, missing that it only manages Kubernetes manifests.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes that templates and deploys Kubernetes manifests; it manages workloads inside a cluster, not cloud infrastructure across providers. Option B is wrong because Istio is a service mesh for traffic management, mTLS, and observability between microservices; it has nothing to do with provisioning cloud infrastructure. Option D is wrong because ArgoCD is a GitOps continuous-delivery controller for Kubernetes that syncs cluster state to Git; it deploys applications, not multi-cloud infrastructure.

Full explanation →

144

Multi-Selectmedium

Which THREE statements about Kubernetes Pods are correct?

Select 3 answers

A.Containers within a Pod cannot communicate with each other without using Services.

B.A Pod is the smallest deployable unit in Kubernetes.

C.A Pod always runs on a single node.

D.A Pod can contain multiple containers that share the same network namespace.

E.Pods are the most resilient unit in Kubernetes and automatically recover from failures.

AnswersB, C, D

Kubernetes schedules and manages Pods as its atomic unit; containers are not deployed independently. This satisfies the stem's requirement for a correct Pod statement, distinguishing the Pod abstraction from higher-level controllers such as ReplicaSets and Deployments that manage Pods.

Why this answer

Option B is correct because the Pod is the smallest deployable unit in Kubernetes — you cannot schedule or deploy individual containers directly; the Pod is the atomic unit the scheduler places on a node. Option C is correct because a Pod is always scheduled as a whole onto a single node; its containers are co-located and cannot be spread across multiple nodes. Option D is correct because a Pod can contain multiple containers that share the same network namespace, meaning they share an IP address and port space and can communicate over localhost.

Option A is incorrect because containers within the same Pod share the network namespace and can communicate directly via localhost without any Service. Option E is incorrect because Pods are ephemeral and not self-healing; if a Pod fails, it is the higher-level controller (such as a Deployment or ReplicaSet) that creates a replacement, not the Pod itself.

Exam trap

The trap is that candidates often assume Pods can span nodes or that containers within a Pod need Services to communicate, but in fact Pods are node-bound and containers share the network namespace.

Full explanation →

145

MCQmedium

Which of the following is a benefit of container orchestration?

A.Requires a hypervisor for each container

B.Manual scaling of containers

C.Static infrastructure with no changes

D.Self-healing of failed containers

AnswerD

Controllers continuously compare observed pod state against the declared desired state, restarting or rescheduling containers that fail. This reconciliation loop restores availability without human action, which is precisely the self-healing benefit the question asks for.

Why this answer

Container orchestration platforms like Kubernetes provide self-healing capabilities by automatically restarting failed containers, rescheduling them on healthy nodes, and replacing or terminating containers that fail health checks. This ensures high availability and reduces manual intervention, which is a core benefit of orchestration.

Exam trap

CNCF often tests the misconception that container orchestration is only about initial deployment, when in fact its key value is ongoing automated management like self-healing and scaling.

How to eliminate wrong answers

Option A is wrong because container orchestration does not require a hypervisor for each container; containers share the host OS kernel and run as isolated processes, unlike VMs that need a hypervisor. Option B is wrong because container orchestration enables automatic scaling (e.g., horizontal pod autoscaling in Kubernetes), not manual scaling, which would defeat the purpose of automation. Option C is wrong because container orchestration promotes dynamic infrastructure with automated deployment, scaling, and updates, not static infrastructure with no changes.

Full explanation →

146

MCQmedium

Which field in a Pod's container specification defines the minimum amount of CPU guaranteed to the container?

A.spec.containers.cpu

B.resources.requests.cpu

C.resources.limits.cpu

D.spec.nodeSelector

AnswerB

`resources.requests.cpu` sets the CPU amount the scheduler reserves for the container, guaranteeing that capacity on the node. Kubernetes enforces this as the container's minimum share under contention, directly satisfying the stem's requirement for guaranteed CPU. Limits, by contrast, cap burst usage rather than guarantee a floor.

Why this answer

In Kubernetes, the `resources.requests.cpu` field specifies the minimum amount of CPU guaranteed to a container. This value is used by the scheduler to ensure the node has enough allocatable CPU, and by the kubelet to enforce CPU shares via the Completely Fair Scheduler (CFS) in the Linux kernel.

Exam trap

The trap here is that candidates often confuse `requests` (guaranteed minimum) with `limits` (maximum allowed), especially since both are defined under `resources` and both use the same unit (e.g., millicores).

How to eliminate wrong answers

Option A is wrong because `spec.containers.cpu` is not a valid field; CPU requests are nested under `resources.requests.cpu`. Option C is wrong because `resources.limits.cpu` defines the maximum CPU a container can burst to, not the guaranteed minimum. Option D is wrong because `spec.nodeSelector` is a scheduling constraint that selects nodes based on labels, not a container resource specification.

Full explanation →

147

Multi-Selectmedium

Which TWO of the following are capabilities of ArgoCD? (Choose two.)

Select 2 answers

A.Building container images from source code

B.Automated application sync from Git to cluster

C.Self-healing to correct configuration drift

D.Running unit tests during deployment

E.Managing secrets using Kubernetes Secrets

AnswersB, C

ArgoCD continuously reconciles cluster state against Git, automatically applying declared manifests when drift is detected. This satisfies the stem's requirement for automated sync from Git to cluster, the pull-based GitOps mechanism ArgoCD implements natively without external CI triggers.

Why this answer

ArgoCD is a declarative GitOps continuous delivery tool for Kubernetes, and option B is correct because it continuously monitors Git repositories and automatically syncs the desired application state defined in Git to the target cluster. Option C is also correct because ArgoCD detects configuration drift between the live cluster state and the desired state in Git and can self-heal by reapplying the Git-defined manifests to restore the correct configuration. Option A is incorrect because ArgoCD does not build container images; that is the job of CI tools such as Jenkins, GitLab CI, or Tekton.

Option D is incorrect because running unit tests is a CI activity, not a core ArgoCD capability. Option E is incorrect because ArgoCD does not manage secrets via Kubernetes Secrets as a built-in capability; secret management is typically handled by external tools like Sealed Secrets, SOPS, or Vault.

Exam trap

The trap is conflating CI and CD responsibilities — candidates assume ArgoCD builds images or runs tests because it is part of a deployment pipeline, but ArgoCD is strictly a GitOps CD tool.

Full explanation →

148

MCQeasy

Which component in Kubernetes is responsible for managing the lifecycle of pods and ensuring the desired number of replicas are running?

A.Kube-proxy

B.Kubelet

C.Controller Manager

D.ReplicaSet

AnswerD

ReplicaSet controllers continuously reconcile actual pod counts against the declared replica specification, creating or deleting pods to maintain the desired state. This directly satisfies the stem's requirement for lifecycle management and replica enforcement, unlike kube-scheduler (placement only) or kubelet (node-local pod execution).

Why this answer

The ReplicaSet (option D) is the Kubernetes controller that ensures a specified number of pod replicas are running at any given time. It manages pod lifecycle by creating or deleting pods to match the desired replica count defined in its spec, and it is the fundamental building block for higher-level controllers like Deployments.

Exam trap

In Kubernetes certification exams, candidates often confuse the Controller Manager (which hosts multiple controllers) with the specific controller (e.g., ReplicaSet) that performs the actual work, leading to selecting the broader component instead of the precise one.

How to eliminate wrong answers

Option A is wrong because kube-proxy is a network proxy that runs on each node, handling service-to-pod traffic routing via iptables or IPVS rules, not pod lifecycle or replica management. Option B is wrong because kubelet is the node agent that ensures containers are running in a pod as defined by the PodSpec, but it does not manage replica counts or pod lifecycle across nodes — it only acts on pods assigned to its node. Option C is wrong because the Controller Manager is a control plane component that runs multiple controllers (including ReplicaSet, Deployment, etc.) as a single binary, but it is not the specific component responsible for managing pod replicas — that is the ReplicaSet controller itself.

Full explanation →

149

Multi-Selecthard

Which THREE of the following are valid ways to expose a set of pods as a network service in Kubernetes?

Select 3 answers

A.Creating a Service of type NodePort.

B.Creating a headless Service (clusterIP: None).

C.Creating an Ingress resource.

D.Creating a Deployment with a label selector.

E.Creating a Service of type ClusterIP.

AnswersA, C, E

Correct; NodePort exposes on a static port on each node.

Why this answer

A Service of type NodePort exposes the pods on a static port on each node's IP address, making the service accessible externally. This is a valid method for exposing a set of pods as a network service in Kubernetes.

Exam trap

The KCNA exam often tests the distinction between workload resources (like Deployments) and networking resources (like Services and Ingresses), leading candidates to mistakenly think a Deployment alone can expose pods as a network service.

Full explanation →

150

Multi-Selecthard

Which THREE of the following are components of the GitOps workflow? (Choose three.)

Select 3 answers

A.A CI/CD pipeline that validates changes before merging

B.A configuration management database (CMDB)

C.A Git repository containing declarative configuration

D.A manual approval process for every change

E.An operator (e.g., ArgoCD) that syncs the cluster state with Git

AnswersA, C, E

The CI/CD pipeline validates declarative changes before they merge, enforcing review and automated testing so only verified manifests reach the Git repository. This gate satisfies the workflow's requirement that proposed configuration is checked prior to becoming the desired state the operator later reconciles.

Why this answer

GitOps relies on a Git repository as single source of truth, a CI/CD pipeline to validate changes, and an operator to sync the cluster.

Full explanation →

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 76–150