Kubernetes and Cloud Native Associate KCNA KCNA Questions 676–750 | Page 10/13

676

Multi-Selecteasy

Which TWO of the following are benefits of implementing progressive delivery techniques (e.g., canary releases)?

Select 2 answers

A.Replaces the need for a CI/CD pipeline

B.Allows testing new features with a subset of users

C.Eliminates the need for monitoring and alerting

D.Guarantees zero downtime

E.Reduces the risk of deploying a bad version to all users

AnswersB, E

Canary releases route a small percentage of live traffic to the new version, so real users exercise the feature before full rollout. This directly satisfies the stem's requirement to test with a subset, limiting blast radius and enabling fast rollback if metrics degrade.

Why this answer

Option B is correct because progressive delivery techniques such as canary releases deliberately expose a new version to a small subset of users (often a percentage of traffic) so that real-world behavior and feedback can be gathered before a full rollout. Option E is correct because by limiting the initial blast radius to that subset, a faulty release can be detected and rolled back before it reaches the entire user base, thereby reducing the risk of deploying a bad version to all users. Option A is incorrect because progressive delivery complements, rather than replaces, a CI/CD pipeline — the pipeline still builds, tests, and deploys the artifacts that progressive delivery then releases gradually.

Option C is incorrect because progressive delivery depends heavily on monitoring and alerting to detect regressions and trigger rollbacks. Option D is incorrect because progressive delivery reduces risk but does not guarantee zero downtime, which depends on architecture and deployment mechanics.

Exam trap

KCNA often tests the misconception that progressive delivery eliminates the need for monitoring or CI/CD, when in fact it depends heavily on both.

Full explanation →

677

MCQhard

A company uses OpenTelemetry to instrument their microservices. They want to ensure that traces from one service can be correlated with those from another service across network calls. Which OpenTelemetry concept enables this correlation?

A.Exporter configuration

B.Span attributes

C.Context propagation

D.Sampling

AnswerC

Context propagation transmits trace context (trace ID, span ID, sampling flags) across service boundaries via protocols such as W3C Trace Context headers. This satisfies the stem's requirement to correlate spans from separate microservices across network calls, letting each downstream service join the same distributed trace rather than starting an unrelated one.

Why this answer

Context propagation is the OpenTelemetry mechanism that carries trace context (trace ID, span ID, sampling flags) across service boundaries via headers such as W3C Trace Context. This allows spans from different services to be stitched into a single distributed trace.

Exam trap

The trap is confusing span attributes (metadata on a span) with context propagation (the mechanism that links spans across services), leading candidates to pick attributes for correlation.

How to eliminate wrong answers

Option A is wrong because exporter configuration determines where telemetry data is sent (e.g., OTLP endpoint), not how traces are correlated. Option B is wrong because span attributes are key-value metadata attached to a span; they enrich a span but do not link spans across services. Option D is wrong because sampling decides which traces are recorded, not how they are correlated.

Full explanation →

678

MCQmedium

Which component is responsible for ensuring that containers are running as specified in a Pod's specification on a node?

A.Container runtime

B.kubelet

C.kube-proxy

D.kube-scheduler

AnswerB

The kubelet runs as an agent on each node, watching the API server for PodSpecs bound to its node and starting, stopping and restarting containers to match that specification. This directly satisfies the stem's requirement for the component ensuring containers run as specified on a node.

Why this answer

The kubelet is the primary node agent that runs on each node in a Kubernetes cluster. It is responsible for ensuring that containers described in Pod specifications (PodSpecs) are running and healthy. The kubelet watches for Pod assignments from the API server, creates or terminates containers via the container runtime, and continuously reports the node and Pod status back to the control plane.

Exam trap

A common pitfall is confusing the kubelet, which ensures containers are running according to the Pod spec, with the container runtime, which actually executes containers. Candidates often choose 'container runtime' because they associate 'running containers' with the container runtime, but the kubelet is the agent that manages Pod lifecycle on the node.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for actually pulling images and running containers, but it does not interpret Pod specifications or enforce desired state — it only executes commands from the kubelet via the CRI (Container Runtime Interface). Option C is wrong because kube-proxy is a network proxy that runs on each node, handling IPVS/iptables rules for Service traffic and network policies, not container lifecycle management. Option D is wrong because kube-scheduler is a control plane component that selects which node a Pod should run on based on resource availability and constraints, but it does not run on the node or manage running containers.

Full explanation →

679

MCQeasy

What does the 'kubectl logs' command retrieve?

A.Audit logs

B.Cluster events

C.Container logs

D.Node logs

AnswerC

`kubectl logs` streams stdout and stderr captured by the container runtime for a specific container in a pod, satisfying the stem's request for container-level output. It reads from the node's log files rather than cluster events or API audit records, so it returns application output only.

Why this answer

The 'kubectl logs' command retrieves the standard output (stdout) and standard error (stderr) streams from a container running in a pod. It directly accesses the container's log files on the node (e.g., /var/log/pods/...) or streams them from the container runtime. This is the primary way to debug application issues in Kubernetes.

Exam trap

KCNA often tests the distinction between different types of logs and events, and candidates may confuse 'kubectl logs' with 'kubectl get events' or assume it retrieves node-level logs.

How to eliminate wrong answers

Option A is wrong because audit logs are records of API server requests, typically stored in files or sent to a backend, and are not retrieved via 'kubectl logs'. Option B is wrong because cluster events are objects in the Kubernetes API (viewed with 'kubectl get events') that report state changes, not container output. Option D is wrong because node logs (e.g., kubelet or system logs) are not accessible through 'kubectl logs'; they require direct node access or a logging agent.

Full explanation →

680

MCQmedium

A company is adopting a GitOps workflow for their Kubernetes deployments. They want to ensure that the cluster state always matches the desired state defined in a Git repository. Which tool is specifically designed for this purpose?

A.Helm

B.Argo CD

C.Kustomize

D.Prometheus

AnswerB

Argo CD continuously reconciles live cluster state against manifests held in Git, detecting and reverting drift automatically. This declarative pull-based reconciliation is precisely the GitOps guarantee the company requires: cluster state always matching the desired state defined in the repository.

Why this answer

Argo CD is a declarative, GitOps continuous delivery tool specifically designed for Kubernetes that automatically synchronizes the live cluster state with the desired state defined in a Git repository. It continuously monitors the cluster and Git, applying any drift to ensure the cluster matches the repository, which is the core requirement of a GitOps workflow.

Exam trap

The trap here is that candidates often confuse Helm or Kustomize as GitOps tools because they are used in GitOps pipelines, but they lack the continuous reconciliation and drift detection that a dedicated GitOps operator like Argo CD provides.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes that uses charts to define, install, and upgrade applications, but it does not provide continuous synchronization or drift detection from a Git repository; it is a deployment tool, not a GitOps operator. Option C is wrong because Kustomize is a configuration management tool that allows customizing Kubernetes manifests without templates, but it is a CLI tool or a kubectl plugin, not a controller that continuously reconciles cluster state with a Git repository. Option D is wrong because Prometheus is a monitoring and alerting toolkit for metrics collection and alerting, not a deployment or GitOps tool; it has no mechanism to enforce desired state from Git.

Full explanation →

681

MCQmedium

A user runs 'kubectl create deployment my-deploy --image=nginx' and then wants to scale the deployment to 5 replicas. Which command should they use?

A.kubectl apply -f deployment.yaml with replicas: 5

B.kubectl edit deployment my-deploy and change replicas to 5

C.kubectl patch deployment my-deploy -p '{"spec":{"replicas":5}}'

D.kubectl scale deployment my-deploy --replicas=5

AnswerD

`kubectl scale` adjusts the replica count on an existing Deployment's spec, letting the controller reconcile five Pods. It directly satisfies the stem's requirement to scale an already-created Deployment named my-deploy, without editing YAML or recreating the resource.

Why this answer

`kubectl scale` is the dedicated imperative command to change the replica count of a deployment. It directly updates the `spec.replicas` field in the deployment's desired state, and the deployment controller then adjusts the ReplicaSet and Pods accordingly. This is the simplest and most direct way to scale a deployment without modifying a YAML file or using an editor.

Exam trap

The trap is that candidates may think `kubectl edit` or `kubectl patch` are the only ways to change replicas, but the KCNA exam expects knowledge of the dedicated imperative `kubectl scale` command for direct scaling operations.

How to eliminate wrong answers

Option A is wrong because `kubectl apply` requires a YAML file with the desired state; the user did not create a deployment.yaml file, and the command as written would fail or create a new resource. Option B is wrong because `kubectl edit` opens an interactive editor, which is not a single command and can be error-prone in scripts or automated workflows; it works but is not the recommended imperative approach. Option C is wrong because `kubectl patch` uses a JSON patch to modify the deployment, which is valid but more complex and less intuitive than the dedicated `kubectl scale` command; it also requires correct JSON syntax and is prone to typos.

Full explanation →

682

MCQeasy

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

A.kube-scheduler

B.kube-proxy

C.kube-controller-manager

D.kubelet

AnswerC

The kube-controller-manager runs control loops that watch cluster state and reconcile actual state toward the desired state declared in objects. Kubelet manages only pod lifecycle on one node, and the scheduler merely assigns pods, so neither maintains cluster-wide desired state.

Why this answer

The kube-controller-manager is the component that runs controller processes, which are control loops that watch the shared state of the cluster through the API server and make changes to move the current state toward the desired state. It is responsible for ensuring that the cluster's actual state matches the desired state defined in Kubernetes objects such as Deployments, ReplicaSets, and StatefulSets.

Exam trap

CNCF often tests the distinction between the kube-controller-manager and the kubelet, where candidates mistakenly think the kubelet maintains the cluster's desired state because it manages containers on a node, but the kubelet only ensures the pod's containers are healthy on its local node, not the cluster-wide desired state.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and scheduling policies, not for maintaining the desired state of the cluster. Option B is wrong because kube-proxy is a network proxy that runs on each node and implements part of the Kubernetes Service concept by maintaining network rules, not for maintaining desired state. Option D is wrong because kubelet is an agent that runs on each node and ensures containers are running in a pod as expected, but it only manages the state on its specific node and does not maintain the overall desired state of the cluster.

Full explanation →

683

Multi-Selecthard

Which of the following are core components of the Flux GitOps toolkit?

Select 3 answers

A.Helm Controller

B.Helm

C.Source Controller

D.ArgoCD Application Controller

E.Kustomize Controller

AnswersA, C, E

Flux ships several purpose-built controllers, and the Helm Controller is one of them, reconciling HelmRelease custom resources to install and upgrade charts declaratively, which is a core component of the GitOps toolkit alongside source, kustomize and notification controllers.

Why this answer

The Flux GitOps toolkit is built from a set of Kubernetes controllers, and the Helm Controller (A) is one of them: it reconciles HelmRelease custom resources to install, upgrade, and roll back Helm charts declaratively. The Source Controller (C) is also a core Flux component, providing GitRepository, HelmRepository, Bucket, and OCIRepository sources that other Flux controllers consume. The Kustomize Controller (E) is likewise core, reconciling Kustomization resources to build and apply manifests from those sources.

Helm (B) is a package manager tool that Flux's Helm Controller uses, but it is not itself a Flux toolkit component, and the ArgoCD Application Controller (D) belongs to Argo CD, a competing GitOps tool, not Flux.

Exam trap

KCNA often tests the distinction between GitOps tools (Flux vs. Argo CD) and their underlying utilities (Helm, Kustomize), causing candidates to select Helm or ArgoCD components as part of the Flux toolkit.

Full explanation →

684

MCQhard

A cluster administrator is configuring a Pod with a container that requires 2 CPU cores and 4Gi of memory. The administrator sets resource requests to 2 CPU and 4Gi memory, and limits to 4 CPU and 8Gi memory. The Pod is scheduled to a node with 4 CPU and 8Gi memory available. What happens when the container attempts to use 3 CPU and 6Gi memory?

A.The container runs normally because usage is within the limits.

B.The container is restarted by the kubelet because it exceeded its request.

C.The container is throttled to 2 CPU and OOM killed for memory.

D.The container is evicted from the node due to resource overcommit.

AnswerA

The container's resource limits are 4 CPU and 8Gi memory. Using 3 CPU and 6Gi memory is below these limits, so the container is not throttled or killed. Requests guarantee scheduling, while limits cap usage. Since the node has enough resources, the container operates without restriction.

Why this answer

Resource requests are used by the scheduler to place pods, while limits define the maximum resources a container can consume. When usage is between requests and limits, the container continues running without throttling or termination. Only exceeding CPU limits causes throttling, and exceeding memory limits triggers an OOM kill.

Exam trap

The trap here is confusing requests with limits, or assuming that exceeding a request triggers throttling or eviction, when requests are only for scheduling.

Full explanation →

685

MCQeasy

A developer wants to store non-confidential configuration data as key-value pairs that can be consumed by Pods as environment variables or mounted files. Which Kubernetes resource is designed for this purpose?

A.PersistentVolumeClaim

B.Volume

C.ConfigMap

D.Secret

AnswerC

A ConfigMap is designed to hold non-confidential configuration data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or configuration files in a volume. It decouples configuration from container images, making applications portable and easier to manage across environments.

Why this answer

ConfigMaps are the standard Kubernetes resource for managing non-confidential configuration data. They allow you to decouple configuration artifacts from image content, and Pods can consume them as environment variables or mounted files. Secrets are for sensitive data, while Volumes and PersistentVolumeClaims are storage abstractions, not configuration stores.

Exam trap

The trap here is assuming that any key-value store can be used for configuration; Secrets are for confidential data, and using them for non-sensitive data is not recommended.

Full explanation →

686

MCQeasy

What is the primary purpose of a Kubernetes Service object?

A.To store configuration data that can be consumed by Pods

B.To manage rolling updates and rollbacks for Pods

C.To provide a stable IP address and DNS name for a set of Pods

D.To persist data beyond the lifecycle of a Pod

AnswerC

A Service selects Pods via labels and exposes them behind a single stable virtual IP and DNS name, so clients reach a consistent endpoint even as Pod IPs change on restart or rescheduling. This satisfies the stem's requirement for stable addressing across a dynamic Pod set.

Why this answer

The primary purpose of a Kubernetes Service object is to provide a stable network endpoint (a fixed IP address and DNS name) that abstracts and load-balances traffic across a dynamic set of Pods. Pods are ephemeral and can be rescheduled with new IP addresses, so the Service ensures clients can reliably reach the application without needing to track individual Pod IPs.

Exam trap

The trap here is that candidates often confuse the Service's role with that of a Deployment or ConfigMap, mistakenly thinking a Service manages Pod lifecycles or stores configuration, when its core function is purely about stable network abstraction and load balancing.

How to eliminate wrong answers

Option A is wrong because storing configuration data that can be consumed by Pods is the role of a ConfigMap (or Secret for sensitive data), not a Service. Option B is wrong because managing rolling updates and rollbacks for Pods is the responsibility of a Deployment controller, which handles replica sets and update strategies. Option D is wrong because persisting data beyond the lifecycle of a Pod is achieved through PersistentVolume (PV) and PersistentVolumeClaim (PVC) objects, not a Service.

Full explanation →

687

Multi-Selectmedium

Which TWO of the following are Kubernetes control plane components?

Select 2 answers

A.kube-apiserver

B.container runtime

C.etcd

D.kube-proxy

E.kubelet

AnswersA, C

The kube-apiserver is the control plane's front end, exposing the Kubernetes API that every other component and user interacts with. It validates and persists object state to etcd, so it runs on control plane nodes rather than worker nodes, satisfying the question's control plane component criterion.

Why this answer

kube-apiserver (A) is correct because it is the central control plane component that exposes the Kubernetes API, validating and processing all REST requests and serving as the front end of the control plane. etcd (C) is correct because it is the consistent, highly-available key-value store that persists all cluster state and is a core control plane component. The container runtime (B) is not a control plane component; it runs on each node as part of the kubelet's node-level machinery to execute containers. kube-proxy (D) is a node-level networking component that maintains network rules for Service traffic, not a control plane component. kubelet (E) is the node agent that manages pods on a worker node, so it is also not part of the control plane.

Exam trap

CNCF often tests the distinction between control plane and worker node components, expecting candidates to mistakenly include kubelet or kube-proxy as control plane components because they are essential for cluster operation but run on nodes, not the control plane.

Full explanation →

688

MCQeasy

Which tool is commonly used for log aggregation in Kubernetes and is designed to be lightweight?

A.Fluent Bit

B.Jaeger

C.Prometheus

D.Grafana

AnswerA

Fluent Bit is a CNCF log processor and forwarder written in C with a small memory and CPU footprint, designed for constrained environments. It collects container logs and ships them to backends, satisfying the lightweight log aggregation requirement in Kubernetes.

Why this answer

Fluent Bit is a CNCF-graduated, lightweight log processor and forwarder written in C with a tiny memory footprint (often under 1 MB), specifically designed for high-performance log aggregation in containerized and edge environments. It is commonly deployed as a DaemonSet in Kubernetes to collect container logs from /var/log/containers and ship them to backends like Elasticsearch, Loki, or CloudWatch. Its low resource usage distinguishes it from heavier aggregators like Fluentd.

Exam trap

KCNA often tests the observability triad confusion — candidates see 'logs' and pick Fluentd or Grafana, or see 'lightweight' and pick Prometheus, forgetting that Fluent Bit is the purpose-built lightweight log forwarder.

How to eliminate wrong answers

Option B is wrong because Jaeger is a distributed tracing system for capturing and visualizing request flows across microservices, not a log aggregation tool. Option C is wrong because Prometheus is a time-series metrics monitoring and alerting system that scrapes numeric metrics, not a log collector. Option D is wrong because Grafana is a visualization and dashboarding layer that queries data sources like Prometheus or Loki; it does not itself aggregate logs.

Full explanation →

689

MCQhard

In the context of the 12-factor app methodology, which factor requires that an app's configuration be stored in environment variables?

A.Config

B.Dependencies

C.Codebase

D.Backing services

AnswerA

The Config factor mandates strict separation of configuration from code, storing deploy-specific values such as credentials and endpoints in environment variables rather than committed files, so the same build can be promoted across environments unchanged.

Why this answer

The Config factor of the 12-factor app methodology explicitly states that configuration should be stored in environment variables, not in code or config files checked into the repository. This separates config that varies between deploys (database URLs, API keys, feature flags) from the immutable codebase, enabling the same artifact to be promoted across environments. Environment variables are language-agnostic and easily injected by the platform.

Exam trap

KCNA often tests whether candidates confuse Config with Backing Services — both involve external resources, but only Config mandates environment-variable storage.

How to eliminate wrong answers

Option B is wrong because the Dependencies factor is about explicitly declaring and isolating dependencies (e.g., via a package manager), not about configuration storage. Option C is wrong because the Codebase factor mandates a single codebase tracked in revision control with many deploys, not configuration handling. Option D is wrong because Backing services treats databases, queues, and caches as attached resources referenced via config, but the factor that specifies environment variables is Config.

Full explanation →

690

MCQhard

Which of the following best describes immutable infrastructure?

A.Servers that are updated in-place with configuration management tools

B.Infrastructure that is version-controlled and deployed using blue/green deployments

C.Infrastructure components that are replaced rather than changed after deployment

D.Infrastructure that uses only read-only file systems

AnswerC

Immutable infrastructure means servers and components are never patched or reconfigured in place; instead a new versioned instance is provisioned from an image and swapped in, then the old one destroyed. This eliminates configuration drift, satisfying the replace-rather-than-change definition the stem asks for.

Why this answer

Immutable infrastructure is a pattern where components (servers, containers, etc.) are never modified after deployment. Instead, any change requires building a new instance from a golden image or template and replacing the old one. This eliminates configuration drift and ensures consistency, which is a core principle in container orchestration with tools like Kubernetes, where Pods are replaced rather than patched in place.

Exam trap

The trap here is that candidates confuse immutable infrastructure with specific deployment patterns (blue/green) or security features (read-only filesystems), rather than recognizing the core principle of replacement over modification.

How to eliminate wrong answers

Option A is wrong because it describes mutable infrastructure, where configuration management tools (e.g., Ansible, Chef) apply updates in-place, directly contradicting the immutable principle of replacement. Option B is wrong because while version-controlled infrastructure and blue/green deployments are often used with immutable infrastructure, they are deployment strategies, not the defining characteristic of immutability itself. Option D is wrong because read-only file systems are a security hardening technique that can be part of an immutable design, but they are not the core definition; immutable infrastructure focuses on the lifecycle of the entire component, not just the filesystem state.

Full explanation →

691

MCQmedium

A CI/CD pipeline includes image scanning. What is the primary security benefit of scanning container images in the CI phase?

A.It reduces the time it takes to build images

B.It automatically fixes vulnerabilities

C.It prevents vulnerable images from being deployed to production

D.It ensures that the image is built only once

AnswerC

Scanning during CI catches known CVEs in base images and dependencies before the image reaches a registry, letting the pipeline fail the build and block promotion. This satisfies the stem's CI-phase constraint: remediation happens pre-deployment, so vulnerable artefacts never reach production clusters.

Why this answer

Scanning images during CI catches known CVEs, misconfigurations, and embedded secrets before the artifact is pushed to a registry or promoted to production. By failing the pipeline on policy violations, teams create a gate that stops vulnerable images from ever reaching runtime environments, shifting security left. This is the core security value: prevention at the earliest feasible stage rather than detection after deployment.

Exam trap

The trap here is conflating scanning with remediation — candidates pick 'automatically fixes vulnerabilities' because scanners suggest fixes, but the exam wants the preventive gate benefit, not auto-patching.

How to eliminate wrong answers

Option A is wrong because image scanning adds a pipeline step and typically increases, not reduces, build time. Option B is wrong because scanners report vulnerabilities; they do not patch or rebuild images automatically — remediation still requires updating base images or dependencies. Option D is wrong because build-once is a reproducibility/immutability concern handled by tagging and caching, not a security benefit of scanning.

Full explanation →

692

Multi-Selectmedium

Which THREE are benefits of using container orchestration platforms like Kubernetes?

Select 3 answers

A.High availability through automatic container restart and replication

B.Automatic scaling of container replicas based on resource usage

C.Self-healing by replacing failed containers without manual intervention

D.Simplified application development by eliminating the need for code changes

E.Elimination of the need for monitoring and logging

AnswersA, B, C

Replication controllers and ReplicaSets maintain the declared replica count, and Kubernetes restarts or reschedules failed containers automatically. This delivers high availability without manual intervention, satisfying the benefit of automatic restart and replication across the cluster.

Why this answer

Option A is correct because Kubernetes provides high availability by automatically restarting failed containers and maintaining the desired number of replicas across nodes, ensuring workloads remain available even when individual containers or nodes fail. Option B is correct because Kubernetes supports automatic scaling of container replicas through mechanisms like the Horizontal Pod Autoscaler, which adjusts replica counts based on observed CPU, memory, or custom metrics. Option C is correct because Kubernetes performs self-healing by detecting failed containers, pods, or nodes and replacing or rescheduling them without manual intervention, restoring the declared desired state.

Option D is not a benefit of orchestration because Kubernetes manages deployment and runtime concerns, not application source code, so developers still must write and modify code as needed. Option E is incorrect because orchestration platforms do not eliminate monitoring and logging; they integrate with tools like Prometheus, Grafana, and the ELK stack, and observability remains essential for operating containerized workloads.

Exam trap

A common pitfall is the misconception that orchestration platforms like Kubernetes automate everything, including application code changes and monitoring setup, when in reality they only automate operational tasks like scaling and recovery, leaving code adaptation and observability configuration to the user.

Full explanation →

693

MCQhard

You are a platform engineer at a fast-growing startup. The company runs a Kubernetes cluster with 50 worker nodes for its production microservices. Recently, the operations team has been struggling with manual configuration drift: developers SSH into nodes to install debugging tools, and some nodes have different kernel parameters or installed packages. This has caused intermittent outages when a pod is scheduled onto a non-standard node. The CTO wants a solution that ensures each node is identical, immutable, and reproducible. The cluster uses kubeadm for bootstrapping and runs on AWS EC2. Which approach best achieves the goal of immutable nodes?

A.Use a configuration management tool like Ansible to enforce desired state on each node via periodic runs.

B.Apply Kubernetes node labels and taints to categorize nodes and prevent workloads from running on non-standard nodes.

C.Create a golden AMI using Packer with all required configurations, then use Auto Scaling groups with a launch template that references the AMI and enable instance refresh for updates.

D.Deploy a DaemonSet that runs a privileged container to enforce node configuration and remove debugging tools.

AnswerC

Packer builds a golden AMI containing every package and kernel parameter, and Auto Scaling groups with instance refresh replace nodes from that image, eliminating SSH drift. Nodes become identical, immutable and reproducible, satisfying the CTO's requirement on EC2.

Why this answer

It uses a golden AMI built with Packer to create identical, immutable nodes that are reproducible via Auto Scaling groups and launch templates. This approach ensures that every EC2 instance launched has the exact same kernel parameters, packages, and configuration, eliminating configuration drift. Instance refresh allows rolling updates to the AMI without manual intervention, aligning with the goal of immutable infrastructure.

Exam trap

The trap here is that candidates often confuse configuration management (Option A) with immutability, not realizing that periodic enforcement still allows drift and does not guarantee identical nodes at all times.

How to eliminate wrong answers

Option A is wrong because configuration management tools like Ansible enforce desired state via periodic runs, which still allows drift between runs and does not achieve true immutability; nodes remain mutable and can deviate. Option B is wrong because node labels and taints only control workload scheduling, they do not enforce node configuration or prevent nodes from being modified via SSH. Option D is wrong because a DaemonSet running a privileged container can attempt to enforce configuration but cannot prevent manual SSH changes or guarantee identical state across nodes, and it introduces security risks without solving the root cause of drift.

Full explanation →

694

MCQhard

Which Kubernetes resource is commonly used to implement the sidecar pattern for injecting a service mesh proxy?

A.NetworkPolicy

B.Service

C.MutatingAdmissionWebhook

D.ConfigMap

AnswerC

A MutatingAdmissionWebhook intercepts pod creation requests and mutates the pod specification, which is how sidecar containers such as service mesh proxies are injected automatically. This admission-time mutation mechanism is the standard implementation of sidecar injection in Kubernetes.

Why this answer

A MutatingAdmissionWebhook intercepts Pod creation requests and automatically injects a sidecar container (e.g., Envoy or Linkerd-proxy) into the Pod spec. This is the standard mechanism used by service mesh control planes like Istio and Linkerd to transparently add the proxy without modifying application manifests.

Exam trap

CNCF often tests the misconception that a Service or NetworkPolicy is responsible for sidecar injection, when in fact only a mutating admission webhook can automatically modify Pod specs at creation time.

How to eliminate wrong answers

Option A is wrong because NetworkPolicy controls ingress/egress traffic at the network layer using labels and CIDR rules, not container injection. Option B is wrong because a Service provides a stable IP and DNS name for Pod discovery and load balancing, not sidecar injection. Option D is wrong because a ConfigMap stores non-sensitive configuration data as key-value pairs or files, but cannot mutate Pod specs at creation time.

Full explanation →

695

Multi-Selecteasy

Which TWO of the following are functions of the kube-controller-manager?

Select 2 answers

A.Managing replication and ensuring the desired number of pods are running

B.Storing cluster state

C.Exposing the Kubernetes API

D.Monitoring node health and responding to node failures

E.Assigning pods to nodes

AnswersA, D

The kube-controller-manager runs the ReplicationController and ReplicaSet controllers, which continuously reconcile observed pod counts against the declared replica count, creating or deleting pods to close any gap. This satisfies the stem's requirement for managing replication and maintaining the desired number of running pods.

Why this answer

Option A is correct because the kube-controller-manager runs the ReplicationController/ReplicaSet controller, which continuously reconciles the actual number of running pods with the desired replica count specified in the resource. Option D is correct because the kube-controller-manager includes the node controller, which monitors node health via heartbeats/leases and responds to node failures by marking nodes NotReady and evicting or rescheduling their pods. Option B is incorrect because cluster state is persisted in etcd, not by the kube-controller-manager.

Option C is incorrect because the Kubernetes API is exposed by the kube-apiserver. Option E is incorrect because pod-to-node assignment (scheduling) is performed by the kube-scheduler.

Exam trap

CNCF often tests the distinction between the kube-controller-manager and the kube-scheduler, so the trap here is that candidates mistakenly think pod-to-node assignment is a controller function, when it is exclusively handled by the scheduler.

Full explanation →

696

MCQeasy

Which component runs on every worker node and is responsible for maintaining the lifecycle of pods?

A.container runtime

B.kube-scheduler

C.kubelet

D.kube-proxy

AnswerC

The kubelet is the node agent that watches the API server for pods bound to its node, then starts, monitors and restarts containers via the container runtime. It therefore maintains pod lifecycle on every worker node, unlike the scheduler or control-plane components.

Why this answer

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It is responsible for ensuring that containers are running in a Pod as expected, by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor Pods based on PodSpecs received from the API server. Without the kubelet, the node cannot manage Pod lifecycles.

Exam trap

A common trap on CNCF exams is confusing the kubelet (node agent for Pod lifecycle) with kube-proxy (node agent for networking), as both run on worker nodes, but kube-proxy does not manage Pods.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it does not manage Pod lifecycles or interact with the Kubernetes control plane; the kubelet delegates container operations to it via the CRI. Option B is wrong because kube-scheduler runs on the control plane, not on worker nodes, and its sole job is to assign Pods to nodes based on resource constraints and policies; it does not maintain Pod lifecycles after scheduling. Option D is wrong because kube-proxy runs on each node but handles network proxying and service abstraction (e.g., implementing iptables or IPVS rules for ClusterIP), not Pod lifecycle management.

Full explanation →

697

MCQmedium

A pod is in 'Pending' state for a long time. What is the most likely cause?

A.The pod's container has crashed

B.The pod's service endpoint is misconfigured

C.The scheduler cannot find a node that satisfies the pod's resource requests or constraints

D.The container image is invalid

AnswerC

The scheduler places pods onto nodes; when no node satisfies resource requests, affinity rules or taints, it leaves the pod unscheduled. That unsatisfied scheduling constraint is the most likely cause of a prolonged Pending state.

Why this answer

A pod remains in 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is that the scheduler cannot find a node that meets the pod's resource requests (CPU/memory) or constraints (node selectors, affinity rules, taints/tolerations). Until a suitable node is found, the pod stays in Pending, waiting for scheduling.

Exam trap

CNCF often tests the distinction between scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff), so the trap here is confusing a pod that cannot be placed on a node with a pod that fails after it starts running.

How to eliminate wrong answers

Option A is wrong because a container crash (e.g., CrashLoopBackOff) occurs after the pod is scheduled and running, not while it is still in Pending. Option B is wrong because a misconfigured service endpoint (e.g., wrong selector or port) affects network connectivity to the pod, not the pod's scheduling state; the pod would still be scheduled and running. Option D is wrong because an invalid container image (e.g., wrong tag or registry path) causes the pod to fail during container creation after scheduling, resulting in ImagePullBackOff or ErrImagePull, not a prolonged Pending state.

Full explanation →

698

MCQhard

In event-driven architecture, which component is responsible for decoupling event producers from consumers?

A.Event broker

B.Event consumer

C.Event producer

D.API gateway

AnswerA

An event broker sits between producers and consumers, receiving published events and routing them to subscribers, so neither side needs direct knowledge of the other. This intermediary role satisfies the decoupling constraint: producers publish without waiting, and consumers subscribe independently, enabling asynchronous, scalable communication across the event-driven architecture.

Why this answer

The event broker (e.g., Apache Kafka, RabbitMQ, or AWS EventBridge) acts as an intermediary that receives events from producers and forwards them to consumers. By decoupling the two, the producer does not need to know the consumer's location or status, and the consumer does not need to be actively listening when the event is published. This enables asynchronous, scalable, and fault-tolerant communication in event-driven architectures.

Exam trap

CNCF often tests the distinction between synchronous and asynchronous communication patterns, and the trap here is that candidates mistakenly think an API gateway (which handles synchronous requests) can decouple producers and consumers in an event-driven architecture, when in fact it only routes requests without persistent event storage or asynchronous delivery.

How to eliminate wrong answers

Option B (Event consumer) is wrong because the consumer is the recipient of events, not the component that decouples producers from consumers; it relies on the broker for decoupling. Option C (Event producer) is wrong because the producer generates events but has no built-in mechanism to decouple itself from consumers without an intermediary. Option D (API gateway) is wrong because an API gateway is designed for synchronous request-response patterns (e.g., REST APIs) and does not provide the persistent, asynchronous event buffering and routing that decouples producers from consumers.

Full explanation →

699

Multi-Selecthard

Which THREE are common features of progressive delivery?

Select 3 answers

A.Feature flags to enable/disable features

B.Gradual traffic shifting

C.Automated analysis and rollback

D.All-at-once deployment

E.Manual verification for every change

AnswersA, B, C

Feature flags decouple deployment from release, letting operators enable or disable functionality at runtime for specific users or cohorts. This satisfies progressive delivery's requirement to expose changes to a subset first, so impact can be observed before full rollout.

Why this answer

Progressive delivery is an extension of continuous delivery that reduces release risk by exposing changes to a subset of users before full rollout, and feature flags (A) are a core mechanism because they decouple deployment from release, letting you enable or disable functionality for specific users, cohorts, or percentages without redeploying. Gradual traffic shifting (B) is also fundamental, as it incrementally routes a growing percentage of traffic to the new version (e.g., canary or blue/green with weighted routing) so impact can be observed at small blast radius. Automated analysis and rollback (C) is the third key feature, since progressive delivery relies on metrics/health signals (e.g., error rates, latency) to automatically promote or revert the release when thresholds are breached.

By contrast, all-at-once deployment (D) is the opposite of progressive delivery because it exposes every user simultaneously with no staged risk control, and manual verification for every change (E) contradicts the automation and continuous, data-driven promotion that progressive delivery depends on.

Exam trap

KCNA often tests whether candidates confuse progressive delivery with plain rolling updates — the trap is picking 'all-at-once' or 'manual verification' as features when both contradict the gradual, automated nature of progressive delivery.

Full explanation →

700

Multi-Selectmedium

A cluster administrator is configuring a Pod to use a ConfigMap for environment variables. Which two methods can be used to expose ConfigMap data as environment variables in a container? (Choose two.)

Select 2 answers

A.Using envFrom with a ConfigMap reference

B.Using env with valueFrom and a ConfigMapKeyRef

C.Using a Secret with the same name as the ConfigMap

D.Using a downward API to reference the ConfigMap

E.Mounting the ConfigMap as a volume

AnswersA, B

envFrom allows you to expose all key-value pairs from a ConfigMap as environment variables in the container. This is a convenient way to inject multiple variables at once. The keys must be valid environment variable names. This method is commonly used when you want to inject all data from a ConfigMap without specifying each key individually.

Why this answer

The two correct methods are using envFrom to expose all keys from a ConfigMap as environment variables, and using env with valueFrom.configMapKeyRef to expose a specific key. These are the standard ways to inject ConfigMap data as environment variables. Mounting as a volume provides files, not environment variables, and the downward API and Secrets are unrelated to ConfigMap data exposure.

Exam trap

The trap here is confusing volume mounts with environment variable injection, or assuming that Secrets and ConfigMaps are interchangeable for this purpose.

Full explanation →

701

Multi-Selectmedium

Which TWO statements accurately describe the concept of immutable infrastructure in the context of container orchestration? (Select two.)

Select 2 answers

A.Configuration changes can be applied via SSH into the container

B.Container images are versioned and promoted through environments without modification

C.When an update is needed, a new container image is built and deployed, and old containers are destroyed

D.Containers are updated in place by executing commands inside running containers

E.Stateful applications require mutable infrastructure

AnswersB, C

Immutable infrastructure promotes the same image through development, staging, and production without changes, ensuring consistency.

Why this answer

Immutable infrastructure treats container images as immutable artifacts that are versioned and promoted through environments (e.g., dev, staging, prod) without modification. This ensures consistency and reproducibility, as the same image is deployed across all stages without patching or altering it in place.

Exam trap

CNCF often tests the distinction between mutable and immutable patterns by presenting options that describe in-place updates (like SSH or exec commands) as valid, which candidates mistakenly accept if they confuse operational debugging with infrastructure management.

Full explanation →

702

MCQeasy

Which kubectl command would you use to view the logs of a specific pod?

A.kubectl logs <pod-name>

B.kubectl exec <pod-name> -- logs

C.kubectl describe pod <pod-name>

D.kubectl get logs <pod-name>

AnswerA

Retrieves stdout/stderr from a named container in the specified pod, satisfying the requirement to inspect that pod's output. The pod name is the positional argument; flags like -c and -f refine container selection or streaming but are not required to view logs.

Why this answer

`kubectl logs <pod-name>` is the standard Kubernetes command to retrieve logs from a specified pod. This command fetches the container's stdout and stderr streams, which are captured by the kubelet and stored as log files on the node. It directly accesses the pod's log output without requiring any additional flags or subcommands.

Exam trap

The trap here is that candidates confuse `kubectl logs` with `kubectl exec` or `kubectl describe`, thinking that logs are accessed via an exec command or that describe includes log output, when in fact logs are a distinct resource accessed through the dedicated `logs` subcommand.

How to eliminate wrong answers

Option B is wrong because `kubectl exec <pod-name> -- logs` attempts to execute a command called 'logs' inside the container, which does not exist; `kubectl exec` is used to run arbitrary commands in a running container, not to retrieve logs. Option C is wrong because `kubectl describe pod <pod-name>` displays detailed metadata, status, and events for a pod, but it does not show the actual log output from the container's stdout/stderr. Option D is wrong because `kubectl get logs` is not a valid kubectl subcommand; the correct verb is `logs`, not `get logs`, and `kubectl get` is used to list resources, not to fetch logs.

Full explanation →

703

MCQmedium

You want to run a batch job that processes data and then terminates. Which Kubernetes resource is best suited for this workload?

A.StatefulSet

B.DaemonSet

C.Job

D.Deployment

AnswerC

A Kubernetes Job creates one or more pods that run to completion, then stops — exactly matching a batch workload that processes data and terminates. Unlike a Deployment, which maintains a desired replica count indefinitely, a Job tracks successful completions, satisfying the stem's requirement for finite, run-to-finish execution.

Why this answer

A Kubernetes Job is designed for batch processing workloads that run to completion and then terminate. Unlike controllers that maintain a desired number of running Pods (like Deployments or StatefulSets), a Job creates one or more Pods and ensures they successfully exit. Once the specified number of successful completions is reached, the Job stops, making it the ideal choice for a one-time data processing task.

Exam trap

CNCF often tests the distinction between controllers that maintain 'desired state' (Deployments, StatefulSets) versus controllers that manage 'completion' (Jobs), and the trap here is that candidates mistakenly choose Deployment for any workload that 'processes data' without recognizing the terminating nature of the task.

How to eliminate wrong answers

Option A is wrong because a StatefulSet is used for stateful applications that require stable, unique network identities and persistent storage (e.g., databases), not for terminating batch jobs. Option B 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 tasks. Option D is wrong because a Deployment manages a set of identical Pods with a desired replica count and supports rolling updates, but it is designed for long-running services, not for workloads that should terminate after completion.

Full explanation →

704

MCQeasy

What is a primary benefit of using containers over virtual machines?

A.Containers provide stronger isolation than VMs

B.Containers can run any operating system kernel

C.Containers are lightweight and share the host OS kernel

D.Containers require a hypervisor to run

AnswerC

Containers share the host OS kernel, so they carry no guest operating system per instance. This eliminates the hypervisor and full OS overhead that virtual machines require, giving faster startup and higher density on the same hardware.

Why this answer

Containers virtualize at the operating system level, sharing the host OS kernel while running in isolated user-space instances. This eliminates the need for a full guest OS per workload, making containers significantly more lightweight in terms of memory, disk usage, and startup time compared to virtual machines, which each require a separate kernel and hypervisor.

Exam trap

CNCF often tests the misconception that containers provide stronger isolation than VMs, when in fact VMs offer hardware-enforced isolation via the hypervisor, and containers rely on software-enforced kernel isolation, which is weaker.

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than VMs; VMs use a hypervisor to enforce hardware-level isolation between guest kernels, while containers rely on kernel features like namespaces and cgroups, which share the host kernel and have a larger attack surface. Option B is wrong because containers cannot run any operating system kernel; they must use the same kernel as the host OS (e.g., Linux containers on a Linux host), and running a different kernel (e.g., Windows containers on Linux) requires a VM layer. Option D is wrong because containers do not require a hypervisor to run; they run directly on the host OS using container runtime engines like Docker or containerd, whereas VMs require a hypervisor (Type 1 or Type 2) to manage guest operating systems.

Full explanation →

705

MCQeasy

What is a key advantage of containers compared to virtual machines?

A.Containers provide stronger isolation than VMs

B.Containers are lightweight and share the host OS kernel

C.Containers include a full guest operating system

D.Containers require hypervisor software to run

AnswerB

Containers share the host operating system kernel, so each container packages only the application and its dependencies rather than a full guest OS. This removes per-instance kernel overhead, making containers smaller and faster to start than virtual machines.

Why this answer

Containers are lightweight because they share the host operating system kernel, avoiding the overhead of a separate guest OS per instance. Unlike VMs, which each include a full OS and require hypervisor mediation, containers run as isolated user-space processes on the same kernel, enabling faster startup times and higher density. This kernel sharing is the fundamental architectural advantage that makes containers more resource-efficient than virtual machines.

Exam trap

The trap here is that candidates often confuse 'isolation' with 'security' and assume containers are more secure because they are lightweight, but the CNCF exam tests the understanding that VMs provide stronger isolation via separate kernels and hypervisor-enforced boundaries.

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than VMs, as they share the host kernel and rely on kernel namespaces and cgroups for separation, whereas VMs use a hypervisor to provide hardware-level isolation with separate kernels. Option C is wrong because containers do not include a full guest operating system; they package only the application and its dependencies, leveraging the host OS kernel. Option D is wrong because containers do not require hypervisor software to run; they run directly on the host OS using the container runtime (e.g., containerd, Docker), while hypervisors are needed for VMs.

Full explanation →

706

MCQhard

Which of the following kubectl commands would you use to apply a manifest file and also save it for later updates?

A.kubectl create -f manifest.yaml

B.kubectl patch -f manifest.yaml

C.kubectl replace -f manifest.yaml

D.kubectl apply -f manifest.yaml

AnswerD

kubectl apply sends the manifest declaratively and records the applied configuration in the last-applied-configuration annotation, enabling subsequent three-way merges. This satisfies the requirement to apply a manifest and retain it for later updates, unlike create or replace.

Why this answer

`kubectl apply` uses a declarative approach: it creates the resource if it doesn't exist and updates it if it does, while also storing the last-applied configuration as an annotation (`kubectl.kubernetes.io/last-applied-configuration`). This allows future `apply` calls to perform a three-way merge diff (current live state, last-applied config, and new manifest) to intelligently update the resource, making it the standard for managing manifests that need ongoing updates.

Exam trap

The trap here is that candidates confuse `kubectl create` (which works for initial creation but fails on re-apply) with `kubectl apply` (which is idempotent and designed for ongoing updates), or they mistakenly think `kubectl replace` is equivalent to `apply` when it actually performs a full replacement without merge logic.

How to eliminate wrong answers

Option A is wrong because `kubectl create` is imperative and will fail with an error if the resource already exists, so it cannot be used for later updates. Option B is wrong because `kubectl patch` applies partial modifications directly to a live resource without saving the manifest state for future reconciliation; it does not store a last-applied configuration. Option C is wrong because `kubectl replace` is a destructive imperative command that replaces the entire resource definition, but it does not track the manifest for later updates and can cause drift if the resource was modified outside the manifest.

Full explanation →

707

MCQeasy

Which command would you use to view the logs of a specific container in a pod?

A.kubectl logs <pod-name>

B.kubectl logs <container-name>

C.kubectl logs <pod-name> -c <container-name>

D.kubectl describe pod <pod-name>

AnswerC

The -c flag scopes log retrieval to the named container within a multi-container pod, which is the constraint the stem implies. Without it, kubectl logs defaults to the pod's first container, returning the wrong output.

Why this answer

`kubectl logs <pod-name> -c <container-name>` explicitly targets a specific container within a pod. In Kubernetes, a pod can host multiple containers, and without the `-c` flag, `kubectl logs` defaults to the first container in the pod spec, which may not be the intended one. This command is essential for multi-container pods where each container has its own log stream.

Exam trap

The trap here is that candidates often assume `kubectl logs <pod-name>` works universally, forgetting that multi-container pods require the `-c` flag to specify the container, which Kubernetes frequently tests to assess understanding of pod-level vs. container-level operations.

How to eliminate wrong answers

Option A is wrong because `kubectl logs <pod-name>` only works for single-container pods; in multi-container pods, it either returns an error or defaults to the first container, not allowing selection of a specific container. Option B is wrong because `kubectl logs <container-name>` is not a valid syntax; the command requires a pod name as the primary argument, and a container name is only specified via the `-c` flag. Option D is wrong because `kubectl describe pod <pod-name>` shows pod metadata, events, and container statuses, but does not display container logs; it is used for debugging pod configuration, not for retrieving log output.

Full explanation →

708

MCQmedium

A company wants to manage its Kubernetes resources using Git as the single source of truth, with automated synchronization. Which approach should they use?

A.Using Helm charts without version control

B.Infrastructure as Code with Terraform

C.Using kubectl apply -f with a CI/CD pipeline

D.GitOps with ArgoCD or Flux

AnswerD

GitOps treats a Git repository as the declarative source of truth, with agents such as ArgoCD or Flux continuously reconciling cluster state to match committed manifests. This delivers the automated synchronisation the company requires, detecting drift and reapplying desired configuration without manual kubectl intervention.

Why this answer

GitOps uses Git as the declarative source of truth for cluster state, with an in-cluster agent (ArgoCD or Flux) continuously reconciling the live cluster to match the repository. This provides automated synchronization, drift detection, and auditable change history via Git commits and pull requests. It is the canonical answer when the requirement is 'Git as single source of truth with automated sync.'

Exam trap

The trap is confusing IaC with GitOps — candidates pick Terraform because it is 'infrastructure as code,' but GitOps specifically means continuous reconciliation of Kubernetes state from Git, which Terraform does not do.

How to eliminate wrong answers

Option A is wrong because Helm charts without version control lose the auditability and single-source-of-truth property that GitOps requires. Option B is wrong because Terraform is infrastructure-as-code for provisioning cloud resources, not for continuously reconciling Kubernetes manifests to a cluster. Option C is wrong because kubectl apply from a CI pipeline is push-based and imperative; it lacks continuous reconciliation and drift correction, so it is not GitOps.

Full explanation →

709

Multi-Selectmedium

Which TWO are pillars of observability? (Select two.)

Select 2 answers

A.SLIs

B.Alerting

C.Logs

D.Metrics

E.Dashboards

AnswersC, D

Logs are one of observability's pillars, recording discrete timestamped events that reveal what happened within a system. This satisfies the stem's requirement by providing the detailed, high-cardinality event data that metrics and traces alone cannot capture for debugging specific failures.

Why this answer

Logs and Metrics are two of the three pillars of observability (alongside Traces). Logs provide immutable, timestamped records of discrete events, while Metrics are numeric aggregations of data over time (e.g., Prometheus counters, histograms). Together they form the foundation for understanding system behavior in cloud-native environments.

Exam trap

CNCF often tests the distinction between the pillars of observability (Logs, Metrics, Traces) and the tools or outputs derived from them (e.g., SLIs, Alerting, Dashboards), leading candidates to confuse operational practices with foundational data types.

Full explanation →

710

MCQmedium

A team wants to implement a canary deployment strategy for their Kubernetes application. Which tool is specifically designed for progressive delivery and can be used to automate canary rollouts?

A.Argo Rollouts

B.Flux

C.Kustomize

D.Helm

AnswerA

Argo Rollouts provides a Kubernetes controller and custom resources that automate canary progression, shifting traffic in weighted increments and analysing metrics before promotion. This satisfies the stem's requirement for a tool specifically designed for progressive delivery, unlike standard Deployments, which only support rolling updates without metric-driven canary automation.

Why this answer

Argo Rollouts is a Kubernetes controller and set of CRDs that provides advanced deployment capabilities such as blue-green and canary deployments with automated promotion and rollback.

Full explanation →

711

MCQmedium

A developer wants to deploy a stateful application that requires stable network identities and persistent storage per pod instance. Which Kubernetes resource is most appropriate?

A.DaemonSet

B.Job

C.Deployment

D.StatefulSet

AnswerD

StatefulSet assigns each pod a stable ordinal hostname and a dedicated PersistentVolumeClaim via volumeClaimTemplates, preserving identity and storage across restarts. Deployments give interchangeable pods with shared or ephemeral volumes, so they cannot satisfy the per-instance persistence constraint.

Why this answer

StatefulSet is the correct choice because it is specifically designed for stateful applications that require stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage per pod instance (via PersistentVolumeClaims that are not shared across replicas). Unlike Deployments, StatefulSet maintains a sticky identity for each pod, ensuring that on rescheduling, the pod retains its name, network identity, and bound storage.

Exam trap

CNCF often tests the misconception that a Deployment with PersistentVolumeClaims is sufficient for stateful workloads, but the trap is that Deployments do not guarantee stable network identities or ordered pod naming, which are critical for applications like databases that rely on hostname-based clustering.

How to eliminate wrong answers

Option A (DaemonSet) is wrong because it ensures exactly one pod runs on each node, which is ideal for node-level agents (e.g., log collectors, monitoring daemons), not for stateful applications needing stable identities and per-instance storage. Option B (Job) is wrong because it is designed for batch or one-off tasks that run to completion, not for long-running stateful services that require persistent storage and stable network identities. Option C (Deployment) is wrong because it treats pods as ephemeral and interchangeable; while it supports persistent storage via PersistentVolumeClaims, it does not guarantee stable network identities or ordered pod naming, so a rescheduled pod gets a new name and IP, breaking stateful expectations.

Full explanation →

712

MCQmedium

What is the primary purpose of a service mesh in a cloud-native architecture?

A.To compile application code

B.To provide a dedicated infrastructure layer for handling service-to-service communication

C.To replace container orchestration

D.To store application configuration

AnswerB

A service mesh supplies a dedicated infrastructure layer, typically via sidecar proxies, that handles service-to-service communication concerns such as traffic routing, mutual TLS, retries and observability. This offloads those functions from application code, satisfying the cloud-native communication requirement.

Why this answer

A service mesh provides a dedicated infrastructure layer for managing service-to-service communication, typically using sidecar proxies. It handles traffic management, security, and observability without requiring changes to application code. This allows developers to focus on business logic while the mesh handles cross-cutting concerns.

Exam trap

KCNA often tests the confusion between service mesh and container orchestration, leading candidates to think a service mesh replaces Kubernetes or handles scaling, when it actually focuses on communication.

How to eliminate wrong answers

Option A is wrong because service meshes do not compile application code; that is the role of build tools and compilers. Option C is wrong because service meshes complement container orchestration (like Kubernetes) rather than replace it; orchestration handles deployment and scaling, while the mesh handles communication. Option D is wrong because storing application configuration is typically handled by configuration management systems (e.g., ConfigMaps, Consul), not service meshes.

Full explanation →

713

MCQhard

A developer creates a Pod with a single container that writes logs to stdout. The Pod is running, but the developer wants to view the last 50 lines of logs from that container and have the command keep streaming new output. Which kubectl command accomplishes this?

A.kubectl logs mypod -c app --tail=50 -f

B.kubectl logs mypod --since=50 -f

C.kubectl describe pod mypod --tail=50 -f

D.kubectl logs mypod --tail=50 --follow=false

AnswerA

This command targets the container named app in the Pod, limits the initial output to the last 50 lines with --tail=50, and follows the log stream with -f. It satisfies both requirements: showing recent history and streaming new entries. The -c flag is necessary only if the Pod has multiple containers, but it is valid and precise here.

Why this answer

The kubectl logs command retrieves container output. The --tail flag limits the number of historical lines, and -f or --follow streams subsequent entries. Combining them gives the last 50 lines plus live updates.

The -c flag selects a container when more than one exists. Other flags such as --since use time durations, and describe is unrelated to log retrieval.

Exam trap

The trap here is confusing --tail, which counts lines, with --since, which takes a time duration.

Full explanation →

714

Multi-Selectmedium

A team is adopting a GitOps workflow with Argo CD to manage Kubernetes applications. They want to ensure that the cluster state always matches the desired state in Git and that changes are automatically applied. Which two Argo CD features should they configure? (Choose two.)

Select 2 answers

A.Sync windows

B.Resource hooks

C.Self-heal

D.Automated sync policy

E.Manual sync policy

AnswersC, D

Self-heal is a sub-feature of automated sync that reverts manual changes to the cluster, ensuring the live state always reflects Git. Without self-heal, manual edits could persist, causing drift. Configuring self-heal ensures that any out-of-band modifications are automatically corrected, which is essential for the team's goal of continuous state matching.

Why this answer

To ensure the cluster state always matches Git and changes are automatically applied, the team must enable automated sync policy and self-heal in Argo CD. Automated sync applies Git changes without manual intervention, while self-heal reverts any manual cluster modifications, maintaining the desired state. Manual sync, resource hooks, and sync windows do not provide these automatic reconciliation capabilities.

Exam trap

The trap here is confusing sync windows or hooks with automatic reconciliation; only automated sync and self-heal provide continuous state enforcement.

Full explanation →

715

MCQeasy

Which Kubernetes object provides stable network endpoints and load balancing for a set of pods?

A.Deployment

B.ConfigMap

C.Service

D.Pod

AnswerC

A Kubernetes Service provides a stable virtual IP and DNS name that persists independently of pod lifecycles, satisfying the stem’s requirement for stable network endpoints. It uses label selectors to identify target pods and distributes incoming traffic across them via kube-proxy’s iptables or IPVS rules, fulfilling the load-balancing constraint without relying on individual pod IPs that change on rescheduling.

Why this answer

A Kubernetes Service provides a stable virtual IP (ClusterIP) and DNS name that remains constant even as Pods are created or destroyed. It uses label selectors to identify target Pods and performs TCP/UDP load balancing across them, ensuring reliable network access without requiring clients to track ephemeral Pod IPs.

Exam trap

The trap here is that candidates often confuse a Deployment’s ability to manage Pod replicas with providing a stable network endpoint, forgetting that Pod IPs are ephemeral and only a Service offers a fixed virtual IP and load balancing.

How to eliminate wrong answers

Option A is wrong because a Deployment manages Pod replicas and their rollout strategy, but it does not provide a stable network endpoint or load balancing; Pod IPs change on restart. Option B is wrong because a ConfigMap is used to inject configuration data (key-value pairs) into Pods, not to expose network endpoints. Option D is wrong because a Pod is an ephemeral unit with a non-static IP address; it cannot guarantee stable network access or load balancing across multiple Pods.

Full explanation →

716

MCQmedium

In Flux CD, which component is responsible for reconciling the cluster state with the source of truth defined in a Git repository?

A.Kustomize controller

B.Source controller

C.Helm controller

D.Notification controller

AnswerA

The Kustomize controller continuously reconciles cluster state against Kustomization manifests sourced from Git, applying declared resources and pruning drift. It satisfies the stem's requirement for the component that pulls the source of truth from Git and enforces it, rather than merely building manifests or serving artefacts.

Why this answer

The Kustomize controller in Flux CD is responsible for reconciling the cluster state with the desired state defined in a Git repository. It continuously monitors Kustomization custom resources, fetches the referenced source artifact (e.g., from a GitRepository), builds the manifests using Kustomize, and applies them to the cluster. This controller ensures that the actual state matches the declared state, making it the core reconciler for GitOps workflows in Flux.

Exam trap

KCNA often tests the distinction between Flux controllers, and candidates may confuse the Source controller (which fetches artifacts) with the Kustomize controller (which applies them), leading to incorrect answers.

How to eliminate wrong answers

Option B is wrong because the Source controller only fetches artifacts from external sources like Git repositories, Helm repositories, and OCI registries; it does not apply or reconcile cluster state. Option C is wrong because the Helm controller manages HelmRelease objects, reconciling Helm charts and releases, not raw Kustomize or Git-defined manifests. Option D is wrong because the Notification controller handles event dispatching and alerts (e.g., to Slack, Teams) based on Flux events; it plays no role in state reconciliation.

Full explanation →

717

Multi-Selecteasy

Which TWO of the following are examples of Infrastructure as Code (IaC) tools? (Choose two.)

Select 2 answers

A.Docker

B.Terraform

C.Kubernetes

D.Prometheus

E.Pulumi

AnswersB, E

Terraform is an IaC tool by HashiCorp.

Why this answer

Terraform (B) is an Infrastructure as Code (IaC) tool that uses declarative configuration files (HashiCorp Configuration Language, HCL) to define and provision cloud and on-premises resources. It manages the full lifecycle of infrastructure through a state file and provider plugins, enabling version-controlled, repeatable deployments.

Exam trap

CNCF often tests the distinction between containerization/orchestration tools (Docker, Kubernetes) and actual IaC tools, leading candidates to confuse tools that manage applications with those that provision infrastructure.

Full explanation →

718

MCQmedium

Which open-source project provides a unified standard for collecting and exporting telemetry data (metrics, logs, and traces) from applications?

A.Prometheus

B.OpenTelemetry

C.Jaeger

D.Fluentd

AnswerB

OpenTelemetry is the CNCF project supplying vendor-neutral APIs, SDKs and specifications for metrics, logs and traces together, so it satisfies the stem's requirement for one unified standard covering all three telemetry signals rather than separate per-signal agents.

Why this answer

OpenTelemetry (OTel) is a CNCF project that provides a vendor-neutral, unified standard — APIs, SDKs, and the Collector — for instrumenting applications to emit metrics, logs, and traces. It solves the fragmentation problem where each backend required its own agent and format. OTel is the answer when the question asks for a unified telemetry collection and export standard.

Exam trap

KCNA often tests the difference between a telemetry standard and a backend — candidates pick Prometheus or Jaeger because they recognize the names, missing that the question asks for the unified collection/export standard, which is OpenTelemetry.

How to eliminate wrong answers

Option A is wrong because Prometheus is a metrics-only monitoring system and time-series database; it does not unify logs and traces. Option C is wrong because Jaeger is a distributed tracing backend focused solely on traces, not a unified telemetry standard. Option D is wrong because Fluentd is a log collection and forwarding tool; it handles logs only and is not a cross-signal standard.

Full explanation →

719

MCQeasy

Which command is used to create a Deployment that runs an nginx container with 3 replicas?

A.kubectl create pod nginx --image=nginx --replicas=3

B.kubectl run nginx --image=nginx --replicas=3

C.kubectl create deployment nginx --image=nginx --replicas=3

D.kubectl scale deployment nginx --replicas=3

AnswerC

The `--replicas=3` flag on `kubectl create deployment` directly satisfies the stem's three-replica constraint, while `--image=nginx` specifies the container image. This imperative command generates the Deployment manifest server-side, so no YAML file is needed to achieve the required nginx workload at the stated scale.

Why this answer

`kubectl create deployment` is the standard Kubernetes command to create a Deployment resource, and the `--replicas=3` flag directly sets the desired replica count to 3. This command creates a Deployment that manages a ReplicaSet to ensure three nginx pods are running and maintained.

Exam trap

The trap here is that candidates confuse `kubectl run` (which creates a pod, not a deployment with replicas) with `kubectl create deployment`, or they mistakenly think `kubectl scale` can create a deployment, when it only modifies an existing one.

How to eliminate wrong answers

Option A is wrong because `kubectl create pod` does not exist; pods are created imperatively with `kubectl run` or declaratively via a manifest, and `--replicas` is not a valid flag for pod creation. Option B is wrong because `kubectl run` creates a single pod (or a deployment in older versions, but not with `--replicas`); the `--replicas` flag is not supported by `kubectl run` in current Kubernetes versions. Option D is wrong because `kubectl scale deployment` modifies an existing Deployment's replica count, but it does not create a new Deployment; the question asks for creating a Deployment, not scaling an existing one.

Full explanation →

720

MCQmedium

A team wants to minimize downtime during a Deployment rollout. Which strategy ensures that new pods are created before old pods are terminated?

A.Set strategy type to 'Recreate'.

B.Set strategy type to 'RollingUpdate' with maxSurge=0, maxUnavailable=1.

C.Set strategy type to 'RollingUpdate' with maxSurge=1, maxUnavailable=0.

D.Set strategy type to 'RollingUpdate' with maxSurge=1, maxUnavailable=1.

AnswerC

RollingUpdate replaces pods incrementally; maxUnavailable=0 forbids any capacity drop, so the controller must create new pods before terminating old ones. maxSurge=1 permits one extra pod above the desired replica count, guaranteeing the zero-downtime constraint the team requires.

Why this answer

Setting `maxSurge=1` and `maxUnavailable=0` in a RollingUpdate strategy ensures that one additional pod is created above the desired replica count before any existing pod is terminated. This guarantees zero downtime by maintaining full capacity during the rollout, as new pods become ready before old ones are removed.

Exam trap

The trap here is that candidates often confuse `maxSurge` and `maxUnavailable` values, mistakenly thinking that allowing both a surge and an unavailable pod (option D) is safer, when in fact it can still cause a temporary capacity drop if the new pod is not ready before the old one is terminated.

How to eliminate wrong answers

Option A is wrong because the 'Recreate' strategy terminates all old pods before creating new ones, causing downtime. Option B is wrong because `maxSurge=0, maxUnavailable=1` terminates one old pod before creating a new one, which can cause a temporary capacity deficit and potential downtime. Option D is wrong because `maxSurge=1, maxUnavailable=1` allows both a new pod to be created and an old pod to be terminated simultaneously, which may still result in a brief capacity drop if the new pod is not ready before the old one is removed.

Full explanation →

721

MCQeasy

What is a key benefit of container orchestration platforms like Kubernetes?

A.Containers are tightly coupled to the underlying hardware

B.Each container runs its own operating system kernel

C.Containers can only run on a single host

D.Self-healing capabilities automatically restart failed containers

AnswerD

Kubernetes controllers continuously reconcile actual state against desired state; when a container or pod fails, the ReplicaSet creates a replacement automatically. This self-healing loop restores the declared replica count without manual intervention, the benefit described.

Why this answer

Kubernetes provides self-healing capabilities through controllers like ReplicaSets and Deployments, which continuously monitor the desired state of containers. If a container fails or becomes unresponsive, the control plane automatically restarts or reschedules it, ensuring high availability without manual intervention. This is a core benefit of container orchestration platforms, as it abstracts away the operational overhead of managing individual container lifecycles.

Exam trap

A common misconception is that container orchestration is primarily about scaling or deployment, but the key differentiator is the automated recovery and health management that distinguishes orchestration from simple container runtimes.

How to eliminate wrong answers

Option A is wrong because containers are not tightly coupled to underlying hardware; they are abstracted from the host OS via namespaces and cgroups, enabling portability across different infrastructure. Option B is wrong because containers share the host operating system kernel, unlike virtual machines that each run their own kernel; this is a fundamental characteristic of containerization. Option C is wrong because orchestration platforms like Kubernetes are designed to schedule containers across multiple hosts in a cluster, enabling distributed deployment and scaling.

Full explanation →

722

Multi-Selectmedium

Which THREE of the following are valid use cases for distributed tracing in a microservices architecture?

Select 3 answers

A.Monitoring CPU and memory usage of each service instance

B.Understanding the dependency graph between microservices

C.Pinpointing the root cause of an error in a distributed transaction

D.Identifying which service contributes the most latency to an end-user request

E.Capturing detailed error messages and stack traces

AnswersB, C, D

Distributed tracing records spans across service calls, letting teams reconstruct which services invoke which, including latency and error propagation. That reconstructed call graph directly reveals the dependency graph between microservices, a core tracing use case.

Why this answer

Distributed tracing is designed to follow a single request as it propagates across service boundaries, so option B is correct because the spans and parent-child relationships recorded in a trace directly reveal the dependency graph and call topology between microservices. Option C is correct because a trace correlates spans across services with shared trace IDs, letting you locate the exact failing span and thus the root cause of an error in a distributed transaction. Option D is correct because span durations and timestamps expose per-service latency contributions, making it possible to identify which service adds the most latency to an end-user request.

Option A is not a tracing use case; CPU and memory usage per instance are collected by metrics/monitoring tools such as Prometheus or CloudWatch, not by distributed tracing. Option E is also not specific to tracing; detailed error messages and stack traces are typically captured by centralized logging or error-tracking systems, even though traces may carry limited error tags.

Exam trap

The KCNA exam often tests the distinction between observability pillars (metrics, logs, traces) and expects candidates to recognize that distributed tracing is not a catch-all for monitoring or logging tasks, so the trap is confusing request-level tracing with infrastructure metrics or detailed error logging.

Full explanation →

723

MCQeasy

What is a key benefit of using containers over virtual machines for application deployment?

A.Containers can only run on Linux

B.Containers require a hypervisor to run

C.Containers provide stronger isolation than VMs

D.Containers are more lightweight and start faster than VMs

AnswerD

Containers share the host OS kernel rather than each running a full guest operating system, so they carry no hypervisor overhead and need far less memory and disk. This architectural difference lets container instances start in seconds, directly satisfying the requirement for lightweight, fast-starting deployment compared with virtual machines.

Why this answer

Containers share the host OS kernel and run as isolated processes, requiring no separate guest OS per instance. This makes them significantly more lightweight and faster to start than VMs, which must boot a full guest OS. For application deployment, this translates to higher density, lower resource overhead, and near-instant startup times.

Exam trap

The trap here is that candidates often confuse 'stronger isolation' with 'better security' and pick Option C, not realizing that VMs actually provide stronger isolation due to separate kernels and hardware virtualization, while containers are designed for lightweight efficiency, not maximum isolation.

How to eliminate wrong answers

Option A is wrong because containers are not limited to Linux; Windows containers run on Windows Server and Docker Desktop supports both Linux and Windows containers via appropriate runtimes. Option B is wrong because containers do not require a hypervisor; they run directly on the host OS using kernel features like cgroups and namespaces, whereas VMs require a hypervisor to virtualize hardware. Option C is wrong because VMs provide stronger isolation than containers; each VM has its own separate kernel and hardware virtualization, while containers share the host kernel, making isolation weaker by design.

Full explanation →

724

Multi-Selecthard

Which THREE of the following are resiliency patterns commonly used in cloud native applications? (Choose three.)

Select 3 answers

A.Retry

B.Timeout

C.Singleton pattern

D.Circuit breaker

E.Round-robin load balancing

AnswersA, B, D

Retrying failed operations can handle transient failures.

Why this answer

The Retry pattern is a fundamental resiliency mechanism in cloud-native applications. When a transient failure occurs (e.g., a network timeout or a temporary database unavailability), the application automatically reattempts the failed operation. This pattern is often implemented with exponential backoff and jitter to avoid overwhelming the downstream service, as seen in libraries like Netflix Hystrix or Kubernetes client-go retry logic.

Exam trap

CNCF often tests the distinction between design patterns (like Singleton) and cloud-native resiliency patterns (like Retry, Timeout, Circuit Breaker), so candidates mistakenly select Singleton because it is a well-known pattern, but it does not address fault tolerance or failure recovery.

Full explanation →

725

MCQmedium

Which kubectl command is used to apply a manifest file to create or update resources?

A.kubectl update -f manifest.yaml

B.kubectl run -f manifest.yaml

C.kubectl apply -f manifest.yaml

D.kubectl create -f manifest.yaml

AnswerC

`kubectl apply -f manifest.yaml` performs a declarative create-or-update against the cluster's live state, satisfying the stem's dual requirement. It reads the manifest, compares it with the stored last-applied configuration, then patches only the differences — creating the resource when absent and updating it when present, without deleting and recreating.

Why this answer

`kubectl apply -f manifest.yaml` is the declarative management command that creates or updates resources by applying a configuration manifest. It uses a three-way merge algorithm to compute the changes needed to reconcile the desired state in the manifest with the current state in the cluster, making it suitable for both initial creation and subsequent updates.

Exam trap

The trap here is that candidates confuse `kubectl create` (imperative, fails on existing resources) with `kubectl apply` (declarative, handles both create and update), leading them to choose option D when they see 'create or update' in the question.

How to eliminate wrong answers

Option A is wrong because `kubectl update` is not a valid kubectl command; the correct imperative update command is `kubectl edit` or `kubectl patch`, and `kubectl apply` is the declarative approach. Option B is wrong because `kubectl run` is used to create a pod or deployment imperatively from an image, not to apply a manifest file; it does not accept a `-f` flag for a manifest file. Option D is wrong because `kubectl create -f manifest.yaml` only creates resources and will fail if the resource already exists, whereas `kubectl apply` handles both creation and updates idempotently.

Full explanation →

726

MCQmedium

A CI pipeline builds a container image and tags it as 'myapp:latest'. The pipeline then pushes the image to a registry. A Kubernetes Deployment manifest references 'myapp:latest' with imagePullPolicy: Always. After a new image is pushed with the same tag, the team notices that existing Pods are not updated. What is the most likely reason?

A.The Deployment's pod template spec has not changed, so no rolling update is triggered.

B.The container registry does not support overwriting existing tags.

C.The imagePullPolicy: Always setting causes Kubernetes to ignore the new image.

D.The Deployment's rollout strategy is set to Recreate, which prevents updates.

AnswerA

Kubernetes Deployments trigger rolling updates only when the pod template spec changes. Pushing a new image with the same tag does not modify the template, so the Deployment controller sees no difference and does not create new ReplicaSets or update Pods. Even with imagePullPolicy: Always, existing Pods are not restarted. Thus, the Deployment remains unchanged and Pods continue running the old image.

Why this answer

A Kubernetes Deployment initiates a rolling update only when the pod template spec changes, such as an image tag or environment variable. Overwriting an existing image tag does not alter the template, so the Deployment controller does not roll out new Pods. Even with imagePullPolicy: Always, existing Pods are not restarted.

To force an update, the team must change the image tag or another template field.

Exam trap

The trap here is assuming that pushing a new image with the same tag automatically updates running Pods; Kubernetes requires a template change to trigger a rollout.

Full explanation →

727

MCQeasy

Which CNCF project provides a graduated service mesh implementation that includes features like traffic management, security, and observability?

A.Linkerd

B.Consul

C.Envoy

D.Istio

AnswerA

Correct. Linkerd is a graduated CNCF service mesh.

Why this answer

Linkerd is a graduated CNCF project that provides a service mesh with features like traffic management, security (mTLS), and observability. Istio is also a service mesh but is incubating, not graduated. Envoy is a graduated proxy but not a full service mesh.

Consul is not a CNCF project.

Full explanation →

728

MCQhard

A user creates a Pod with a PersistentVolumeClaim (PVC) that requests 5Gi of storage. The cluster has two PersistentVolumes (PVs): PV1 (3Gi, AccessModes: ReadWriteOnce) and PV2 (10Gi, AccessModes: ReadOnlyMany). The PVC specifies storageClassName: "" and AccessModes: ReadWriteOnce. Which PV will bind to the PVC?

A.PV2 will bind because it has sufficient capacity.

B.Neither PV will bind; the PVC will remain pending.

C.PV1 will bind because it has matching AccessModes.

D.Both PVs will bind to satisfy the request.

AnswerB

Binding requires matching capacity and access modes. PV1 is too small for the 5Gi request, while PV2 offers only ReadOnlyMany, not the requested ReadWriteOnce. With no storage class, no other PV satisfies both constraints, so the PVC stays Pending.

Why this answer

The PVC specifies storageClassName: "", which means it requires a PV with the same empty storage class (i.e., a statically provisioned PV without a StorageClass). PV1 has 3Gi capacity, which is less than the requested 5Gi, so it fails capacity matching. PV2 has ReadOnlyMany access mode, which does not match the PVC's ReadWriteOnce.

Since neither PV satisfies all binding criteria (capacity, access modes, and storage class), the PVC remains Pending.

Exam trap

The trap here is that candidates assume capacity is the only criterion or that a larger PV can compensate for mismatched access modes, but Kubernetes requires all three conditions (capacity, access modes, and storage class) to match exactly for a static PV to bind.

How to eliminate wrong answers

Option A is wrong because PV2 has ReadOnlyMany access mode, which does not match the PVC's ReadWriteOnce, and the storage class mismatch (empty string vs. implicit) also prevents binding; capacity alone is insufficient. Option C is wrong because PV1 has only 3Gi capacity, which is less than the PVC's request of 5Gi, so it fails the capacity requirement even though access modes match. Option D is wrong because a PVC binds to exactly one PV that satisfies all criteria; multiple PVs cannot bind to satisfy a single PVC request.

Full explanation →

729

MCQeasy

Which component is responsible for running containers on a Kubernetes node?

A.kube-controller-manager

B.kube-proxy

C.kube-apiserver

D.kubelet

AnswerD

The kubelet is the node agent that receives PodSpecs from the control plane and instructs the container runtime to start, stop and monitor containers. It satisfies the stem's constraint of running containers on a node, whereas the API server, scheduler and controller manager operate at cluster level.

Why this answer

The kubelet is the primary node agent that runs on each Kubernetes node. It is responsible for ensuring that containers are running in a Pod as expected, by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers based on PodSpecs received from the API server.

Exam trap

The trap here is that candidates often confuse kubelet with kube-controller-manager, thinking the controller manager handles node-level container operations, but the kubelet is the only component that directly manages containers on the node.

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager runs controller processes (like Node Controller, Replication Controller) at the control plane level, not on worker nodes, and does not directly manage containers. Option B is wrong because kube-proxy is a network proxy that handles network rules and service load balancing on each node, but it does not run or manage containers. Option C is wrong because kube-apiserver is the front-end of the Kubernetes control plane that exposes the Kubernetes API; it validates and processes RESTful requests but does not execute container lifecycle operations on nodes.

Full explanation →

730

MCQmedium

Which command is used to view the logs of a pod named 'web-pod'?

A.kubectl logs web-pod

B.kubectl describe pod web-pod

C.kubectl get logs web-pod

D.kubectl exec web-pod -- logs

AnswerA

kubectl logs retrieves stdout/stderr from a named pod's containers, satisfying the requirement to view 'web-pod' output. The logs subcommand targets a single pod directly, unlike exec or describe, which inspect state rather than emitted log streams.

Why this answer

The correct command to view logs from a pod in Kubernetes is 'kubectl logs web-pod'. This command retrieves the current stdout/stderr output from the primary container in the specified pod, which is the standard method for accessing container logs without entering the pod.

Exam trap

A common trap is confusing 'kubectl logs' with 'kubectl describe'. Candidates mistakenly think 'describe' shows logs due to its verbose output, but it only shows events and configuration, not the actual log stream.

How to eliminate wrong answers

Option B is wrong because 'kubectl describe pod web-pod' shows detailed metadata, status, and events for the pod, but does not display container logs; it provides configuration and state information, not log output. Option C is wrong because 'kubectl get logs' is not a valid kubectl subcommand; the correct subcommand is 'logs', and 'get' is used for resources like pods or deployments, not for log retrieval. Option D is wrong because 'kubectl exec web-pod -- logs' attempts to run a command named 'logs' inside the container, which does not exist; 'kubectl exec' is for executing arbitrary commands in a container, not for fetching logs, and would fail unless the container has a 'logs' binary.

Full explanation →

731

MCQhard

In a serverless architecture using Knative, what happens to a service that has not received traffic for an extended period?

A.It throws an error and must be redeployed

B.It continues running with one replica to reduce cold start latency

C.It scales down to zero replicas and is reactivated on the next request

D.It is automatically deleted

AnswerC

Knative's autoscaler, via the Activator and queue-proxy, reduces idle services to zero replicas after the configured scale-to-zero window, eliminating compute cost. The next incoming request is buffered by the Activator, which spins up a pod and forwards traffic.

Why this answer

Knative scales to zero when idle, meaning no pods are running, thus no cost incurred.

Full explanation →

732

MCQmedium

You are writing a Deployment YAML (apps/v1) for a stateless web application. The application should have 3 replicas and use rolling updates with maxSurge=1 and maxUnavailable=0. Which field should you set under spec.strategy?

A.type: Recreate

B.type: Canary

C.type: OnDelete

D.type: RollingUpdate with rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }

AnswerD

RollingUpdate is the only strategy type supporting maxSurge and maxUnavailable. Setting maxSurge: 1 and maxUnavailable: 0 adds one new pod before terminating any old pod, guaranteeing three available replicas throughout the rollout, exactly as the stem requires.

Why this answer

The Deployment's `spec.strategy.type` must be set to `RollingUpdate` to enable a controlled, incremental update of pods. The `rollingUpdate` field then allows you to specify `maxSurge: 1` (one extra pod above the desired count during update) and `maxUnavailable: 0` (ensure all existing pods remain available during the update), which is the exact configuration for a zero-downtime rolling update with a single surge pod.

Exam trap

CNCF often tests the misconception that `maxSurge` and `maxUnavailable` are top-level fields under `spec.strategy`, when in fact they must be nested inside `rollingUpdate` and the `type` must explicitly be set to `RollingUpdate`.

How to eliminate wrong answers

Option A is wrong because `type: Recreate` terminates all existing pods before creating new ones, which violates the requirement for a rolling update with `maxSurge` and `maxUnavailable` settings. Option B is wrong because `Canary` is not a valid Deployment strategy type in the `apps/v1` API; it is a separate deployment pattern often implemented via service mesh or progressive delivery tools, not a native Kubernetes Deployment field. Option C is wrong because `OnDelete` is a strategy type used by StatefulSets (not Deployments) and only triggers pod replacement when a pod is manually deleted, which does not support automated rolling updates or the specified surge/unavailable parameters.

Full explanation →

733

MCQeasy

What does SLA stand for in the context of service reliability?

A.Service Level Agreement

B.Service Level Indicator

C.Service Level Availability

D.Service Level Objective

AnswerA

SLA denotes Service Level Agreement, a documented commitment defining expected service levels such as availability, latency and error budgets. In service reliability it formalises the target against which reliability is measured and error budgets are derived.

Why this answer

SLA stands for Service Level Agreement, a contract specifying expected service level.

Full explanation →

734

MCQmedium

An administrator needs to store a database password for a Pod to consume as an environment variable. The password must be stored securely and not exposed in the Pod specification. Which Kubernetes resource should the administrator create?

A.A ConfigMap

B.A Secret

C.A PersistentVolumeClaim

D.A ServiceAccount

AnswerB

A Secret is designed to hold sensitive data such as passwords, tokens, or keys. It can be mounted as a volume or exposed as an environment variable without embedding the value in the Pod spec. By referencing the Secret in the Pod spec, the administrator keeps the password out of the manifest, matching the security requirement.

Why this answer

Secrets are the Kubernetes resource for storing sensitive data and can be referenced in Pod specs as environment variables or mounted volumes. ConfigMaps are for non-sensitive configuration, PersistentVolumeClaims provide storage, and ServiceAccounts provide API identities. Only a Secret meets the requirement of secure, out-of-manifest password storage.

Exam trap

The trap here is assuming ConfigMaps are suitable for any configuration, including passwords, when they are not designed for sensitive data.

Full explanation →

735

MCQhard

An application running in a Kubernetes cluster needs to securely access a third-party API. The API key must be stored in the cluster and mounted into the Pod as an environment variable. Which is the best practice?

A.Create a Secret with the API key and use envFrom or valueFrom in the Pod spec.

B.Store the API key in a ConfigMap and reference it in the Pod spec.

C.Embed the API key directly in the container image.

D.Store the API key in a Pod annotation and read it with kubectl.

AnswerA

A Secret stores the API key separately from the image and Pod spec, and envFrom or valueFrom injects it as an environment variable at runtime. This satisfies the requirement to mount the key into the Pod without hard-coding credentials in the manifest or container image.

Why this answer

Kubernetes Secrets are specifically designed to store sensitive data like API keys, and using `envFrom` or `valueFrom` in the Pod spec injects the Secret value as an environment variable without exposing it in the Pod definition. This approach follows the principle of least privilege and avoids hardcoding secrets in images or plaintext ConfigMaps.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming both are equally secure for sensitive data, but Kubernetes tests the understanding that ConfigMaps store data in plaintext and are not encrypted, making them unsuitable for secrets like API keys.

How to eliminate wrong answers

Option B is wrong because ConfigMaps store data in plaintext and are intended for non-sensitive configuration, not secrets; using a ConfigMap for an API key would expose it in etcd and logs. Option C is wrong because embedding the API key directly in the container image violates security best practices, as the key would be baked into the image layers and accessible to anyone with image pull access. Option D is wrong because Pod annotations are metadata fields not designed for secret storage, and reading them with kubectl would expose the key in the API server and command output.

Full explanation →

736

Multi-Selecthard

Which THREE of the following are true about Kubernetes labels and selectors?

Select 3 answers

A.Labels are encrypted at rest by default

B.Set-based selectors support operators like 'In' and 'NotIn'

C.Selectors can be used by Services to identify which pods to route traffic to

D.Labels are immutable after creation

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

AnswersB, C, E

Set-based requirements use In, NotIn, Exists and DoesNotExist, matching a label against a list of values rather than exact equality. Equality-based selectors only compare a single key to a single value, so this statement is true.

Why this answer

Option B is correct because set-based selectors support operators such as In, NotIn, Exists, and DoesNotExist, allowing matching against a set of values rather than a single equality. Option C is correct because a Service uses its selector to match pod labels and route traffic only to the pods whose labels satisfy that selector. Option E is correct because labels are key/value pairs attached to objects specifically so users can organize and select subsets of objects, for example with kubectl get pods -l app=web.

Option A is not correct because labels are ordinary metadata and are not encrypted at rest by default; encryption at rest applies to etcd data only if configured. Option D is not correct because labels are mutable and can be added, updated, or removed after object creation.

Exam trap

CNCF often tests the misconception that labels are immutable like certain other Kubernetes fields, but labels are explicitly designed to be mutable for dynamic resource management.

Full explanation →

737

MCQmedium

You need to run a batch job that processes data every hour and exits upon completion. Which Kubernetes resource should you use?

A.Deployment

B.Job

C.DaemonSet

D.CronJob

AnswerD

A CronJob creates Jobs on a repeating schedule, so it runs the batch workload hourly and each Job's pod exits once processing completes. It satisfies both constraints: the hourly recurrence and the requirement that the process terminate rather than run continuously like a Deployment.

Why this answer

The correct choice is CronJob. While a Job is designed to run a finite task to completion, the requirement to run 'every hour' indicates a recurring schedule. A CronJob creates Jobs on a specified schedule, so it is the appropriate resource to use.

The Job itself will run and exit, but the CronJob manages the schedule.

Exam trap

A common pitfall is focusing on the phrase 'exits upon completion' and choosing Job, forgetting that the question specifies a recurring schedule (every hour). CronJob is the scheduler that creates Jobs at specified times; without it, the Job would only run once.

How to eliminate wrong answers

Option A is wrong because a Deployment is intended for long-running, stateless applications that should never exit; it continuously restarts Pods to maintain a desired replica count, which would cause the batch job to run repeatedly rather than exit upon completion. Option C 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 a batch job that runs once per hour and exits. Option D is wrong because a CronJob is used to schedule Jobs on a recurring basis (e.g., every hour), but the question specifies that the batch job 'processes data every hour and exits upon completion' — the resource that actually runs and exits is a Job, while the CronJob is the scheduler that creates the Job; the question asks for the resource that runs the workload, not the scheduler.

Full explanation →

738

Multi-Selecthard

Which THREE of the following are features typically provided by a service mesh? (Choose three.)

Select 3 answers

A.Observability through metrics and tracing

B.Auto-scaling of pods based on CPU

C.Traffic management between services

D.Security with mutual TLS (mTLS)

E.Service discovery

AnswersA, C, D

Service meshes collect per-request telemetry from sidecar proxies, exposing golden signals such as latency, error rates and request volume, plus distributed traces across service hops. This satisfies the stem's observability feature, giving uniform metrics and tracing without instrumenting each application.

Why this answer

A service mesh like Istio or Linkerd provides observability by collecting metrics and distributed traces from the sidecar proxies (e.g., Envoy) that intercept service-to-service traffic, so option A is correct. It also delivers traffic management capabilities such as routing rules, retries, timeouts, circuit breaking, and canary or blue-green deployments, making option C correct. Additionally, a service mesh secures service-to-service communication with mutual TLS (mTLS), automatically issuing and rotating certificates and enforcing encryption and identity between workloads, so option D is correct.

Option B is wrong because pod auto-scaling based on CPU is handled by the Kubernetes Horizontal Pod Autoscaler (HPA), not by a service mesh. Option E is wrong because service discovery is a core Kubernetes function (via kube-dns/CoreDNS and Services), not a feature typically attributed to the service mesh itself.

Exam trap

KCNA often tests the confusion between service mesh features and orchestration features, leading candidates to select auto-scaling or service discovery as mesh responsibilities.

Full explanation →

739

MCQhard

An administrator needs to ensure that Pods from two different Deployments cannot communicate with each other. Which Kubernetes resource should be used?

A.NetworkPolicy

B.RBAC Role

C.PodSecurityPolicy

D.ResourceQuota

AnswerA

NetworkPolicy selects Pods by label and defines ingress and egress rules, so denying traffic between the two Deployments' label sets isolates them. It operates at layer 3/4 within the cluster, which RBAC or namespaces alone cannot enforce.

Why this answer

NetworkPolicy is the correct resource because it acts as a firewall for Kubernetes Pods, controlling ingress and egress traffic at the IP address and port level using layer 3/4 rules. By applying a NetworkPolicy that denies all traffic between the Pods of the two Deployments (e.g., using podSelector and ingress/egress rules with an empty `from` or `to` block), the administrator can enforce network isolation. This is the native Kubernetes mechanism for restricting Pod-to-Pod communication within a cluster.

Exam trap

The trap here is that candidates confuse NetworkPolicy with RBAC or PodSecurityPolicy, mistakenly thinking that authorization or security contexts can control network traffic, when in fact only NetworkPolicy (with a compatible CNI) provides layer 3/4 isolation.

How to eliminate wrong answers

Option B (RBAC Role) is wrong because RBAC controls authorization for Kubernetes API operations (e.g., creating Pods, reading Secrets) and does not manage network traffic between Pods. Option C (PodSecurityPolicy) is wrong because it defines security constraints on Pods (e.g., privileged containers, host namespaces) but has no effect on network communication between Pods. Option D (ResourceQuota) is wrong because it limits aggregate resource consumption (CPU, memory, storage) per namespace and cannot restrict network connectivity between Pods.

Full explanation →

740

MCQmedium

Which Kubernetes object provides a stable IP address and DNS name to access a set of pods, and can perform load balancing?

A.Service

B.Ingress

C.Deployment

D.Pod

AnswerA

A Service front-ends a dynamic pod set behind a single stable virtual IP and DNS name, and kube-proxy load-balances connections across the selected endpoints. That satisfies the requirement for stable addressing plus load balancing, which bare pods with ephemeral IPs cannot provide.

Why this answer

A Service is the correct Kubernetes object because it provides a stable virtual IP (ClusterIP) and a DNS name (via CoreDNS) that remains constant even as pods are created or destroyed. It performs layer 4 (TCP/UDP) load balancing across the set of pods selected by its label selector, using iptables or IPVS rules to distribute traffic.

Exam trap

A common misconception is that Ingress itself performs load balancing, but Ingress is only a routing rule set; the actual load balancing is done by the Service or the Ingress controller's underlying proxy.

How to eliminate wrong answers

Option B (Ingress) is wrong because Ingress is not a load balancer itself; it is an API object that manages external HTTP/HTTPS access to Services, typically relying on a controller (e.g., NGINX) to route traffic, and it does not provide a stable IP or DNS name directly to pods. Option C (Deployment) is wrong because a Deployment manages the desired state of replica sets and pod rollouts, but it does not expose a network endpoint or perform load balancing. Option D (Pod) is wrong because a Pod has a dynamic IP address that changes on restart, and it cannot provide stable DNS or load balancing across multiple pods.

Full explanation →

741

MCQmedium

A team is implementing a multi-cloud strategy to avoid vendor lock-in. Which Kubernetes feature is most helpful for abstracting the underlying cloud provider?

A.Services

B.ConfigMaps

C.Namespaces

D.Kubernetes API

AnswerD

The Kubernetes API provides a consistent declarative interface that abstracts underlying infrastructure, so workloads defined against it remain portable across clouds. This decoupling from provider-specific APIs directly satisfies the vendor lock-in avoidance goal of the multi-cloud strategy.

Why this answer

The Kubernetes API is the abstraction layer that decouples workloads from any specific cloud provider — manifests, controllers, and clients interact with the API server, not with AWS, GCP, or Azure APIs directly. This portability is what enables multi-cloud and avoids vendor lock-in. While Services, ConfigMaps, and Namespaces are API objects, the API itself is the unifying abstraction.

Exam trap

KCNA often tests whether candidates confuse a specific API object (Service, ConfigMap, Namespace) with the API itself as the abstraction layer — the trap is picking a familiar resource instead of the unifying API.

How to eliminate wrong answers

Option A is wrong because Services provide stable networking and load balancing within a cluster, but they do not abstract cloud provider differences — LoadBalancer Services actually depend on cloud-specific controllers. Option B is wrong because ConfigMaps store configuration data and do not abstract infrastructure or provider APIs. Option C is wrong because Namespaces provide logical isolation and resource scoping, not provider abstraction.

Full explanation →

742

MCQeasy

A cluster administrator needs to run a log-forwarding agent on every node, including nodes added later, without manually scheduling a Pod per node. Which workload object should be used?

A.A Deployment with a high replica count

B.A Job with parallelism set to the node count

C.A DaemonSet

D.A StatefulSet with podManagementPolicy set to Parallel

AnswerC

A DaemonSet ensures one copy of a Pod runs on each eligible node and automatically schedules a copy onto nodes added to the cluster later. That matches node-level agents such as log shippers, metrics collectors, and CNI helpers. It removes the need to hand-place Pods or maintain per-node manifests as the cluster grows or nodes are replaced.

Why this answer

Node-wide agents need exactly one instance per node with automatic coverage of newly joined nodes. A DaemonSet is purpose-built for that pattern, scheduling a Pod onto each eligible node as the cluster changes. Deployments, Jobs, and StatefulSets all lack the one-per-node guarantee, so they cannot satisfy the requirement reliably.

Exam trap

The trap here is reaching for a Deployment with many replicas, which spreads Pods unevenly and never guarantees coverage of every node.

Full explanation →

743

MCQmedium

A DevOps team wants to adopt a deployment pattern where a new version of an application is gradually rolled out to a small subset of users before full deployment. Which progressive delivery technique should they use?

A.Canary deployment

B.Rolling update

C.Blue-green deployment

D.Recreate deployment

AnswerA

Canary deployment routes a small percentage of live traffic to the new version, then progressively increases it while monitoring metrics. This satisfies the stem's requirement to expose only a subset of users before full rollout.

Why this answer

Canary deployment is the progressive delivery technique that routes a small percentage of live traffic to the new version while the majority continues to hit the stable version. This allows the team to observe real-user metrics (error rates, latency, business KPIs) on a limited blast radius before promoting the release to 100% of users. It is the canonical pattern for gradual, risk-controlled rollouts.

Exam trap

KCNA often tests the distinction between deployment strategies (rolling, recreate, blue-green) and progressive delivery techniques (canary, A/B, shadow), so candidates who pick 'rolling update' because it sounds gradual miss that canary is the only option giving user-subset exposure.

How to eliminate wrong answers

Option B is wrong because a rolling update replaces pods/instances incrementally at the infrastructure layer but does not give user-level traffic control or a subset-of-users rollout — it is a deployment strategy, not a progressive delivery technique. Option C is wrong because blue-green deployment flips 100% of traffic from the old environment to the new one in a single cutover, which is the opposite of a gradual subset rollout. Option D is wrong because recreate deployment tears down the old version entirely before starting the new one, causing downtime and offering no gradual exposure at all.

Full explanation →

744

Multi-Selecthard

Which TWO of the following are best practices for structuring log output in cloud-native applications to maximize observability?

Select 2 answers

A.Include verbose debug-level information in every log line

B.Use multi-line log entries for detailed error information

C.Output logs in structured format such as JSON

D.Include a unique request or correlation ID in each log entry

E.Avoid timestamps to reduce log size

AnswersC, D

JSON output gives each log entry discrete, machine-parseable fields rather than an opaque string, so aggregators such as Loki, Elasticsearch or Cloud Logging can index and query individual attributes. This satisfies the observability requirement by enabling filtering, correlation and alerting without brittle regex parsing.

Why this answer

Option C is correct because emitting logs as structured data such as JSON lets log processors and observability backends parse fields programmatically, enabling reliable filtering, aggregation, and indexing by attributes like severity, service, and trace context rather than relying on fragile regex over free text. Option D is correct because including a unique request or correlation ID (for example a W3C traceparent trace ID or an application-generated correlation ID) in every entry allows distributed traces and logs to be stitched together across microservices, which is essential for root-cause analysis in cloud-native systems. The remaining options are not best practices: A floods storage and cost with low-value debug noise and can obscure real signals, B breaks line-oriented log collectors and parsers that expect one event per line, and E removes timestamps that are required to order events and correlate them across services and time zones.

Exam trap

CNCF often tests the misconception that 'more detail is better' (Option A) or that 'human readability' (Option B) is the priority, when in cloud-native observability, machine-parseable, single-line structured logs are the standard for scalability and automation.

Full explanation →

745

MCQmedium

A retail company runs its e-commerce platform on Kubernetes. During a flash sale, the application experiences high latency. The team notices that the database pods are CPU-bound and the application pods are waiting on database responses. Which architectural change would best address this bottleneck?

A.Change the database service type from ClusterIP to NodePort.

B.Implement read replicas for the database and configure the application to use them for read operations.

C.Increase the number of application pod replicas.

D.Store database configuration in a ConfigMap to improve startup time.

AnswerB

Read replicas offload read queries from the primary database, distributing CPU load across additional nodes so the CPU-bound database pods are no longer saturated. Configuring the application to route reads to replicas directly reduces the wait time for application pods, addressing the bottleneck identified during the flash sale.

Why this answer

The bottleneck is caused by the database being CPU-bound, meaning it cannot process requests fast enough. Implementing read replicas offloads read queries from the primary database, reducing its CPU load and allowing it to handle write operations more efficiently. The application can be configured to route read operations to the replicas, which directly addresses the latency caused by waiting on database responses.

Exam trap

CNCF often tests the misconception that scaling application pods (Option C) is a universal fix for performance issues, but here it would amplify the database bottleneck rather than resolve it.

How to eliminate wrong answers

Option A is wrong because changing the service type from ClusterIP to NodePort exposes the database externally but does nothing to reduce its CPU load or improve query processing speed. Option C is wrong because increasing application pod replicas would only increase the number of requests hitting the already CPU-bound database, worsening the bottleneck. Option D is wrong because storing database configuration in a ConfigMap improves manageability and startup time but has no impact on runtime database CPU utilization or query latency.

Full explanation →

746

MCQmedium

An administrator wants to allow a Pod to consume a ConfigMap named app-config as environment variables, but only the keys DB_HOST and DB_PORT. The ConfigMap contains additional keys. Which Pod spec snippet correctly injects only those two keys as environment variables?

A.env: - name: DB_HOST value: app-config.DB_HOST - name: DB_PORT value: app-config.DB_PORT

B.envFrom: - configMapRef: name: app-config

C.env: - name: DB_HOST valueFrom: configMapKeyRef: name: app-config key: DB_HOST - name: DB_PORT valueFrom: configMapKeyRef: name: app-config key: DB_PORT

D.volumeMounts: - name: config mountPath: /etc/config volumes: - name: config configMap: name: app-config

AnswerC

Using valueFrom with configMapKeyRef allows selecting individual keys from a ConfigMap. Each env entry names the environment variable and references a specific key. This injects only DB_HOST and DB_PORT and ignores other keys. It is the precise way to map selected ConfigMap keys into environment variables.

Why this answer

To inject specific ConfigMap keys as environment variables, each env entry must use valueFrom.configMapKeyRef with the ConfigMap name and key. This maps only the chosen keys. envFrom injects all keys, volume mounts expose keys as files, and the value field sets literal strings. The scenario requires selective environment variable injection.

Exam trap

The trap here is confusing envFrom, which imports all keys, with valueFrom.configMapKeyRef, which selects individual keys.

Full explanation →

747

MCQeasy

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate.' What is the most likely cause?

A.All nodes have disk pressure.

B.All nodes are unreachable or have been cordoned.

C.The pod has a toleration that matches the taint.

D.The nodes do not have enough CPU or memory.

AnswerB

The taint indicates nodes are unreachable.

Why this answer

The taint `node.kubernetes.io/unreachable` is automatically added by the node controller when a node becomes unreachable (e.g., network failure, kubelet stops heartbeating). The error shows all 4 nodes have this taint and the pod has no matching toleration, meaning the scheduler cannot place the pod. This directly indicates all nodes are unreachable or have been cordoned (which also adds the `node.kubernetes.io/unschedulable` taint, but here the specific taint is `unreachable`).

Exam trap

The KCNA exam often tests the distinction between taint types — candidates confuse `unreachable` with resource-based taints like `disk-pressure` or `insufficient-memory`, or assume a toleration would solve the issue when the problem is that no toleration exists.

How to eliminate wrong answers

Option A is wrong because disk pressure is indicated by the taint `node.kubernetes.io/disk-pressure`, not `node.kubernetes.io/unreachable`. Option C is wrong because if the pod had a toleration matching the taint, it would be scheduled despite the taint, but the error explicitly states the pod didn't tolerate it. Option D is wrong because insufficient CPU or memory would show taints like `node.kubernetes.io/insufficient-cpu` or `node.kubernetes.io/insufficient-memory`, not the `unreachable` taint.

Full explanation →

748

MCQmedium

Which Kubernetes object should you use to store non-sensitive configuration data that can be consumed by Pods as environment variables or mounted files?

A.Secret

B.PersistentVolume

C.ConfigMap

D.Service

AnswerC

ConfigMaps hold non-sensitive key-value configuration decoupled from pod images, satisfying the stem's requirement for data consumable as environment variables or mounted files. Secrets are reserved for sensitive data, so ConfigMap is the correct object here.

Why this answer

ConfigMap is the correct Kubernetes object for storing non-sensitive configuration data, such as key-value pairs or configuration files. It is designed to decouple configuration artifacts from container images, allowing Pods to consume this data as environment variables, command-line arguments, or mounted files in a volume. Unlike Secrets, ConfigMaps do not provide encryption or base64 encoding by default, making them suitable only for non-sensitive information.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming both are interchangeable for configuration, but the KCNA exam tests the distinction that Secrets are for sensitive data and ConfigMaps are for non-sensitive data, and that PersistentVolume is for storage, not configuration.

How to eliminate wrong answers

Option A is wrong because Secret is specifically designed for storing sensitive data (e.g., passwords, tokens, SSH keys) and uses base64 encoding with optional encryption at rest, not for non-sensitive configuration. Option B is wrong because PersistentVolume is an abstraction for storage resources (e.g., NFS, iSCSI) that provides persistent storage volumes to Pods, not for storing configuration data as environment variables or files. Option D is wrong because Service is a networking abstraction that exposes a set of Pods as a network service (e.g., ClusterIP, NodePort), and it cannot store or provide configuration data to Pods.

Full explanation →

749

MCQmedium

A developer wants to view the logs of a specific container named 'sidecar' inside a pod named 'app-pod'. Which command should they use?

A.kubectl log app-pod --container sidecar

B.kubectl logs app-pod sidecar

C.kubectl logs -c sidecar app-pod

D.kubectl logs app-pod -c sidecar

AnswerD

The -c flag selects a specific container within a multi-container pod, so kubectl logs app-pod -c sidecar returns only the sidecar container's output. Without it, kubectl logs on a multi-container pod fails or prompts for a container name, so this syntax satisfies the requirement precisely.

Why this answer

The -c flag specifies the container name. The correct command is 'kubectl logs app-pod -c sidecar'.

Full explanation →

750

MCQhard

A pod is stuck in the 'Pending' state. Which command would you use to get more details about why the pod cannot be scheduled?

A.kubectl logs <pod-name>

B.kubectl exec -it <pod-name> -- sh

C.kubectl describe pod <pod-name>

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

AnswerC

kubectl describe pod returns the pod's events, including scheduler messages such as insufficient CPU, unschedulable taints or unbound persistent volume claims. Those events reveal why the scheduler cannot bind the pod, satisfying the stem's requirement for scheduling failure details.

Why this answer

`kubectl describe pod <pod-name>` provides detailed event logs and status information, including scheduler decisions, resource constraints, and node conditions that explain why a pod remains in 'Pending' state. The 'Pending' state typically indicates the pod has not been scheduled, and `kubectl describe` surfaces the exact reason, such as insufficient CPU/memory, persistent volume claims not bound, or node selector mismatches.

Exam trap

A common trap in Kubernetes exams is confusing `kubectl describe pod` (which shows dynamic runtime events and scheduling reasons) with `kubectl get pod -o yaml` (which shows static configuration). Candidates may think YAML output provides the same troubleshooting detail, but it lacks the scheduler decisions and event history that explain why a pod is 'Pending'.

How to eliminate wrong answers

Option A is wrong because `kubectl logs <pod-name>` retrieves container stdout/stderr logs, which are only available after the pod has started running; a pod stuck in 'Pending' has no running containers, so this command returns nothing useful. Option B is wrong because `kubectl exec -it <pod-name> -- sh` attempts to open an interactive shell inside a running container, which is impossible when the pod is not scheduled and no containers exist. Option D is wrong because `kubectl get pod <pod-name> -o yaml` outputs the pod's current YAML manifest, which may show the `status.conditions` field but does not include the detailed scheduler events and resource allocation failures that `kubectl describe` surfaces in its 'Events' section.

Full explanation →

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 676–750