833 questions total · 12pages · All types, answers revealed
In OpenTelemetry, which component is responsible for receiving, processing, and exporting telemetry data from multiple sources?
The Collector is a pipeline component for receiving, processing, and exporting data.
Why this answer
The OpenTelemetry Collector is a vendor-agnostic agent that receives, processes, and exports telemetry data.
Which two commands are valid for viewing information about pods in a namespace named 'production'?
Correct.
Why this answer
`kubectl get pods -n production` retrieves a list of all pods in the specified namespace, which is a fundamental command for viewing pod information. Option E is correct because `kubectl describe pod <pod-name> -n production` provides detailed information about a specific pod, including events and configuration, within the given namespace.
Exam trap
The trap here is that candidates confuse `kubectl logs` with `kubectl get` for viewing pod information, or they mistakenly think `kubectl get all` is a valid way to list pods, when it actually shows a broader set of resources and is not a direct pod-viewing command.
Which of the following is a resiliency pattern that limits the number of concurrent requests to a service to prevent overload?
Bulkhead pattern isolates different parts of a system into separate pools to prevent failure propagation and limit concurrency.
Why this answer
Bulkhead isolates resources into pools (e.g., thread pools) so that a failure in one pool does not cascade. Circuit breaker stops calls after failures, retry repeats failed calls, and timeout limits wait time.
In Prometheus, what is the purpose of the Alertmanager component?
Correct. Alertmanager handles alert processing and notifications.
Why this answer
Alertmanager handles alerts sent by Prometheus server, deduplicates, groups, and routes them to receivers (email, Slack, etc.), and manages silencing and inhibition.
A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?
OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.
Why this answer
The OOMKilled status indicates the container was terminated because it exceeded its memory limit. Increasing the memory limit in the pod's container resource specification directly addresses the root cause by allowing the container to use more memory before being killed. This is the most appropriate action because the pod was running successfully for days, suggesting a gradual memory growth or a recent workload change rather than a configuration error.
Exam trap
CNCF often tests the misconception that OOMKilled is a CPU issue, leading candidates to incorrectly choose CPU adjustments, or that simply restarting the pod will fix the underlying resource constraint.
How to eliminate wrong answers
Option A is wrong because increasing the CPU request does not affect memory usage; OOMKilled is a memory-related issue, not CPU. Option B is wrong because deleting and recreating the pod would only temporarily restart the container; the same memory limit would still be enforced, and the pod would likely crash again. Option D is wrong because deleting the entire namespace and redeploying all workloads is an extreme, disruptive action that does not address the specific memory limit issue and would cause unnecessary downtime.
Which three components are part of the Kubernetes control plane?
Correct.
Why this answer
The Kubernetes control plane is responsible for maintaining the desired state of the cluster. The kube-controller-manager runs controller processes that handle routine tasks such as node management, replication, and endpoint management, making it a core control plane component.
Exam trap
A common mistake is to include kube-proxy or kubelet as control plane components because they are essential to cluster operation, but they actually run on every node and are not part of the control plane.
A developer wants to run a containerized application locally for development. Which tool is most appropriate?
Ideal for local development with multi-container apps.
Why this answer
Docker Compose is the most appropriate tool for running a containerized application locally during development because it allows you to define and manage multi-container applications using a simple YAML file. It handles container lifecycle, networking, and volume mounts with a single `docker compose up` command, making it ideal for local development workflows where rapid iteration and simplicity are key.
Exam trap
The trap here is that candidates confuse container runtimes (CRI-O, containerd) or orchestration platforms (Kubernetes) with development tools, assuming any container-related technology can run apps locally, but the KCNA exam specifically tests the understanding that Docker Compose is the standard for local multi-container development.
How to eliminate wrong answers
Option A (CRI-O) is wrong because it is a lightweight container runtime designed for Kubernetes, not a tool for local development; it lacks the developer-friendly features like `docker compose up` and is typically used in production clusters. Option C (containerd) is wrong because it is a low-level container runtime that manages container lifecycle but does not provide orchestration or multi-container application definitions; it is a building block for higher-level tools like Docker or Kubernetes, not a development tool. Option D (Kubernetes) is wrong because it is a full-scale container orchestration platform intended for production deployments across clusters; running it locally (e.g., via Minikube or kind) adds unnecessary complexity and overhead compared to Docker Compose for simple development scenarios.
Which CNCF project is classified as a 'graduated' project?
Linkerd is a graduated CNCF project, having achieved graduation status in 2021.
Why this answer
Linkerd is a graduated CNCF project. K3s is in the CNCF sandbox, while Knative and Backstage are incubating projects.
An application requires stable network identities and persistent storage. Which workload type should be used?
StatefulSets provide stable identities and persistent storage.
Why this answer
StatefulSet is the correct workload type because it provides stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage (via PersistentVolumeClaims that persist across Pod rescheduling). This makes it ideal for stateful applications like databases, where each Pod requires a stable identity and dedicated storage that survives restarts.
Exam trap
The KCNA exam often tests the misconception that Deployments can handle stateful workloads by using PersistentVolumeClaims, but they fail to account for the lack of stable network identities and ordered pod management that StatefulSet provides.
How to eliminate wrong answers
Option A is wrong because Deployment is designed for stateless applications; it creates pods with random, ephemeral identities and does not guarantee stable network names or persistent storage per pod. Option B is wrong because DaemonSet ensures one pod per node, typically for node-level services like logging or monitoring, and does not provide stable identities or persistent storage for stateful workloads. Option C is wrong because Job is intended for batch processing tasks that run to completion, not for long-running stateful services requiring stable identities and persistent storage.
Which component of the Kubernetes control plane is responsible for persisting the cluster state?
etcd is the cluster's database, storing all cluster data.
Why this answer
etcd is the distributed key-value store that acts as the single source of truth for the entire Kubernetes cluster. It stores all cluster state data, including configuration, secrets, and the desired state of every object, ensuring consistency and durability. The kube-apiserver is the only component that directly interacts with etcd, enforcing a strict serialization of writes to prevent corruption.
Exam trap
The trap here is that candidates often confuse the kube-apiserver as the storage backend, but it merely validates requests and writes to etcd. The etcd cluster is the actual persistent state store.
How to eliminate wrong answers
Option A is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for persisting state. Option B is wrong because kube-controller-manager runs controller loops that reconcile the actual cluster state with the desired state stored in etcd, but it does not persist data itself. Option D is wrong because kube-apiserver is the front-end that validates and processes API requests, but it delegates the actual persistence of cluster state to etcd via gRPC calls.
Which THREE are typical characteristics of a cloud-native application?
Containers are standard.
Why this answer
Cloud-native applications are typically packaged as lightweight containers (e.g., Docker) that encapsulate the application and its dependencies, enabling fast startup, portability, and efficient resource utilization. Containers share the host OS kernel and have minimal overhead compared to virtual machines, which aligns with the cloud-native principle of agility and scalability.
Exam trap
CNCF often tests the misconception that cloud-native apps are just 'apps in the cloud' rather than specifically requiring containerization, microservices, and horizontal scaling; candidates may mistakenly associate long startup times or fragility with cloud-native, when those are anti-patterns.
You are implementing an API gateway pattern for a set of microservices. Which of the following is a typical responsibility of an API gateway?
These are common gateway responsibilities.
Why this answer
An API gateway handles cross-cutting concerns like authentication, rate limiting, routing, and aggregation. Direct database access (B) is an antipattern, managing container lifecycle (A) is Kubernetes' job, and storing application state (C) is not a gateway function.
Which of the following is a benefit of using an orchestrator like Kubernetes?
Horizontal Pod Autoscaler can automatically scale pods based on CPU or custom metrics.
Why this answer
Kubernetes, as a container orchestrator, provides built-in Horizontal Pod Autoscaling (HPA) that automatically adjusts the number of pod replicas based on observed CPU utilization (or custom metrics). This is a core benefit because it allows applications to handle varying load without manual intervention, improving resource efficiency and availability.
Exam trap
The trap here is that candidates confuse 'automatic scaling' with 'manual scaling' or assume Kubernetes guarantees zero downtime, but the exam tests the specific benefit of automated, policy-driven scaling based on metrics like CPU utilization.
How to eliminate wrong answers
Option A is wrong because Kubernetes does not provide direct access to the host kernel; containers share the host kernel via namespaces and cgroups, and direct kernel access would break isolation and security. Option B is wrong because Kubernetes cannot guarantee zero downtime for all updates; while it supports rolling updates and strategies like maxSurge and maxUnavailable to minimize disruption, factors like application bugs or resource constraints can still cause downtime. Option D is wrong because manual scaling based on traffic spikes is not a benefit of using an orchestrator; orchestrators like Kubernetes automate scaling, and manual scaling is a legacy approach that defeats the purpose of orchestration.
Which TWO of the following components are part of the Kubernetes control plane? (Select 2)
It is the API server, central to the control plane.
Why this answer
The Kubernetes control plane is responsible for maintaining the desired state of the cluster and making global decisions. The kube-apiserver is the front-end for the control plane, exposing the Kubernetes API, and etcd is the consistent and highly-available key-value store used as the backing store for all cluster data. Both are essential control plane components.
Exam trap
Candidates often confuse kubelet or kube-proxy (which run on every node) as part of the control plane because they are essential for cluster operation, but they are not control plane components.
Drag and drop the steps to perform a backup of etcd in a Kubernetes cluster into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Access the node, save snapshot, verify, store securely, and restore when necessary.
A team is designing a cloud-native system that must maintain high availability across multiple cloud regions. The application uses Kubernetes clusters in each region. Which approach best ensures that the system can tolerate a full region failure while minimizing complexity?
Simpler to implement and manage while ensuring failover.
Why this answer
A global load balancer with active-passive regional failover provides a straightforward way to route traffic to a healthy secondary region when the primary fails, without the complexity of multi-region Kubernetes control planes or synchronous replication. This approach leverages DNS-based or anycast routing to detect region failure and redirect traffic, ensuring high availability while keeping the operational overhead low.
Exam trap
CNCF often tests the misconception that active-active with synchronous replication is always the best for high availability, but the trap here is that it introduces unnecessary complexity and cost for most use cases, while active-passive with a global load balancer offers a simpler, production-proven alternative for tolerating region failures.
How to eliminate wrong answers
Option A is wrong because a single Kubernetes cluster spanning multiple regions introduces significant latency, network partitioning risks, and control plane complexity, as Kubernetes is not designed for跨区域 single clusters and would violate the recommended failure domain boundaries. Option C is wrong because active-active with synchronous data replication across regions adds substantial latency, cost, and complexity, and is typically unnecessary for most applications; it also requires careful handling of conflict resolution and network reliability. Option D is wrong because manual failover procedures are slow, error-prone, and cannot meet the high availability requirements of a cloud-native system that must tolerate a full region failure automatically.
Which FOUR of the following are CNCF graduated projects? (Choose four.)
Helm is a CNCF graduated project (graduated in 2021). It is a package manager for Kubernetes.
Why this answer
Helm graduated in 2021, Kubernetes in 2018, ArgoCD in 2022, and Prometheus in 2018. Linkerd is an incubating project. Therefore, the four correct options are A, C, D, and E.
Exam trap
Candidates may be unaware that Helm and ArgoCD have graduated, thinking only Kubernetes and Prometheus are graduated projects. Be sure to keep up with the latest CNCF graduation announcements.
Which component is responsible for running containers on a Kubernetes node?
The container runtime is the component that actually runs containers.
Why this answer
The container runtime (e.g., containerd) is the component responsible for actually running containers on a Kubernetes node. It pulls container images, manages container lifecycles, and handles low-level operations such as starting and stopping containers via the CRI (Container Runtime Interface). Without a container runtime, the kubelet cannot launch or manage any containers on the node.
Exam trap
The trap here is that candidates often confuse the kubelet with the container runtime, thinking the kubelet directly runs containers, when in fact the kubelet only orchestrates via the CRI and relies on a separate container runtime to execute them.
How to eliminate wrong answers
Option A is wrong because etcd is a distributed key-value store that holds all cluster data, not a component that runs containers on a node. Option B is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints, but it does not execute containers. Option D is wrong because the kubelet is the node agent that communicates with the container runtime via the CRI to ensure containers are running as expected, but it does not directly run containers itself.
A team is deploying a microservice application on Kubernetes. They want to ensure that during rolling updates, the new version of the service receives traffic only after the readiness probe succeeds. However, they observe that the old pods are terminated before the new pods are ready, causing a brief downtime. Which configuration change should they make to the Deployment to prevent this?
Setting maxSurge=1 and maxUnavailable=0 ensures that at least one extra pod is created before any old pod is terminated, maintaining availability and preventing downtime.
Why this answer
Setting spec.strategy.rollingUpdate.maxSurge=1 and maxUnavailable=0 ensures that during a rolling update, new pods are created before old pods are terminated. This prevents downtime by maintaining the desired number of available pods at all times. Option B is incorrect because maxSurge=0 prevents creating new pods before terminating old ones, which can cause downtime if old pods are removed before new ones are ready.
Option A is incorrect because minReadySeconds controls how long a pod must be ready before being considered available, not the order of creation/termination. Option C is incorrect because a liveness probe is for restarting unhealthy pods, not for controlling rollout behavior.
You have a Deployment that manages 3 replicas. You want to perform a rolling update with a maximum of 2 Pods unavailable during the update. Which field should you set in the Deployment spec?
maxUnavailable defines the maximum number of Pods that can be unavailable during the update.
Why this answer
The `maxUnavailable` field in `spec.strategy.rollingUpdate.maxUnavailable` specifies the maximum number of Pods that can be unavailable during a rolling update. Setting it to 2 allows up to 2 Pods to be taken down at a time, ensuring that at least 1 Pod remains available (since the Deployment has 3 replicas). This field directly controls the availability tolerance during the update process.
Exam trap
The trap here is that candidates often confuse `maxUnavailable` with `maxSurge`, mistakenly thinking that `maxSurge` controls how many Pods can be down, when in fact `maxSurge` controls how many extra Pods can be created above the desired count.
How to eliminate wrong answers
Option B is wrong because `spec.minReadySeconds` controls how long a newly created Pod must be ready before it is considered available, but it does not limit the number of Pods that can be unavailable during an update. Option C is wrong because `spec.strategy.rollingUpdate.maxSurge` controls the maximum number of Pods that can be created above the desired replica count during an update, not the number of Pods that can be unavailable. Option D is wrong because `spec.replicas` sets the desired number of Pods for the Deployment, but it does not control the availability constraints during a rolling update.
You have a Pod with a container that needs to read sensitive data such as a database password. Which Kubernetes resource should you use to store this data?
Secrets store sensitive data and can be mounted as volumes or environment variables.
Why this answer
A Secret is the correct Kubernetes resource for storing sensitive data like database passwords because it encodes the data in base64 and is designed to be consumed by Pods via environment variables or volume mounts. Unlike ConfigMaps, Secrets are intended for confidential information and can be encrypted at rest using etcd encryption providers or KMS.
Exam trap
The trap here is that candidates often confuse ConfigMaps with Secrets, thinking both are interchangeable for configuration, but Secrets are the only resource intended for sensitive data, while ConfigMaps are for non-sensitive plaintext data.
How to eliminate wrong answers
Option A is wrong because a PersistentVolume is a storage abstraction for persistent data (e.g., files, databases), not for storing sensitive configuration like passwords; it lacks built-in mechanisms for confidentiality or encoding. Option C is wrong because a ServiceAccount is an identity resource used for Pod-to-API authentication and RBAC, not for storing arbitrary secret data. Option D is wrong because a ConfigMap stores non-sensitive configuration data in plain text and is not designed for secrets; using it for passwords would expose them in clear text in etcd and logs.
Which of the following is a benefit of using container orchestration platforms like Kubernetes?
Kubernetes automatically restarts containers that fail, replaces and reschedules pods when nodes die.
Why this answer
Kubernetes includes a built-in controller (the kubelet and ReplicaSet controller) that continuously monitors the desired state of pods. If a container fails or its process crashes, the kubelet automatically restarts it based on the pod's restart policy (e.g., Always), ensuring high availability without manual intervention. This self-healing capability is a core benefit of container orchestration, reducing downtime and operational overhead.
Exam trap
CNCF often tests the misconception that container orchestration platforms like Kubernetes increase complexity and latency, but the correct answer highlights that they actually automate recovery and improve resilience, not degrade performance.
How to eliminate wrong answers
Option A is wrong because container orchestration platforms like Kubernetes typically reduce network latency through service discovery and intelligent load balancing (e.g., kube-proxy with iptables/IPVS), not increase it. Option B is wrong because Kubernetes enables automatic scaling via Horizontal Pod Autoscaler (HPA) based on CPU/memory metrics or custom metrics, eliminating the need for manual scaling. Option D is wrong because Kubernetes promotes loose coupling between microservices through declarative APIs, service abstractions (ClusterIP), and decoupled communication patterns, not tighter coupling.
In Istio, which component is responsible for enforcing traffic policies and collecting telemetry data at the pod level?
Envoy runs as a sidecar and handles data-plane tasks.
Why this answer
Envoy proxy is the correct answer because in Istio, each pod is deployed with an Envoy sidecar proxy that intercepts all inbound and outbound traffic. This proxy enforces traffic policies (e.g., routing rules, fault injection, rate limiting) and collects telemetry data (e.g., metrics, logs, traces) at the pod level, sending it to the observability backends. The sidecar model ensures policy enforcement and telemetry collection happen without modifying the application code.
Exam trap
CNCF often tests the misconception that Mixer is still the primary policy enforcement and telemetry component, but the trap here is that Mixer was deprecated and removed; candidates who haven't kept up with Istio's evolution may incorrectly select Mixer (Option A) instead of recognizing that Envoy now handles both roles via in-proxy extensions.
How to eliminate wrong answers
Option A is wrong because Mixer was a separate Istio component responsible for access control and telemetry preprocessing, but it was deprecated in Istio 1.5 and removed in later versions; telemetry and policy enforcement are now handled directly by Envoy proxies via WebAssembly extensions and the Telemetry API. Option C is wrong because Pilot is the control plane component that translates high-level traffic rules into Envoy configuration (e.g., xDS APIs) and distributes them to proxies, but it does not enforce policies or collect telemetry at the pod level. Option D is wrong because Citadel is the security component that manages certificate issuance and mTLS key rotation (using SPIFFE identities), but it does not handle traffic policy enforcement or telemetry collection.
Which TWO of the following are benefits of using a container orchestration platform like Kubernetes? (Select 2)
Orchestration restarts failed containers automatically.
Why this answer
Kubernetes includes a built-in controller loop that continuously monitors the desired state of workloads. If a container or pod fails, the ReplicaSet or StatefulSet controller automatically replaces it by rescheduling a new pod, ensuring application availability without manual intervention.
Exam trap
A common misconception is that container orchestration requires hypervisors or static infrastructure, but the correct understanding is that Kubernetes abstracts the underlying hardware and provides dynamic, self-healing, and auto-scaling capabilities without hypervisors.
What is the purpose of a readiness probe in a Kubernetes pod?
Readiness probes indicate when a container is ready to start accepting requests. If it fails, traffic is not sent to the pod.
Why this answer
A readiness probe in Kubernetes determines whether a container inside a pod is ready to start accepting traffic. If the probe fails, the pod is removed from the Service's endpoints, preventing traffic from being routed to an unready container. This is distinct from a liveness probe, which checks if the container is healthy and should be restarted.
Exam trap
The trap here is that candidates often confuse readiness probes with liveness probes, mistakenly thinking both are used for restarting containers, when in fact readiness probes only control traffic routing and do not trigger restarts.
How to eliminate wrong answers
Option A is wrong because checking if a pod has been scheduled on a node is the responsibility of the Kubernetes scheduler and is reflected in the pod's status (e.g., `PodScheduled` condition), not by a readiness probe. Option B is wrong because measuring CPU and memory usage is done via metrics servers or monitoring tools (e.g., `kubectl top`), not by probes; readiness probes only check application-level readiness via HTTP, TCP, or exec commands. Option C is wrong because determining if a container is healthy and should be restarted is the purpose of a liveness probe, not a readiness probe; readiness probes only affect traffic routing, not pod lifecycle.
Which TWO of the following are valid Kubernetes resource types that can be used to store configuration data or secrets?
Correct: Secrets are a dedicated resource for storing sensitive configuration data like passwords and tokens.
Why this answer
ConfigMaps and Secrets are the only dedicated Kubernetes resource types for storing configuration data and secrets, respectively. ConfigMaps store non-sensitive data as key-value pairs, while Secrets store sensitive data (base64-encoded). Other options like Volume, PersistentVolumeClaim, and ServiceAccount are not designed for this purpose.
Exam trap
CNCF often tests the misconception that Volumes or PersistentVolumeClaims can store configuration data or secrets, but they are storage abstractions for arbitrary data, not the dedicated key-value resources (ConfigMap and Secret) designed for configuration and secrets management.
An administrator runs 'kubectl get pods' and sees that a pod named 'app-pod' is in 'CrashLoopBackOff'. They run 'kubectl logs app-pod' and see a segmentation fault error. What is the most likely cause?
Segmentation faults are typically caused by bugs in the application code.
Why this answer
A segmentation fault (segfault) is a specific error caused by a program attempting to access memory it does not have permission to access, typically due to a bug in the application code (e.g., null pointer dereference, buffer overflow). Since the container starts but then crashes repeatedly (CrashLoopBackOff), the segfault indicates the application itself is failing, not the infrastructure or configuration. This is the most direct cause of the pod entering CrashLoopBackOff.
Exam trap
CNCF often tests the distinction between application-level errors (like segfaults) and infrastructure or configuration issues, tempting candidates to blame resource constraints or probe misconfiguration when the logs clearly point to a runtime crash.
How to eliminate wrong answers
Option A is wrong because a node out-of-memory condition would cause the pod to be evicted or fail to schedule, not produce a segmentation fault in the application logs; the kubelet would report an OOMKilled status, not a segfault. Option B is wrong because a configuration error (e.g., missing environment variable, incorrect command) would typically result in an immediate container exit with a non-zero exit code or a startup failure, not a segmentation fault which is a runtime memory access violation. Option D is wrong because a misconfigured readiness probe would cause the pod to be marked as not ready and removed from service endpoints, but the container would continue running and not crash; the logs would show probe failures, not a segfault.
Which TWO statements about GitOps are correct?
GitOps defines desired state in Git.
Why this answer
GitOps uses Git as the single source of truth and automatically reconciles cluster state with the repository.
In a microservices application, you want to prevent cascading failures by limiting the number of concurrent requests to a downstream service. Which resilience pattern should you implement?
Bulkhead pattern partitions resources to prevent a single service from exhausting all resources.
Why this answer
The bulkhead pattern isolates resources into separate pools (e.g., thread pools) to limit the impact of a failure in one service on others.
Match each Kubernetes object to its typical use case.
Drag a concept onto its matching description — or click a concept then click the description.
Ensures a copy of a pod runs on all or selected nodes
Manages stateful applications with unique network identities
Runs a finite task to completion
Runs jobs on a time-based schedule
Automatically scales pod replicas based on CPU/memory metrics
Why these pairings
Correct matches: Deployment manages stateless apps with rolling updates; StatefulSet handles stateful apps with stable identities; DaemonSet runs a pod on every node. Common confusions: mixing Deployment with DaemonSet (one per node vs. stateless management) and StatefulSet with Jobs (stateful vs. batch).
Which deployment strategy updates pods incrementally, replacing old pods with new ones while ensuring availability?
This is the default Kubernetes deployment strategy.
Why this answer
The Rolling update strategy is the correct answer because it incrementally replaces old pods with new ones while maintaining application availability. In Kubernetes, a rolling update updates pods one by one (or in small batches), ensuring that a specified number of pods remain available throughout the process. This is achieved by gradually scaling down the old ReplicaSet and scaling up the new one, controlled by parameters like `maxSurge` and `maxUnavailable` in the Deployment spec.
Exam trap
CNCF often tests the distinction between deployment strategies by confusing candidates with 'Canary deployment' because it also involves gradual traffic shifting, but the key difference is that Canary does not replace pods incrementally—it runs both versions concurrently and requires external traffic routing.
How to eliminate wrong answers
Option A is wrong because a Canary deployment routes a small percentage of traffic to a new version before a full rollout, but it does not incrementally replace pods; it runs both versions simultaneously and requires traffic management (e.g., via a service mesh or ingress). Option B is wrong because a Blue-green deployment creates a completely new environment (green) alongside the old one (blue) and switches traffic all at once, rather than updating pods incrementally. Option C is wrong because the Recreate strategy terminates all old pods before creating new ones, causing downtime and violating the availability requirement.
Which TWO of the following are valid ways to view the logs of a pod named 'my-pod'?
If the application writes logs to a file, this command can retrieve them.
Why this answer
`kubectl exec my-pod -- cat /var/log/app.log` runs the `cat` command inside the container of the pod, allowing you to read a specific log file directly from the filesystem. This is a valid method when the application writes logs to a file rather than stdout/stderr, or when you need to inspect a log file that is not captured by the standard logging driver.
Exam trap
The trap here is that candidates may confuse `kubectl describe` (which shows pod events and status) with `kubectl logs` (which shows actual application output), or assume `kubectl attach` can retrieve past logs when it only connects to the live process stream.
You have a Deployment with three replicas. You want to update the container image but ensure that only one pod is updated at a time, and the update proceeds only if the new pod becomes healthy. Which update strategy should you configure?
This configuration updates one pod at a time and waits for the new pod to become healthy before proceeding.
Why this answer
A RollingUpdate strategy with maxSurge=1 and maxUnavailable=0 ensures that exactly one new pod is created before any old pod is terminated, and the update only proceeds when the new pod passes its readiness probe (i.e., becomes healthy). This guarantees that at all times during the update, the desired number of replicas (3) are available, and only one pod is updated at a time, matching the requirement.
Exam trap
In the KCNA exam, candidates often misinterpret that maxSurge controls the number of pods updated at a time, when in reality it controls the number of extra pods allowed above the desired count, while maxUnavailable controls the number of pods that can be unavailable during the update; candidates may incorrectly choose Option A thinking maxSurge=1 means one pod at a time, but maxSurge=3 allows three new pods to be created simultaneously, violating the 'only one pod updated at a time' constraint.
How to eliminate wrong answers
Option A is wrong because maxSurge=3 allows up to 3 extra pods to be created simultaneously, which could update multiple pods at once, violating the 'only one pod updated at a time' constraint. Option C is wrong because a Canary deployment via Ingress is a traffic-splitting technique that routes a percentage of traffic to a new version, but it does not inherently control pod update ordering or ensure that only one pod is updated at a time; it is a higher-level routing strategy, not a Deployment update strategy. Option D is wrong because the Recreate strategy terminates all existing pods before creating new ones, causing downtime and violating the requirement that the update proceeds only if the new pod becomes healthy (since all pods are replaced simultaneously).
Which THREE of the following are valid ways to create a Kubernetes resource using kubectl?
Creates a deployment or pod running the specified image.
Why this answer
`kubectl run nginx --image=nginx` creates a Pod imperatively, which is a valid way to create a Kubernetes resource directly from the command line without a manifest file. This command generates a Pod named 'nginx' using the specified container image, and it is a supported method for quick testing or ad-hoc resource creation.
Exam trap
CNCF often tests the distinction between commands that create resources versus commands that interact with existing resources, so candidates may mistakenly think `kubectl exec` or `kubectl logs` can create resources because they are common kubectl commands.
Which service mesh component is typically deployed as a sidecar proxy alongside application containers?
Envoy is often deployed as a sidecar to intercept traffic.
Why this answer
Envoy proxy is the most common sidecar proxy in service meshes like Istio and Linkerd. Istiod is the control plane component, Kiali is a visualization tool, and Prometheus is a monitoring system.
An administrator wants to update the image of a Deployment named 'my-app' from 'nginx:1.19' to 'nginx:1.20' with a rolling update strategy. They want to ensure that during the update, the number of unavailable pods never exceeds 1. Which field should they set in the Deployment spec?
maxUnavailable sets the maximum number of pods that can be unavailable during a rolling update. Setting to 1 ensures at most one pod is down at a time.
Why this answer
`spec.strategy.rollingUpdate.maxUnavailable` controls the maximum number of Pods that can be unavailable during a rolling update. Setting this to 1 ensures that at most one Pod is unavailable at any time, meeting the administrator's requirement. This field is part of the Deployment's rolling update strategy and directly governs the availability guarantee during the update process.
Exam trap
The trap here is that candidates often confuse `maxSurge` with `maxUnavailable`, mistakenly thinking that controlling how many extra Pods are created (surge) also limits unavailable Pods, but `maxSurge` only caps the number of Pods above the desired count, not the number that can be unavailable.
How to eliminate wrong answers
Option A is wrong because `spec.replicas` defines the desired number of Pod replicas, not the availability constraints during an update. Option B is wrong because `spec.minReadySeconds` controls how long a newly created Pod must be ready before it is considered available, but it does not limit the number of unavailable Pods during a rolling update. Option C is wrong because `spec.strategy.rollingUpdate.maxSurge` controls the maximum number of Pods that can be created above the desired replica count during an update, not the number of unavailable Pods.
What is the primary purpose of a continuous integration (CI) pipeline in cloud native application delivery?
CI focuses on building and testing every change.
Why this answer
CI automates building and testing code changes to catch integration issues early, ensuring that code is always in a deployable state.
Which service mesh provides built-in support for multi-cluster and multi-cloud deployments?
Why this answer
Istio is correct because it provides native support for multi-cluster and multi-cloud deployments through its mesh federation capabilities, including features like multi-primary and primary-remote cluster models, as well as east-west gateways for cross-cluster traffic. It leverages Envoy proxies and a unified control plane to enable service discovery, traffic management, and security across clusters, making it the only option among the listed that offers built-in, production-ready multi-cluster support.
Exam trap
CNCF often tests the misconception that all service meshes have equal multi-cluster support, leading candidates to pick Linkerd for its simplicity or Consul for its multi-datacenter reputation, but Istio is the only one with built-in, comprehensive multi-cloud and multi-cluster capabilities as a core feature.
How to eliminate wrong answers
Option A is wrong because Kuma, while supporting multi-zone deployments, is built on Envoy and primarily focuses on service mesh for Kubernetes and VMs with a simpler architecture, but it lacks the mature, built-in multi-cluster and multi-cloud features that Istio provides out-of-the-box, such as native federation and cross-cluster load balancing. Option B is wrong because Consul Connect (part of HashiCorp Consul) supports multi-datacenter deployments but is not a dedicated service mesh; it relies on Consul's service discovery and intentions for security, and its multi-cluster capabilities are more about datacenter replication rather than the seamless multi-cloud service mesh integration that Istio offers. Option D is wrong because Linkerd, while lightweight and simple, does not have built-in multi-cluster support; it requires additional tools or manual configuration for cross-cluster communication, and its focus is on single-cluster performance and simplicity, not multi-cloud deployments.
A Deployment is configured with 'replicas: 5' and a rolling update strategy. During an update, you notice that the number of available pods drops to 3 momentarily. Which field in the Deployment spec can be adjusted to control the minimum number of pods available during a rolling update?
maxUnavailable controls how many pods can be unavailable during the update.
Why this answer
`spec.strategy.rollingUpdate.maxUnavailable` defines the maximum number (or percentage) of Pods that can be unavailable during a rolling update. With `replicas: 5`, setting `maxUnavailable: 2` would allow at most 2 Pods to be unavailable at any time, ensuring that at least 3 Pods remain available — which matches the observed drop to 3. This field directly controls the minimum number of available Pods during the update process.
Exam trap
The exam often tests the distinction between `maxSurge` and `maxUnavailable` by describing a scenario where Pods drop below the desired count, leading candidates to mistakenly choose `maxSurge` because they confuse 'extra Pods above desired' with 'minimum Pods available'.
How to eliminate wrong answers
Option A is wrong because `maxSurge` controls the maximum number of Pods that can be created above the desired replica count during a rolling update, not the minimum number of available Pods. Option C is wrong because `minReadySeconds` defines the minimum duration a Pod must be ready before it is considered available, but it does not control the number of Pods that can be unavailable during the update. Option D is wrong because `spec.replicas` sets the desired number of Pods for the Deployment, but it does not control the availability constraints during a rolling update; it only defines the target count.
You need to deploy a batch job that processes a queue and runs to completion. The job should run exactly once and create exactly one pod per work item, but some items may fail. Which Kubernetes resource is best suited?
A Job is designed for batch processing, ensuring a specified number of pods complete successfully.
Why this answer
A Kubernetes Job is the correct resource for batch processing tasks that run to completion, such as processing a queue where each work item corresponds to a pod. By configuring the `.spec.completions` and `.spec.parallelism` fields, you can ensure exactly one pod per work item and control concurrency. The Job automatically retries failed pods (up to a configurable limit) without restarting the entire batch, making it ideal for handling some failures.
In contrast, a Deployment (A) is for long-running, continuously available services; a CronJob (C) is for scheduled recurring jobs; and a DaemonSet (D) runs a pod on every node for infrastructure tasks. Therefore, Job (B) is the best fit.
Exam trap
The KCNA exam often tests the distinction between batch and long-running workloads, and the trap here is that candidates may confuse a Job with a Deployment because both can create multiple pods, but a Deployment is designed for continuous availability, not one-time execution.
How to eliminate wrong answers
Option A is wrong because a Deployment is intended for long-running, stateless applications that maintain a desired number of replicas, not for batch jobs that run to completion; it would restart pods indefinitely, violating the 'run exactly once' requirement. Option C is wrong because a CronJob schedules Jobs on a time-based schedule, but the question specifies a one-time batch job that processes a queue and runs to completion, not a recurring task. Option D is wrong because a DaemonSet ensures exactly one pod runs on each node in the cluster, which is used for node-level services like logging or monitoring, not for processing a queue with one pod per work item.
A company wants to adopt immutable infrastructure for its containerized applications. Which practice BEST exemplifies immutability?
Immutable infrastructure treats containers as disposable; failures are handled by replacement, not repair.
Why this answer
Immutable infrastructure means that once a container is deployed from a specific image, it is never modified in place. When a container fails, the orchestrator (e.g., Kubernetes) terminates it and launches a new container from the same image, ensuring consistency and reproducibility. This approach eliminates configuration drift and aligns with the principle that all changes should be made by rebuilding the image, not by altering running instances.
Exam trap
The trap here is that candidates confuse immutability with automation, thinking that any automated update (like a config management tool) is acceptable, when in fact immutability in Kubernetes requires that no changes are made to running containers — only new images are deployed via rolling updates or similar mechanisms.
How to eliminate wrong answers
Option A is wrong because using kubectl exec to change environment variables in a running pod directly modifies the container's state, violating immutability by introducing runtime changes that are not captured in the image. Option C is wrong because a configuration management tool that runs periodically to update containers implies in-place modifications, which contradicts the immutable model where updates should come from deploying new images. Option D is wrong because logging into a running container and applying a security patch with apt-get update mutates the container's filesystem, creating a snowflake server that cannot be reliably reproduced from the original image.
Which TWO of the following are responsibilities of the kube-controller-manager?
Why this answer
The kube-controller-manager runs controllers that handle routine tasks. The Node controller watches the health of nodes. The Endpoint controller (now EndpointSlice controller) manages endpoints for Services.
Assigning pods to nodes is done by the scheduler. Storing cluster state is done by etcd. Serving the Kubernetes API is done by kube-apiserver.
Which Kubernetes object can be used to store sensitive data, such as passwords or API keys, and inject them into pods?
Secrets store sensitive data base64 encoded.
Why this answer
A Secret is the dedicated Kubernetes object for storing sensitive data like passwords, API keys, and tokens. Secrets store data as base64-encoded strings and can be injected into pods as environment variables or mounted as volumes, with optional encryption at rest via etcd or KMS.
Exam trap
The trap is that candidates might think ConfigMap is appropriate for secrets because it also injects data into pods, but ConfigMap stores data in plaintext (base64 is encoding, not encryption) and is intended for non-sensitive configuration. Additionally, Secrets are not encrypted by default unless etcd encryption or KMS is configured, so they are not inherently secure.
How to eliminate wrong answers
Option A is wrong because a PersistentVolume is a storage abstraction for persistent data (e.g., NFS, iSCSI) and is not designed for injecting sensitive configuration into pods. Option B is wrong because a ServiceAccount provides an identity for pod-to-API-server authentication, not for storing or injecting secrets. Option D is wrong because a ConfigMap stores non-sensitive configuration data in plaintext (base64-encoded but not encrypted) and should not be used for passwords or API keys.
A Deployment is configured with 'replicas: 3'. After a node failure, only 2 pods are running. What component ensures that a new pod is scheduled to restore the desired replica count?
The controller manager includes the ReplicaSet controller that ensures the desired number of pods.
Why this answer
The kube-controller-manager runs the ReplicaSet controller, which detects the mismatch and creates a new pod.
A user reports that they cannot connect to a database service named 'db-service' from another pod in the same namespace. The service selector matches the database pod's labels. Which command would you run FIRST to troubleshoot the service's endpoints?
Endpoints show the IP addresses of pods selected by the service. If empty, the selector is mismatched.
Why this answer
`kubectl get endpoints db-service` directly shows whether the service has any endpoints (i.e., pod IPs) associated with it. If the endpoints list is empty, it indicates that the service's label selector is not matching any pods, which is the most common cause of connectivity failure. This is the fastest way to verify the fundamental prerequisite for service-to-pod traffic.
Exam trap
The trap here is that candidates often jump to connectivity tests (like curl) or pod logs, forgetting that the service must first have endpoints; the exam tests whether you know to verify the selector-to-pod match at the endpoint level before assuming network issues.
How to eliminate wrong answers
Option A is wrong because `kubectl describe pod db-service` would fail since 'db-service' is a service name, not a pod name; even if you used the correct pod name, describing a pod does not reveal the service's endpoint status. Option C is wrong because `kubectl exec -it <some-pod> -- curl db-service` tests connectivity from within the cluster, but it assumes the service already has endpoints; running this first could waste time if the issue is that no endpoints exist. Option D is wrong because `kubectl logs db-service` is invalid (logs require a pod name, not a service name) and even if applied to a pod, logs would not show the service's endpoint state.
Refer to the exhibit. A pod is created with the above manifest. The container runs nginx listening on port 80, but the liveness probe is configured to check port 8080. What will happen?
Correct; liveness probe failure leads to restart.
Why this answer
The liveness probe is configured to check port 8080, but the container only listens on port 80. Since the probe will never receive a successful HTTP response from port 8080, it will fail repeatedly. According to Kubernetes behavior, after the failure threshold is reached (default: 3 failures with a 10-second interval), kubelet will restart the container to attempt to recover it.
This is the intended mechanism for detecting and remediating deadlocked or unresponsive applications.
Exam trap
The KCNA exam often tests the distinction between probe failure and pod startup failure—candidates mistakenly think a misconfigured probe prevents the pod from starting, but Kubernetes always starts the container first and then evaluates probes asynchronously.
How to eliminate wrong answers
Option A is wrong because a probe port mismatch does not prevent the pod from starting; the pod will start and the container will run, but the liveness probe will fail. Option B is wrong because the liveness probe failure does not affect the Ready condition directly—readiness is determined by the readiness probe, not the liveness probe—but the container will be restarted, so the pod will not remain in a stable Ready state. Option D is wrong because the liveness probe is explicitly defined in the manifest and is therefore required; Kubernetes will execute it regardless of whether the container port matches.
A pod is running a Java application that occasionally leaks memory. After a few hours, 'kubectl describe pod' shows the container exited with OOMKilled. You want to automatically restart the container but ensure the application has enough memory. What should you do?
Increasing memory limit prevents OOM, and a liveness probe can restart the pod before OOM.
Why this answer
Increasing the memory limit in resources.limits provides the Java application with more memory headroom, reducing the likelihood of OOMKilled terminations. Adding a liveness probe that triggers on high memory usage ensures the pod is restarted proactively if memory consumption approaches the limit, maintaining availability while the underlying memory leak is addressed.
Exam trap
A common misconception is that restartPolicy alone solves OOMKilled issues, but without adjusting resource limits, the container will simply be killed again. Additionally, a liveness probe is needed for proactive health management.
How to eliminate wrong answers
Option A is wrong because restartPolicy: OnFailure restarts the container only after it exits with a non-zero exit code, but OOMKilled is an exit code 137 (SIGKILL), which does trigger OnFailure; however, this option does not address the root cause of insufficient memory, so the container will repeatedly OOMKill without solving the memory issue. Option B is wrong because a DaemonSet ensures one pod per node and is used for node-level services (e.g., logging, monitoring), not for managing stateless applications like a Java app that needs automatic restarts and resource adjustments; it does not help with memory limits or OOMKilled scenarios. Option D is wrong because terminationGracePeriodSeconds controls the grace period for graceful shutdown (default 30 seconds), and setting it to 0 forces immediate termination, which does not prevent OOMKilled or provide more memory; it only affects shutdown behavior, not resource allocation.
Which of the following is a core component of the three pillars of observability?
Logs are one of the three pillars of observability.
Why this answer
The three pillars of observability are logs, metrics, and traces. Alerting is derived from metrics, not a pillar itself.
Which component is the primary entry point for all administrative tasks and API requests in a Kubernetes control plane?
It is the API gateway for all administrative tasks.
Why this answer
The kube-apiserver is the front-end of the Kubernetes control plane and the only component that directly interacts with etcd. All administrative tasks (via kubectl), API requests from pods, and internal control plane components (scheduler, controller-manager) must pass through the kube-apiserver, which validates and processes them before persisting state or triggering actions.
Exam trap
A common misconception is that etcd is the primary entry point because it stores all cluster data, but the trap is that etcd is a backend storage layer with no direct API exposure to users or external components. The kube-apiserver is the only component that exposes the Kubernetes API and handles all administrative requests.
How to eliminate wrong answers
Option B (etcd) is wrong because etcd is a distributed key-value store used for persistent cluster state, not an entry point for API requests; it is accessed only by the kube-apiserver. Option C (kube-scheduler) is wrong because it only handles pod-to-node assignment decisions and does not expose an API endpoint for administrative tasks. Option D (kube-controller-manager) is wrong because it runs controller loops to maintain desired state but does not serve as an API gateway; it receives its instructions from the kube-apiserver.
You create a Deployment with 'replicas: 3' and update the pod template to use a new image. After the rollout, you notice that the new ReplicaSet has 3 pods but they are all failing with 'CrashLoopBackOff'. You want to rollback to the previous working revision. Which command should you run?
This command rolls back the Deployment to the previous revision.
Why this answer
`kubectl rollout undo deployment/my-deployment` reverts the Deployment to the previous revision, which is the standard Kubernetes method to roll back a failed rollout. This command restores the pod template from the last working ReplicaSet, effectively undoing the change that caused the CrashLoopBackOff.
Exam trap
The trap here is that candidates confuse `kubectl rollout undo` with `kubectl set image` or `kubectl rollout pause`, thinking that manually setting the old image or pausing the rollout will revert the changes, but only `undo` actually triggers a rollback to a previous revision in the Deployment's history.
How to eliminate wrong answers
Option A is wrong because `kubectl set image deployment/my-deployment nginx=nginx:1.21` manually updates the image again, which does not roll back to a previous revision and may repeat the same failure if the new image is also broken. Option B is wrong because `kubectl delete deployment/my-deployment --cascade=false` deletes the Deployment but leaves its pods orphaned, which does not restore the previous working state and can cause resource leaks. Option D is wrong because `kubectl rollout pause deployment/my-deployment` only pauses the rollout, preventing further changes but not reverting to a previous working revision; the failing pods remain in CrashLoopBackOff.
You have a Deployment with image: myapp:v1. You update the image to myapp:v2 using 'kubectl set image deployment/myapp myapp=myapp:v2'. The rollout status shows 'Waiting for rollout to finish: 0 out of 3 new replicas have been updated...'. What is the most likely cause of this behavior?
If the image cannot be pulled, the new Pods will remain in ImagePullBackOff, preventing them from being counted as updated.
Why this answer
The rollout is stuck waiting for new replicas to become ready, which typically happens when the container image cannot be pulled. The message '0 out of 3 new replicas have been updated' indicates that the ReplicaSet is attempting to create Pods with the new image, but the Pods are failing to start. The most common cause is that the image tag 'myapp:v2' does not exist in the registry or cannot be accessed due to authentication or network issues, preventing the kubelet from pulling it.
Exam trap
The trap here is that candidates often assume a syntax error (Option A) or a Pod crash (Option B) when the real issue is a missing or inaccessible image, which is a common cause of stuck rollouts in Kubernetes.
How to eliminate wrong answers
Option A is wrong because the command syntax 'kubectl set image deployment/myapp myapp=myapp:v2' is correct; the format is 'container-name=image:tag', not 'deployment-name image:tag'. Option B is wrong because a missing command would cause a CrashLoopBackOff, not a stuck rollout with zero new replicas updated; the rollout would still show progress but with restart counts. Option C is wrong because the 'Recreate' strategy kills all old Pods before creating new ones, which would show 'Waiting for rollout to finish: 0 out of 3 new replicas have been updated...' only if the new Pods fail to start, but the message itself is typical of a RollingUpdate strategy that is stuck; 'Recreate' would not show this specific message because it does not update replicas incrementally.
Which three of the following are valid methods to expose a Service to external traffic? (Select THREE)
Ingress provides HTTP/HTTPS routing to Services.
Why this answer
Ingress is correct because it provides HTTP/HTTPS routing rules to expose services externally, typically using a reverse proxy like NGINX or HAProxy. It operates at Layer 7 and can route traffic based on hostnames or paths to different services within the cluster, making it a valid method for external exposure.
Exam trap
A common misconception is that ClusterIP can be used for external access because it has an IP address, but it is strictly internal unless combined with a proxy or port-forwarding mechanism.
You have a Deployment named 'frontend' with 3 replicas. You want to perform a rolling update to a new container image. Which command should you use?
This command updates the image for container1 in the frontend deployment.
Why this answer
The `kubectl set image` command is the correct way to perform a rolling update on a Deployment. It directly updates the container image in the pod template, triggering a rolling update where the ReplicaSet gradually replaces old pods with new ones, ensuring zero downtime. Option A specifies the exact container name and new image, which matches the required syntax for a targeted update.
Exam trap
The trap here is that candidates confuse imperative commands like `kubectl set image` with declarative commands like `kubectl replace` or non-existent commands like `kubectl update`, leading them to pick options that either require a full manifest or are syntactically invalid.
How to eliminate wrong answers
Option B is wrong because `kubectl replace` is used to replace a resource from a file or stdin, not to update an image directly; it would require a full YAML/JSON definition and does not trigger a rolling update by default. Option C is wrong because `kubectl edit` opens an editor for manual changes and does not accept an `--image` flag; it is interactive and not a single command for a rolling update. Option D is wrong because `kubectl update` is not a valid kubectl command; the correct imperative command for updating an image is `kubectl set image`.
Counters are cumulative and only increase, perfect for counting total requests.
Why this answer
A counter is a cumulative metric that only increases, ideal for counting requests.
A Deployment named 'myapp' is managing a ReplicaSet. You need to update the application image to version 2.0. What is the recommended approach?
Updating the Deployment triggers a rolling update, ensuring zero-downtime and rollback capability.
Why this answer
The recommended approach to update a Deployment's application image is to modify the pod template in the Deployment specification. The Deployment controller then automatically performs a rolling update, creating a new ReplicaSet with the updated image and gradually scaling down the old ReplicaSet, ensuring zero-downtime updates and maintaining desired replica count.
Exam trap
CNCF often tests the misconception that you must directly manipulate ReplicaSets or pods to update an application, when in fact the Deployment abstraction is designed to handle all updates through its pod template, and any direct changes to underlying resources are either reverted or break the declarative model.
How to eliminate wrong answers
Option A is wrong because scaling down to 0 replicas and then scaling up with a new image causes an unnecessary service disruption and does not leverage the Deployment's built-in rolling update mechanism, which is designed for seamless updates. Option C is wrong because manually deleting the existing ReplicaSet and creating a new one bypasses the Deployment controller's management, losing revision history and the ability to roll back; the Deployment should manage ReplicaSets automatically. Option D is wrong because directly editing pods in a ReplicaSet is ineffective, as the ReplicaSet controller will immediately revert any changes to match its pod template, and this approach does not update the Deployment's desired state.
A team wants to use feature flags to control the rollout of a new feature in a Kubernetes-deployed microservice. Which tool is specifically designed for managing feature flags in cloud-native applications?
Why this answer
LaunchDarkly is a feature management platform specifically designed for managing feature flags in cloud-native applications. It allows for controlled rollouts and A/B testing. Argo Rollouts focuses on progressive delivery (canary, blue-green deployments), not feature flags.
Helm is a package manager for Kubernetes. Kustomize is for configuration management. Therefore, option B (LaunchDarkly) is correct.
What is the primary benefit of using an API gateway in a microservices architecture?
The gateway abstracts the backend services and provides centralized management.
Why this answer
An API gateway acts as a single entry point for clients, providing request routing, composition, and cross-cutting concerns like authentication and rate limiting.
A user reports that a ConfigMap update is not reflected in running pods. Which action should be taken to ensure pods receive the updated configuration?
Triggers new pods with updated ConfigMap values.
Why this answer
A is correct because ConfigMaps are mounted into pods as volumes or consumed via environment variables at pod creation time. Kubernetes does not automatically propagate ConfigMap updates to running pods; the only way to pick up the new configuration is to restart the pods. A rollout restart of the deployment (e.g., `kubectl rollout restart deployment`) triggers a new ReplicaSet, which creates fresh pods that read the updated ConfigMap.
Exam trap
The trap here is that candidates assume Kubernetes automatically propagates ConfigMap changes to running pods, but in reality, pods are immutable after creation and require a restart to pick up new configuration.
How to eliminate wrong answers
Option B is wrong because deleting and recreating the ConfigMap does not affect running pods; pods still reference the old data from the initial mount or environment variable injection. Option C is wrong because changing a label on the deployment does not cause pods to be recreated; labels are metadata and do not trigger a pod restart or re-read of ConfigMap data. Option D is wrong because restarting the kubelet on nodes restarts the node agent but does not force pods to re-read their ConfigMap; pods continue using the cached configuration from their initial creation.
Your organization runs a microservices application in a Kubernetes cluster with 5 worker nodes. Each microservice is deployed as a Deployment with 3 replicas. Recently, users report intermittent timeouts when accessing the frontend service. The frontend communicates with a backend service via ClusterIP. You check the backend pods and find that one of the three replicas is in CrashLoopBackOff. The other two backend pods are healthy. The frontend deployment has no readiness or liveness probes. You notice that the frontend's connection pool to the backend has a timeout of 5 seconds. The crashing backend pod logs show an occasional NullPointerException that causes the container to restart, but the pod becomes ready after restart within 2 seconds. However, the frontend's connection pool does not evict unhealthy connections quickly. What is the best course of action to reduce timeouts?
Readiness probe will remove the pod from the Service endpoints when it is not ready.
Why this answer
The intermittent timeouts occur because the frontend's connection pool holds stale connections to the backend pod that is in CrashLoopBackOff. Although the pod restarts and becomes ready within 2 seconds, the frontend does not detect that the old connection is broken and continues to use it until the 5-second timeout expires. Adding a readiness probe to the backend Deployment ensures that Kubernetes only sends traffic to pods that pass the health check; when the pod fails the probe, it is removed from the ClusterIP's endpoints, preventing the frontend from routing requests to it and thus eliminating the timeouts.
Exam trap
The trap here is that candidates often confuse readiness and liveness probes, thinking a liveness probe is needed to restart the failing backend pod, but the real issue is traffic routing and connection pool management, which a readiness probe solves by removing the unhealthy pod from the service endpoints.
How to eliminate wrong answers
Option A is wrong because simply increasing the number of replicas does not address the root cause—stale connections to a failing pod—and may only mask the problem while wasting resources. Option C is wrong because adding a liveness probe to the frontend Deployment would restart the frontend pod if it becomes unhealthy, but the frontend itself is not crashing; the issue is connection management to the backend. Option D is wrong because increasing the connection pool timeout to 10 seconds would only make the timeouts longer, not prevent them; the frontend would still wait up to 10 seconds on a broken connection instead of quickly failing over.
A team uses Helm to manage their Kubernetes applications. They need to upgrade a release and want to reuse the values from the previous release while overriding a specific value. Which helm command should they use?
--reuse-values retains the previous release's values and merges the new --set overrides.
Why this answer
The --reuse-values flag tells Helm to reuse the last release's values and merge any provided overrides. This is the correct approach to preserve existing values while updating a specific one.
Which THREE of the following are benefits of using a service mesh for observability? (Select three.)
Service mesh can propagate trace context and generate spans for each hop.
Why this answer
A service mesh provides visibility into inter-service communication, adds distributed tracing without code changes, and collects metrics like request latency.
A company wants to adopt a GitOps workflow for managing their Kubernetes clusters. Which two tools are specifically designed for implementing GitOps on Kubernetes?
Flux is a CNCF incubating project for GitOps.
Why this answer
ArgoCD and Flux are both CNCF projects that implement GitOps principles, synchronizing cluster state with a Git repository. Helm is a package manager, Terraform is for infrastructure provisioning (not strictly GitOps for Kubernetes), and Jenkins is a CI/CD tool that can be used with GitOps but is not purpose-built for it.
A DevOps team notices that a microservice is returning 503 errors intermittently. The service runs in Kubernetes and uses a liveness probe. The team wants to understand the root cause without restarting the pod. Which observability approach should they use first?
Metrics like 'probe_success' from kubelet can show probe status over time, helping identify intermittent failures.
Why this answer
Prometheus can scrape kubelet metrics that expose liveness probe success and failure counts directly, allowing the team to see if the probe is failing without restarting the pod. This approach provides historical data on probe behavior, which is essential for diagnosing intermittent 503 errors that stem from the kubelet restarting the container when the liveness probe fails. Unlike other options, it does not require modifying the application or restarting the pod, and it directly surfaces the root cause if the probe is the issue.
Exam trap
The trap here is that candidates often assume 'kubectl describe pod' (Option A) is sufficient for debugging, but they overlook that its event log is short-lived and may not retain evidence of intermittent failures, whereas Prometheus metrics provide persistent historical data.
How to eliminate wrong answers
Option A is wrong because 'kubectl describe pod' shows recent events, but these events are ephemeral and may not capture intermittent failures that occurred minutes or hours ago, especially if the pod has not been restarted recently. Option C is wrong because increasing log verbosity requires modifying the application deployment and restarting the pod, which the team explicitly wants to avoid, and it does not directly reveal liveness probe failures (which are handled by the kubelet, not the application). Option D is wrong because distributed tracing across the service mesh focuses on request-level latency and errors between services, not on the kubelet's health check mechanism; it would not show liveness probe failures unless the probe itself is instrumented as a span, which is not standard.
A Kubernetes cluster runs a critical application that must be updated with zero downtime. The team wants to gradually shift traffic from the old version to the new version over a period of time. Which deployment pattern is MOST appropriate?
Canary deployment gradually shifts a percentage of traffic to the new version, allowing monitoring and controlled rollout.
Why this answer
Canary deployment involves rolling out the new version to a small subset of users initially and gradually increasing traffic while monitoring for issues. This minimizes risk and provides control over the rollout.
Which component of the Kubernetes control plane is responsible for storing the cluster state?
etcd is the key-value store that persists the entire cluster configuration and state.
Why this answer
etcd is the distributed key-value store that serves as Kubernetes' single source of truth for cluster state, including all object definitions, configurations, and statuses. The control plane components (kube-apiserver, scheduler, controller-manager) are stateless and rely on etcd to persist and retrieve cluster data. Without etcd, the cluster cannot recover its state after a restart.
Exam trap
A common misconception is that kube-apiserver stores the cluster state because it is the central API endpoint, but in reality it is a stateless gateway that delegates persistence to etcd.
How to eliminate wrong answers
Option A is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for storing cluster state. Option C is wrong because kube-apiserver is the front-end for the control plane that validates and processes API requests, but it does not persist data itself—it reads from and writes to etcd. Option D is wrong because kube-controller-manager runs controller loops that reconcile desired state with actual state, but it relies on etcd for state storage and does not store state itself.
Which of the following is NOT one of the three pillars of observability?
Alerts are not a pillar; they are typically generated from metrics or logs.
Why this answer
The three pillars are logs, metrics, and traces. Alerts are derived from these pillars but not considered a pillar themselves.
In a multi-cloud scenario, an organization wants to avoid vendor lock-in by abstracting infrastructure provisioning. Which tool is specifically designed to manage infrastructure as code across multiple cloud providers?
Terraform is a multi-cloud infrastructure-as-code tool that provisions resources across providers.
Why this answer
Terraform is an infrastructure-as-code tool that supports multiple cloud providers (AWS, Azure, GCP, etc.) with a declarative configuration language. Pulumi also supports multiple clouds but is less widely adopted in the CNCF ecosystem.
Which of the following is a benefit of container orchestration?
Orchestration restarts failed containers automatically.
Why this answer
Container orchestration platforms like Kubernetes provide self-healing capabilities by automatically restarting failed containers, rescheduling them on healthy nodes, and replacing or terminating containers that fail health checks. This ensures high availability and reduces manual intervention, which is a core benefit of orchestration.
Exam trap
CNCF often tests the misconception that container orchestration is only about initial deployment, when in fact its key value is ongoing automated management like self-healing and scaling.
How to eliminate wrong answers
Option A is wrong because container orchestration does not require a hypervisor for each container; containers share the host OS kernel and run as isolated processes, unlike VMs that need a hypervisor. Option B is wrong because container orchestration enables automatic scaling (e.g., horizontal pod autoscaling in Kubernetes), not manual scaling, which would defeat the purpose of automation. Option C is wrong because container orchestration promotes dynamic infrastructure with automated deployment, scaling, and updates, not static infrastructure with no changes.
A production issue arises: a Deployment with 10 replicas is updated, but the new Pods are failing health checks and being terminated. The old Pods are also being terminated. What is the most likely cause?
For example, maxSurge=1 and maxUnavailable=1 allows the rollout to continue even if new Pods are unhealthy, potentially terminating old ones.
Why this answer
When maxSurge and maxUnavailable are set to values that allow termination of old Pods before new ones are ready, the RollingUpdate strategy can scale down old ReplicaSets even if the new Pods are failing health checks. This happens because maxUnavailable defines the maximum number of Pods that can be unavailable during the update, and if set to a value like 1 (or a percentage), the controller will terminate old Pods to meet that threshold, even if the new Pods are not yet healthy. The result is a cascading failure where both old and new Pods are terminated, leading to a service disruption.
Exam trap
A common misconception is that maxSurge and maxUnavailable only control scaling speed, not the order of Pod termination, leading candidates to overlook that aggressive values can cause old Pods to be terminated before new ones are healthy.
How to eliminate wrong answers
Option A is wrong because setting the Deployment's 'paused' field to true would prevent any rollout from proceeding, meaning no new Pods would be created and old Pods would not be terminated; the issue describes active termination of both old and new Pods, which cannot happen when paused. Option B is wrong because 'revisionHistoryLimit' controls how many old ReplicaSets are retained for rollback, not the behavior of Pod termination during a rolling update; it has no effect on health checks or termination of current Pods. Option D is wrong because maxSurge=0 and maxUnavailable=0 would enforce a strict rolling update where no Pods are terminated until new ones are fully ready, preventing the described scenario of old Pods being terminated before new ones pass health checks.
Which field in a Pod's container specification defines the minimum amount of CPU guaranteed to the container?
Requests specify the minimum amount of CPU reserved for the container.
Why this answer
In Kubernetes, the `resources.requests.cpu` field specifies the minimum amount of CPU guaranteed to a container. This value is used by the scheduler to ensure the node has enough allocatable CPU, and by the kubelet to enforce CPU shares via the Completely Fair Scheduler (CFS) in the Linux kernel.
Exam trap
The trap here is that candidates often confuse `requests` (guaranteed minimum) with `limits` (maximum allowed), especially since both are defined under `resources` and both use the same unit (e.g., millicores).
How to eliminate wrong answers
Option A is wrong because `spec.containers.cpu` is not a valid field; CPU requests are nested under `resources.requests.cpu`. Option C is wrong because `resources.limits.cpu` defines the maximum CPU a container can burst to, not the guaranteed minimum. Option D is wrong because `spec.nodeSelector` is a scheduling constraint that selects nodes based on labels, not a container resource specification.
Which TWO of the following are capabilities of ArgoCD? (Choose two.)
ArgoCD syncs applications automatically or on demand.
Why this answer
ArgoCD provides automated sync (applying desired state from Git) and self-healing (automatically reverting configuration drift). It is not a CI tool and does not build images.
Which CNCF project is a graduated project for service discovery and configuration management?
Consul is a tool for service discovery, health checking, and configuration management, making it the correct answer.
Why this answer
None of the listed options are CNCF graduated projects for service discovery and configuration management. Consul is a HashiCorp tool, not a CNCF project. Prometheus is for monitoring, Fluentd for logging, and Envoy is a service proxy.
Which THREE of the following are components of the GitOps workflow? (Choose three.)
CI/CD ensures changes are correct before applying.
Why this answer
GitOps relies on a Git repository as single source of truth, a CI/CD pipeline to validate changes, and an operator to sync the cluster.
Which Helm command is used to upgrade a release to a newer version of a chart?
helm upgrade updates an existing release to a new chart version or configuration.
Why this answer
The 'helm upgrade' command upgrades an existing release with a new chart version or configuration.
In a Helm chart, which file is used to define default configuration values that can be overridden by users during installation?
Why this answer
values.yaml is the conventional file in Helm charts for default configuration values. Users can override these values during installation using --set or by providing a custom values file. Option A (templates/) contains Kubernetes manifest templates.
Option B (charts/) holds subchart dependencies. Option D (Chart.yaml) includes chart metadata like name and version. Therefore, the correct answer is C.
Practice KCNA by domain
Target a specific domain to shore up weak areas.