Certified Kubernetes Application Developer CKAD CKAD Questions 76–150 | Page 2/3

Multi-Selecthard

A Deployment named 'api' has 6 replicas. You want to perform a rolling update with the following constraints: at most 2 pods can be unavailable during the update, and at most 1 extra pod can be created above the desired 6. Which strategy configurations achieve this? (Choose TWO)

Select 2 answers

A.strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 2

B.strategy: rollingUpdate: maxSurge: 16% maxUnavailable: 33%

C.strategy: rollingUpdate: maxSurge: 2 maxUnavailable: 2

D.strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 3

E.strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1

AnswersA, B

Absolute numbers match constraints.

Why this answer

Uses absolute numbers: maxSurge=1 and maxUnavailable=2, directly matching the constraints. Option B uses percentages: 16% of 6 = 0.96 rounded up to 1, and 33% of 6 = 1.98 rounded up to 2, so it also yields maxSurge=1 and maxUnavailable=2. Option C has maxSurge=2, exceeding the surge limit.

Option D has maxUnavailable=3, exceeding the unavailable limit. Option E has maxUnavailable=1, which is more restrictive than the allowed maximum of 2; while it technically satisfies the constraint, it is not the intended configuration. Therefore, the correct answers are A and B.

Full explanation →

MCQhard

A pod has a startup probe with failureThreshold: 30 and periodSeconds: 10. The application takes up to 5 minutes to start. What should be changed to ensure the startup probe does not kill the container prematurely?

A.Increase failureThreshold to 40

B.Change periodSeconds to 5

C.Change timeoutSeconds to 30

D.Set initialDelaySeconds to 300

AnswerA

Increasing failureThreshold to 40 allows the startup probe to fail up to 40 consecutive times before the kubelet declares the container failed. Because the existing periodSeconds is 10, the new total grace period is 40 × 10 = 400 seconds (6m40s), which comfortably exceeds the application's 5-minute (300-second) startup requirement. This is the correct modification because it directly extends the cumulative time the kubelet tolerates an unready container without changing how frequently the probe runs or delaying the start of probing. The extra 100 seconds of tolerance eliminates the risk of premature termination while still allowing the probe to eventually catch a genuinely broken container.

Why this answer

Increasing failureThreshold to 40 (from 30) with periodSeconds: 10 gives a total timeout of 40 × 10 = 400 seconds (6 minutes 40 seconds), which exceeds the 5-minute startup time. Setting initialDelaySeconds (Option D) would also delay the first probe execution, but best practices recommend adjusting the probe's failure threshold and interval instead of using an initial delay for startup probes, as the purpose of a startup probe is to start probing immediately and replace the need for an initial delay.

Exam trap

The trap is that candidates may consider setting initialDelaySeconds as a valid solution to extend the probe's grace period. However, for startup probes, the best practice is to adjust failureThreshold and periodSeconds to cover the expected startup time, rather than adding an initial delay which defeats the purpose of immediate probing.

How to eliminate wrong answers

Option B is wrong because changing periodSeconds to 5 reduces the interval between checks, but with failureThreshold: 30, the total timeout becomes 30 × 5 = 150 seconds (2.5 minutes), which is still less than the required 5 minutes. Option C is wrong because timeoutSeconds controls the timeout for a single probe check, not the overall startup window; it does not extend the total time the probe waits for success. Option D is wrong because initialDelaySeconds delays the start of the probe, but the probe still runs with the same failureThreshold and periodSeconds; after the delay, the probe would still kill the container prematurely if the total probe window (30 × 10 = 300 seconds) is not enough.

Full explanation →

MCQmedium

A pod is running but not receiving traffic from a Service. The readiness probe is failing. What is the likely effect on the pod?

A.The pod will be marked as CrashLoopBackOff

B.The pod will remain running but will not be included in the Service's endpoints

C.The pod will be terminated and restarted

D.The pod will be evicted from the node

AnswerB

This is the correct behavior. The kubelet continuously executes the readiness probe, and when it fails, the pod is marked as NotReady. As a result, the endpoints controller removes the pod's IP address from the Service's Endpoints object, preventing the Service from forwarding new requests to it — but the pod itself is not stopped, restarted, or evicted, and it can still receive direct traffic from other clients if they target its IP explicitly.

Why this answer

When a readiness probe fails, Kubernetes marks the pod as not ready. The pod continues running, but the associated Service removes the pod's IP from its Endpoints (or EndpointSlice) list. This ensures the Service does not route traffic to a pod that is not prepared to handle requests, while allowing the pod to remain alive for debugging or other internal operations.

Exam trap

The CKAD exam often tests the distinction between readiness and liveness probes, and the trap here is that candidates confuse a failing readiness probe with a failing liveness probe, assuming the pod will be killed or restarted when it will not.

How to eliminate wrong answers

Option A is wrong because CrashLoopBackOff is a status for pods whose containers repeatedly crash (e.g., due to a failing liveness probe or application error), not for pods with a failing readiness probe. Option C is wrong because a failing readiness probe does not trigger pod termination or restart; only a failing liveness probe would cause the kubelet to restart the container. Option D is wrong because pod eviction is caused by node resource pressure (e.g., memory or disk) or node-level failures, not by a readiness probe failure.

Full explanation →

MCQeasy

You have a ConfigMap named 'app-config' with key 'database.url'. Which environment variable definition correctly injects this value into a pod using a configMapKeyRef?

A.- name: DATABASE_URL valueFrom: configMapKeyRef: name: app-config key: database.url

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

C.- name: DATABASE_URL valueFrom: secretKeyRef: name: app-config key: database.url

D.- valueFrom: configMapKeyRef: name: app-config key: database.url

AnswerA

This option is correct because it properly defines an environment variable named `DATABASE_URL` using the `name` field and combines it with a `valueFrom` block. The `configMapKeyRef` inside `valueFrom` specifies the ConfigMap `app-config` and the key `database.url`, which instructs Kubernetes to retrieve that specific value. This is the standard and complete syntax for referencing a single key from a ConfigMap as an environment variable.

Why this answer

It properly defines an environment variable with a name and uses `valueFrom.configMapKeyRef` to reference the specific key 'database.url' from the ConfigMap 'app-config'. The `name` field is required in the env entry to specify the environment variable name. Option D is incorrect because it omits the `name` field, making the definition incomplete.

Exam trap

The trap is that candidates might think the `name` field is optional or that `valueFrom` alone is sufficient. In reality, each environment variable injection via `valueFrom` must include the `name` field to define the variable name.

How to eliminate wrong answers

Option A is wrong because it uses `valueFrom` with a `configMapKeyRef` but the syntax is incomplete — it lacks the `- name: DATABASE_URL` line above the `valueFrom` block, which is required to define the environment variable name; however, the core structure is actually correct if the name were present, so this option is not the best answer because the question expects the exact correct snippet. Option B is wrong because `envFrom` with a `configMapRef` injects all keys from the ConfigMap as environment variables, not a single specific key, and it does not allow renaming the variable to `DATABASE_URL`; it would create an environment variable named `database.url`, which is invalid in most shells due to the dot. Option C is wrong because it uses `secretKeyRef` instead of `configMapKeyRef`, which is designed for Secrets, not ConfigMaps; referencing a ConfigMap with `secretKeyRef` will fail because the API expects a Secret resource.

Full explanation →

MCQhard

A pod in a namespace with a ResourceQuota that sets 'requests.cpu: 2' is failing to schedule. The pod manifest specifies 'resources: { requests: { cpu: "500m" } }'. What is the likely cause?

A.The ResourceQuota applies to limits, not requests.

B.The namespace has already used all its CPU request quota.

C.The pod does not specify a CPU limit.

D.The pod's CPU request exceeds the ResourceQuota limit.

AnswerB

Even though the pod's individual request is small (500m), the ResourceQuota enforces an aggregate limit on the sum of all CPU requests in the namespace. At admission time, Kubernetes compares the current usage (sum of requests from all running/creating objects) plus the new pod's request against the quota's hard limit of 2000m. If the existing usage is already at or near 2000m, adding this pod's 500m pushes the total over the limit, causing the 'quota exceeded' error. This is a namespace-level accounting issue, not a per-pod scheduling problem.

Why this answer

The ResourceQuota sets a hard limit of 2 CPU cores for total requests across all pods in the namespace. If the sum of CPU requests from all pods already reaches or exceeds 2, a new pod with a 500m CPU request cannot be scheduled because it would exceed the quota. The pod's request (500m) is well within the quota limit, so the issue is that the namespace has exhausted its CPU request budget.

Exam trap

The trap here is that candidates assume the pod's individual request must be less than the quota, but they overlook that the quota is a cumulative limit across all pods in the namespace, so even a small request can fail if the namespace is already at capacity.

How to eliminate wrong answers

Option A is wrong because ResourceQuota can apply to both requests and limits; by default, it applies to requests unless specified otherwise, and the question states 'requests.cpu: 2' which explicitly targets requests. Option C is wrong because a CPU limit is not required for scheduling; the ResourceQuota only enforces the requests.cpu limit, and the pod can run without a limit. Option D is wrong because the pod's CPU request (500m) is less than the ResourceQuota limit (2), so it does not exceed the quota; the failure is due to cumulative usage, not an individual overage.

Full explanation →

MCQhard

You are responsible for a multi-tier application running in a Kubernetes cluster. The frontend Pods communicate with backend Pods via a Service named 'backend' in the same namespace. Recently, the frontend team reported that the backend Service is intermittently unreachable. You inspect the backend Pods and notice that they are all running and ready, but the Endpoints object for the 'backend' Service shows only a subset of the Pod IPs. You also notice that the backend Pods have a readiness probe configured that checks an HTTP endpoint '/healthz'. The readiness probe has a periodSeconds of 5 and failureThreshold of 3. The application logs show occasional spikes in response time on the /healthz endpoint, sometimes exceeding 15 seconds. You need to resolve the intermittent unavailability without removing the readiness probe. Which action should you take?

A.Remove the readiness probe configuration from the backend Pods

B.Add a second readiness probe on a different endpoint to increase redundancy

C.Change the Service type from ClusterIP to NodePort to bypass endpoint issues

D.Increase the failureThreshold to 10 and periodSeconds to 10 to tolerate transient slowness

AnswerD

Increasing failureThreshold to 10 and periodSeconds to 10 gives the readiness probe a much larger tolerance window: the kubelet would need 10 consecutive failed probes spaced 10 seconds apart (i.e., about 90 seconds of continuous failures) before marking the backend Pod unready. This directly addresses transient slowness because brief spikes in latency or occasional failed HTTP responses will not cause the Pod to be dropped from Service endpoints. The tradeoff is that truly dead backends take longer to be removed, but for a multi-tier app that only needs to tolerate temporary degradation, this is the correct, targeted tuning.

Why this answer

Increasing the failureThreshold to 10 and periodSeconds to 10 gives the readiness probe more time (100 seconds total) to tolerate transient slowness on the /healthz endpoint, preventing premature removal of Pod IPs from the Endpoints object. This keeps all backend Pods in the ready state during response time spikes, ensuring the Service remains reachable.

Exam trap

The trap here is that candidates might think removing the readiness probe (Option A) is a quick fix, but the CKAD exam emphasizes that readiness probes are essential for traffic routing and should be tuned, not removed, to handle transient issues.

How to eliminate wrong answers

Option A is wrong because removing the readiness probe would allow traffic to be sent to Pods that may be unresponsive, causing application errors and defeating the purpose of health checking. Option B is wrong because adding a second readiness probe on a different endpoint does not address the root cause of intermittent slowness on the existing /healthz endpoint; it could even cause more Pods to be marked unready if the new endpoint also experiences delays. Option C is wrong because changing the Service type to NodePort does not bypass endpoint issues; the Endpoints object is still used for routing, and NodePort only exposes the Service externally without fixing the readiness probe logic.

Full explanation →

MCQeasy

Which Service type is used to expose a Service on a static port on each node's IP address, allowing external traffic to reach the Service?

A.ClusterIP

B.ExternalName

C.NodePort

D.LoadBalancer

AnswerC

NodePort is the only service type that opens a specific static port (in the 30000–32767 range by default) on every node in the cluster, forwarding traffic from that port to the service's ClusterIP and then to the selected pods. This directly matches the requirement: each node's IP address becomes an external entry point on that same fixed port. It is the underlying primitive that a LoadBalancer service uses when it provisions cloud infrastructure.

Why this answer

NodePort is the correct Service type because it exposes the Service on a static port (in the range 30000-32767) on each node's IP address. This allows external traffic to reach the Service by sending requests to any node's IP at that port, which then forwards traffic to the appropriate Pods via the ClusterIP and kube-proxy rules.

Exam trap

Some candidates mistakenly think LoadBalancer is the only external Service type, but the question specifies a static port on each node's IP, which is the definition of NodePort. LoadBalancer builds on NodePort and adds an external load balancer.

How to eliminate wrong answers

Option A is wrong because ClusterIP exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like an ingress or proxy. Option B is wrong because ExternalName maps a Service to a DNS name (via CNAME records) and does not expose any port or IP for external traffic; it is used for internal DNS aliasing. Option D is wrong because LoadBalancer provisions an external load balancer (e.g., from a cloud provider) and is a superset of NodePort, but the question specifically asks for exposing on a static port on each node's IP, which is the defining characteristic of NodePort, not LoadBalancer.

Full explanation →

Multi-Selectmedium

Which TWO of the following are valid methods to create a Service in Kubernetes? (Select 2)

Select 2 answers

A.kubectl apply -f service.yaml

B.kubectl expose deployment my-deploy --port=80

C.kubectl port-forward svc/my-svc 8080:80

D.kubectl run my-svc --image=nginx --port=80

E.kubectl create service clusterip my-svc --tcp=80:80

AnswersA, B

Applying a YAML manifest creates the Service.

Why this answer

`kubectl apply -f service.yaml` declaratively creates a Service from a YAML manifest. Option B is correct because `kubectl expose deployment my-deploy --port=80` imperatively creates a Service that exposes the deployment's pods. Option E is not considered a standard method for creating a Service in the context of this exam; the commonly taught imperative commands are `kubectl apply -f` and `kubectl expose`.

Options C and D are incorrect: `kubectl port-forward` does not create a Service, and `kubectl run` creates a Pod or Deployment, not a Service.

Exam trap

A common trap is that `kubectl run` and `kubectl port-forward` might appear to create a Service but actually do not; only declarative or imperative Service creation commands like `kubectl apply -f`, `kubectl expose`, and `kubectl create service` are valid.

Full explanation →

MCQmedium

You need to perform a blue-green deployment using Deployments and Services. What is the most common approach to switch traffic from the old version (blue) to the new version (green)?

A.Update the Deployment's image field in the blue Deployment to the new version

B.Change the Service's label selector to point to the green Deployment's pod labels

C.Delete the blue Deployment and create the green Deployment

D.Scale the blue Deployment to 0 and the green Deployment to desired replicas

AnswerB

Altering the Service's label selector to match the green Deployment's pod labels is the canonical blue-green traffic switch. Because the Deployment labels are immutable to the selector only after the fact, you simply retarget the Service to the already-running and ready green pods, instantly moving all traffic without redeploying anything. This provides zero-downtime shifting and makes rollback trivial by reverting the selector to blue.

Why this answer

In a blue-green deployment, the Service acts as the traffic router by using a label selector to match pods. By updating the Service's selector to match the green Deployment's pod labels (e.g., `version: green`), traffic is instantly switched from blue pods to green pods without any downtime, as Kubernetes Services use label selectors to dynamically route traffic to matching pods.

Exam trap

The trap here is that candidates often confuse a blue-green deployment with a rolling update or scaling strategy, and mistakenly think that updating the image (Option A) or scaling (Option D) is sufficient to switch traffic, ignoring the critical role of the Service's label selector in directing traffic to the correct set of pods.

How to eliminate wrong answers

Option A is wrong because updating the image field in the blue Deployment triggers a rolling update, not a blue-green switch; this mixes old and new pods during the transition and defeats the purpose of having two separate environments. Option C is wrong because deleting the blue Deployment before creating the green one causes downtime, as there is no overlap period to validate the green deployment before cutting over. Option D is wrong because scaling blue to 0 and green to desired replicas does not automatically redirect traffic; the Service's label selector must still be updated to point to green pods, otherwise traffic continues to blue pods even if they are scaled down (and will fail if blue has 0 replicas).

Full explanation →

MCQmedium

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

A.Increase the CPU request for the container

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

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

D.Delete the namespace and redeploy all workloads

AnswerC

OOMKilled specifically indicates that the container's memory usage hit the memory limit set in its resources.limits field, causing the kernel's out-of-memory killer to terminate the process. Increasing the memory limit grants the container a larger memory cgroup allowance, so it can continue running with its actual memory footprint without being killed, which directly addresses the root cause.

Why this answer

The 'OOMKilled' message indicates the container was terminated because it exceeded its memory limit. Increasing the memory limit in the container's resource specification allows the container to use more memory, preventing the out-of-memory kill. This directly addresses the root cause without losing the pod's state or affecting other workloads.

Exam trap

The trap here is that candidates confuse CPU and memory resource issues, or think that restarting the pod (Option B) will fix the underlying resource constraint, when in fact the OOMKilled status persists until the memory limit is increased.

How to eliminate wrong answers

Option A is wrong because increasing CPU request does not affect memory usage; OOMKilled is a memory issue, not a CPU issue. Option B is wrong because deleting and recreating the pod will not change the memory limit; the new pod will still be killed with OOMKilled if the memory limit remains unchanged. Option D is wrong because deleting the entire namespace is an extreme, unnecessary action that destroys all workloads and does not fix the memory limit for the specific pod.

Full explanation →

MCQhard

A Service named 'api' has no endpoints. 'kubectl describe svc api' shows the selector 'app: api', but no pods have that label. What is the most likely reason for missing endpoints?

A.The Service is in a different namespace than the pods

B.No pods match the Service's selector

C.The Service port is incorrect

D.The Service type is ExternalName

AnswerB

The Service's endpoints are generated dynamically from the pods whose labels match its `selector` field. If no pods in the Service's namespace carry that label (e.g., `app: api`), no pod IPs are added to the Endpoints objects, so `kubectl describe svc` displays "Endpoints: <none>". This is the most frequent cause of an endpointless Service.

Why this answer

The most likely reason for missing endpoints is that no pods match the Service's selector. A Kubernetes Service routes traffic to pods that have labels matching its `spec.selector`. If `kubectl describe svc api` shows `Selector: app=api` but no pods carry the label `app: api`, the Service's endpoint controller will not populate any endpoints, resulting in an empty `Endpoints` object.

This is the direct cause of the missing endpoints.

Exam trap

The trap here is that candidates may assume missing endpoints are due to namespace mismatch or port misconfiguration, but the core issue is always the selector-to-pod label match, which is the fundamental mechanism for endpoint discovery in Kubernetes Services.

How to eliminate wrong answers

Option A is wrong because the Service and pods must be in the same namespace for the selector to work; if they were in different namespaces, the Service would still show endpoints if matching pods existed in its own namespace, but the question states no pods have the label, not that they are in a different namespace. Option C is wrong because an incorrect Service port would cause connection failures, not missing endpoints; endpoints are populated based on pod IPs and ports matching the selector, regardless of the Service port definition. Option D is wrong because a Service of type ExternalName does not use selectors or endpoints at all; it returns a CNAME record, so missing endpoints would be expected, but the question states the Service has selector `app: api`, which is incompatible with ExternalName type.

Full explanation →

MCQmedium

A pod fails to start with a 'CreateContainerConfigError'. Running 'kubectl describe pod my-pod' reveals: 'Error: container has runAsNonRoot and image will run as root'. The pod definition includes 'securityContext.runAsNonRoot: true'. What is the most likely cause?

A.The container does not have the CAP_SYS_ADMIN capability

B.The container image's default user is root (UID 0), conflicting with runAsNonRoot

C.The container's filesystem is read-only

D.The runAsUser field is missing, so the pod uses a random UID

AnswerB

When runAsNonRoot: true is set, the kubelet inspects the container image's configured user (typically the USER instruction or default UID). If the image's default user is root (UID 0), the kubelet refuses to start the container and emits an error such as 'container has runAsNonRoot and image will run as root'. Since the error is CreateContainerConfigError, it exactly matches this contradiction between the securityContext and the image's default user, making this the correct cause.

Why this answer

The error 'container has runAsNonRoot and image will run as root' occurs because the pod's securityContext sets `runAsNonRoot: true`, but the container image's default user is root (UID 0). Kubernetes checks the image's user at container startup; if the image runs as root and the pod enforces non-root, the container fails to start with a CreateContainerConfigError.

Exam trap

The trap here is that candidates often assume the error is about missing runAsUser or capabilities, but the error message directly points to the image's default user being root, which is a mismatch with the runAsNonRoot constraint.

How to eliminate wrong answers

Option A is wrong because CAP_SYS_ADMIN is a Linux capability unrelated to the runAsNonRoot check; the error is about the container's user identity, not capabilities. Option C is wrong because a read-only filesystem does not cause a runAsNonRoot conflict; it would produce a different error (e.g., 'read-only filesystem'). Option D is wrong because runAsUser is not required when runAsNonRoot is true; Kubernetes will still enforce non-root even without an explicit UID, and the error explicitly states the image runs as root, not that a random UID is used.

Full explanation →

MCQhard

You have a Deployment that uses a ConfigMap. You update the ConfigMap, but the pods are not picking up the changes. What is the MOST efficient way to force the pods to use the new ConfigMap values without downtime?

A.Run 'kubectl rollout restart deployment/deployment-name'

B.Delete the pods manually and let the ReplicaSet recreate them

C.Delete the ConfigMap and recreate it with the same name

D.Edit the Deployment to add an annotation, triggering a rollout

AnswerA

kubectl rollout restart deployment/deployment-name performs a rolling restart by adding a temporary annotation to the pod template, which forces the Deployment controller to create a new ReplicaSet and progressively swap old pods for new ones. This ensures zero downtime, as new pods are fully ready before old ones are terminated, and crucially, the new pods will read the updated ConfigMap from the API server at container startup. It is the cleanest, most declarative way to push a ConfigMap change to an existing Deployment.

Why this answer

A is correct because `kubectl rollout restart deployment/deployment-name` triggers a new ReplicaSet and gracefully terminates old pods while creating new ones, which will mount the updated ConfigMap. This avoids downtime by leveraging the Deployment's rolling update strategy, ensuring the new pods read the current ConfigMap data from the volume mount or environment variable reference.

Exam trap

The trap here is that candidates assume ConfigMap updates are automatically reflected in running pods, but Kubernetes only refreshes mounted volumes after a sync interval (and never for environment variables), so a restart is required to pick up changes without downtime.

How to eliminate wrong answers

Option B is wrong because manually deleting pods causes the ReplicaSet to recreate them with the same old ConfigMap data, as the ConfigMap reference in the Pod template hasn't changed; it does not force a refresh. Option C is wrong because deleting and recreating the ConfigMap with the same name does not update the pods' in-memory data or mounted files unless the pods are restarted; the pods continue to use the cached version from the initial mount. Option D is wrong because adding an annotation to the Deployment triggers a rollout only if the annotation change is part of a spec change that causes the Pod template hash to differ; a simple metadata annotation update without a corresponding pod template change does not trigger a rollout in Kubernetes.

Full explanation →

MCQeasy

Which Dockerfile instruction sets a command that can be overridden when running the container?

A.RUN

B.EXPOSE

C.ENTRYPOINT

D.CMD

AnswerD

CMD is the instruction that sets the default command and parameters for the container. When you run 'docker run <image> <command>', the command you supply entirely overrides the CMD value. This is precisely why CMD is the correct answer: it provides a runtime default that can be easily replaced without any special flags. CMD can also supply default arguments to an ENTRYPOINT if both are defined, but in the absence of ENTRYPOINT, CMD is the executable that runs.

Why this answer

The CMD instruction provides default arguments for the container's entrypoint, which can be overridden by supplying command-line arguments when running the container with `docker run`. This makes CMD the correct choice for a command that is intended to be overridden at runtime.

Exam trap

The trap here is that candidates often confuse ENTRYPOINT and CMD, mistakenly thinking ENTRYPOINT is overridable by default, when in fact CMD is the instruction specifically designed to be overridden by runtime arguments.

How to eliminate wrong answers

Option A is wrong because RUN executes commands during the image build process, creating new layers in the image, and its effects are baked into the image and cannot be overridden at container runtime. Option B is wrong because EXPOSE only documents which ports the container listens on; it does not execute any command and cannot be overridden. Option C is wrong because ENTRYPOINT defines the main executable for the container, and while it can be overridden with `--entrypoint` flag, it is designed to be the fixed command that is not easily replaced by simple command-line arguments—unlike CMD, which is specifically intended to be overridden.

Full explanation →

MCQeasy

What is the purpose of a readiness probe in Kubernetes?

A.To control whether the pod receives traffic from Services

B.To delay the start of other probes for slow-starting containers

C.To monitor resource usage of the container

D.To restart the container if it becomes unhealthy

AnswerA

A failing readiness probe removes the pod from Service endpoints.

Why this answer

A readiness probe determines whether a container is ready to serve traffic. If the probe fails, the pod is removed from the endpoints of Services, thus it does not receive traffic. Option B describes a startup probe (to delay liveness/readiness probes for slow-starting containers).

Option C describes resource monitoring, not a probe. Option D describes a liveness probe, which restarts the container if unhealthy.

Full explanation →

MCQmedium

You are tasked with deploying a stateless web application on a Kubernetes cluster. The application is containerized and listens on port 8080. You have created a Deployment named 'webapp' with 3 replicas, and a ClusterIP Service named 'webapp-svc' exposing port 80 targeting the application's port 8080. During testing, you notice that some requests to the service return errors while others succeed. You have verified that all Pods are running and ready. The application logs show no errors. What is the most likely cause of the intermittent failures?

A.The ClusterIP Service type does not support load balancing.

B.The Service is not configured with enough endpoints.

C.The Service's targetPort is set incorrectly, causing traffic to be misrouted.

D.The Deployment lacks a readiness probe, causing the Service to route traffic to Pods that are not ready.

AnswerD

Without a readiness probe, kube-proxy considers a Pod 'Ready' as soon as its containers are running, even if the application inside is still initializing, warming up, or temporarily unable to handle traffic. This causes the Service to include such Pods as endpoints, so some requests get routed to a Pod that will sporadically return 5xx errors or drop the connection. A readiness probe solves this by marking the Pod Ready only when it responds successfully to a health check, ensuring the Service’s endpoint list contains only truly available Pods.

Why this answer

The intermittent failures are most likely caused by the absence of a readiness probe in the Deployment. Without a readiness probe, the Service's EndpointSlice controller considers all Pods with a matching label selector as ready endpoints, even if the application inside the container has not finished initializing or is temporarily unable to serve traffic. This results in the ClusterIP Service load-balancing requests to Pods that are not actually ready, causing some requests to fail while others succeed.

Exam trap

CNCF often tests the distinction between 'Pod is Running' (container process started) and 'Pod is Ready' (application is healthy and can serve traffic), trapping candidates who assume that a Running Pod is automatically ready to receive Service traffic.

How to eliminate wrong answers

Option A is wrong because ClusterIP Services do provide internal load balancing via kube-proxy using iptables or IPVS rules, distributing traffic across ready endpoints. Option B is wrong because the Service is configured with a label selector matching the Deployment's Pods, and with 3 replicas all running and ready (as verified), there are exactly 3 endpoints — enough for load balancing. Option C is wrong because the targetPort is set to 8080, which matches the container's listening port, so traffic is correctly routed to the application.

Full explanation →

Multi-Selecthard

Which TWO statements about kubectl apply vs kubectl create are correct? (Select two)

Select 2 answers

A.Both commands support the --dry-run=client flag.

B.Both commands require a full YAML manifest file.

C.kubectl apply can update existing resources; kubectl create cannot.

D.kubectl create is the recommended way to manage production resources.

E.Both commands can only be used to create resources, not update.

.kubectl apply stores the last applied configuration in an annotation.

AnswersC

Correct. `kubectl apply` can update existing resources; `kubectl create` cannot update and will fail if the resource exists.

Why this answer

The correct options are the statement about kubectl apply storing the last applied configuration in an annotation (the first option) and option C. The annotation `kubectl.kubernetes.io/last-applied-configuration` enables declarative updates with `kubectl apply`. Option C is correct because `kubectl apply` can update existing resources declaratively, while `kubectl create` will fail if the resource already exists.

Option A is incorrect because `kubectl create` does not support `--dry-run=client`; only `kubectl apply` does. Options B, D, and E are incorrect as explained.

Exam trap

Kubernetes often tests the misconception that `kubectl apply` and `kubectl create` are interchangeable, but the trap here is that candidates confuse the imperative `create` (which cannot update) with the declarative `apply` (which can), and they may also incorrectly assume `--dry-run=client` works identically for both commands.

Full explanation →

MCQmedium

You need to configure a liveness probe for a container that starts a web server on port 8080. The probe should check the '/healthz' endpoint. Which YAML snippet correctly defines this probe?

A.livenessProbe:\n exec:\n command: ["curl", "http://localhost:8080/healthz"]

B.livenessProbe:\n httpGet:\n port: 8080

C.livenessProbe:\n httpGet:\n path: /healthz\n port: 8080

D.livenessProbe:\n tcpSocket:\n port: 8080

AnswerC

This is the correct liveness probe because it declares an httpGet handler that instructs the kubelet to send an HTTP GET request to the container's /healthz endpoint on port 8080. Kubernetes considers the probe successful if the HTTP response status code is in the 200-399 range, so a 400 or 500 response would restart the container. This definition precisely matches the stated requirement of performing a HTTP GET liveness check against that path and port.

Why this answer

It defines an HTTP GET liveness probe that checks the '/healthz' endpoint on port 8080, which is the standard way to verify the health of a web server. The `httpGet` probe sends an HTTP GET request to the specified path and port, and the container is considered healthy if the response status code is between 200 and 399.

Exam trap

The trap here is that candidates often choose a `tcpSocket` probe (option D) thinking it's sufficient for a web server, but the CKAD exam expects you to use an `httpGet` probe with the correct path to validate the application's health endpoint.

How to eliminate wrong answers

Option A is wrong because it uses an `exec` probe with a `curl` command, which is unnecessary when an `httpGet` probe can directly check the HTTP endpoint; also, `curl` may not be installed in the container image, leading to probe failures. Option B is wrong because it omits the `path` field, so the probe defaults to the root path '/' instead of '/healthz', which may not reflect the actual health check endpoint. Option D is wrong because it uses a `tcpSocket` probe, which only checks if the TCP port is open, not whether the web server is serving the correct HTTP response on '/healthz'.

Full explanation →

MCQeasy

A user creates a Deployment with 3 replicas and a Service of type ClusterIP. The Service selects pods with label 'app: web'. The user wants external clients to access the application via a stable IP address. Which additional resource is required?

A.A second Service of type NodePort

B.A NetworkPolicy

C.An Ingress resource

D.A ConfigMap

AnswerC

An Ingress resource is the correct approach because it manages external HTTP(S) access to services using hostnames and URL paths, and it is backed by an ingress controller that typically provisions a stable external IP or load balancer. This gives clients a single, predictable address to reach the deployment, while also supporting TLS termination and advanced routing rules without creating multiple NodePorts.

Why this answer

A ClusterIP Service is only reachable within the cluster. To expose a Deployment to external clients via a stable IP, an Ingress resource is required because it provides HTTP/HTTPS routing from outside the cluster to the Service, typically using a load balancer or a reverse proxy like NGINX. Ingress also offers a stable external IP (or hostname) and can manage TLS termination, making it the correct choice for external access with a stable endpoint.

Exam trap

CNCF often tests the misconception that a ClusterIP Service alone can be accessed externally, or that a NodePort Service provides a stable IP, when in fact NodePort exposes on ephemeral node IPs and ports, while Ingress provides a stable external endpoint with path-based routing.

How to eliminate wrong answers

Option A is wrong because creating a second NodePort Service would expose the application on a high port on each node, but it does not provide a stable IP address; the node IPs may change, and clients would need to know the specific node and port. Option B is wrong because a NetworkPolicy controls ingress/egress traffic between pods within the cluster, not external access; it cannot expose the application to external clients. Option D is wrong because a ConfigMap is used to store configuration data (e.g., environment variables) for pods, not to expose services externally.

Full explanation →

MCQhard

You have a NetworkPolicy that allows ingress from pods with label 'app: frontend' in any namespace, and also allows ingress from the IP range '10.0.0.0/8'. The policy is not working as expected. Which YAML snippet correctly implements both requirements?

A.ingress: - from: - namespaceSelector: {} podSelector: matchLabels: app: frontend - from: - ipBlock: cidr: 10.0.0.0/8

B.ingress: - from: - namespaceSelector: {} - podSelector: matchLabels: app: frontend - ipBlock: cidr: 10.0.0.0/8

C.ingress: - from: - podSelector: matchLabels: app: frontend - ipBlock: cidr: 10.0.0.0/8

D.ingress: - from: - namespaceSelector: {} podSelector: matchLabels: app: frontend - ipBlock: cidr: 10.0.0.0/8

AnswerA

Correct. Two separate `from` entries OR the two rules, allowing pods with label `app: frontend` in any namespace and the IP range 10.0.0.0/8.

Why this answer

It uses two separate `from` entries in the ingress rule. The first `from` combines a `namespaceSelector: {}` (selects all namespaces) with a `podSelector` for `app: frontend`, meaning pods with that label in any namespace are allowed. The second `from` uses an `ipBlock` to allow traffic from the 10.0.0.0/8 CIDR range.

In Kubernetes NetworkPolicy, multiple `from` entries are ORed together, so traffic matching either rule is permitted.

Exam trap

The trap here is that candidates often try to combine `ipBlock` with `podSelector` or `namespaceSelector` in the same `from` entry, not realizing that `ipBlock` must be in its own `from` entry to be ORed with other rules, and that omitting `namespaceSelector: {}` restricts the pod selector to the current namespace only.

How to eliminate wrong answers

Option B is wrong because it places `namespaceSelector`, `podSelector`, and `ipBlock` as separate items within a single `from` array, which is invalid syntax—each `from` entry must be an object, and mixing selectors and ipBlock in this way will cause a validation error. Option C is wrong because it omits the `namespaceSelector`, so the `podSelector` only matches pods in the same namespace as the NetworkPolicy, not across all namespaces. Option D is wrong because it combines `namespaceSelector` and `podSelector` in one `from` entry (correctly), but then places `ipBlock` as a separate item in the same `from` array, which is syntactically invalid—`ipBlock` must be in its own `from` entry to be ORed with the selector-based rule.

Full explanation →

MCQmedium

A NetworkPolicy named 'deny-all' is applied in a namespace. Which YAML snippet correctly implements a default-deny-all ingress policy?

A.spec: podSelector: {} policyTypes: - Ingress

B.spec: podSelector: {} ingress: - from: []

C.spec: podSelector: matchLabels: {} ingress: - from: []

D.spec: podSelector: matchLabels: {} policyTypes: - Ingress

AnswerA

Empty podSelector targets all pods; no ingress rules means deny all ingress.

Why this answer

A NetworkPolicy with an empty `podSelector: {}` selects all pods in the namespace, and specifying `policyTypes: [Ingress]` without any `ingress` rules creates a default-deny-all ingress policy, blocking all incoming traffic. Options B and C include `ingress` rules (with empty `from`), which is not the standard approach for a strict deny-all; the canonical method is to omit the `ingress` field entirely when using `policyTypes: [Ingress]`.

Exam trap

The trap is that candidates often think specifying an empty `ingress: []` or `from: []` allows all traffic, but in Kubernetes NetworkPolicy, both an empty `ingress` list and an omitted `ingress` field result in denying all ingress traffic. However, the standard default-deny pattern is to omit the `ingress` field entirely while including `policyTypes: [Ingress]`.

How to eliminate wrong answers

Option B is wrong because it includes an `ingress` rule with an empty `from: []`, which actually allows all ingress traffic (an empty `from` matches nothing, but the presence of an `ingress` field with a rule means traffic is allowed by default). Option C is wrong because `matchLabels: {}` is equivalent to `podSelector: {}` but the inclusion of `ingress: [from: []]` again allows all ingress traffic, not deny-all. Option D is wrong because `matchLabels: {}` is valid, but it lacks the `ingress` field entirely; however, the `policyTypes: [Ingress]` alone without an `ingress` rule does deny all ingress, but the use of `matchLabels: {}` is unnecessary and could be misleading—the correct minimal form uses `podSelector: {}` without `matchLabels`.

Full explanation →

Multi-Selecthard

You have a Deployment 'web-app' with 4 replicas. You want to perform a rolling update such that during the update, at most 2 pods can be unavailable and at most 5 pods can be above the desired replica count. Which TWO of the following strategy configurations achieve this?

Select 2 answers

A.maxSurge: 3, maxUnavailable: 3

B.maxSurge: 5, maxUnavailable: 0

C.maxSurge: 5, maxUnavailable: 2

D.maxSurge: '125%', maxUnavailable: '50%'

E.maxSurge: 1, maxUnavailable: 2

AnswersC, D

Correct because maxSurge: 5 allows up to 5 extra pods, and maxUnavailable: 2 allows up to 2 unavailable, matching the requirement.

Why this answer

MaxSurge: 5 and maxUnavailable: 2 means during the rolling update, up to 2 pods can be unavailable (below the desired 4) and up to 5 extra pods can be created above the desired count, allowing a total of 9 pods at peak. This satisfies the requirement that at most 2 pods are unavailable and at most 5 pods are above the desired replica count. Option D is correct because 125% of 4 equals 5, and 50% of 4 equals 2, so the effective limits are the same as option C.

Option B is incorrect because maxUnavailable: 0 prevents any pod from becoming unavailable during the update, making it impossible to delete old pods without violating the constraint. A rolling update requires some pods to become temporarily unavailable when they are terminated; with maxUnavailable=0, the update cannot proceed because no pod can be terminated. Thus, the configuration does not achieve a successful rolling update.

Options A and E are incorrect because they allow more than 2 pods unavailable (A: maxUnavailable=3) or allow only 1 extra pod (E: maxSurge=1), not the required 5.

Exam trap

The CKAD exam often tests the distinction between absolute and percentage values for maxSurge and maxUnavailable, and the trap here is that candidates may incorrectly assume percentages are always rounded down or that both values must be integers, missing that '125%' and '50%' produce the same effective limits as 5 and 2 for a 4-replica deployment.

Full explanation →

MCQmedium

A Role named 'pod-reader' in namespace 'ns1' grants get, list, and watch on pods. Which RoleBinding correctly binds this role to a ServiceAccount 'sa1' in the same namespace?

A.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1

B.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: User name: sa1

C.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: ClusterRole, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: ns1

D.roleRef: { apiGroup: rbac.authorization.k8s.io, kind: Role, name: pod-reader } subjects: - kind: ServiceAccount name: sa1 namespace: default

AnswerA

This is correct because a RoleBinding in ns1 uses roleRef to bind the namespaced Role 'pod-reader' to ServiceAccount 'sa1' also in ns1. RoleBindings are namespaced, and both the Role and the ServiceAccount must reside in the same namespace as the binding for the permissions to apply. Here the subject kind is ServiceAccount, which matches the intended identity, so sa1 will receive the Role's permissions.

Why this answer

A RoleBinding in the same namespace as the Role and ServiceAccount must specify the Role's kind as 'Role' (not ClusterRole) and include the ServiceAccount's namespace in the subjects list. The roleRef references the 'pod-reader' Role with the correct apiGroup and kind, and the subject specifies the ServiceAccount 'sa1' in namespace 'ns1', which matches the Role's namespace, allowing the binding to grant the permissions.

Exam trap

The trap here is that candidates often forget to include the ServiceAccount's namespace in the subjects list or mistakenly use 'kind: User' for a ServiceAccount, leading to a binding that either fails or applies to the wrong entity.

How to eliminate wrong answers

Option B is wrong because it uses 'kind: User' instead of 'kind: ServiceAccount', and a ServiceAccount cannot be bound via a User subject; the subject must match the actual entity type. Option C is wrong because it uses 'kind: ClusterRole' in the roleRef, but the question specifies a Role (namespaced), not a ClusterRole; a RoleBinding can only reference a Role in the same namespace or a ClusterRole (which would then be scoped to the namespace), but here the role is a Role, so the kind must be 'Role'. Option D is wrong because it specifies 'namespace: default' in the subject, but the ServiceAccount 'sa1' is in namespace 'ns1', so the subject's namespace must match the ServiceAccount's actual namespace for the binding to work.

Full explanation →

MCQhard

An Ingress resource is configured with TLS termination. The secret referenced in the Ingress is present, but the Ingress controller returns 404. What is the most likely cause?

A.The IngressClass annotation is missing

B.The Ingress controller is not installed

C.The backend Service does not have any endpoints

D.The TLS certificate is expired

AnswerC

The Ingress controller dynamically discovers the backend Service's endpoints (via EndpointSlices) and configures its proxy to forward traffic to those IPs. If the Service selector matches no pods or the pods are not Ready, the endpoint list is empty, leaving no upstream target for the proxy to route to; the controller therefore responds with HTTP 404 for that host/path. This is a classic cause of '404 Not Found' even when Ingress and Service definitions appear valid, so checking `kubectl get endpoints <service>` is the standard diagnostic step.

Why this answer

When an Ingress returns a 404 error despite TLS being configured and the secret present, the most common cause is that the backend Service has no healthy endpoints. The Ingress controller routes traffic to the Service's endpoints (pods), and if none are ready (e.g., due to failed readiness probes or scaled-to-zero replicas), the controller has no target to forward requests to, resulting in a 404 response.

Exam trap

Candidates often assume that a 404 error with TLS configured indicates a certificate or secret issue, but in Kubernetes, the Ingress controller returns a 404 when the backend Service lacks ready endpoints.

How to eliminate wrong answers

Option A is wrong because the IngressClass annotation is used to specify which Ingress controller should process the resource; its absence would cause the Ingress to be ignored entirely, not a 404 after TLS termination. Option B is wrong because if the Ingress controller were not installed, the Ingress resource would have no effect at all, and the 404 would likely come from a default backend or no route at all, not from TLS-terminated traffic. Option D is wrong because an expired TLS certificate would cause TLS handshake errors (e.g., certificate expired in browser or curl), not a 404 HTTP status code, which is an application-layer response after the TLS connection is established.

Full explanation →

100

Multi-Selecthard

An administrator wants to implement Pod Security Admission (PSA) to enforce the 'restricted' policy for pods in the 'secure' namespace, but allow certain pods to use privileged containers by applying an exemption label. Which three steps are required? (Choose three.)

Select 3 answers

A.Use 'pod-security.kubernetes.io/audit=restricted' to log violations without enforcement.

B.Enable the PodSecurity feature gate on the API server and kubelet.

C.Create a ServiceAccount for exempted pods and label it with 'pod-security.kubernetes.io/enforce=privileged'.

D.Install a custom container runtime that supports privilege escalation.

E.Set the namespace label 'pod-security.kubernetes.io/enforce=restricted' on the 'secure' namespace.

AnswersA, C, E

Setting the audit label logs violations without enforcement, which helps assess the impact before enforcing. It is a recommended step but not strictly required for enforcement. However, in this scenario, it is considered a required step for implementation.

Why this answer

Setting the audit label to 'restricted' logs violations, which is a common initial step to assess compliance before enforcing the policy. Option C is correct because creating a ServiceAccount and labeling it with 'pod-security.kubernetes.io/enforce=privileged' exempts pods using that ServiceAccount from the restricted policy, allowing them to run privileged containers. Option E is correct because setting the namespace label 'pod-security.kubernetes.io/enforce=restricted' enforces the restricted policy on all pods in that namespace that are not exempted.

Option B is not required because the PodSecurity feature gate is enabled by default in Kubernetes v1.23+. Option D is incorrect because PSA uses security context validation, not a custom runtime.

Exam trap

The trap is that candidates may think enabling the PodSecurity feature gate is necessary, but it is default in newer Kubernetes versions. Also, they may confuse audit and enforce modes, or think a custom runtime is needed for privilege escalation.

Full explanation →

101

MCQmedium

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

B.Delete the namespace and redeploy all workloads

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

D.Increase the CPU request for the container

AnswerC

OOMKilled is the kubelet's signal that the container's memory usage exceeded its specified limit, prompting the kernel OOM killer to terminate the process. Raising the memory limit in the container's resource specification permits the container to consume more memory before that threshold is reached, directly addressing the root cause and allowing the pod to remain running. This is the expected fix when the application's nominal memory footprint is larger than the old limit but still fits within node capacity.

Why this answer

The pod is in CrashLoopBackOff due to OOMKilled, which means the container's memory usage exceeded its configured memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to allocate more memory without being terminated by the Out-of-Memory (OOM) killer.

Exam trap

The trap here is that candidates often confuse OOMKilled with a general crash and choose to delete and recreate the pod (Option A), not realizing that the resource limit itself must be adjusted to prevent recurrence.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the pod will not resolve the underlying memory limit issue; the new pod will still have the same resource constraints and will be OOMKilled again. Option B is wrong because deleting the entire namespace and redeploying all workloads is an extreme, disruptive action that does not address the specific memory limit problem and would cause unnecessary downtime. Option D is wrong because increasing the CPU request does not affect memory allocation; the OOMKilled status is caused by exceeding the memory limit, not CPU constraints.

Full explanation →

102

MCQmedium

You want to expose a Deployment 'app' externally on port 30080 on each node. What service type should you use?

A.LoadBalancer

B.ExternalName

C.NodePort

D.ClusterIP

AnswerC

NodePort is the correct choice because it exposes the service on a static port on every worker node's IP address, allowing external clients to access the deployment via any node's IP:nodePort. This provides direct external access to the pods without needing a cloud load balancer, and it's the standard way to expose a deployment on a specific port for simple use cases.

Why this answer

A NodePort service exposes the Deployment on a static port (30080) on each node's IP address, making it accessible externally via <NodeIP>:30080. This is the correct choice because the requirement explicitly asks to expose the app on port 30080 on each node, which matches the NodePort service type's behavior of opening a specific port on every node in the cluster.

Exam trap

The trap here is that candidates may confuse NodePort with LoadBalancer, thinking that exposing on 'each node' implies a load balancer, but NodePort specifically provides per-node port exposure without requiring a cloud provider.

How to eliminate wrong answers

Option A is wrong because a LoadBalancer service provisions an external load balancer (typically from a cloud provider) and does not guarantee exposure on a specific port on each node; it creates a single external IP and port, not per-node ports. Option B is wrong because an ExternalName service maps a service to a DNS name (via CNAME) and does not expose any ports or provide external access to a Deployment; it is used for internal DNS aliasing. Option D is wrong because a ClusterIP service is only reachable within the cluster via its internal IP and cannot be accessed externally from outside the cluster.

Full explanation →

103

Multi-Selectmedium

Which TWO of the following are valid fields in a container's SecurityContext to restrict privilege escalation? (Select two.)

Select 2 answers

A.allowPrivilegeEscalation

B.readOnlyRootFilesystem

C.runAsNonRoot

D.privileged

E.capabilities

AnswersA, E

Setting this to false prevents privilege escalation.

Why this answer

A is correct because `allowPrivilegeEscalation` directly controls whether a process can gain more privileges than its parent, such as via setuid binaries or file capabilities. Setting it to `false` prevents privilege escalation, which is a core security requirement for restricting container breakout.

Exam trap

CNCF often tests the distinction between fields that *prevent* privilege escalation versus fields that enforce other security constraints like filesystem immutability or user identity, leading candidates to confuse `readOnlyRootFilesystem` or `runAsNonRoot` with escalation control.

Full explanation →

104

MCQhard

You are tasked with running a batch job that processes 100 items in parallel, using a Kubernetes Job. The Job should ensure that all items are processed even if some pods fail, and the total number of pod failures should be limited to 3. Which Job configuration is correct?

A.Set spec.parallelism: 100, spec.completions: 100, spec.backoffLimit: 3

B.Set spec.parallelism: 1, spec.completions: 100, spec.backoffLimit: 3

C.Set spec.parallelism: 100, spec.completions: 1, spec.backoffLimit: 3

D.Set spec.parallelism: 100, spec.completions: 100, spec.activeDeadlineSeconds: 300

AnswerA

This configuration correctly matches the workload: spec.parallelism: 100 lets up to 100 pods run simultaneously to process the 100 items in parallel, while spec.completions: 100 ensures the Job is not marked successful until each of the 100 items is handled by a successful pod completion. Adding spec.backoffLimit: 3 caps the number of retries for failing pods to 3, providing a sane bound on wasted work. Together these fields encode the exact concurrency and completion requirements for a 100-item batch without any time-based preemption.

Why this answer

Setting `spec.parallelism: 100` allows 100 pods to run concurrently, `spec.completions: 100` ensures all 100 items are processed (each pod handles one item), and `spec.backoffLimit: 3` limits the total number of pod failures to 3 before the Job is marked as failed. This configuration guarantees that even if some pods fail, the Job will retry them up to the specified backoff limit, ensuring all items are processed.

Exam trap

The trap here is confusing `backoffLimit` (which limits pod failures) with `activeDeadlineSeconds` (which limits the overall Job runtime), leading candidates to pick Option D, which fails to cap failures and instead imposes a time constraint.

How to eliminate wrong answers

Option B is wrong because `spec.parallelism: 1` forces pods to run sequentially, not in parallel, which defeats the requirement to process 100 items in parallel. Option C is wrong because `spec.completions: 1` means the Job only needs one successful pod completion, so it will not process all 100 items. Option D is wrong because `spec.activeDeadlineSeconds: 300` sets a time limit for the Job, but does not limit the number of pod failures; the `backoffLimit` field is required to cap failures at 3.

Full explanation →

105

MCQhard

You have a Deployment 'db' that uses a ConfigMap for configuration. You want to update the ConfigMap and roll out the changes to pods without restarting them manually. Which approach should you use?

A.Delete the ConfigMap and recreate it with the same name

B.Update the ConfigMap and then update the Deployment's pod template (e.g., change an annotation) to trigger a rolling update

C.Edit the ConfigMap and run kubectl rollout restart deployment/db

D.Use kubectl replace on the ConfigMap and the pods will automatically get the new values

AnswerB

Pods will be recreated with the new ConfigMap.

Why this answer

Mounting ConfigMaps as volumes with subPath does not automatically update pods; however, using environment variables from ConfigMaps also does not update pods. The recommended approach is to use a Deployment update with a change that triggers a rollout (e.g., updating an annotation). Option B is correct.

Full explanation →

106

MCQmedium

You are debugging a pod that is running but not responding to network requests on port 8080. You suspect the application inside the container is faulty. You need to run an interactive shell inside the container to inspect the process. Which command should you use?

A.kubectl describe pod pod-name

B.kubectl logs pod-name -f

C.kubectl debug -it pod-name --image=busybox

D.kubectl exec -it pod-name -- /bin/sh

AnswerD

kubectl exec -it pod-name -- /bin/sh attaches directly to the primary container's process namespace and starts an interactive shell there. The -i flag keeps stdin open, and -t allocates a pseudo-TTY, giving you a real terminal session. This lets you run commands such as ps, cat /proc/1/cmdline, lsof, and netstat inside the exact runtime where the application is hanging, enabling direct inspection and troubleshooting of the live process. It is the only option that provides an interactive shell within the existing, running container.

Why this answer

`kubectl exec -it pod-name -- /bin/sh` opens an interactive shell inside the running container, allowing you to inspect processes, check network listeners, and debug the application directly. This is the standard command for gaining shell access to a container in Kubernetes.

Exam trap

The trap here is that candidates confuse `kubectl exec` (which runs a command in an existing container) with `kubectl debug` (which creates a new ephemeral container), and they may choose option C thinking it provides interactive access, but it does not attach to the original application container's process space.

How to eliminate wrong answers

Option A is wrong because `kubectl describe pod` shows pod metadata, events, and status but does not provide an interactive shell or allow process inspection inside the container. Option B is wrong because `kubectl logs -f` streams container logs, which is useful for viewing output but does not give you an interactive shell to run commands or inspect processes. Option C is wrong because `kubectl debug -it pod-name --image=busybox` creates a separate ephemeral container for debugging, not an interactive shell inside the original application container; it is used when the container image lacks debugging tools or the container is crashing, but the question specifies the pod is running and you need to inspect the existing application process.

Full explanation →

107

Multi-Selecteasy

Which TWO Service types allow external access to pods from outside the Kubernetes cluster? (Select 2)

Select 2 answers

A.Headless

B.NodePort

C.ClusterIP

D.ExternalName

E.LoadBalancer

AnswersB, E

A NodePort service exposes a specific static port (30000–32767) on every cluster node’s IP address, forwarding inbound traffic from that port to the target pods. This mechanism satisfies the stem’s constraint of enabling external access from outside the cluster because any external client can reach the service by targeting `<NodeIP>:<NodePort>`, bypassing the cluster-internal network boundary.

Why this answer

NodePort is correct because it exposes a service on a static port on each node's IP address, allowing external traffic to reach the service by targeting any node's IP and that port. This works by opening a high-range port (30000-32767) on all nodes, which forwards traffic to the ClusterIP service and then to the pods.

Exam trap

The CKAD exam often tests the misconception that ClusterIP or Headless services can be accessed externally, when in fact only NodePort and LoadBalancer (and Ingress, though not listed) provide external access without additional configuration.

Full explanation →

108

Multi-Selecteasy

Which TWO of the following are valid Kubernetes Secret types? (Select two.)

Select 3 answers

A.kubernetes.io/password

B.kubernetes.io/ssh-auth

C.kubernetes.io/configmap

D.kubernetes.io/tls

E.Opaque

AnswersB, D, E

Correct. `kubernetes.io/ssh-auth` is a built-in Secret type for SSH credentials.

Why this answer

kubectl create secret tls, kubectl create secret ssh-auth, and kubectl create secret generic (which creates an Opaque secret) are all valid Kubernetes Secret types. The type kubernetes.io/ssh-auth is used for SSH credentials, kubernetes.io/tls is used for TLS certificates, and Opaque is the default type for arbitrary user-defined data. Options A (kubernetes.io/password) and C (kubernetes.io/configmap) are not valid Secret types.

Exam trap

Candidates often mistakenly believe that Opaque is not a valid Secret type because it is the default, but it is indeed valid. Also, be aware that kubernetes.io/password and kubernetes.io/configmap are not real Secret types.

Full explanation →

109

MCQhard

You need to debug a pod that is running but not serving traffic. You want to add a temporary container with networking tools to the pod. Which command should you use?

A.kubectl run debug --image=busybox -it --restart=Never -- /bin/sh

B.kubectl attach mypod

C.kubectl exec -it mypod -- /bin/sh

D.kubectl debug mypod --image=busybox -it

AnswerD

kubectl debug mypod --image=busybox -it adds an ephemeral container to the same pod, sharing the pod's network namespace, filesystem mounts, and IPC. This gives you a fresh multitool environment (busybox) without disturbing the original container, ideal for inspecting network endpoints, DNS, or routing from the pod's point of view. It is the standard, non-invasive way to debug a running pod that is not serving traffic as expected.

Why this answer

`kubectl debug` allows you to add an ephemeral container (a temporary container with networking tools) to an existing running pod without restarting it. This is the only command that directly injects a new container into the pod's network namespace, enabling debugging of network issues while the original container continues running.

Exam trap

The trap here is that candidates confuse `kubectl exec` (which runs a command in an existing container) with `kubectl debug` (which adds a new container), and they forget that `kubectl exec` requires the target container to have the necessary tools installed, which is often not the case in production images.

How to eliminate wrong answers

Option A is wrong because `kubectl run debug --image=busybox -it --restart=Never -- /bin/sh` creates a completely new, standalone pod, not a temporary container attached to the existing pod. Option B is wrong because `kubectl attach mypod` attaches to the main process of an existing container in the pod, but it does not add a new container or provide networking tools; it only connects to the container's stdin/stdout/stderr. Option C is wrong because `kubectl exec -it mypod -- /bin/sh` runs a command inside an existing container of the pod, but if that container lacks networking tools (e.g., a minimal distroless image), you cannot install them without modifying the image.

Full explanation →

110

MCQhard

You have an Ingress with TLS configured. The Ingress controller returns a certificate error when accessing via HTTPS. The secret 'my-tls' exists in the same namespace. Which of the following is the most likely cause?

A.The secret name in the TLS section of the Ingress does not match the actual secret name

B.The Ingress controller does not support TLS

C.The secret is in a different namespace than the Ingress

D.The certificate is not signed by a trusted CA

AnswerA

The TLS block in an Ingress references a Kubernetes Secret by name to obtain the certificate and private key. If the name in the TLS section does not exactly match the name of an existing Secret in the Ingress's namespace, the controller cannot locate the Secret, so it cannot load the certificate. This typically results in the controller reporting a certificate fetch error or falling back to serving a default certificate, which is often the observable symptom in this scenario.

Why this answer

The most likely cause is that the secret name specified in the TLS section of the Ingress resource does not match the actual name of the Secret object. When TLS is configured, the Ingress controller reads the `secretName` field to fetch the certificate and key; a mismatch causes the controller to fail to load the TLS material, resulting in a certificate error. Since the secret exists in the same namespace, the only plausible issue is a naming mismatch.

Exam trap

The trap here is that candidates assume a certificate error always means the certificate is invalid or untrusted, but the CKAD exam tests the specific Kubernetes configuration issue where the secret name in the Ingress TLS section does not match the actual Secret object name.

How to eliminate wrong answers

Option B is wrong because the Ingress controller must support TLS to serve HTTPS at all; if it did not, the error would be about TLS not being available, not a certificate error. Option C is wrong because the question explicitly states the secret exists in the same namespace, and Ingress resources can only reference secrets in their own namespace (Kubernetes enforces this). Option D is wrong because an untrusted CA would cause a browser warning about an invalid certificate authority, not a certificate error from the Ingress controller itself; the controller would still load the certificate and serve it.

Full explanation →

111

Multi-Selectmedium

Which TWO of the following are true about Kustomize overlays? (Select 2)

Select 2 answers

A.Overlays can only add labels, not modify existing ones.

B.Overlays are used to customize resources for different environments.

C.Overlays must be stored in the same directory as the base.

D.Overlays can patch resources defined in a base.

E.Overlays can only be used with Helm charts.

AnswersB, D

Overlays apply environment-specific patches.

Why this answer

Overlays are used to customize resources for different environments, and they can patch resources defined in bases.

Full explanation →

112

MCQhard

You have a multi-container pod with two containers: container-A and container-B. container-B needs to access the network of container-A. Which configuration is required?

A.Define a ServiceAccount for container-B to access container-A

B.No additional configuration is needed; they share the same network namespace

C.Set hostNetwork: true in the pod spec

D.Expose the port in container-A and map it in container-B

AnswerB

Containers in a Pod share the same network namespace by design, meaning they all use the same IP address, loopback interface, and network stack. This allows container-B to simply connect to container-A's port using 127.0.0.1 or localhost. Kubernetes automatically configures this shared namespace, so no additional YAML settings, port mappings, or service definitions are required for inter-container communication.

Why this answer

In Kubernetes, containers within the same pod share the same network namespace by default, including the same IP address and port space. This means container-B can reach container-A via localhost and the port that container-A is listening on, without any additional configuration. The shared network namespace is a fundamental property of pod design, enabling direct inter-container communication.

Exam trap

The trap here is that candidates often think inter-container communication requires services or explicit port exposure, forgetting that containers in the same pod inherently share the network stack and can communicate via localhost.

How to eliminate wrong answers

Option A is wrong because a ServiceAccount controls authentication and authorization for API access, not network connectivity between containers in the same pod; network namespace sharing is independent of RBAC. Option C is wrong because setting hostNetwork: true makes the pod use the node's network stack, which is unnecessary and changes the pod's IP to the node's IP, breaking the default shared pod network namespace. Option D is wrong because port mapping is not required; containers in the same pod communicate via localhost and the target container's port directly, as they share the same network namespace without any port forwarding.

Full explanation →

113

MCQeasy

An init container in a pod runs a database migration script. The init container fails and exits with a non-zero exit code. What will happen to the pod?

A.The main containers will start anyway

B.The pod will enter CrashLoopBackOff

C.The init container will be restarted until it succeeds

D.The pod will be deleted and recreated

AnswerC

Correct: init containers are restarted on failure until they succeed.

Why this answer

Init containers must run successfully (exit 0) before the main containers start. If an init container fails, Kubernetes restarts it (if restartPolicy is Always or OnFailure) until it succeeds. The pod will remain in Init:Error state until the init container succeeds.

Full explanation →

114

MCQmedium

You have a Pod with two containers: a main application and a sidecar that handles logging. The sidecar needs access to the same log files as the main application. Which volume type allows both containers to share files?

A.persistentVolumeClaim

B.hostPath

C.configMap

D.emptyDir

AnswerD

emptyDir creates an empty directory when a pod is assigned to a node, and it remains available as long as the pod runs, allowing all containers in the pod to mount the same volume and share files seamlessly. It is the standard Kubernetes mechanism for inter-container communication via the filesystem, and it requires no persistent storage provisioning or external dependencies. Because the log files only need to exist for the pod's lifetime and must be shared between the main application and the logging sidecar, emptyDir exactly matches the requirement.

Why this answer

An `emptyDir` volume is created when a Pod is assigned to a node and exists as long as the Pod runs, allowing both containers in the same Pod to mount and share the same directory. This is the simplest and most appropriate volume type for sharing ephemeral data, such as log files, between a main application and a sidecar container within the same Pod.

Exam trap

The trap here is that candidates often confuse `emptyDir` with `hostPath` or `persistentVolumeClaim` because they think of 'shared storage' in terms of persistent or host-level volumes, but the CKAD exam specifically tests the Pod-level ephemeral sharing pattern using `emptyDir` for sidecar containers.

How to eliminate wrong answers

Option A is wrong because a `persistentVolumeClaim` is used to request persistent storage that survives Pod restarts and is typically used for data that must persist beyond the Pod's lifecycle, not for sharing files between containers within the same Pod. Option B is wrong because a `hostPath` volume mounts a file or directory from the host node's filesystem into the Pod, which introduces node-specific dependencies and is not recommended for sharing data between containers in a multi-container Pod; it also violates Pod portability. Option C is wrong because a `ConfigMap` is designed to inject configuration data (key-value pairs or small files) into containers, not for sharing dynamic, writable log files between containers; it is read-only by default and cannot be used for runtime file sharing.

Full explanation →

115

Multi-Selectmedium

Which THREE of the following are valid reasons to use an annotation in Kubernetes?

Select 3 answers

A.To enable a Service to select Pods based on the annotation value

B.To store the name of the CI/CD tool that deployed the resource

C.To record the build version or commit hash for auditing

D.To set resource limits for a container

E.To attach arbitrary non-identifying metadata to an object

AnswersB, C, E

Annotations can hold deployment tool metadata.

Why this answer

Annotations are key-value metadata used for non-identifying information. Option A is incorrect because selection of Pods by a Service is done using labels, not annotations. Option B is correct: annotations can store tooling metadata like CI/CD tool name.

Option C is correct: build versions and commit hashes are typical audit information stored in annotations. Option D is incorrect because resource limits are set in the container spec, not in annotations. Option E is correct: annotations are designed for arbitrary non-identifying metadata.

Full explanation →

116

MCQmedium

You want to ensure your application shuts down gracefully when a pod is terminated. The application needs 30 seconds to clean up. Which field should you set in the pod spec?

A.spec.containers[].livenessProbe.initialDelaySeconds: 30

B.spec.containers[].lifecycle.preStop.exec.command: ["sleep", "30"]

C.spec.containers[].readinessProbe.periodSeconds: 30

D.terminationGracePeriodSeconds: 30

AnswerD

This pod-level field defines the duration between when Kubernetes sends SIGTERM to the container's primary process and when it forcibly follows up with SIGKILL. Setting it to 30 seconds grants your application a full half-minute to finish in-flight requests, close connections, flush logs, and release external resources. Without this grace period, or if set too low, the kubelet will kill the process forcefully, likely causing data loss or incomplete cleanup.

Why this answer

`terminationGracePeriodSeconds` defines the time Kubernetes waits for a pod to shut down gracefully after sending a SIGTERM signal. Setting it to 30 seconds gives the application the required cleanup window before a SIGKILL is forced.

Exam trap

CNCF often tests the misconception that a `preStop` hook alone guarantees graceful shutdown, but without adjusting `terminationGracePeriodSeconds`, the hook's execution time is counted against the default 30-second grace period, potentially causing a SIGKILL before cleanup completes.

How to eliminate wrong answers

Option A is wrong because `livenessProbe.initialDelaySeconds` controls how long to wait before starting the liveness probe, not the shutdown behavior. Option B is wrong because `preStop` hooks run before the SIGTERM is sent, but they do not extend the total grace period; the `terminationGracePeriodSeconds` must be set to accommodate both the hook and the application's cleanup. Option C is wrong because `readinessProbe.periodSeconds` sets the interval for readiness checks, which is unrelated to graceful termination.

Full explanation →

117

MCQhard

You are debugging a network issue: a pod 'frontend' cannot reach a service 'backend' in the same namespace. The service endpoints are empty. What is the most likely cause?

A.The pod 'frontend' is not in the same namespace as the service 'backend'.

B.The service selector does not match the labels of any running pod.

C.The pod's container port is different from the service port.

D.The kube-proxy is misconfigured and not updating iptables rules.

AnswerB

Endpoints are created by the endpoint controller, which watches pods and compares each pod's labels against the service's spec.selector. If no running pod carries every label key/value in that selector, the Endpoints object remains with an empty address list, even though the service itself exists. This is the textbook cause of an empty Endpoints resource and the correct answer to this symptom.

Why this answer

B is correct because the most common reason for empty endpoints in a Kubernetes service is that the service's selector does not match the labels of any running pod. The service controller continuously monitors pods and updates the Endpoints object to include only those pods whose labels match the service's selector. If no pods match, the endpoints list remains empty, causing the frontend pod to fail to reach the backend service.

Exam trap

The trap here is that candidates often confuse the cause of empty endpoints with other networking issues like port mismatches or kube-proxy problems, but the CKAD exam specifically tests the understanding that endpoints are directly tied to label selector matching, not to port configuration or proxy behavior.

How to eliminate wrong answers

Option A is wrong because the question explicitly states that both the pod and service are in the same namespace, so namespace mismatch is not the cause. Option C is wrong because a mismatch between the container port and the service port would cause connection failures but would not result in empty endpoints; the endpoints would still be populated with the pod's IP and the container port. Option D is wrong because a misconfigured kube-proxy would affect traffic routing (e.g., iptables rules not being updated) but would not cause the service's endpoints to be empty; endpoints are managed by the endpoint controller, not kube-proxy.

Full explanation →

118

MCQmedium

You have a multi-stage Dockerfile. The first stage builds a binary using a large build image. The second stage copies the binary from the first stage into a minimal runtime image. Which Dockerfile instruction is used to copy artifacts from a previous stage?

A.ADD --from=builder /app/artifact /app/

B.ENTRYPOINT --from=builder /app/artifact /app/

C.CMD --from=builder /app/artifact /app/

D.COPY --from=builder /app/artifact /app/

AnswerD

This is the correct multi-stage copy directive: the --from=builder flag tells Docker to retrieve /app/artifact from the filesystem of the stage named 'builder' (created with FROM ... AS builder) and place it at /app/ in the current stage. COPY preserves permissions and is the standard way to transplant compiled artifacts between stages without including the entire build environment in the final image.

Why this answer

In multi-stage Docker builds, the COPY instruction with the --from flag allows you to copy files from a named previous stage (e.g., 'builder') into the current stage. This is the standard Docker mechanism for selectively transferring build artifacts while discarding intermediate build dependencies, enabling a smaller final image.

Exam trap

This question tests the distinction between COPY and ADD in multi-stage builds. The trap is that candidates may confuse ADD's additional features (like URL fetching or tar extraction) with the --from flag, or mistakenly think ENTRYPOINT or CMD can be used for file operations.

How to eliminate wrong answers

Option A is wrong because ADD does support --from for multi-stage builds, but it is not the idiomatic or recommended instruction for copying artifacts; COPY is preferred for its simplicity and predictability. Option B is wrong because ENTRYPOINT defines the container's entry point command, not a file copy operation, and does not support --from. Option C is wrong because CMD provides default command arguments for the container, not file copying, and also lacks --from support.

Full explanation →

119

MCQhard

You have a Service that exposes a Deployment. Some pods are not receiving traffic. 'kubectl get endpoints my-service' shows only 2 out of 3 pod IPs. What is the most likely cause?

A.The Deployment has a wrong targetPort

B.The Service type is NodePort

C.One pod has a different label than the Service selector

D.One pod is not ready (readiness probe failing)

AnswerD

Only pods that are both matching the Service selector and in a Ready state are included as endpoints. A pod can be Running and have passed startup liveness checks, but if its readiness probe is failing, Kubernetes sets the pod's Ready condition to False, and the EndpointController immediately removes it from all Services it backs. This is why some pods appear while others—those with failing readiness probes—are missing from the endpoints list, even though they are part of the Deployment.

Why this answer

The most likely cause is that one pod is not ready because its readiness probe is failing. Services only forward traffic to pods that are in the Ready state, as reflected in the Endpoints object. If a pod fails its readiness probe, it is removed from the list of endpoints, even if it is running and has the correct labels.

Exam trap

The trap here is that candidates often confuse readiness probes with liveness probes or assume that any pod with matching labels will automatically receive traffic, ignoring the critical role of the Ready condition in endpoint selection.

How to eliminate wrong answers

Option A is wrong because a wrong targetPort would cause all pods to fail to receive traffic, not just one out of three. Option B is wrong because the Service type being NodePort does not affect which pods receive traffic; NodePort simply exposes the Service on each node's IP at a static port. Option C is wrong because if one pod had a different label than the Service selector, that pod would never be included in the Endpoints object at all, but the question states that only 2 out of 3 pod IPs are shown, implying the third pod was previously included but is now removed due to readiness failure.

Full explanation →

120

MCQeasy

Which Service type is used to expose a service externally on a static port on each worker node?

A.NodePort

B.ExternalName

C.ClusterIP

D.LoadBalancer

AnswerA

NodePort is correct because it directly answers the question: it opens a static port (typically in the 30000–32767 range) on every node's IP address, and kube-proxy routes traffic from that nodePort to the backing pods via the service's ClusterIP. Because the port is opened on each node, any client that can reach a node's IP can access the service at that nodeIP:nodePort. It is the only service type whose defining behavior is exactly this node-level static port exposure.

Why this answer

A NodePort service exposes the application on a static port (in the range 30000-32767) on every worker node's IP address. This allows external traffic to reach the service by targeting any node's IP and the assigned NodePort, making it the correct choice for exposing a service externally on a static port per node.

Exam trap

A common mistake is confusing NodePort with LoadBalancer. LoadBalancer does not expose a static port on every node; it provisions an external load balancer with a single IP. NodePort is the correct type for a static port on every worker node.

How to eliminate wrong answers

Option B (ExternalName) is wrong because it maps a service to a DNS name (CNAME record) and does not expose any port or route traffic to pods; it is used for internal DNS aliasing, not external exposure. Option C (ClusterIP) is wrong because it exposes the service only on a cluster-internal IP, reachable only from within the cluster, not externally on worker nodes. Option D (LoadBalancer) is wrong because it provisions an external load balancer (e.g., from a cloud provider) that provides a single external IP, not a static port on each worker node; it builds on NodePort but adds a load balancer layer.

Full explanation →

121

Multi-Selectmedium

You are designing a health check strategy for a web application. Which TWO probe types should you configure to ensure that traffic is only sent to pods that are ready to serve?

Select 2 answers

A.Readiness probe

B.TCP socket probe

C.Startup probe

D.HTTP GET probe

E.Liveness probe

AnswersA, C

Controls whether a pod is included in service endpoints.

Why this answer

A Readiness probe (Option A) is specifically designed to determine whether a pod is ready to serve traffic. If the probe fails, the pod is removed from the Service's endpoints, ensuring traffic is only sent to pods that are ready. This directly fulfills the requirement of controlling traffic routing based on pod readiness.

Exam trap

The trap here is that candidates confuse probe handlers (like HTTP GET or TCP socket) with probe types (like readiness, liveness, startup), leading them to select handlers instead of the correct probe types that control traffic routing.

Full explanation →

122

MCQeasy

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

A.To provide a debugging shell into the pod

B.To handle traffic routing between services

C.To run a long-running process alongside the main container

D.To perform initialization tasks such as waiting for a database to be ready

AnswerD

Init containers are purpose-built for one-time setup tasks that must finish before the application starts. They run sequentially, and each must complete successfully before the next one starts, ensuring prerequisites like database readiness, schema migrations, or configuration downloads are met. This makes them ideal for blocking the app container until its dependencies are ready, rather than burdening the app itself with retry logic.

Why this answer

Init containers run to completion before the main application containers start, making them ideal for setup tasks like waiting for a database to be ready (e.g., using a `pg_isready` loop). They ensure the main container only runs when its prerequisites are satisfied, which is the core purpose defined in the Kubernetes documentation.

Exam trap

The trap here is confusing init containers with sidecar containers, as both run in the same pod, but init containers are strictly for one-time setup tasks and exit, while sidecars run continuously alongside the main container.

How to eliminate wrong answers

Option A is wrong because a debugging shell is provided by a sidecar container or ephemeral container (e.g., `kubectl debug`), not an init container, which runs to completion and cannot be accessed interactively. Option B is wrong because traffic routing between services is handled by Kubernetes Services, Ingress controllers, or network policies, not by init containers, which have no network proxy or routing logic. Option C is wrong because a long-running process alongside the main container is the role of a sidecar container (e.g., a logging agent), whereas init containers are designed to run to completion and exit before the main container starts.

Full explanation →

123

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 →

124

Multi-Selectmedium

Which TWO of the following commands create a ConfigMap named 'my-config' from a file named 'app.properties'? (Choose two.)

Select 3 answers

A.kubectl create configmap my-config --from-file=app.properties --from-literal=extra=value

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

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

D.kubectl create configmap my-config --from-literal=app.properties

E.kubectl create configmap my-config --from-file=app.properties

AnswersB, C, E

The `--from-file=app.properties=app.properties` syntax sets the ConfigMap key to `app.properties` and the value to the file's content, but the stem requires a ConfigMap named `my-config` from a file named `app.properties` without specifying a custom key. This option is tempting because it explicitly maps a key to a file, which is correct when you need to override the default key name (the filename) with a different key, such as when the desired key differs from the source filename.

Why this answer

Options B, C, and E are all valid commands that create a ConfigMap named 'my-config' from the file 'app.properties'. Option B uses explicit key mapping (--from-file=app.properties=app.properties). Option C uses --from-env-file to read key-value pairs from the file.

Option E uses the default --from-file behavior. Option A is incorrect because it adds an extra literal (--from-literal=extra=value). Option D is invalid syntax.

Exam trap

Candidates often confuse --from-file with --from-env-file and think --from-literal can read a file. A subtle trap is that Option B is syntactically valid and creates the same ConfigMap as Option E, but some may consider it redundant; nonetheless, it is a correct command. The question asks for two choices, but there are three technically correct options, which can be confusing.

Full explanation →

125

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 →

126

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 →

127

MCQmedium

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

B.Increase the CPU request for the container

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

D.Delete the namespace and redeploy all workloads

AnswerA

The OOMKilled status means the container's memory usage exceeded its configured memory limit, triggering the kernel's out-of-memory killer. Raising the memory limit in the container resource spec gives the application more headroom to work within, directly addressing the root cause by preventing the OOM kill and subsequent CrashLoopBackOff. Correctly sizing the limit requires observing actual memory usage, as an arbitrarily high limit may hide memory leaks but does stop the crash loop.

Why this answer

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

Exam trap

The trap here is that candidates may confuse CPU and memory resource management or think that restarting the pod will fix the issue, but OOMKilled is a persistent resource constraint problem that requires adjusting the memory limit.

How to eliminate wrong answers

Option B is wrong because increasing the CPU request does not affect memory usage or prevent OOM kills; CPU and memory are independent resources in Kubernetes. Option C is wrong because deleting and recreating the pod will not resolve the underlying memory limit issue; the pod will crash again with the same OOMKilled error. Option D is wrong because deleting the entire namespace and redeploying all workloads is an extreme, unnecessary action that does not fix the memory limit configuration and would disrupt all other workloads in the namespace.

Full explanation →

128

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 →

129

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 →

130

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 →

131

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 →

132

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

Service Mesh provides fine-grained traffic splitting.

Why this answer

A Service Mesh like Istio uses a VirtualService resource to define traffic routing rules based on weights (e.g., `weight: 90` for stable and `weight: 10` for canary). This allows fine-grained, percentage-based traffic splitting between two different Kubernetes Services or subsets, which is a core requirement for canary deployments.

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 →

133

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 →

134

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 →

135

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 →

136

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 →

137

MCQmedium

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

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

C.Increase the CPU request for the container

D.Delete the namespace and redeploy all workloads

AnswerB

Increasing the memory limit in the container's resource specification directly addresses the root cause of this CrashLoopBackOff: the kernel's out-of-memory killer is terminating the container because its memory usage exceeds the cgroup memory limit. By raising the limit to a value above the container's observed steady-state memory footprint, the OOM kill no longer triggers, assuming the node has enough allocatable memory to grant the new limit. This is the correct remediation because the container is not being killed for CPU or scheduling reasons—it is strictly a memory limit violation.

Why this answer

The pod is in CrashLoopBackOff due to OOMKilled, meaning the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. The most appropriate action is to increase the memory limit in the pod's container resource specification, as this directly addresses the root cause—insufficient memory allocation—without requiring a full redeployment or affecting other workloads.

Exam trap

The CKAD exam often tests the distinction between memory and CPU resources, and the trap here is that candidates may confuse OOMKilled (a memory issue) with a CPU throttling or resource starvation problem, leading them to incorrectly adjust CPU settings instead of memory limits.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the pod would only restart the same container with the same memory limit, leading to an immediate repeat of the OOMKilled crash. Option C is wrong because increasing the CPU request does not affect memory constraints; OOMKilled is a memory issue, not a CPU issue. Option D is wrong because deleting the entire namespace and redeploying all workloads is an extreme, unnecessary action that would disrupt all services in the namespace and does not solve the specific memory limit problem for this pod.

Full explanation →

138

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 →

139

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 →

140

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 →

141

MCQmedium

A pod manifest includes the following securityContext: securityContext: { runAsUser: 1000, runAsGroup: 3000, fsGroup: 2000 }. What UID will be used for processes in the container?

A.0 (root)

B.3000

C.2000

D.1000

AnswerD

runAsUser: 1000 is the correct UID because it directly sets the numeric user ID for the container's primary process. When a container starts, the process is launched with this UID unless an image-level USER directive is overridden by this field. The securityContext's runAsUser takes precedence over the image's default user, so the process runs as UID 1000.

Why this answer

The `runAsUser` field in the pod's securityContext explicitly sets the user ID (UID) for all processes in the container. In this manifest, `runAsUser: 1000` overrides the default UID (usually 0, root) and ensures that the container's main process runs with UID 1000. The `runAsGroup` and `fsGroup` fields affect group IDs and file ownership, not the process UID.

Exam trap

CNCF often tests the distinction between `runAsUser` (process UID), `runAsGroup` (process GID), and `fsGroup` (volume ownership GID), and the trap here is that candidates confuse `fsGroup` or `runAsGroup` with the process UID, leading them to select 2000 or 3000 instead of 1000.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` explicitly overrides the default root UID (0), so processes do not run as root. Option B is wrong because `runAsGroup: 3000` sets the primary group ID (GID) for the process, not the UID. Option C is wrong because `fsGroup: 2000` is used to set the group ownership of mounted volumes and any files created in them, but it does not affect the UID of the container's processes.

Full explanation →

142

MCQeasy

Which kubectl command creates a Secret from literal username and password values?

A.kubectl create secret generic my-secret --literal username=admin password=secret123

B.kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secret123

C.kubectl create secret generic my-secret --from-file=username --from-file=password

D.kubectl create secret generic my-secret --from-env-file=creds.txt

AnswerB

This creates a Secret from literal key=value pairs.

Why this answer

`kubectl create secret generic` with `--from-literal` is the proper syntax for specifying literal key-value pairs directly in the command. Each literal must be prefixed with `--from-literal=key=value`, and multiple literals can be provided to create a Secret containing both the username and password keys.

Exam trap

The trap here is that candidates confuse `--from-literal` with the non-existent `--literal` flag, or assume that multiple key-value pairs can be passed in a single `--from-literal` argument, leading them to choose Option A.

How to eliminate wrong answers

Option A is wrong because it uses `--literal` instead of the correct `--from-literal` flag, and the syntax `--literal username=admin password=secret123` is invalid — kubectl requires each literal to be specified with its own `--from-literal=key=value` flag. Option C is wrong because `--from-file` creates a Secret from file contents, not literal values; it would read the files named 'username' and 'password' from the filesystem, not use inline strings. Option D is wrong because `--from-env-file` imports key-value pairs from a file in the format `KEY=VALUE`, but it does not accept literal values directly on the command line.

Full explanation →

143

MCQmedium

A.Delete the namespace and redeploy all workloads

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

C.Increase the CPU request for the container

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

AnswerD

The OOMKilled status means the container's memory usage exceeded the limit specified in resources.limits.memory. Raising this limit in the pod's container resource specification gives the process more headroom under the cgroup, allowing it to run without being killed by the kernel. This directly resolves the cause of the crash loop, provided the node has sufficient allocatable memory.

Why this answer

The OOMKilled status indicates the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. Since the pod ran successfully for days, the issue is likely a memory leak or increased workload demand, not a configuration error. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory usage without being killed.

Exam trap

The trap here is that candidates confuse CPU and memory resource constraints, thinking increasing CPU requests will solve an OOM issue, or they assume a simple pod restart is sufficient without addressing the underlying resource limit.

How to eliminate wrong answers

Option A is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not address the root cause (memory exhaustion) and would cause unnecessary downtime. Option B is wrong because deleting and recreating the pod will only restart it with the same memory limit, leading to the same OOMKilled crash loop. Option C is wrong because increasing the CPU request does not affect memory allocation; the OOM killer is triggered by memory usage exceeding the limit, not CPU.

Full explanation →

144

MCQeasy

Which kubectl command streams logs from a pod named 'web-pod' in real-time?

A.kubectl logs --since=5m web-pod

B.kubectl logs --tail=100 web-pod

C.kubectl logs -f web-pod

D.kubectl logs web-pod

AnswerC

The -f flag streams logs in real-time.

Why this answer

The `-f` flag (short for `--follow`) tells kubectl to stream logs from the pod in real-time, similar to `tail -f` on a file. This is essential for live monitoring of application output as it is generated.

Exam trap

The trap here is that candidates may confuse flags like `--tail` or `--since` with real-time streaming, not realizing that only `-f` (or `--follow`) provides continuous log output.

How to eliminate wrong answers

Option A is wrong because `--since=5m` retrieves logs from the last 5 minutes but does not stream them; it prints the logs and exits. Option B is wrong because `--tail=100` shows only the last 100 lines of logs and then exits, without following new output. Option D is wrong because `kubectl logs web-pod` prints all available logs from the pod and exits, providing no real-time streaming capability.

Full explanation →

145

MCQeasy

Which of the following Service types exposes a pod on a static port on each node's IP address?

A.LoadBalancer

B.ExternalName

C.ClusterIP

D.NodePort

AnswerD

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

Why this answer

NodePort is the correct answer because it exposes a pod on a static port (in the range 30000-32767) on every node's IP address. When a Service of type NodePort is created, Kubernetes opens that port on all nodes in the cluster, forwarding traffic to the target pods. This allows external access to the pod via any node's IP and the assigned static port.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking LoadBalancer also exposes a static port on each node, but LoadBalancer actually relies on NodePort internally and adds an external LB, not a direct per-node static port exposure.

How to eliminate wrong answers

Option A is wrong because LoadBalancer exposes the service via an external load balancer (e.g., cloud provider's LB) and does not directly expose a static port on each node's IP; it typically builds on NodePort but adds a load balancer frontend. Option B is wrong because ExternalName maps a service to a DNS name (CNAME record) and does not expose any port or pod at all; it is used for external service references. Option C is wrong because ClusterIP exposes the service only on a cluster-internal IP, reachable only within the cluster, not on each node's IP address.

Full explanation →

146

MCQhard

Based on the exhibit, why is the container being killed and restarted?

A.The readiness probe is failing, causing the pod to be considered not ready and restarted.

B.The liveness probe is failing, causing the container to be restarted.

C.The container is running out of memory (OOM).

D.The container image is being pulled repeatedly.

AnswerB

The liveness probe is the probe that determines whether the application inside the container is healthy; if it fails, the kubelet kills the container and restarts it according to the pod's restartPolicy. The exhibit shows a restart counter increasing while the container's status cycles through Running, then terminated, then Running again, which exactly matches the behavior of a failing liveness probe. A liveness probe failure would cause the kubelet to record the reason as "Liveness probe failed: <message>" in the pod events, leading to the automatic restart observed in the exhibit.

Why this answer

In Kubernetes, a failing liveness probe causes the kubelet to restart the container. The exhibit shows the container being killed and restarted, which is consistent with liveness probe failure. Option A is incorrect because a failing readiness probe does not restart the container; it only marks the pod as not ready and removes it from service endpoints.

Option C is incorrect: OOM would result in a different error message (OOMKilled). Option D is incorrect: repeated image pulls would cause ImagePullBackOff, not a restart after running.

Exam trap

A common pitfall is forgetting that readiness probes do not restart containers; only liveness probes do. The restart policy (e.g., Always) acts on liveness failures.

How to eliminate wrong answers

Option B is wrong because a failing liveness probe directly causes the container to be restarted by the kubelet, but the exhibit indicates the container is being killed and restarted due to a readiness probe failure, not a liveness probe failure. Option C is wrong because an OOM kill would result in a `CrashLoopBackOff` state with an `OOMKilled` reason in the pod status, not a readiness probe failure. Option D is wrong because repeated image pulls would cause `ErrImagePull` or `ImagePullBackOff` errors, not a readiness probe failure leading to container restarts.

Full explanation →

147

MCQhard

You are a platform engineer at a company that runs a microservices architecture on Kubernetes. The application consists of a frontend service (Node.js), a backend API (Go), and a PostgreSQL database. All components are deployed in the same namespace 'production'. Recently, the backend API has been experiencing intermittent 503 errors from the frontend. The backend API Pods have CPU limits set to 500m and memory limits to 256Mi. The backend API exposes metrics at /metrics and has a liveness probe (HTTP GET /healthz) and a readiness probe (HTTP GET /ready). You notice that during traffic spikes, the backend API Pods are restarted frequently. You examine the metrics and see that memory usage spikes to 250Mi during high load. What is the most likely cause of the restarts and 503 errors?

A.The liveness probe is misconfigured and should use a TCP check instead.

B.The memory limit is set too low; the container is being OOMKilled during traffic spikes.

C.The readiness probe is failing because the application is not ready, but the liveness probe keeps it alive.

D.The CPU limit is too low, causing the container to be throttled and timeout.

AnswerB

The container's memory limit is 256Mi, yet during traffic spikes memory reaches roughly 250Mi plus cache overhead, which pushes usage over the cgroup limit. When that limit is breached, the kernel OOM killer terminates the container, and restartPolicy causes the observed restarts. The liveness probe is not involved because the kernel acts independently of any probe status.

Why this answer

The backend API Pods are being restarted frequently because the memory limit of 256Mi is too close to the observed memory usage of 250Mi during traffic spikes. When memory usage hits the limit, the Linux kernel's OOM killer terminates the container (OOMKilled), causing the Pod to restart. This restart leads to temporary unavailability, which the frontend sees as 503 errors.

Exam trap

The trap here is that candidates often confuse CPU throttling (which causes slowness and timeouts) with OOM kills (which cause restarts), and they may overlook that memory limits are a hard cap enforced by the kernel, while CPU limits are a soft cap enforced by the scheduler.

How to eliminate wrong answers

Option A is wrong because the liveness probe is already an HTTP GET check, which is appropriate for an application that exposes an HTTP endpoint; switching to a TCP check would not prevent OOM kills and would only verify the port is open, not application health. Option C is wrong because the readiness probe failing would prevent traffic from being sent to the Pod, but the Pod would not be restarted; restarts are caused by liveness probe failures or OOM kills, not readiness probe failures. Option D is wrong because CPU throttling (due to low CPU limits) causes performance degradation and timeouts, not container restarts; the kernel does not kill containers for exceeding CPU limits—it only throttles them.

Full explanation →

148

MCQhard

You need to allow ingress traffic to pods with label 'app: web' from pods with label 'role: frontend' in the same namespace, and also from any pod in namespace 'monitoring'. Which NetworkPolicy egress/ingress rule correctly implements this?

A.spec: podSelector: matchLabels: app: web ingress: - from: - namespaceSelector: matchLabels: name: monitoring - podSelector: matchLabels: role: frontend

B.spec: podSelector: matchLabels: app: web ingress: - from: - podSelector: matchLabels: role: frontend namespaceSelector: matchLabels: name: monitoring

C.spec: podSelector: matchLabels: app: web ingress: - from: - podSelector: matchLabels: role: frontend - namespaceSelector: matchLabels: name: monitoring

D.spec: podSelector: matchLabels: app: web ingress: - from: - podSelector: matchLabels: role: frontend - from: - namespaceSelector: matchLabels: name: monitoring

AnswerA, C

Uses separate 'from' items, so traffic from either a namespace matching 'name: monitoring' OR pods with label 'role: frontend' is allowed. However, the podSelector alone (without a namespaceSelector) matches pods in any namespace, so it allows frontend pods from all namespaces, not just the same namespace.

Why this answer

It defines two separate ingress rules: one allowing traffic from pods with label 'role: frontend' in the same namespace, and another allowing traffic from any pod in namespace 'monitoring'. In Kubernetes NetworkPolicy, when multiple items are listed under 'from' in an ingress rule, they are ORed; however, here each rule is independent, so the first rule matches pods with 'role: frontend' (no namespaceSelector, so same namespace), and the second rule matches all pods in the 'monitoring' namespace (no podSelector, so all pods). This satisfies the requirement.

Exam trap

The trap is misunderstanding how NetworkPolicy selectors combine. Within a single 'from' item, selectors are ANDed; multiple 'from' items are ORed. Option B incorrectly combines both selectors in one 'from' item (AND), requiring pods to match both conditions.

Option A and C correctly use separate 'from' items (OR), allowing frontend pods (same namespace, because a bare podSelector defaults to the namespace of the policy) or all pods from the monitoring namespace. Option D is also valid with two separate ingress rules.

How to eliminate wrong answers

Option A is wrong because it places both the podSelector and namespaceSelector in the same 'from' item, which means traffic must come from a pod that is both labeled 'role: frontend' AND in a namespace labeled 'name: monitoring' — an AND condition, not the required OR. Option B is wrong because it also combines podSelector and namespaceSelector in the same 'from' item, again requiring both conditions to be met simultaneously (AND logic), which would only allow pods with 'role: frontend' in the 'monitoring' namespace. Option D is wrong because it uses two separate 'from' blocks, but the second 'from' block has a namespaceSelector without a podSelector, which would allow traffic from any pod in 'monitoring' — however, the first 'from' block with only a podSelector would allow traffic from any pod with 'role: frontend' in any namespace (including other namespaces), which is too permissive; the requirement is to allow from pods with 'role: frontend' only in the same namespace.

Full explanation →

149

MCQhard

You have a Deployment with a liveness probe that fails intermittently, causing the pod to restart. You want to reduce the sensitivity of the probe so that it only restarts after 3 consecutive failures. Which probe parameter should you adjust?

A.initialDelaySeconds

B.periodSeconds

C.failureThreshold

D.successThreshold

AnswerC

failureThreshold is the correct parameter to adjust because it specifies the number of consecutive liveness probe failures the kubelet must observe before restarting the container. By increasing this value from its default (often 1 for liveness) to 3, you require multiple failed probes in a row, making the restart decision less sensitive to transient errors. This directly addresses the problem of a probe that fails intermittently without causing immediate container restarts.

Why this answer

The `failureThreshold` parameter defines the number of consecutive probe failures required before Kubernetes considers the probe to have failed and triggers the configured action (e.g., restarting the container). By default, this value is 3, but if it is set lower (e.g., 1), a single failure causes a restart. Increasing `failureThreshold` to 3 (or higher) ensures that the liveness probe only restarts the pod after three consecutive failures, thereby reducing sensitivity to transient issues.

Exam trap

The trap here is that candidates often confuse `failureThreshold` with `periodSeconds`, thinking that reducing the probe frequency (period) will reduce sensitivity, but the correct way to require multiple consecutive failures is to increase the `failureThreshold` value.

How to eliminate wrong answers

Option A is wrong because `initialDelaySeconds` controls how long to wait after the container starts before initiating the first probe; it does not affect the number of consecutive failures required to trigger a restart. Option B is wrong because `periodSeconds` sets the frequency (in seconds) at which the probe is executed; adjusting it changes how often checks occur, not how many failures are needed. Option D is wrong because `successThreshold` defines the number of consecutive successes required for the probe to be considered successful after a failure; it is relevant for startup and readiness probes but not for liveness probes (where it is always 1 and cannot be changed).

Full explanation →

150

MCQhard

You need to create a Secret of type 'kubernetes.io/tls' for ingress. Which command is correct?

A.kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem

B.kubectl create secret tls my-tls --certificate=cert.pem --private-key=key.pem

C.kubectl create secret tls my-tls --from-file=tls.crt=cert.pem --from-file=tls.key=key.pem

D.kubectl create secret tls my-tls --cert=cert.pem --key=key.pem

AnswerD

This command creates a tls secret with the provided certificate and key files.

Why this answer

`kubectl create secret tls` is the dedicated command for creating a TLS secret, and it uses the `--cert` and `--key` flags to specify the certificate and private key files respectively. This creates a Secret of type `kubernetes.io/tls`, which is required for Ingress resources to terminate HTTPS traffic.

Exam trap

The trap here is that candidates confuse the `--from-file` syntax from `kubectl create secret generic` with the dedicated TLS command, or misremember the flag names as `--certificate`/`--private-key` instead of the correct `--cert`/`--key`.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret generic` creates a generic (Opaque) Secret, not a `kubernetes.io/tls` type, and Ingress requires the TLS-specific type to correctly interpret the certificate and key data. Option B is wrong because the flags `--certificate` and `--private-key` are not valid for `kubectl create secret tls`; the correct flags are `--cert` and `--key`. Option C is wrong because `--from-file` is used with `kubectl create secret generic`, not with `kubectl create secret tls`, and the `tls.crt`/`tls.key` key names are automatically set by the `tls` subcommand when using the correct flags.

Full explanation →

Certified Kubernetes Application Developer CKAD (CKAD) — Questions 76–150