Courseiva

CCNA Kubernetes Fundamentals Questions

75 of 326 questions · Page 1/5 · Kubernetes Fundamentals · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

You have a ConfigMap named 'app-config' with key 'database.url'. Which environment variable reference in a Pod spec injects this value correctly?

A.env: - name: DATABASE_URL valueFrom: configMapKeyRef: name: app-config key: database.url
B.env: - name: DATABASE_URL value: "$(APP_CONFIG_DATABASE_URL)"
C.env: - name: DATABASE_URL valueFrom: secretKeyRef: name: app-config key: database.url
D.env: - name: DATABASE_URL valueFrom: configMapRef: name: app-config key: database.url
AnswerA

This correctly references the key 'database.url' from ConfigMap 'app-config'.

Why this answer

It uses the `configMapKeyRef` field under `valueFrom` to reference a specific key (`database.url`) from the ConfigMap named `app-config`. This is the standard Kubernetes syntax for injecting a single key from a ConfigMap as an environment variable into a Pod.

Exam trap

The trap here is that candidates may confuse `configMapKeyRef` with `configMapRef` (which is used with `envFrom`, not `valueFrom`) or mistakenly use `secretKeyRef` for ConfigMaps, thinking the syntax is interchangeable.

How to eliminate wrong answers

Option B is wrong because `$(APP_CONFIG_DATABASE_URL)` is not a valid Kubernetes syntax for referencing ConfigMap values; it resembles a shell variable substitution, not a Kubernetes environment variable reference. Option C is wrong because it uses `secretKeyRef`, which is for referencing Secrets, not ConfigMaps; ConfigMaps must use `configMapKeyRef`. Option D is wrong because `configMapRef` is not a valid field under `valueFrom`; the correct field is `configMapKeyRef`.

Practice this question →
2
MCQeasy

Which component runs on every node and is responsible for ensuring that containers are running as specified in Pod manifests?

A.kubelet
B.kube-proxy
C.container runtime
D.kube-controller-manager
AnswerA

kubelet is the agent that runs on each node and manages Pods and their containers.

Why this answer

The kubelet is the primary node agent that runs on every node in a Kubernetes cluster. It is responsible for ensuring that containers described in Pod manifests (typically provided via the API server) are running and healthy. The kubelet does not manage containers directly; instead, it interacts with the container runtime (e.g., containerd, CRI-O) to create, start, and stop containers as specified.

Exam trap

The trap here is that candidates confuse the container runtime (which actually runs containers) with the kubelet (which ensures the desired state from Pod manifests), leading them to pick 'container runtime' instead of 'kubelet'.

How to eliminate wrong answers

Option B is wrong because kube-proxy is a network proxy that runs on each node, handling network rules and forwarding traffic for Services, not managing container lifecycle. Option C is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it is not responsible for reconciling Pod manifests or ensuring desired state — that is the kubelet's job. Option D is wrong because kube-controller-manager runs as a control plane component (not on every node) and manages controllers like ReplicaSet and Node Controller, but does not directly interact with containers on individual nodes.

Practice this question →
3
Multi-Selecthard

A pod is stuck in Pending state. Which THREE of the following are possible causes?

Select 3 answers
A.The pod specifies a nodeSelector that does not match any node
B.The container image does not exist
C.No node has enough CPU or memory to satisfy the pod's resource requests
D.The pod has a liveness probe that is failing
E.A PersistentVolumeClaim used by the pod is not bound
AnswersA, C, E

If no nodes have the required labels, the pod cannot be scheduled.

Why this answer

A pod enters a Pending state when it cannot be scheduled onto a node. A `nodeSelector` constraint requires the node to have specific labels; if no node matches, the scheduler cannot place the pod, leaving it Pending. This is a common scheduling failure cause.

Exam trap

CNCF often tests the distinction between scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly attribute image or probe issues to the Pending state.

Practice this question →
4
MCQmedium

You need to expose a set of pods running in the 'dev' namespace internally within the cluster on a stable IP. All pods have the label 'app: web'. Which kubectl command should you use?

A.kubectl expose deployment web --port=80 --target-port=8080 --name=web-service -n dev
B.kubectl create service clusterip web --tcp=80:8080 -n dev
C.kubectl run web --image=nginx --port=80 -n dev
D.kubectl expose pod web --port=80 --target-port=8080 --name=web-service -n dev
AnswerA

If the pods are managed by a Deployment named 'web', this creates a Service that targets the pods.

Why this answer

It exposes the existing deployment named 'web' (which manages pods with label 'app: web') as a ClusterIP service, providing a stable internal IP and DNS name within the cluster. The `--port=80` sets the service port, and `--target-port=8080` maps to the container port, ensuring traffic reaches the pods correctly in the 'dev' namespace.

Exam trap

CNCF often tests the distinction between exposing a deployment (which uses a label selector for all pods) versus exposing a specific pod (which targets only that pod by name), leading candidates to choose Option D incorrectly.

How to eliminate wrong answers

Option B is wrong because `kubectl create service clusterip` requires a selector to match the pods, but the command does not specify `--clusterip` or a selector; it creates a service with no endpoints, leaving it non-functional. Option C is wrong because `kubectl run` creates a deployment or pod, not a service; it does not expose anything on a stable IP. Option D is wrong because `kubectl expose pod` targets a specific pod by name, not a set of pods with a label selector; it would expose only that single pod, not the entire set, and the pod name 'web' likely does not exist.

Practice this question →
5
MCQmedium

You need to run a stateless web application with three replicas, and you want to ensure that if a pod fails, it is automatically replaced. Which Kubernetes resource should you use?

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

Deployment creates a ReplicaSet to maintain the desired number of pod replicas and supports rolling updates.

Why this answer

A Deployment is the correct resource because it manages a ReplicaSet to ensure the desired number of pod replicas (three) are running at all times. If a pod fails, the Deployment's controller automatically creates a replacement pod, maintaining the stateless application's availability.

Exam trap

The trap here is that candidates confuse StatefulSet with Deployment for stateless apps because both manage replicas, but StatefulSet introduces ordered pod creation and persistent identities that are unnecessary and can cause overhead for stateless workloads.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that exactly one pod runs on each node, not a specified number of replicas, and is used for node-level services like logging or monitoring. Option B is wrong because a Job runs a finite task to completion and does not maintain a continuous set of running replicas. Option C is wrong because a StatefulSet is designed for stateful applications requiring stable network identities and persistent storage, which is unnecessary for a stateless web application.

Practice this question →
6
MCQmedium

Which kubectl command would you use to view the logs of a specific container named 'app' in a multi-container Pod named 'web-pod'?

A.kubectl log web-pod container app
B.kubectl logs web-pod app
C.kubectl logs web-pod -c app
D.kubectl logs app web-pod
AnswerC

The -c flag specifies the container name in a multi-container Pod.

Why this answer

The `kubectl logs` command uses the `-c` flag to specify a container name within a multi-container Pod. The correct syntax is `kubectl logs <pod-name> -c <container-name>`, which targets the 'app' container inside 'web-pod'.

Exam trap

The trap here is that candidates often forget the `-c` flag and assume `kubectl logs web-pod app` works by positional arguments, but Kubernetes requires the explicit `-c` flag for multi-container Pods.

How to eliminate wrong answers

Option A is wrong because `kubectl log` is not a valid command; the correct verb is `logs`. Option B is wrong because it omits the `-c` flag, which is required to specify a container in a multi-container Pod; without it, `kubectl logs` defaults to the first container or fails if multiple containers exist. Option D is wrong because the argument order is reversed; the pod name must come first, followed by the `-c` flag and container name.

Practice this question →
7
MCQeasy

What is the role of the kubelet on a worker node?

A.It ensures containers are running in a Pod as specified
B.It stores cluster state
C.It manages network rules for Services
D.It runs the container runtime
AnswerA

kubelet receives Pod specifications and works with the container runtime to maintain them.

Why this answer

The kubelet is the primary node agent that runs on every worker node. Its core responsibility is to ensure that containers described in Pod specs (received from the API server via the kube-apiserver) are running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers, and it reports the Pod and node status back to the control plane.

Exam trap

The trap here is confusing the kubelet's role with that of the container runtime (option D), as many candidates assume the kubelet directly runs containers, but it only orchestrates them via the Container Runtime Interface (CRI).

How to eliminate wrong answers

Option B is wrong because storing cluster state is the job of etcd, a distributed key-value store that runs on the control plane, not the kubelet. Option C is wrong because managing network rules for Services is handled by the kube-proxy component (which implements iptables or IPVS rules), not the kubelet. Option D is wrong because the kubelet does not run the container runtime; it communicates with the container runtime via the Container Runtime Interface (CRI) to manage containers, but the runtime itself (e.g., containerd) is a separate process.

Practice this question →
8
MCQeasy

What is the primary purpose of Kubernetes?

A.To provide a graphical interface for managing containers
B.To replace virtual machines with containers
C.To compile container images from source code
D.To orchestrate containers across a cluster of machines
AnswerD

This is the core purpose of Kubernetes.

Why this answer

Kubernetes is a container orchestration platform designed to automate the deployment, scaling, and management of containerized applications across a cluster of machines. Its primary purpose is to ensure that containers run reliably and efficiently by handling scheduling, load balancing, self-healing, and rolling updates, which is why option D is correct.

Exam trap

The trap here is confusing orchestration with lower-level container management tasks like image building or replacing VMs. Candidates often mistakenly think Kubernetes is a container runtime or build tool.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not provide a graphical interface natively; while tools like the Kubernetes Dashboard exist, they are optional add-ons, not the primary purpose. Option B is wrong because Kubernetes does not replace virtual machines with containers; it orchestrates containers that often run on top of VMs or bare metal, and VMs remain a separate abstraction layer. Option C is wrong because compiling container images from source code is the job of CI/CD tools (e.g., Docker build, Kaniko) or build systems, not Kubernetes itself.

Practice this question →
9
MCQmedium

Which command would you use to view the logs of a container named 'web' in a pod named 'frontend' running in the 'production' namespace?

A.kubectl logs -c web frontend --namespace production
B.kubectl logs frontend -c web -n production
C.kubectl logs frontend -n production container web
D.kubectl logs frontend web --namespace production
AnswerB

Correct syntax: kubectl logs <pod> -c <container> -n <namespace>.

Why this answer

The `kubectl logs` command requires the pod name as the first positional argument, and the `-c` flag specifies the container name when a pod has multiple containers. The `-n` flag sets the namespace. The correct syntax is `kubectl logs <pod-name> -c <container-name> -n <namespace>`, which matches option B exactly.

Exam trap

CNCF often tests the correct ordering of flags and positional arguments in `kubectl` commands, specifically that the `-c` container flag must come after the pod name, not before, and that omitting it when a pod has multiple containers will not target the intended container.

How to eliminate wrong answers

Option A is wrong because it places the `-c web` flag before the pod name, which is syntactically incorrect; the `-c` flag must follow the pod name. Option C is wrong because it uses an invalid positional argument 'container' after the pod name; `kubectl logs` does not accept a literal 'container' keyword. Option D is wrong because it omits the `-c` flag entirely, so it would attempt to view logs from the pod's default container (or fail if the pod has multiple containers and no default is defined), not specifically from the container named 'web'.

Practice this question →
10
Multi-Selectmedium

Which TWO of the following are valid ways to expose a Deployment as a Service?

Select 2 answers
A.Run 'kubectl expose deployment my-deployment --port=80 --target-port=8080'
B.Edit the Deployment and set 'spec.serviceName'
C.Run 'kubectl run my-deployment --image=nginx --expose'
D.Add a 'service' section to the Deployment's YAML manifest
E.Create a Service YAML with a selector matching the Deployment's pod labels
AnswersA, E

This command creates a Service based on the Deployment's pod labels.

Why this answer

'kubectl expose deployment my-deployment --port=80 --target-port=8080' creates a Service object that selects pods based on the labels automatically assigned to the Deployment's pods. This command generates a ClusterIP Service by default, mapping port 80 on the Service to port 8080 on the pods, which is a standard and valid method to expose a Deployment.

Exam trap

The trap here is that candidates confuse 'kubectl run --expose' (which creates a Pod, not a Deployment) with exposing an existing Deployment, or incorrectly assume that a Deployment can contain a Service definition within its own YAML manifest.

Practice this question →
11
MCQhard

You have a Deployment that uses a ConfigMap for configuration. You update the ConfigMap with new data. However, the pods in the Deployment continue to use the old configuration. What is the most likely reason?

A.The ConfigMap data is immutable and cannot be updated
B.The ConfigMap is referenced by a different name in the pod spec
C.The ConfigMap is mounted as a volume, and the pods have not been restarted
D.The Deployment's update strategy is set to Recreate
AnswerC

When a ConfigMap is mounted as a volume, the files are updated eventually, but the application may not automatically reload the configuration. For environment variables, the pod must be restarted. In either case, without a restart, the old configuration is used.

Why this answer

When a ConfigMap is mounted as a volume in a Pod, updates to the ConfigMap are automatically propagated to the mounted files, but the running process inside the container does not automatically reload the configuration. The Pod must be restarted (e.g., by rolling update or manual deletion) for the application to read the new values. This is the most common reason for stale configuration in a Deployment.

Exam trap

CNCF often tests the misconception that updating a ConfigMap automatically updates running Pods, when in fact the Pod must be restarted (or the application must watch for file changes) for the new configuration to take effect.

How to eliminate wrong answers

Option A is wrong because ConfigMaps are not immutable by default; they can be updated unless the `immutable` field is explicitly set to `true`. Option B is wrong because if the ConfigMap were referenced by a different name, the Pod would fail to start or mount, not silently use old data. Option D is wrong because the `Recreate` update strategy would terminate all Pods and create new ones, which would pick up the updated ConfigMap; it does not cause stale configuration.

Practice this question →
12
MCQmedium

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?

A.Delete the namespace and redeploy all workloads
B.Increase the memory limit in the pod's container resource specification
C.Delete and recreate the pod to clear the crash loop
D.Increase the CPU request for the container
AnswerB

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 allows the container to use more memory without being killed, directly addressing the root cause of the CrashLoopBackOff.

Exam trap

The CNCF exam often tests the misconception that restarting a pod (Option C) fixes OOMKilled issues, but candidates must recognize that the root cause is the memory limit, not a transient failure.

How to eliminate wrong answers

Option A is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not fix the underlying memory limit issue and would cause unnecessary downtime. Option C is wrong because deleting and recreating the pod would only temporarily restart the container; it would still hit the same memory limit and be OOMKilled again, perpetuating the crash loop. Option D is wrong because increasing the CPU request does not affect memory limits; OOMKilled is caused by exceeding memory, not CPU, so this change would not resolve the issue.

Practice this question →
13
Multi-Selectmedium

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

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

API server is a control plane component.

Why this answer

The Kubernetes control plane manages the cluster and makes global decisions. kube-apiserver is the front-end for the control plane, exposing the Kubernetes API for all interactions. etcd is a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data, making it a core control plane component.

Exam trap

CNCF often tests the distinction between control plane and worker node components, and the trap here is that candidates confuse kubelet or kube-proxy (which run on every node) with control plane components because they are essential to cluster operation but are not part of the control plane itself.

Practice this question →
14
MCQhard

You have a Pod that needs to run a one-time batch job to completion. Which resource type should you use?

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

Jobs run Pods to completion.

Why this answer

A Job resource is designed for running a finite task to completion, such as a batch job or a one-time computation. Unlike controllers that maintain a desired number of replicas indefinitely, a Job creates one or more Pods and tracks their successful termination. Once the specified number of completions is reached, the Job is considered finished and no further Pods are created.

Exam trap

The trap here is that candidates often confuse a Job with a Deployment, thinking that any workload that runs a container should use a Deployment, but Deployments are designed for long-running services, not ephemeral batch tasks.

How to eliminate wrong answers

Option B (StatefulSet) is wrong because StatefulSets are used for stateful applications that require stable, unique network identities and persistent storage, not for one-time batch jobs. Option C (DaemonSet) is wrong because DaemonSets ensure that a copy of a Pod runs on every (or selected) node in the cluster, typically for daemon-like services such as logging or monitoring, not for tasks that run to completion. Option D (Deployment) is wrong because Deployments manage a set of identical Pods with a desired replica count, ensuring they are always running and self-healing, which is the opposite of a one-time batch job that should terminate upon success.

Practice this question →
15
MCQeasy

Which of the following is a worker node component responsible for ensuring that containers are running in a pod as specified in the pod's spec?

A.kube-scheduler
B.kube-proxy
C.kubelet
D.etcd
AnswerC

The kubelet ensures that containers are running in a pod as specified.

Why this answer

The kubelet is the primary node agent that runs on each worker node. It receives PodSpecs (via the API server or a file) and ensures that the containers described in those PodSpecs are running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers as required.

Exam trap

CNCF often tests the distinction between control plane components (scheduler, etcd) and worker node agents (kubelet, kube-proxy), and the trap here is confusing the kubelet's role of running containers with the kube-scheduler's role of placing pods onto nodes.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is a control plane component responsible for assigning pods to nodes based on resource requirements and constraints, not for running containers on a node. Option B is wrong because kube-proxy is a network proxy that runs on each node, handling network rules (e.g., iptables or IPVS) for service abstraction and pod-to-service communication, not container lifecycle management. Option D is wrong because etcd is a distributed key-value store used as Kubernetes' backing store for all cluster data, not a node-level component that manages containers.

Practice this question →
16
MCQmedium

Which component on a worker node is responsible for enforcing the network rules and implementing Service abstractions?

A.kube-proxy
B.kubelet
C.container runtime
D.kube-scheduler
AnswerA

kube-proxy maintains network rules for Service connectivity.

Why this answer

kube-proxy is the component on each worker node that implements Service abstractions by maintaining network rules (iptables, IPVS, or userspace) that allow traffic to reach Pods from inside or outside the cluster. It watches the Kubernetes API server for changes to Services and EndpointSlices, then updates the node's packet filtering rules to forward traffic to the correct backend Pods, handling load balancing and session affinity.

Exam trap

A common misconception is that kubelet or the container runtime handles Service networking, but kube-proxy is the dedicated component for implementing network rules and Service abstractions on each node.

How to eliminate wrong answers

Option B (kubelet) is wrong because kubelet is the primary node agent that manages Pod lifecycle (creating, stopping, and reporting Pod status) and mounts volumes, but it does not enforce network rules or implement Service abstractions. Option C (container runtime) is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for pulling images and running containers, not for network policy or Service proxying. Option D (kube-scheduler) is wrong because kube-scheduler runs on the control plane, not worker nodes, and is responsible for assigning Pods to nodes based on resource availability and constraints, not for enforcing network rules.

Practice this question →
17
MCQmedium

You have a Deployment named 'web-app' that manages 3 replicas. You need to update the container image from version 1.0 to 2.0 with zero downtime. Which Kubernetes feature is designed to handle this automatically when you update the Deployment's pod template?

A.ReplicationController
B.Rolling update strategy in the Deployment
C.DaemonSet
D.StatefulSet's onDelete strategy
AnswerB

The rolling update strategy is the default update strategy for Deployments, enabling gradual pod replacement with zero downtime.

Why this answer

A Deployment's default update strategy is 'RollingUpdate', which automatically replaces old Pods with new ones in a controlled manner, ensuring zero downtime by incrementally scaling down old replicas and scaling up new replicas. When you update the container image in the Deployment's pod template, Kubernetes triggers a rolling update that maintains the desired number of replicas throughout the process.

Exam trap

The trap here is that candidates may confuse the Deployment's automatic rolling update with manual update methods (like onDelete) or think that a ReplicationController or DaemonSet can handle zero-downtime updates in the same way, but only the Deployment's RollingUpdate strategy provides this out-of-the-box behavior for stateless applications.

How to eliminate wrong answers

Option A is wrong because a ReplicationController does not support rolling updates natively; it only ensures a specified number of Pod replicas are running, and updating its pod template requires manual deletion and recreation of Pods, causing downtime. Option C is wrong because a DaemonSet ensures that a copy of a Pod runs on all (or a subset of) nodes, and it is not designed for managing stateless application replicas with zero-downtime updates; its update strategy can be RollingUpdate or OnDelete, but it is not the feature intended for a Deployment like 'web-app'. Option D is wrong because StatefulSet's onDelete strategy requires manual Pod deletion to trigger updates, which does not provide automatic zero-downtime updates; StatefulSets are designed for stateful applications and their default update strategy is RollingUpdate, but the question asks about a Deployment, not a StatefulSet.

Practice this question →
18
MCQmedium

A Deployment manages ReplicaSets and supports rolling updates. You want to change the container image of a Deployment without downtime. What is the recommended approach?

A.Use kubectl expose to update the image on the service
B.Delete the existing Deployment and create a new one with the updated image
C.Edit the Deployment's pod template spec to use the new image; the Deployment will automatically perform a rolling update
D.Manually delete all pods one by one; they will be recreated with the new image by the ReplicaSet
AnswerC

Changing the pod template triggers a rolling update managed by the Deployment.

Why this answer

Editing the Deployment's pod template spec triggers an automatic rolling update, which is the recommended approach for zero-downtime updates. The Deployment controller creates a new ReplicaSet with the updated image and gradually scales it up while scaling down the old ReplicaSet, ensuring that a minimum number of pods remain available throughout the process.

Exam trap

The trap here is that candidates may confuse `kubectl expose` with updating images, or think that manually deleting pods will trigger the new image, when in fact the ReplicaSet only recreates pods based on its current template.

How to eliminate wrong answers

Option A is wrong because `kubectl expose` creates a Service to expose a Deployment or pod, but it does not update container images; it only manages network access. Option B is wrong because deleting and recreating the Deployment would cause a period of downtime while the new Deployment is being created and pods are scheduled, violating the requirement for no downtime. Option D is wrong because manually deleting pods one by one would cause the existing ReplicaSet to recreate them with the original image, not the new one, and this approach is not automated and risks downtime if pods are deleted faster than they are recreated.

Practice this question →
19
Multi-Selectmedium

Which THREE of the following are valid options for the 'kubectl get' command to display output in different formats?

Select 3 answers
A.-o verbose
B.-o wide
C.-o json
D.-o yaml
E.--describe
AnswersB, C, D

Output with additional details.

Why this answer

`kubectl get -o wide` is a valid output format that displays additional details such as node names and internal IPs for pods, or cluster IPs and ports for services, beyond the default summary columns. This is a standard kubectl output flag for human-readable extended output.

Exam trap

CNCF often tests the distinction between output format flags (`-o`) and separate subcommands (`describe`), trapping candidates who confuse `--describe` with `-o wide` or think `-o verbose` is a real format.

Practice this question →
20
MCQhard

A cluster has a node with the taint 'node-role.kubernetes.io/control-plane:NoSchedule'. A pod must be scheduled on this node for a special workload. Which action is required?

A.Use a nodeSelector to select the node.
B.Remove the taint from the node.
C.Add a toleration to the pod spec.
D.Use podAffinity to attract the pod to the node.
AnswerC

Correct; toleration allows the pod to be scheduled on the tainted node.

Why this answer

A taint on a node causes the scheduler to avoid placing pods on that node unless the pod explicitly tolerates the taint. By adding a toleration in the pod spec that matches the taint key, effect, and optionally the value, the pod becomes eligible to be scheduled on the tainted node. This is the standard Kubernetes mechanism for allowing pods to run on control-plane or other specially tainted nodes.

Exam trap

The trap here is that candidates confuse nodeSelector (label-based) with tolerations (taint-based), thinking that selecting a node by label can override a taint, when in fact taints are a separate, higher-priority scheduling constraint.

How to eliminate wrong answers

Option A is wrong because a nodeSelector only matches node labels, not taints; it cannot override the scheduling restriction imposed by a NoSchedule taint. Option B is wrong because removing the taint would affect all pods and is unnecessary when only a specific pod needs to run on that node; it also violates the principle of least privilege. Option D is wrong because podAffinity attracts pods based on labels of other pods, not node-level taints, and does not bypass the NoSchedule effect.

Practice this question →
21
MCQmedium

You want to update a Deployment's container image from 'nginx:1.20' to 'nginx:1.21' and record the change. Which kubectl command should you use?

A.kubectl edit deployment nginx
B.kubectl apply -f deployment.yaml
C.kubectl set image deployment/nginx nginx=nginx:1.21 --record
D.kubectl set image deployment/nginx nginx=nginx:1.21
AnswerC

The --record flag annotates the change for history.

Why this answer

The `kubectl set image` command directly updates the container image of a specified deployment, and the `--record` flag annotates the change in the rollout history, allowing you to track the change for auditing or rollback purposes. This is the most efficient way to update the image and record the change without editing the full deployment manifest or reapplying a file.

Exam trap

The trap here is that candidates often choose option D, thinking the image update alone suffices, but they overlook the explicit requirement to 'record the change,' which is a common KCNA trick to test attention to detail with the `--record` flag.

How to eliminate wrong answers

Option A is wrong because `kubectl edit deployment nginx` opens the deployment manifest in an editor, which is interactive and does not automatically record the change in the rollout history unless you manually add an annotation; it also requires manual editing, which is error-prone and not the intended command for a simple image update with recording. Option B is wrong because `kubectl apply -f deployment.yaml` applies a manifest file, which would update the deployment only if the file is modified, but it does not inherently record the change in the rollout history unless the manifest includes an annotation; it also requires a separate file, making it less direct than the `--record` flag. Option D is wrong because it lacks the `--record` flag, so while it updates the container image, it does not annotate the change in the rollout history, failing to meet the requirement to 'record the change'.

Practice this question →
22
MCQhard

You create a Service of type ClusterIP in the 'default' namespace. You try to reach the Service from a pod in the 'production' namespace using the service name. The connection fails. What is the most likely reason?

A.The pod cannot resolve the DNS name because service DNS names are only resolvable within the same namespace
B.Cross-namespace service access is not allowed by default
C.The service has no endpoints
D.The service port is not correctly configured
AnswerA

DNS resolution for services is namespace-scoped; you need to use the FQDN.

Why this answer

By default, Kubernetes DNS resolves Service names only within the same namespace. A Service named 'my-svc' in the 'default' namespace is resolvable as 'my-svc' only from pods in the 'default' namespace. From a pod in the 'production' namespace, the DNS name must be fully qualified as 'my-svc.default.svc.cluster.local' to be resolved, otherwise the DNS lookup fails, causing the connection to fail.

Exam trap

A common mistake is to think that Kubernetes network policies block cross-namespace traffic, but the actual issue is DNS name resolution. A Service DNS name is only resolvable within the same namespace unless a fully qualified domain name (FQDN) is used.

How to eliminate wrong answers

Option B is wrong because cross-namespace service access is allowed by default in Kubernetes; there is no built-in network policy blocking it, and the issue is purely DNS resolution, not network-level access. Option C is wrong because the question states the connection fails due to DNS resolution, not because the service lacks endpoints; even if endpoints exist, the pod cannot resolve the short service name across namespaces. Option D is wrong because the service port configuration is irrelevant if the DNS name cannot be resolved; the connection fails before any port-level communication occurs.

Practice this question →
23
MCQhard

You have a Deployment that runs a web application. You need to expose this application externally on a fixed port using a cloud load balancer. Which Service type should you use?

A.NodePort
B.LoadBalancer
C.ExternalName
D.ClusterIP
AnswerB

LoadBalancer provisions an external load balancer and assigns a fixed external IP.

Why this answer

A LoadBalancer Service type provisions an external cloud load balancer (e.g., AWS ELB, GCP TCP/UDP Load Balancer) that exposes the application on a fixed port (typically 80/443) and distributes traffic to the Pods. This is the correct choice because the requirement explicitly asks for a cloud load balancer with a fixed external port, which is exactly what LoadBalancer provides by integrating with the underlying cloud provider's API.

Exam trap

CNCF often tests the misconception that NodePort is sufficient for external access, but the question's requirement for a 'cloud load balancer' and 'fixed port' (like 80/443) disqualifies NodePort because it uses a high port range and lacks cloud LB integration.

How to eliminate wrong answers

Option A is wrong because NodePort exposes the application on a static port on each node's IP (range 30000-32767), not via a cloud load balancer, and does not provide a fixed external port like 80 or 443. Option C is wrong because ExternalName maps a Service to a DNS name (CNAME record) and does not expose any ports or provide load balancing; it is used for external service discovery, not for exposing an application externally. Option D is wrong because ClusterIP exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like an Ingress or a proxy.

Practice this question →
24
MCQmedium

Which component runs on every node and is responsible for maintaining network rules that allow communication to Pods from network endpoints?

A.kube-controller-manager
B.kube-proxy
C.container runtime
D.kubelet
AnswerB

kube-proxy maintains network rules for service connectivity.

Why this answer

B is correct because kube-proxy is the component that runs on every node in a Kubernetes cluster and is responsible for maintaining network rules (e.g., iptables, IPVS, or userspace proxy) that allow network communication to Pods from network endpoints, both inside and outside the cluster. It implements the Kubernetes Service concept by managing the mapping of Service IPs to backend Pod IPs and performing load balancing.

Exam trap

The trap here is that candidates often confuse kubelet with kube-proxy because both run on every node, but kubelet manages Pods and containers, while kube-proxy exclusively handles network rules for Service connectivity.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that regulate cluster state, but it does not run on every node nor manage per-node network rules. Option C is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for pulling images and running containers, not for maintaining network rules for Pod communication. Option D is wrong because kubelet is the primary node agent that registers the node with the API server and manages Pod lifecycle (e.g., ensuring containers are running), but it does not handle network rule maintenance for Service-to-Pod traffic.

Practice this question →
25
Multi-Selectmedium

Which THREE of the following are valid types of Kubernetes Services? (Select THREE)

Select 3 answers
A.InternalIP
B.LoadBalancer
C.NodePort
D.ExternalName
E.ClusterIP
AnswersB, C, E

LoadBalancer exposes the Service externally via a cloud provider's load balancer.

Why this answer

(LoadBalancer) is correct because it exposes the Service externally using a cloud provider's load balancer, which automatically routes external traffic to the NodePort and ClusterIP Services. This is one of the four standard Kubernetes Service types defined in the core API.

Exam trap

The trap in this question is that InternalIP is not a valid Kubernetes Service type. Candidates may confuse it with internal cluster networking concepts. The three recognized types from the options are ClusterIP, NodePort, and LoadBalancer.

ExternalName is also a valid type but is not one of the three selected here.

Practice this question →
26
MCQmedium

What is the purpose of kube-proxy on a worker node?

A.To run the container runtime
B.To store cluster configuration data
C.To implement network rules and handle service traffic routing
D.To monitor pod health and restart unhealthy containers
AnswerC

kube-proxy configures iptables or IPVS rules to route traffic to the correct Pods.

Why this answer

Kube-proxy is the component responsible for implementing network rules on each worker node, enabling service abstraction by managing IP tables or IPVS rules to route traffic to the appropriate pods. It handles service discovery and load balancing for ClusterIP, NodePort, and LoadBalancer service types, ensuring that traffic destined for a service is correctly forwarded to healthy pod endpoints.

Exam trap

CNCF often tests the misconception that kube-proxy handles pod health checks and restarts, but that is actually the kubelet's job, while kube-proxy only deals with network traffic routing and service abstraction.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is a separate component that runs containers, not kube-proxy. Option B is wrong because cluster configuration data is stored in etcd, a distributed key-value store, not in kube-proxy. Option D is wrong because monitoring pod health and restarting unhealthy containers is the responsibility of the kubelet, specifically through liveness probes and pod lifecycle management, not kube-proxy.

Practice this question →
27
MCQmedium

Which Kubernetes resource provides stable network endpoints for a set of pods, enabling service discovery and load balancing?

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

A Service provides a stable endpoint and load balancing for a set of pods, enabling service discovery within the cluster.

Why this answer

A Service is the correct Kubernetes resource because it provides a stable virtual IP (ClusterIP) and DNS name that persists independently of pod lifecycles, enabling reliable service discovery and client-side load balancing across a set of pods selected by labels. This abstraction decouples clients from ephemeral pod IPs, ensuring traffic is routed to healthy pods via kube-proxy and iptables/IPVS rules.

Exam trap

CNCF often tests the misconception that Ingress provides load balancing and stable endpoints directly to pods, when in fact Ingress only routes external traffic to a Service, which is the actual resource providing those capabilities.

How to eliminate wrong answers

Option B is wrong because NetworkPolicy is a firewall rule that controls ingress/egress traffic at the pod level using IP blocks or label selectors, but it does not provide stable network endpoints or load balancing. Option C is wrong because Ingress is an API object that manages external HTTP/HTTPS routing to Services (typically via a controller like NGINX), but it does not itself provide stable endpoints or load balance directly to pods; it relies on a Service for that. Option D is wrong because EndpointSlice is a lower-level resource that tracks the actual pod IPs and ports backing a Service, but it is a data object consumed by kube-proxy, not a resource that provides stable endpoints or load balancing on its own.

Practice this question →
28
MCQmedium

Which resource type provides a stable IP address and DNS name to access a set of Pods, regardless of Pod IP changes?

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

Services provide stable networking for Pods.

Why this answer

A Service in Kubernetes provides a stable virtual IP (ClusterIP) and a DNS name (via CoreDNS) that remains constant even as Pods are created, destroyed, or rescheduled. This decouples client access from the ephemeral nature of Pod IPs, ensuring reliable connectivity to the Pods selected by the Service's label selector.

Exam trap

The trap here is that candidates confuse Ingress with providing a stable IP/DNS for Pods, but Ingress only routes external traffic to a Service and does not itself assign a stable internal endpoint.

How to eliminate wrong answers

Option A is wrong because an Ingress is not a resource that provides a stable IP/DNS for Pods directly; it is a layer 7 HTTP/HTTPS routing rule that exposes Services externally, relying on a Service to provide the stable endpoint. Option B is wrong because a ConfigMap is used to store non-confidential configuration data as key-value pairs, not to provide network endpoints or IP addresses. Option C is wrong because a Deployment manages the desired state and lifecycle of Pods (replicas, rolling updates) but does not assign a stable IP or DNS name; Pods managed by a Deployment get new IPs on restart.

Practice this question →
29
Multi-Selectmedium

Which TWO statements about Kubernetes Services are correct?

Select 2 answers
A.A Service can only route traffic to Pods in the same namespace
B.A Service can only be of type ClusterIP
C.A Service automatically scales Pods based on load
D.A Service provides a stable IP address for Pods
E.A Service uses selectors to identify target Pods
AnswersD, E

Services have a virtual IP that remains stable even as Pods change.

Why this answer

A Kubernetes Service provides a stable virtual IP address that remains constant even as the underlying Pods are created, destroyed, or rescheduled. This decouples clients from the ephemeral nature of Pod IPs, ensuring reliable connectivity within the cluster.

Exam trap

The trap here is that candidates often confuse the Service's role in providing a stable IP with the idea that it also handles scaling, or they mistakenly think Services are restricted to a single namespace or type, when in fact they are flexible across namespaces and types.

Practice this question →
30
MCQhard

You have a Pod with a container that runs a web server. The Pod has a memory request of 256Mi and a memory limit of 512Mi. The container attempts to allocate 600Mi of memory. What happens?

A.The memory limit is automatically increased to 600Mi
B.The container is killed by the OOM killer, and the Pod enters CrashLoopBackOff
C.The Pod is evicted from the node
D.The container is allowed to use up to 600Mi because the limit is a soft constraint
AnswerB

Exceeding the memory limit triggers OOM kill; the container restarts and may crash again.

Why this answer

When a container's memory usage exceeds its memory limit (512Mi), the Linux Out-Of-Memory (OOM) killer terminates the container process. Kubernetes then restarts the container based on the Pod's restart policy, but because the container immediately tries to allocate 600Mi again, it is repeatedly killed, resulting in a CrashLoopBackOff state. Memory limits are hard constraints enforced by the kernel via cgroups, not soft limits.

Exam trap

A common misconception is that memory limits are 'soft' or 'advisory' (like CPU limits), but in Kubernetes, memory limits are hard and enforced by the kernel's OOM killer, causing container termination when exceeded.

How to eliminate wrong answers

Option A is wrong because Kubernetes never automatically increases a resource limit; limits are static and defined in the Pod spec. Option C is wrong because Pod eviction occurs when a node is under memory pressure and the Pod's usage exceeds its request, not when a single container exceeds its limit (the container is killed in-place). Option D is wrong because memory limits are hard constraints enforced by the kernel's cgroup OOM killer, not soft constraints; the container cannot exceed the limit.

Practice this question →
31
Multi-Selecthard

Which THREE of the following are valid fields in a Kubernetes Deployment spec (apps/v1)?

Select 3 answers
A.replicas
B.template
C.selector
D.containers
E.nodeName
AnswersA, B, C

Specifies the desired number of pods.

Why this answer

The `replicas` field is a standard part of the Deployment spec under `apps/v1`, defining the desired number of Pod replicas. Option B is correct because the `template` field is mandatory, containing the Pod template that describes the Pods to be created. Option C is correct because the `selector` field is required to match the Pods managed by the Deployment, ensuring the ReplicaSet controls the correct Pods.

Exam trap

CNCF often tests the distinction between fields that belong to the Deployment spec versus fields that belong to the Pod spec, so candidates mistakenly select `containers` or `nodeName` as top-level Deployment fields.

Practice this question →
32
MCQeasy

What is the primary purpose of Kubernetes?

A.To compile source code
B.To orchestrate containers across a cluster
C.To run virtual machines
D.To manage physical servers
AnswerB

Kubernetes automates the deployment, scaling, and management of containerized applications.

Why this answer

Kubernetes is a container orchestration platform designed to automate the deployment, scaling, and management of containerized applications across a cluster of nodes. Its primary purpose is to abstract the underlying infrastructure and provide a declarative way to run and manage containers, ensuring desired state and self-healing. This directly corresponds to orchestrating containers across a cluster, not compiling code, running VMs, or managing physical servers.

Exam trap

CNCF often tests the misconception that Kubernetes is a general-purpose infrastructure manager, but the trap here is confusing container orchestration with VM management or physical server administration, leading candidates to pick Option C or D.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not compile source code; compilation is handled by build tools like Docker or language-specific compilers, while Kubernetes only runs the resulting container images. Option C is wrong because Kubernetes is designed for containers, not virtual machines; it can orchestrate VMs via providers like KubeVirt, but that is a specialized extension, not its primary purpose. Option D is wrong because Kubernetes abstracts physical servers into a cluster and manages container workloads, not the physical hardware itself; hardware management is the role of infrastructure tools like IPMI or provisioning systems.

Practice this question →
33
MCQeasy

Which kubectl command would you use to view detailed information about a specific pod, including events and container status?

A.kubectl explain pod
B.kubectl get pod <pod-name>
C.kubectl logs pod <pod-name>
D.kubectl describe pod <pod-name>
AnswerD

This command provides a detailed description of the pod including events and container statuses.

Why this answer

`kubectl describe pod <pod-name>` provides a comprehensive view of a pod's metadata, spec, status, conditions, container resource usage, and a chronological list of events (e.g., scheduling, pulling images, container restarts). This command aggregates information from the Kubernetes API server, including the pod's current state and lifecycle events, which is essential for debugging pod failures or unexpected behavior.

Exam trap

CNCF often tests the distinction between `kubectl get` (summary) and `kubectl describe` (detailed with events), expecting candidates to know that only `describe` surfaces the event stream and container state transitions needed for troubleshooting.

How to eliminate wrong answers

Option A is wrong because `kubectl explain pod` only displays the API documentation for the Pod resource schema (fields and descriptions), not runtime details or events about a specific pod instance. Option B is wrong because `kubectl get pod <pod-name>` outputs a concise summary (name, status, restarts, age) but omits detailed container status, conditions, and events. Option C is wrong because `kubectl logs pod <pod-name>` retrieves only the stdout/stderr output from the pod's containers, not the pod's metadata, status, or Kubernetes events.

Practice this question →
34
MCQhard

A Service of type ClusterIP has been created, but pods in the same namespace cannot reach it by its DNS name. The Service selector matches the pods. What is a likely cause?

A.The Service YAML does not specify a port
B.The kube-dns or CoreDNS pod is not running
C.The Service is not exposed on a node port
D.The pods are using an incorrect container runtime
AnswerB

DNS resolution is provided by CoreDNS; if it is down, DNS names cannot be resolved.

Why this answer

The DNS name resolution for a ClusterIP Service relies on the cluster's DNS service (kube-dns or CoreDNS). If the DNS pod is not running, the Service's DNS record (e.g., <service>.<namespace>.svc.cluster.local) cannot be resolved, even if the Service itself is properly configured and the pods match the selector. Without DNS, pods must use the Service's ClusterIP directly, which is not the expected behavior for name-based access.

Exam trap

The trap here is that candidates often assume DNS resolution is automatic and always available, overlooking that the DNS service itself is a critical component that must be running for name-based Service discovery to work.

How to eliminate wrong answers

Option A is wrong because a Service of type ClusterIP does not require a port specification to be reachable by DNS; the port is needed for actual traffic routing, but DNS resolution depends on the Service object existing in the API server, not on port definitions. Option C is wrong because exposing a Service on a node port (NodePort type) is unrelated to DNS resolution within the cluster; ClusterIP Services are reachable internally without node ports, and DNS works regardless of the Service type. Option D is wrong because the container runtime (e.g., containerd, CRI-O) does not affect DNS resolution; DNS is handled by the cluster's network and DNS infrastructure, not by how containers are run.

Practice this question →
35
MCQhard

You need to run a one-time batch job that processes data and then exits. The job should run to completion and not be restarted. Which Kubernetes resource should you use?

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

Jobs are designed for batch processing and run to completion.

Why this answer

A Kubernetes Job is designed for one-time batch processing tasks that run to completion and are not restarted. It creates one or more Pods and ensures they successfully terminate, making it the correct choice for a non-repeating, finite workload.

Exam trap

CNCF often tests the distinction between a Job and a CronJob, where candidates might mistakenly choose a CronJob for a one-time task, or confuse a Job's restart behavior with that of a Deployment's rolling update.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on all (or a subset of) nodes, typically for long-running services like log collectors or monitoring agents, not for one-time batch jobs. Option C is wrong because a Deployment manages a set of identical Pods to maintain a desired replica count for long-running, stateless applications, and it will restart Pods if they exit, which contradicts the requirement that the job should not be restarted. Option D is wrong because a StatefulSet is used for stateful applications that require stable, unique network identities and persistent storage, such as databases, and is not intended for ephemeral batch processing.

Practice this question →
36
Multi-Selecteasy

Which two commands are valid for viewing information about pods in a namespace named 'production'?

Select 2 answers
A.kubectl logs pods -n production
B.kubectl get pods -n production
C.kubectl get all -n production
D.kubectl run pod --image=nginx -n production
E.kubectl describe pod <pod-name> -n production
AnswersB, E

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.

Practice this question →
37
Multi-Selecthard

Which three components are part of the Kubernetes control plane?

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

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.

Practice this question →
38
MCQeasy

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

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

etcd is the 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.

Practice this question →
39
Multi-Selectmedium

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

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

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.

Practice this question →
40
MCQhard

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

A.spec.strategy.rollingUpdate.maxUnavailable
B.spec.minReadySeconds
C.spec.strategy.rollingUpdate.maxSurge
D.spec.replicas
AnswerA

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.

Practice this question →
41
MCQmedium

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

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

Secrets store sensitive data 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.

Practice this question →
42
Multi-Selectmedium

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

Select 2 answers
A.Secret
B.Volume
C.PersistentVolumeClaim
D.ServiceAccount
E.ConfigMap
AnswersA, E

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.

Practice this question →
43
Multi-Selecteasy

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

Select 2 answers
A.kubectl describe pod my-pod
B.kubectl exec my-pod -- cat /var/log/app.log
C.kubectl logs my-pod
D.kubectl run my-pod -- logs
E.kubectl attach my-pod
AnswersB, C

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.

Practice this question →
44
Multi-Selectmedium

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

Select 3 answers
A.kubectl exec -it pod-name -- /bin/bash
B.kubectl run nginx --image=nginx
C.kubectl logs pod-name
D.kubectl create -f pod.yaml
E.kubectl apply -f deployment.yaml
AnswersB, D, E

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.

Practice this question →
45
MCQmedium

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

A.spec.replicas
B.spec.minReadySeconds
C.spec.strategy.rollingUpdate.maxSurge
D.spec.strategy.rollingUpdate.maxUnavailable
AnswerD

maxUnavailable 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.

Practice this question →
46
MCQhard

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

A.spec.strategy.rollingUpdate.maxSurge
B.spec.strategy.rollingUpdate.maxUnavailable
C.spec.minReadySeconds
D.spec.replicas
AnswerB

maxUnavailable 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.

Practice this question →
47
Multi-Selecthard

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

Select 2 answers
A.Assigning pods to nodes
B.Storing cluster state
C.Managing endpoint objects for Services
D.Monitoring node health
E.Serving the Kubernetes API
AnswersC, D

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.

Practice this question →
48
MCQmedium

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

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

Secrets store sensitive 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.

Practice this question →
49
MCQmedium

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

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

The 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.

Practice this question →
50
MCQhard

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

A.kubectl describe pod db-service
B.kubectl get endpoints db-service
C.kubectl exec -it <some-pod> -- curl db-service
D.kubectl logs db-service
AnswerB

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.

Practice this question →
51
MCQmedium

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?

A.The pod will fail to start because the probe port mismatches the container port.
B.The liveness probe will fail, but the pod will still be marked as Ready.
C.The liveness probe will fail, causing the container to be restarted.
D.The pod will run successfully because the probe is not required.
AnswerC

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.

Practice this question →
52
MCQhard

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?

A.Set restartPolicy: OnFailure in the pod spec
B.Use a DaemonSet instead of a Deployment
C.Increase the memory limit in the container's resources.limits and add a liveness probe that triggers on high memory usage
D.Set terminationGracePeriodSeconds to 0
AnswerC

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.

Practice this question →
53
MCQeasy

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

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

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.

Practice this question →
54
MCQhard

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

A.kubectl set image deployment/my-deployment nginx=nginx:1.21
B.kubectl delete deployment/my-deployment --cascade=false
C.kubectl rollout undo deployment/my-deployment
D.kubectl rollout pause deployment/my-deployment
AnswerC

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.

Practice this question →
55
MCQhard

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

A.The command syntax is incorrect; you should use 'kubectl set image deployment/myapp myapp:v2'
B.The new Pods are crashing due to a missing command
C.The Deployment's update strategy is set to 'Recreate'
D.The new image myapp:v2 does not exist or cannot be pulled from the registry
AnswerD

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.

Practice this question →
56
Multi-Selecthard

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

Select 3 answers
A.Ingress
B.NodePort
C.LoadBalancer
D.ClusterIP
E.ExternalName
AnswersA, B, C

Ingress 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.

Practice this question →
57
MCQmedium

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?

A.kubectl set image deployment/frontend container1=nginx:1.20
B.kubectl replace deployment frontend --image=nginx:1.20
C.kubectl edit deployment frontend --image=nginx:1.20
D.kubectl update deployment frontend --image=v2
AnswerA

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`.

Practice this question →
58
MCQmedium

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

A.Scale down the Deployment to 0 replicas, then scale up with the new image
B.Update the Deployment's pod template image to version 2.0
C.Delete the existing ReplicaSet and create a new one with the updated image
D.Directly update the pods in the ReplicaSet by using 'kubectl edit pod'
AnswerB

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.

Practice this question →
59
MCQmedium

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

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

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.

Practice this question →
60
MCQhard

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?

A.The Deployment's 'paused' field is set to true
B.The Deployment's 'revisionHistoryLimit' is set to 1
C.maxSurge and maxUnavailable are set to values that allow termination of old Pods before new ones are ready
D.The RollingUpdate strategy has maxSurge=0 and maxUnavailable=0
AnswerC

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.

Practice this question →
61
MCQmedium

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

A.spec.containers.cpu
B.resources.requests.cpu
C.resources.limits.cpu
D.spec.nodeSelector
AnswerB

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.

Practice this question →
62
MCQmedium

Which kubectl command is used to create or update resources defined in a YAML file?

A.kubectl update -f file.yaml
B.kubectl create -f file.yaml
C.kubectl apply -f file.yaml
D.kubectl set -f file.yaml
AnswerC

This creates or updates resources based on the current state defined in the file.

Why this answer

`kubectl apply -f file.yaml` uses a declarative approach to create or update Kubernetes resources. It sends the YAML configuration to the API server, which compares the desired state with the current state and applies the necessary changes, storing the last-applied configuration in an annotation for future 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), or assume a non-existent `kubectl update` command exists based on other tools like `apt update`.

How to eliminate wrong answers

Option A is wrong because `kubectl update` is not a valid kubectl command; Kubernetes uses `kubectl edit`, `kubectl patch`, or `kubectl apply` to modify resources, not `update`. Option B is wrong because `kubectl create -f file.yaml` only creates new resources and will fail if the resource already exists, whereas the question asks for creating OR updating. Option D is wrong because `kubectl set -f file.yaml` is not a valid command; `kubectl set` is used to modify specific fields of live resources (e.g., `kubectl set image`), not to apply a full YAML file.

Practice this question →
63
Multi-Selecteasy

Which TWO components are part of the Kubernetes control plane?

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

The kube-apiserver exposes the Kubernetes API, serving as the front-end for the control plane by validating and processing RESTful requests to etcd. This satisfies the stem’s constraint of being a control-plane component, as it orchestrates cluster state changes and authentication, distinct from worker-node agents like kubelet.

Why this answer

The Kubernetes control plane manages the cluster's state and scheduling decisions. The kube-apiserver (C) is the front-end for the control plane, exposing the Kubernetes API, while etcd (D) is the distributed key-value store that holds all cluster data, including configuration and state. Both are essential control plane components.

Exam trap

CNCF often tests the misconception that kubelet or kube-proxy are control plane components because they are essential for node operation, but they actually run on worker nodes and are considered node-level services.

Practice this question →
64
Multi-Selectmedium

Which two of the following are valid ways to expose a set of Pods to external traffic?

Select 2 answers
A.Create a Service of type NodePort
B.Use a ConfigMap to expose the Pods
C.Create an Ingress resource without a Service
D.Create a Service of type LoadBalancer
E.Create a Service of type ClusterIP
AnswersA, D

NodePort exposes the Service on each node's IP at a static port.

Why this answer

A Service of type NodePort exposes each Pod's port on a static port (the NodePort) on every node's IP address, allowing external traffic to reach the Pods via <NodeIP>:<NodePort>. This is a valid method for exposing a set of Pods to external traffic without requiring a cloud load balancer.

Exam trap

A common misconception is that an Ingress resource can function without an underlying Service, but Ingress only provides routing and must point to a Service to reach Pods.

Practice this question →
65
MCQmedium

A user wants to run a one-time batch job that runs to completion. Which Kubernetes resource should they use?

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

Job is correct for one-time batch jobs.

Why this answer

A Kubernetes Job is the correct resource for a one-time batch job that runs to completion. Unlike controllers designed for long-running processes, a Job creates one or more Pods and ensures they successfully terminate, making it ideal for finite tasks like data processing or backups.

Exam trap

A common pitfall is assuming that a Deployment can handle batch jobs because it manages Pods, but Deployments enforce a desired replica count and restart policies that keep Pods running indefinitely, making them unsuitable for tasks that must terminate successfully after completing their work.

How to eliminate wrong answers

Option B (StatefulSet) is wrong because it manages stateful applications with persistent identities and stable storage, designed for long-running workloads like databases, not one-time batch jobs. Option C (DaemonSet) is wrong because it ensures a Pod runs on every node in the cluster, intended for cluster-wide services like logging agents, not finite tasks. Option D (Deployment) is wrong because it manages stateless, long-running applications with rolling updates and scaling, aiming for continuous availability, not job completion.

Practice this question →
66
Multi-Selectmedium

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

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

API server is a control plane component.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane, exposing the Kubernetes API for all cluster operations. The kube-scheduler is responsible for assigning newly created pods to nodes based on resource availability and policy constraints. Both are essential control plane components that manage cluster state and scheduling decisions.

Exam trap

CNCF often tests the distinction between control plane and worker node components, and the trap here is that candidates confuse kube-proxy or kubelet (which run on every node) with control plane components because they are essential for cluster operation, but they are not part of the control plane itself.

Practice this question →
67
MCQhard

A Kubernetes cluster has multiple worker nodes. You create a Pod without any node selector. The scheduler places the pod on a node, but the pod remains in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 node had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate'. What does this indicate?

A.The node has a taint that the pod does not tolerate
B.The pod has a resource request that exceeds the node's capacity
C.The node is cordoned and should be uncordoned
D.The node is out of disk space
AnswerA

The error explicitly states the node had a taint that the pod didn't tolerate.

Why this answer

The error message explicitly states that one node had a taint (`node-role.kubernetes.io/master`) that the pod did not tolerate. Taints and tolerations are a Kubernetes mechanism that allows nodes to repel pods unless the pod has a matching toleration. Since the pod was created without any tolerations, the scheduler could not place it on the tainted node, leaving it in 'Pending' state.

Exam trap

The trap here is that candidates may confuse taints with resource constraints or node cordoning, but the specific error message 'node had taint ... that the pod didn't tolerate' directly points to a toleration mismatch, not a capacity or cordon issue.

How to eliminate wrong answers

Option B is wrong because the error message does not mention resource requests or insufficient capacity; it specifically cites a taint issue. Option C is wrong because a cordoned node would show a different message (e.g., 'node is cordoned') and the pod would not be scheduled at all, but here the scheduler attempted placement on a tainted node. Option D is wrong because disk pressure would be reported as a different condition (e.g., 'NodeHasDiskPressure') and would not produce the taint-related error shown.

Practice this question →
68
MCQhard

A user reports that their application's DNS resolution is failing for a Service named 'my-service' in the same namespace. They are able to reach the Service by its cluster IP. Which of the following is the most likely cause?

A.The application container is using an incorrect DNS policy
B.The kube-proxy is misconfigured on the node
C.The CoreDNS pod is not running or misconfigured
D.The Service is of type ExternalName
AnswerC

CoreDNS is responsible for DNS resolution for Services. If CoreDNS is down or misconfigured, DNS queries for Services will fail.

Why this answer

DNS resolution for a Service in the same namespace relies on CoreDNS, which is the cluster DNS provider in Kubernetes. If CoreDNS is not running or misconfigured, DNS queries for the Service name (e.g., 'my-service') will fail, even though the Service is reachable via its cluster IP. The user's ability to reach the Service by IP confirms that kube-proxy and networking are functional, isolating the issue to DNS resolution.

Exam trap

CNCF often tests the distinction between DNS resolution and Service reachability, trapping candidates who assume that a DNS failure must be caused by the application's DNS policy rather than the cluster DNS service itself.

How to eliminate wrong answers

Option A is wrong because an incorrect DNS policy (e.g., ClusterFirstWithHostNet or None) would affect how the container resolves names, but it would not cause a complete failure for a Service in the same namespace if CoreDNS is healthy; the user can still reach the Service by IP, indicating the DNS policy is not the primary issue. Option B is wrong because kube-proxy is responsible for implementing Service IP-to-Pod routing via iptables or IPVS; since the user can reach the Service by its cluster IP, kube-proxy is functioning correctly. Option D is wrong because a Service of type ExternalName returns a CNAME record, not a cluster IP; the user can reach the Service by its cluster IP, so the Service cannot be of type ExternalName.

Practice this question →
69
MCQmedium

A Service of type ClusterIP is created. What is the default behavior of this Service?

A.It exposes the Service externally via a cloud load balancer
B.It exposes the Service on a static port on each node
C.It routes traffic to Pods based on external DNS names
D.It exposes the Service on a cluster-internal IP
AnswerD

ClusterIP is the default and provides internal connectivity only.

Why this answer

A ClusterIP Service is the default Kubernetes Service type, which assigns a virtual IP address reachable only within the cluster. Traffic sent to this IP is load-balanced across the Pods selected by the Service's label selector, using iptables or IPVS rules. No external access is provided unless an Ingress or other mechanism is explicitly configured.

Exam trap

The trap here is that candidates often confuse the default Service type (ClusterIP) with NodePort or LoadBalancer, assuming a Service must be externally accessible by default, but Kubernetes intentionally isolates ClusterIP Services to internal cluster traffic only.

How to eliminate wrong answers

Option A is wrong because exposing a Service externally via a cloud load balancer is the behavior of a Service of type LoadBalancer, not ClusterIP. Option B is wrong because exposing the Service on a static port on each node is the behavior of a Service of type NodePort, which opens a high-port on every node's IP. Option C is wrong because routing traffic based on external DNS names is not a native Service behavior; DNS-based routing is typically handled by an Ingress controller or external DNS integration, not by a ClusterIP Service.

Practice this question →
70
MCQhard

You have a Deployment with 3 replicas. You need to perform a rolling update with 2 extra pods during the update and ensure that only 1 pod is unavailable at any time. Which update strategy configuration achieves this?

A.maxSurge: 1, maxUnavailable: 2
B.maxSurge: 0, maxUnavailable: 2
C.maxSurge: 3, maxUnavailable: 0
D.maxSurge: 2, maxUnavailable: 1
AnswerD

Why this answer

It sets maxSurge to 2 (allowing up to 2 extra pods above the desired 3, for a total of 5 pods during the update) and maxUnavailable to 1 (ensuring at most 1 pod is unavailable at any time). This satisfies the requirement of having 2 extra pods during the update while keeping only 1 pod unavailable.

Exam trap

The trap here is that candidates often confuse maxSurge and maxUnavailable as percentages or misinterpret the requirement for '2 extra pods' as a surge of 2, but forget that maxUnavailable must also be set to 1 to limit downtime, leading them to pick option A or B.

How to eliminate wrong answers

Option A is wrong because maxSurge: 1 allows only 1 extra pod, not the required 2 extra pods. Option B is wrong because maxSurge: 0 means no extra pods are allowed, and maxUnavailable: 2 allows 2 pods to be unavailable, violating the requirement of only 1 unavailable pod. Option C is wrong because maxSurge: 3 allows 3 extra pods (more than needed), and maxUnavailable: 0 means zero pods can be unavailable, which is too restrictive and does not match the requirement of allowing 1 unavailable pod.

Practice this question →
71
Multi-Selecteasy

Which two of the following are benefits of using Kubernetes for container orchestration? (Select TWO.)

Select 2 answers
A.Integrated continuous integration pipeline
B.Automatic code compilation
C.Self-healing: automatically restarts failed containers
D.Built-in database management
E.Automated rollouts and rollbacks
AnswersC, E

Kubernetes replaces containers that fail.

Why this answer

Kubernetes provides self-healing capabilities through controllers like ReplicaSets and Deployments, which monitor pod health via liveness probes. If a container fails or becomes unresponsive, the controller automatically terminates the unhealthy pod and creates a replacement to maintain the desired replica count, ensuring application resilience without manual intervention.

Exam trap

A common pitfall is assuming that Kubernetes includes built-in CI/CD, code compilation, or database management features. In reality, these are external tools integrated separately. Kubernetes core features focus on container orchestration, including self-healing (via liveness probes and controllers) and automated rollouts/rollbacks (via Deployments).

Practice this question →
72
MCQhard

A developer wants to inject environment variables into a pod from a ConfigMap named 'app-config'. Which YAML snippet correctly mounts all key-value pairs from the ConfigMap as environment variables?

A.env: - name: CONFIG value: "$(CONFIGMAP)"
B.envFrom: - configMapRef: name: app-config
C.volumes: - name: config configMap: name: app-config volumeMounts: - name: config mountPath: /etc/config
D.env: - name: CONFIG valueFrom: configMapKeyRef: name: app-config key: config.yaml
AnswerB

This mounts all keys from the ConfigMap as environment variables.

Why this answer

`envFrom` with a `configMapRef` injects all key-value pairs from the ConfigMap named 'app-config' as environment variables into the container. This is the standard Kubernetes method for bulk injection of ConfigMap data into environment variables, as opposed to selecting individual keys.

Exam trap

The trap here is that candidates often confuse `envFrom` (bulk injection) with `env` + `configMapKeyRef` (single key injection) or volume mounts (file-based injection), leading them to pick options that inject only one key or mount files instead of environment variables.

How to eliminate wrong answers

Option A is wrong because `env` with `value: "$(CONFIGMAP)"` is not valid syntax; Kubernetes does not support referencing a ConfigMap via a variable expansion like `$(CONFIGMAP)` — it requires explicit `valueFrom` or `envFrom`. Option C is wrong because it mounts the ConfigMap as a volume at `/etc/config`, which injects keys as files, not as environment variables — this does not satisfy the requirement to inject them as environment variables. Option D is wrong because it uses `env` with `configMapKeyRef` to inject only a single key (`config.yaml`) from the ConfigMap, not all key-value pairs.

Practice this question →
73
MCQeasy

A developer wants to run a one-time batch job that processes a queue and then terminates. Which Kubernetes resource should they use?

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

Jobs run pods until successful completion.

Why this answer

A Kubernetes Job is designed for finite, batch-oriented tasks that run to completion, such as processing a queue and then terminating. Unlike controllers that maintain a desired state (like Deployments or StatefulSets), a Job creates one or more Pods and ensures they successfully exit, making it the correct choice for a one-time batch job.

Exam trap

The trap here is that candidates confuse a Job with a Deployment, assuming that any workload that 'runs' must be a Deployment, but Deployments are designed for long-running services and will restart terminated Pods, whereas a Job is the correct resource for workloads that should run to completion and then stop.

How to eliminate wrong answers

Option B (StatefulSet) is wrong because it is used for stateful applications that require stable, unique network identities and persistent storage, not for one-time batch jobs. Option C (Deployment) is wrong because it manages a set of Pods intended to run continuously (e.g., web servers) and will restart Pods if they exit, which is the opposite of a terminating batch job. Option D (DaemonSet) is wrong because it ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, typically for long-running system services like log collectors or monitoring agents, not for one-time tasks.

Practice this question →
74
Multi-Selectmedium

Which TWO resources can be used to store configuration data separately from container images?

Select 2 answers
A.Service
B.PersistentVolume
C.Secret
D.Deployment
E.ConfigMap
AnswersC, E

Secrets store sensitive data like passwords or tokens.

Why this answer

ConfigMaps and Secrets are Kubernetes API objects designed specifically to decouple configuration data and sensitive information from container images. ConfigMaps store non-sensitive key-value pairs (e.g., environment variables, command-line arguments, or configuration files), while Secrets store sensitive data (e.g., passwords, tokens, or SSH keys) in base64-encoded or encrypted form. Both can be mounted into pods as volumes or injected as environment variables, allowing image reuse across different environments without rebuilding.

Exam trap

CNCF often tests the distinction between storage for configuration data (ConfigMaps/Secrets) vs. storage for application data (PersistentVolumes), so candidates mistakenly select PersistentVolume thinking it can store config files, but it is intended for stateful workloads like databases, not for decoupling configuration from images.

Practice this question →
75
MCQhard

Refer to the exhibit. A pod 'my-pod' shows repeated 'BackOff' events after the container starts. Which is the most likely cause?

A.The image 'myapp:v2' does not exist.
B.The container exceeds its memory limit.
C.The liveness probe is failing.
D.The application crashes shortly after starting.
AnswerD

Correct; the container starts but then crashes, leading to restart backoff.

Why this answer

The 'BackOff' event in Kubernetes indicates that the container has started but repeatedly crashes, causing the kubelet to increase the restart delay. Option D is correct because an application that crashes shortly after starting will trigger this restart loop, as the container exits with a non-zero exit code, leading to exponential backoff.

Exam trap

The KCNA exam often tests the distinction between 'ImagePullBackOff' (image not found) and 'CrashLoopBackOff' (container crashes after start), so candidates must recognize that 'BackOff' events after the container starts point to a runtime crash, not a pull failure.

How to eliminate wrong answers

Option A is wrong because if the image 'myapp:v2' does not exist, the pod would show 'ErrImagePull' or 'ImagePullBackOff' events, not 'BackOff' after the container starts. Option B is wrong because exceeding the memory limit causes an 'OOMKilled' status and a container restart, but the event would typically be 'OOMKilled' or 'CrashLoopBackOff', not specifically 'BackOff' after a successful start. Option C is wrong because a failing liveness probe results in the container being killed and restarted, but the event would be 'Unhealthy' or 'Liveness probe failed', and the pod would show 'CrashLoopBackOff' rather than 'BackOff' immediately after start.

Practice this question →
Page 1 of 5 · 326 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Kubernetes Fundamentals questions.

Start 20-question session