Courseiva

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 301–375

930 questions total · 13pages · All types, answers revealed

Take a mock examExam hub
Page 4

Page 5 of 13

Page 6
301
Multi-Selectmedium

Which TWO of the following are key characteristics of cloud-native applications? (Select two.)

Select 2 answers
A.Monolithic architecture
B.Microservices architecture
C.Containerized deployment
D.Manual scaling
E.Long-lived virtual machines
AnswersB, C

Microservices architecture decomposes an application into independently deployable services, each owning its own data and lifecycle. This satisfies the stem's characteristic criterion by enabling independent scaling, fault isolation, and rapid iteration, which monolithic designs cannot match.

Why this answer

Option B is correct because cloud-native applications are built as microservices architecture, decomposing functionality into small, independently deployable services that communicate over lightweight APIs (e.g., REST/gRPC), enabling independent scaling and resilience. Option C is correct because cloud-native apps are typically packaged and deployed in containers (e.g., Docker images orchestrated by Kubernetes), which provide portability, immutable artifacts, and fast, consistent deployment across environments. Option A is incorrect because monolithic architecture is the opposite of the loosely coupled, independently deployable services that characterize cloud-native design.

Option D is incorrect because cloud-native applications rely on automated/elastic scaling (e.g., Horizontal Pod Autoscaler, auto-scaling groups) rather than manual scaling. Option E is incorrect because long-lived virtual machines reflect traditional, pet-style infrastructure, whereas cloud-native workloads favor ephemeral, disposable instances and containers managed declaratively.

Exam trap

KCNA often tests the misconception that 'cloud-native' simply means 'running in the cloud', tricking candidates into selecting options like long-lived VMs or manual scaling that describe traditional cloud-hosted rather than cloud-native architectures.

Full explanation →
302
MCQeasy

Which Kubernetes resource is used to run a batch job that runs to completion?

A.DaemonSet
B.StatefulSet
C.Job
D.Deployment
AnswerC

A Job creates pods that run until successful completion, tracking completions and retrying failures. Unlike a Deployment, which maintains a continuously running replica set, a Job suits finite batch workloads that must terminate once their task finishes.

Why this answer

A Kubernetes Job is specifically designed to run a finite task to completion, creating one or more Pods and ensuring they successfully terminate. Unlike controllers that maintain a desired state of running Pods, a Job tracks the number of successful completions and stops when the specified parallelism or completions count is reached.

Exam trap

The trap here is that candidates confuse a Job with a Deployment because both can run Pods, but a Deployment is designed for long-running services with continuous availability, while a Job is the only controller that tracks and terminates upon successful completion.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, intended for long-running services like log collectors or monitoring agents, not for batch jobs that run to completion. Option B is wrong because a StatefulSet manages stateful applications with unique network identities and persistent storage, designed for workloads like databases that require stable identities and ordered deployment, not for ephemeral batch tasks. Option D is wrong because a Deployment manages ReplicaSets to provide declarative updates for stateless applications that should run continuously, ensuring a specified number of replicas are always running, which is the opposite of a job that terminates upon completion.

Full explanation →
303
MCQmedium

An administrator must run a privileged DaemonSet on every node, including the control-plane node, to collect host logs. The control-plane node has a taint node-role.kubernetes.io/control-plane:NoSchedule. Which change allows the DaemonSet Pods to be scheduled on the control-plane node while keeping the taint intact?

A.Remove the taint from the control-plane node with kubectl taint nodes --all node-role.kubernetes.io/control-plane-.
B.Set spec.template.spec.nodeName to the control-plane node name in the DaemonSet.
C.Add a toleration for key node-role.kubernetes.io/control-plane with operator Exists and effect NoSchedule to the DaemonSet Pod template.
D.Add a nodeSelector for node-role.kubernetes.io/control-plane to the DaemonSet Pod template.
AnswerC

Tolerations allow Pods to be scheduled onto nodes with matching taints without removing the taint. Using operator Exists with effect NoSchedule tolerates the control-plane taint regardless of its value, so the DaemonSet can place a Pod on that node. The taint remains, preserving the default scheduling restriction for other workloads.

Why this answer

Taints repel Pods unless the Pod declares a matching toleration. Adding a toleration with operator Exists and effect NoSchedule for the control-plane taint lets the DaemonSet schedule there while leaving the taint in place, so other workloads remain excluded. Removing the taint, pinning with nodeName, or using a nodeSelector does not meet the requirement of keeping the taint intact.

Exam trap

The trap here is confusing nodeSelector or node labels with tolerations, when only a toleration overrides a NoSchedule taint without removing it.

Full explanation →
304
Multi-Selecthard

Which TWO of the following are recommended practices for achieving observability in a Kubernetes cluster?

Select 2 answers
A.Use a single centralized logging solution to aggregate logs from all components.
B.Store all debug logs for a minimum of 90 days for compliance.
C.Include correlation IDs in structured logs to enable tracing across services.
D.Disable leader election for monitoring components to reduce complexity.
E.Use Prometheus with a pull-based model to scrape metrics from pods.
AnswersC, E

Correlation IDs help trace requests across microservices.

Why this answer

Including correlation IDs in structured logs is a key observability practice that enables distributed tracing across microservices. In Kubernetes, where requests often traverse multiple pods and services, correlation IDs allow you to link logs from different components into a single transaction flow, which is essential for debugging and understanding system behavior.

Exam trap

CNCF often tests the misconception that centralized logging is always best, but the trap here is that observability emphasizes distributed, resilient data collection over a single monolithic log sink, and that debug logs are not subject to long-term compliance retention like audit logs.

Full explanation →
305
Multi-Selecthard

An administrator wants to perform a rolling update of a Deployment. Which TWO actions will achieve this?

Select 2 answers
A.Run 'kubectl set image deployment/myapp myapp=myapp:v2'
B.Run 'kubectl scale deployment myapp --replicas=0' then 'kubectl scale deployment myapp --replicas=5'
C.Run 'kubectl delete deployment' and then 'kubectl create deployment' with the new image
D.Run 'kubectl rollout undo deployment/myapp'
E.Edit the Deployment YAML to change the image version and run 'kubectl apply -f deployment.yaml'
AnswersA, E

kubectl set image patches the Deployment's pod template with the new image tag, which triggers the controller to create a new ReplicaSet and roll pods over gradually. This achieves the rolling update without editing YAML manually.

Why this answer

Option A is correct because 'kubectl set image deployment/myapp myapp=myapp:v2' updates the container image in the Deployment's Pod template, which triggers the Deployment controller to perform a rolling update by creating a new ReplicaSet and gradually replacing old Pods while maintaining availability. Option E is also correct because editing the Deployment YAML to change the image version and running 'kubectl apply -f deployment.yaml' updates the Pod template spec, causing the same rolling update behavior managed by the Deployment controller. Option B is incorrect because scaling to zero replicas causes downtime and does not perform a rolling update; scaling back up simply creates new Pods without the controlled surge/unavailable semantics of a rollout.

Option C is incorrect because deleting and recreating the Deployment destroys the existing rollout history and causes an outage rather than a rolling update. Option D is incorrect because 'kubectl rollout undo' reverts to a previous revision, which is a rollback, not a rolling update to a new image version.

Exam trap

The trap here is that candidates may confuse scaling (Option B) or deleting/recreating (Option C) with a rolling update, or think that 'rollout undo' (Option D) is a way to update to a new image, when it is actually for reverting to a previous version.

Full explanation →
306
MCQmedium

A DevOps engineer wants to deploy a stateful application that requires stable network identities and persistent storage. Which Kubernetes resource is most appropriate?

A.DaemonSet
B.StatefulSet
C.Deployment
D.ReplicaSet
AnswerB

StatefulSet gives each pod a stable, ordinal hostname and its own PersistentVolumeClaim, so replicas keep predictable network identities and storage across restarts and rescheduling. Deployments provide neither guarantee, making them unsuitable for the stable identity and persistence this stateful workload requires.

Why this answer

StatefulSet is the correct choice because it is designed specifically for stateful applications that require stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage (via PersistentVolumeClaims that persist across Pod rescheduling). Unlike Deployments, StatefulSet guarantees ordered, graceful deployment and scaling, which is essential for applications like databases or distributed systems that rely on stable identities.

Exam trap

The trap here is that candidates confuse StatefulSet with Deployment, assuming Deployments can handle stateful workloads by adding persistent volumes, but they overlook the critical need for stable network identities and ordered Pod management that only StatefulSet provides.

How to eliminate wrong answers

Option A (DaemonSet) is wrong because it ensures one Pod per Node for daemon-like workloads (e.g., logging agents, monitoring) and does not provide stable network identities or per-Pod persistent storage. Option C (Deployment) is wrong because it is designed for stateless applications; Pods are interchangeable and get random hostnames, and PersistentVolumeClaims are shared or recreated, breaking identity and storage persistence. Option D (ReplicaSet) is wrong because it is a lower-level resource that only maintains a desired replica count without any guarantees for stable identities, ordered operations, or persistent storage binding.

Full explanation →
307
Multi-Selecthard

Which THREE of the following are true about the Open Container Initiative (OCI)? (Select 3)

Select 3 answers
A.OCI is governed solely by Docker Inc.
B.OCI only applies to Linux containers
C.OCI defines the container image format specification
D.OCI standards are vendor-neutral
E.OCI defines a standard for container runtime execution
AnswersC, D, E

OCI publishes the image-spec, which standardises how container images are built and laid out, including manifests, configuration and layer content. This directly satisfies the stem's requirement by defining the container image format specification, enabling any compliant runtime or registry to consume the same image.

Why this answer

Option C is correct because the Open Container Initiative publishes the OCI Image Format Specification, which standardizes how container images (manifest, config, and layer filesystem changesets) are structured so any compliant tool can build, pull, and run them. Option D is correct because OCI is a vendor-neutral, open governance project hosted under the Linux Foundation, with contributions from many companies rather than a single vendor, ensuring interoperability across ecosystems. Option E is correct because OCI also defines the Runtime Specification, which describes how a container runtime executes a filesystem bundle (covering lifecycle operations such as create, start, and kill) and is implemented by runtimes like runc.

Option A is wrong because OCI is not governed solely by Docker Inc.; it operates under the Linux Foundation with broad industry participation. Option B is wrong because OCI specifications are platform-agnostic and also apply to Windows containers, not only Linux containers.

Exam trap

CNCF often tests the misconception that OCI is Docker-specific or Linux-only, when in fact it is a vendor-neutral, cross-platform standard governed by the Linux Foundation.

Full explanation →
308
Multi-Selectmedium

Which TWO of the following are benefits of using a container orchestration platform like Kubernetes? (Choose two.)

Select 2 answers
A.Inability to manage container networking
B.Requirement to run applications on a single node
C.Self-healing by restarting failed containers
D.Manual rollback of application versions
E.Automated scaling of applications based on demand
AnswersC, E

Kubernetes continuously reconciles desired state against actual state via controllers such as the ReplicaSet, automatically recreating or restarting containers that fail liveness probes or crash. This removes manual intervention, directly delivering the self-healing benefit the question asks for.

Why this answer

Option C is correct because Kubernetes continuously reconciles desired state with actual state via controllers such as ReplicaSet and kubelet, so when a container or Pod fails, it is automatically restarted or rescheduled to maintain the declared replica count. Option E is correct because Kubernetes provides the Horizontal Pod Autoscaler (HPA), which scales the number of Pod replicas automatically based on metrics like CPU utilization or custom metrics, enabling demand-based scaling. Option A is incorrect because Kubernetes actually provides robust container networking through the Container Network Interface (CNI), Services, and Ingress, rather than lacking it.

Option B is incorrect because Kubernetes is a distributed system designed to schedule workloads across a cluster of multiple nodes, not to confine applications to a single node. Option D is incorrect because Kubernetes supports automated rollouts and rollbacks via Deployments (for example, kubectl rollout undo), so rollback is not inherently manual.

Exam trap

KCNA often tests candidate understanding of what Kubernetes actually provides versus common misconceptions, and the trap is picking plausible-sounding but inverted statements (like 'inability to manage networking') or confusing manual operations with the automated capabilities Kubernetes delivers.

Full explanation →
309
Multi-Selectmedium

Which THREE of the following are valid Kubernetes resource types?

Select 3 answers
A.DockerImage
B.Deployment
C.ConfigMap
D.VirtualMachine
E.Service
AnswersB, C, E

Deployment is a built-in apps/v1 resource that manages ReplicaSets to provide declarative rolling updates and rollbacks for stateless Pods. It is a genuine Kubernetes API resource type, unlike abstractions such as PodSpec fields or labels.

Why this answer

Deployment (B) is a valid Kubernetes resource type, an apps/v1 workload controller that manages ReplicaSets and provides declarative rolling updates and rollbacks for stateless Pods. ConfigMap (C) is a valid core/v1 resource used to store non-confidential configuration data as key-value pairs that Pods can consume via environment variables, command-line arguments, or mounted volumes. Service (E) is a valid core/v1 resource that provides a stable virtual IP and DNS name to load-balance traffic to a set of Pods selected by labels.

DockerImage (A) is not a Kubernetes API resource; container images are referenced in a Pod spec's image field but are not themselves objects managed by the API server. VirtualMachine (D) is not a built-in Kubernetes resource type; VM lifecycle is handled by separate projects such as KubeVirt, which introduces its own CRDs like VirtualMachineInstance.

Exam trap

The KCNA exam often tests whether candidates confuse container image references (like Docker images) with actual Kubernetes API resource types, leading them to incorrectly select DockerImage as a valid resource.

Full explanation →
310
Multi-Selectmedium

Which two components are part of the Kubernetes worker node? (Select TWO)

Select 2 answers
A.kubelet
B.kube-controller-manager
C.etcd
D.kube-scheduler
E.container runtime
AnswersA, E

kubelet is the node agent that registers the node with the control plane, watches for assigned PodSpecs, and ensures containers run and report health. It is a core worker node component, distinct from control plane services like the scheduler.

Why this answer

The kubelet (A) is correct because it is the primary node agent that runs on every worker node, registering the node with the API server and ensuring containers described in PodSpecs are running and healthy. The container runtime (E) is correct because the worker node needs a CRI-compliant runtime such as containerd or CRI-O to actually pull images and run containers. The kube-controller-manager (B), etcd (C), and kube-scheduler (D) are all control plane components that typically run on master nodes, not on worker nodes, so they are not part of the worker node.

Exam trap

The CNCF exam often tests the distinction between control plane and worker node components; the trap here is that candidates confuse the kubelet (worker node agent) with the kube-controller-manager or kube-scheduler, which are control-plane-only services, or mistakenly think etcd runs on every node.

Full explanation →
311
Multi-Selectmedium

Which THREE are core principles of the Twelve-Factor App methodology?

Select 3 answers
A.Store config in codebase for traceability
B.Explicitly declare and isolate dependencies
C.Tight coupling to backing services
D.Treat logs as event streams
E.One codebase tracked in revision control, many deploys
AnswersB, D, E

Twelve-Factor's dependency principle requires applications to declare all dependencies explicitly in a manifest and isolate them from the host, never relying on implicit system-wide packages. This guarantees reproducible builds and prevents version drift between development and production environments.

Why this answer

Option B is correct because Factor II (Dependencies) requires an app to explicitly declare all dependencies via a manifest such as requirements.txt, package.json, or Gemfile, and isolate them using tooling like virtualenv or Bundler so no implicit system-wide packages are assumed. Option D is correct because Factor XI (Logs) states an app should never manage log files itself; instead it writes unbuffered event streams to stdout/stderr, letting the execution environment aggregate and route them. Option E is correct because Factor I (Codebase) mandates exactly one codebase tracked in a version control system such as Git, with many deploys from that same codebase across environments.

Option A is wrong because Factor III (Config) requires config to be stored in the environment, not in the codebase, precisely to keep credentials and environment-specific values out of revision control. Option C is wrong because the methodology calls for loosely coupled, interchangeable backing services (Factor IV), attached and detached via config, not tight coupling.

Exam trap

CNCF often tests the misconception that storing configuration in the codebase provides traceability, but the Twelve-Factor App explicitly forbids this to maintain strict separation of config from code and avoid accidental exposure of secrets.

Full explanation →
312
Multi-Selectmedium

Which TWO of the following are required fields when defining a container in a Kubernetes Pod spec? (Choose 2)

Select 2 answers
A.env
B.image
C.name
D.resources
E.ports
AnswersB, C

The `image` field is mandatory because the kubelet needs a container image reference to pull and instantiate the container's filesystem and process. Without it, the Pod spec fails validation, satisfying the stem's requirement for a required field alongside `name`.

Why this answer

In a Kubernetes Pod spec, the `name` and `image` fields are mandatory for each container definition. The `name` field uniquely identifies the container within the Pod, and the `image` field specifies the container image to run (e.g., `nginx:1.25`). Without these two fields, the Pod creation will fail with a validation error from the Kubernetes API server.

Exam trap

CNCF often tests the misconception that `ports` or `resources` are required because they appear in most example Pod specs, but the KCNA exam expects you to know that only `name` and `image` are mandatory per the Kubernetes API specification.

Full explanation →
313
MCQmedium

A DevOps engineer has created a ConfigMap named 'app-config' with some configuration data. They want to make that data available as environment variables in a pod. Which field in the pod spec should they use to achieve this?

A.spec.volumes
B.spec.containers[].volumeMounts
C.spec.containers[].envFrom
D.spec.containers[].env
AnswerC

envFrom bulk-imports every key-value pair from the referenced ConfigMap as environment variables, satisfying the requirement without enumerating each key individually. The alternative, env with valueFrom, exposes only one key per entry, so envFrom is the correct field.

Why this answer

The `envFrom` field in the container spec allows you to inject all key-value pairs from a ConfigMap (or Secret) as environment variables into the container. This is the most direct and efficient way to expose ConfigMap data as environment variables without needing to specify each key individually.

Exam trap

The trap here is that candidates often confuse `envFrom` with `env` or `volumeMounts`, thinking that mounting a ConfigMap as a volume or using individual `env` entries is the only way to expose its data, but `envFrom` is the specific field designed for bulk injection of ConfigMap keys as environment variables.

How to eliminate wrong answers

Option A is wrong because `spec.volumes` defines volumes at the pod level, not environment variables; it is used for mounting data as files. Option B is wrong because `spec.containers[].volumeMounts` mounts a volume into a container's filesystem, not into environment variables. Option D is wrong because `spec.containers[].env` is used to set individual environment variables explicitly, but it does not automatically pull all data from a ConfigMap; it requires manual mapping of each key using `valueFrom`.

Full explanation →
314
MCQmedium

A platform team wants to run a batch job that must complete successfully exactly once per day on a schedule. They need Kubernetes to create a Job object automatically at the specified times, and they want to keep a history of the last three successful and one failed Job for debugging. Which resource should they create?

A.A Job with a cron schedule annotation and a restartPolicy of OnFailure.
B.A DaemonSet that runs a Pod on every node and executes the batch script once per day.
C.A StatefulSet with an initContainer that sleeps until the next scheduled time.
D.A CronJob with a schedule, successfulJobsHistoryLimit: 3, and failedJobsHistoryLimit: 1.
AnswerD

A CronJob creates Job objects on a cron schedule. The fields `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` control how many completed and failed Jobs are retained for inspection. Setting them to 3 and 1 matches the requirement to keep a short history while allowing the CronJob to create a new Job each day. The Job then runs the Pod to completion.

Why this answer

The requirement is a scheduled, one-off task with retention of past runs. A CronJob is the only resource that natively creates Jobs on a cron schedule and exposes history limits for successful and failed Jobs. The Job it creates handles completion and retries.

Other workload controllers either run continuously or lack scheduling and history features, so they cannot fulfill the scenario.

Exam trap

The trap here is confusing a Job, which runs a task once, with a CronJob, which creates Jobs on a schedule and manages their history.

Full explanation →
315
MCQmedium

Which Kubernetes controller ensures that a specified number of pod replicas are running at all times?

A.ReplicaSet
B.Job
C.ReplicationController
D.DaemonSet
AnswerA

A ReplicaSet's reconciliation loop continuously compares the desired replica count in its specification against observed pod counts, creating or deleting pods to match. This directly satisfies the stem's requirement for maintaining a specified number of pod replicas at all times, unlike Deployments (which manage ReplicaSets) or DaemonSets (one pod per node).

Why this answer

A ReplicaSet is the Kubernetes controller that ensures a specified number of pod replicas are running at all times. It uses a label selector to match pods and maintains the desired replica count by creating or deleting pods as needed. ReplicaSet is the successor to ReplicationController and is primarily used by Deployments to manage pod scaling and self-healing.

Exam trap

CNCF often tests the distinction between ReplicaSet and ReplicationController, trapping candidates who think ReplicationController is still the primary controller for replica management, when in fact ReplicaSet is the modern, recommended controller.

How to eliminate wrong answers

Option B is wrong because a Job controller is designed to run a specified number of pods to completion, not to maintain a continuous replica count. Option C is wrong because ReplicationController is the older, deprecated controller that also ensures a specified number of pod replicas, but it has been superseded by ReplicaSet with more flexible label selectors; however, the question asks for the current correct answer, and ReplicaSet is the standard. Option D is wrong because a DaemonSet ensures that a copy of a pod runs on every node (or a subset of nodes), not a specified number of replicas cluster-wide.

Full explanation →
316
Multi-Selecthard

Which TWO are characteristics of the microservices architecture that are supported by container orchestration?

Select 2 answers
A.Tight coupling between services to ensure performance
B.Independent deployment of each service
C.Decomposition of an application into small, independent services
D.Monolithic codebase with centralized deployment
E.Use of a single, shared database for all services
AnswersB, C

Container orchestration lets each microservice be built, versioned and released on its own schedule, so teams deploy independently without coordinating a monolithic release. This satisfies the stem's requirement by matching the architectural trait of decoupled, autonomous service delivery.

Why this answer

Option B is correct because container orchestration platforms such as Kubernetes let each microservice be built, versioned, and rolled out on its own schedule, so a change to one service does not force redeployment of the others. Option C is correct because microservices architecture decomposes an application into small, independently runnable services, and orchestration supports this by scheduling, scaling, and networking each service as a separate workload. Options A, D, and E are not characteristics of microservices supported by orchestration: tight coupling, a monolithic codebase with centralized deployment, and a single shared database all describe monolithic or tightly integrated designs that contradict the independence and loose coupling that orchestration enables.

Exam trap

A common misconception tested in the KCNA exam is that microservices require a shared database or tight coupling for performance, but the correct answer emphasizes independent deployment and decomposition, which are the defining characteristics supported by container orchestration.

Full explanation →
317
Multi-Selectmedium

Which two of the following are valid ways to expose a Pod's container port to other resources? (Select two.)

Select 2 answers
A.Create a Service of type ClusterIP pointing to the Pod's port
B.Add a containerPort field in the Pod spec
C.Set the pod's hostNetwork to true
D.Create an Ingress that routes to the Service
E.Use kubectl port-forward
AnswersA, D

A ClusterIP Service provides a stable virtual IP and DNS name that load-balances to the pod's target port, letting other in-cluster resources reach the container. It satisfies internal exposure without requiring node-level or external access.

Why this answer

Option A is correct because a Service of type ClusterIP provides a stable virtual IP and DNS name that load-balances traffic to the Pod's target port, making the container port reachable by other resources inside the cluster. Option D is correct because an Ingress routes external HTTP/HTTPS traffic to a Service (which then forwards to the Pod's container port), thereby exposing the port to resources outside the cluster. Option B is not a valid exposure method by itself: containerPort is purely informational metadata in the Pod spec and does not publish or open the port.

Option C is incorrect because hostNetwork: true makes the Pod share the node's network namespace, but it does not expose a specific container port to other resources as a Kubernetes networking construct. Option E is incorrect because kubectl port-forward is a temporary debugging tunnel from a local machine to a Pod, not a way to expose a container port to other cluster resources.

Exam trap

A common mistake is assuming that setting a containerPort in the Pod spec alone exposes the port to other resources; it only documents the port. Similarly, hostNetwork exposes the Pod's ports on the node's network but is not a standard Kubernetes service discovery method. The correct production approach is to create a Service (ClusterIP) to expose the Pod, and optionally an Ingress for HTTP-based routing.

Full explanation →
318
MCQmedium

Which deployment strategy is characterized by gradually shifting traffic from an old version to a new version of an application, often requiring a service mesh or ingress controller to manage traffic splitting?

A.Rolling update
B.Canary deployment
C.Blue-green deployment
D.Recreate
AnswerB

Canary deployment routes a small percentage of live traffic to the new version while the remainder still reaches the old one, then shifts that weighting gradually. This satisfies the stem's requirement for traffic splitting, which needs a service mesh or ingress controller to manipulate routing weights at the network layer.

Why this answer

A canary deployment gradually shifts a small percentage of traffic to the new version while the majority still hits the old version, allowing observation of metrics before full rollout. This traffic splitting is typically implemented via a service mesh (Istio, Linkerd) or an ingress controller (NGINX, Traefik) that supports weighted routing.

Exam trap

KCNA often tests the distinction between canary and rolling update — the trap is assuming any gradual rollout is a canary, when the defining feature of canary is percentage-based traffic splitting via a mesh or ingress controller.

How to eliminate wrong answers

Option A is wrong because a rolling update replaces pods/instances incrementally at the infrastructure level but does not provide fine-grained percentage-based traffic splitting or easy rollback of a subset of users. Option C is wrong because blue-green runs two full environments and switches all traffic at once (or via DNS/load balancer cutover), not gradually. Option D is wrong because recreate stops the old version entirely before starting the new one, causing downtime and offering no gradual traffic shift.

Full explanation →
319
MCQeasy

Which of the following is a key principle of microservices architecture?

A.Shared database schema for all services
B.Tight coupling between services
C.Loose coupling and independent deployability
D.Building a large, monolithic codebase
AnswerC

Loose coupling lets each microservice evolve, scale and be deployed without coordinated releases of other services, since communication occurs through well-defined APIs rather than shared internal state. Independent deployability is the operational outcome that enables frequent, low-risk releases.

Why this answer

Microservices architecture emphasizes breaking an application into small, independently deployable services that communicate over well-defined APIs. The correct answer is C: Loose coupling and independent deployability are key principles. Option A (shared database) contradicts the principle of service autonomy.

Option B (tight coupling) is the opposite of what microservices aim for. Option D (monolithic codebase) is what microservices avoid.

Full explanation →
320
MCQmedium

When creating a Deployment, you want to ensure that only a certain number of pods run at a time across all nodes. Which field in the Deployment spec controls this?

A.spec.replicas
B.spec.selector
C.spec.minReadySeconds
D.spec.template
AnswerA

`spec.replicas` declares the desired number of identical pod replicas the ReplicaSet maintains cluster-wide, so the Deployment controller continuously reconciles actual pod count towards it across all nodes. This directly satisfies the stem's constraint of limiting how many pods run concurrently, independent of node placement.

Why this answer

The `spec.replicas` field in a Deployment spec defines the desired number of identical Pod replicas that should be running at any given time. This field directly controls the count of Pods across all nodes in the cluster, ensuring that exactly that many Pods are maintained by the ReplicaSet controller. Option A is correct because it is the only field that sets the target Pod count.

Exam trap

The trap here is that candidates confuse `spec.replicas` with `spec.selector`, thinking the selector controls the number of Pods, but the selector only determines which Pods are managed, not how many.

How to eliminate wrong answers

Option B is wrong because `spec.selector` defines a label query used to identify which Pods the Deployment manages, not the number of Pods. Option C is wrong because `spec.minReadySeconds` controls the minimum time a Pod must be ready before it is considered available, not the number of Pods. Option D is wrong because `spec.template` defines the Pod template (containers, volumes, etc.) used to create new Pods, not the desired count.

Full explanation →
321
MCQmedium

A developer has created a Deployment with 3 replicas. The application should be reachable from other Pods within the same cluster. Which Kubernetes resource should be used to provide a stable network endpoint?

A.Ingress
B.Service
C.PersistentVolumeClaim
D.ConfigMap
AnswerB

A Service supplies a stable virtual IP and DNS name that load-balances across the Deployment's three Pods, satisfying the requirement for reachability from other Pods inside the cluster. Because Pod IPs are ephemeral, only a Service provides the consistent endpoint ClusterIP access demands.

Why this answer

A Service provides a stable network endpoint (ClusterIP) that load-balances traffic across the Pod replicas, abstracting away Pod IP changes due to restarts or scaling. This allows other Pods within the cluster to reach the application reliably using the Service's DNS name, without needing to track individual Pod IPs.

Exam trap

CNCF often tests the misconception that an Ingress is required for any network access, but the trap here is that Ingress is only for external (north-south) traffic, while internal Pod-to-Pod communication uses a Service.

How to eliminate wrong answers

Option A is wrong because an Ingress is an API object that manages external HTTP/HTTPS access to Services, not internal cluster communication; it requires a Service to route traffic to Pods. Option C is wrong because a PersistentVolumeClaim is used to request storage resources, not to provide a network endpoint for Pod-to-Pod communication. Option D is wrong because a ConfigMap is used to inject configuration data (e.g., environment variables, files) into Pods, not to expose a stable network address.

Full explanation →
322
MCQmedium

What is the primary function of a service mesh like Istio?

A.To build container images
B.To handle inter-service communication with features like traffic control and security
C.To manage container orchestration
D.To provide persistent storage for stateful applications
AnswerB

Istio provides a dedicated infrastructure layer that intercepts all service-to-service traffic via sidecar proxies, delivering traffic routing, mutual TLS, and policy enforcement. This directly satisfies the stem's requirement for managing inter-service communication rather than merely deploying or monitoring individual services.

Why this answer

A service mesh provides observability, traffic management, and security for microservices communication.

Full explanation →
323
MCQmedium

You need to store a sensitive database password in Kubernetes. Which resource should you use?

A.PersistentVolume
B.ConfigMap
C.ServiceAccount
D.Secret
AnswerD

Secrets store base64-encoded data separately from pod specs and images, satisfying the need to keep credentials out of container definitions. They can be mounted as volumes or injected as environment variables, and access is restricted via RBAC and encryption at rest.

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 securely by pods, with access controlled via RBAC. Unlike ConfigMaps, Secrets are not intended for non-sensitive configuration and provide a layer of separation for confidential information.

Exam trap

The most common mistake is selecting ConfigMap instead of Secret, because both can hold key-value data, but Secret is designed for sensitive information and provides base64 encoding as a basic security measure, while ConfigMap is for non-sensitive configuration.

How to eliminate wrong answers

Option A is wrong because a PersistentVolume is a storage abstraction for persistent data (e.g., files) and is not designed to store small, sensitive configuration values like passwords. Option B is wrong because a ConfigMap stores non-sensitive configuration data in plain text (or base64 if manually encoded) and lacks the security context and RBAC controls that Secrets provide for sensitive information. Option C is wrong because a ServiceAccount is an identity for pods to authenticate to the Kubernetes API server, not a resource for storing secrets or passwords.

Full explanation →
324
MCQmedium

A pod is experiencing high memory usage. The administrator wants to enforce that the pod is terminated if it exceeds a memory limit and restarted automatically, but also wants to guarantee a minimum amount of memory for the pod. Which resource specification should be used in the container definition?

A.spec.containers[].resources.requests.memory only
B.spec.containers[].resources.limits.memory and requests.cpu
C.spec.containers[].resources.limits.memory only
D.spec.containers[].resources.requests.memory and limits.memory
AnswerD

Requests reserve guaranteed memory for scheduling, while limits set the ceiling the kubelet enforces; exceeding the limit triggers an OOM kill and the container restarts per its restartPolicy. Together they satisfy both the guarantee and termination requirements.

Why this answer

Setting both `requests.memory` and `limits.memory` guarantees a minimum memory allocation (the request) while enforcing a hard cap (the limit). If the pod exceeds the memory limit, it is terminated (OOMKilled) and, if part of a Deployment or StatefulSet, the controller automatically restarts it. This satisfies the requirement for both guaranteed minimum and enforced maximum with automatic restart.

Exam trap

CNCF often tests the misconception that setting only `limits.memory` is sufficient for both guarantee and enforcement, but without `requests.memory` the pod has no guaranteed minimum and may be evicted under node pressure, failing the 'guarantee a minimum' requirement.

How to eliminate wrong answers

Option A is wrong because `requests.memory` only sets the minimum guaranteed memory but does not enforce any upper limit; the pod could consume unlimited memory and cause node instability. Option B is wrong because `limits.memory` and `requests.cpu` do not address memory limits at all — `requests.cpu` only guarantees CPU, not memory, so the pod could still exceed memory without being terminated. Option C is wrong because `limits.memory` alone enforces a hard cap but does not guarantee a minimum memory allocation; the pod could be starved or evicted if the node is under pressure, failing the 'guarantee a minimum amount of memory' requirement.

Full explanation →
325
MCQhard

A microservice application is experiencing high latency during traffic spikes. The team identifies that the database connection pool is exhausted. They want to implement a pattern that helps decouple the microservice from direct database connections and smooth out traffic bursts. Which design pattern should they apply?

A.Bulkhead pattern
B.Circuit Breaker pattern
C.Queue-based Load Leveling pattern
D.Retry pattern
AnswerC

Queue-based Load Leveling inserts a queue between the microservice and database, letting producers enqueue requests while consumers drain them at a controlled rate. This decouples direct database connections and absorbs traffic bursts, preventing connection pool exhaustion.

Why this answer

The Queue-based Load Leveling pattern uses a message queue (e.g., RabbitMQ, Amazon SQS) as a buffer between the microservice and the database. When traffic spikes occur, requests are queued and processed at a manageable rate, preventing the database connection pool from being exhausted. This decouples the service from direct database connections and smooths out bursts, directly addressing the latency issue.

Exam trap

CNCF often tests the distinction between patterns that handle failures (Circuit Breaker, Retry) versus patterns that manage load (Queue-based Load Leveling), and the trap here is that candidates confuse 'smoothing traffic bursts' with 'preventing repeated failures,' leading them to pick the Circuit Breaker or Retry pattern incorrectly.

How to eliminate wrong answers

Option A is wrong because the Bulkhead pattern isolates resources (e.g., thread pools) within a service to prevent cascading failures, but it does not buffer traffic spikes or decouple from database connections. Option B is wrong because the Circuit Breaker pattern monitors for failures and opens the circuit to stop requests temporarily, but it does not smooth out traffic bursts or prevent connection pool exhaustion during spikes. Option D is wrong because the Retry pattern automatically retries failed operations, but it can exacerbate connection pool exhaustion by adding more load during traffic spikes, not decouple or level the load.

Full explanation →
326
MCQmedium

A pod is stuck in the 'Pending' state. You run 'kubectl describe pod mypod' and see the event: '0/3 nodes are available: 1 node had taint that the pod didn't tolerate, 2 Insufficient cpu.' What is the most likely cause?

A.The pod's liveness probe is failing
B.The pod's resource requests exceed available node capacity and a node taint is not tolerated
C.The pod's container runtime is not installed
D.The pod's image pull secret is missing
AnswerB

The scheduler events show two independent blockers: insufficient CPU on two nodes and an untolerated taint on the third. The pod's resource requests exceed schedulable capacity, and no node both satisfies those requests and tolerates the taint.

Why this answer

The pod is in 'Pending' state because the scheduler cannot find a node that meets its requirements. The event '0/3 nodes are available: 1 node had taint that the pod didn't tolerate, 2 Insufficient cpu' directly indicates that the pod's resource requests exceed the available CPU on two nodes, and the remaining node has a taint that the pod does not tolerate. This matches option B: the pod's resource requests exceed available node capacity and a node taint is not tolerated.

Exam trap

The trap here is that candidates may confuse 'Pending' state with post-scheduling issues like probe failures or image pull errors, but the event message explicitly points to scheduling failures (resource insufficiency and taint intolerance), which are the only reasons a pod remains unscheduled.

How to eliminate wrong answers

Option A is wrong because a failing liveness probe would cause the pod to be restarted or marked as 'CrashLoopBackOff', not stuck in 'Pending' — liveness probes only run after the pod is scheduled and started. Option C is wrong because if the container runtime were not installed, the kubelet would report a 'ContainerRuntimeNotReady' condition, and the pod would not even be considered for scheduling; the scheduler would not produce 'Insufficient cpu' events. Option D is wrong because a missing image pull secret would cause an 'ImagePullBackOff' or 'ErrImagePull' error after the pod is scheduled, not a 'Pending' state with resource-related scheduling failures.

Full explanation →
327
MCQmedium

In distributed tracing, what is a 'span'?

A.A metric measuring request latency
B.A single logical operation within a trace
C.A collection of related traces
D.A log entry with trace context
AnswerB

A span represents one logical operation within a trace, carrying its own operation name, start and end timestamps, duration, and parent-child relationships. This granular unit lets you break a distributed request into discrete steps, satisfying the stem's requirement for the building block that composes a trace.

Why this answer

A span represents a single logical operation within a trace, such as an HTTP request, a database query, or a function call. It has a start time, duration, and metadata, and spans are nested to form the trace tree. This is the fundamental unit of work in distributed tracing.

Exam trap

KCNA often tests the distinction between a span and a trace, catching candidates who think a span is a collection of traces or a metric rather than a single operation.

How to eliminate wrong answers

Option A is wrong because a metric is a numeric measurement aggregated over time (e.g., latency percentiles), not a discrete operation with parent-child relationships. Option C is wrong because a collection of related traces is a trace or a trace group, not a span; spans are the components of a trace, not the other way around. Option D is wrong because a log entry with trace context is a log correlated to a trace, not a span itself; spans are structured timing records, not log messages.

Full explanation →
328
MCQmedium

A developer creates a Deployment with 3 replicas. The developer runs 'kubectl get pods' immediately after creation and sees that only 1 pod is in Running state, and the other 2 are Pending. What is the most likely reason for this?

A.The cluster does not have enough resources (CPU/memory) to schedule the additional pods
B.The Deployment's YAML has a syntax error
C.The container image is not available on the worker nodes
D.The kubelet on the node is not running
AnswerA

Pending means the scheduler cannot bind the pod to a node. With 3 replicas requested, insufficient allocatable CPU or memory across nodes leaves the extra pods unschedulable, so they remain Pending rather than failing or restarting.

Why this answer

When a Pod remains in Pending state, it indicates that the scheduler cannot find a suitable node to place it. The most common cause is insufficient cluster resources (CPU or memory) to accommodate the additional Pods, as the scheduler checks node allocatable resources against Pod resource requests. With 2 out of 3 Pods pending, the cluster likely has enough resources for only one replica, leaving the others unscheduled.

Exam trap

CNCF often tests the distinction between Pod lifecycle phases — Pending means scheduling failure, not image or runtime issues — so candidates mistakenly associate Pending with image pull errors or node problems rather than resource insufficiency.

How to eliminate wrong answers

Option B is wrong because a syntax error in the Deployment YAML would cause the API server to reject the resource creation entirely, resulting in no Pods being created at all, not a mix of Running and Pending Pods. Option C is wrong because if the container image were unavailable, the Pods would transition to ImagePullBackOff or ErrImagePull state, not remain Pending — Pending means scheduling hasn't occurred yet. Option D is wrong because if the kubelet were not running on a node, that node would be marked as NotReady, but the scheduler would still attempt to schedule Pods to other nodes; the issue here is that no node has enough resources, not that a node is offline.

Full explanation →
329
Multi-Selectmedium

Which two components are part of the Kubernetes control plane? (Select two.)

Select 2 answers
A.etcd
B.kube-proxy
C.kube-apiserver
D.kubelet
E.container runtime
AnswersA, C

etcd is the control plane's distributed key-value store, holding all cluster state and configuration. The API server reads and writes exclusively to it, making etcd a core control plane component rather than a node-level one.

Why this answer

etcd (A) is correct because it is the control plane's distributed key-value store that persists all cluster state and configuration data, and kube-apiserver (C) is correct because it is the control plane component that exposes the Kubernetes API and serves as the front end through which all other components communicate. The other options are node-level components, not control plane components: kube-proxy (B) maintains network rules for Service traffic on each node, kubelet (D) runs on each node to manage Pods and containers, and the container runtime (E) is the software on each node that actually runs containers.

Exam trap

A common trap is confusing control plane components (etcd, kube-apiserver, kube-controller-manager, kube-scheduler) with node-level components like kubelet, kube-proxy, and the container runtime. Candidates often select kube-proxy or kubelet, which run on every node, instead of the centralized control plane services.

Full explanation →
330
Multi-Selectmedium

Which TWO statements about containers are true compared to virtual machines? (Select TWO.)

Select 2 answers
A.Containers are more lightweight and start faster than VMs
B.Containers include a full guest operating system
C.Containers are more portable across different environments
D.Containers provide stronger isolation than VMs
E.Containers require a hypervisor to run
AnswersA, C

Because they share the host kernel and do not need to boot an OS, containers are lightweight and start quickly.

Why this answer

Containers share the host OS kernel and run as isolated processes, requiring no hypervisor or full OS boot. This makes them lightweight (megabytes vs gigabytes) and allows them to start in milliseconds, whereas VMs must boot a full guest OS, which takes seconds to minutes.

Exam trap

A common pitfall in CNCF exams is believing containers provide stronger isolation than VMs, but VMs offer hardware-level isolation via a hypervisor, while containers rely on kernel-level isolation which is inherently weaker.

Full explanation →
331
MCQmedium

Which component is responsible for aggregating metrics from Kubernetes nodes and exposing them to the metrics API?

A.Prometheus Server
B.Grafana
C.metrics-server
D.Fluentd
AnswerC

metrics-server collects resource metrics from kubelets on each node, aggregates them, and serves them through the metrics API, which Horizontal Pod Autoscalers and kubectl top consume. It satisfies the requirement for node metric aggregation and API exposure.

Why this answer

The metrics-server is the correct component because it is specifically designed to collect resource metrics (CPU and memory) from the kubelet on each node via the Summary API and expose them through the Kubernetes Metrics API. This allows tools like `kubectl top` and the Horizontal Pod Autoscaler to access real-time resource usage without requiring a full monitoring stack.

Exam trap

The trap here is that candidates often confuse Prometheus (a full monitoring system) with the metrics-server (a lightweight, Kubernetes-native component for the Metrics API), assuming Prometheus is required for `kubectl top` or HPA when in fact the metrics-server is the dedicated and simpler solution.

How to eliminate wrong answers

Option A is wrong because Prometheus Server is a full monitoring and alerting system that scrapes metrics from various endpoints, but it is not the component responsible for aggregating metrics from nodes and exposing them to the Kubernetes Metrics API; it typically scrapes the metrics-server or kubelet directly. Option B is wrong because Grafana is a visualization and dashboarding tool that queries data sources like Prometheus or metrics-server, but it does not aggregate or expose metrics to the Metrics API. Option D is wrong because Fluentd is a log collector and forwarder used for log aggregation, not for collecting or exposing resource metrics to the Kubernetes Metrics API.

Full explanation →
332
MCQeasy

An organization wants to adopt a cloud-native approach for its new application. Which characteristic is most important for the application to be considered cloud-native?

A.It stores all state in local files on the container filesystem.
B.It is designed to be resilient, scalable, and manageable in a dynamic environment.
C.It runs as a single monolithic process for simplicity.
D.It is deployed exclusively on on-premises infrastructure.
AnswerB

Resilience, scalability and manageability in a dynamic environment define cloud-native design, satisfying the stem's demand for a cloud-native approach rather than mere cloud hosting. Unlike lift-and-shift workloads, such applications tolerate node failure, scale horizontally, and are orchestrated declaratively, aligning with CNCF principles and Kubernetes-based platforms.

Why this answer

Cloud-native applications are fundamentally defined by their ability to operate in dynamic, distributed environments. They leverage principles like microservices, containerization, and orchestration (e.g., Kubernetes) to achieve resilience, scalability, and manageability. This characteristic is the core tenet of cloud-native architecture as defined by the CNCF, enabling the app to handle failures gracefully and scale on demand.

Exam trap

CNCF often tests the misconception that cloud-native simply means 'running in containers' or 'using Kubernetes,' but the defining characteristic is the architectural property of being resilient, scalable, and manageable in a dynamic environment, not the deployment technology itself.

How to eliminate wrong answers

Option A is wrong because storing state in local container filesystems violates the cloud-native principle of statelessness; containers are ephemeral, and local state is lost on restart, making the application non-resilient and unscalable. Option C is wrong because a monolithic process contradicts the cloud-native preference for microservices, which allow independent scaling, deployment, and fault isolation; monoliths become bottlenecks in dynamic environments. Option D is wrong because cloud-native applications are designed to be infrastructure-agnostic and typically run in multi-cloud or hybrid environments, not exclusively on-premises; being tied to on-premises infrastructure limits portability and cloud benefits.

Full explanation →
333
MCQeasy

In GitOps with ArgoCD, what does 'self-healing' refer to?

A.Automatically scaling applications based on metrics
B.Automatically restarting failed pods
C.Automatically reverting manual changes to match the Git repository
D.Automatically updating the Git repository when changes are made in the cluster
AnswerC

Self-healing means ArgoCD continuously compares live cluster state against the desired state declared in Git. When drift is detected, it automatically reapplies the Git version, discarding manual kubectl edits so the repository remains the single source of truth.

Why this answer

In ArgoCD, self-healing refers to the automatic reconciliation of the live cluster state with the desired state defined in Git. When a manual change is made to a resource in the cluster (e.g., editing a Deployment), ArgoCD detects the drift and automatically reverts the resource to match the Git repository. This ensures that Git remains the single source of truth and prevents configuration drift.

Exam trap

KCNA often tests the confusion between self-healing and other automated actions like scaling or restarting pods, but the key is that self-healing specifically reverts manual changes to match Git.

How to eliminate wrong answers

Option A is wrong because automatic scaling based on metrics is the function of Horizontal Pod Autoscaler (HPA) or similar tools, not ArgoCD's self-healing. Option B is wrong because automatically restarting failed pods is typically handled by Kubernetes controllers like ReplicaSet or liveness probes, not by ArgoCD's self-healing feature. Option D is wrong because automatically updating the Git repository when changes are made in the cluster is the opposite of GitOps principles; ArgoCD does not push changes to Git, it only pulls from Git to sync the cluster.

Full explanation →
334
MCQhard

A pod has resource requests: cpu: 250m, memory: 512Mi and limits: cpu: 500m, memory: 1Gi. If the container tries to use 600m CPU and 700Mi memory, what will happen?

A.The container will be allowed to use the extra resources because limits are only soft constraints
B.The container will be throttled for CPU and may be terminated if it continues to exceed the limit
C.The container will be throttled for CPU, but will not be killed because memory is within limits
D.The container will be killed immediately because it exceeded its CPU limit
AnswerC

CPU is a compressible resource, so exceeding the 500m limit triggers CFS throttling rather than termination. Memory is incompressible, but 700Mi stays below the 1Gi limit, so no OOM kill occurs. The constraint satisfied is that only memory overage causes container termination.

Why this answer

CPU is a compressible resource: exceeding the CPU limit (500m) causes throttling, not termination. Memory is a non-compressible resource, and since the container's memory usage (700Mi) is below its limit (1Gi), it will not be killed. The container will be CPU-throttled but allowed to continue running.

Exam trap

The trap here is that candidates often confuse compressible (CPU) and non-compressible (memory) resources, incorrectly assuming that exceeding any limit leads to termination, whereas CPU only causes throttling and memory causes termination.

How to eliminate wrong answers

Option A is wrong because Kubernetes limits are hard constraints enforced by the kubelet and container runtime, not soft constraints; exceeding CPU limits causes throttling, and exceeding memory limits can cause termination. Option B is wrong because while the container will be throttled for CPU, it will not be terminated solely for exceeding the CPU limit; termination only occurs for memory limit violations or other OOM scenarios. Option D is wrong because CPU limits do not cause immediate termination; the container is throttled at the cgroup level, and only memory limit violations lead to OOM kills.

Full explanation →
335
MCQhard

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 4 Insufficient memory'. What is the most likely cause?

A.All nodes have taints that the pod cannot tolerate
B.The pod's liveness probe is failing
C.The container image is not found
D.The pod requires more memory than any node can allocate
AnswerD

The scheduler's memory predicate compares the pod's memory request against each node's allocatable memory. All four nodes fail this filter, leaving no feasible node, so the pod remains Pending until requests are lowered or capacity added.

Why this answer

The error message '0/4 nodes are available: 4 Insufficient memory' directly indicates that the pod's memory request exceeds the allocatable memory on every node in the cluster. The Kubernetes scheduler evaluates resource requests (spec.containers[].resources.requests.memory) against node capacity, and if no node can satisfy the request, the pod remains in Pending state.

Exam trap

Kubernetes certification exams often test the distinction between scheduling failures (Pending) and runtime errors (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly associate image or probe issues with Pending state instead of recognizing the scheduler's resource check.

How to eliminate wrong answers

Option A is wrong because taints and tolerations produce a different error message, such as '0/4 nodes are available: 4 node(s) had taint {key:value} that the pod didn't tolerate', not 'Insufficient memory'. Option B is wrong because a failing liveness probe would cause the pod to be restarted or become CrashLoopBackOff, not stuck in Pending; Pending occurs before the pod is scheduled to a node. Option C is wrong because an image-not-found error results in ErrImagePull or ImagePullBackOff after scheduling, not a Pending state with a scheduling failure message.

Full explanation →
336
MCQmedium

Which resource provides stable network endpoints to a set of pods, regardless of pod IP changes?

A.ConfigMap
B.Service
C.Deployment
D.Ingress
AnswerB

A Service assigns a stable virtual IP and DNS name, load-balancing traffic to backing pods selected by labels. This satisfies the stable-endpoint requirement, since pod IPs change on recreation, whereas the Service's ClusterIP persists for the Service's lifetime.

Why this answer

A Service provides a stable virtual IP and DNS name that remains constant even as pods are created, destroyed, or rescheduled. It uses label selectors to dynamically route traffic to the backing pods, abstracting away their individual IP changes. This is the core mechanism for reliable network endpoints in Kubernetes.

Exam trap

A common trap is confusing a Service's stable network endpoint role with a Deployment's pod lifecycle management role, leading candidates to incorrectly choose Deployment.

How to eliminate wrong answers

Option A is wrong because a ConfigMap is used to store non-confidential configuration data as key-value pairs, not to provide network endpoints. Option C is wrong because a Deployment manages the desired state of replica sets and pods, but does not expose a stable network endpoint; pods managed by a Deployment still have ephemeral IPs. Option D is wrong because an Ingress is a layer 7 resource that routes external HTTP/HTTPS traffic to Services, not directly to pods, and it depends on a Service for stable endpoints.

Full explanation →
337
Multi-Selecthard

Which THREE of the following are benefits of using an event-driven architecture? (Choose three.)

Select 3 answers
A.Simpler debugging and tracing
B.Better resilience through decoupled components
C.Improved scalability through asynchronous processing
D.Reduced need for monitoring
E.Loose coupling between services
AnswersB, C, E

Because producers publish to a broker rather than calling consumers directly, a failed consumer does not cascade failure upstream; events queue until recovery. This decoupling delivers the resilience benefit the stem asks for, unlike tightly coupled synchronous invocation.

Why this answer

Option B is correct because event-driven architecture decouples producers from consumers, so if one component fails or is slow, others can continue operating and events can be buffered or retried, improving overall resilience. Option C is correct because asynchronous processing lets events be queued and consumed independently, allowing components to scale out horizontally based on event volume rather than being blocked by synchronous calls. Option E is correct because services communicate through events via a broker or event bus rather than direct point-to-point calls, which reduces dependencies and enforces loose coupling between services.

Option A is not correct because event-driven systems typically make debugging and tracing harder, since flows span multiple asynchronous hops and require correlation IDs and distributed tracing. Option D is not correct because event-driven architectures still require robust monitoring, observability, and alerting to track event flows, broker health, and consumer lag.

Exam trap

KCNA often tests the misconception that event-driven architectures simplify operations; in reality they trade synchronous simplicity for asynchronous complexity, so 'simpler debugging' and 'reduced monitoring' are always wrong.

Full explanation →
338
MCQhard

A pod is running but you need to view the contents of a file '/var/log/app.log' inside the container to debug an issue. Which kubectl command allows you to do this without modifying the pod?

A.kubectl logs pod-name -c container-name --tail=100
B.kubectl cp pod-name:/var/log/app.log -
C.kubectl exec pod-name -- cat /var/log/app.log
D.kubectl attach pod-name
AnswerC

`kubectl exec` opens a stream into the already-running container's namespace, so `cat` reads `/var/log/app.log` from the container's own filesystem without restarting or altering the pod. This satisfies the stem's constraint of inspecting a live container's file contents non-destructively, unlike `logs`, `cp`, or `describe`.

Why this answer

`kubectl exec pod-name -- cat /var/log/app.log` runs the `cat` command inside the container without modifying the pod or its state. This allows you to view the file contents directly from the container's filesystem, which is essential for debugging when the application logs are not written to stdout/stderr and thus not accessible via `kubectl logs`.

Exam trap

The trap here is that candidates often confuse `kubectl logs` with reading arbitrary files, assuming it can retrieve any log file, when in fact it only captures container stdout/stderr streams, while `kubectl exec` is the correct tool for accessing files inside a container.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` only retrieves logs written to the container's stdout/stderr streams, not arbitrary files like `/var/log/app.log`. Option B is wrong because `kubectl cp` is used to copy files between a pod and the local machine, but the syntax shown (`kubectl cp pod-name:/var/log/app.log -`) is incomplete and would fail; the correct usage requires a local destination path, and even then it modifies the pod's filesystem only if copying into the pod, but here it attempts to copy out, which does not modify the pod but the command as given is invalid. Option D is wrong because `kubectl attach` attaches to the container's main process (usually PID 1) and streams its stdout/stderr, which does not allow you to read an arbitrary file and typically interferes with the running process.

Full explanation →
339
MCQmedium

A Deployment named 'web' has 3 replicas. You run 'kubectl scale deployment web --replicas=5'. What will happen?

A.Two additional Pods are created to reach a total of 5 replicas.
B.An error occurs because scaling a Deployment is not allowed.
C.The Deployment is updated and all Pods are restarted.
D.The existing Pods are deleted and 5 new Pods are created.
AnswerA

Scaling the Deployment updates its desired replica count to 5, so the ReplicaSet controller creates two additional Pods to reconcile actual state with desired state. The existing three Pods remain untouched, satisfying the stem's requirement of reaching a total of 5 replicas without recreating running workloads.

Why this answer

The `kubectl scale` command adjusts the replica count of a Deployment to the desired number. Since the Deployment currently has 3 replicas and the command sets `--replicas=5`, the ReplicaSet controller creates 2 additional Pods to match the desired state. No existing Pods are deleted or restarted unless the Pod template changes.

Exam trap

The trap here is confusing scaling with a rolling update — candidates often think changing the replica count restarts all Pods, but scaling only adjusts the number of Pods without modifying their configuration.

How to eliminate wrong answers

Option B is wrong because scaling a Deployment is a fundamental and allowed operation in Kubernetes; the `scale` subcommand is explicitly designed for this purpose. Option C is wrong because scaling does not update the Pod template (e.g., container image or environment variables), so no rolling update or restart of existing Pods occurs. Option D is wrong because scaling only adds or removes Pods to reach the target count; existing Pods are not deleted unless the replica count is reduced.

Full explanation →
340
Multi-Selecthard

Which three components are part of the Kubernetes control plane? (Select THREE)

Select 3 answers
A.etcd
B.kube-apiserver
C.kube-proxy
D.kube-controller-manager
E.kubelet
AnswersA, B, D

etcd is the control plane's distributed key-value store, persisting all cluster state and configuration. It is one of the three core control plane components named in the KCNA syllabus, alongside the kube-apiserver and kube-controller-manager, so it satisfies the question's requirement for a control plane member.

Why this answer

etcd (A) is correct because it is the control plane's distributed key-value store that persists all cluster state and object data. kube-apiserver (B) is correct because it is the central control plane component that exposes the Kubernetes API and is the front end through which all other components communicate. kube-controller-manager (D) is correct because it runs the built-in controller loops that reconcile cluster state toward the desired state. kube-proxy (C) is not part of the control plane; it runs on each node to implement Service networking via iptables/IPVS rules. kubelet (E) is also not part of the control plane; it is the node agent that manages Pods and containers on each worker node.

Exam trap

CNCF often tests the distinction between control plane and worker node components, and the trap here is that candidates confuse 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 →
341
MCQeasy

Which Kubernetes control plane component is responsible for maintaining the desired state of the cluster, such as ensuring the correct number of pods are running?

A.kube-controller-manager
B.kube-apiserver
C.kube-scheduler
D.etcd
AnswerA

The kube-controller-manager runs reconciliation loops that continuously compare observed cluster state against the declared desired state, spawning or deleting pods to match a ReplicaSet's replica count. This satisfies the stem's requirement to maintain desired state and correct pod numbers, a duty distinct from the API server's storage role or the scheduler's one-off placement decisions.

Why this answer

The kube-controller-manager is the control plane component that 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 continuously watches the state of the cluster via the kube-apiserver and makes adjustments to reconcile the current state with the desired state defined in the cluster's configuration.

Exam trap

CNCF often tests the distinction between the component that stores state (etcd) and the component that actively reconciles state (kube-controller-manager), leading candidates to mistakenly choose etcd because it holds the desired state data.

How to eliminate wrong answers

Option B is wrong because the kube-apiserver is the front-end for the Kubernetes control plane that exposes the Kubernetes API, handling authentication, authorization, and API requests, but it does not directly manage the desired state of pods or other resources. Option C is wrong because the kube-scheduler is responsible for assigning newly created pods to nodes based on resource availability and constraints, not for maintaining the desired number of running pods. Option D is wrong because etcd is a distributed key-value store that holds the cluster's configuration and state data, but it is a data store, not a controller that actively reconciles desired state.

Full explanation →
342
MCQmedium

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

A.Treat logs as event streams
B.Bind services at build time
C.Use local disk storage for persistence
D.Store configuration in the codebase
AnswerA

Treating logs as event streams satisfies the 12-factor requirement that an app never concern itself with routing or storage of its output. Each running process writes its event stream unbuffered to stdout, letting the execution environment capture, aggregate and route those streams to files or monitoring systems.

Why this answer

The 12-factor app includes the principle of treating logs as event streams, not as files.

Full explanation →
343
MCQmedium

Which command would you run to get a list of all pods in all namespaces?

A.kubectl get pods --namespace=*
B.kubectl get pods --global
C.kubectl get pods --all-namespaces
D.kubectl get pods --include-uninitialized
AnswerC

The --all-namespaces flag instructs kubectl to query every namespace in the cluster, returning pods across all of them in one output, which directly satisfies the requirement to list pods cluster-wide rather than only the current namespace.

Why this answer

`kubectl get pods --all-namespaces` (or its shorthand `-A`) retrieves pods from every namespace in the cluster. This flag overrides the default behavior of `kubectl get pods`, which only returns pods in the current namespace (usually `default`).

Exam trap

CNCF often tests the misconception that a wildcard or global flag exists for namespace selection, leading candidates to choose `--namespace=*` or `--global` instead of the correct `--all-namespaces` flag.

How to eliminate wrong answers

Option A is wrong because `--namespace=*` is not a valid kubectl syntax; the asterisk wildcard is not supported for namespace selection, and kubectl will return an error. Option B is wrong because `--global` is not a valid kubectl flag; it does not exist and would cause a parsing error. Option D is wrong because `--include-uninitialized` is a deprecated flag that was used in older Kubernetes versions to include pods that had not yet been fully initialized, but it does not affect namespace scope and is no longer supported in recent releases.

Full explanation →
344
MCQeasy

Which DORA metric measures the percentage of deployments that cause a failure in production?

A.Deployment Frequency
B.Mean Time to Recovery (MTTR)
C.Change Failure Rate
D.Lead Time for Changes
AnswerC

Change Failure Rate directly quantifies the proportion of production deployments that result in degraded service or require remediation, such as a hotfix or rollback. This precisely matches the stem's requirement to measure the percentage of deployments causing production failures, distinguishing it from deployment frequency, lead time, and mean time to restore.

Why this answer

Change Failure Rate is the percentage of changes that result in a failure (e.g., service degradation, rollback). It is one of the four key DORA metrics.

Full explanation →
345
Multi-Selecthard

Which THREE of the following are key characteristics of microservices architecture?

Select 3 answers
A.Independent deployment of services
B.Decomposition by business capability
C.Single monolithic codebase
D.Shared database schema across services
E.Loose coupling between services
AnswersA, B, E

Each microservice can be deployed independently.

Why this answer

Microservices architecture mandates that each service can be independently deployed, updated, and scaled without affecting other services. This is achieved through separate deployment pipelines, containerization (e.g., Docker), and orchestration platforms like Kubernetes that manage service lifecycles independently. Independent deployment enables continuous delivery and reduces the blast radius of changes.

Exam trap

A common misconception is that microservices can share a single database or persistent volume in Kubernetes for simplicity. However, each service should own its data to maintain loose coupling and independent deployability within a Kubernetes cluster.

Full explanation →
346
MCQeasy

What is the primary purpose of the Kubernetes control plane component 'kube-apiserver'?

A.Run container runtime operations on nodes
B.Schedule pods onto nodes
C.Store cluster state and configuration
D.Expose the Kubernetes REST API and act as the entry point for all administrative tasks
AnswerD

kube-apiserver exposes the Kubernetes REST API, making it the sole entry point for administrative tasks: every kubectl command, controller and scheduler request flows through it for authentication, authorisation and admission before persisting state to etcd. This satisfies the stem's requirement for the control plane's central API gateway role.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane, exposing the Kubernetes REST API. It validates and processes all administrative requests (e.g., creating pods, scaling deployments) and is the only component that directly interacts with the etcd datastore. This makes it the central entry point for all cluster management tasks, aligning with option D.

Other options are incorrect: A describes the kubelet, B describes the kube-scheduler, and C describes etcd.

Exam trap

A common misconception is that the kube-apiserver stores cluster state, when in fact it only mediates access to etcd, which is the actual persistent store.

How to eliminate wrong answers

Option A is wrong because running container runtime operations on nodes is the responsibility of the kubelet, not the kube-apiserver. Option B is wrong because scheduling pods onto nodes is performed by the kube-scheduler, which watches for unscheduled pods and assigns them to nodes based on resource availability and constraints. Option C is wrong because storing cluster state and configuration is the role of etcd, a distributed key-value store; the kube-apiserver reads from and writes to etcd but does not itself store the data.

Full explanation →
347
MCQmedium

In a blue-green deployment strategy, at any given time, only one environment (blue or green) is active. What is the primary advantage of this approach?

A.Gradual traffic shifting to detect issues early
B.Instant rollback by switching traffic back to the previous environment
C.Minimal resource consumption by using only one environment
D.No need for load balancers or ingress controllers
AnswerB

Because the previous environment remains fully deployed and idle, reverting is simply a matter of repointing the router or load balancer, giving near-instantaneous rollback. This satisfies the stem's single-active-environment constraint while minimising downtime risk during release.

Why this answer

Blue-green deployments allow instant rollback by switching traffic back to the previous environment. This is the primary advantage: if issues arise in the new version, you can immediately revert by pointing the router/load balancer to the old environment. Option A describes gradual traffic shifting, which is characteristic of canary deployments, not blue-green.

Option C is incorrect because blue-green requires two full environments, doubling resource consumption. Option D is false because a load balancer or ingress controller is essential to switch traffic between the two environments.

Full explanation →
348
MCQeasy

Which of the following is NOT one of the three pillars of observability in cloud-native environments?

A.Metrics
B.Traces
C.Security
D.Logs
AnswerC

The three pillars are metrics, logs and traces, which together describe system state and behaviour. Security is a separate discipline applied across those signals, not a pillar itself, so it is the correct exclusion. This satisfies the question's NOT requirement.

Why this answer

The three pillars are logs, metrics, and traces. Security is not one of them, though it is important.

Full explanation →
349
MCQhard

You need to deploy an application that requires exactly one pod per cluster node for logging purposes. Which Kubernetes workload resource should you use?

A.DaemonSet
B.Job
C.StatefulSet
D.Deployment
AnswerA

A DaemonSet ensures exactly one pod replica runs on every cluster node, satisfying the one-pod-per-node logging constraint. Unlike Deployments, which schedule arbitrary replica counts, DaemonSets automatically add pods to new nodes and remove them when nodes leave the cluster.

Why this answer

A DaemonSet ensures that a copy of a pod runs on every node in the cluster, or on a subset of nodes if a node selector is used. This is the correct resource for deploying a logging agent that must be present on each node to collect logs from that node's containers and system components.

Exam trap

The trap here is that candidates often confuse DaemonSet with Deployment, assuming a Deployment with replicas equal to the node count will achieve the same effect, but Deployments do not guarantee one pod per node and can schedule multiple pods on the same node or leave nodes empty.

How to eliminate wrong answers

Option B (Job) is wrong because a Job creates one or more pods that run to completion and then stop, which is unsuitable for a continuously running logging daemon that must persist on every node. Option C (StatefulSet) is wrong because StatefulSet is designed for stateful applications that require stable, unique network identities and persistent storage, not for ensuring one pod per node. Option D (Deployment) is wrong because a Deployment manages replicas across the cluster without guaranteeing that a pod runs on every node; it uses a scheduler to distribute pods based on resource availability, not node coverage.

Full explanation →
350
MCQmedium

You need to ensure that a set of pods in a Deployment can be reached by other pods using a stable IP address and DNS name. Which Kubernetes object should you use?

A.Service
B.NetworkPolicy
C.Ingress
D.ConfigMap
AnswerA

A Service provides a stable virtual IP address and DNS name that load-balances traffic across the Deployment's pods, satisfying the reachability requirement. Pod IPs are ephemeral, so clients must target the Service rather than individual pod addresses.

Why this answer

A Service provides a stable IP address and DNS name for a set of pods, abstracting the underlying pod IPs that can change due to scaling or failures. By default, a Service uses a cluster-internal virtual IP and DNS record (e.g., <service-name>.<namespace>.svc.cluster.local) that other pods can resolve, ensuring reliable connectivity without needing to track individual pod IPs.

Exam trap

The trap here is that candidates confuse Ingress (external HTTP routing) with internal service discovery, or think NetworkPolicy provides addressing, when only a Service offers a stable virtual IP and DNS name for pod-to-pod communication.

How to eliminate wrong answers

Option B (NetworkPolicy) is wrong because it defines firewall rules for pod-to-pod traffic, not a stable IP or DNS name. Option C (Ingress) is wrong because it manages external HTTP/HTTPS traffic routing to Services, not internal pod-to-pod communication with a stable IP. Option D (ConfigMap) is wrong because it stores configuration data as key-value pairs, not network endpoints.

Full explanation →
351
Multi-Selectmedium

Which TWO components are part of the Kubernetes control plane?

Select 2 answers
A.kube-proxy
B.kubelet
C.etcd
D.kube-apiserver
E.container runtime
AnswersC, D

etcd is the control plane's distributed key-value store, holding all cluster state and configuration. It satisfies the control plane membership criterion because it runs on control plane nodes alongside the API server, scheduler and controller manager, rather than on worker nodes with kubelet and kube-proxy.

Why this answer

etcd (C) is correct because it is the control plane's distributed key-value store that persistently holds all cluster state and configuration data, which the API server reads and writes. kube-apiserver (D) is correct because it is the central control plane component that exposes the Kubernetes API, validates and processes REST requests, and is the front end through which all other components communicate. The other options are node-level components, not control plane components: kube-proxy (A) implements Service networking rules on each node, kubelet (B) runs on each node and manages Pods/containers via the container runtime, and the container runtime (E) is the node software (e.g., containerd, CRI-O) that actually runs containers.

Exam trap

The KCNA exam often tests the misconception that kubelet or kube-proxy are control plane components because they are essential for cluster operation, but they actually run on every node as part of the data plane.

Full explanation →
352
Multi-Selecthard

Which THREE of the following are valid apiVersions for Kubernetes resources?

Select 3 answers
A.batch/v1
B.v1
C.apps/v1
D.extensions/v1beta1
E.v1beta1
AnswersA, B, C

batch/v1 is a genuine, stable Kubernetes API group/version, used by the Job and CronJob resources. It satisfies the stem's requirement for a valid apiVersion, since Kubernetes apiVersions follow the group/version format and batch/v1 remains actively served by current clusters.

Why this answer

The three valid apiVersions here are batch/v1 (A), v1 (B), and apps/v1 (C). batch/v1 is the stable API group/version used for workload resources such as Job and CronJob, so it is a legitimate apiVersion value. v1 is the core (legacy) API group version used for resources like Pod, Service, ConfigMap, and Secret, and it is valid without a group prefix. apps/v1 is the stable API group/version for workloads such as Deployment, StatefulSet, DaemonSet, and ReplicaSet, making it valid as well. The unmarked options do not belong because extensions/v1beta1 (D) is a removed/deprecated API group version no longer served in modern Kubernetes clusters, and v1beta1 (E) is not a complete apiVersion by itself since a beta version must be qualified by its API group (for example, apps/v1beta1 or batch/v1beta1).

Exam trap

The KCNA exam often tests the distinction between core group versions (just 'v1') and named group versions (e.g., 'apps/v1'), and the trap here is that candidates may think 'v1beta1' is valid as a standalone version, not realizing it requires a group prefix, or they may mistakenly consider deprecated versions like extensions/v1beta1 as still valid.

Full explanation →
353
MCQhard

Which of the following is a benefit of using an API gateway pattern?

A.It reduces the number of microservices needed
B.It replaces the need for a service mesh
C.It provides a single entry point for clients and handles cross-cutting concerns
D.It stores application state
AnswerC

An API gateway consolidates disparate backend services behind one client-facing endpoint, so callers avoid coupling to individual service addresses. It also centralises cross-cutting concerns such as authentication, rate limiting, TLS termination and request routing, satisfying the stem's requirement for a single entry point that offloads duplicated logic from every service.

Why this answer

An API gateway sits in front of microservices and provides a single, unified entry point for all external clients, while centralizing cross-cutting concerns such as authentication, rate limiting, TLS termination, request routing, and logging. This decouples clients from the internal service topology, so services can be refactored or scaled without changing client code. It is a traffic-management and policy-enforcement layer, not a compute or storage layer.

Exam trap

KCNA often tests the misconception that an API gateway and a service mesh are interchangeable — candidates must distinguish north-south (gateway) from east-west (mesh) traffic.

How to eliminate wrong answers

Option A is wrong because an API gateway does not reduce the number of microservices — it aggregates and routes to them; the number of services is determined by domain decomposition, not by the gateway. Option B is wrong because a service mesh handles east-west (service-to-service) traffic inside the cluster, whereas an API gateway handles north-south (client-to-service) traffic; they are complementary, not replacements. Option D is wrong because API gateways are stateless proxies — they do not store application state, which belongs in databases or stateful services.

Full explanation →
354
Drag & Dropmedium

Drag and drop the steps for a rolling update of a Kubernetes Deployment into the correct order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Change the image, apply, monitor rollout, verify health, and rollback if issues arise.

Full explanation →
355
MCQmedium

You need to run a batch job that processes data and then exits. Which Kubernetes resource type is most appropriate for this workload?

A.Deployment
B.DaemonSet
C.Job
D.StatefulSet
AnswerC

A Job creates Pods that run to completion and tracks successful termination, which suits batch processing that exits after finishing. Deployments and ReplicaSets instead maintain continuously running replicas, so they restart or replace Pods rather than allowing them to exit cleanly.

Why this answer

A Kubernetes Job is designed for workloads that run to completion and then exit, such as batch processing, data transformation, or one-off tasks. Unlike controllers that maintain a desired number of running Pods (like Deployments), Jobs ensure that a specified number of Pods successfully terminate, making them the correct choice for this scenario.

Exam trap

A common misconception is that any workload requiring Pods must use a Deployment, but the key differentiator is whether the workload is long-running or batch/terminating, which is exactly what the Job resource is designed for.

How to eliminate wrong answers

Option A is wrong because a Deployment is intended for long-running, stateless services that must maintain a specified number of replicas continuously; it will restart Pods if they exit, which is not appropriate for a batch job that should terminate. Option B is wrong because a DaemonSet ensures that a copy of a Pod runs on every (or selected) Node in the cluster, typically for daemon processes like logging or monitoring, not for one-off batch tasks. Option D is wrong because a StatefulSet is used for stateful applications that require stable, unique network identities and persistent storage, such as databases, and is not designed for ephemeral batch processing that exits after completion.

Full explanation →
356
MCQmedium

You run 'kubectl get pods' and see a Pod in the 'Pending' state. Which of the following is a likely cause?

A.No node meets the requested CPU or memory resources
B.The application crashed due to a bug
C.The container image is missing
D.The Pod has been deleted
AnswerA

The scheduler leaves a pod Pending when no node satisfies its resource requests, since it cannot bind the pod anywhere. Insufficient allocatable CPU or memory across all nodes is the classic trigger for this state.

Why this answer

A Pod enters the 'Pending' state when it cannot be scheduled onto a node. The most common reason is that no node in the cluster has sufficient available CPU or memory resources to satisfy the Pod's resource requests. The Kubernetes scheduler continuously evaluates nodes against Pod resource requirements, and if none match, the Pod remains unscheduled in Pending.

Exam trap

The trap here is confusing 'Pending' (scheduling failure) with 'CrashLoopBackOff' (runtime failure) or 'ImagePullBackOff' (image pull failure), leading candidates to pick a wrong answer about application or image issues.

How to eliminate wrong answers

Option B is wrong because an application crash due to a bug would cause the Pod to enter a CrashLoopBackOff or Error state, not Pending. Option C is wrong because a missing container image would result in an ImagePullBackOff or ErrImagePull state, not Pending. Option D is wrong because a deleted Pod would not appear in the output of 'kubectl get pods' at all; it would be removed from the API server.

Full explanation →
357
MCQhard

A cloud-native application uses a service mesh (Istio) for traffic management. The team notices increased latency in inter-service communication. Which likely cause should be investigated first?

A.Kubernetes Network Policies blocking traffic
B.Misconfigured sidecar proxy settings
C.Application code is not optimized for the mesh
D.mTLS encryption overhead
AnswerB

Each Istio sidecar proxies every inbound and outbound request, so an incorrect proxy setting—such as a misconfigured concurrency limit, buffer size or timeout—directly adds per-hop latency to inter-service calls. Inspecting sidecar configuration and Envoy stats isolates this overhead before blaming the application or network.

Why this answer

In Istio, the sidecar proxy (Envoy) intercepts all inbound and outbound traffic for the application container. Misconfigured proxy settings—such as incorrect timeouts, retry policies, or circuit breaker thresholds—can introduce significant latency by causing unnecessary retries, connection delays, or queueing. This is the most common and immediate cause of increased latency in a service mesh, as the data plane is directly in the request path.

Exam trap

CNCF often tests the misconception that mTLS encryption is a major source of latency, but in practice its overhead is negligible compared to misconfigured proxy settings that directly impact request handling.

How to eliminate wrong answers

Option A is wrong because Kubernetes Network Policies operate at the IP/port level and would block traffic entirely rather than cause increased latency; they do not introduce gradual performance degradation. Option C is wrong because application code optimization is a separate concern—the service mesh handles traffic management at the infrastructure layer, and unoptimized code would cause latency regardless of the mesh. Option D is wrong because mTLS encryption overhead in Istio is minimal (typically under 5% latency increase) and is a known, accepted cost of zero-trust security; it would not be the first suspect for a noticeable latency spike.

Full explanation →
358
MCQmedium

A platform engineer is explaining cloud-native architecture to a new team. The team asks which statement BEST describes the relationship between microservices and cloud-native architecture. Which answer is correct?

A.Microservices are the only valid way to build cloud-native applications
B.Cloud-native architecture requires every service to share a single database
C.Microservices are one common architectural style used within cloud-native systems
D.Microservices eliminate the need for observability and monitoring
AnswerC

Microservices are a widely adopted architectural style in cloud-native systems because they support independent deployment, scaling, and fault isolation. However, cloud-native architecture also includes other styles and practices. This statement correctly describes microservices as one common approach rather than the only one, matching the broader definition of cloud-native architecture.

Why this answer

Microservices are a common architectural style within cloud-native systems, valued for independent deployability, scalability, and fault isolation. They are not the only way to be cloud-native, and they do not remove the need for observability or decentralized data. The other statements are either too absolute or contradict established cloud-native practices, so the accurate description is that microservices are one common style.

Exam trap

The trap here is treating microservices as synonymous with cloud-native architecture, when cloud-native is a broader set of principles and practices.

Full explanation →
359
MCQmedium

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

A.To manage service-to-service communication within a cluster
B.To replace DNS for service discovery
C.To act as a single entry point for external clients
D.To directly connect databases to clients
AnswerC

An API gateway fronts all backend microservices, routing external requests to the appropriate service while handling cross-cutting concerns such as authentication and rate limiting. This satisfies the stem's requirement for a single entry point, hiding internal service topology from external clients.

Why this answer

The primary purpose of an API gateway in a microservices architecture is to act as a single entry point for external clients, hiding the internal service topology and centralizing concerns like routing, authentication, and rate limiting. Clients talk only to the gateway, which forwards requests to the appropriate backend microservice. This simplifies client code and allows services to evolve independently.

Exam trap

KCNA often tests the confusion between API gateway (north-south, external entry) and service mesh (east-west, internal service-to-service), causing candidates to pick the service-mesh-related option.

How to eliminate wrong answers

Option A is wrong because service-to-service communication within a cluster is the domain of a service mesh (e.g., Istio, Linkerd) or direct service discovery, not the API gateway, which handles external ingress. Option B is wrong because DNS-based service discovery (e.g., CoreDNS in Kubernetes) resolves service names to ClusterIPs; an API gateway does not replace DNS — it consumes service discovery to route traffic. Option D is wrong because directly connecting databases to clients bypasses the service layer entirely and violates microservice encapsulation; gateways route to services, not databases.

Full explanation →
360
MCQmedium

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

A.Certifying Kubernetes administrators
B.Providing a hosted container registry
C.Defining standards for container images and runtimes
D.Managing the Kubernetes source code
AnswerC

The Open Container Initiative publishes open specifications covering container image formats and runtime behaviour, ensuring portability across compliant engines. This directly addresses the stem's question by defining industry standards for container images and runtimes rather than orchestration or networking.

Why this answer

The Open Container Initiative (OCI) is a Linux Foundation project that defines open industry standards for container formats and runtimes. Specifically, it maintains the OCI Image Specification (which standardizes the container image format, including layers and configuration) and the OCI Runtime Specification (which defines the lifecycle and interface for container runtimes like runc). This ensures interoperability between different container tools and platforms.

Exam trap

The trap here is that candidates confuse the OCI with the CNCF, assuming the OCI manages Kubernetes or its certification, when in fact the OCI focuses solely on container format and runtime standards, while the CNCF oversees Kubernetes and its ecosystem.

How to eliminate wrong answers

Option A is wrong because certifying Kubernetes administrators is the responsibility of the Cloud Native Computing Foundation (CNCF) through the Certified Kubernetes Administrator (CKA) program, not the OCI. Option B is wrong because providing a hosted container registry is a service offered by cloud providers (e.g., Docker Hub, Amazon ECR, Google Container Registry) or self-hosted solutions, not a function of the OCI. Option D is wrong because managing the Kubernetes source code is the role of the CNCF and the Kubernetes community via the Kubernetes GitHub repository; the OCI focuses on container standards, not Kubernetes-specific code.

Full explanation →
361
Multi-Selectmedium

Which TWO of the following are benefits of using a Deployment over managing ReplicaSets directly? (Choose two.)

Select 2 answers
A.Support for stateful workloads
B.Declarative scaling
C.Direct access to pod IP addresses
D.Automatic rolling updates and rollbacks
E.Ability to run a pod on every node
AnswersB, D

A Deployment's spec.replicas field lets you declare the desired pod count, and the Deployment controller reconciles ReplicaSets to match it. Managing ReplicaSets directly requires manual scaling of each set, so declarative scaling is a genuine Deployment benefit.

Why this answer

Option B (Declarative scaling) is correct because a Deployment declares the desired replica count in its spec (spec.replicas), and the Deployment controller continuously reconciles the actual number of pods to match that declared state, so scaling is expressed declaratively rather than by manually editing a ReplicaSet. Option D (Automatic rolling updates and rollbacks) is correct because Deployments manage ReplicaSets under the hood to perform rolling updates via spec.strategy (RollingUpdate with maxSurge/maxUnavailable) and preserve revision history (spec.revisionHistoryLimit) so that kubectl rollout undo can roll back to a previous ReplicaSet. Option A is incorrect because stateful workloads requiring stable identities and persistent per-pod storage are handled by StatefulSets, not Deployments.

Option C is incorrect because pod IP addresses are a function of the cluster network (e.g., CNI-assigned IPs) and are not a Deployment-specific benefit; direct pod access is generally discouraged in favor of Services. Option E is incorrect because running one pod on every node is the purpose of a DaemonSet, not a Deployment.

Exam trap

A common misconception is that Deployments are suitable for stateful workloads or provide direct pod networking, when in fact StatefulSets and Services are the correct solutions for those needs.

Full explanation →
362
MCQeasy

A developer wants to run a one-off database migration task in Kubernetes that must complete successfully and then stop. The task should not restart after successful completion, and the developer wants to inspect logs after it finishes. Which resource should be created?

A.A bare Pod with restartPolicy set to Always
B.A CronJob with schedule set to a date in the past
C.A Deployment with a single replica
D.A Job with restartPolicy set to OnFailure or Never
AnswerD

A Job is designed for run-to-completion workloads. Setting the Pod template's restartPolicy to OnFailure or Never ensures the container is not restarted after it exits successfully. The Job controller tracks successful completions, and the completed Pod remains available for log inspection until manually deleted or cleaned up by a TTL controller.

Why this answer

A Job is the correct resource for run-to-completion tasks. By setting the Pod template's restartPolicy to OnFailure or Never, the container stops after a successful exit, and the Job records completion. The completed Pod remains for log inspection, unlike a Deployment or bare Pod with Always restart policy, which would keep restarting the container.

Exam trap

The trap here is confusing a Job with a Deployment and assuming that a single-replica Deployment will run a task just once.

Full explanation →
363
Multi-Selecthard

Which THREE of the following are important considerations when defining SLOs (Service Level Objectives)? (Select three.)

Select 3 answers
A.They should include an error budget
B.They must be aligned with business impact
C.They must be based on measurable SLIs
D.They define a target percentage over a time window
E.They should minimize infrastructure cost
AnswersB, C, D

An SLO only matters if it reflects what users and the business actually care about, so targets must trace to business impact rather than arbitrary infrastructure metrics. This alignment ensures reliability investment addresses genuine customer-facing risk instead of technical vanity measures.

Why this answer

Option B is correct because SLOs must be aligned with business impact: an SLO only makes sense if the reliability target reflects what users and the business actually need, so the chosen SLI and threshold are tied to a meaningful customer or revenue outcome rather than an arbitrary technical metric. Option C is correct because SLOs must be based on measurable SLIs: an SLO is a target applied to a Service Level Indicator, so the underlying measurement (for example, request latency or success rate) must be quantifiable and observable via monitoring. Option D is correct because SLOs define a target percentage over a time window: a valid SLO takes the form of a target such as 99.9% of successful requests measured over a rolling 30-day window, giving a concrete, time-bounded reliability goal.

Option A is not correct as a defining consideration because the error budget is derived from the SLO (100% minus the SLO target) rather than being a required component when defining the SLO itself. Option E is not correct because minimizing infrastructure cost is a cost-optimization concern, not a criterion for setting reliability objectives, and can even conflict with achieving the intended service level.

Exam trap

KCNA often tests confusion between SLOs and error budgets, tricking candidates into selecting 'include an error budget' as a defining consideration when error budgets are actually derived from SLOs.

Full explanation →
364
Multi-Selectmedium

Which TWO of the following are valid ways to expose a set of pods as a network service in Kubernetes? (Select two.)

Select 1 answer
A.Creating a Deployment with a label selector
B.Creating a PersistentVolumeClaim
C.Creating an Ingress resource
D.Assigning a public IP directly to a Pod
E.Creating a Service of type ClusterIP
AnswersE

ClusterIP allocates a virtual IP reachable only inside the cluster, and kube-proxy load-balances connections across the selected pods. It is the default Service type and a valid way to expose pods internally to other workloads.

Why this answer

Option E (Creating a Service of type ClusterIP) is correct because a ClusterIP Service provides a stable virtual IP and DNS name that load-balances traffic to the set of pods matched by its label selector, which is the fundamental way to expose pods internally. Option A is not correct because a Deployment only manages pod replicas and their labels; it does not itself create a network endpoint or stable service address. Option B is not correct because a PersistentVolumeClaim provides storage, not network exposure.

Option C is not correct because an Ingress exposes Services (via an ingress controller), not pods directly, and therefore is not itself a way to expose a set of pods as a network service. Option D is not correct because assigning a public IP directly to a Pod is not a supported or durable Kubernetes service-exposure mechanism, since pod IPs are ephemeral and not managed as service endpoints.

Exam trap

A common misconception is that a Deployment itself provides network exposure, but a Deployment only manages pod replicas and requires a separate Service resource to expose them as a network service. Another trap is assuming Ingress directly exposes pods; Ingress routes to Services, which then select pods.

Full explanation →
365
Multi-Selectmedium

Which TWO statements are true about cloud-native architecture?

Select 2 answers
A.Applications are typically monolithic for simplicity
B.Infrastructure is treated as immutable
C.Manual scaling is the default approach
D.Services can be scaled independently
E.Stateful components are preferred for performance
AnswersB, D

Immutable infrastructure means servers are never patched or reconfigured in place; changes produce new instances that replace old ones. This eliminates configuration drift, makes deployments reproducible, and enables reliable rollback, which are core cloud-native principles.

Why this answer

Option B is correct because cloud-native architecture treats infrastructure as immutable — servers and containers are provisioned from versioned images and replaced rather than patched in place, which enables consistent, reproducible deployments and supports practices like blue/green and rolling updates. Option D is correct because cloud-native design decomposes applications into loosely coupled microservices that can each be scaled independently (e.g., via Kubernetes Horizontal Pod Autoscaler or similar orchestration), so a hot service can scale out without scaling the entire application. Option A is incorrect because cloud-native favors small, independently deployable microservices over monolithic applications.

Option C is incorrect because autoscaling driven by metrics is the default approach, not manual scaling. Option E is incorrect because cloud-native prefers stateless components with state externalized to managed data services, since statelessness improves scalability, resilience, and portability.

Exam trap

KCNA often tests the misconception that cloud-native simply means 'running in the cloud,' causing candidates to pick monolithic or manual-scaling options that describe traditional on-premises patterns.

Full explanation →
366
MCQeasy

What is the primary purpose of a liveness probe in a container?

A.To check resource usage like CPU and memory
B.To check if the container is still alive; restart if not
C.To check if the container is ready to serve traffic
D.To check if the pod is scheduled on the correct node
AnswerB

A liveness probe periodically tests whether the container process is still responsive; on failure, kubelet restarts the container according to its restart policy. This directly matches the stem's requirement to detect a dead container and restart it.

Why this answer

The primary purpose of a liveness probe is to determine whether a container is still running and healthy. If the probe fails, the kubelet kills the container and restarts it according to the pod's restart policy, ensuring self-healing. This is distinct from readiness probes, which control traffic routing, and resource checks, which are handled by metrics servers or cAdvisor.

Exam trap

The trap here is that candidates confuse liveness probes with readiness probes, often selecting option C because both involve health checks, but liveness probes manage container lifecycle while readiness probes manage traffic routing.

How to eliminate wrong answers

Option A is wrong because checking resource usage like CPU and memory is the job of the metrics server or cAdvisor, not a liveness probe; liveness probes only test application responsiveness via HTTP, TCP, or exec commands. Option C is wrong because checking if the container is ready to serve traffic is the purpose of a readiness probe, which controls whether the pod is added to Service endpoints; a liveness probe does not affect traffic routing. Option D is wrong because checking if the pod is scheduled on the correct node is handled by the Kubernetes scheduler and node affinity rules, not by a liveness probe, which operates at the container level within an already-scheduled pod.

Full explanation →
367
Multi-Selectmedium

Which TWO statements correctly describe how Kubernetes handles self-healing? (Select two.)

Select 2 answers
A.If a node fails, the ReplicaSet controller automatically recreates the pods on healthy nodes
B.If a container in a pod crashes, the kubelet restarts it according to the pod's restart policy
C.Kubernetes automatically fixes application-level bugs by rolling back to a previous version
D.Kubernetes can automatically resolve OOMKilled errors by increasing memory limits
E.Kubernetes can automatically resolve OOMKilled errors by increasing memory limits
AnswersA, B

The ReplicaSet (or Deployment) controller detects that pods are no longer running and creates replacement pods on available nodes.

Why this answer

The ReplicaSet controller monitors the cluster for node failures and, when a node becomes unhealthy, it creates replacement pods on other healthy nodes to maintain the desired replica count. This is a core self-healing mechanism in Kubernetes that operates at the controller level, independent of the kubelet.

Exam trap

CNCF often tests the distinction between automatic self-healing at the infrastructure level (node/pod restarts) versus manual or policy-driven recovery for application-level issues, leading candidates to incorrectly assume Kubernetes automatically fixes bugs or adjusts resource limits.

Full explanation →
368
MCQeasy

What is the smallest deployable unit in Kubernetes?

A.Deployment
B.Container
C.Node
D.Pod
AnswerD

A Pod is the smallest deployable unit in Kubernetes, encapsulating one or more containers that share network and storage namespaces. Containers themselves are not scheduled directly; the scheduler places Pods onto nodes, making them the atomic unit of deployment.

Why this answer

The Pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of a running process in the cluster and encapsulates one or more containers with shared storage and network resources. Deployments manage ReplicaSets, which in turn manage Pods, but the Pod itself is the atomic deployable unit.

Exam trap

The trap here is that candidates often confuse 'container' as the smallest unit because of Docker's standalone container model, but Kubernetes abstracts containers into Pods to enforce co-location and resource sharing.

How to eliminate wrong answers

Option A is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods, not the smallest deployable unit. Option B is wrong because a Container is not a Kubernetes object; it is a runtime instance of a container image that runs inside a Pod. Option C is wrong because a Node is a worker machine in the cluster that hosts Pods, not a deployable unit.

Full explanation →
369
MCQeasy

A user wants to run a one-time batch task that processes a dataset and then exits. The task should not be restarted if it completes successfully. Which Kubernetes resource is most appropriate?

A.Job
B.Deployment
C.StatefulSet
D.DaemonSet
AnswerA

A Job creates one or more Pods and ensures that a specified number of them successfully terminate. It is intended for batch tasks that run to completion. By default, a Job does not restart the Pod if it exits successfully, making it the correct choice for a one-time dataset processing task.

Why this answer

A Job is the Kubernetes resource designed for batch workloads that run to completion. It tracks successful Pod completions and does not restart Pods that exit with success. Deployments, StatefulSets, and DaemonSets are all intended for long-running services and do not provide the same completion guarantees.

Exam trap

The trap here is assuming that any workload controller can run a batch task, but only a Job provides run-to-completion semantics without restarting on success.

Full explanation →
370
MCQmedium

You need to run a batch job that processes a queue and then terminates. Which Kubernetes resource is most appropriate?

A.StatefulSet
B.Job
C.Deployment
D.DaemonSet
AnswerB

A Job runs Pods to successful completion rather than continuously, which suits a queue-processing task that must terminate. Unlike a Deployment, which restarts Pods indefinitely to maintain availability, the Job controller tracks completion and stops once the work finishes.

Why this answer

A Job is the correct resource because it is designed to run a specified number of pods to completion and then terminate, making it ideal for batch processing tasks like processing a queue. Unlike controllers that maintain a desired state indefinitely, a Job ensures the pod runs successfully to completion, even if the pod fails and needs to be restarted, and then stops.

Exam trap

CNCF often tests the distinction between controllers that maintain a desired state (Deployment, StatefulSet, DaemonSet) versus controllers that run to completion (Job), and the trap here is assuming that any workload that processes data must use a Deployment because it's the most common controller.

How to eliminate wrong answers

Option A is wrong because a StatefulSet is used for stateful applications that require stable, unique network identifiers and persistent storage, not for batch jobs that terminate. Option C is wrong because a Deployment is designed to maintain a desired number of replica pods running continuously, not to run a task to completion and then stop. Option D is wrong because a DaemonSet ensures that a copy of a pod runs on every node (or a subset of nodes) in the cluster, typically for cluster-level services like logging or monitoring, not for one-off batch processing.

Full explanation →
371
MCQeasy

A DevOps engineer needs to expose a set of pods running an HTTP API to external clients. The pods are stateless and should be load-balanced. Which Kubernetes resource should they use?

A.StatefulSet with a headless Service
B.Ingress resource without a Service
C.Service of type ClusterIP
D.Service of type LoadBalancer
AnswerD

A Service of type LoadBalancer provisions an external load balancer that distributes traffic across the stateless pod endpoints, exposing the HTTP API to external clients. ClusterIP is internal only, and NodePort lacks integrated load balancing.

Why this answer

A Service of type LoadBalancer is the correct choice because it provisions an external load balancer (e.g., an AWS ELB or Azure LB) that distributes incoming traffic across the pods, exposing the stateless HTTP API to external clients. This resource automatically assigns a public IP and handles load balancing without requiring manual proxy configuration, making it ideal for external access to stateless workloads.

Exam trap

The trap here is that candidates often confuse 'exposing to external clients' with internal-only services, leading them to pick ClusterIP (C) or assume Ingress (B) can work without a Service, while the question explicitly requires load balancing for stateless pods, making LoadBalancer the direct and correct answer.

How to eliminate wrong answers

Option A is wrong because a StatefulSet is designed for stateful applications (e.g., databases) that require stable network identities and persistent storage, not for stateless HTTP APIs, and a headless Service does not provide load balancing or external exposure. Option B is wrong because an Ingress resource cannot function without a backing Service; it requires a Service (typically of type NodePort or LoadBalancer) to route traffic to pods, and it does not itself expose pods directly. Option C is wrong because a Service of type ClusterIP is only reachable within the cluster's internal network (e.g., via cluster IP 10.0.0.1) and cannot be accessed by external clients without additional components like a proxy or Ingress.

Full explanation →
372
MCQhard

A Kubernetes cluster runs Prometheus for monitoring. The operations team wants to receive alerts when the 99th percentile latency of an HTTP service exceeds 500ms for 5 minutes. They have a metric http_request_duration_seconds histogram. Which PromQL expression should they use to calculate the 99th percentile latency?

A.http_request_duration_seconds_bucket{le="0.5"} > 500
B.quantile(0.99, http_request_duration_seconds)
C.rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])
D.histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
AnswerD

The histogram_quantile function calculates quantiles from histogram buckets. Using rate on the bucket metric over a 5-minute window accounts for counter resets and provides per-second rate of increase. This is the standard way to compute latency percentiles from histograms. The 0.99 quantile gives the 99th percentile, and the 5-minute window aligns with the alerting requirement.

Why this answer

To compute the 99th percentile from a Prometheus histogram, the histogram_quantile function is used with the desired quantile and a rate over the bucket metric. The rate function calculates the per-second increase of the cumulative bucket counters over a 5-minute window, which is necessary for accurate quantile estimation. This expression correctly yields the 99th percentile latency, enabling the alerting condition to be evaluated.

Exam trap

The trap here is using the quantile function directly on a histogram metric instead of histogram_quantile on the _bucket series, which is required for histograms.

Full explanation →
373
MCQmedium

A cluster administrator needs to ensure that a logging agent runs on every node in the cluster, including nodes added in the future. The agent should collect logs from each node and forward them to a central system. Which Kubernetes resource should be used?

A.Job
B.DaemonSet
C.Deployment
D.StatefulSet
AnswerB

DaemonSet ensures that a copy of a pod runs on all (or selected) nodes. When new nodes are added to the cluster, the DaemonSet controller automatically schedules a pod on them. This is ideal for node-level services like log collectors, monitoring agents, or network plugins. It directly meets the requirement of running a logging agent on every node, including future ones, without manual intervention.

Why this answer

DaemonSet is specifically designed to run a pod on each node, automatically handling new nodes as they join. This makes it the correct choice for node-level agents like log collectors. Deployments, StatefulSets, and Jobs do not provide this per-node guarantee; they manage replicas or batch tasks without ensuring coverage of every node.

Exam trap

The trap here is thinking that a Deployment with many replicas can cover all nodes, but it lacks the automatic per-node scheduling that DaemonSet provides.

Full explanation →
374
MCQeasy

Which component of Kubernetes is responsible for maintaining the desired state of the cluster?

A.kube-scheduler
B.kube-controller-manager
C.kubelet
D.kube-apiserver
AnswerB

The kube-controller-manager runs reconciliation loops that continuously compare observed cluster state against the declared desired state, then act to close any drift. This directly satisfies the stem's requirement: it is the control-plane component responsible for maintaining that desired state, distinct from the API server, which merely stores it.

Why this answer

The kube-controller-manager is the component that runs controller processes, which are responsible for regulating the state of the cluster. It continuously watches the current state via the kube-apiserver and takes corrective actions to match the desired state defined in the cluster's control loop, such as ensuring the correct number of pods are running.

Exam trap

CNCF often tests the misconception that the kube-scheduler maintains desired state because it 'schedules' pods, but scheduling is only one part of the control loop; the actual state reconciliation is done by the controller-manager.

How to eliminate wrong answers

Option A is wrong because the kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for maintaining the desired state. Option C is wrong because the kubelet is an agent that runs on each node and ensures containers are running in a pod, but it does not maintain the cluster-wide desired state. Option D is wrong because the kube-apiserver serves as the front-end for the Kubernetes control plane, handling API requests and storing state in etcd, but it does not actively enforce or reconcile the desired state.

Full explanation →
375
MCQeasy

Which of the following best describes a key advantage of containers over virtual machines?

A.Containers share the host OS kernel, resulting in lower resource overhead compared to VMs
B.Containers take longer to start than VMs because they need to initialize a kernel
C.Containers consume more disk space than VMs because they include a full operating system
D.Containers have stronger isolation than VMs because each container runs its own kernel
AnswerA

Containers share the host OS kernel and isolate only the process, so each avoids booting a full guest OS. That removes the hypervisor and duplicate kernel overhead, giving lower resource consumption than VMs, which is the advantage the stem asks for.

Why this answer

Containers share the host operating system kernel, which means they do not need to boot a separate kernel or emulate hardware. This shared kernel model eliminates the overhead of running a full guest OS per instance, resulting in significantly lower memory and CPU consumption compared to virtual machines, which each run a complete OS stack including a separate kernel.

Exam trap

The exam often tests the misconception that containers provide stronger isolation than VMs because they are 'self-contained,' but the trap here is that containers actually share the host kernel, making isolation weaker than the hypervisor-based isolation of VMs.

How to eliminate wrong answers

Option B is wrong because containers start in seconds (often sub-second) since they only need to initialize the application process, whereas VMs take minutes because they must boot a full kernel and operating system. Option C is wrong because containers are lightweight (typically tens of MB) as they package only the application and its dependencies, while VMs include a full OS (gigabytes) and thus consume more disk space. Option D is wrong because containers share the host kernel and have weaker isolation (e.g., via cgroups and namespaces), whereas VMs provide stronger isolation by running each instance with its own separate kernel and hypervisor-enforced boundaries.

Full explanation →
Page 4

Page 5 of 13

Page 6

All pages

12345678910111213

Practice KCNA by domain

Target a specific domain to shore up weak areas.

Kubernetes FundamentalsContainer OrchestrationCloud Native ArchitectureCloud Native ObservabilityCloud Native Application Delivery
See all domains with question counts →