CCNA Kubernetes Fundamentals Questions — Page 5 of 5

301

MCQmedium

You have a Deployment named 'web-app' with 3 replicas. You need to scale it to 5 replicas. Which kubectl command should you use?

A.kubectl create deployment web-app --replicas=5

B.kubectl scale deployment web-app --replicas=5

C.kubectl edit deployment web-app --replicas=5

D.kubectl describe deployment web-app

AnswerB

The scale command changes the replica count of the deployment.

Why this answer

The `kubectl scale` command is the correct way to adjust the replica count of an existing Deployment. It directly modifies the `spec.replicas` field in the Deployment's desired state, instructing the ReplicaSet controller to create or delete Pods to match the new count. Option B uses the correct syntax `kubectl scale deployment web-app --replicas=5` to achieve this.

Exam trap

The trap here is that candidates confuse `kubectl create` with `kubectl scale`, thinking they can reuse the create command with a different replica count to update an existing Deployment, when in fact `create` is only for initial creation and will fail or overwrite the resource.

How to eliminate wrong answers

Option A is wrong because `kubectl create deployment` creates a new Deployment from scratch, not scaling an existing one; using `--replicas=5` would create a new Deployment named 'web-app' (or fail if it already exists), overwriting the original configuration and ignoring the existing 3 replicas. Option C is wrong because `kubectl edit deployment` opens an interactive editor for manual YAML/JSON modification, not a direct scaling command; the `--replicas` flag is not valid with `edit`, and the user would need to manually change the `spec.replicas` field, which is inefficient and error-prone. Option D is wrong because `kubectl describe deployment` only displays the current state and details of the Deployment, including its replica count, but does not perform any scaling action.

Practice this question →

302

MCQhard

A Pod is in 'CrashLoopBackOff' state. You run 'kubectl logs <pod>' and see an error that the application cannot bind to port 8080 because the port is already in use. What is the most likely cause?

A.The container's health check is misconfigured

B.The container runtime is not installed

C.The Pod's resource limits are too low

D.Another process inside the container is already using port 8080

AnswerD

If the application or another process occupies the port, the app cannot bind.

Why this answer

The 'CrashLoopBackOff' state indicates the container repeatedly starts, fails, and is restarted by the kubelet. The error message 'port is already in use' means the application inside the container cannot bind to port 8080 because another process within the same container's network namespace is already listening on that port. This is a classic application-level conflict, not a Kubernetes configuration issue.

Exam trap

The trap here is that candidates may confuse a container-level port conflict with a Kubernetes-level port conflict (e.g., hostPort or NodePort collision), but the error originates from inside the container's own network namespace, not from the host or cluster networking layer.

How to eliminate wrong answers

Option A is wrong because a misconfigured health check (e.g., liveness or readiness probe) would cause the Pod to be restarted due to probe failures, but the specific error 'port is already in use' is not a probe-related message; it is a bind system call failure. Option B is wrong because if the container runtime were not installed, the Pod would never reach the 'Running' state, let alone 'CrashLoopBackOff'; the kubelet would fail to start the container entirely. Option C is wrong because insufficient resource limits (CPU/memory) would cause the container to be OOMKilled or throttled, resulting in 'OOMKilled' or 'CrashLoopBackOff' with resource-related errors, not a 'port already in use' bind error.

Practice this question →

303

MCQmedium

You have a pod that needs to securely access a database password. Which Kubernetes resource should you use to store the password?

A.ServiceAccount

B.Secret

C.ConfigMap

D.PersistentVolume

AnswerB

Secrets store sensitive data and are base64 encoded.

Why this answer

A Kubernetes Secret is specifically designed to store sensitive data, such as database passwords, in a base64-encoded format. Secrets can be mounted as volumes or exposed as environment variables in a pod, ensuring the password is not stored in plaintext in the pod specification or container image.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming both can store sensitive data, but ConfigMaps store data in plaintext and lack the security features of Secrets, such as encryption at rest and RBAC controls.

How to eliminate wrong answers

Option A is wrong because a ServiceAccount is an identity for processes running in a pod, used for authentication to the Kubernetes API server, not for storing sensitive data like passwords. Option C is wrong because a ConfigMap is intended for non-confidential configuration data, such as environment variables or configuration files, and does not provide encryption or security for sensitive values. Option D is wrong because a PersistentVolume is a storage resource for persistent data in a cluster, not a mechanism for storing secrets or passwords.

Practice this question →

304

Multi-Selecthard

Which three of the following are true about etcd in Kubernetes?

Select 3 answers

A.etcd stores all cluster state, including Pods, ConfigMaps, and Secrets

B.etcd is a relational database

C.etcd is a distributed, consistent key-value store

D.etcd can be used as a message queue

E.etcd supports watches to monitor changes to keys

AnswersA, C, E

etcd is the backing store for all cluster data.

Why this answer

Etcd is the primary datastore for Kubernetes, storing all cluster state including objects like Pods, ConfigMaps, and Secrets. This ensures that the Kubernetes API server has a consistent, authoritative source of truth for the entire cluster.

Exam trap

The trap here is that candidates may confuse etcd's watch functionality with message queuing, or incorrectly assume that any database with key-value storage is relational, leading them to select options B or D.

Practice this question →

305

Multi-Selectmedium

Which TWO statements about Kubernetes Services are correct?

Select 2 answers

A.A Service can expose only one container port

B.A Service can only route traffic to pods on the same node as the Service

C.The default Service type is ClusterIP

D.A Service provides a stable IP address and DNS name for a set of pods

E.A Service of type NodePort exposes the service only on the node where the pod is running

AnswersC, D

If no type is specified, ClusterIP is used.

Why this answer

The default Service type in Kubernetes is ClusterIP, which exposes the Service on a cluster-internal IP address. This means the Service is only reachable from within the cluster, providing a stable internal endpoint for pod-to-pod communication without external exposure.

Exam trap

The KCNA exam often tests the misconception that a Service can only expose one port or that NodePort is node-specific, when in fact multiple ports are supported and NodePort opens the port on every node in the cluster.

Practice this question →

306

MCQmedium

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

A.It ensures the desired number of pods are running

B.It runs the container runtime

C.It reports node status to the control plane

D.It implements part of the Kubernetes Service concept by managing network rules

AnswerD

kube-proxy handles IP tables/IPVS rules for service load balancing.

Why this answer

kube-proxy runs on each worker node and is responsible for implementing the Kubernetes Service abstraction by managing network rules (e.g., iptables, IPVS, or userspace mode). It watches the API server for Service and EndpointSlice changes and configures local packet filtering or forwarding rules to route traffic to the correct backend pods, enabling load balancing and service discovery.

Exam trap

A common misconception is that kube-proxy handles pod lifecycle or node health reporting, when in fact those are kubelet responsibilities. Candidates often confuse the 'proxy' name with general node management.

How to eliminate wrong answers

Option A is wrong because ensuring the desired number of pods are running is the function of the ReplicaSet controller and the kubelet, not kube-proxy. Option B is wrong because running the container runtime (e.g., containerd, CRI-O) is the responsibility of the kubelet, which interacts with the CRI, while kube-proxy handles network proxying. Option C is wrong because reporting node status to the control plane is a core function of the kubelet, which sends NodeStatus updates via the Kubernetes API, not kube-proxy.

Practice this question →

307

MCQhard

A pod has resource requests set to 'cpu: 500m' and 'memory: 256Mi'. The node has 2 CPU cores and 4Gi memory. How many pods with the same resource requests can be scheduled on that node, assuming no other pods?

A.2

B.4

C.8

D.16

AnswerB

CPU is the bottleneck; 2000m / 500m = 4.

Why this answer

Each pod requests 0.5 CPU cores (500m) and 256 MiB of memory. The node has 2 CPU cores, so the CPU limit allows 2 / 0.5 = 4 pods. The node has 4 GiB of memory (4096 MiB), so the memory limit allows 4096 / 256 = 16 pods.

The tighter constraint is CPU, which permits exactly 4 pods. Option B is correct.

Exam trap

Candidates often mistakenly calculate the maximum number of pods based on memory (16) instead of CPU (4), since memory appears less restrictive. However, CPU is the tighter constraint in this scenario.

How to eliminate wrong answers

Option A is wrong because it assumes only 2 pods can fit, likely confusing the 2 CPU cores with the number of pods without dividing by the per-pod request of 500m. Option C is wrong because 8 pods would require 8 * 500m = 4 CPU cores, which exceeds the node's 2 cores. Option D is wrong because 16 pods would require 16 * 500m = 8 CPU cores, far beyond the node's capacity, even though memory alone could support 16 pods.

Practice this question →

308

MCQmedium

You need to securely store a database password for use by a Pod. Which Kubernetes resource should you use?

A.Secret

B.PersistentVolumeClaim

C.ServiceAccount

D.ConfigMap

AnswerA

Secrets are intended for sensitive information.

Why this answer

A Secret is the correct Kubernetes resource for storing sensitive data like database passwords because it encodes the value in base64 and can be mounted as a volume or injected as an environment variable into a Pod. Unlike ConfigMaps, Secrets are designed for confidential information and support optional encryption at rest when enabled in the cluster. This ensures the password is not stored in plaintext in the Pod specification or version control.

Exam trap

CNCF often tests the misconception that ConfigMaps are suitable for all configuration data, including sensitive values, but the KCNA exam expects you to know that Secrets are the dedicated resource for confidential information like passwords and API keys.

How to eliminate wrong answers

Option B (PersistentVolumeClaim) is wrong because it is used to request storage volumes for Pods, not to store sensitive configuration data like passwords. Option C (ServiceAccount) is wrong because it provides an identity for Pods to authenticate with the Kubernetes API server, not a mechanism for storing secrets. Option D (ConfigMap) is wrong because it is intended for non-sensitive configuration data; storing a password in a ConfigMap would expose it in plaintext and violate security best practices.

Practice this question →

309

Multi-Selectmedium

Which TWO of the following are characteristics of a Namespace in Kubernetes?

Select 2 answers

A.Namespaces are required for all Kubernetes objects

B.Namespaces provide network isolation by default

C.Resource names must be unique within a namespace, but can be reused across namespaces

D.Namespaces allow multiple virtual clusters within a physical cluster

E.Deleting a namespace deletes all objects inside it

AnswersC, D

Correct. Kubernetes enforces unique names only within the same namespace. This allows names like 'my-app' to be reused across different namespaces (e.g., dev and prod), providing naming flexibility without collisions.

Why this answer

Namespaces in Kubernetes provide a mechanism for logical grouping and scoping of resources. Two key characteristics are: (1) resource names must be unique within a namespace but can be reused across different namespaces (option C), and (2) namespaces allow multiple virtual clusters (logical clusters) within a single physical cluster (option D). While deleting a namespace does delete all its contained objects (option E), this is a consequence of namespace lifecycle management rather than a defining characteristic of what a namespace is.

Network isolation is not provided by default; it requires explicit NetworkPolicy resources.

Exam trap

CNCF often tests the misconception that Namespaces provide built-in network isolation, but in reality, they only offer logical grouping; network segmentation requires explicit NetworkPolicy resources.

Practice this question →

310

MCQhard

A pod in the 'default' namespace has the following YAML snippet: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 What is the effect of the fsGroup field?

A.It restricts the pod to run only on nodes with that group ID.

B.It sets the group ID for any volumes mounted into the pod.

C.It defines the group ID for the pod's service account.

D.It sets the group ID for the container's main process.

AnswerB

fsGroup changes the group ownership of volumes and any files created in them.

Why this answer

The `fsGroup` field in a Pod's security context sets the group ID (GID) that will be used for ownership of any volumes mounted into the pod. When a volume is mounted, Kubernetes recursively changes the group ownership of the volume's files to the specified GID (2000 in this case) and makes them readable and writable by that group. This ensures that processes running in the container, which may have a different primary group (3000 from `runAsGroup`), can still access the volume files if they are members of the fsGroup.

Exam trap

A common trap is confusing the role of `runAsGroup` (which sets the primary GID of the container process) with `fsGroup` (which sets the group ownership of mounted volumes), leading candidates to incorrectly select option D.

How to eliminate wrong answers

Option A is wrong because `fsGroup` does not restrict pod scheduling to nodes with a specific group ID; node affinity or taints/tolerations control node selection. Option C is wrong because the pod's service account group ID is unrelated to `fsGroup`; service accounts are managed via Kubernetes RBAC and do not have a group ID field in the security context. Option D is wrong because the group ID for the container's main process is set by `runAsGroup`, not `fsGroup`; `fsGroup` only affects volume file ownership, not the process's GID.

Practice this question →

311

Multi-Selectmedium

Which TWO of the following are valid ways to assign a pod to a specific node?

Select 2 answers

A.nodeSelector

B.affinity: nodeAntiAffinity

C.tolerations

D.nodeName

E.podSelector

AnswersA, D

Node selector uses labels to match nodes.

Why this answer

`nodeSelector` is a simple, built-in field in the Pod spec that matches the pod to nodes with specific labels. When you add a `nodeSelector` with a key-value pair, the scheduler only places the pod on nodes that have that exact label. This is the most straightforward way to constrain a pod to a subset of nodes.

Exam trap

CNCF often tests the distinction between mechanisms that *constrain* scheduling (like nodeSelector and nodeAffinity) versus mechanisms that *permit* scheduling (like tolerations), and candidates mistakenly think tolerations can force a pod to a specific node when they only allow it to be scheduled on tainted nodes.

Practice this question →

312

Multi-Selectmedium

Which two of the following are true about ConfigMaps? (Select TWO.)

Select 2 answers

A.ConfigMaps are automatically encrypted at rest

B.ConfigMaps are namespace-scoped

C.ConfigMaps can hold binary data

D.ConfigMaps can be mounted as volumes or exposed as environment variables

E.ConfigMaps are used to store sensitive configuration data

AnswersB, D

Correct. ConfigMaps are namespace-scoped, meaning they exist within a specific namespace and are only accessible to pods in that namespace.

Why this answer

ConfigMaps are namespace-scoped objects (B) and can be mounted as volumes or exposed as environment variables (D).

Exam trap

CNCF often tests the distinction between ConfigMaps and Secrets, specifically that ConfigMaps are for non-sensitive, plaintext data and are not encrypted by default, while Secrets are intended for sensitive data and have optional encryption at rest.

Practice this question →

313

MCQhard

You run 'kubectl logs my-pod' and see: "Error from server (BadRequest): container "my-container" in pod "my-pod" is waiting to start: PodInitializing". What does this mean?

A.The container is running but producing no output

B.The container runtime is failing to start the container

C.The container has crashed and is restarting

D.The Pod is in the process of initializing and logs are not yet available

AnswerD

PodInitializing means the container hasn't started yet.

Why this answer

The error 'PodInitializing' indicates that the pod's init containers are still running or the main container is waiting for init containers to complete. During this phase, the container has not started, so logs are not yet available. Option D correctly identifies that the pod is initializing and logs cannot be retrieved until the container enters the 'Running' state.

Exam trap

The trap here is that candidates confuse 'PodInitializing' with a container runtime failure or crash loop, when in fact it is a normal waiting state caused by init containers or pod initialization, not an error condition.

How to eliminate wrong answers

Option A is wrong because 'PodInitializing' means the container has not started, so it cannot be running or producing output. Option B is wrong because the error does not indicate a runtime failure; it simply means the container is waiting to start, which is a normal part of the pod lifecycle when init containers are executing. Option C is wrong because a crash loop would show 'CrashLoopBackOff' or 'Error' status, not 'PodInitializing', which is a transient state before the container starts.

Practice this question →

314

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Delete the namespace and redeploy all workloads

B.Increase the memory limit in the pod's container resource specification

C.Increase the CPU request for the container

D.Delete and recreate the pod to clear the crash loop

AnswerB

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

The pod is in CrashLoopBackOff with an OOMKilled message, which means the container was terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it exceeded its memory limit. Increasing the memory limit in the container's resource specification allows the container to use more memory before being killed, directly addressing the root cause.

Exam trap

Candidates often confuse resource requests and limits in Kubernetes. They may mistakenly increase the CPU request instead of the memory limit, or think that simply restarting the pod will resolve an OOMKilled error. However, the root cause is an exceeded memory limit, so the correct fix is to increase the memory limit in the container's resource specification.

How to eliminate wrong answers

Option A is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not fix the underlying memory constraint; the same OOMKilled error would recur. Option C is wrong because increasing the CPU request does not affect memory allocation; the OOM killer is triggered by memory usage, not CPU. Option D is wrong because deleting and recreating the pod only restarts the container with the same memory limit, so it will be OOMKilled again once memory usage spikes.

Practice this question →

315

MCQmedium

A.Increase the memory limit in the pod's container resource specification

B.Increase the CPU request for the container

C.Delete the namespace and redeploy all workloads

D.Delete and recreate the pod to clear the crash loop

AnswerA

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

The 'OOMKilled' status indicates the pod's container was terminated by the Linux kernel Out-of-Memory (OOM) killer because it exceeded its configured memory limit. Since the pod ran successfully for days, this suggests a gradual memory leak or increased workload demand. Increasing the memory limit in the pod's container resource specification allows the container to use more memory before being killed, directly addressing the root cause.

Exam trap

The trap here is that candidates may confuse 'OOMKilled' with a general crash and choose to delete/recreate the pod, not realizing the memory limit must be adjusted to prevent recurrence.

How to eliminate wrong answers

Option B is wrong because increasing the CPU request does not affect memory consumption or prevent OOM kills; CPU and memory are independent resources in Kubernetes. Option C is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not fix the underlying memory limit issue and would cause unnecessary downtime. Option D is wrong because deleting and recreating the pod only restarts the container with the same memory limit, so it will likely be OOMKilled again when memory usage spikes.

Practice this question →

316

MCQmedium

Which of the following is NOT a responsibility of the kubelet on a worker node?

A.Performing liveness and readiness probes

B.Starting and stopping containers based on PodSpecs

C.Implementing network rules for Services

D.Reporting node and pod status to the control plane

AnswerC

Network rules and service load balancing are handled by kube-proxy, not kubelet.

Why this answer

The kubelet is the primary node agent that runs on each worker node, responsible for ensuring containers are running in a Pod as specified by the PodSpec. It performs liveness and readiness probes, starts and stops containers, and reports node and pod status to the control plane. Implementing network rules for Services, such as iptables or IPVS rules, is the responsibility of the kube-proxy, not the kubelet.

Exam trap

The trap here is that candidates often confuse the kubelet's role with kube-proxy's role, assuming the kubelet handles all networking on the node, including Service traffic routing.

How to eliminate wrong answers

Option A is wrong because the kubelet is responsible for executing liveness and readiness probes against containers and taking action based on their results (e.g., restarting containers). Option B is wrong because the kubelet directly manages container lifecycle by communicating with the container runtime (e.g., containerd, CRI-O) to start and stop containers as defined in the PodSpec. Option D is wrong because the kubelet periodically reports the node's condition and the status of each Pod to the API server via the NodeStatus and PodStatus updates.

Practice this question →

317

Multi-Selecteasy

Which TWO components are part of a Kubernetes worker node?

Select 2 answers

A.kubelet

B.kube-scheduler

C.container runtime

D.kube-proxy

E.etcd

AnswersA, D

kubelet runs on each node and ensures containers are running as specified.

Why this answer

The kubelet is the primary node agent that runs on every worker node. It registers the node with the cluster, receives Pod specifications from the API server, and ensures that the containers described in those Pods are running and healthy. Without the kubelet, a node cannot participate in the cluster as a worker.

Exam trap

CNCF often tests the distinction between control plane and worker node components, and the trap here is that candidates mistakenly include the container runtime as a 'Kubernetes component' when it is actually a third-party dependency, or they confuse kube-scheduler as a worker node component because it deals with Pod placement.

Practice this question →

318

MCQeasy

A Pod has a container that needs to write logs to a file. The administrator wants the logs to persist even if the container restarts. What is the simplest solution?

A.Use a PersistentVolumeClaim for each container.

B.Use a hostPath volume to write logs directly to the node filesystem.

C.Store logs in a ConfigMap.

D.Use an emptyDir volume and mount it at the log path.

AnswerD

emptyDir volumes share the Pod's lifetime and persist across container restarts within the same Pod.

Why this answer

An emptyDir volume provides a simple, ephemeral storage solution that persists across container restarts within the same Pod. When a container crashes and is restarted by the kubelet, the emptyDir volume's contents remain intact, allowing log files to survive container restarts without requiring external storage or complex configuration.

Exam trap

CNCF often tests the misconception that container restarts always wipe all data, leading candidates to choose persistent storage options like PVCs or hostPath, when in fact emptyDir volumes are specifically designed to survive container restarts within the same Pod.

How to eliminate wrong answers

Option A is wrong because a PersistentVolumeClaim (PVC) is designed for durable, long-term storage that survives Pod deletion and rescheduling, which is overkill for simple log persistence across container restarts and adds unnecessary complexity. Option B is wrong because a hostPath volume ties the Pod to a specific node and poses security risks (e.g., allowing container access to the host filesystem), and it is not the simplest solution for log persistence within a Pod. Option C is wrong because a ConfigMap is intended for storing configuration data (e.g., key-value pairs, small files) and is not designed for dynamic, writable log output; ConfigMaps are read-only when mounted and cannot be written to by containers.

Practice this question →

319

MCQmedium

A developer deploys a pod with the following resource specification: ```yaml resources: requests: memory: "256Mi" limits: memory: "512Mi" ``` The pod is killed with OOMKilled. What is the most likely cause?

A.The container exceeded the memory request of 256Mi

B.The node ran out of memory

C.The CPU limit was too low

D.The container exceeded the memory limit of 512Mi

AnswerD

OOMKilled indicates the container exceeded its memory limit.

Why this answer

The OOMKilled exit code indicates the container was terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it attempted to use more memory than its configured limit of 512Mi. Kubernetes enforces memory limits using cgroups; when the container exceeds the limit, the kernel kills the process, resulting in the OOMKilled status.

Exam trap

CNCF often tests the distinction between requests and limits, trapping candidates who think exceeding a request causes termination, when in fact only exceeding the limit triggers OOMKilled.

How to eliminate wrong answers

Option A is wrong because exceeding the memory request of 256Mi does not cause termination; requests are used for scheduling and guaranteed QoS, not enforcement. Option B is wrong because node memory exhaustion would cause the node to evict pods or the OOM killer to target pods, but the pod's explicit memory limit is the direct cause here, not node-level pressure. Option C is wrong because CPU limits do not cause OOMKilled; CPU is a compressible resource, and exceeding CPU limits results in throttling, not termination.

Practice this question →

320

MCQeasy

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

A.kube-scheduler

B.kube-controller-manager

C.kube-apiserver

D.etcd

AnswerC

The API server exposes the Kubernetes API and is the primary management entry point.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the sole entry point for all administrative operations. It exposes the Kubernetes REST API, validates and processes requests (including authentication, authorization, and admission control), and updates the corresponding objects in etcd. Without the API server, no kubectl command, automation, or internal component communication can occur.

Exam trap

CNCF often tests the misconception that etcd is the primary entry point because it stores all cluster data, but the trap here is that etcd is a data store, not an API endpoint — all interactions must go through the kube-apiserver, which is the only component that communicates directly with etcd.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible only for assigning newly created pods to nodes based on resource requirements and policies, not for serving the API or handling administrative tasks. Option B is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that watch the desired state via the API server, but it does not expose an API endpoint itself. Option D is wrong because etcd is a distributed key-value store used as Kubernetes' backing store for all cluster data, but it is not the entry point for administrative tasks and does not serve the Kubernetes API.

Practice this question →

321

Multi-Selectmedium

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

Select 2 answers

A.Assigning pods to nodes based on resource requirements

B.Ensuring the correct number of pod replicas are running

C.Implementing network rules for Services

D.Monitoring node health and responding to node failures

E.Storing the cluster state

AnswersB, D

The Replication Controller ensures the desired number of replicas.

Why this answer

The kube-controller-manager runs controller processes that regulate the state of the cluster. The ReplicaSet controller, which runs inside the kube-controller-manager, is responsible for ensuring that the desired number of pod replicas are running at all times, creating or deleting pods as necessary to match the specified replica count.

Exam trap

The trap here is that candidates often confuse the kube-controller-manager's role in node health monitoring with the kube-scheduler's role in pod placement, or they mistakenly think the controller-manager handles network rules, which is actually done by kube-proxy.

Practice this question →

322

MCQmedium

A Deployment is configured with 'replicas: 4' and 'strategy.type: RollingUpdate'. You update the container image. What behavior does the Deployment exhibit?

A.The Deployment creates 8 Pods total, 4 old and 4 new

B.All 4 Pods are deleted immediately and then 4 new Pods are created

C.New Pods are created before old ones are terminated, one at a time

D.The update is paused until manually resumed

AnswerC

RollingUpdate replaces Pods incrementally.

Why this answer

With a RollingUpdate strategy, the Deployment controller replaces old Pods with new ones incrementally to ensure zero downtime. By default, it creates new Pods before terminating old ones (maxSurge=25%, maxUnavailable=25%), so one new Pod is created first, then one old Pod is terminated, repeating until all 4 Pods run the new image.

Exam trap

The trap here is that candidates confuse RollingUpdate with Recreate (Option B) or assume all Pods are replaced simultaneously (Option A), failing to recognize the incremental, surge-based behavior controlled by maxSurge and maxUnavailable defaults.

How to eliminate wrong answers

Option A is wrong because a RollingUpdate does not create 8 Pods simultaneously; it creates at most 1 extra Pod (maxSurge=25% of 4 = 1) beyond the desired 4, so the total is 5, not 8. Option B is wrong because deleting all Pods immediately is a Recreate strategy, not RollingUpdate, which would cause downtime. Option D is wrong because the update is not paused; a paused update requires explicitly setting 'paused: true' in the Deployment spec, which is not mentioned in the question.

Practice this question →

323

MCQmedium

You want to update a Deployment's container image to v2 and perform a rolling update using the simplest imperative command. Which kubectl command achieves this?

A.kubectl update deployment my-deployment --image=myapp:v2

B.kubectl replace -f updated-deployment.yaml

C.kubectl patch deployment my-deployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"my-container","image":"myapp:v2"}]}}}}'

D.kubectl set image deployment/my-deployment my-container=myapp:v2 --record

AnswerD

`kubectl set image` directly updates the container image for a specific container and initiates a rolling update; adding `--record` annotates the change for rollback history.

Why this answer

The `kubectl set image` command is the standard imperative way to update a container image in a Deployment, and it automatically triggers a rolling update. Option A is invalid; `kubectl update` is not a real command. Option B, `kubectl replace`, requires a full YAML file and is a declarative replacement operation, not a simple image update command.

Option C, `kubectl patch`, can be used but is overly complex and error-prone for a simple image update. The question asks for the simplest imperative command, making D the best answer.

Exam trap

A common pitfall is assuming that `kubectl update` is a valid command (it is not) or that `kubectl patch` is the simplest approach. While `kubectl patch` can update the image, it is not the simplest or most direct imperative command for this task.

How to eliminate wrong answers

Option A is wrong because `kubectl update` is not a valid kubectl command; the correct imperative command for updating a Deployment's image is `kubectl set image`. Option B is wrong because `kubectl replace -f updated-deployment.yaml` performs a full replacement of the Deployment object, which is a declarative approach that does not inherently trigger a rolling update; it replaces the entire resource definition, potentially causing downtime if not managed carefully. Option C is wrong because while `kubectl patch` can update the container image, it requires a complex JSON patch and does not automatically trigger a rolling update unless the patch modifies the pod template spec; however, it is less straightforward and not the recommended imperative command for this specific task.

Practice this question →

324

MCQmedium

A Service of type ClusterIP is created to expose a set of pods. How does the Service achieve load balancing to the pods?

A.The API server routes traffic directly to the pods

B.The kube-proxy component on each node sets up network rules to forward traffic to the pods

C.The kubelet configures the container runtime to route traffic

D.Using a cloud load balancer

AnswerB

kube-proxy handles the implementation of ClusterIP Services.

Why this answer

Kube-proxy on each node implements load balancing for ClusterIP Services by creating iptables or IPVS rules that distribute traffic from the Service's virtual IP to the backend pods. These rules use a random or round-robin selection (depending on the mode) to forward packets to healthy pods, ensuring no single pod is overwhelmed.

Exam trap

A common trap is confusing the control-plane role of the API server with the data-plane role of kube-proxy. The API server does not handle data-plane traffic for Services.

How to eliminate wrong answers

Option A is wrong because the API server does not handle data-plane traffic; it only manages the control plane and stores Service definitions in etcd, while actual packet forwarding is done by kube-proxy. Option C is wrong because kubelet is responsible for managing pod lifecycle and container runtime configuration, not for setting up network routing rules for Services. Option D is wrong because a cloud load balancer is used for Services of type LoadBalancer, not ClusterIP, which is an internal virtual IP only reachable within the cluster.

Practice this question →

325

Multi-Selectmedium

Which two of the following are Kubernetes controllers that run inside the kube-controller-manager? (Select TWO)

Select 2 answers

A.kubelet

B.Replication controller

C.etcd

D.Node controller

E.kube-scheduler

AnswersB, D

Ensures correct number of pod replicas.

Why this answer

The kube-controller-manager is a control plane component that runs controller processes to regulate the state of the cluster. The Replication controller (option B) is a legacy controller that ensures a specified number of pod replicas are running at all times, and the Node controller (option D) is responsible for monitoring the health of nodes and managing node lifecycle events. Both are built-in controllers that run inside the kube-controller-manager binary.

Exam trap

The exam often tests the distinction between control plane components (kube-controller-manager, kube-scheduler, etcd) and node agents (kubelet). Many candidates mistakenly think kubelet is a controller because it manages pods locally, but it runs on each node as a separate binary, not inside the kube-controller-manager.

Practice this question →

326

Multi-Selectmedium

Which TWO of the following are valid methods for exposing a Service externally?

Select 2 answers

A.ExternalName

B.Ingress

C.LoadBalancer

D.ClusterIP

E.NodePort

AnswersC, E

LoadBalancer provisions an external load balancer.

Why this answer

(LoadBalancer) is correct because it provisions an external load balancer (e.g., AWS ELB, GCP TCP LB) that assigns a public IP address to the Service, making it accessible from outside the cluster. Option E (NodePort) is correct because it exposes the Service on a static port (30000–32767) on every Node's IP, allowing external traffic to reach the Service via `<NodeIP>:<NodePort>`. Both are valid Service types in Kubernetes for external exposure.

Exam trap

The trap here is that candidates often confuse Ingress as a Service type or think ExternalName provides external access, when in fact Ingress is a separate resource and ExternalName is purely a DNS alias with no proxying or port exposure.

Practice this question →