Certified Kubernetes Application Developer CKAD CKAD Questions 676–750 | Page 10/12

676

MCQhard

An administrator creates a Pod with an ephemeral container using 'kubectl debug my-pod -it --image=busybox --target=my-container'. The ephemeral container shares the same process namespace as the target container. Which flag enables this?

A.--target

B.--container

C.--namespace

D.--share-process-namespace

AnswerA

--target is the correct flag because it tells kubectl debug which container within the target Pod should serve as the namespace source for the ephemeral container. Without --target, the ephemeral container is created with its own network and process namespaces, so it cannot see the processes or network interfaces of other containers, severely limiting debugging. The flag's value must match a container name in the Pod spec, and it is supported only in kubectl debug, not in kubectl exec.

Why this answer

The `--target` flag in `kubectl debug` specifies the target container within the Pod for the ephemeral container. When used, the ephemeral container shares the same process namespace as the target container, allowing tools like `ps` to see processes from the target container. This is essential for debugging scenarios where you need to inspect or interact with the target container's processes.

Exam trap

The CKAD exam often tests the distinction between Pod-level process namespace sharing (via `shareProcessNamespace` in the Pod spec) and the ephemeral container's `--target` flag, leading candidates to mistakenly choose `--share-process-namespace` when the question specifically asks about `kubectl debug`.

How to eliminate wrong answers

Option B is wrong because `--container` is used to specify the container name when attaching or executing commands in a Pod, not to enable process namespace sharing with an ephemeral container. Option C is wrong because `--namespace` is a kubectl flag for specifying the Kubernetes namespace of the resource, not for process namespace sharing. Option D is wrong because `--share-process-namespace` is a Pod-level field in the Pod spec (not a kubectl debug flag) that enables process namespace sharing between regular containers in the same Pod, not specifically for ephemeral containers created via `kubectl debug`.

Full explanation →

677

Multi-Selecthard

Which THREE are valid patterns for multi-container Pods?

Select 3 answers

A.Init

B.Ambassador

C.Replicator

D.Adapter

E.Sidecar

AnswersB, D, E

The Ambassador pattern deploys a sidecar container that proxies all inbound and outbound network traffic for the main application container, abstracting service discovery, load balancing, and circuit-breaking logic away from the application code. This satisfies the CKAD requirement for multi-container Pods that handle cross-cutting infrastructure concerns without modifying the primary process.

Why this answer

(Ambassador) is correct because the Ambassador pattern uses a proxy container that mediates network traffic between the main application container and external services, allowing the main container to connect to localhost while the ambassador handles protocol translation or service discovery. This is a valid multi-container Pod design pattern in Kubernetes, commonly implemented with tools like Envoy or a custom sidecar proxy.

Exam trap

The trap here is that candidates may confuse Init containers (which run to completion) with multi-container patterns that run concurrently, or they may invent patterns like 'Replicator' that sound plausible but are not defined in Kubernetes documentation.

Full explanation →

678

MCQmedium

You have a headless Service for a StatefulSet. What is the DNS resolution behavior for the StatefulSet pods?

A.DNS is disabled for headless Services.

B.The Service name resolves to the IP of the first pod only.

C.All pods share a single cluster IP via the Service.

D.Each pod gets a DNS A record pointing to its individual IP.

AnswerD

With a StatefulSet bound to a headless Service, Kubernetes publishes a stable DNS A record for each pod in the format pod-name.service-name.namespace.svc.cluster.local, pointing to that pod's specific IP address. This works because the StatefulSet gives each pod a stable hostname (e.g., mydb-0, mydb-1) and the headless Service's selector causes the DNS controller to create an A record for each ready pod. These records persist even if the pod is rescheduled, because the pod name (and hence its DNS entry) stays the same, providing consistent network identity for the stateful workload.

Why this answer

For a headless Service (clusterIP: None) associated with a StatefulSet, DNS resolution returns individual A records for each pod, mapping the pod's hostname (e.g., pod-name.service-name.namespace.svc.cluster.local) to its unique pod IP. This is because headless Services disable load-balanced cluster IPs and instead rely on DNS to provide direct pod-to-pod connectivity, which is essential for StatefulSet workloads like databases that require stable network identities.

Exam trap

The trap here is that candidates often confuse headless Services with regular Services, assuming they still provide a single virtual IP for load balancing, or mistakenly think DNS is disabled, when in fact headless Services rely entirely on DNS for direct pod resolution.

How to eliminate wrong answers

Option A is wrong because DNS is not disabled for headless Services; in fact, DNS is the primary mechanism for pod discovery in headless Services, returning A records for each pod. Option B is wrong because the Service name does not resolve to a single pod IP; it resolves to multiple A records (one per pod) or, in some implementations, to the IPs of all ready pods. Option C is wrong because headless Services explicitly set clusterIP to None, meaning no single cluster IP is assigned; each pod is directly addressable via its own IP.

Full explanation →

679

MCQmedium

Which of the following is the correct way to set a memory limit of 512Mi for a container in a pod spec?

A.resources.requests.memory: 512Mi

B.resources.limits.memory: 512Mi

C.resources.requests.limits.memory: 512Mi

D.resources.limits.cpu: 512Mi

AnswerB

This is correct because resources.limits.memory defines the hard upper bound on memory that the container can use. When the container's memory usage exceeds this value, the kernel will terminate the container with an OOMKilled error (if memory pressure exists) or the container will be evicted. It also affects the pod's Quality-of-Service class, especially when paired with a matching request.

Why this answer

`resources.limits.memory` is the Kubernetes field used to set the maximum amount of memory a container is allowed to use. When a container exceeds this limit, it may be terminated or OOM-killed. The value `512Mi` specifies 512 mebibytes, which is a binary-based unit commonly used in Kubernetes resource specifications.

Exam trap

The trap here is that candidates often confuse `requests` (guarantees) with `limits` (caps), or misplace the `limits` field as a subfield of `requests`, leading them to pick option C or A instead of the correct B.

How to eliminate wrong answers

Option A is wrong because `resources.requests.memory` sets the minimum guaranteed memory for the container, not a hard limit; the container can burst above this value if the node has spare memory. Option C is wrong because `resources.requests.limits.memory` is an invalid path — `limits` is not a subfield of `requests`; the correct hierarchy places `limits` and `requests` as siblings under `resources`. Option D is wrong because `resources.limits.cpu` sets a CPU limit, not a memory limit, and `512Mi` is a memory unit, not a valid CPU unit (CPU uses millicores like `500m` or whole cores).

Full explanation →

680

MCQhard

You run 'kubectl get pods -o wide' and see that a pod 'worker-pod' is in 'Completed' state with 'Restart Count: 5'. The pod's restart policy is 'OnFailure'. What is the most likely reason the pod has restarted 5 times?

A.The liveness probe failed and restarted the container

B.The container exited with non-zero exit code multiple times before succeeding

C.The pod's node was rebooted

D.The pod was evicted due to node pressure

AnswerB

Under a restartPolicy of OnFailure, a container exiting with a non-zero code triggers a restart, and each failure increments the restart count. If the container eventually exits with code 0, the pod reaches the Completed phase, preserving a restart count that records the earlier failed attempts. This exactly matches a pod that shows Completed but has restarts.

Why this answer

B is correct because the pod's restart policy is 'OnFailure', which means the kubelet will restart the container only when it exits with a non-zero exit code. The pod is in 'Completed' state with a restart count of 5, indicating the container exited with a non-zero code multiple times (triggering restarts) before finally exiting with a zero exit code and reaching completion.

Exam trap

The trap here is that candidates often confuse 'Completed' with 'CrashLoopBackOff' — but 'Completed' means the container exited successfully (exit code 0) after the restarts, while 'CrashLoopBackOff' would indicate ongoing failures with no successful exit.

How to eliminate wrong answers

Option A is wrong because a liveness probe failure would cause the container to be restarted regardless of the exit code, and the pod would typically remain in 'Running' state, not 'Completed'; also, liveness probe restarts are counted but the pod would not show 'Completed' unless the container exited successfully. Option C is wrong because a node reboot would restart all containers on the node, but the pod would show a 'Running' or 'Pending' state after reboot, not 'Completed', and the restart count would increment for all containers, not just this one. Option D is wrong because pod eviction due to node pressure results in the pod being terminated and possibly recreated on another node, but the pod would show a 'Failed' or 'Evicted' status, not 'Completed', and the restart count would not increment from eviction.

Full explanation →

681

MCQeasy

What is the primary purpose of a Kubernetes ServiceAccount?

A.To provide an identity for processes running in a Pod

B.To grant permissions to users

C.To define network policies for Pods

D.To store Docker registry credentials

AnswerA

A ServiceAccount supplies a distinct identity that the Kubernetes API server associates with processes in a Pod. Workloads authenticate as that account when calling the API, and RBAC bindings grant the account specific permissions, decoupling Pod identity from individual users.

Why this answer

A Kubernetes ServiceAccount provides an identity for processes running in a Pod, allowing them to authenticate to the Kubernetes API server and to external services. When a Pod is created, it can be assigned a ServiceAccount, and the API server then associates that identity with the Pod's requests. This is distinct from user accounts, which are for human users.

Exam trap

CKAD often tests the confusion between ServiceAccounts (workload identity) and user accounts (human identity) — candidates pick the option about granting permissions to users because they conflate authentication with authorization.

How to eliminate wrong answers

Option B is wrong because granting permissions to users is done through RBAC roles and bindings for user accounts, not ServiceAccounts; ServiceAccounts are for workloads. Option C is wrong because network policies are defined by NetworkPolicy resources and control pod-to-pod traffic, not by ServiceAccounts. Option D is wrong because Docker registry credentials are stored in Kubernetes Secrets (of type kubernetes.io/dockerconfigjson) and referenced in Pod specs, not in ServiceAccounts.

Full explanation →

682

MCQeasy

You want to see detailed information about a node's resource usage. Which command should you run?

A.kubectl describe node

B.kubectl logs node

C.kubectl get nodes -o wide

D.kubectl top node

AnswerD

kubectl top node retrieves live CPU and memory usage for each node from the Kubernetes metrics API, which is typically served by metrics-server, and reports both raw values and the percentage of allocatable resources consumed. It is the Kubernetes equivalent of the top utility and the standard way to see current node utilization. If metrics-server is not installed or unavailable, the command fails with an error like 'error: metrics not available'.

Why this answer

`kubectl top node` retrieves real-time CPU and memory usage metrics for nodes from the metrics server, which is essential for monitoring resource consumption. This command directly answers the question about detailed resource usage, unlike other options that provide configuration or log data.

Exam trap

The trap here is that candidates confuse `kubectl describe node` (which shows static resource capacity) with `kubectl top node` (which shows dynamic usage), leading them to choose option A for resource monitoring questions.

How to eliminate wrong answers

Option A is wrong because `kubectl describe node` shows node metadata, conditions, and capacity/allocatable resources, but not real-time usage metrics. Option B is wrong because `kubectl logs node` is invalid; logs are fetched for pods, not nodes, and this command would fail. Option C is wrong because `kubectl get nodes -o wide` displays additional node details like internal IP and OS image, but not dynamic resource usage.

Full explanation →

683

MCQmedium

You run 'kubectl run nginx --image=nginx --restart=Never --dry-run=client -o yaml'. What is the output?

A.A Pod manifest with apiVersion: v1beta1

B.A Pod manifest with apiVersion: v1

C.A Job manifest with apiVersion: batch/v1

D.A Deployment manifest with apiVersion: apps/v1

AnswerB

Running `kubectl run nginx --image=nginx --restart=Never` generates a standalone Pod manifest with `apiVersion: v1` and `kind: Pod`, because `--restart=Never` explicitly disables controller-managed restart behavior. The core `v1` API is the correct, stable group/version for Pods. This single-container manifest simply declares the nginx image and a `restartPolicy: Never` in the Pod spec.

Why this answer

The command `kubectl run nginx --image=nginx --restart=Never --dry-run=client -o yaml` creates a Pod manifest because `--restart=Never` explicitly sets the restart policy to Never, which is a Pod-level field. The `kubectl run` command without `--restart=Never` defaults to creating a Deployment, but with `--restart=Never`, it generates a standalone Pod. The output uses `apiVersion: v1`, which is the correct and stable API version for Pods.

Exam trap

The trap here is that candidates often assume `kubectl run` always creates a Deployment, forgetting that the `--restart` flag changes the resource type, and they may also mistakenly think Pods use a beta API version.

How to eliminate wrong answers

Option A is wrong because Pods use `apiVersion: v1`, not `v1beta1`; `v1beta1` was deprecated and removed in Kubernetes 1.22, and Pods have been stable at v1 since early Kubernetes versions. Option C is wrong because a Job manifest would require `apiVersion: batch/v1` and a different command (e.g., `kubectl create job` or `kubectl run` with `--restart=OnFailure`), but `--restart=Never` forces a Pod, not a Job. Option D is wrong because a Deployment manifest uses `apiVersion: apps/v1` and is generated only when `--restart` is not specified (defaults to `Always`), but `--restart=Never` overrides that default to produce a Pod.

Full explanation →

684

MCQmedium

A pod uses a ServiceAccount with automountServiceAccountToken set to false. The pod still needs to access the Kubernetes API. How can you mount the service account token in this pod?

A.Set automountServiceAccountToken: true in the pod spec

B.Create a secret with the token and mount it manually

C.Use a ConfigMap to store the token

D.Set serviceAccountName: default and automountServiceAccountToken: true in the pod spec

AnswerA

Setting automountServiceAccountToken: true directly in the pod spec is the correct, explicit override when the referenced ServiceAccount has automount disabled. This field takes precedence over the ServiceAccount's setting, causing the kubelet to project the service account token into the pod at /var/run/secrets/kubernetes.io/serviceaccount/token. That mounted token lets in-cluster clients authenticate to the Kubernetes API server without any extra steps.

Why this answer

Setting `automountServiceAccountToken: true` in the pod spec overrides the ServiceAccount-level setting of `false`. This allows the pod to mount the service account token automatically, enabling it to authenticate to the Kubernetes API without manual intervention.

Exam trap

The trap here is that candidates may think they need to manually create a Secret or ConfigMap to inject the token, when in fact the pod spec override of `automountServiceAccountToken` is the correct and simplest approach.

How to eliminate wrong answers

Option B is wrong because service account tokens are not stored as Secrets; they are automatically mounted via a projected volume, and manually creating a Secret with the token is unnecessary and insecure. Option C is wrong because ConfigMaps are designed for non-sensitive configuration data and cannot securely store service account tokens, which are sensitive credentials. Option D is wrong because setting `serviceAccountName: default` is irrelevant; the pod already uses a ServiceAccount, and the key issue is overriding `automountServiceAccountToken` to true, which is already covered by Option A.

Full explanation →

685

Multi-Selecteasy

Which two commands can create a ConfigMap from an environment file? (Select TWO.)

Select 2 answers

A.kubectl create configmap my-config --from-literal=app.env

B.kubectl create configmap my-config --from-env-file=app.env

C.kubectl create configmap my-config --from-file=app.env

D.kubectl create configmap my-config --from-file=key1=app.env

E.kubectl create configmap my-config --from-env=app.env

AnswersB, C

The --from-env-file flag is specifically designed to import environment variables from a file formatted as KEY=VALUE lines. It parses each line and creates a separate data entry in the ConfigMap for each key, automatically ignoring blank lines and comments. This is the correct method when the goal is to load the env file's variable definitions into the ConfigMap for later use as environment variables in a pod.

Why this answer

`--from-env-file=app.env` is the dedicated flag for creating a ConfigMap from an environment file, where each line in the file is parsed as a key=value pair. Option C is also correct because `--from-file=app.env` creates a ConfigMap with the file's entire contents stored under the filename as the key, which is a valid method even though it does not parse the file as environment variables.

Exam trap

The trap here is that candidates often confuse `--from-env-file` (which parses key=value pairs) with `--from-file` (which stores the file as a single entry), and may incorrectly assume that `--from-file` also parses environment files, or that `--from-env` is a valid flag.

Full explanation →

686

MCQeasy

Which command shows resource usage (CPU and memory) for pods?

A.kubectl top node

B.kubectl resource pod

C.kubectl top pod

D.kubectl metrics pod

AnswerC

This is the correct command. `kubectl top pod` retrieves real-time CPU and memory usage metrics from the Metrics API, which is typically backed by metrics-server. It displays per-pod usage and supports flags like `--containers` to drill down into individual container utilization, making it the standard tool for troubleshooting pod resource consumption.

Why this answer

The `kubectl top pod` command retrieves and displays real-time CPU and memory usage metrics for pods from the metrics server, which aggregates resource usage data from kubelets via the Resource Metrics API. This is the correct command to view per-pod resource consumption in a Kubernetes cluster.

Exam trap

The trap here is that candidates may confuse `kubectl top pod` with `kubectl top node` (option A) or invent a non-existent command like `kubectl metrics pod` (option D), because the CKAD exam often tests the exact syntax of the `top` subcommand for resource monitoring.

How to eliminate wrong answers

Option A is wrong because `kubectl top node` shows resource usage for nodes, not pods, and is used to view aggregate node-level CPU and memory metrics. Option B is wrong because `kubectl resource pod` is not a valid kubectl command; the correct verb for viewing metrics is `top`, not `resource`. Option D is wrong because `kubectl metrics pod` is not a valid kubectl command; the metrics are accessed via the `top` subcommand, not a `metrics` subcommand.

Full explanation →

687

Multi-Selecthard

A Pod is configured with a securityContext that sets runAsUser: 1000 and runAsGroup: 3000 at the pod level. A container within that Pod has its own securityContext that sets runAsUser: 2000 but does not set runAsGroup. The container process attempts to create a file in a directory owned by group 3000 with group write permissions. Which two statements are true regarding the effective user and group of the container process? (Choose two.)

Select 2 answers

A.The container process runs with UID 1000 because pod-level settings take precedence.

B.The container process runs with UID 2000.

C.The container process runs with GID 3000.

D.The container process runs with GID 2000 because the container's runAsUser implies a matching group.

E.The container process cannot write to the directory because the group ID does not match the directory's group owner.

AnswersB, C

The container-level securityContext overrides the pod-level setting for runAsUser. Since the container specifies runAsUser: 2000, the process inside that container will run as UID 2000. This is a fundamental principle of securityContext inheritance: more specific scopes override broader ones. The pod-level runAsUser: 1000 is superseded for this container.

Why this answer

Container-level securityContext overrides pod-level for the same field, so runAsUser: 2000 applies. For runAsGroup, the container does not specify it, so it inherits the pod-level runAsGroup: 3000. Thus the process runs as UID 2000 and GID 3000, allowing write access to the group-writable directory.

Exam trap

The trap here is assuming that setting runAsUser at the container level also changes the group, or that pod-level settings override container-level settings.

Full explanation →

688

MCQmedium

You are tasked with building a container image for a Node.js application. The Dockerfile must first install system dependencies, then copy application code, and finally run the app. Which of the following Dockerfiles is correct?

A.FROM node:14\nCMD apt-get update && apt-get install -y build-essential\nCOPY . /app\nCMD ["node","app.js"]

B.FROM node:14\nRUN apt-get update && apt-get install -y build-essential\nCOPY . /app\nRUN ["node","app.js"]

C.FROM node:14\nRUN apt-get update && apt-get install -y build-essential\nCOPY . /app\nCMD ["node","app.js"]

D.FROM node:14\nRUN apt-get update && apt-get install -y build-essential\nCOPY . /app\nENTRYPOINT ["node","app.js"]

AnswerC

The Dockerfile orders instructions correctly: FROM sets the base image, RUN installs system dependencies, then COPY brings in application code, and CMD starts the app. This satisfies the stem's required sequence of installing dependencies before copying code and running the app.

Why this answer

It follows the required order: first installs system dependencies using RUN (which executes at build time), then copies application code with COPY, and finally uses CMD to define the default command that runs the Node.js app at container runtime. CMD is the appropriate instruction for specifying the executable when the container starts, as opposed to RUN which would execute during image build and fail to run the app.

Exam trap

In the CKAD exam, candidates often confuse RUN (build-time execution) with CMD (runtime command). For this Dockerfile, using RUN for the final app command would execute during build, not at container start. Placing CMD before COPY or using ENTRYPOINT incorrectly can cause build errors or unexpected behavior.

How to eliminate wrong answers

Option A is wrong because it uses CMD instead of RUN for installing dependencies, so apt-get commands are not executed during image build and will run at container start, potentially failing due to missing package lists or incorrect order. Option B is wrong because it uses RUN ["node","app.js"] which attempts to execute the Node.js app during image build, but the app code is copied after the RUN instruction in the Dockerfile, so the file does not exist at that point, causing a build failure. Option D is wrong because it uses ENTRYPOINT instead of CMD; while ENTRYPOINT can also run the app, the question specifically asks for CMD to run the app, and using ENTRYPOINT changes the container's behavior (e.g., it cannot be overridden by command-line arguments without --entrypoint flag), making it incorrect for this scenario.

Full explanation →

689

MCQeasy

Which command creates a Docker registry secret from an existing Docker config file?

A.kubectl create secret tls my-reg --cert=... --key=...

B.kubectl create secret generic my-reg --from-file=.dockerconfigjson=config.json

C.kubectl create secret docker-registry my-reg --docker-server=... --docker-username=...

D.kubectl create secret docker-registry my-reg --from-file=.dockerconfigjson=config.json

AnswerB

This is the correct approach because `kubectl create secret generic` with `--from-file=.dockerconfigjson=config.json` directly places the contents of your existing `config.json` file under the exact data key that Kubernetes expects. The secret is created as type `Opaque`, but the kubelet reads the `.dockerconfigjson` key regardless of the secret type, so it works as an imagePullSecret. This method preserves all registry entries and authentication tokens from the original file, making it ideal when you already have a `docker login` output.

Why this answer

`kubectl create secret generic` with `--from-file=.dockerconfigjson=config.json` creates a generic secret that stores the contents of an existing Docker config file (typically `~/.docker/config.json`) under the key `.dockerconfigjson`. This is the standard method for importing a pre-existing Docker configuration as a Kubernetes secret, which can then be used for image pull authentication.

Exam trap

CNCF often tests the distinction between `kubectl create secret docker-registry` (which creates a new secret from individual flags) and `kubectl create secret generic` with `--from-file` (which imports an existing config file), leading candidates to incorrectly choose option D because they assume `docker-registry` supports `--from-file`.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret tls` creates a TLS secret for serving certificates, not a Docker registry authentication secret. Option C is wrong because `kubectl create secret docker-registry` with `--docker-server`, `--docker-username`, etc. creates a new secret from individual credentials, not from an existing Docker config file. Option D is wrong because `kubectl create secret docker-registry` does not support the `--from-file` flag; that flag is only valid for `kubectl create secret generic`.

Full explanation →

690

MCQeasy

Which YAML snippet correctly defines a CronJob that runs a task every 5 minutes?

A.schedule: "*/5 * * *"

B.schedule: "*/5 * * * *"

C.schedule: "0 */5 * * *"

D.schedule: "* * * * *"

AnswerB

This is the standard five-field cron expression where the minute field uses the step operator */5, meaning it matches minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55. Since all other fields (hour, day of month, month, day of week) are wildcards, the job executes every five minutes around the clock, exactly as required.

Why this answer

The standard cron expression for 'every 5 minutes' is `*/5 * * * *`, which matches the required five fields (minute, hour, day of month, month, day of week). Kubernetes CronJob uses this exact format, where `*/5` in the minute field means 'every 5 minutes' and the four asterisks mean 'every hour, every day, every month, every weekday'.

Exam trap

The CKAD exam often tests the distinction between `*/5 * * * *` (every 5 minutes) and `0 */5 * * *` (every 5 hours), which is a classic trap where candidates confuse the minute and hour fields in cron syntax.

How to eliminate wrong answers

Option A is wrong because it has only five asterisk-like fields but is missing the fifth field (day of week), which makes it an invalid cron expression for Kubernetes; the correct format requires exactly five fields. Option C is wrong because `0 */5 * * *` means 'at minute 0 of every 5th hour' (i.e., every 5 hours at the top of the hour), not every 5 minutes. Option D is wrong because `* * * * *` means 'every minute', not every 5 minutes.

Full explanation →

691

MCQeasy

What is the correct apiVersion for a Kubernetes Job in v1.29?

A.batch/v1beta1

B.apps/v1

C.batch/v1

D.v1

AnswerC

Since Kubernetes v1.21, Jobs are served by the stable batch/v1 API version, and this remains true in v1.29. batch/v1 is the only non-deprecated, enabled version for Jobs, offering full production functionality including parallelism, backoffLimit, and TTL cleanup. Any current cluster requires apiVersion: batch/v1 for Job resources.

Why this answer

Kubernetes Jobs are part of the batch API group, and starting from Kubernetes v1.21, the batch/v1 API version is stable and the only supported version for Jobs. In v1.29, batch/v1beta1 has been removed, so batch/v1 is the correct and required apiVersion.

Exam trap

The trap here is that candidates may recall older Kubernetes versions where batch/v1beta1 was still available, or confuse the batch API group with apps/v1 or core v1, leading them to select an incorrect apiVersion for a Job in v1.29.

How to eliminate wrong answers

Option A is wrong because batch/v1beta1 was deprecated in Kubernetes v1.21 and removed in v1.25, so it is not valid for v1.29. Option B is wrong because apps/v1 is used for workloads like Deployments, StatefulSets, and DaemonSets, not for Jobs. Option D is wrong because v1 is the core API group (e.g., Pods, Services) and does not include Job resources.

Full explanation →

692

MCQmedium

You have created a HorizontalPodAutoscaler (HPA) for a Deployment. The HPA is configured with targetCPUUtilizationPercentage: 50. The current CPU utilization is 80%. What will the HPA do?

A.It will restart the pods

B.It will do nothing because HPA only scales based on memory

C.It will increase the number of replicas

D.It will decrease the number of replicas

AnswerC

When the average CPU utilization across the current pods is above the target value, the HPA controller calculates a desired replica count using the formula `ceil(currentReplicas * (currentMetric / desiredMetric))`. Since the ratio is greater than 1, it produces a response that increases `spec.replicas` on the target workload. This is the exact behavior expected: scale-out to reduce the per-pod CPU load to the configured target. The controller will gradually raise the replica count, subject to the `maxReplicas` limit.

Why this answer

The HPA will increase the number of replicas to bring average CPU utilization down to the target.

Full explanation →

693

MCQhard

A Deployment has a rolling update strategy with maxSurge: 1 and maxUnavailable: 0. The Deployment has 4 replicas. During a rollout, what is the maximum number of pods that can exist at any point?

A.5

B.6

C.8

D.4

AnswerA

With maxSurge set to 1, Kubernetes is allowed to create one extra pod above the desired replica count during a rolling update. Since the deployment's desired count is 4, the absolute maximum number of pods that can exist at any moment is 4 + 1 = 5. This surge pod ensures the new ReplicaSet can scale up before any old pods are terminated, maintaining availability throughout the update.

Why this answer

With maxSurge: 1 and maxUnavailable: 0, the Deployment controller ensures that during a rolling update, at most one additional pod (beyond the desired 4 replicas) is created before terminating old pods. Since no pods can be unavailable, the maximum number of pods at any point is 4 (desired) + 1 (surge) = 5.

Exam trap

Kubernetes often tests the interaction between maxSurge and maxUnavailable, where candidates mistakenly add the surge to the maximum unavailable value or forget that maxUnavailable: 0 forces the surge to be created before any termination.

How to eliminate wrong answers

Option B (6) is wrong because it assumes maxSurge could be 2 or that the surge count is doubled, but maxSurge is explicitly set to 1. Option C (8) is wrong because it incorrectly doubles both the desired replicas and the surge, possibly confusing maxSurge with a percentage-based calculation. Option D (4) is wrong because it ignores the maxSurge parameter entirely, assuming no extra pods are created during the rollout.

Full explanation →

694

MCQeasy

You need to view metrics from a Pod running a web server. Which approach follows Kubernetes best practices?

A.Configure a Prometheus server to scrape the Pod's /metrics endpoint.

B.Use kubectl top pod to view CPU and memory metrics.

C.Exec into the container and run curl to check health.

D.Create a ServiceMonitor resource to expose metrics.

AnswerA

Configuring a Prometheus server to scrape the Pod's /metrics endpoint is the correct approach because Prometheus is the de facto standard for collecting and storing application-level metrics in Kubernetes. You define a scrape job—either statically in prometheus.yml or via Kubernetes service discovery—that targets the pod's address and the /metrics path, and Prometheus periodically retrieves the metrics over HTTP. This provides persistent time-series data queryable with PromQL, and it enables alerting and visualization through Grafana, making it the proper foundation for application monitoring.

Why this answer

Prometheus is the de facto standard for monitoring in Kubernetes, and scraping a Pod's /metrics endpoint is the recommended approach for collecting application-level metrics. This follows the Kubernetes best practice of exposing metrics via an HTTP endpoint that a monitoring system can scrape, rather than relying on ephemeral commands or resource-level metrics.

Exam trap

The trap here is that candidates confuse resource-level metrics (CPU/memory) with application-level metrics, or assume that kubectl top pod or exec commands are sufficient for observability, when Kubernetes best practices emphasize using a dedicated monitoring system like Prometheus for application metrics.

How to eliminate wrong answers

Option B is wrong because kubectl top pod only shows CPU and memory usage from the resource metrics pipeline, not application-level metrics like request latency or error rates. Option C is wrong because execing into a container and running curl is an ad-hoc debugging method, not a scalable or best-practice approach for ongoing observability. Option D is wrong because a ServiceMonitor is a Prometheus Operator custom resource that requires the Operator to be installed and is not a native Kubernetes resource; it is not a general best practice for all clusters.

Full explanation →

695

Multi-Selectmedium

Which TWO of the following are valid ways to expose a Service externally in a Kubernetes cluster?

Select 2 answers

A.Service type ClusterIP

B.Service type ExternalName

C.Service type LoadBalancer

D.Service type NodePort

E.Ingress resource with ClusterIP Service

AnswersC, D

Service type LoadBalancer is a valid way to expose a Service because the cloud provider automatically provisions an external load balancer (e.g., ALB, ELB, or a similar L4 LB) that forwards traffic to the Service's underlying node ports. This gives the Service a stable public IP or hostname, making it directly reachable from the internet. It is the most common approach for external exposure in cloud environments.

Why this answer

Service type LoadBalancer (C) exposes the Service externally by provisioning a cloud load balancer (e.g., AWS ELB, GCP L7) that routes external traffic to the Service's ClusterIP. Service type NodePort (D) exposes the Service on a static port (30000-32767) on every node's IP, allowing external access via <NodeIP>:<NodePort>. Both are valid methods for external exposure in Kubernetes.

Exam trap

The trap here is that candidates often think Ingress alone can expose a Service externally, but Ingress is only a routing layer that requires an underlying Service of type NodePort or LoadBalancer to actually receive external traffic.

Full explanation →

696

MCQmedium

You want to perform a blue-green deployment using Deployments and Services. You have two Deployments: 'app-blue' (current) and 'app-green' (new). The Service 'app-service' currently selects pods with label 'version: blue'. What kubectl command should you run to switch traffic to the green deployment?

A.kubectl patch service app-service -p '{"spec":{"selector":{"version":"green"}}}'

B.kubectl delete service app-service --ignore-not-found && kubectl create service app-service --selector version=green

C.kubectl set selector service/app-service version=green

D.kubectl apply -f service.yaml where service.yaml has the new selector

AnswerA

The patch command mutates the existing Service's selector in place, updating the label selector from version=blue to version=green. Because the Service object is not deleted, its ClusterIP and NodePort are preserved, and Kubernetes immediately reconciles the Endpoints to include the green pods and exclude blue pods. This is the canonical zero-downtime traffic shift in a blue-green deployment, as it requires no file creation and only a single atomic API call.

Why this answer

A Kubernetes Service routes traffic based on its label selector, so blue-green switching is achieved by changing the Service's selector to point at the new pods. The kubectl patch command with a strategic merge patch on spec.selector updates the selector in place, instantly redirecting traffic to pods labeled version: green without recreating the Service or changing its ClusterIP. This is the canonical, non-disruptive way to flip traffic between blue and green Deployments.

Exam trap

CKAD often tests whether candidates know that Service selectors are mutable via patch and that delete/recreate breaks the ClusterIP, so the trap is choosing the destructive recreate option or an invalid subcommand like 'set selector'.

How to eliminate wrong answers

Option B is wrong because deleting and recreating the Service changes its ClusterIP and causes downtime, breaking DNS records and any clients caching the old IP — the opposite of a zero-downtime blue-green cutover. Option C is wrong because 'kubectl set selector' is not a valid kubectl subcommand; selector changes must go through patch, edit, or apply. Option D is wrong because it is not a specific command — while applying a manifest with a new selector can work, the question asks for the command to run, and a bare apply without the correct file content is not a deterministic answer; patch is the precise, direct method.

Full explanation →

697

MCQeasy

A Secret named 'db-secret' of type Opaque contains a key 'password'. How do you reference this key as an environment variable named 'DB_PASSWORD' in a pod spec?

A.env: - name: DB_PASSWORD valueFrom: configMapKeyRef: name: db-secret key: password

B.env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: db-secret key: password

C.envFrom: - secretRef: name: db-secret key: password

D.env: - name: DB_PASSWORD value: "db-secret.password"

AnswerB

This is the correct way to consume a specific key from a Secret as an environment variable. The secretKeyRef field tells the kubelet to read the value associated with the password key from the Secret named db-secret in the same namespace, then assign it to DB_PASSWORD. The Secret must exist before the Pod starts, otherwise the container creation will fail with a resolution error.

Why this answer

It uses the `secretKeyRef` field under `valueFrom` to reference a specific key from a Kubernetes Secret of type Opaque. The `secretKeyRef` is the proper mechanism to inject a single key from a Secret as an environment variable, mapping the key 'password' to the environment variable name 'DB_PASSWORD'.

Exam trap

The trap here is confusing `configMapKeyRef` with `secretKeyRef` — CNCF often tests whether candidates know that Secrets require `secretKeyRef` while ConfigMaps use `configMapKeyRef`, and that `envFrom` with `secretRef` injects all keys, not a single key.

How to eliminate wrong answers

Option A is wrong because it uses `configMapKeyRef`, which is used to reference keys from a ConfigMap, not a Secret; Secrets require `secretKeyRef`. Option C is wrong because `envFrom` with `secretRef` injects all keys from the Secret as environment variables, not a single key, and the syntax shown incorrectly includes a `key` field which is not valid under `secretRef`. Option D is wrong because it uses a static `value` string, which does not dynamically reference the Secret's key; Kubernetes will treat the string literally as 'db-secret.password' rather than fetching the actual password value.

Full explanation →

698

MCQmedium

Which command correctly creates a Role named 'pod-reader' that allows get, list, and watch on pods?

A.kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

B.kubectl create role pod-reader --verb=get,list,watch --resource=Pod

C.kubectl create role pod-reader --verb=get,list,watch --resource=pods

D.kubectl create role pod-reader --verbs=get,list,watch --resources=pods

AnswerC

This is the correct syntax because it supplies all three verbs as a single comma-separated value for the --verb flag and specifies the resource using the standard lowercase plural name pods. The kubectl create role command uses this input to generate or directly create a Role object that grants get, list, and watch permissions on pods in the active namespace. This exactly matches the documented command line syntax for kubectl create role, making it the only valid option among the four.

Why this answer

The `kubectl create role` command uses the `--verb` flag (singular) with comma-separated values and the `--resource` flag (singular) with the lowercase plural resource name 'pods'. This matches the Kubernetes API convention where resources are specified as lowercase plurals (e.g., 'pods', 'deployments') and verbs are comma-separated.

Exam trap

The trap here is that candidates often confuse the singular `--verb`/`--resource` flags with the plural `--verbs`/`--resources` or incorrectly use repeated `--verb` flags, leading to syntax errors or incorrect RBAC rule generation.

How to eliminate wrong answers

Option A is wrong because it uses multiple `--verb` flags, which is not the correct syntax; `kubectl create role` expects a single `--verb` flag with comma-separated values, not repeated flags. Option B is wrong because it uses 'Pod' with a capital P, but Kubernetes resource names must be lowercase plural (e.g., 'pods'). Option D is wrong because it uses `--verbs` (plural) and `--resources` (plural), but the correct flags are the singular forms `--verb` and `--resource`.

Full explanation →

699

MCQmedium

You have a Dockerfile that uses a multi-stage build. Which of the following statements about multi-stage builds is correct?

A.Multi-stage builds require a single FROM statement

B.Multi-stage builds increase the final image size

C.Each stage must have a unique name

D.Artifacts from earlier stages can be copied to later stages using COPY --from

AnswerD

COPY --from=<stage> is the mechanism that makes multi-stage builds effective, letting you select a named stage or a numeric index and copy specific files or directories into the current build stage. This allows the final stage to contain only the runtime and essential artifacts, not the compiler, headers, or source code from earlier stages. This is a correct statement and is the core feature of multi-stage builds.

Why this answer

Multi-stage builds allow you to copy artifacts from a previous stage using the `COPY --from=<stage_name_or_index>` instruction. This enables you to keep only the necessary runtime artifacts in the final image, significantly reducing image size by discarding build-time dependencies and intermediate layers.

Exam trap

The trap here is that candidates often assume all stages must have unique names or that multi-stage builds increase image size, when in fact the key benefit is size reduction and stages can be referenced by index without names.

How to eliminate wrong answers

Option A is wrong because multi-stage builds require at least two FROM statements, not a single one; each FROM starts a new stage. Option B is wrong because multi-stage builds are specifically designed to reduce the final image size by excluding build tools and intermediate files from the final stage. Option C is wrong because stages can be referenced by their index (e.g., FROM 0) or by an optional name assigned with AS, but names are not required; unnamed stages are allowed.

Full explanation →

700

MCQhard

You want to restrict ingress traffic to pods with label 'app: web' in namespace 'frontend' to only come from pods in namespace 'backend'. Which NetworkPolicy YAML is correct?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: frontend spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: backend

B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: backend spec: podSelector: matchLabels: app: web ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: frontend

C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: frontend spec: podSelector: matchLabels: app: web ingress: - from: - ipBlock: cidr: 0.0.0.0/0

D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: frontend spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: backend

AnswerA

This is correct because the NetworkPolicy is placed in the frontend namespace, so its podSelector matches frontend pods carrying the app: web label. The policyTypes: [Ingress] explicitly makes this an ingress rule, and the ingress from list uses a namespaceSelector that matches the backend namespace by its automatically assigned metadata.name label, thus permitting inbound traffic only from pods in namespace backend — not from any other source. Because no podSelector is nested inside the namespaceSelector, the rule applies to every pod running in that source namespace.

Why this answer

It defines a NetworkPolicy in the 'frontend' namespace that selects pods with label 'app: web' and allows ingress traffic only from pods in the 'backend' namespace. The key is the `namespaceSelector` with `kubernetes.io/metadata.name: backend`, which matches the namespace named 'backend' (this label is automatically added by Kubernetes to every namespace). The `policyTypes: [Ingress]` explicitly enables ingress rules, and the `from` rule restricts traffic to only those originating from the 'backend' namespace.

Exam trap

The trap here is that candidates often forget that a `podSelector` alone only selects pods within the same namespace, and they mistakenly omit the `namespaceSelector` when trying to allow traffic from pods in a different namespace.

How to eliminate wrong answers

Option B is wrong because the NetworkPolicy is placed in the 'backend' namespace, but the target pods (with label 'app: web') are in the 'frontend' namespace; a NetworkPolicy only applies to pods in its own namespace, so it would not affect the 'frontend' pods. Option C is wrong because it uses an `ipBlock` with `0.0.0.0/0`, which allows traffic from all IP addresses, not just from pods in the 'backend' namespace, thus failing to restrict ingress to only 'backend' pods. Option D is wrong because it uses a `podSelector` without a `namespaceSelector`, which only selects pods in the same namespace ('frontend'), not pods from the 'backend' namespace; to select pods from another namespace, a `namespaceSelector` is required.

Full explanation →

701

MCQmedium

A pod in namespace 'default' cannot resolve the service name 'db' in namespace 'data'. Which DNS name should the pod use to reach the service?

A.db.default.svc.cluster.local

B.data.db.svc.cluster.local

C.db.data.svc.cluster.local

D.db.svc.data.cluster.local

AnswerC

This FQDN correctly follows the Kubernetes DNS schema for cross-namespace Service discovery: `<service-name>.<namespace>.svc.cluster.local`. Here `db` is the Service name and `data` is the namespace, so a pod in the `default` namespace can resolve this name to the Service's ClusterIP. Using the full FQDN is required when the Service is in a different namespace than the pod, as a short name would only work within the same namespace.

Why this answer

Kubernetes DNS resolves a service in another namespace using the format <service>.<namespace>.svc.cluster.local. Since the service is named 'db' in namespace 'data', the fully qualified domain name (FQDN) is db.data.svc.cluster.local. This allows cross-namespace service discovery without needing to modify the pod's DNS configuration.

Exam trap

The trap here is that candidates often confuse the order of service and namespace in the DNS name, incorrectly placing the namespace before the service (as in option B) or misplacing 'svc' (as in option D), instead of remembering the correct pattern <service>.<namespace>.svc.cluster.local.

How to eliminate wrong answers

Option A is wrong because db.default.svc.cluster.local would resolve a service named 'db' in the 'default' namespace, not in the 'data' namespace. Option B is wrong because data.db.svc.cluster.local reverses the order of service and namespace; the correct format is <service>.<namespace>.svc.cluster.local, not <namespace>.<service>.svc.cluster.local. Option D is wrong because db.svc.data.cluster.local places 'svc' before the namespace, which is invalid; the DNS hierarchy is <service>.<namespace>.svc.<cluster-domain>, so 'svc' must come after the namespace.

Full explanation →

702

MCQmedium

You apply the following Ingress manifest: ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: ingressClassName: nginx rules: - host: app.example.com http: paths: - pathType: Prefix path: / backend: service: name: app-svc port: number: 80 ``` What is missing to enable TLS termination for this Ingress?

A.Create a ConfigMap with the TLS certificate

B.Set `service.beta.kubernetes.io/load-balancer-source-ranges` annotation on the Service

C.Change the Ingress API version to extensions/v1beta1

D.Add `tls` section under spec with hosts and secretName

AnswerD

To expose a service over HTTPS, the Ingress manifest must include a tls section directly under spec that lists the hosts to be covered and the secretName referencing a TLS secret. The secret must exist in the same namespace as the Ingress and contain the certificate and private key in the expected format. This tls block instructs the Ingress controller to terminate TLS by decrypting incoming HTTPS traffic for the specified hosts and forwarding plain HTTP to the backend service. Without this section, even if you have a valid certificate in a Secret, the Ingress will only serve plain HTTP.

Why this answer

D is correct because TLS termination in Kubernetes Ingress requires a `tls` section under `spec` that specifies the `hosts` and a `secretName` referencing a Kubernetes Secret containing the TLS certificate and private key. Without this section, the Ingress will only serve HTTP traffic, even if an ingress controller like nginx is used.

Exam trap

The trap here is that candidates may think TLS termination is automatically enabled by the ingress controller or that a ConfigMap can hold certificates, but Kubernetes explicitly requires a `tls` section and a Secret of type `kubernetes.io/tls` for this purpose.

How to eliminate wrong answers

Option A is wrong because TLS certificates are stored in a Kubernetes Secret, not a ConfigMap; ConfigMaps are for non-sensitive configuration data. Option B is wrong because the annotation `service.beta.kubernetes.io/load-balancer-source-ranges` restricts client IPs for a LoadBalancer Service, not for TLS termination on an Ingress. Option C is wrong because `extensions/v1beta1` is deprecated and removed in newer Kubernetes versions; the correct API version for Ingress is `networking.k8s.io/v1`, and changing the version does not enable TLS.

Full explanation →

703

Multi-Selecthard

You are tasked with improving the observability of a microservices application running in Kubernetes. The application is deployed with multiple replicas and experiences occasional high latency. Which TWO actions should you take to gain better insight into the application's performance?

Select 2 answers

A.Increase the replica count for each deployment to reduce latency.

B.Enable Prometheus metrics endpoints on each pod and configure a Prometheus server to scrape them.

C.Configure readiness probes to ensure only healthy pods receive traffic.

D.Add liveness probes to all containers to detect when they are unresponsive.

E.Implement distributed tracing using Jaeger to trace requests across services.

AnswersB, E

Prometheus scraping per-pod metrics endpoints exposes latency histograms and request rates across every replica, satisfying the need to diagnose occasional high latency in a multi-replica deployment. Unlike node-level or aggregated monitoring, it attributes performance data to individual pods, revealing whether specific replicas degrade.

Why this answer

Option B is correct because exposing Prometheus metrics endpoints on each pod and configuring a Prometheus server to scrape them provides quantitative observability into request rates, error rates, and latency histograms per service and replica, which is essential for diagnosing occasional high latency in a microservices application. Option E is correct because implementing distributed tracing with Jaeger captures end-to-end request flows across service boundaries, letting you pinpoint which service or call in a chain contributes to latency spikes, something metrics alone cannot attribute to a specific request path. The unmarked options do not belong: A (increasing replica count) is a scaling remediation, not an observability action, and may mask rather than reveal the root cause; C (readiness probes) and D (liveness probes) are availability and health-management mechanisms that affect traffic routing and container restarts but do not provide performance insight into latency.

Exam trap

CNCF often tests the distinction between observability (monitoring, metrics, tracing) and reliability mechanisms (probes, scaling). Candidates mistakenly choose readiness or liveness probes as tools for performance insight instead of recognizing they only ensure basic health and traffic routing. Similarly, scaling replicas is a performance fix, not an observability improvement.

Full explanation →

704

MCQeasy

Which of the following is true about headless services?

A.It performs round-robin load balancing across pods

B.It has no cluster IP; DNS returns the IPs of the pods

C.It provides a single DNS record for the service

D.It must not have a selector

AnswerB

In a headless service, you explicitly set clusterIP: None, which removes the stable cluster IP from the Service object. The DNS name then resolves not to a VIP but to the actual IP addresses of all backing pods selected by the service. This is the defining behavior of headless services: DNS returns multiple A records, one per pod endpoint, enabling direct pod-to-pod communication.

Why this answer

A headless service is created by setting `clusterIP: None` in the Service spec. Because it has no Cluster IP, kube-proxy does not create any load-balancing rules for it. Instead, the DNS lookup for the service name returns the IP addresses of all ready pods backing the service, allowing direct pod-to-pod communication without a proxy.

Exam trap

The trap here is that candidates often assume all services must have a Cluster IP and perform load balancing, but headless services explicitly disable that to provide direct pod IP resolution for stateful workloads.

How to eliminate wrong answers

Option A is wrong because headless services do not perform any load balancing; they bypass kube-proxy entirely and rely on DNS to return multiple A/AAAA records, leaving load balancing to the client or DNS resolver. Option C is wrong because a headless service returns multiple DNS A records (one per pod IP) rather than a single record; a regular ClusterIP service returns a single DNS record pointing to the Cluster IP. Option D is wrong because a headless service can have a selector; if it has a selector, DNS returns the pod IPs; if it has no selector, DNS returns the IPs of the endpoints defined manually via an Endpoints or EndpointSlice object.

Full explanation →

705

MCQmedium

A developer is building an image for a Node.js application. The Dockerfile currently copies package.json and package-lock.json, runs npm ci, then copies the rest of the source code. They want to ensure that rebuilding the image after only editing application source files does not re-run npm ci. Which statement about Docker layer caching explains why this Dockerfile ordering achieves that goal?

A.Docker caches the result of every RUN instruction globally in the local image store keyed by the command string, so npm ci is skipped whenever the same command appears in any Dockerfile on the host.

B.The COPY instruction always invalidates all subsequent layers, so placing COPY package.json before npm ci forces npm ci to run only when the source code changes.

C.Docker automatically detects that npm ci is a dependency installation step and caches its output separately from the image layers, independent of Dockerfile instruction order.

D.Each Dockerfile instruction creates a layer; a layer is reused from cache if its instruction and the contents of files it references are unchanged, so npm ci is only invalidated when the dependency manifests change.

AnswerD

Docker builds images layer by layer, and a cached layer is reused when the instruction text and the copied file contents are identical. Since package.json and package-lock.json are copied before the source, editing only source files does not invalidate the earlier npm ci layer, so dependencies are not reinstalled.

Why this answer

Docker layer caching reuses a layer when its instruction and referenced file contents match the previous build. Copying dependency manifests first and running npm ci before copying source code means source edits do not invalidate the dependency layer, so npm ci is skipped and rebuilds are faster.

Exam trap

The trap here is assuming Docker understands package managers or caches command results globally, rather than caching layers keyed by instruction and file content.

Full explanation →

706

MCQmedium

A developer creates a Dockerfile with the following content: FROM alpine:3.18 COPY app.sh /app.sh RUN chmod +x /app.sh CMD ["/app.sh"] They want to override the command to run '/app.sh --debug' when deploying the container in Kubernetes. Which of the following pod spec fields should they use?

A.spec.containers[].entrypoint

B.spec.containers[].command

C.spec.containers[].args

D.spec.command

AnswerC

The `spec.containers[].args` field is correct because it directly overrides the Dockerfile's CMD instruction—the default argument list passed to the image's ENTRYPOINT. In this image, the ENTRYPOINT is `/app.sh`, and setting `args` to `['--debug']` replaces the default CMD arguments with `--debug`, resulting in the container process `/app.sh --debug`. This preserves the original entrypoint while changing its arguments, which is exactly what the developer intends.

Why this answer

In Kubernetes, the `args` field overrides the CMD instruction from the Docker image. The Dockerfile's `CMD ["/app.sh"]` is replaced by `args: ["--debug"]`, which is appended to the ENTRYPOINT (defaulting to `/bin/sh -c` if not set, but here the ENTRYPOINT is `/app.sh` from the image's implicit ENTRYPOINT? Actually, the image has no explicit ENTRYPOINT, so the default is `/app.sh` from CMD? Wait — the Dockerfile has no ENTRYPOINT, so the container's entrypoint is the default `/bin/sh -c`? No, in Kubernetes, if no `command` is set, the image's ENTRYPOINT is used; if no ENTRYPOINT, then the image's CMD is used as the command. Here, the image has CMD `["/app.sh"]` and no ENTRYPOINT, so the container's command is `/app.sh`.

Setting `args: ["--debug"]` will append `--debug` to that command, resulting in `/app.sh --debug`.

Exam trap

The CKAD exam often tests the confusion between `command` (overrides ENTRYPOINT) and `args` (overrides CMD), leading candidates to incorrectly choose `command` when they only need to append arguments to the existing command.

How to eliminate wrong answers

Option A is wrong because `spec.containers[].entrypoint` is not a valid Kubernetes field; the correct field to override the image's ENTRYPOINT is `command`. Option B is wrong because `spec.containers[].command` overrides the image's ENTRYPOINT, not the CMD; using it would replace the entire command, not just append `--debug`. Option D is wrong because `spec.command` is not a valid field at the pod spec level; the correct path is `spec.containers[].command`.

Full explanation →

707

MCQmedium

You run 'kubectl get pods' and see that a pod is in 'Pending' state. What is the most likely cause?

A.The readiness probe is failing

B.The container command exited with an error

C.The pod's imagePullPolicy is set to Never

D.The node has insufficient resources to run the pod

AnswerD

A pod remains in Pending when the scheduler cannot find a node that meets its resource requests (CPU and memory). The scheduler's predicate filters out nodes with insufficient allocatable capacity, so no node is selected, the PodScheduled condition is set to False, and the pod waits indefinitely—this is why Pending is the correct answer. Unlike container-level failures, this is a pre-scheduling issue; kubectl describe events would show a FailedScheduling message with reasons like FailedNodeSelector or OutOfRange.

Why this answer

A pod in 'Pending' state indicates that the pod has been accepted by the Kubernetes API server but is not yet scheduled to a node. The most common cause is insufficient resources (CPU, memory, or ephemeral storage) on any available node, which prevents the scheduler from binding the pod. This is confirmed by running 'kubectl describe pod <pod-name>' and checking the 'Events' section for messages like '0/1 nodes are available: Insufficient cpu'.

Exam trap

The trap here is that candidates confuse pod lifecycle phases: 'Pending' is specifically about scheduling or container image download delays, not about runtime failures like probe failures or command errors, which occur after the pod is already running.

How to eliminate wrong answers

Option A is wrong because a failing readiness probe causes the pod to be in 'Running' state but not ready to serve traffic, not 'Pending'. Option B is wrong because a container command exiting with an error results in a 'CrashLoopBackOff' or 'Error' state, not 'Pending'. Option C is wrong because imagePullPolicy: Never only affects image pulling behavior and can cause 'ImagePullBackOff' or 'ErrImageNeverPull' if the image is not present locally, but the pod would still be scheduled and move past 'Pending' to a container-creation phase.

Full explanation →

708

Multi-Selecthard

You are troubleshooting a Pod that cannot start because it fails with 'Error: container has runAsNonRoot and image will run as root'. The Pod's SecurityContext has 'runAsNonRoot: true' and no explicit 'runAsUser'. Which three actions could resolve this? (Choose three.)

Select 3 answers

A.Remove 'runAsNonRoot: true' from the SecurityContext.

B.Set 'readOnlyRootFilesystem: true' in the SecurityContext.

C.Use a container image that runs as a non-root user by default.

D.Set 'runAsGroup: 3000' in the SecurityContext.

E.Set 'runAsUser: 1000' in the SecurityContext.

AnswersA, C, E

The 'runAsNonRoot: true' field tells the kubelet to reject the pod if the container would start as UID 0. Because this image runs as root by default, that validation triggers the failure. Removing the flag disables the admission-time check and lets the container start with root privileges, though it also drops this particular security hardening control.

Why this answer

Removing 'runAsNonRoot: true' eliminates the constraint that the container image must run as a non-root user. Since the image runs as root by default and no 'runAsUser' is set, the Pod fails. Removing the flag allows the container to start with its default root user.

Exam trap

The trap here is that candidates may think setting 'runAsGroup' or 'readOnlyRootFilesystem' can indirectly fix the user mismatch, but neither changes the effective UID, so they do not resolve the runAsNonRoot violation.

Full explanation →

709

MCQmedium

A pod named 'webapp' is stuck in 'Pending' state. 'kubectl describe pod webapp' shows '0/1 nodes are available: 1 Insufficient memory'. What is the most likely cause?

A.The node has insufficient CPU

B.The container was killed due to out-of-memory

C.The pod's memory request exceeds available node memory

D.The container image does not exist

AnswerC

When a pod requests more memory than is allocatable on any node in the cluster, the Kubernetes scheduler cannot find a suitable placement and leaves the pod in `Pending` with an event such as `0/3 nodes are available: insufficient memory`. Memory is a non-compressible resource, so the scheduler treats a memory request as a hard guarantee and refuses to place the pod where satisfying it would overcommit available allocatable memory. Since no candidate node can accommodate the specified memory request, the pod remains unscheduled until capacity is freed or the request is reduced.

Why this answer

The error message '0/1 nodes are available: 1 Insufficient memory' directly indicates that the pod's memory request exceeds the allocatable memory on the node. The scheduler cannot place the pod because no node has enough unallocated memory to satisfy the pod's memory request. This is a scheduling failure, not a runtime issue.

Exam trap

Kubernetes certification exams often test the distinction between scheduling failures (Pending state) and runtime failures (CrashLoopBackOff, OOMKilled) to see if candidates confuse resource requests with limits or confuse scheduling with execution.

How to eliminate wrong answers

Option A is wrong because the error explicitly mentions 'Insufficient memory', not CPU; insufficient CPU would produce a different message like 'Insufficient cpu'. Option B is wrong because a container killed due to out-of-memory (OOM) would result in a CrashLoopBackOff or OOMKilled state, not a Pending state; Pending means the pod has not yet been scheduled to a node. Option D is wrong because a missing container image would cause an ErrImagePull or ImagePullBackOff event, not a Pending state with a scheduling failure message.

Full explanation →

710

MCQmedium

You have a pod with two containers: one runs a web server, and the other is a sidecar that logs the web server's output to a central logging system. Which pattern does this represent?

A.Sidecar pattern

B.Decorator pattern

C.Ambassador pattern

D.Adapter pattern

AnswerA

The sidecar pattern adds a helper container to the same pod as the main application container. The helper extends or enhances the main container's behavior, such as by collecting logs, forwarding metrics, or managing file synchronization. Both containers share the pod lifecycle, so they start and stop together, and can communicate via localhost or a shared volume. This matches a web server paired with a logging agent or similar enhancement.

Why this answer

The sidecar pattern involves deploying a helper container alongside the main application container within the same pod. In this scenario, the sidecar container consumes the web server's logs (e.g., by tailing a shared volume or reading stdout/stderr) and forwards them to a central logging system, such as Elasticsearch or Fluentd. This pattern is a core Kubernetes design principle for extending or enhancing the main container without modifying its code.

Exam trap

In the CKAD exam, the sidecar pattern is often tested by describing a helper container that performs a supporting function (like logging, monitoring, or proxying), and the trap is confusing it with the ambassador pattern, which specifically handles network proxying or service discovery, not log forwarding.

How to eliminate wrong answers

Option B (Decorator pattern) is wrong because the decorator pattern typically involves attaching additional responsibilities to an object dynamically, not deploying a separate container to handle cross-cutting concerns like logging. Option C (Ambassador pattern) is wrong because an ambassador container acts as a proxy for network traffic to or from the main container (e.g., for service discovery or rate limiting), not for log forwarding. Option D (Adapter pattern) is wrong because an adapter container standardizes interfaces or data formats between the main container and external systems (e.g., converting metrics output), whereas logging is a sidecar responsibility.

Full explanation →

711

MCQmedium

A Pod is stuck in CrashLoopBackOff. You run 'kubectl logs mypod' and get no output. What is the most likely cause?

A.The Pod is not ready yet.

B.The application crashes before writing any logs.

C.The liveness probe is failing.

D.The container never started due to a missing image.

AnswerB

The application crashes before writing any logs. This is the correct answer because empty output from `kubectl logs` means the process exited before emitting anything to stdout/stderr. Many applications crash during early startup—such as on missing configuration, failed dependency connection, or a panic in initialization—before reaching any logging call. The container repeatedly restarts, and each attempt produces no logs, so the crash loop yields empty log output.

Why this answer

When a Pod is in CrashLoopBackOff and `kubectl logs mypod` returns no output, the most likely cause is that the application crashes before it can write any logs to stdout/stderr. The container starts, runs briefly, and exits before the logging framework initializes, so no log data is captured by the container runtime.

Exam trap

CNCF often tests the distinction between a container that never starts (image pull failure) and one that starts but crashes immediately, with the key clue being the Pod status (CrashLoopBackOff vs ImagePullBackOff) and the absence of log output indicating a pre-log crash.

How to eliminate wrong answers

Option A is wrong because a Pod not being ready yet would typically show a status like 'ContainerCreating' or 'Init:0/1', not CrashLoopBackOff, and logs would still be available if the container had run. Option C is wrong because a failing liveness probe would cause the container to be restarted, but logs would still contain output from the application before the probe failure, unless the crash happens before any log output. Option D is wrong because if the container never started due to a missing image, the Pod would be in 'ImagePullBackOff' or 'ErrImagePull' status, not CrashLoopBackOff, and `kubectl logs` would return an error like 'container is waiting to start'.

Full explanation →

712

MCQeasy

Which kubectl command shows detailed information about a pod, including events, labels, and container state?

A.kubectl logs my-pod

B.kubectl describe pod my-pod

C.kubectl get pod my-pod -o yaml

D.kubectl top pod my-pod

AnswerB

kubectl describe pod my-pod is the correct command because it produces a human-readable, aggregated summary of the pod's configuration, current status, and lifecycle conditions. Crucially, it also displays recent events (e.g., pulls, scheduling, errors) at the bottom, which are essential for diagnosing why a pod is not running as expected.

Why this answer

B is correct because `kubectl describe pod my-pod` provides a comprehensive summary of the pod, including its current state, labels, annotations, conditions, container states (waiting/running/terminated with reasons), and a chronological list of recent events (e.g., pulls, starts, restarts). This makes it the standard command for detailed troubleshooting of a pod's lifecycle and configuration.

Exam trap

The trap here is that candidates often confuse `kubectl get pod -o yaml` with `kubectl describe pod`, not realizing that `describe` includes the event history and a human-readable state summary that `get -o yaml` omits.

How to eliminate wrong answers

Option A is wrong because `kubectl logs my-pod` only streams the stdout/stderr output from the container(s), not metadata like events, labels, or container state. Option C is wrong because `kubectl get pod my-pod -o yaml` outputs the full Kubernetes object manifest in YAML, which includes labels and container state but does NOT include the event history or the human-readable summary of conditions and recent state transitions. Option D is wrong because `kubectl top pod my-pod` shows real-time CPU and memory usage metrics from the metrics-server, not events, labels, or container state details.

Full explanation →

713

MCQhard

You have a Deployment that must run a legacy application that takes up to 5 minutes to start. You need to ensure the liveness probe does not kill the container prematurely. Which probe configuration should you use?

A.Use a HTTP GET liveness probe with path /healthz and port 8080

B.Set livenessProbe.initialDelaySeconds to 300

C.Configure a startup probe with a high failureThreshold and appropriate initialDelaySeconds

D.Set livenessProbe.periodSeconds to a high value, like 300

AnswerC

Configuring a startup probe with a high failureThreshold and an appropriate initialDelaySeconds is the correct approach: the kubelet runs the startup probe first and disables liveness and readiness probes until the startup probe succeeds. By setting failureThreshold high and periodSeconds short (for example, 30 failures x 2 seconds), you give the application up to 60 seconds to initialize without risking a restart, while still detecting a true startup failure. Once the startup probe passes, the normal liveness and readiness probes take over, ensuring ongoing health checks are responsive and do not interfere with the boot sequence.

Why this answer

A startup probe is specifically designed for slow-starting containers. It runs before the liveness probe and allows the container extra time to initialize without being killed. By setting a high failureThreshold (e.g., 30) and an appropriate initialDelaySeconds, the probe can wait up to 5 minutes for the application to start, after which the liveness probe takes over.

Exam trap

The trap here is that candidates often confuse initialDelaySeconds with a solution for slow starts, but it only delays the first probe and does not prevent the liveness probe from killing the container if the app takes longer than the sum of initialDelaySeconds and the failure threshold interval.

How to eliminate wrong answers

Option A is wrong because a simple HTTP GET liveness probe without any delay or threshold adjustments would start immediately and kill the container after the default failure threshold (3 failures) within seconds, not allowing the 5-minute startup time. Option B is wrong because setting livenessProbe.initialDelaySeconds to 300 only delays the first liveness check but does not prevent the probe from failing quickly after that; the container could still be killed if the application takes the full 5 minutes to respond, as the probe would fail after the initial delay and hit the failure threshold. Option D is wrong because setting livenessProbe.periodSeconds to a high value like 300 reduces the frequency of checks but does not prevent the probe from failing on its first check after the initial delay; the container could still be killed before the application starts if the probe fails immediately.

Full explanation →

714

MCQmedium

A pod uses a ServiceAccount 'my-sa' but the pod's container needs to list pods in the namespace. Which RBAC resources are necessary?

A.Role and RoleBinding

B.Role and ClusterRoleBinding

C.ServiceAccount and RoleBinding only

D.ClusterRole and ClusterRoleBinding

AnswerA

This combination is correct because the pod's ServiceAccount needs permissions only within its own namespace. A Role defines namespace-scoped rules—such as get/list pods in the specified namespace—and the RoleBinding links that Role to the ServiceAccount as the subject. Since both the Role and the ServiceAccount exist in the same namespace, the RoleBinding can directly grant the pod's identity exactly the permissions it needs without exposing them cluster-wide.

Why this answer

A Role and RoleBinding are necessary because the pod's ServiceAccount 'my-sa' needs permissions to list pods within a specific namespace. A Role defines the allowed API operations (e.g., 'list pods') scoped to a namespace, and a RoleBinding binds that Role to the ServiceAccount, granting those permissions within that namespace. This is the standard RBAC pattern for namespace-scoped access in Kubernetes.

Exam trap

CNCF often tests the distinction between namespace-scoped and cluster-scoped RBAC resources, trapping candidates who assume that any 'list pods' operation requires a ClusterRole, when in fact a Role and RoleBinding are sufficient for a single namespace.

How to eliminate wrong answers

Option B is wrong because a ClusterRoleBinding would grant cluster-wide permissions, which is excessive and unnecessary for listing pods in a single namespace; a RoleBinding is sufficient. Option C is wrong because a ServiceAccount alone does not grant permissions; it requires a Role (or ClusterRole) to define the allowed actions, and a RoleBinding to associate them. Option D is wrong because a ClusterRole and ClusterRoleBinding grant permissions across all namespaces, which is overkill and violates the principle of least privilege for a namespace-scoped operation.

Full explanation →

715

MCQeasy

Which of the following commands creates a LoadBalancer Service named `web-svc` for a Deployment named `web` on port 80?

A.kubectl create service web-svc --port=80 --type=LoadBalancer

B.kubectl expose deployment web --name=web-svc --port=80 --type=LoadBalancer

C.kubectl create deployment web --expose --port=80 --type=LoadBalancer

D.kubectl expose pod web --port=80 --type=LoadBalancer

AnswerB

This is the correct command because `kubectl expose deployment web` reads the Deployment's pod template labels and automatically creates a Service whose selector matches those labels, ensuring the Service routes traffic to all pods managed by the Deployment. The `--type=LoadBalancer` flag requests an external load balancer from the cloud provider, `--name=web-svc` assigns a stable DNS name, and `--port=80` sets the Service's forward port. This is the standard imperative way to create a LoadBalancer Service that fronts a Deployment.

Why this answer

`kubectl expose deployment` creates a Service from an existing Deployment, and the `--name` flag sets the Service name to `web-svc`. The `--port=80` and `--type=LoadBalancer` flags configure the Service to listen on port 80 and expose it externally via a cloud load balancer, which is the standard way to create a LoadBalancer Service for a Deployment.

Exam trap

The CKAD exam often tests the distinction between `kubectl expose` (which creates a Service from an existing resource) and `kubectl create service` (which creates a standalone Service without a selector), leading candidates to pick Option A because they think 'create service' is the correct verb for making a Service.

How to eliminate wrong answers

Option A is wrong because `kubectl create service web-svc --port=80 --type=LoadBalancer` creates a Service without linking it to a Deployment; it lacks a selector to target the `web` Deployment's pods, so the Service would have no endpoints. Option C is wrong because `kubectl create deployment web --expose --port=80 --type=LoadBalancer` is invalid syntax; `--expose` creates a ClusterIP Service by default, and `--type=LoadBalancer` is not a valid flag for `kubectl create deployment`. Option D is wrong because `kubectl expose pod web --port=80 --type=LoadBalancer` creates a Service for a single pod named `web`, not for the `web` Deployment, and the Service would target that specific pod rather than the Deployment's replica set, which is not the intended behavior for a Deployment-backed Service.

Full explanation →

716

MCQhard

A Service of type LoadBalancer is created but the external IP remains <pending>. What is the most likely reason?

A.The Service port is already in use

B.The Service selector does not match any Pods

C.The cluster does not have a cloud provider configured

D.The Pods are not listening on the container port

AnswerC

A pending external IP on a LoadBalancer Service almost always indicates that no cloud provider integration is active in the cluster. The component responsible for creating and managing the cloud load balancer is the cloud-controller-manager (or an in-tree cloud provider in older versions); if it is not running or the cluster is on bare metal, the Service will never transition out of the '<pending>' state. This is a common scenario in minikube, kind, or on-premises deployments, where you need a solution like MetalLB to provide LB functionality.

Why this answer

A LoadBalancer Service in Kubernetes relies on an external cloud provider (e.g., AWS, GCP, Azure) to provision a real load balancer and assign its external IP. If no cloud provider is configured (e.g., in a bare-metal or Minikube cluster), the external IP will remain <pending> indefinitely because there is no controller to allocate the IP.

Exam trap

The trap here is that candidates often confuse a LoadBalancer's external IP assignment with Pod readiness or port availability, but the core requirement is a functioning cloud provider integration to allocate the external IP.

How to eliminate wrong answers

Option A is wrong because a port conflict would cause the Service creation to fail or the NodePort assignment to error, not leave the external IP as <pending>. Option B is wrong because mismatched selectors would result in no endpoints for the Service, but the external IP would still be assigned by the cloud provider if one were configured. Option D is wrong because Pods not listening on the container port would cause connection failures, but the LoadBalancer external IP assignment is independent of Pod readiness.

Full explanation →

717

Multi-Selecthard

You need to perform a canary deployment using a Service and two Deployments (stable and canary). Which TWO resources or configurations are typically used to route a percentage of traffic to the canary? (Select TWO)

Select 2 answers

A.Service Mesh (e.g., Istio VirtualService)

B.A single Service with multiple label selectors

C.NetworkPolicy

D.Ingress with canary annotation

E.HorizontalPodAutoscaler

AnswersA, D

A service mesh such as Istio provides VirtualService and DestinationRule resources that split traffic between the stable and canary Deployments by weighted percentages, giving fine-grained, L7 control that a plain Kubernetes Service cannot achieve on its own.

Why this answer

Option A (Service Mesh, e.g., Istio VirtualService) is correct because a service mesh like Istio can split traffic between the stable and canary Deployments at the L7 level, using VirtualService/DestinationRule weights to send a precise percentage of requests to the canary subset. Option D (Ingress with canary annotation) is correct because ingress controllers such as NGINX Ingress support canary annotations (e.g., nginx.ingress.kubernetes.io/canary and canary-weight) to route a defined percentage of traffic to a canary backend Service. Option B is not valid because a Kubernetes Service has a single label selector and cannot natively split traffic by percentage across two Deployments.

Option C is incorrect because NetworkPolicy only controls L3/L4 pod-level ingress/egress firewall rules, not HTTP traffic weighting. Option E is incorrect because a HorizontalPodAutoscaler only scales replica counts based on metrics and does not perform traffic routing or canary splitting.

Exam trap

A common misconception in CKAD is that a single Service with multiple selectors can split traffic by percentage, when in fact Kubernetes Services only support label-based selection and round-robin load balancing without weighted routing.

Full explanation →

718

MCQhard

You have a Helm chart for an application. After running 'helm install my-release ./mychart', you realize you forgot to set a required value. Which command can you use to update the release with the correct value while keeping the same chart version?

A.kubectl edit deployment my-release

B.helm install my-release ./mychart --set key=value

C.helm upgrade my-release ./mychart --set key=value

D.helm rollback my-release 1

AnswerC

helm upgrade my-release ./mychart --set key=value is the correct Helm-native way to apply new chart values to an existing release. The upgrade command compares the current release's manifests (from the last rendered chart) with the desired state rendered from ./mychart combined with the new --set key=value override, then computes and applies a Kubernetes patch to update only changed resources. It increments the release revision, updates the Helm release metadata, and preserves prior revisions so the change can be rolled back if needed.

Why this answer

Helm upgrade modifies a release with new values or chart changes. The --set flag overrides values inline.

Full explanation →

719

MCQmedium

You have a Deployment named 'web-app' with 3 replicas. You want to expose the pods on port 80 internally within the cluster using a ClusterIP service. Which kubectl command should you use?

A.kubectl expose deployment web-app --port=80 --target-port=8080

B.kubectl create service clusterip web-app --tcp=80:8080

C.kubectl create service nodeport web-app --tcp=80:8080

D.kubectl expose pod web-app --port=80 --target-port=8080

AnswerA

kubectl expose deployment web-app --port=80 --target-port=8080 creates a ClusterIP service automatically using the Deployment's pod selector, so traffic on port 80 is forwarded to port 8080 on all three replicas. It is the correct approach because the service tracks the Deployment's labels, giving it a stable cluster-internal IP and load-balancing across healthy pods, and it remains correct across scale events and rolling updates.

Why this answer

`kubectl expose deployment web-app --port=80 --target-port=8080` creates a ClusterIP Service that maps port 80 on the Service to port 8080 on the Pods, allowing internal cluster traffic to reach the application. The `--port` flag defines the Service's listening port, while `--target-port` specifies the container port the traffic is forwarded to, which is essential when the container listens on a different port than the Service exposes.

Exam trap

The trap here is that candidates often confuse `kubectl expose` with `kubectl create service`, not realizing that `kubectl create service` does not automatically inherit the selector from an existing workload, leading to a Service that has no endpoints and fails to route traffic.

How to eliminate wrong answers

Option B is wrong because `kubectl create service clusterip web-app --tcp=80:8080` creates a Service with an arbitrary name 'web-app' but does not link it to the existing Deployment's selector labels, so it will not route traffic to the Pods managed by the Deployment. Option C is wrong because `kubectl create service nodeport web-app --tcp=80:8080` creates a NodePort Service, which exposes the Service on a static port on each Node's IP, not a ClusterIP-only Service as required by the question. Option D is wrong because `kubectl expose pod web-app --port=80 --target-port=8080` attempts to expose a single Pod named 'web-app', but 'web-app' is a Deployment, not a Pod, so this command will fail or create a Service targeting a non-existent resource.

Full explanation →

720

MCQmedium

A Deployment named 'app' has the following strategy: type: RollingUpdate with maxSurge=1 and maxUnavailable=0. You have 5 replicas. During a rolling update, how many pods will be running at any given time?

A.Between 5 and 6

B.Between 4 and 5

C.Between 5 and 10

D.Exactly 5

AnswerA

With maxUnavailable=0, the Deployment controller guarantees that the desired 5 pods remain available throughout the update, so the available count never falls below 5. At the same time, maxSurge=1 allows at most one additional pod to be created above the desired count, capping the total at 6 (5 old + 1 new, or 5 new + 1 old). Therefore the running pod count stays between 5 and 6 for the duration of the rolling update.

Why this answer

With maxSurge=1 and maxUnavailable=0 on a 5-replica Deployment, Kubernetes must keep all 5 original pods available at all times while it may temporarily add 1 extra pod above the desired count. Therefore the total number of running pods ranges from 5 (when no surge pod exists yet) up to 6 (when one surge pod is created before an old one is terminated). The rollout proceeds by creating one new pod, waiting for it to become Ready, then terminating one old pod, keeping the count between 5 and 6.

Exam trap

CKAD often tests the confusion between maxSurge and maxUnavailable — candidates incorrectly assume maxUnavailable=0 means no extra pods can be created, or that maxSurge adds to the total rather than defining a temporary ceiling.

How to eliminate wrong answers

Option B is wrong because maxUnavailable=0 explicitly forbids dropping below the desired replica count, so the minimum is 5, not 4. Option C is wrong because maxSurge=1 limits the surge to a single extra pod, so the maximum is 6, not 10 (10 would require maxSurge=5 or 100%). Option D is wrong because maxSurge=1 permits a temporary extra pod, so the count is not fixed at exactly 5 — it fluctuates between 5 and 6 during the rollout.

Full explanation →

721

MCQeasy

A pod is scheduled but remains in 'Pending' state. Running 'kubectl describe pod mypod' shows: '0/1 nodes are available: 1 Insufficient memory'. What is the most likely cause?

A.The pod's memory request exceeds the available memory on any node

B.The pod is using too many CPU resources

C.The pod's memory limit is too low

D.The pod's container is crashing due to a bug

AnswerA

The Kubernetes scheduler only assigns a pod to a node when it can satisfy the pod's total resource requests against the node's allocatable capacity. If the sum of memory requests across all containers in the pod exceeds the available (unrequested) memory on every node, the pod remains in Pending with a scheduling failure. The event 'Insufficient memory' confirms that no node has enough unreserved memory to guarantee the requested amount. Remember that requests, not limits, are the scheduling constraint.

Why this answer

The '0/1 nodes are available: 1 Insufficient memory' message indicates that the Kubernetes scheduler attempted to place the pod on a node but found that the node's allocatable memory is less than the pod's memory request. The pod's memory request must be satisfied by at least one node for scheduling to succeed; if no node has enough unallocated memory, the pod remains Pending. This is a resource request, not a limit, that gates scheduling.

Exam trap

The trap here is that candidates confuse memory requests with memory limits, assuming that setting a low limit (or no limit) would fix scheduling, when in fact the scheduler only evaluates requests, not limits.

How to eliminate wrong answers

Option B is wrong because the error message explicitly mentions 'Insufficient memory', not CPU; insufficient CPU would produce a different message like 'Insufficient cpu'. Option C is wrong because a low memory limit does not prevent scheduling—limits are enforced at runtime by the kubelet, not by the scheduler; the scheduler only considers requests. Option D is wrong because a crashing container would result in a CrashLoopBackOff or Error state, not a Pending state; Pending means the pod has not been scheduled to a node yet.

Full explanation →

722

MCQmedium

You have a service account 'my-sa' in the default namespace. You want a pod to use this service account and also prevent the pod from mounting the service account token. Which pod spec configuration is correct?

A.spec: serviceAccountName: my-sa automountServiceAccountToken: true

B.spec: serviceAccount: my-sa automountServiceAccountToken: true

C.spec: serviceAccountName: my-sa automountServiceAccountToken: false

D.spec: serviceAccountName: default automountServiceAccountToken: false

AnswerC

This is the correct configuration: it sets serviceAccountName to 'my-sa', giving the pod the RBAC identity and permissions associated with that service account, and sets automountServiceAccountToken: false to prevent the kubelet from placing the service account token inside the container. This ensures the pod can authenticate or be authorized as 'my-sa' where needed, but the token is not exposed on the filesystem, exactly as the requirement demands. The combination is the canonical way to decouple service account identity from token accessibility.

Why this answer

Setting `automountServiceAccountToken: false` in the pod spec prevents the automatic mounting of the service account token, while `serviceAccountName: my-sa` specifies the desired service account. This satisfies both requirements: using the custom service account and disabling token mounting.

Exam trap

CNCF often tests the distinction between the deprecated `serviceAccount` field and the current `serviceAccountName` field, as well as the default `true` value of `automountServiceAccountToken`, leading candidates to overlook the need to explicitly set it to `false` when token mounting must be prevented.

How to eliminate wrong answers

Option A is wrong because `automountServiceAccountToken: true` explicitly mounts the token, which contradicts the requirement to prevent token mounting. Option B is wrong because it uses the deprecated `serviceAccount` field (instead of `serviceAccountName`) and sets `automountServiceAccountToken: true`, which again mounts the token. Option D is wrong because it specifies the `default` service account instead of `my-sa`, failing to use the required service account.

Full explanation →

723

MCQeasy

Which command creates a Service named 'my-svc' that exposes a deployment named 'my-deploy' on port 80?

A.kubectl create service my-svc --port=80 --target-port=80

B.kubectl run my-svc --expose --port=80 --image=my-image

C.kubectl create svc clusterip my-svc --tcp=80:80

D.kubectl expose deployment my-deploy --name=my-svc --port=80

AnswerD

This is the correct command because it creates a Service from an existing deployment. `kubectl expose` reads the deployment's label selector and applies it to the Service, ensuring the Service forwards traffic to the pods managed by `my-deploy`. The `--name` flag customizes the Service name while `--port=80` defines the exposed port, with `targetPort` defaulting to the pod's container port.

Why this answer

The `kubectl expose` command is specifically designed to create a Service from an existing resource like a Deployment. By specifying `deployment my-deploy`, `--name=my-svc`, and `--port=80`, it generates a ClusterIP Service that routes traffic to the pods selected by the deployment's labels on port 80.

Exam trap

The trap here is that candidates often confuse `kubectl create service` (which requires a service type and does not link to a deployment) with `kubectl expose` (which is the correct imperative command to create a Service from an existing resource), leading them to pick Option A or C without realizing the missing selector linkage.

How to eliminate wrong answers

Option A is wrong because `kubectl create service` requires a service type (e.g., `clusterip`, `nodeport`) and does not accept a deployment reference; it creates an orphaned Service without proper selector labels matching the deployment. Option B is wrong because `kubectl run` with `--expose` creates a Pod (not a Deployment) and a Service, but the Service name defaults to the run name, and the `--name` flag is not valid here; it also requires `--image` which is irrelevant to exposing an existing deployment. Option C is wrong because `kubectl create svc clusterip` creates a Service with the specified name as the first argument (e.g., `my-svc`), but the `--tcp=80:80` flag sets the port mapping, and the command does not link to any existing deployment; the Service will lack correct selectors unless manually added.

Full explanation →

724

MCQeasy

What is the purpose of an init container in a pod?

A.To check the health of the main container and restart it if necessary

B.To run alongside the main container and provide additional services

C.To run to completion before the main containers start, often for initialization tasks

D.To run a command after the main container starts

AnswerC

Init containers run sequentially to completion before the main containers start, performing setup such as fetching configuration, waiting for dependencies or setting permissions. Because they finish first, the main containers begin only once initialisation succeeds, which is their defining purpose within the pod lifecycle.

Why this answer

Init containers run to completion sequentially before any main containers in the pod start. They are designed for initialization tasks such as setting up databases, waiting for external services, or populating configuration files. Unlike sidecar containers, they do not run alongside the main containers and must exit successfully before the pod transitions to the Running phase.

Exam trap

CKAD often tests the distinction between init containers and sidecar containers, where candidates mistakenly think init containers run alongside main containers or perform health checks, when in fact they run to completion before any main containers start.

How to eliminate wrong answers

Option A is wrong because health checks (liveness probes) are performed by the kubelet on the main container, not by an init container. Option B is wrong because containers that run alongside the main container are sidecar containers, not init containers. Option D is wrong because init containers run before the main containers start, not after; a postStart lifecycle hook runs a command after the main container starts, but that is not an init container.

Full explanation →

725

MCQeasy

Which field in a CronJob spec specifies the maximum number of successful jobs that should be retained?

A..spec.jobTemplate.spec.backoffLimit

B..spec.successfulJobsHistoryLimit

C..spec.jobHistory.succeeded

D..spec.history.successfulJobsLimit

AnswerB

The correct field is .spec.successfulJobsHistoryLimit, a top-level CronJob spec attribute that sets the maximum number of successfully completed Job objects to keep. Its default value is 3, and setting it to zero disables retention entirely, causing the CronJob controller to delete each successful Job as soon as it finishes. This field directly controls the number of historical Job objects visible in the cluster, distinct from failedJobsHistoryLimit which governs failed Jobs.

Why this answer

The `.spec.successfulJobsHistoryLimit` field in a CronJob spec explicitly controls the number of successful jobs that are retained after completion. This field defaults to 3 and, when set to 0, suppresses the retention of any successful job history, directly managing cluster resource usage by limiting the accumulation of completed Pods.

Exam trap

The trap here is that candidates confuse `backoffLimit` (retry logic) with history limits, or invent plausible-sounding field paths like `.spec.jobHistory.succeeded` that mimic the correct field but use incorrect nesting or naming.

How to eliminate wrong answers

Option A is wrong because `.spec.jobTemplate.spec.backoffLimit` defines the number of retries for a failed Job (default 6), not the retention of successful jobs. Option C is wrong because `.spec.jobHistory.succeeded` is not a valid field in the CronJob API; the correct field path is `.spec.successfulJobsHistoryLimit`. Option D is wrong because `.spec.history.successfulJobsLimit` does not exist in the Kubernetes API; the proper field uses `successfulJobsHistoryLimit` under the spec, not a nested `history` object.

Full explanation →

726

Multi-Selectmedium

Which TWO statements about Kubernetes Services are correct? (Choose two.)

Select 2 answers

A.Services can only route traffic based on named ports.

B.A Service provides a stable endpoint for a set of pods.

C.A Service uses label selectors to identify the target pods.

D.Services can only route traffic to pods in the same namespace.

E.Every Service must have a cluster IP assigned.

AnswersB, C

A Service provides a stable virtual IP address and a corresponding DNS name that remain constant even as the underlying Pods are scaled, rescheduled, or replaced. Because Pod IPs are ephemeral by nature, clients can rely on the Service address as the durable network endpoint for a logical application, and traffic is load-balanced across the current set of Pods. This stable endpoint is the primary reason Services are used for inter-Pod communication.

Why this answer

A Kubernetes Service provides a stable virtual IP and DNS name that remains constant even as the underlying pods are created, destroyed, or rescheduled. This decouples clients from the ephemeral nature of pod IPs, ensuring reliable connectivity to the pod group.

Exam trap

The trap here is that candidates often assume Services require a cluster IP or can only use named ports, but the CKAD exam tests knowledge of headless Services and the flexibility of port definitions.

Full explanation →

727

MCQhard

You are deploying a Pod that contains two containers: a web server and a file sync agent. The file sync agent needs to run as long as the web server is running and should share the same network namespace. Which design pattern does this represent?

A.Adapter pattern

B.Ambassador pattern

C.Init container pattern

D.Sidecar pattern

AnswerD

The sidecar pattern is precisely the design where an additional container is deployed in the same Pod alongside the main application container to augment its capabilities without changing its code. Sidecars share the Pod lifecycle and can provide functionality such as log collection, metrics scraping, health endpoints, or service mesh traffic handling. This matches the described scenario of a web container being paired with a supporting service, making the sidecar pattern the correct answer.

Why this answer

The Sidecar pattern (D) is correct because it describes a secondary container that runs alongside a primary container in the same Pod, sharing the same network namespace and lifecycle. In this scenario, the file sync agent is a helper that must run as long as the web server runs and share its network stack, which is exactly what a sidecar container does — it extends or enhances the primary container's functionality without being its own separate Pod.

Exam trap

The trap here is confusing the Sidecar pattern with the Init container pattern, because both involve multiple containers in a Pod, but Init containers run to completion before the main containers start and do not share the network namespace during the main container's runtime.

How to eliminate wrong answers

Option A is wrong because the Adapter pattern standardizes interfaces between containers (e.g., converting logs or metrics formats), not sharing a network namespace or running alongside for the entire lifecycle. Option B is wrong because the Ambassador pattern proxies network traffic to external services (e.g., a Redis proxy), not synchronizing files locally with the primary container. Option C is wrong because the Init container pattern runs to completion before the main containers start and does not share the network namespace with the main containers during runtime; it exits after initialization, whereas the file sync agent must run continuously.

Full explanation →

728

MCQhard

You are using Helm to manage an application. After running 'helm install myapp ./mychart', you notice that the application is running but you need to change a configuration value. Which command should you use to update the release?

A.helm update myapp ./mychart

B.helm install myapp ./mychart --replace

C.kubectl edit deployment myapp

D.helm upgrade myapp ./mychart --set key=value

AnswerD

`helm upgrade myapp ./mychart --set key=value` is the correct command because it tells Helm to update the existing release `myapp` using the chart at `./mychart`, while `--set` overrides the chart's default value for `key`. Helm increments the release revision, applies a calculated patch to the cluster resources, and records the new values in its history so the change can be rolled back if needed. This is the standard Helm workflow for updating an application after the initial `helm install`.

Why this answer

'helm upgrade' is the correct command to update an existing release with new chart values or a new chart version. Passing '--set key=value' overrides a specific value at upgrade time, and Helm computes a diff against the previous release, applying only the necessary Kubernetes changes. 'helm install' is only for creating new releases.

Exam trap

CKAD often tests whether candidates know the correct Helm verb ('upgrade', not 'update') and whether they understand that editing resources directly with kubectl breaks Helm's release tracking — the trap is choosing the kubectl shortcut for a Helm-managed release.

How to eliminate wrong answers

Option A is wrong because 'helm update' is not a valid Helm subcommand — the correct verb is 'upgrade'. Option B is wrong because 'helm install --replace' is a legacy/edge-case flag that reuses a release name after deletion; it is not the standard way to modify a running release and can cause downtime. Option C is wrong because 'kubectl edit deployment' bypasses Helm entirely, causing the live state to drift from the Helm release state; the next 'helm upgrade' would overwrite the manual edit, and 'helm rollback' would not capture it.

Full explanation →

729

Multi-Selectmedium

Which TWO of the following are valid ways to consume environment variables from a ConfigMap in a pod?

Select 2 answers

A.envFrom: - configMapRef: name: myconfig

B.env: - name: VAR configMapRef: name: myconfig key: mykey

C.volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: myconfig

D.env: - name: VAR valueFrom: configMapKeyRef: name: myconfig key: mykey

E.env: - name: VAR valueFrom: configMapRef: name: myconfig key: mykey

AnswersA, D

The envFrom field injects all key-value pairs from the referenced ConfigMap as environment variables into the container. Each key in the ConfigMap becomes an environment variable name, provided the key is a valid environment variable name; invalid keys are skipped. This is a bulk injection method, unlike the selective method used with valueFrom.configMapKeyRef.

Why this answer

`envFrom` with a `configMapRef` injects all key-value pairs from the named ConfigMap as environment variables into the container. This is a concise way to consume multiple variables without specifying each key individually, as defined in the Kubernetes API for Pods.

Exam trap

The trap here is confusing `envFrom` with `env` syntax: candidates often misremember that `configMapRef` can be used directly under `env` (like in Option B), or they confuse `configMapKeyRef` with `configMapRef` (Option E), which is only valid under `envFrom`.

Full explanation →

730

MCQmedium

You need to run a batch job that processes 100 items. The job should be considered complete when all items are processed successfully. You want to run up to 10 pods concurrently. Which job configuration is correct?

A..spec.completions: 10, .spec.parallelism: 100

B..spec.backoffLimit: 100, .spec.parallelism: 10

C..spec.completions: 100, .spec.parallelism: 1

D..spec.completions: 100, .spec.parallelism: 10

AnswerD

This is the correct configuration because .spec.completions specifies the exact number of Pods that must finish successfully (100), and .spec.parallelism limits how many of those Pods can run simultaneously (10). The Job controller creates Pods in waves, using the parallelism value as an upper bound on concurrent execution, while tracking cumulative completions until the target of 100 is reached. This matches the requirement of processing 100 items with up to 10 Pods running at once.

Why this answer

It sets `.spec.completions` to 100 (the total number of items to process) and `.spec.parallelism` to 10 (the maximum number of pods running concurrently). This ensures the Job runs pods in parallel up to the specified limit until all 100 completions are achieved, matching the requirement of processing 100 items with up to 10 concurrent pods.

Exam trap

The trap here is confusing the roles of `.spec.completions` and `.spec.parallelism`, where candidates often swap the values (e.g., setting completions to the concurrency limit) or omit completions entirely, not realizing that both fields are needed to define a parallel Job with a fixed total number of completions.

How to eliminate wrong answers

Option A is wrong because it sets `.spec.completions` to 10 and `.spec.parallelism` to 100, which would only require 10 successful completions (not 100 items) and allow up to 100 concurrent pods, exceeding the limit of 10. Option B is wrong because `.spec.backoffLimit` controls retries on failure, not the number of completions or parallelism; setting it to 100 does not define the total items to process, and `.spec.parallelism` alone without `.spec.completions` defaults to 1 completion, so only one pod would run. Option C is wrong because `.spec.parallelism` is set to 1, which runs pods sequentially, not concurrently, failing the requirement to run up to 10 pods at once.

Full explanation →

731

MCQeasy

Which of the following commands creates a ClusterIP service named 'my-service' that exposes port 80 on the pod with label 'app=web'?

A.kubectl expose deployment my-deployment --port=80 --name=my-service

B.kubectl expose pod my-pod --port=80 --target-port=8080 --name=my-service

C.kubectl create service clusterip my-service --tcp=80:8080 --cluster-ip=10.0.0.1

D.kubectl expose deployment my-deployment --type=NodePort --port=80 --name=my-service

AnswerA

The `kubectl expose deployment my-deployment --port=80 --name=my-service` command correctly creates a ClusterIP service by default because no `--type` flag is specified, so it defaults to `ClusterIP`. It also infers the selector from the deployment's pod template labels (e.g., `app=web`) and sets the service's target port to the container's port (defaulting to 80), allowing automatic traffic routing to the pods managed by the deployment.

Why this answer

`kubectl expose deployment my-deployment --port=80 --name=my-service` creates a ClusterIP service by default, which selects pods based on the labels of the deployment (e.g., `app=web` if the deployment has that label). The `--port=80` flag sets the service port, and the service automatically maps to the container port (defaults to the same port if `--target-port` is omitted). This command satisfies the requirement of exposing port 80 on pods with label `app=web`.

Exam trap

The trap here is that candidates may think `kubectl create service clusterip` is the correct way to create a ClusterIP service with a selector, but it actually creates a service without a selector, requiring manual label specification via `--selector` or a YAML definition.

How to eliminate wrong answers

Option B is wrong because it targets a specific pod (`my-pod`) rather than a set of pods with label `app=web`, and it uses `--target-port=8080`, which would expose port 80 on the service but forward to port 8080 on the pod, not port 80 as required. Option C is wrong because `kubectl create service clusterip` does not automatically select pods based on labels; it creates a service with no selector, so it would not expose pods with label `app=web`. Option D is wrong because it specifies `--type=NodePort`, which creates a NodePort service instead of the required ClusterIP type.

Full explanation →

732

MCQeasy

You need to scale a Deployment named 'api' to 10 replicas instantly. Which command should you use?

A.kubectl autoscale deployment api --min=10 --max=10

B.kubectl patch deployment api -p '{"spec":{"replicas":10}}'

C.kubectl resize deployment api --replicas=10

D.kubectl scale deployment api --replicas=10

AnswerD

The `kubectl scale deployment api --replicas=10` command is the standard, imperative way to directly change the replica count of a Deployment. It updates the Deployment's desired state to 10 replicas, causing the ReplicaSet controller to create or remove Pods until the actual count matches the desired count. This command is explicit, concise, and explicitly designed for scaling resources, making it the correct answer.

Why this answer

`kubectl scale` is the dedicated imperative command to change the replica count of a Deployment instantly. It directly updates the `spec.replicas` field in the Deployment's desired state, causing the controller to immediately create or terminate Pods to match the new count.

Exam trap

The trap here is that candidates may confuse `kubectl autoscale` (which creates an HPA for dynamic scaling) with `kubectl scale` (which performs an immediate, static replica change), or they may invent a non-existent command like `kubectl resize`.

How to eliminate wrong answers

Option A is wrong because `kubectl autoscale` creates a HorizontalPodAutoscaler (HPA) that adjusts replicas dynamically based on metrics, not an instant static change; setting `--min=10 --max=10` would still create an HPA object, not directly scale the Deployment. Option B is wrong because while `kubectl patch` can technically update the replicas field, it is a generic, less idiomatic approach for scaling; the CKAD exam expects the purpose-built `kubectl scale` command for this task. Option C is wrong because `kubectl resize` is not a valid kubectl command; no such subcommand exists in the Kubernetes CLI.

Full explanation →

733

MCQeasy

Which kubectl command creates a Secret named 'db-secret' with key 'password' and value 'mypwd'?

A.kubectl create secret generic db-secret password=mypwd

B.kubectl create secret generic db-secret --from-file=password=mypwd

C.kubectl create secret generic db-secret --from-literal=password=mypwd

D.kubectl create secret generic db-secret --from-env-file=password=mypwd

AnswerC

This is the canonical syntax for creating an Opaque Secret from a single inline key-value pair. The `--from-literal=password=mypwd` flag tells kubectl to split the string on the first `=`, then store the value `mypwd` under the key `password` in the Secret's `data` field (base64-encoded by the API). It is unambiguous and works as intended, though it is worth remembering that the secret value is visible in the shell command and process list, so for production secrets you would normally use `--from-file` or an external secrets manager to avoid exposing credentials.

Why this answer

`kubectl create secret generic` with `--from-literal` allows you to specify key-value pairs directly on the command line. The syntax `--from-literal=password=mypwd` creates a secret with key 'password' and value 'mypwd', which is the exact requirement.

Exam trap

The trap here is that candidates confuse `--from-literal` with `--from-file` or the bare `key=value` syntax, mistakenly thinking any `key=value` format works without the correct flag.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret generic` does not accept a bare `key=value` syntax; it requires a flag like `--from-literal` to specify literal key-value pairs. Option B is wrong because `--from-file` expects a file path, not a literal key-value pair; using `--from-file=password=mypwd` would try to read a file named 'password=mypwd', which does not exist. Option D is wrong because `--from-env-file` expects a file containing environment variables in key=value format, not a single literal key-value pair on the command line.

Full explanation →

734

MCQhard

A Pod with an init container and a main container is created. The init container runs a script that takes 10 seconds. The main container's startupProbe has initialDelaySeconds: 5. When does the startupProbe begin?

A.5 seconds after the pod is created

B.10 seconds after the pod is created

C.Immediately after the pod is created

D.After the init container completes, then plus 5 seconds

AnswerD

The startupProbe begins only after the main container has entered the Running state, which is possible only after all init containers complete successfully. At that point, the kubelet waits the configured initialDelaySeconds—here, 5 seconds—before performing the first probe. Hence the first probe occurs at the init container's total runtime plus 5 seconds, not at pod creation plus 5 seconds.

Why this answer

The startupProbe does not begin until the Pod's containers are actually running. Init containers must complete successfully before any main containers start. Therefore, the startupProbe's initialDelaySeconds of 5 is counted from the moment the main container starts, which is after the init container finishes its 10-second script.

The probe begins 5 seconds after the main container starts, not from Pod creation.

Exam trap

The trap here is that candidates mistakenly think probes start counting from Pod creation time, ignoring the sequential blocking nature of init containers, which must complete before any main container probes are scheduled.

How to eliminate wrong answers

Option A is wrong because it assumes the startupProbe begins 5 seconds after Pod creation, ignoring that init containers must finish first. Option B is wrong because it assumes the probe begins immediately after the init container completes, but the initialDelaySeconds of 5 is still applied after the main container starts. Option C is wrong because probes never begin immediately upon Pod creation; they wait for the container to start and respect any initialDelaySeconds.

Full explanation →

735

MCQhard

Consider the following partial Dockerfile: FROM alpine:3.18 AS builder RUN apk add --no-cache curl COPY src /app/src RUN make /app/bin FROM alpine:3.18 COPY --from=builder /app/bin /app/bin CMD ["/app/bin"] What is the primary benefit of this multi-stage build?

A.Faster builds because the builder stage runs in parallel

B.Reduced final image size by excluding build dependencies

C.Automatic caching of the builder stage

D.Improved security by running the builder as a non-root user

AnswerB

The final image is produced by the last `FROM` line, which in this pattern is a fresh minimal base image. Only specific files copied from the builder stage (e.g., compiled binary, configs) are preserved, while compilers, package managers, and intermediate layer caches from the builder are discarded. This slims the image and simultaneously reduces the number of packages that could contain vulnerabilities.

Why this answer

The primary benefit of a multi-stage build is reduced final image size by excluding build dependencies. The builder stage installs build tools like curl and compiles the application, but only the compiled binary is copied to the final stage, leaving behind the build tools and intermediate files. This results in a smaller, more secure production image.

Exam trap

CKAD often tests the misconception that multi-stage builds primarily improve build speed or security, when the core benefit is reducing final image size by excluding build dependencies.

How to eliminate wrong answers

Option A is wrong because Docker build stages do not run in parallel by default; they run sequentially unless BuildKit is used with specific optimizations, and the primary benefit is not faster builds. Option C is wrong because while Docker layer caching can speed up builds, it is not the primary benefit of multi-stage builds and requires proper layer ordering. Option D is wrong because the Dockerfile does not specify a non-root user for the builder stage, and improved security is a secondary benefit, not the primary one.

Full explanation →

736

MCQmedium

Which field in a Deployment's rolling update strategy controls the maximum number of pods that can be created above the desired replicas during a rolling update?

A.maxUnavailable

B.maxSurge

C.revisionHistoryLimit

D.minReadySeconds

AnswerB

It is the correct field because it defines how many extra pods can be created over the desired replica count during a rolling update, enabling faster rollout by ensuring new pods become ready before old ones are terminated. The default value is 25% of the desired pods, and the total number of pods can temporarily exceed the desired count by this amount.

Why this answer

In a Deployment's rolling update strategy, `maxSurge` controls the maximum number of pods that can be created above the desired replica count during the update. This allows the system to spin up new pods before terminating old ones, ensuring zero downtime. The value can be an absolute number or a percentage of the desired replicas.

Exam trap

The trap here is confusing `maxSurge` with `maxUnavailable`, as both are percentage-based fields in the rolling update strategy, but `maxSurge` controls the extra pods above the desired count while `maxUnavailable` controls the deficit below it.

How to eliminate wrong answers

Option A is wrong because `maxUnavailable` controls the maximum number of pods that can be unavailable during the update, not the number created above the desired count. Option C is wrong because `revisionHistoryLimit` specifies how many old ReplicaSets to retain for rollback, not the surge capacity. Option D is wrong because `minReadySeconds` defines how long a pod must be ready before it is considered available, which affects the rollout speed but not the maximum number of pods above the desired replicas.

Full explanation →

737

MCQhard

You have a pod that takes 2 minutes to start its application. You want to avoid the liveness probe from killing the pod during startup, but still have it active afterward. Which probe should you add to the pod spec?

A.Add a startup probe with a failureThreshold high enough to cover the startup time

B.Increase the timeoutSeconds on the liveness probe

C.Set periodSeconds on the liveness probe to 120

D.Set initialDelaySeconds on the liveness probe to 120

AnswerA

A startup probe is the idiomatic solution because Kubernetes keeps the liveness and readiness probes disabled until this startup probe succeeds, so a slow-starting process is not repeatedly killed. Configure failureThreshold and periodSeconds together so their product comfortably exceeds the ~2 minute startup window (e.g., failureThreshold: 20, periodSeconds: 10). Once the startup probe succeeds, the normal liveness and readiness probes take over, and if the app later fails, it gets restarted.

Why this answer

A startup probe is designed specifically for slow-starting containers. It runs before the liveness probe and, if it fails, the container is killed. By setting a high failureThreshold (e.g., 12 with a 10-second period gives 120 seconds), you allow the application up to 2 minutes to start without the liveness probe interfering.

Once the startup probe succeeds, the liveness probe takes over normally.

Exam trap

The trap here is that candidates often choose initialDelaySeconds (option D) thinking it's the standard way to handle slow starts, but it doesn't account for variable startup times and can mask real failures after the delay expires.

How to eliminate wrong answers

Option B is wrong because increasing timeoutSeconds on the liveness probe only extends how long Kubernetes waits for a single probe response, not the total startup window; the probe still starts immediately and can kill the pod before the app is ready. Option C is wrong because setting periodSeconds to 120 on the liveness probe only makes it check every 2 minutes, but the first check still occurs immediately (or after initialDelaySeconds), so it could kill the pod before the app starts. Option D is wrong because initialDelaySeconds on the liveness probe delays the first probe by 120 seconds, but this is a static delay that doesn't adapt to actual startup time; if the app takes longer than expected, the probe still kills it, and it also delays detection of real failures after startup.

Full explanation →

738

MCQeasy

What is the purpose of a HorizontalPodAutoscaler (HPA)?

A.To update the application version without downtime

B.To restart pods automatically when they fail

C.To distribute incoming traffic across multiple pods

D.To automatically adjust the number of pods based on resource metrics

AnswerD

The HPA controller watches metrics such as CPU utilisation and adjusts a workload's replica count to meet a target, scaling pods horizontally. It satisfies the requirement to match capacity to demand automatically rather than manually resizing deployments.

Why this answer

A HorizontalPodAutoscaler automatically scales the number of pods in a Deployment, ReplicaSet, or StatefulSet based on observed CPU utilization (or other custom metrics).

Full explanation →

739

MCQhard

A developer configures a liveness probe for a container that takes a long time to start (about 120 seconds). The probe uses httpGet on port 8080 with a path '/healthz'. The probe is configured with initialDelaySeconds=10, periodSeconds=10, failureThreshold=3. The pod enters CrashLoopBackOff. What is the MOST likely cause?

A.The failureThreshold should be increased to 10

B.The httpGet path '/healthz' is incorrect and should be '/ready'

C.The readiness probe is misconfigured and should be used instead of a liveness probe

D.The liveness probe is failing too early because initialDelaySeconds is too low for the slow-starting container

AnswerD

The liveness probe is configured to begin only 10 seconds after container start (initialDelaySeconds=10), but the application requires 120 seconds to initialize and listen on its health endpoint. During those first 110 seconds, the probe returns HTTP 500 or fails to connect, and after the default failureThreshold (3) consecutive failures, Kubernetes kills and restarts the container. This restart loop never gives the application the 120 seconds it needs, so it never becomes healthy. By setting initialDelaySeconds to 120 or adding a startup probe with a longer period, the container can finish starting before liveness checks begin.

Why this answer

The liveness probe is configured with initialDelaySeconds=10, which means Kubernetes will start probing 10 seconds after the container starts. Since the application takes about 120 seconds to become healthy, the probe will fail immediately. With failureThreshold=3 and periodSeconds=10, the probe will fail after 30 seconds (3 * 10s), causing Kubernetes to restart the container before it has finished initializing, leading to CrashLoopBackOff.

Exam trap

The trap here is that candidates often focus on the probe path or failure threshold, but the real issue is that initialDelaySeconds is set too low for a slow-starting container, causing premature restarts.

How to eliminate wrong answers

Option A is wrong because increasing failureThreshold would only delay the inevitable restart by a few more cycles; the core issue is that the probe starts too early, not that it gives up too quickly. Option B is wrong because the path '/healthz' is a common and valid endpoint for liveness checks; the problem is timing, not the endpoint name. Option C is wrong because a readiness probe would not prevent the container from being restarted; liveness probes are responsible for restarting unhealthy containers, and readiness probes only control traffic routing.

Full explanation →

740

MCQeasy

You need to create a Job that runs a single task to completion. Which kubectl command correctly creates a Job named 'data-processor' that runs the image 'myapp/processor:1.0'?

A.kubectl create deployment data-processor --image=myapp/processor:1.0

B.kubectl create job data-processor --image=myapp/processor:1.0

C.kubectl run data-processor --image=myapp/processor:1.0 --restart=Never

D.kubectl create cronjob data-processor --image=myapp/processor:1.0

AnswerB

kubectl create job data-processor --image=myapp/processor:1.0 explicitly creates a Job resource, which is the designated controller for finite tasks that must run to completion. The Job controller will create a Pod from the specified image and monitor it; with default settings, it runs a single Pod and marks the Job as complete when that Pod exits with code 0. It also provides automatic retries on failure up to the backoffLimit, making it the correct imperative command for a one-time batch task.

Why this answer

`kubectl create job` is the dedicated command to create a Job resource, which runs a pod to completion without restarting the container after success. The Job controller ensures the pod runs exactly once, making it ideal for batch processing tasks.

Exam trap

The trap here is that candidates often confuse `kubectl run` with `--restart=Never` as a valid way to create a Job, but it only creates a Pod, missing the Job controller's automatic retry and completion tracking.

How to eliminate wrong answers

Option A is wrong because `kubectl create deployment` creates a Deployment, which manages a ReplicaSet to maintain a desired number of pods running continuously, not a single task to completion. Option C is wrong because `kubectl run` with `--restart=Never` creates a standalone Pod, not a Job; the Pod will not be automatically retried if it fails, and it lacks the Job controller's lifecycle management. Option D is wrong because `kubectl create cronjob` creates a CronJob, which schedules Jobs on a recurring basis, not a one-time task.

Full explanation →

741

MCQhard

You want to enforce that all pods in a namespace run with the 'restricted' Pod Security Standard (Pod Security Admission). Which label should you set on the namespace?

A.pod-security.kubernetes.io/warn=restricted

B.pod-security.kubernetes.io/enforce=baseline

C.pod-security.kubernetes.io/enforce=restricted

D.pod-security.kubernetes.io/audit=restricted

AnswerC

The pod-security.kubernetes.io/enforce=restricted label is correct because it instructs the Pod Security Admission controller to use the most secure level of the Kubernetes Pod Security Standards. All pods (and pod templates in workloads) are checked against the restricted profile during admission, and if they fail—for example, by allowing privilege escalation, setting privileged: true, or omitting a required seccompProfile—the API server rejects the request. This guarantees that every pod running in the namespace adheres to a hardened, baseline-plus configuration. Using enforce mode (rather than warn or audit) is the only option that actually blocks non-compliant pods.

Why this answer

The `pod-security.kubernetes.io/enforce=restricted` label enforces the 'restricted' Pod Security Standard on the namespace, preventing any pod that violates the restricted policy from being created. This label directly activates Pod Security Admission (PSA) enforcement mode, which blocks non-compliant pods at admission time.

Exam trap

The trap here is that candidates often confuse the three PSA modes (enforce, warn, audit) and select a 'warn' or 'audit' label thinking it blocks non-compliant pods, when only 'enforce' actually prevents pod creation.

How to eliminate wrong answers

Option A is wrong because `pod-security.kubernetes.io/warn=restricted` only generates a warning for non-compliant pods but does not enforce the policy, so pods violating the restricted standard would still be created. Option B is wrong because `pod-security.kubernetes.io/enforce=baseline` enforces the 'baseline' standard, which is less restrictive than 'restricted' and allows some privileged configurations that the restricted standard would block. Option D is wrong because `pod-security.kubernetes.io/audit=restricted` only logs violations to the audit log without blocking or warning, so pods violating the restricted standard would still be admitted.

Full explanation →

742

Multi-Selecthard

Which THREE statements about Dockerfile CMD and ENTRYPOINT are correct?

Select 3 answers

A.CMD is always ignored if ENTRYPOINT is defined.

B.CMD can be overridden at container runtime by specifying a command after the image name.

C.ENTRYPOINT can be overridden at container runtime using the --entrypoint flag.

D.If both CMD and ENTRYPOINT are specified, CMD provides default arguments to ENTRYPOINT.

E.If neither CMD nor ENTRYPOINT is specified, the container will run but exit immediately.

AnswersB, C, D

When you run a container, any command-line arguments you place after the image name are passed to the image's entrypoint and replace the CMD instruction entirely. This behavior is fundamental to how Docker separates the immutable executable (ENTRYPOINT) from the default parameters (CMD), allowing runtime flexibility without rebuilding the image. For example, `docker run nginx -v` overrides the CMD (e.g., `nginx -g daemon off;`) with `-v`, which would be interpreted by the entrypoint.

Why this answer

Only three statements are correct. Option A is false because CMD is not ignored when ENTRYPOINT is defined; CMD provides default arguments to ENTRYPOINT. Option B is correct: specifying a command after the image name at runtime overrides CMD.

Option C is correct: ENTRYPOINT can be overridden with `--entrypoint` flag. Option D is correct: CMD provides default arguments to ENTRYPOINT when both are present. Option E is incorrect because if neither CMD nor ENTRYPOINT is specified, the container inherits the base image's default command, which may keep it running (e.g., a shell) or cause it to exit; it does not always run and exit immediately.

Exam trap

A common misconception is that CMD is ignored when ENTRYPOINT is present, but the correct behavior is that CMD becomes default arguments for ENTRYPOINT unless overridden.

Full explanation →

743

MCQhard

You have a Deployment named 'api' with 3 replicas. You need to ensure that new pods are not added to the Service's endpoints until the application is ready to serve traffic. Which probe configuration should you add to the pod spec?

A.Readiness probe

B.No probe is needed; pods are automatically added when running

C.Startup probe

D.Liveness probe

AnswerA

Readiness probe is the only mechanism that determines whether a pod should receive traffic from a Service. When the probe fails, the kubelet sets the pod's Ready condition to false, and the EndpointSlice controller removes that pod's IP from the Service's endpoints. For a Deployment with 3 replicas, this ensures only fully initialized and healthy-app-ready pods are behind the Service, preventing connection errors during startup or temporary stalls.

Why this answer

A Readiness probe is the correct choice because it controls whether a pod is added to a Service's endpoints. Kubernetes will only mark a pod as Ready when the probe succeeds, and only Ready pods receive traffic from the Service. This ensures new pods are not added until the application is ready to serve traffic.

Exam trap

The trap here is that candidates confuse Liveness probes (which restart pods) with Readiness probes (which control traffic routing), or assume that a running pod is automatically considered ready for Service endpoints.

How to eliminate wrong answers

Option B is wrong because Kubernetes does not automatically add pods to Service endpoints when they are running; it only adds pods that pass their Readiness probe. Option C is wrong because a Startup probe is used to determine when an application has started, not when it is ready to serve traffic; it delays the start of Liveness and Readiness probes but does not control Service endpoint membership. Option D is wrong because a Liveness probe is used to determine if a pod should be restarted, not to control traffic routing; it does not affect whether a pod is added to a Service's endpoints.

Full explanation →

744

MCQmedium

When performing a rolling update of a Deployment, which field in the Deployment spec controls the maximum number of Pods that can be created above the desired replicas during the update?

A.spec.strategy.type

B.spec.strategy.rollingUpdate.maxSurge

C.spec.strategy.rollingUpdate.maxUnavailable

D.spec.replicas

AnswerB

`spec.strategy.rollingUpdate.maxSurge` is the correct field because it explicitly caps how many Pods can be temporarily created above the desired replica count during a rolling update. It can be configured as an absolute number or as a percentage of `spec.replicas`, giving the controller permission to overshoot the target while replacing old Pods. This overshoot allows new Pods to become ready before old ones are terminated, reducing downtime. Without this field, the default value is 25%, meaning Kubernetes will not create more than 25% extra Pods beyond the replica target.

Why this answer

maxSurge defines how many Pods can be created above the desired replica count during a rolling update.

Full explanation →

745

MCQmedium

You run 'kubectl rollout undo deployment/app'. What happens?

A.It rolls back the Deployment to the previous revision

B.It pauses the rollout

C.It shows the rollout history

D.It deletes the Deployment

AnswerA

`kubectl rollout undo deployment app` reverts the Deployment's pod template to the previous revision, which the Deployment controller uses to create a new ReplicaSet with that older specification. The current ReplicaSet is scaled down to zero while the previous one is scaled up, effectively rolling back the application state without deleting the Deployment object or its history.

Why this answer

The 'kubectl rollout undo' command rolls back a Deployment to the previous revision. By default, it reverts to the immediate prior revision (revision 1 less than current).

Full explanation →

746

MCQmedium

You need to set environment variables in a pod from a ConfigMap 'app-config' that has keys 'APP_ENV' and 'APP_DEBUG'. Which approach exposes all keys as environment variables?

A.envFrom: - secretRef: name: app-config

B.env: - name: APP_ENV valueFrom: configMapKeyRef: name: app-config key: APP_ENV - name: APP_DEBUG valueFrom: configMapKeyRef: name: app-config key: APP_DEBUG

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

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

AnswerC

envFrom with configMapRef automatically creates an environment variable for each key in the ConfigMap, using the key name as the variable name. This is the intended way to inject an entire ConfigMap into the pod's environment without explicitly mapping each key. Note that keys that are not valid environment variable names are skipped, and this snapshot is taken at pod creation.

Why this answer

`envFrom` with `configMapRef` is the Kubernetes-native way to expose all keys from a ConfigMap as environment variables in a pod. This injects each key-value pair from the ConfigMap 'app-config' as an environment variable, matching the requirement to expose all keys without manual enumeration.

Exam trap

CNCF often tests the distinction between `configMapRef` and `secretRef`, and the trap here is that candidates confuse ConfigMaps with Secrets or assume that mounting a ConfigMap as a volume is equivalent to setting environment variables, leading them to pick Option A or D.

How to eliminate wrong answers

Option A is wrong because it uses `secretRef` which references a Secret, not a ConfigMap; Secrets are for sensitive data (e.g., passwords) and cannot read from a ConfigMap. Option B is wrong because it manually enumerates each key using `configMapKeyRef`, which works but does not expose 'all keys' automatically; it requires explicit listing of each key, violating the requirement. Option D is wrong because it mounts the ConfigMap as a volume at `/etc/config`, creating files named after the keys (e.g., `APP_ENV` and `APP_DEBUG`), not environment variables; this is a different mechanism for injecting configuration.

Full explanation →

747

MCQeasy

Which of the following is the correct way to set an environment variable 'APP_COLOR' from a ConfigMap key 'color'?

A.env: - name: APP_COLOR valueFrom: configMapRef: name: my-config key: color

B.envFrom: - configMapKeyRef: name: my-config key: color

C.env: - name: APP_COLOR valueFrom: configMapKeyRef: name: my-config key: color

D.env: - name: APP_COLOR value: "configMap.color"

AnswerC

This is correct because it uses the `env` array to define a single environment variable named `APP_COLOR`, then sources its value from the ConfigMap named `my-config` via `valueFrom.configMapKeyRef`, specifying the exact `key: color`. The `configMapKeyRef` field is the precise mechanism for pulling one key's value into an environment variable—it is the Kubernetes-standard way to make a ConfigMap value available inside a container under a chosen env var name.

Why this answer

It uses the `configMapKeyRef` field under `valueFrom` in the `env` array to inject a specific key from a ConfigMap as an environment variable. This is the standard Kubernetes syntax for referencing a single key from a ConfigMap, where `name` specifies the ConfigMap object and `key` specifies the key within that ConfigMap whose value will be assigned to the environment variable `APP_COLOR`.

Exam trap

The trap here is confusing `configMapRef` (used in `envFrom` to import all keys) with `configMapKeyRef` (used in `env` to import a single key), leading candidates to choose Option A or B due to similar naming.

How to eliminate wrong answers

Option A is wrong because `configMapRef` is not a valid field under `valueFrom`; `configMapRef` is used in `envFrom` to load all keys from a ConfigMap, not a single key. Option B is wrong because `envFrom` uses `configMapRef` (not `configMapKeyRef`) and cannot target a specific key; it imports all key-value pairs from the ConfigMap as environment variables, and the syntax shown (`configMapKeyRef`) is invalid. Option D is wrong because it attempts to set a literal string value `"configMap.color"` rather than referencing the ConfigMap key, which would not resolve to the actual value from the ConfigMap.

Full explanation →

748

MCQhard

You have a Job that runs a batch process. The Job YAML is as follows: apiVersion: batch/v1 kind: Job metadata: name: batch-job spec: parallelism: 4 completions: 12 backoffLimit: 2 template: spec: containers: - name: worker image: myapp:latest restartPolicy: Never If one pod fails after 3 successful completions, and the Job has already completed 7 successes, how many pods will be running at that point? Assume no other failures.

A.4

B.3

C.7

D.5

AnswerA

The correct answer is 4 because the Job's `parallelism` field is set to 4, which defines the desired number of pods the Job controller keeps running concurrently. Even if a pod fails, the controller immediately creates a replacement pod to restore the count to 4, provided the `backoffLimit` has not been exceeded. Thus, at any given time (except for transient moments during pod termination), up to 4 pods are actively running.

Why this answer

The Job is configured with parallelism: 4, meaning up to 4 pods run concurrently. At the moment a pod fails after 3 successful completions and the Job has already achieved 7 successes, the Job controller will still be running pods to reach the target of 12 completions. Since the failure does not reduce the number of running pods below the parallelism limit, and no other failures have occurred, the Job will continue to run 4 pods simultaneously.

Exam trap

The trap here is that candidates mistakenly think a pod failure reduces the number of running pods or that the Job stops or scales down, but the parallelism remains constant and the controller continues to run pods up to that limit.

How to eliminate wrong answers

Option B is wrong because it assumes the Job reduces parallelism after a failure, but the parallelism setting remains 4 regardless of failures. Option C is wrong because it confuses the total number of successful completions (7) with the number of currently running pods; the Job runs pods up to the parallelism value, not the success count. Option D is wrong because it suggests a specific number like 5, which is not derived from any Job field; the parallelism is fixed at 4, and failures do not dynamically adjust it.

Full explanation →

749

MCQmedium

A pod has two containers: a web server and a sidecar that scrapes logs. The sidecar container needs to read log files written by the web server. How should the logs be shared between the containers?

A.Use a ConfigMap to store logs

B.Use a hostPath volume mounted in both containers

C.Use a shared emptyDir volume mounted into both containers at the same path

D.Use a PersistentVolumeClaim

AnswerC

An emptyDir volume is created when the pod starts and exists for the pod's lifetime, and mounting it into both containers at the same path gives the sidecar direct filesystem access to the log files the web server writes, satisfying the sharing requirement.

Why this answer

An emptyDir volume is a shared, ephemeral volume that is created when a Pod is assigned to a node and exists as long as that Pod is running. Both containers in the same Pod can mount the same emptyDir volume at the same or different paths, allowing the sidecar to read log files written by the web server without any external storage dependency. This is the standard Kubernetes pattern for inter-container log sharing within a Pod.

Exam trap

A common misconception is that hostPath is the default or simplest way to share files between containers, but the correct Kubernetes-native pattern for ephemeral, intra-Pod log sharing is an emptyDir volume, which is portable and automatically lifecycle-managed.

How to eliminate wrong answers

Option A is wrong because ConfigMaps are designed to store configuration data (e.g., key-value pairs, small files) and are not suitable for dynamic, growing log files; they are read-only when mounted and cannot be written to by containers. Option B is wrong because hostPath volumes tie the Pod to a specific node's filesystem, which breaks portability and is not recommended for simple log sharing; it also introduces security risks and is not the idiomatic Kubernetes approach for sidecar log scraping. Option D is wrong because a PersistentVolumeClaim (PVC) is intended for persistent storage that survives Pod restarts and is typically used for stateful workloads, not for ephemeral log sharing between containers in the same Pod; it adds unnecessary complexity and overhead.

Full explanation →

750

MCQeasy

To mount a ConfigMap as a volume, which field type must be used in the pod spec's volumes and volumeMounts?

A.configMap

B.emptyDir

C.secret

D.hostPath

AnswerA

The configMap volume type is the only correct choice because it directly references a ConfigMap object in the volumes field of a pod spec. When this type is used, the kubelet retrieves the ConfigMap's key-value data and materializes it as files in the volume, making the configuration accessible to containers via mountPath. You can further control the projection with items for selecting specific keys and defaultMode for file permissions.

Why this answer

To mount a ConfigMap as a volume in a Pod, the `configMap` field type must be specified in the `volumes` array of the Pod spec, and the corresponding `volumeMounts` entry references that volume by name. This tells Kubernetes to populate the volume with the key-value pairs from the ConfigMap, making them available as files in the container's filesystem.

Exam trap

The trap here is that candidates often confuse `configMap` with `secret` because both are used to inject configuration data, but the question specifically asks for the field type to mount a ConfigMap, not a Secret.

How to eliminate wrong answers

Option B (emptyDir) is wrong because it creates an empty, ephemeral directory that is not backed by any ConfigMap or Secret; it is used for scratch space or sharing data between containers. Option C (secret) is wrong because it mounts a Secret, not a ConfigMap; while both are volume types, they are distinct resources with different data sources and use cases. Option D (hostPath) is wrong because it mounts a file or directory from the host node's filesystem, not from a Kubernetes ConfigMap object.

Full explanation →

Certified Kubernetes Application Developer CKAD (CKAD) — Questions 676–750