Courseiva

CCNA Kubernetes Fundamentals Questions

75 of 400 questions · Page 1/6 · 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

configMapKeyRef injects a single named key from a ConfigMap as an environment variable, satisfying the requirement to map key 'database.url' into DATABASE_URL. The name field targets the 'app-config' ConfigMap and key selects the exact entry, so the container receives that value at startup.

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
Multi-Selecthard

Which three of the following are true about Services in Kubernetes? (Select three.)

Select 3 answers
A.A Service provides a stable IP address for a set of pods
B.A Service can load balance traffic across multiple pods
C.A Service can be used for internal cluster traffic only using ClusterIP
D.A Service can store configuration data for applications
E.A Service can replace an Ingress for HTTP routing
AnswersA, B, C

A Service's ClusterIP is virtual and stable, remaining constant while backing pods are created, deleted or rescheduled. This satisfies the decoupling constraint in the stem: clients address a fixed virtual IP, and kube-proxy translates it to current endpoint IPs, so pod churn never breaks connectivity.

Why this answer

Option A is correct because a Kubernetes Service is assigned a stable virtual IP (the ClusterIP) and DNS name that front a dynamic set of pod endpoints, so clients get a consistent address even as pods are created or destroyed. Option B is correct because kube-proxy programs iptables/IPVS (or the equivalent) rules so that traffic sent to the Service's ClusterIP is load balanced across the matching pods selected by the Service's label selector. Option C is correct because the default ClusterIP Service type exposes the Service only on an internal, cluster-routable virtual IP, making it reachable solely from within the cluster unless NodePort, LoadBalancer, or an Ingress is added.

Option D is not correct because storing configuration data is the role of ConfigMaps and Secrets, not Services, which only handle network endpoint abstraction. Option E is not correct because Ingress provides HTTP/HTTPS layer-7 host- and path-based routing via an ingress controller, whereas a Service only offers layer-4 (or simple L7 with newer Gateway API) access to a single set of pods and cannot perform Ingress-style routing.

Exam trap

Candidates often confuse Services with other resources: Services do not store configuration data (that's ConfigMaps/Secrets) and do not provide HTTP routing (that's Ingress). Services operate at Layer 4 (TCP/UDP), not Layer 7, so they cannot replace Ingress for HTTP-specific routing.

Practice this question →
3
MCQmedium

Which component on each worker node is responsible for ensuring that containers are running as specified in the Pod manifest?

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

kubelet runs on every worker node and reconciles the node's containers against their PodSpecs, starting, stopping and reporting container status. This directly satisfies the stem's requirement for the per-node component ensuring containers run as specified in the Pod manifest.

Why this answer

The kubelet is the primary node agent that runs on each worker node. It receives Pod manifests (via the API server or a file) and ensures the containers described in those manifests are running and healthy. It interacts with the container runtime (e.g., containerd) to create, start, and stop containers as needed, continuously reconciling the actual state with the desired state defined in the Pod spec.

Exam trap

A common trap in the KCNA exam is confusing the kubelet with the container runtime. Remember: the kubelet is the Kubernetes agent that ensures containers are running as specified, while the container runtime is the underlying software (like containerd) that actually executes the containers.

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; it does not run on worker nodes nor manage container lifecycle. Option B is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it is the kubelet that instructs the runtime which containers to run and monitors their status; the runtime itself does not interpret Pod manifests or enforce desired state. Option D is wrong because kube-proxy is a network proxy that runs on each node, managing network rules (e.g., iptables, IPVS) for service load balancing; it has no role in ensuring containers are running.

Practice this question →
4
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

The kubelet is the node agent that watches the API server for PodSpecs bound to its node and starts, stops and health-checks the containers to match that declared state. It therefore satisfies the stem's constraint of running on every node.

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 →
5
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

The scheduler filters nodes by nodeSelector; if no node carries matching labels, no feasible node remains, so the pod stays Pending with no node assigned. This directly satisfies the stem's Pending constraint, since scheduling never completes.

Why this answer

Option A is correct because the scheduler filters nodes using the pod's nodeSelector (and node affinity); if no node carries matching labels, the pod cannot be placed and remains Pending. Option C is correct because the scheduler only assigns a pod to a node whose allocatable resources can satisfy the pod's resource requests; insufficient CPU/memory leaves the pod unschedulable in Pending. Option E is correct because a pod referencing an unbound PersistentVolumeClaim cannot be scheduled until the PVC is bound to a PersistentVolume, so it stays Pending.

Option B is not a scheduling cause: a nonexistent image leads to ImagePullBackOff/ErrImagePull after the pod has been scheduled to a node, so the pod is not Pending. Option D is also not a scheduling cause: a failing liveness probe only occurs after the container is running, causing restarts (CrashLoopBackOff), not a Pending phase.

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 →
6
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

A Deployment manages a ReplicaSet, which maintains the desired replica count by creating replacement pods whenever one fails. This directly satisfies the self-healing requirement for three stateless replicas, unlike a bare Pod or DaemonSet, which cannot guarantee continuous availability across nodes.

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 →
7
MCQeasy

A user wants to check the resource usage of Pods in a cluster. Which command should be used to display CPU and memory usage for all Pods in the default namespace?

A.kubectl top pods
B.kubectl get pods --show-metrics
C.kubectl logs --metrics
D.kubectl describe pods
AnswerA

kubectl top pods displays the current CPU and memory usage for Pods in the default namespace. It requires the Metrics Server to be installed in the cluster. This command is the standard way to view resource usage metrics for Pods. It provides a quick overview of which Pods are consuming the most resources.

Why this answer

The correct command is kubectl top pods, which retrieves CPU and memory usage metrics from the Metrics Server. This command is specifically designed for viewing resource consumption. The other options are either invalid commands or provide different types of information, such as configuration details or logs, but not live resource usage.

Exam trap

The trap here is assuming that kubectl describe or kubectl get can provide live metrics, when only kubectl top is designed for that purpose.

Practice this question →
8
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 scopes log retrieval to the named container, which is mandatory when a pod holds multiple containers. Without it, kubectl errors or picks the default, so -c app isolates the requested container's output.

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 →
9
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 runs on each worker node, watches PodSpecs assigned to it, and starts, stops and probes containers to match the desired state. This satisfies the requirement that containers run as specified, reporting status back to the API server.

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 →
10
MCQmedium

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

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

A Service assigns a stable virtual IP and DNS name, then load-balances traffic across the backing Pods selected by its label selector. Pod IPs change as Pods restart, so the Service abstraction satisfies the requirement for stable network endpoints.

Why this answer

A Service is the Kubernetes abstraction that defines a logical set of Pods and a policy for accessing them, providing a stable IP address and DNS name that remains constant even as Pods are created or destroyed. Services use label selectors to identify target Pods and perform Layer 4 (TCP/UDP) load balancing across them, either via iptables, IPVS, or eBPF rules in kube-proxy.

Exam trap

The trap here is that candidates confuse the Ingress (Layer 7 routing) with the Service (Layer 4 load balancing), forgetting that Ingress requires a Service to forward traffic to Pods and does not itself provide stable endpoints.

How to eliminate wrong answers

Option A is wrong because a NetworkPolicy is a security resource that controls ingress and egress traffic to Pods at the network layer, not a mechanism for stable endpoints or load balancing. Option B is wrong because a Deployment manages the desired state and lifecycle of Pods (replicas, rollouts, rollbacks) but does not expose a stable network endpoint; Pod IPs are ephemeral and change on restart. Option C is wrong because an Ingress is a Layer 7 (HTTP/HTTPS) routing resource that sits in front of Services, providing host/path-based routing and TLS termination, but it does not itself provide stable endpoints or load balancing for Pods—it relies on a Service for that.

Practice this question →
11
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

`kubectl logs` targets a single container's stdout/stderr stream, and the `-c web` flag selects the container named 'web' within the pod, while `-n production` satisfies the namespace constraint. Without `-c`, the command would fail on a multi-container pod or default to the wrong container.

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 →
12
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

The imperative 'kubectl expose' command reads the Deployment's pod template, creates a Service with the matching label selector, and maps port 80 to container port 8080. It is a valid, supported way to expose a Deployment.

Why this answer

Option A is correct because 'kubectl expose deployment my-deployment --port=80 --target-port=8080' is the imperative command that creates a Service of type ClusterIP (by default) targeting the Deployment's pods, with the Service port 80 forwarding to container port 8080. Option E is correct because a Service is decoupled from the Deployment and selects its backing pods via 'spec.selector' matching the Deployment's pod template labels (e.g., app=my-deployment), so authoring a Service YAML with the correct selector is a valid declarative way to expose the Deployment. Option B is incorrect because 'spec.serviceName' is not a valid Deployment field; the closest concept, 'serviceName', belongs to StatefulSet's spec and is used for headless Service governance, not for exposing a Deployment.

Option C is incorrect because 'kubectl run' creates a new Pod (or with newer versions a Pod), not a Deployment, and '--expose' would expose that newly created resource rather than an existing Deployment. Option D is incorrect because a Deployment's manifest has no 'service' section; Services are separate API objects (kind: Service) and cannot be embedded in a Deployment spec.

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 →
13
Multi-Selectmedium

A platform engineer is troubleshooting a Pod stuck in the Pending state and wants to identify scheduling-related causes. Which two commands or outputs are most useful for diagnosing why the scheduler cannot place the Pod? (Choose two.)

Select 2 answers
A.kubectl get events --field-selector involvedObject.name=<pod-name>
B.kubectl get nodes and review the STATUS and Allocatable columns
C.kubectl describe pod <pod-name> and inspect the Events section
D.kubectl exec -it <pod-name> -- /bin/sh to inspect the node from inside
E.kubectl logs <pod-name> to read the container startup output
AnswersA, C

Filtering cluster events by the involved object name surfaces the same scheduler warnings and failure reasons in a time-ordered list, which is helpful when events have scrolled past the default kubectl describe output window. It confirms conditions such as FailedScheduling with the specific predicate that rejected each candidate node.

Why this answer

Scheduling failures are reported as events on the Pod object. Both kubectl describe pod and a field-selector-filtered kubectl get events expose FailedScheduling messages that name the blocking predicate, such as insufficient resources or an unsatisfied node affinity. Node listings and container logs or exec sessions cannot reveal scheduler decisions for a Pod that has never been bound to a node.

Exam trap

The trap here is reaching for kubectl logs or kubectl exec on a Pending Pod, when those commands require a running container and a Pending Pod has none.

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

A Job's controller tracks completions and retries failed pods until the specified count succeeds, then stops. Unlike a Deployment, which restarts pods indefinitely to maintain a desired replica count, a Job suits run-to-completion batch work.

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 runs as an agent on each worker node, watching the API server for pods scheduled to that node and restarting containers to match the pod spec. This directly satisfies the stem's requirement for the node component that keeps containers running 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 runs on each worker node, programming iptables or IPVS rules that translate Service virtual IPs into Pod endpoints. The kubelet manages container lifecycle, while the scheduler and controller manager run in the control plane, so neither enforces Service networking.

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

Rolling updates replace pods incrementally, respecting maxSurge and maxUnavailable, so the Deployment keeps serving traffic throughout the image change from 1.0 to 2.0. This satisfies the zero-downtime constraint directly, since Kubernetes creates new pods before terminating old ones rather than recreating all three at once.

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
MCQeasy

What is the smallest deployable unit in Kubernetes?

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

A Pod is the smallest deployable unit in Kubernetes, representing one or more containers that share a network namespace, storage volumes and lifecycle. Containers themselves are not scheduled independently; the scheduler places Pods onto nodes, making the Pod the atomic deployment unit.

Why this answer

A Pod is the smallest and simplest unit in the Kubernetes object model, representing a single instance of a running process in the cluster. It encapsulates one or more containers, shared storage, and a unique network IP, making it the atomic unit of scheduling and deployment.

Exam trap

The trap here is that candidates often confuse the smallest deployable unit (Pod) with the smallest runtime unit (Container), but Kubernetes always schedules and manages Pods, not individual containers.

How to eliminate wrong answers

Option B is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods, not the smallest deployable unit itself. Option C is wrong because a Node is a worker machine (physical or virtual) that hosts Pods, not a deployable object. Option D is wrong because a Container is the lowest-level runtime unit, but Kubernetes does not deploy containers directly; it always wraps them inside a Pod.

Practice this question →
19
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

Updating the Deployment's pod template spec with the new image triggers the Deployment controller to create a new ReplicaSet and gradually scale it up while scaling the old one down, performing a rolling update that maintains availability without downtime.

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 →
20
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

The `-o wide` flag extends the default table with extra columns, such as node name and pod IP, satisfying the requirement to display output in a different format. It remains a tabular, human-readable view rather than structured data, but Kubernetes documents it as a distinct output format alongside `-o json` and `-o yaml`.

Why this answer

Option B (-o wide) is correct because the -o wide output format extends the default table with additional columns such as node name, IP addresses, and nominated node, which is a documented kubectl output format. Option C (-o json) is correct because kubectl supports -o json to serialize the resource as a JSON object, useful for scripting and parsing with tools like jq. Option D (-o yaml) is correct because -o yaml renders the resource as YAML, another officially supported output format for kubectl get.

The unmarked options do not belong: -o verbose is not a valid output format (verbose logging is controlled by -v/--v), and --describe is not an output format but a separate kubectl subcommand (kubectl describe) that shows detailed human-readable information.

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 →
21
Multi-Selecthard

Which three of the following are valid ways to expose a service externally in Kubernetes? (Select THREE.)

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

Ingress exposes HTTP and HTTPS routes from outside the cluster to Services, satisfying the external-exposure constraint. An Ingress controller provides the actual entry point, routing by host or path rules rather than allocating a node port or cloud load balancer.

Why this answer

Ingress (A) is correct because it exposes HTTP/HTTPS services externally by routing traffic through an Ingress controller to internal ClusterIP services based on host/path rules. NodePort (C) is correct because it opens a static port (default range 30000–32767) on every node's IP, forwarding external traffic to the target service. LoadBalancer (D) is correct because it provisions an external load balancer (e.g., via a cloud provider) that distributes traffic to the service, typically building on NodePort and ClusterIP.

ExternalName (B) is not a way to expose a service externally; it merely creates a CNAME DNS alias to an external hostname without proxying traffic. ClusterIP (E) is incorrect because it only provides an internal virtual IP reachable within the cluster, not from outside.

Exam trap

The trap is that candidates often mistake ExternalName (option B) and ClusterIP (option E) as external exposure methods. ExternalName only creates a DNS alias within the cluster, while ClusterIP exposes the service only internally. Only Ingress, NodePort, and LoadBalancer are valid for external exposure.

Practice this question →
22
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

The control-plane taint repels pods lacking a matching toleration, so the scheduler will not place the workload there. Adding a toleration for node-role.kubernetes.io/control-plane with effect NoSchedule to the pod spec permits scheduling onto that 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 →
23
MCQhard

An administrator needs to grant a ServiceAccount in namespace 'dev' permission to list and watch Pods in the same namespace. Which combination of resources is required?

A.A Role and a RoleBinding in the 'dev' namespace
B.A ClusterRole and a RoleBinding in the 'dev' namespace
C.A ClusterRole and a ClusterRoleBinding
D.A Role and a ClusterRoleBinding
AnswerA

A Role defines permissions within a namespace, and a RoleBinding grants those permissions to a subject such as a ServiceAccount in that namespace. Since the requirement is limited to Pods in 'dev', a Role with verbs list and watch on pods, bound via RoleBinding, provides the necessary access without cluster-wide scope.

Why this answer

To grant a ServiceAccount permission to list and watch Pods in a single namespace, you create a Role in that namespace with the appropriate rules and bind it to the ServiceAccount using a RoleBinding. This follows the principle of least privilege, as the permissions are confined to the 'dev' namespace and do not extend cluster-wide.

Exam trap

The trap here is assuming a ClusterRoleBinding is needed for any RBAC grant, when namespaced permissions should use a Role and RoleBinding to avoid granting cluster-wide access.

Practice this question →
24
MCQeasy

A platform engineer is preparing a new cluster and wants each worker node to run a copy of a log-forwarding agent that must also run on control-plane nodes. Which Kubernetes workload resource should be used?

A.StatefulSet with podManagementPolicy: Parallel
B.Deployment with replicas equal to the number of nodes
C.CronJob with a schedule of every minute
D.DaemonSet
AnswerD

A DaemonSet ensures that a copy of a Pod runs on every eligible node in the cluster, including newly added nodes. Because the requirement is one log-forwarding agent per node, and it must tolerate control-plane taints, a DaemonSet with appropriate tolerations is the correct workload type.

Why this answer

A DaemonSet is the only workload controller that guarantees a Pod on every eligible node, which is exactly what a per-node log-forwarding agent requires. Deployments, StatefulSets, and CronJobs do not provide per-node placement semantics, so they cannot meet the requirement of running the agent on every worker and control-plane node.

Exam trap

The trap here is assuming that a Deployment with replicas equal to the node count will place one Pod per node, but Deployments do not guarantee per-node scheduling.

Practice this question →
25
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

A LoadBalancer Service provisions an external cloud load balancer and assigns a stable, externally reachable IP, satisfying the requirement to expose the application externally on a fixed port. Unlike NodePort, which opens a port on every node, it integrates directly with the cloud provider's load-balancing infrastructure.

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 →
26
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 runs as a DaemonSet on every node and programs iptables or IPVS rules, translating Service virtual IPs into Pod endpoints. This maintains the network rules enabling communication to Pods from network endpoints, exactly the responsibility the question describes.

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 →
27
MCQeasy

You want to view the logs of a running pod named 'my-pod'. Which kubectl command should you use?

A.kubectl exec my-pod -- cat /var/log/container.log
B.kubectl logs my-pod
C.kubectl get pod my-pod -o yaml
D.kubectl describe pod my-pod
AnswerB

`kubectl logs my-pod` retrieves stdout and stderr from the pod's container, satisfying the requirement to view a running pod's logs. It targets the pod by name directly, without needing a pod list, selector or exec session, which is the standard mechanism for reading container output in Kubernetes.

Why this answer

The `kubectl logs my-pod` command is the correct way to retrieve the standard output and standard error logs from a running pod in Kubernetes. It directly fetches the container logs from the kubelet, which are stored on the node and rotated by the container runtime (e.g., containerd or CRI-O). This is the dedicated command for log inspection, as defined in the Kubernetes CLI documentation.

Exam trap

The trap here is that candidates confuse `kubectl exec` with `kubectl logs`, thinking they need to manually cat a log file inside the container, when Kubernetes automatically captures stdout/stderr and provides a dedicated `kubectl logs` command for that purpose.

How to eliminate wrong answers

Option A is wrong because `kubectl exec my-pod -- cat /var/log/container.log` attempts to execute a command inside the container to read a log file, but the path `/var/log/container.log` is not a standard location for Kubernetes container logs; container logs are streamed to stdout/stderr and managed by the container runtime, not stored as a file at that path. Option C is wrong because `kubectl get pod my-pod -o yaml` outputs the pod's full YAML manifest, which includes metadata, spec, and status, but does not contain the container logs. Option D is wrong because `kubectl describe pod my-pod` shows detailed information about the pod's state, events, and conditions, but does not include the actual log output from the container.

Practice this question →
28
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 implements the Service abstraction by programming iptables, IPVS, or nftables rules on each node, directing traffic addressed to a Service's virtual IP toward the correct backend pods. This satisfies the stem's requirement for handling service traffic routing on worker nodes.

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 →
29
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 supplies a stable virtual IP and DNS name that front a dynamic set of pod IPs, distributing traffic across matching ready pods. This decouples clients from pod churn, delivering service discovery and load balancing.

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 →
30
MCQmedium

A Pod has been in 'Pending' state for an unusual amount of time. Which of the following is a likely cause?

A.The container image is invalid
B.The Pod's liveness probe is failing
C.The cluster does not have enough resources to schedule the Pod
D.The Service pointing to the Pod is misconfigured
AnswerC

Insufficient allocatable CPU or memory across nodes leaves the scheduler unable to bind the Pod, so it remains Pending indefinitely. This directly satisfies the stem's scheduling-failure constraint: the kube-scheduler cannot find a node meeting the Pod's resource requests, unlike image-pull or runtime errors that occur after binding.

Why this answer

A Pod stuck in 'Pending' state indicates that the Pod has been accepted by the API server but has not been scheduled to a node. The most common cause is insufficient cluster resources (CPU, memory, or ephemeral storage) across all nodes, preventing the scheduler from finding a suitable node that meets the Pod's resource requests. The scheduler continuously evaluates nodes using predicates and priorities, and if no node passes the predicates (e.g., NodeResourcesFit), the Pod remains Pending.

Exam trap

Kubernetes certification exams often test the distinction between Pod lifecycle phases (Pending vs. Running vs. CrashLoopBackOff) and the specific conditions that cause each state, tricking candidates into confusing post-scheduling issues (like image errors or probe failures) with pre-scheduling issues.

How to eliminate wrong answers

Option A is wrong because an invalid container image causes the Pod to transition to 'ImagePullBackOff' or 'ErrImagePull' after scheduling, not to remain in 'Pending' — the scheduler can still place the Pod on a node. Option B is wrong because a failing liveness probe affects a running container, causing restarts or 'CrashLoopBackOff', but the Pod must first be scheduled and running (i.e., in 'Running' state) for probes to execute. Option D is wrong because a misconfigured Service affects network connectivity to the Pod, not the Pod's scheduling or lifecycle state — the Pod would still be scheduled and run, but traffic would fail to reach it.

Practice this question →
31
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

A Service assigns a stable virtual IP and DNS name, then load-balances traffic to the selected Pods via kube-proxy. Pod IPs change on recreation, so clients address the Service instead, satisfying the requirement for stable access regardless of Pod churn.

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 →
32
MCQmedium

A user runs 'kubectl get pods -n production' and sees no output. What is the most likely reason?

A.The kube-apiserver is down
B.There are no pods in the 'production' namespace
C.The user does not have permissions to list pods
D.The namespace does not exist
AnswerB

An empty result from `kubectl get pods -n production` means the API server returned zero matching objects, not an error. Since the namespace exists and the query succeeded, the production namespace simply contains no pods, satisfying the stem's observation of no output.

Why this answer

`kubectl get pods -n production` returning no output typically indicates that there are no pods in the specified namespace. The command successfully connected to the API server, authenticated, and queried the namespace, but the result set is empty. This is a common scenario when a namespace exists but has no running or pending pods.

Exam trap

The trap here is that candidates often assume no output means a cluster or permission issue, but kubectl returns explicit error messages for connectivity, authorization, or resource-not-found problems, while an empty list is silently displayed.

How to eliminate wrong answers

Option A is wrong because if the kube-apiserver were down, kubectl would return a connection error (e.g., 'Unable to connect to the server') rather than no output. Option C is wrong because if the user lacked permissions to list pods, kubectl would return a Forbidden error (HTTP 403) with a message like 'Error from server (Forbidden): pods is forbidden'. Option D is wrong because if the namespace did not exist, kubectl would return an error like 'Error from server (NotFound): namespaces "production" not found'.

Practice this question →
33
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 512Mi limit triggers the kernel OOM killer, which terminates the container process rather than throttling it. Kubernetes then restarts the container per its restartPolicy, and repeated failures drive the Pod into CrashLoopBackOff. The memory limit, not the 256Mi request, is the binding constraint here.

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 →
34
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

`replicas` sits under `spec` and declares the desired number of Pod replicas the ReplicaSet should maintain, satisfying the question's requirement for a genuine apps/v1 Deployment field. It is a core scaling parameter, distinct from metadata or status, and is reconciled continuously by the Deployment controller to match observed state.

Why this answer

In an apps/v1 Deployment spec, the correct top-level fields include A. replicas, which declares the desired number of Pod replicas the ReplicaSet managed by the Deployment should maintain; B. template, which is the required PodTemplateSpec describing the Pods to be created; and C. selector, which is the required LabelSelector that must match the labels in the template and determines which Pods the Deployment manages. Options D and E are not valid Deployment spec fields: containers belongs inside the Pod template's spec (spec.template.spec.containers), not directly under the Deployment spec, and nodeName is a Pod-level scheduling field under spec.template.spec, not a Deployment spec field.

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 →
35
MCQmedium

You want to expose a set of pods running a web application on port 80 internally within the cluster, with a stable IP address, so that other services can reach them. Which Kubernetes resource should you create?

A.Service (ClusterIP)
B.Ingress
C.Deployment
D.Pod
AnswerA

A ClusterIP Service allocates a stable virtual IP reachable only inside the cluster, exactly matching the internal exposure requirement. Its kube-proxy rules load-balance traffic across the selected pods on port 80, so other services get a consistent address despite pod restarts or rescheduling.

Why this answer

A Service of type ClusterIP provides a stable virtual IP address and DNS name that load-balances traffic to a set of pods. Since the requirement is internal cluster access with a stable IP, ClusterIP is the correct choice — it exposes the pods on a cluster-internal IP that other services can reach reliably, without needing external exposure.

Exam trap

The trap here is that candidates often confuse Ingress with internal service exposure, thinking it provides a stable internal IP, when in fact Ingress only handles external routing and requires a Service underneath.

How to eliminate wrong answers

Option B (Ingress) is wrong because Ingress is designed for external HTTP/HTTPS traffic routing (e.g., host/path-based rules) and does not provide a stable internal IP; it requires a Service to route traffic to pods. Option C (Deployment) is wrong because a Deployment manages pod replicas and updates but does not provide a stable network endpoint or IP address — it needs a Service to expose the pods. Option D (Pod) is wrong because a Pod’s IP is ephemeral and changes on restart or rescheduling, so it cannot serve as a stable endpoint for other services.

Practice this question →
36
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

kubectl describe pod queries the API server for the pod's full status plus associated Events, showing container states, restart counts and scheduling messages. Unlike kubectl get, it surfaces the event stream needed to diagnose why a container is pending or crash-looping.

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 →
37
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

ClusterIP resolution depends on cluster DNS: kubelet points pods at the CoreDNS (or kube-dns) Service via resolv.conf. If those pods are down, the Service still has a stable IP and matching endpoints, yet the DNS name cannot resolve, producing the failure described.

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 →
38
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

A Kubernetes Job creates pods that run until successful completion, then stops — exactly matching the one-time batch requirement. Unlike a Deployment or ReplicaSet, which maintain a desired replica count and restart pods indefinitely, a Job's controller tracks completion and does not restart finished pods, satisfying the "run to completion and not be restarted" constraint.

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 →
39
MCQmedium

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

A.The apply succeeds but the change is silently ignored because Pods are managed by the kubelet.
B.The apply fails with an error indicating that the Pod spec is invalid or cannot be updated.
C.The existing Pod is patched in place and the container image is updated without restarting the Pod.
D.The Pod is deleted and recreated with the new image because Pods are immutable.
AnswerB

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

Why this answer

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

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

Exam trap

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

Practice this question →
40
Multi-Selecthard

Which three components are part of the Kubernetes control plane?

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

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

Why this answer

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

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

Exam trap

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

Practice this question →
41
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
42
Multi-Selectmedium

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

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

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

Why this answer

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

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

Exam trap

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

Practice this question →
43
MCQhard

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

A.The Pod's liveness probe has failed repeatedly and kubelet is restarting the container, which temporarily reports not ready.
B.The Pod has no resource requests, so the scheduler has not fully allocated CPU and the readiness gate remains closed.
C.The Pod is using a hostPath volume that is not writable, causing the readiness probe to fail at the filesystem level.
D.The readiness probe endpoint `/healthz` returns a non-2xx status code or times out, so kubelet marks the container as not ready.
AnswerD

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

Why this answer

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

Exam trap

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

Practice this question →
44
MCQmedium

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

A.configMap
B.hostPath
C.secret
D.emptyDir
AnswerB

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

Why this answer

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

Exam trap

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

Practice this question →
45
MCQmedium

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

A.Secret for both the settings and the credentials, consumed via environment variables.
B.ConfigMap for both, with the credentials stored in a separate key and mounted as a volume.
C.ConfigMap for the non-sensitive settings and Secret for the credentials, both consumed as volumes.
D.ConfigMap for the settings and a downward API volume for the credentials.
AnswerC

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

Why this answer

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

Exam trap

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

Practice this question →
46
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
47
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
48
Multi-Selectmedium

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

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

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

Why this answer

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

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

Exam trap

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

Practice this question →
49
Multi-Selecteasy

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

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

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

Why this answer

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

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

Exam trap

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

Practice this question →
50
Multi-Selectmedium

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

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

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

Why this answer

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

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

Exam trap

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

Practice this question →
51
MCQmedium

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

A.spec.containers[].command
B.spec.containers[].env.name
C.spec.containers[].volumeMounts
D.spec.containers[].envFrom
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
52
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
53
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
54
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
55
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
56
MCQmedium

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

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

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

Why this answer

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

Practice this question →
57
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
58
MCQmedium

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

A.kubectl logs web-1 --container app
B.kubectl logs web-1 -c app
C.kubectl logs app web-1
D.kubectl logs -p web-1 app
AnswerB

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
59
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

Practice this question →
60
MCQeasy

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
61
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
62
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
63
Multi-Selecthard

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

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

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

Why this answer

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

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

Exam trap

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

Practice this question →
64
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
65
MCQmedium

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

A.Create a ServiceAccount, bind it to a Role with a RoleBinding, and use the ServiceAccount token in the Pod.
B.Configure the Pod to use client certificate authentication with a certificate signed by the cluster CA.
C.Set the Pod's hostNetwork to true and use the node's kubelet credentials.
D.Use a static token file on the API server and mount it into the Pod.
AnswerA

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

Why this answer

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

Exam trap

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

Practice this question →
66
Multi-Selectmedium

Which THREE statements about Kubernetes Pods are correct?

Select 3 answers
A.Containers within a Pod cannot communicate with each other without using Services.
B.A Pod is the smallest deployable unit in Kubernetes.
C.A Pod always runs on a single node.
D.A Pod can contain multiple containers that share the same network namespace.
E.Pods are the most resilient unit in Kubernetes and automatically recover from failures.
AnswersB, C, D

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

Why this answer

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

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

Exam trap

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

Practice this question →
67
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
68
Multi-Selecthard

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

Select 3 answers
A.Creating a Service of type NodePort.
B.Creating a headless Service (clusterIP: None).
C.Creating an Ingress resource.
D.Creating a Deployment with a label selector.
E.Creating a Service of type ClusterIP.
AnswersA, C, E

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

Why this answer

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

Exam trap

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

Practice this question →
69
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

Declarative management: apply reconciles the live object against the YAML manifest, creating it if absent or patching changed fields if present. This satisfies the stem's requirement to both create and update from one file, unlike imperative create, which fails on an existing resource.

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 →
70
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 opens a static port on every cluster node, forwarding external traffic to the matched Pods via kube-proxy. This satisfies the stem's requirement to expose Pods externally without a cloud load balancer, unlike ClusterIP, which remains reachable only inside the cluster.

Why this answer

Option A (Create a Service of type NodePort) is correct because a NodePort Service allocates a port on every node's IP (default range 30000-32767) and forwards external traffic to the selected Pods, making it a valid way to expose Pods externally. Option D (Create a Service of type LoadBalancer) is correct because it provisions an external load balancer (via the cloud provider) that routes traffic to the Service's endpoints, thereby exposing the Pods to external clients. Option B is incorrect because a ConfigMap stores configuration data, not network routing, and cannot expose Pods.

Option C is incorrect because an Ingress resource requires a backing Service (typically ClusterIP) to route traffic to Pods; without a Service, it has no endpoints to forward to. Option E is incorrect because a ClusterIP Service only exposes Pods on an internal cluster IP, reachable only from within the cluster, not from external traffic.

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 →
71
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

A Job creates pods that run until successful completion, tracking completions and retries — exactly matching the one-time batch requirement. Unlike Deployments, which maintain a desired replica count indefinitely, or CronJobs, which schedule recurring runs, a Job's controller terminates once the specified completions succeed, satisfying the run-to-completion constraint.

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 →
72
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

kube-apiserver is the control plane's central REST front end: it validates and persists every object to etcd and is the only component all others talk to. It satisfies the control-plane criterion because it runs on the control plane, not on worker nodes.

Why this answer

The kube-apiserver (option D) is the central control plane component that exposes the Kubernetes API, validating and processing all REST requests and serving as the front end for the cluster's shared state in etcd. The kube-scheduler (option E) is also a control plane component, responsible for watching for newly created Pods with no assigned node and selecting an appropriate node based on resource requirements, affinity rules, and other constraints. By contrast, kube-proxy (A) runs on each node and maintains network rules for Service traffic, the kubelet (B) is a node agent that ensures containers described in PodSpecs are running, and the container runtime (C) is the software on each node that actually runs containers — all three are node components, not control plane components.

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 →
73
MCQhard

A team wants to run a database Pod that must be scheduled onto a node with an SSD and must not be evicted when the node comes under memory pressure. Which combination of fields should be configured in the Pod spec?

A.nodeAffinity with a disk-type match and resource requests equal to limits for memory
B.A taint on the database Pod and a matching toleration on the SSD nodes
C.nodeSelector with a disk-type label and a PriorityClass with a high value
D.A PodDisruptionBudget with minAvailable set to one and an emptyDir volume
AnswerA

nodeAffinity with a requiredDuringSchedulingIgnoredDuringExecution rule pins the Pod to SSD-labeled nodes, and setting memory requests equal to limits makes the Pod Guaranteed QoS. Guaranteed Pods are the last to be evicted when a node exceeds its memory eviction threshold, satisfying both the placement and eviction-resistance requirements.

Why this answer

Node placement is expressed through nodeSelector or nodeAffinity, and protection from kubelet eviction under resource pressure comes from the Pod's QoS class. Setting memory requests equal to limits yields Guaranteed QoS, which is evicted last. Taints, tolerations, PriorityClass, and PodDisruptionBudgets address different concerns and do not provide the required placement plus eviction resistance together.

Exam trap

The trap here is believing a high PriorityClass prevents eviction, when priority affects scheduling and preemption while QoS class determines eviction order under node pressure.

Practice this question →
74
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 Service type, allocating a virtual IP reachable only from within the cluster network. It satisfies the scenario's implicit constraint that no external exposure is requested, unlike NodePort or LoadBalancer, which additionally open host ports or provision cloud ingress.

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 →
75
MCQmedium

Which field in a Deployment YAML specifies the number of pod replicas?

A.spec.replicas
B.spec.template.spec.replicas
C.spec.replicaCount
D.spec.selector.matchLabels
AnswerA

The Deployment's pod template sits under spec.template, but the replica count is a direct child of spec, so spec.replicas declares how many identical pods the controller maintains. Setting it satisfies the stem's requirement for the field specifying pod replica numbers.

Why this answer

In a Kubernetes Deployment YAML, the `spec.replicas` field directly defines the desired number of pod replicas that the Deployment controller should maintain. This is a top-level field under the Deployment spec, not nested under `template.spec`, because the replica count is a property of the Deployment itself, not of the Pod template.

Exam trap

The trap here is that candidates confuse the Deployment's `spec.replicas` with the Pod template's `spec` section, or they misremember the field name as `replicaCount` due to exposure to Helm chart conventions or other orchestration tools.

How to eliminate wrong answers

Option B is wrong because `spec.template.spec.replicas` is not a valid field; the `spec.template` section defines the Pod template, and Pods themselves do not have a `replicas` field — that concept belongs to higher-level controllers like Deployments or ReplicaSets. Option C is wrong because `spec.replicaCount` is not a Kubernetes API field; the correct field name is `replicas`, not `replicaCount`, which is a common naming convention in Helm charts but not in native Kubernetes YAML. Option D is wrong because `spec.selector.matchLabels` is used to define the label selector that the Deployment uses to identify which Pods it manages, not to specify the number of replicas.

Practice this question →
Page 1 of 6 · 400 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Kubernetes Fundamentals questions.

Start 20-question session