Certified Kubernetes Application Developer CKAD CKAD Questions 151–225 | Page 3/12

151

MCQmedium

A developer wants to debug a running container in a Pod named 'web-app' in namespace 'dev'. Which command attaches an ephemeral container with the 'nicolaka/netshoot' image for network debugging?

A.kubectl debug web-app -n dev --image=nicolaka/netshoot -c debugger

B.kubectl run debugger -n dev --image=nicolaka/netshoot --restart=Never

C.kubectl attach web-app -n dev -c debugger --image=nicolaka/netshoot

D.kubectl exec -n dev web-app --image=nicolaka/netshoot -- /bin/bash

AnswerA

kubectl debug injects an ephemeral container named debugger directly into the existing web-app pod using the nicolaka/netshoot image. Ephemeral containers share the pod’s network, IPC, and PID namespaces with the application container, allowing you to inspect its interfaces, sockets, and processes without modifying or restarting the original workload. This is the intended mechanism for bringing a debugging image into a running pod for interactive troubleshooting.

Why this answer

`kubectl debug` is the dedicated command for adding an ephemeral container to a running Pod for troubleshooting. The `--image=nicolaka/netshoot` flag specifies the network debugging image, and `-c debugger` names the ephemeral container. This allows the developer to attach to the Pod's network namespace without restarting or modifying the original container.

Exam trap

Kubernetes often tests the distinction between `kubectl debug` (for ephemeral containers) and `kubectl exec` (for existing containers), trapping candidates who think `exec` can add a new container with a different image.

How to eliminate wrong answers

Option B is wrong because `kubectl run` creates a standalone Pod, not an ephemeral container attached to an existing Pod; it does not share the network namespace of 'web-app'. Option C is wrong because `kubectl attach` attaches to a running container's stdio, not to a new container, and it does not support the `--image` flag. Option D is wrong because `kubectl exec` runs a command in an existing container, not a new container with a different image; the `--image` flag is invalid for `kubectl exec`.

Full explanation →

152

MCQmedium

You need to expose a Deployment named 'web' on port 80 internally within the cluster. Which command creates the appropriate Service?

A.kubectl create service clusterip web --tcp=80:80

B.kubectl expose deployment web --port=80

C.kubectl apply -f service.yaml

D.kubectl run web --image=nginx --port=80

AnswerB

kubectl expose deployment web --port=80 is the imperative command that creates a ClusterIP Service directly from the Deployment object. kubectl extracts the labels defined in the Deployment's pod template and sets them as the Service's selector, guaranteeing the Service routes traffic to exactly those Pods. It also maps port 80 to the Pods' targetPort, which defaults to 80 if not specified. This is the intended one-line solution.

Why this answer

The `kubectl expose deployment web --port=80` command creates a Service of type ClusterIP by default, which exposes the Deployment's pods on port 80 internally within the cluster. This matches the requirement to expose the 'web' Deployment on port 80 internally without specifying a target port, as it defaults to the container's port defined in the Deployment.

Exam trap

The trap here is that candidates often confuse `kubectl create service clusterip` with `kubectl expose`; the former creates a Service without linking it to a workload, while the latter creates a Service that automatically selects the pods of the specified resource, which is required to expose the Deployment's pods internally.

How to eliminate wrong answers

Option A is wrong because `kubectl create service clusterip web --tcp=80:80` creates a Service named 'web' but does not link it to the existing Deployment; it creates a standalone Service without a selector matching the Deployment's pods, so it won't route traffic to the Deployment's pods. Option C is wrong because `kubectl apply -f service.yaml` is a valid way to create a Service from a YAML file, but it is not a command that directly exposes the Deployment; it requires a pre-existing YAML definition, and the question asks for a command that creates the appropriate Service, implying a direct imperative command. Option D is wrong because `kubectl run web --image=nginx --port=80` creates a new Pod (or Deployment in older versions) named 'web', not a Service; it does not expose the existing Deployment named 'web'.

Full explanation →

153

MCQeasy

What is the purpose of the 'kubectl rollout status' command?

A.To roll back a deployment

B.To check the current status of a rollout

C.To view the rollout history

D.To pause a rollout

AnswerB

kubectl rollout status is the correct command to monitor a live rollout's progress. It polls the Deployment's status conditions and prints whether the update is still ongoing, has succeeded, or failed during the process deadline. It's a read-only operation and returns a successful exit code once the rollout has completed.

Why this answer

The command 'kubectl rollout status' tracks the progress of a rollout until it completes or fails.

Full explanation →

154

Multi-Selecthard

Which of the following are valid kubectl commands for managing rollouts? (Select all that apply)

Select 4 answers

A.kubectl rollout status deployment/myapp

B.kubectl rollout diff deployment/myapp

C.kubectl rollout history deployment/myapp

D.kubectl rollout restart deployment/myapp

E.kubectl rollout pause deployment/myapp

AnswersA, C, D, E

`kubectl rollout status deployment/myapp` is a valid subcommand that monitors the progress of a rollout in real time, waiting until the Deployment's pods are fully updated and available. It returns a non-zero exit code if the rollout fails, making it valuable in CI/CD to block execution until the deployment is healthy. It is one of the primary rollout inspection commands.

Why this answer

Option A, `kubectl rollout status deployment/myapp`, is correct because it is a valid subcommand that watches the progress of a Deployment rollout until it completes or fails, reporting the current status. Option C, `kubectl rollout history deployment/myapp`, is correct because it lists the revision history of the Deployment, showing each revision number and change-cause annotation. Option D, `kubectl rollout restart deployment/myapp`, is correct because it performs a rolling restart of the Deployment by adding a restartedAt annotation to the pod template, triggering a new rollout.

Option E, `kubectl rollout pause deployment/myapp`, is correct because it pauses an in-progress rollout, allowing multiple changes to be applied before resuming with `kubectl rollout resume`. Option B, `kubectl rollout diff deployment/myapp`, is not a valid kubectl subcommand; `kubectl rollout` supports status, history, undo, restart, pause, and resume, but not diff.

Exam trap

The CKAD exam often tests the distinction between valid rollout subcommands and other kubectl commands, so candidates may mistakenly think rollout diff exists because kubectl diff is a real command. Note that all four of A, C, D, and E are valid subcommands.

Full explanation →

155

MCQhard

You are a platform engineer managing a production Kubernetes cluster. A team deploys a stateful application called 'inventory-service' with 3 replicas using a StatefulSet. Each pod writes logs to a persistent volume via a PersistentVolumeClaim. Recently, the team reports that the application becomes unresponsive after running for a few hours. You notice that the pods are still running (READY 1/1) but the application does not respond to HTTP requests. You exec into one pod and find that the disk is 100% full. The PVC is backed by a cloud disk (e.g., AWS EBS). You check the pod's resource limits and see that memory and CPU are not exhausted. The container logs are not rotated. Which course of action should you take to resolve the immediate issue and prevent recurrence?

A.Increase the size of the PVC to provide more disk space, and configure log rotation inside the container to limit log file size

B.Add a sidecar container that compresses and archives logs to a remote storage every hour

C.Change the application to log to stdout and configure Docker log rotation on the host

D.Configure a log rotation sidecar that writes logs to an emptyDir volume with size limit

AnswerA

Resizing the PersistentVolumeClaim provides immediate temporary relief by giving the container more disk headroom, which is often the fastest way to mitigate an acute disk-full incident. However, without log rotation inside the container, the new space will eventually be consumed again, so configuring rotation (e.g., logrotate to cap total log size) prevents recurrence by keeping per-file and aggregate growth bounded. This combination addresses the immediate symptom and the root cause, making it the right answer.

Why this answer

The immediate issue is a full disk caused by unrotated logs. Increasing the PVC size provides temporary relief, while configuring log rotation inside the container (e.g., using logrotate or the application's own rotation) prevents the disk from filling up again. This directly addresses the root cause without changing the application's logging behavior or introducing unnecessary sidecars.

Exam trap

CNCF often tests the distinction between logs written to stdout (handled by container runtime) versus logs written to a file inside the container (which require explicit rotation or external management).

How to eliminate wrong answers

Option B is wrong because compressing and archiving logs to remote storage does not free disk space on the local PVC; the logs remain on disk until deleted, so the disk will still fill up. Option C is wrong because changing the application to log to stdout and configuring Docker log rotation on the host does not affect logs written to a persistent volume; the application is writing logs to a file inside the container, not to stdout. Option D is wrong because using an emptyDir volume with a size limit would only cap the sidecar's own log storage, not the application's logs written to the PVC; the application's logs would still fill the PVC.

Full explanation →

156

MCQeasy

A pod named 'web-app' is running but has no environment variables. The developer wants to inject a variable 'DB_URL=postgres://db:5432' from a ConfigMap named 'db-config'. Which pod spec snippet correctly achieves this?

A.env: - name: DB_URL value: "postgres://db:5432"

B.envFrom: - configMapRef: name: db-config key: DB_URL

C.env: - name: DB_URL valueFrom: secretKeyRef: name: db-config key: DB_URL

D.env: - name: DB_URL valueFrom: configMapKeyRef: name: db-config key: DB_URL

AnswerD

This is the correct and idiomatic way to inject a single value from a ConfigMap into an environment variable. The configMapKeyRef field explicitly names the ConfigMap (db-config) and the specific key (DB_URL), and Kubernetes resolves this reference when the pod is created. Unlike envFrom, it gives precise control over which entry gets injected, and unlike a literal value, it keeps the configuration externalized so the same manifest can be reused with different ConfigMaps.

Why this answer

It uses the `configMapKeyRef` field under `valueFrom` to inject a specific key from a ConfigMap as an environment variable. This allows the pod to consume the `DB_URL` value from the `db-config` ConfigMap without exposing it as a file or using `envFrom`.

Exam trap

CNCF often tests the distinction between `envFrom` (which imports all keys) and `valueFrom.configMapKeyRef` (which imports a single key), and candidates confuse the syntax by placing `key` directly under `configMapRef` instead of using the correct nested structure.

How to eliminate wrong answers

Option A is wrong because it hardcodes the value directly in the pod spec, ignoring the requirement to inject from a ConfigMap. Option B is wrong because `envFrom` with `configMapRef` imports all keys from the ConfigMap as environment variables, but the syntax is incorrect: `key` is not a valid field under `configMapRef` (it belongs under `configMapKeyRef` inside `valueFrom`). Option C is wrong because `secretKeyRef` is used to reference a Secret, not a ConfigMap, and the resource is named `db-config`, which implies a ConfigMap.

Full explanation →

157

Multi-Selecthard

Which THREE statements correctly describe Kustomize? (Select THREE.)

Select 3 answers

A.Kustomize uses a kustomization.yaml file to define customization rules.

B.Kustomize can only be used with Helm charts.

C.Kustomize requires a separate server component to run.

D.Kustomize supports strategic merge patches and JSON patches.

E.kubectl apply -k <directory> is used to apply Kustomize overlays.

AnswersA, D, E

A kustomization.yaml file is Kustomize's declarative entry point, listing resources, patches, and generators that Kustomize applies to produce the final manifests. This directly satisfies the stem's requirement for a statement describing Kustomize's core mechanism, since every overlay and base depends on this file to define its customisation rules.

Why this answer

Option A is correct because Kustomize is driven by a kustomization.yaml file that declares the resources, bases, overlays, patches, and other customization rules for a given directory. Option D is correct because Kustomize natively supports both strategic merge patches (which merge by Kubernetes object schema and merge keys) and JSON patches (RFC 6902-style operations) to modify resources. Option E is correct because kubectl has built-in Kustomize support, so kubectl apply -k <directory> builds and applies the kustomization found in that directory.

Option B is incorrect because Kustomize works with plain Kubernetes YAML manifests and is not limited to Helm charts; it can even be combined with Helm output via helm template. Option C is incorrect because Kustomize is a client-side, standalone binary (and is embedded in kubectl) with no separate server component required.

Exam trap

CKAD often tests the misconception that Kustomize requires a server component (like a controller or admission webhook) to function, but in reality it is purely client-side and runs as part of `kubectl apply -k` or the standalone `kustomize build` command.

Full explanation →

158

Multi-Selecthard

Which THREE of the following are valid use cases for a Headless Service (clusterIP: None)?

Select 3 answers

A.Discovering all Pod IPs via DNS A/AAAA records

B.Exposing the service externally via cloud load balancer

C.StatefulSet pod DNS (e.g., pod-0.svc.namespace.svc.cluster.local)

D.Implementing a custom load balancing algorithm

E.Providing a stable virtual IP for load balancing

AnswersA, C, D

A headless Service (spec.clusterIP: None) yields DNS A/AAAA records populated with the IP addresses of each ready backing Pod instead of a single virtual IP. This enables clients to resolve every instance's address directly, which is essential for peer discovery and client-side service discovery patterns. Because the records reflect current ready endpoints, they also react to Pod churn and scale events.

Why this answer

A Headless Service (clusterIP: None) does not provide a virtual IP or load balancing. Instead, DNS queries return A/AAAA records containing the IP addresses of all healthy Pods selected by the service. This allows clients to discover and connect directly to individual Pod IPs, which is essential for stateful applications or custom discovery patterns.

Exam trap

The trap here is that candidates often confuse the purpose of a Headless Service with a regular ClusterIP Service, mistakenly thinking it can provide external exposure or a stable virtual IP, when in fact it is designed for direct Pod-to-Pod discovery without load balancing.

Full explanation →

159

MCQhard

A pod is running but the application inside is not serving traffic. The team runs 'kubectl exec -it <pod> -- curl localhost:8080' and gets 'Connection refused'. What is the most likely cause?

A.Container logs are full and writing to disk is slow

B.NetworkPolicy is blocking traffic

C.Application is not listening on port 8080

D.Liveness probe is failing and restarting the container

AnswerC

Connection refused means the client sent a SYN to port 8080 on the loopback address, and the kernel responded with RST because nothing is bound to that listen socket. The application either never started, crashed before binding, or is configured to listen on a different port or interface such as 127.0.0.1:9090 instead of 0.0.0.0:8080. Troubleshooting should include checking the process in the container (ss -tlnp), reading application logs, and confirming the command/config passed to the container.

Why this answer

The 'Connection refused' error from curl indicates that the TCP connection to port 8080 was actively rejected by the kernel, meaning no process is listening on that port inside the container. This is most commonly caused by the application not starting, crashing before binding, or being configured to listen on a different port (e.g., 3000, 8443). The error is immediate and does not suggest a timeout or network-level block.

Exam trap

CNCF often tests the distinction between 'Connection refused' (no listener) and 'Connection timed out' (network block) — candidates mistakenly attribute the error to NetworkPolicy or resource issues, but the immediate RST is a definitive sign of a missing socket, not a network filter.

How to eliminate wrong answers

Option A is wrong because full container logs or slow disk writes would cause performance degradation or write errors, not a TCP 'Connection refused' — the kernel would still accept the connection if a socket is listening. Option B is wrong because NetworkPolicy operates at the network layer (iptables/eBPF) to allow or deny traffic between pods, but 'kubectl exec' runs inside the pod's network namespace, bypassing NetworkPolicy entirely; a NetworkPolicy cannot block localhost traffic. Option D is wrong because a failing liveness probe would cause the container to be restarted, but during the restart window the application might briefly be unavailable; however, 'Connection refused' is a persistent socket-level rejection, not a transient restart behavior, and a failing probe would also show events or crash loop status, not just a curl error.

Full explanation →

160

MCQhard

A multi-stage build has two stages named 'builder' and 'final'. Which instruction copies artifacts from the builder stage to the final stage?

A.COPY --from=builder /app /app

B.FROM builder /app /app

C.COPY builder /app /app

D.ADD --from=builder /app /app

AnswerA

This is the correct syntax for copying artifacts from a previous stage in a multi-stage Docker build. The `--from=builder` flag specifies the named stage called `builder`, and both `/app` arguments are container filesystem paths: the source path inside the builder stage's filesystem and the destination path in the current build stage. Because the `COPY` instruction requires this exact format to reference another stage, this command successfully copies the application from the builder stage into the final image.

Why this answer

In a multi-stage Docker build, the COPY instruction with the --from flag allows you to copy files from a named previous stage (here 'builder') into the current stage ('final'). This is the correct syntax to selectively transfer build artifacts without carrying over intermediate layers or dependencies.

Exam trap

The trap here is that candidates confuse the COPY --from syntax with the ADD instruction or forget the --from flag entirely, assuming COPY alone can reference a stage name, which leads to a build error or unintended host path copy.

How to eliminate wrong answers

Option B is wrong because 'FROM builder /app /app' is not a valid Dockerfile instruction; FROM is used to specify a base image, not to copy files. Option C is wrong because 'COPY builder /app /app' omits the required --from flag, so Docker would interpret 'builder' as a source path on the host filesystem, not as a stage name. Option D is wrong because ADD does not support the --from flag; ADD is used for adding files from URLs or archives, and multi-stage artifact copying is exclusive to COPY --from.

Full explanation →

161

MCQmedium

You run 'kubectl get pods -o wide' and see that a pod's NODE column shows 'node-1'. You want to see more details about that node's resource usage. Which command should you use?

A.kubectl top pods --all-namespaces

B.kubectl describe node node-1

C.kubectl top pod node-1

D.kubectl top node node-1

AnswerD

kubectl top node node-1 is correct because it directly queries the metrics-server for that specific node and displays real-time CPU and memory utilization at the node level. This command provides a snapshot of current usage, typically expressed as a percentage and absolute values, fulfilling the requirement to see what resources the node is actually using.

Why this answer

`kubectl top node node-1` directly displays real-time resource usage (CPU and memory) for the specified node, which is exactly what you need when you want to see more details about a node's resource consumption after identifying the node from `kubectl get pods -o wide`.

Exam trap

The trap here is that candidates confuse `kubectl top node` with `kubectl top pod` or `kubectl describe node`, mistakenly thinking that `describe` provides real-time resource usage or that `top pod` can target a node by name.

How to eliminate wrong answers

Option A is wrong because `kubectl top pods --all-namespaces` shows resource usage for pods across all namespaces, not for a specific node. Option B is wrong because `kubectl describe node node-1` shows detailed metadata, conditions, and capacity of the node, but not real-time resource usage metrics like CPU and memory consumption. Option C is wrong because `kubectl top pod node-1` attempts to get resource usage for a pod named 'node-1', not for a node; the command syntax is invalid for node-level metrics.

Full explanation →

162

MCQmedium

A developer creates a Role and RoleBinding in the namespace 'development' to grant list pods permission to a service account. Which manifest snippet correctly defines the Role?

A.rules: - apiGroups: ["pods"] resources: ["pods"] verbs: ["get", "list"]

B.rules: - apiGroups: ["apps"] resources: ["pods"] verbs: ["list"]

C.rules: - apiGroups: [""] resources: ["pods"] verbs: ["list"]

D.rules: - apiGroups: ["*"] resources: ["pods"] verbs: ["list"]

AnswerC

This rule is correct because the apiGroups field uses an empty string "", which is the proper way to reference the Kubernetes core API group where pods live. The resource "pods" and verb "list" are valid, and because this is a Role (not a ClusterRole), it grants the ability to list pods only within the namespace where the Role is bound. This minimal, precise scope aligns with RBAC best practices.

Why this answer

Pods belong to the core API group, which is represented by an empty string `""` in the `apiGroups` field. The `list` verb is sufficient to list pods, and the `resources` field correctly specifies `pods`. This Role grants the service account permission to list pods in the `development` namespace.

Exam trap

The trap here is that candidates often confuse the core API group with a named group like `"apps"` or use a wildcard `"*"` instead of the correct empty string `""`, leading to rules that either don't apply or are overly permissive.

How to eliminate wrong answers

Option A is wrong because `apiGroups: ["pods"]` is invalid; `pods` is a resource, not an API group, and the correct API group for pods is the core group (`""`). Option B is wrong because `apiGroups: ["apps"]` is incorrect; pods are not part of the `apps` API group (which includes Deployments, StatefulSets, etc.), so the rule would not apply to pods. Option D is wrong because `apiGroups: ["*"]` is a wildcard that matches all API groups, which is overly broad and not the precise way to specify the core group; the correct value for the core group is an empty string.

Full explanation →

163

MCQmedium

A pod is stuck in 'Pending' state. You run 'kubectl describe pod mypod' and see the event: '0/4 nodes are available: 4 Insufficient memory'. Which action will resolve the issue?

A.Scale down other pods in the cluster to free memory

B.Add a nodeSelector to target a specific node

C.Increase the memory request in the pod spec

D.Scale up the Deployment to create more pod replicas

AnswerA

When a pod is Pending, one common cause is that no node has enough allocatable memory because the sum of memory requests from pods already assigned to each node is at or near the node's capacity. Scaling down other pods (for example, reducing Deployment replicas) lowers the total requested memory on those nodes, freeing enough headroom for the scheduler to place the pending pod. This directly addresses the scheduling failure, though it may require coordination with other workloads.

Why this answer

The pod is stuck in 'Pending' because no node has enough allocatable memory to satisfy its memory request. Scaling down other pods frees memory on existing nodes, allowing the scheduler to place the pod. This directly resolves the 'Insufficient memory' condition without changing the pod's specification or cluster topology.

Exam trap

The trap here is that candidates often think increasing resource requests or adding selectors will help, but those actions either increase demand or restrict placement, making the problem worse instead of solving the underlying resource shortage.

How to eliminate wrong answers

Option B is wrong because adding a nodeSelector restricts scheduling to nodes matching specific labels, but no node currently has sufficient memory, so the pod will remain unschedulable. Option C is wrong because increasing the memory request would make the pod require even more memory, worsening the shortage and keeping it pending. Option D is wrong because scaling up the Deployment creates more pod replicas, each with the same memory request, increasing total demand and making the memory shortage worse.

Full explanation →

164

MCQmedium

A Pod is running in a namespace with a default LimitRange that sets a default CPU request of 100m and a default CPU limit of 200m. The Pod's container spec does not specify any CPU requests or limits. What will be the effective CPU request and limit for the container?

A.CPU request: 200m, CPU limit: 200m

B.CPU request: 0, CPU limit: 0

C.CPU request: 100m, CPU limit: 200m

D.CPU request: 100m, CPU limit: 100m

AnswerC

The LimitRange's default values are applied to containers that do not specify their own CPU requests and limits. Since the container omits both, the default request of 100m and default limit of 200m are automatically set. This ensures that resources are allocated according to namespace policies. The Pod will be scheduled based on the 100m request and constrained by the 200m limit.

Why this answer

A LimitRange with default CPU request and limit values automatically applies those to containers that do not specify their own. The defaultRequest becomes the request, and the default becomes the limit. Thus, the container gets a CPU request of 100m and a limit of 200m, as defined in the LimitRange.

Exam trap

The trap here is assuming that without explicit requests and limits, the container gets none, or that the request and limit are always equal when defaults are applied.

Full explanation →

165

Drag & Dropmedium

Arrange the steps to create a Kubernetes Deployment with a rolling update strategy.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First, define the Deployment in YAML. Then apply it. After an update, modify the YAML and re-apply; kubectl performs rolling update automatically.

Full explanation →

166

Multi-Selecthard

Which THREE of the following are valid fields for configuring a probe in Kubernetes? (Select 3)

Select 3 answers

A.initialDelaySeconds

B.retrySeconds

C.intervalSeconds

D.periodSeconds

E.timeoutSeconds

AnswersA, D, E

The field specifies the waiting period after the container starts before the kubelet begins running the probe. It is crucial for applications that need time to initialize, such as loading configuration or establishing connections. Without it, probes might fail prematurely, causing unnecessary restarts. The field is part of the probe specification along with periodSeconds, timeoutSeconds, successThreshold, and failureThreshold.

Why this answer

`initialDelaySeconds` is a valid field in a Kubernetes probe configuration (e.g., livenessProbe, readinessProbe, startupProbe). It defines the number of seconds after the container has started before the probe is initiated, allowing the application time to initialize before health checks begin.

Exam trap

The trap here is that candidates confuse `intervalSeconds` with `periodSeconds` and `retrySeconds` with `failureThreshold`, as the incorrect options sound plausible but do not exist in the Kubernetes API specification.

Full explanation →

167

MCQmedium

A pod with a startup probe configured is taking longer than usual to start. The startup probe has 'failureThreshold: 10' and 'periodSeconds: 5'. What is the maximum time the pod has to start before it is restarted?

A.50 seconds

B.10 seconds

C.30 seconds

D.60 seconds

AnswerA

The correct calculation multiplies failureThreshold (10) by periodSeconds (5), yielding 50 seconds. With no initialDelaySeconds specified, the kubelet begins probing immediately and gives exactly this window for the container to become ready. If the probe fails 10 consecutive times at 5-second intervals, the kubelet restarts the container, making 50 seconds the definitive startup deadline.

Why this answer

The maximum time a pod has to start before being restarted is calculated by multiplying the startup probe's `failureThreshold` (10) by its `periodSeconds` (5), which equals 50 seconds. This is because the startup probe runs every 5 seconds, and after 10 consecutive failures (i.e., the probe never succeeds within that window), the kubelet restarts the container. The startup probe is specifically designed to give slow-starting applications a grace period before the liveness probe takes over.

Exam trap

The trap here is that candidates often forget to multiply `failureThreshold` by `periodSeconds` and instead pick a single value (like 10 or 5) or add them, missing the core formula for probe timeout calculation.

How to eliminate wrong answers

Option B (10 seconds) is wrong because it incorrectly assumes the `failureThreshold` alone (10) is the time limit, ignoring the `periodSeconds` multiplier. Option C (30 seconds) is wrong because it might result from multiplying `failureThreshold` (10) by a mistaken `periodSeconds` of 3, or from adding the two values (10+5=15) and doubling, but it does not match the correct product of 10*5=50. Option D (60 seconds) is wrong because it likely comes from misreading `periodSeconds` as 6 or adding an extra 10 seconds; the correct calculation is strictly `failureThreshold * periodSeconds`.

Full explanation →

168

MCQmedium

A pod's securityContext has 'allowPrivilegeEscalation: false' and 'capabilities: { drop: ["ALL"] }'. Which statement is true?

A.The container can still gain capabilities via setuid binaries.

B.The container runs with no extra capabilities and cannot gain privileges.

C.The container runs as root with full privileges.

D.The container runs with all Linux capabilities.

AnswerB

This is correct when the security context also drops all Linux capabilities (e.g., `capabilities: drop: [ALL]`) alongside `allowPrivilegeEscalation: false`. The container's process starts with an empty effective and permitted capability set, and the `no_new_privs` flag stops it from acquiring any new capabilities through setuid, `execve`, or other escalation paths. The result is a container that has no extra capabilities and no mechanism to gain privileges at runtime.

Why this answer

Setting 'allowPrivilegeEscalation: false' prevents processes from gaining more privileges than their parent (e.g., via setuid binaries or kernel exploits), and dropping all capabilities with 'capabilities: { drop: ["ALL"] }' removes every Linux capability from the container's bounding set. Together, these ensure the container runs with no extra capabilities and cannot escalate privileges, even if running as root.

Exam trap

The trap here is that candidates assume dropping all capabilities still allows privilege escalation via setuid binaries, but 'allowPrivilegeEscalation: false' specifically blocks that path, making the combination a hard security boundary.

How to eliminate wrong answers

Option A is wrong because 'allowPrivilegeEscalation: false' explicitly blocks setuid binaries from granting elevated privileges, so the container cannot gain capabilities via that mechanism. Option C is wrong because dropping all capabilities means the container does not run with full privileges, even if the user is root; root without capabilities is restricted. Option D is wrong because 'drop: ["ALL"]' removes all Linux capabilities, so the container does not run with any capabilities, let alone all of them.

Full explanation →

169

Multi-Selectmedium

A developer needs to expose database credentials to a Pod as environment variables. The credentials are stored in a Kubernetes Secret named 'db-secret' with keys 'username' and 'password'. Which two methods correctly inject these values? (Choose two.)

Select 2 answers

A.Set 'env.name' to 'db-secret' and 'env.value' from 'secretKeyRef'.

B.Use 'valueFrom' with 'configMapKeyRef'.

C.Define an env entry with 'valueFrom' and 'secretKeyRef' for each key.

D.Mount the Secret as a volume and source environment variables from the mounted files.

E.Use 'envFrom' with 'secretRef' to expose all keys as environment variables.

AnswersC, E

The only way to inject a specific Secret key as an environment variable is to define an env entry with a name for the variable and a valueFrom block that contains secretKeyRef. Inside secretKeyRef, you provide the Secret object's name and the exact key you want; the referenced key's value is then resolved by the kubelet when the container starts. Using per-key entries gives you explicit control and avoids accidentally exposing unrelated Secret data.

Why this answer

`valueFrom` with `secretKeyRef` allows you to reference a specific key from a Kubernetes Secret and inject its value as an environment variable. This is the standard method for exposing individual secret keys to a Pod. Option E is correct because `envFrom` with `secretRef` injects all keys from the referenced Secret as environment variables into the container, which is efficient when you need to expose multiple keys without defining each one individually.

Exam trap

CNCF often tests the distinction between `valueFrom` with `secretKeyRef` for individual keys versus `envFrom` with `secretRef` for bulk injection, and the trap here is that candidates confuse `configMapKeyRef` with `secretKeyRef` or think that mounting a Secret as a volume automatically creates environment variables from the file contents.

Full explanation →

170

Multi-Selecteasy

Which TWO commands can be used to create a Secret from a file? (Select 2)

Select 2 answers

A.kubectl create secret generic mysecret --from-file=key=file.txt

B.kubectl create configmap mysecret --from-file=file.txt

C.kubectl apply -f secret.yaml where secret.yaml contains data fields

D.kubectl create secret tls mysecret --cert=file.txt

E.kubectl create secret generic mysecret --from-env-file=file.txt

AnswersA, E

The generic subcommand with --from-file=key=file.txt explicitly assigns the file's contents to a chosen key inside the Secret's data map. This is the canonical way to create a Secret that holds a single arbitrary file, and kubectl automatically base64-encodes the value when the Secret is created, though the command line uses the raw file content. It is the recommended approach when you need to mount the file as a volume in a Pod.

Why this answer

Both options A and E are valid commands to create a Secret from a file. Option A uses `--from-file` to read file contents and store them under a specified key. Option E uses `--from-env-file` to parse a file with key=value pairs and create a Secret for environment variables.

Option C is incorrect for this question because `kubectl apply -f secret.yaml` applies a YAML manifest that defines a Secret, but it does not create a Secret directly from a file's contents in the same way as the `kubectl create secret` commands. The question asks for two commands that create a Secret from a file, and both A and E meet that criterion.

Exam trap

The trap here is that candidates often confuse `--from-file` with `--from-env-file` or think `kubectl create configmap` can create Secrets, but the CKAD exam tests precise command syntax and the distinction between Secret types (generic vs. TLS) and resource types (ConfigMap vs. Secret).

Full explanation →

171

MCQmedium

Which command attaches an ephemeral container to a running pod for debugging?

A.kubectl attach mypod

B.kubectl exec -it mypod -- sh

C.kubectl logs mypod -c mycontainer

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

AnswerD

kubectl debug -it mypod --image=busybox --target=mycontainer creates a new ephemeral container in the pod, attaches it interactively, and joins it to the process namespace of the target container mycontainer. The --target flag makes the ephemeral container see the same processes as mycontainer, enabling low-level debugging with tools like strace or tcpdump. The -it flags allocate a TTY and keep stdin open, while --image=busybox provides the debugging environment, all without restarting the pod.

Why this answer

`kubectl debug` with `-it` and `--image=busybox` creates an ephemeral container in the target pod for interactive debugging, while `--target=mycontainer` attaches the ephemeral container to the same network and process namespace as the specified container. This is the only command that adds a new, temporary container to a running pod without restarting it, which is essential when the existing container lacks debugging tools or is in a crash loop.

Exam trap

The trap here is that candidates confuse `kubectl exec` (which runs in an existing container) with `kubectl debug` (which creates a new ephemeral container), especially when the pod's container is unhealthy or lacks a shell, making `kubectl exec` impossible.

How to eliminate wrong answers

Option A is wrong because `kubectl attach mypod` attaches to the primary container's main process (usually PID 1) in the pod, not an ephemeral container; it does not create a new container and requires the container to have an interactive shell running. Option B is wrong because `kubectl exec -it mypod -- sh` runs a command in an existing container, not an ephemeral container; it fails if the container has no shell or is in a broken state. Option C is wrong because `kubectl logs mypod -c mycontainer` only retrieves log output from a specified container; it does not attach or create any container for debugging.

Full explanation →

172

MCQmedium

An administrator wants to enforce that all Pods in a namespace run with a read-only root filesystem. Which admission controller should be configured?

A.LimitRange

B.ResourceQuota

C.MutatingAdmissionWebhook

D.Pod Security Admission (PSA)

AnswerD

Pod Security Admission (PSA) is a built-in admission controller that enforces the Pod Security Standards, which define privileged, baseline, and restricted security profiles. The restricted profile explicitly requires readOnlyRootFilesystem: true, along with preventing privileged containers, host namespaces, and other high-risk capabilities. By labeling a namespace with the enforce level and restricted version, an administrator guarantees that every pod meets these mandatory security context requirements.

Why this answer

Pod Security Admission (PSA) is the correct choice because it enforces Pod Security Standards (PSS) at the namespace level, including the `Restricted` profile which mandates a read-only root filesystem (`readOnlyRootFilesystem: true`). PSA is a built-in admission controller that evaluates pod specifications against predefined security policies and rejects pods that violate them, making it the appropriate tool for this requirement.

Exam trap

The trap here is that candidates confuse admission controllers that manage resource quotas (LimitRange, ResourceQuota) with those that enforce security policies, or mistakenly think a webhook is required when a built-in controller like PSA already provides the needed enforcement.

How to eliminate wrong answers

Option A is wrong because LimitRange is used to set default resource requests/limits and enforce min/max constraints on CPU and memory per pod or container, not to enforce filesystem security policies like read-only root filesystem. Option B is wrong because ResourceQuota limits aggregate resource consumption (e.g., total CPU, memory, or count of objects) in a namespace, but does not inspect or enforce pod-level security attributes such as filesystem access. Option C is wrong because MutatingAdmissionWebhook can modify pod specs (e.g., inject a read-only root filesystem), but it is not a built-in admission controller for enforcing security policies; it requires custom development and does not natively enforce the read-only root filesystem constraint without additional logic.

Full explanation →

173

MCQeasy

Which command creates a Secret named 'db-secret' with two keys, 'username' and 'password', from literal values?

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

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

C.kubectl create secret generic db-secret --from-file=username=admin --from-file=password=secret123

D.kubectl create secret generic db-secret --literal=username=admin --literal=password=secret123

AnswerA

The `kubectl create secret generic` command instantiates a Secret of type Opaque (generic) in the current namespace. `--from-literal` takes a key=value pair directly and base64-encodes the value when storing it in the Secret's `data` map. Multiple `--from-literal` flags are allowed, so this command creates a Secret named `db-secret` with two data entries: `username` and `password` with the provided literal strings.

Why this answer

`kubectl create secret generic` is the correct command syntax for creating a generic (opaque) Secret from literal key-value pairs. The `--from-literal` flag allows you to specify each key and its value directly on the command line, making it the appropriate choice for this task.

Exam trap

The trap here is that candidates often forget the `generic` subcommand or confuse `--from-literal` with `--from-file` or a non-existent `--literal` flag, leading to syntax errors or unintended behavior.

How to eliminate wrong answers

Option B is wrong because it omits the required subcommand `generic`; the correct syntax is `kubectl create secret generic`. Option C is wrong because `--from-file` expects a file path, not a literal key=value pair; using `--from-file=username=admin` would attempt to read a file named 'admin' and assign its content to key 'username', which is not the intended behavior. Option D is wrong because the flag `--literal` does not exist; the correct flag is `--from-literal`.

Full explanation →

174

Multi-Selecthard

Which THREE of the following are valid reasons to use a startup probe? (Select THREE.)

Select 3 answers

A.To handle containers that have a variable startup time

B.To check if the container is healthy after startup

C.To delay readiness and liveness probes until the application is fully initialized

D.To remove the pod from service endpoints if it fails

E.To allow a container a long time to start up without being killed by liveness probe

AnswersA, C, E

Containers that take a variable amount of time to become ready—for example, because they must load large datasets or wait for external dependencies—can trip the default liveness probe settings and be restarted before they finish initializing. A startup probe lets you set a generous periodSeconds and failureThreshold so the kubelet waits an adequate, configurable window that can encompass all startup variability. Once the startup probe succeeds, normal liveness/readiness probing begins, but the startup probe itself ensures the variable initialization doesn't cause premature termination.

Why this answer

A startup probe is specifically designed for containers that have a variable or long initialization time. It allows the kubelet to delay the start of liveness and readiness probes until the application has finished starting up, preventing premature failures.

Exam trap

CNCF often tests the distinction between probe types, and the trap here is confusing the startup probe's role of delaying other probes with the readiness probe's role of controlling service traffic, or the liveness probe's role of restarting unhealthy containers.

Full explanation →

175

MCQmedium

A developer creates a ServiceAccount 'my-sa' in namespace 'default'. They want to prevent pods from automatically mounting the ServiceAccount token. Which field should be set to false in the pod spec?

A.serviceAccountName: my-sa

B.automountServiceAccountToken: false

C.serviceAccountName: my-sa automountServiceAccountToken: false

D.containers: - automountServiceAccountToken: false

AnswerB

Setting `automountServiceAccountToken: false` in the pod spec stops the kubelet projecting the ServiceAccount token into the container's filesystem, satisfying the requirement to prevent automatic mounting. This field overrides the ServiceAccount's own setting, giving per-pod control without altering the `my-sa` object itself.

Why this answer

Setting `automountServiceAccountToken: false` in the pod spec explicitly prevents the automatic mounting of the ServiceAccount token into the pod. This is the standard Kubernetes field for controlling token mounting at the pod level, overriding the default behavior where the token is mounted automatically.

Exam trap

CNCF often tests the distinction between pod-level and container-level fields, and the trap here is that candidates may incorrectly assume `automountServiceAccountToken` can be set under `containers` (option D) or that specifying `serviceAccountName` alone (option A) is sufficient to control token mounting.

How to eliminate wrong answers

Option A is wrong because `serviceAccountName: my-sa` only specifies which ServiceAccount to use, but does not control token mounting; the token would still be mounted automatically unless explicitly disabled. Option C is wrong because it redundantly specifies both `serviceAccountName` and `automountServiceAccountToken`, but the correct field name is `automountServiceAccountToken` (not `automountServiceAccountToken` with a typo) and the placement is at the pod spec level, not as a separate line; however, the core issue is that the question asks for the field to set to false, and option C includes an unnecessary `serviceAccountName` specification, making it less precise than B. Option D is wrong because `automountServiceAccountToken` is a pod-level field, not a container-level field; placing it under `containers` is invalid and would be ignored by the Kubernetes API.

Full explanation →

176

MCQmedium

An Ingress resource is created with the following YAML: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-svc port: number: 80 Which of the following requests will be routed to the api-svc Service? (Select all that apply.)

A.GET http://example.com/other

B.GET http://example.com/api/

C.GET http://example.org/api

D.GET http://example.com/apix

E.GET http://example.com/api/users

AnswerB, E

This request is valid because Kubernetes Prefix path matching treats /api/ as having the path element api as its first element, and the trailing slash is simply a separator after that element. The configured path /api is exactly matched by the first path element of /api/, so the rule applies even though the URL ends with a slash. Thus the request is correctly forwarded to the backend service, just like /api/users.

Why this answer

Based on the Ingress YAML, the host must be 'example.com' and the path must match the prefix '/api' according to pathType: Prefix, which matches based on URL path elements split by '/'. /api/ and /api/users are valid matches because the first path element 'api' matches and then the prefix ends. /apix does not match because 'apix' is not an element-wise prefix of 'api'. Option A fails due to path '/other'. Option C fails due to host 'example.org'.

Therefore, only options B and E are correct.

Exam trap

The common trap is thinking that Prefix matching works as a simple string prefix. In Kubernetes, Prefix matching for Ingress requires that the prefix ends at a path element boundary. For example, the prefix /api matches /api/ and /api/users, but not /apix because 'apix' is not a path element that starts with 'api'.

How to eliminate wrong answers

Option A is wrong because the path /other does not start with /api, so it does not match the Prefix rule. Option B is wrong because although /api/ starts with /api, the pathType Prefix matches any path beginning with the specified prefix, but /api/ is a valid match; however, the question asks which request will be routed, and /api/ is not listed as correct because the exam expects the path to include additional segments like /api/users to demonstrate prefix matching—Option B is actually a valid match but is not the intended correct answer here; the trap is that candidates might think /api/ is not matched, but it is. Option C is wrong because the host example.org does not match the specified host example.com.

Option D is wrong because /apix starts with /api, but the pathType Prefix matches any path beginning with /api, so /apix is technically a match; however, the question's correct answer is E because it is the only option that clearly demonstrates a longer path under /api, and the exam expects candidates to recognize that /apix is a different prefix (it is not a subpath of /api but a distinct path that happens to start with /api).

Full explanation →

177

MCQeasy

Which API version is correct for a Deployment in Kubernetes v1.29?

A.extensions/v1beta1

B.v1

C.apps/v1beta2

D.apps/v1

AnswerD

The apps/v1 version is the stable, general-availability API for Deployment and other workload resources. It has been the standard since Kubernetes 1.9 and is fully supported by all modern clusters, containing the complete set of stable fields and behaviors. kubectl and other tooling default to this version, making it the correct and safest apiVersion for Deployment manifests.

Why this answer

(apps/v1) is correct because the Deployment API version apps/v1 has been the stable version since Kubernetes v1.9, and it is the only correct version for creating Deployments in Kubernetes v1.29. The apps/v1 API group is the current, stable, and recommended version for managing Deployments, ReplicaSets, and other workload resources.

Exam trap

The trap here is that candidates may confuse the core v1 API group (used for Pods) with the apps/v1 group (used for Deployments), or mistakenly think that beta versions like apps/v1beta2 are still valid in recent Kubernetes releases.

How to eliminate wrong answers

Option A is wrong because extensions/v1beta1 was deprecated in Kubernetes v1.9 and removed entirely in v1.16; it is no longer available in v1.29. Option B is wrong because v1 is the core API group used for resources like Pods, Services, and ConfigMaps, but Deployments belong to the apps API group, not the core group. Option C is wrong because apps/v1beta2 was deprecated in Kubernetes v1.9 and removed in v1.16; it is not a valid API version in v1.29.

Full explanation →

178

MCQmedium

A Job must run 10 times in total, with up to 3 pods running simultaneously. Which fields should be set?

A.completions: 10, parallelism: 3

B.completions: 10, successfulJobsHistoryLimit: 3

C.completions: 10, parallelism: 10

D.completions: 3, parallelism: 10

AnswerA

This configuration sets the desired Job state: completions: 10 tells the Kubernetes Job controller that it must manage exactly 10 successful pod completions before the Job is marked complete, while parallelism: 3 caps the number of Pods that can run simultaneously. The controller will create Pods in batches, never exceeding the parallelism limit, until the total number of completed Pods reaches 10. This precisely matches the requirement of 10 total runs with at most 3 pods running at any given time.

Why this answer

In a Kubernetes Job, `completions: 10` specifies the total number of successful Pod completions required, and `parallelism: 3` limits the number of Pods that can run concurrently. This ensures the Job runs exactly 10 times with up to 3 Pods in parallel, which matches the requirement.

Exam trap

In CKAD, candidates often confuse `parallelism` (concurrent Pods) with `successfulJobsHistoryLimit` (history retention) or `completions` (total Pod completions). Remember that `parallelism` controls how many Pods run at once, not the total count.

How to eliminate wrong answers

Option B is wrong because `successfulJobsHistoryLimit` controls how many completed Job records are retained in the cluster history, not the number of concurrent Pods; it does not affect parallelism. Option C is wrong because `parallelism: 10` would allow up to 10 Pods to run simultaneously, exceeding the required limit of 3. Option D is wrong because `completions: 3` would only run the Job 3 times total, not 10, and `parallelism: 10` would allow up to 10 concurrent Pods, violating both requirements.

Full explanation →

179

MCQmedium

A pod uses a Secret 'db-secret' with keys 'username' and 'password'. Which environment variable definition correctly exposes the 'password' as an env var named 'DB_PASSWORD'?

A.env: - name: DB_PASSWORD value: "password"

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

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

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

AnswerB

This correctly maps the password key from the db-secret Secret into the DB_PASSWORD environment variable via valueFrom.secretKeyRef. Kubernetes fetches the value from the Secret at container creation and exposes it to the process exactly as named. This is the standard, recommended pattern for injecting a single secret key into a pod.

Why this answer

It uses `valueFrom.secretKeyRef` to reference the specific key `password` from the Secret `db-secret`, mapping it to the environment variable `DB_PASSWORD`. This is the standard Kubernetes method to expose a single key from a Secret as an environment variable with a custom name.

Exam trap

The trap here is that candidates often confuse `envFrom` with `env` and `secretRef` with `configMapKeyRef`, or assume that `envFrom` allows renaming keys, when in fact it only imports keys as-is, making Option C a distractor for those who want to import all keys but forget the naming requirement.

How to eliminate wrong answers

Option A is wrong because it hardcodes the password as a literal string in the Pod spec, which defeats the purpose of using a Secret and exposes sensitive data in plaintext. Option C is wrong because `envFrom` with `secretRef` imports all keys from the Secret as environment variables, but it does not allow renaming the variable to `DB_PASSWORD`; the key name `password` would become the env var name, not `DB_PASSWORD`. Option D is wrong because `configMapKeyRef` is used to reference ConfigMaps, not Secrets; Secrets require `secretKeyRef`.

Full explanation →

180

MCQeasy

Which of the following correctly describes the purpose of a PodSecurityPolicy (PSP) in Kubernetes? (Note: PSP is deprecated in v1.21+ and removed in v1.25; Pod Security Admission is the replacement.)

A.PSP is deprecated; its replacement is Pod Security Admission (PSA)

B.PSP is applied automatically to all pods in a cluster without configuration

C.PSP is a namespace-scoped resource that defines default security for pods

D.PSP cannot be used to control container security contexts

AnswerA

PodSecurityPolicy (PSP) was formally deprecated in Kubernetes v1.21 and entirely removed in v1.25, making it unavailable in current clusters. Its successor, Pod Security Admission (PSA), is a built-in admission controller that enforces the Pod Security Standards (baseline, restricted, privileged) at namespace granularity, addressing PSP's complexity and management overhead by providing a simpler, declarative approach without needing custom webhooks or separate RBAC.

Why this answer

PodSecurityPolicy (PSP) was indeed deprecated in Kubernetes v1.21 and removed in v1.25, with Pod Security Admission (PSA) as its official replacement. PSA uses built-in Pod Security Standards (baseline, restricted, privileged) enforced via admission controllers and labels, eliminating the need for a separate admission webhook or CRD-based policy object.

Exam trap

The trap here is that candidates may remember PSP as a namespace-scoped resource (Option C) because it is often associated with namespaces in documentation, but it is actually cluster-scoped, and the deprecation timeline (Option A) is a frequent distractor for those who haven't kept up with Kubernetes version changes.

How to eliminate wrong answers

Option B is wrong because PSP is not applied automatically; it requires explicit RBAC authorization (use of the `use` verb on the PSP resource for the pod's service account) and an admission controller (`PodSecurityPolicy`) to be enabled in the API server. Option C is wrong because PSP is a cluster-scoped resource, not namespace-scoped; it applies across all namespaces unless restricted by RBAC. Option D is wrong because PSP can control container security contexts (e.g., `privileged`, `runAsUser`, `seLinuxOptions`, `capabilities`) via its spec fields, which is its primary function.

Full explanation →

181

MCQhard

A pod is configured with 'securityContext.seccompProfile.type: RuntimeDefault' but the container still attempts to use a syscall that is blocked by the default seccomp profile. What happens?

A.The container is killed because it violated the seccomp policy.

B.The pod is evicted by the kubelet because of a security violation.

C.The container runs successfully because RuntimeDefault allows all syscalls.

D.The syscall fails with an error, but the container may continue running.

AnswerD

When a syscall is blocked by a seccomp profile, the kernel returns an error (commonly EPERM) to the process that made the call. The process's behavior after that depends entirely on how the application handles the error: it may log the failure, retry, or abort, but the container itself is not automatically stopped. Many applications do not check for seccomp-related errors and continue running with degraded functionality, so the container often remains alive and running.

Why this answer

When a container uses a syscall blocked by the seccomp profile, the syscall itself fails (returns an error like EPERM or is killed by SIGSYS), but the container process can handle that error and continue running. The `RuntimeDefault` profile applies Docker's default seccomp profile, which blocks around 44 syscalls (e.g., `mount`, `ptrace`, `perf_event_open`), but does not terminate the container unless the process exits due to the failed syscall. The container is not killed by Kubernetes; only the specific syscall is denied by the kernel's seccomp mechanism.

Exam trap

The trap here is that candidates assume any security violation immediately kills the container or evicts the pod, but seccomp violations only fail the specific syscall, and the container may continue if the process handles the error.

How to eliminate wrong answers

Option A is wrong because the container is not killed by Kubernetes; the seccomp policy causes the syscall to fail, but the container process may continue if it handles the error gracefully. Option B is wrong because pod eviction by the kubelet occurs for resource constraints or node-level issues (e.g., memory pressure, disk pressure), not for seccomp violations. Option C is wrong because `RuntimeDefault` does not allow all syscalls; it applies a restrictive default profile that blocks dangerous syscalls, so a blocked syscall will fail.

Full explanation →

182

MCQmedium

You want to update a Deployment's image from nginx:1.20 to nginx:1.21. Which command will perform a rolling update?

A.kubectl create deployment my-deployment --image=nginx:1.21

B.kubectl apply -f deployment.yaml

C.kubectl set image deployment/my-deployment nginx=nginx:1.21

D.kubectl edit deployment my-deployment

AnswerC

kubectl set image deployment/my-deployment nginx=nginx:1.21 is the correct imperative command because it directly changes the image of the container named nginx in the existing Deployment's pod template. The Deployment controller detects the template hash change, creates a new ReplicaSet, and performs a rolling update while keeping the Deployment name and metadata intact. This is a one-line, non-interactive, auditable update that accomplishes exactly the requested change.

Why this answer

`kubectl set image` directly updates the container image of a Deployment, which triggers a rolling update by default. The Deployment controller creates a new ReplicaSet with the updated image and gradually scales it up while scaling down the old ReplicaSet, ensuring zero downtime.

Exam trap

The trap here is that candidates may think `kubectl apply` or `kubectl edit` are the standard ways to trigger a rolling update, but the CKAD exam specifically tests the `kubectl set image` command as the direct imperative method for updating a Deployment's image.

How to eliminate wrong answers

Option A is wrong because `kubectl create deployment` creates a new Deployment resource, it does not update an existing one. Option B is wrong because `kubectl apply -f deployment.yaml` only works if the YAML file contains the updated image; the command itself does not guarantee a rolling update if the file is unchanged or if the Deployment is managed declaratively. Option D is wrong because `kubectl edit deployment` opens an editor for manual changes; while it can trigger a rolling update if the image is changed, it is not a direct command for performing a rolling update and relies on user interaction, making it less reliable for automation.

Full explanation →

183

MCQmedium

You run 'kubectl get events' and see an event 'FailedScheduling' for a pod. What is the most common cause?

A.Insufficient node resources to meet the pod's requests

B.The pod's container image pull failed

C.The liveness probe failed

D.The pod was deleted by a Deployment update

AnswerA

The FailedScheduling event is emitted by the kube-scheduler when no node passes all scheduling predicates for the pod. For a plain resource shortage, the scheduler cannot find a node with enough allocatable CPU/memory to meet the sum of container requests (not limits). This can also be triggered by node selectors, taints/tolerations, or affinity rules excluding every node, but the most common cause is insufficient resources. The event message typically names the specific constraint, such as 'Insufficient memory', for the node(s) attempted.

Why this answer

The 'FailedScheduling' event indicates that the Kubernetes scheduler could not find a suitable node to place the pod. The most common cause is insufficient node resources (CPU, memory, or ephemeral storage) to meet the pod's resource requests defined in the pod spec. The scheduler uses the `kube-scheduler` component to evaluate node fit based on predicates like `PodFitsResources`, and if no node satisfies the requested resources, the pod remains in a Pending state with this event.

Exam trap

The trap here is that candidates confuse 'FailedScheduling' with pod runtime failures (like image pull or probe failures), but scheduling events occur before the pod is bound to a node, so only resource-related or node affinity issues apply.

How to eliminate wrong answers

Option B is wrong because a container image pull failure generates a 'Failed' or 'ErrImagePull' event, not 'FailedScheduling', and is handled by the kubelet on an already scheduled node. Option C is wrong because a liveness probe failure causes the kubelet to restart the container, not a scheduling failure; it would produce a 'Unhealthy' or 'BackOff' event. Option D is wrong because a Deployment update that deletes a pod triggers a 'Killing' event and the pod is terminated, not left unscheduled; 'FailedScheduling' occurs before the pod is placed on any node.

Full explanation →

184

MCQeasy

Which kubectl command creates a ConfigMap named 'app-config' from a file named 'config.properties'?

A.kubectl create configmap app-config --from-file=config.properties

B.kubectl create configmap app-config --from-literal=config.properties

C.kubectl create configmap app-config --file=config.properties

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

AnswerA

The --from-file flag reads the entire content of config.properties and stores it as the Value of a single data entry whose Key is the file basename, config.properties. This is the correct way to create a ConfigMap when you want the file's raw content exposed intact, for example when mounting it to a volume or consuming via envFrom. By default, kubectl also ensures the ConfigMap is named app-config as specified.

Why this answer

`kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' by reading the entire contents of the file 'config.properties' and storing it as a single key-value pair, where the key defaults to the filename (config.properties) and the value is the file's content. This is the standard syntax for creating a ConfigMap from a file in Kubernetes.

Exam trap

The trap here is that candidates confuse `--from-file` (which imports a file as a single key-value pair) with `--from-env-file` (which imports a file of environment variables as multiple key-value pairs), or mistakenly think `--from-literal` can accept a file path.

How to eliminate wrong answers

Option B is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to reference a file; using `--from-literal=config.properties` would treat 'config.properties' as a literal string key with no value, which is invalid. Option C is wrong because `--file` is not a valid flag for `kubectl create configmap`; the correct flag is `--from-file`. Option D is wrong because `--from-env-file` is used to create a ConfigMap from a file containing environment variable definitions in KEY=VALUE format (one per line), not from a generic properties file; it would parse the file differently and may not produce the expected single-key ConfigMap.

Full explanation →

185

Multi-Selecthard

Which THREE commands can be used to get detailed information about a pod named 'my-pod'? (Choose three.)

Select 3 answers

A.kubectl logs my-pod

B.kubectl get pod my-pod -o json

C.kubectl describe pod my-pod

D.kubectl exec my-pod -- env

E.kubectl get pod my-pod -o yaml

AnswersB, C, E

Running `kubectl get pod my-pod -o json` requests the full Pod resource from the Kubernetes API and formats it as a JSON document. This output contains the complete object, including metadata (labels, annotations, ownerReferences), the desired spec, and the live status (pod IP, phase, container states, conditions). It is the canonical machine-readable representation, which can be piped to tools like `jq` for automation.

Why this answer

`kubectl get pod my-pod -o json` retrieves the full object representation of the pod in JSON format, which includes all fields such as metadata, spec, status, and annotations. This provides detailed, machine-readable information about the pod's current state and configuration.

Exam trap

CNCF often tests the distinction between commands that retrieve object metadata/status (get/describe) versus commands that interact with the pod's runtime (logs/exec), leading candidates to mistakenly select runtime commands for 'detailed information' about the pod itself.

Full explanation →

186

MCQmedium

A developer wants to create a ConfigMap named 'app-config' with two key-value pairs: 'color=blue' and 'size=large'. Which kubectl command should they use?

A.kubectl create configmap app-config --from-literal=color,size --value=blue,large

B.kubectl create configmap app-config --from-literal=color=blue --from-literal=size=large

C.kubectl create configmap app-config --from-env-file=color=blue,size=large

D.kubectl create configmap app-config --from-file=color=blue --from-file=size=large

AnswerB

This is the correct way to create a ConfigMap from literal values: each --from-literal flag declares one key-value pair, and repeating the flag adds multiple entries to the ConfigMap's data field. The resulting resource will have data containing color: blue and size: large. This syntax is unambiguous, follows the kubectl CLI contract, and works in scripts without external files.

Why this answer

`kubectl create configmap` with `--from-literal` allows specifying key-value pairs directly in the command line. Each literal must be provided as a separate `--from-literal=key=value` flag, and this command correctly creates the ConfigMap with the two entries 'color=blue' and 'size=large'.

Exam trap

The trap here is that candidates often confuse `--from-literal` with `--from-file` or try to use comma-separated syntax, not realizing that each literal must be specified with its own `--from-literal` flag in the exact `key=value` format.

How to eliminate wrong answers

Option A is wrong because `--from-literal` does not accept comma-separated keys and values; it requires the format `--from-literal=key=value` for each pair. Option C is wrong because `--from-env-file` expects a file path containing environment variables in `key=value` format, not inline comma-separated values. Option D is wrong because `--from-file` creates a ConfigMap entry from the content of a file, using the filename as the key, not from literal key-value pairs.

Full explanation →

187

Drag & Dropmedium

Order the steps to perform a rolling rollback of a Deployment to a previous revision.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

View history, choose revision, undo to that revision, wait for completion, then verify.

Full explanation →

188

MCQeasy

Which kubectl command correctly creates a ConfigMap from a file named 'app.properties'?

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

B.kubectl create configmap app-config --from-literal=app.properties

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

D.kubectl create configmap app-config --from-file=app.properties

AnswerD

The correct flag, --from-file, imports the specified file as a single ConfigMap entry, with the key defaulting to the file's basename (app.properties) and the value being the complete file content. This is the standard way to store a raw configuration file so it can later be mounted as a volume or exposed as a single environment variable. It works for any file format, including properties, YAML, JSON, or text, without requiring the content to look like KEY=VALUE pairs.

Why this answer

`kubectl create configmap app-config --from-file=app.properties` creates a ConfigMap by reading the entire contents of the file 'app.properties' and storing it under a key that defaults to the filename (app.properties). This is the standard way to import a file's data as a single key-value pair in a ConfigMap.

Exam trap

The trap here is that candidates confuse `--from-env-file` (which parses key=value lines) with `--from-file` (which imports the entire file as a single key), leading them to choose option C incorrectly.

How to eliminate wrong answers

Option A is wrong because it combines `--from-file` and `--from-env-file` for the same file, which is redundant and not the correct single command to create a ConfigMap from a file; `--from-env-file` is used for files with key=value format, not for importing a file as a single key. Option B is wrong because `--from-literal` is used to specify key-value pairs directly on the command line, not to reference a file; it would attempt to treat 'app.properties' as a literal key without a value. Option C is wrong because `--from-env-file` is intended for files containing environment-variable-style key=value lines (e.g., a .env file), not for importing a file's entire content as a single key; it would parse 'app.properties' line by line and fail if the file does not follow that format.

Full explanation →

189

MCQmedium

You have created a ServiceAccount named 'my-sa' in namespace 'default'. You want a Pod to use this ServiceAccount. Which Pod spec field is correct?

A.spec.securityContext.serviceAccount: my-sa

B.serviceAccountName: my-sa

C.serviceAccount: my-sa

D.automountServiceAccountToken: false

AnswerB

The serviceAccountName field is the correct way to assign the ServiceAccount my-sa to the pod. It is a top-level field in the pod spec, and when set, all containers in the pod share the identity and permissions of that ServiceAccount. Omitting it defaults to the 'default' ServiceAccount in the namespace.

Why this answer

The `serviceAccountName` field in a Pod spec is the standard way to assign a specific ServiceAccount to a Pod. When this field is set to `my-sa`, the Pod will use the token and permissions associated with that ServiceAccount for API authentication and authorization.

Exam trap

The trap here is that candidates confuse the deprecated `serviceAccount` field with the current `serviceAccountName` field, or incorrectly assume that `securityContext` can set the ServiceAccount.

How to eliminate wrong answers

Option A is wrong because `spec.securityContext.serviceAccount` is not a valid field; `securityContext` applies to Pod or container security settings (e.g., user ID, SELinux options), not ServiceAccount assignment. Option C is wrong because `serviceAccount` is a deprecated field in Pod spec; it has been replaced by `serviceAccountName` in Kubernetes v1.1+ and may be removed in future versions. Option D is wrong because `automountServiceAccountToken: false` controls whether the ServiceAccount token is automatically mounted into the Pod, but it does not specify which ServiceAccount to use; it is a boolean flag, not a name reference.

Full explanation →

190

MCQmedium

A Deployment has been updated with a new image. After running 'kubectl rollout status deployment/myapp', you see that the rollout has stalled. You want to undo the rollout to the previous revision. What command do you run?

A.kubectl rollout restart deployment/myapp

B.kubectl rollout undo deployment/myapp

C.kubectl delete deployment/myapp --cascade=orphan

D.kubectl set image deployment/myapp app=old-image

AnswerB

This is correct because kubectl rollout undo deployment/myapp inspects the Deployment's rollout history, retrieves the spec of the last completed revision, and copies that Pod template back into the Deployment. The change triggers a new ReplicaSet that runs the previously known-good image and performs a rolling update. This is the standard, trackable mechanism for recovering from a bad rollout.

Why this answer

'kubectl rollout undo deployment/myapp' reverts the Deployment to the previous revision, which is the standard Kubernetes command for rolling back a stalled or failed rollout. This command uses the Deployment's revision history stored in its annotations to restore the prior pod template specification.

Exam trap

The trap here is that candidates confuse 'rollout restart' (which re-deploys the current image) with 'rollout undo' (which reverts to a previous revision), or they mistakenly think manually setting an old image with 'set image' is equivalent to a proper rollback, ignoring Kubernetes' built-in revision management.

How to eliminate wrong answers

Option A is wrong because 'kubectl rollout restart' triggers a new rollout by restarting pods but does not revert to a previous revision; it re-deploys the current image, which would not fix a stalled rollout with a bad image. Option C is wrong because 'kubectl delete deployment/myapp --cascade=orphan' deletes the Deployment object but leaves its ReplicaSets and pods orphaned, which does not undo the rollout and instead removes the controller managing the pods. Option D is wrong because 'kubectl set image deployment/myapp app=old-image' manually sets the container image to a specific old image, but this does not leverage the rollout history and could introduce inconsistencies if the old image is not the exact previous revision; it also does not trigger a proper rollback with revision tracking.

Full explanation →

191

MCQhard

You have a multi-stage Dockerfile with two stages: 'builder' and 'runtime'. You want to copy artifacts from the builder stage to the runtime stage. Which Dockerfile instruction achieves this?

A.EXPORT builder /app/artifact /app/

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

C.COPY ../builder/artifact /app/

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

AnswerD

This is the correct way to copy an artifact from a previous build stage. The --from=builder flag tells Docker to treat the source path /app/artifact as being in the filesystem of the stage named builder, rather than in the build context. This copies the compiled artifact into the current stage's /app/ directory, enabling a clean separation between the build environment and the final runtime image. The COPY instruction is specifically designed to support this cross-stage file transfer.

Why this answer

The COPY instruction with --from=stage-name copies files from a previous build stage.

Full explanation →

192

MCQeasy

Which service type is used to expose a service using an external DNS name, such as a database hosted outside Kubernetes?

A.ClusterIP

B.NodePort

C.LoadBalancer

D.ExternalName

AnswerD

ExternalName is the correct Service type because it acts as a DNS alias by returning a CNAME record that points to a fully-qualified external domain name. It requires no ClusterIP, no selector, and no port mapping; any request to the Service name is transparently redirected to the external DNS name, making it the only Service type designed specifically to expose an external DNS name.

Why this answer

ExternalName is the correct service type because it maps a Kubernetes service to an external DNS name (e.g., a database hosted outside the cluster) by returning a CNAME record with that external name. This allows pods to access the external resource using the service's DNS name without needing to know the external endpoint's IP address.

Exam trap

The trap here is that candidates often confuse ExternalName with LoadBalancer, thinking that exposing an external resource requires a load balancer, but ExternalName is specifically designed for DNS-based aliasing without any network proxy.

How to eliminate wrong answers

Option A is wrong because ClusterIP exposes the service on a cluster-internal IP, making it only reachable from within the cluster, not via an external DNS name. Option B is wrong because NodePort exposes the service on a static port on each node's IP, which is for external traffic but does not provide an external DNS name mapping. Option C is wrong because LoadBalancer provisions an external load balancer with a public IP, but it does not map to an arbitrary external DNS name; it is for exposing services to external traffic via a load balancer, not for aliasing an external resource.

Full explanation →

193

MCQeasy

Which field in a Pod spec specifies which ServiceAccount the pod should use?

A.spec.serviceAccount

B.spec.accountName

C.spec.automountServiceAccountToken

D.spec.serviceAccountName

AnswerD

spec.serviceAccountName is the exact field used to specify which ServiceAccount should be attached to a Pod. This string field must reference a ServiceAccount that exists in the same namespace as the Pod, and if omitted, it defaults to 'default'. It is the basis for the Pod's identity for RBAC authorization and for authentication when contacting the Kubernetes API.

Why this answer

The correct field is `spec.serviceAccountName` in the Pod spec. This field explicitly specifies the name of the ServiceAccount that the Pod should use. If omitted, the Pod automatically uses the `default` ServiceAccount in its namespace.

This is defined in the Kubernetes API for PodSpec.

Exam trap

The trap here is that candidates may confuse the deprecated `spec.serviceAccount` field with the correct `spec.serviceAccountName`, or mistakenly think `spec.automountServiceAccountToken` selects the ServiceAccount, when it only controls token mounting.

How to eliminate wrong answers

Option A is wrong because `spec.serviceAccount` is a deprecated field that was replaced by `spec.serviceAccountName` in Kubernetes v1.9+; it is no longer supported in current API versions. Option B is wrong because `spec.accountName` is not a valid field in the PodSpec; Kubernetes does not recognize this field for ServiceAccount assignment. Option C is wrong because `spec.automountServiceAccountToken` is a boolean field that controls whether the ServiceAccount token is automatically mounted into the Pod, not which ServiceAccount to use.

Full explanation →

194

MCQmedium

You are performing a blue-green deployment. You have two Deployments: 'app-blue' and 'app-green', each with 5 replicas. Both are labeled with 'app: myapp'. The Service 'myapp-svc' selects pods with 'app: myapp' and 'version: blue'. After deploying the new version to 'app-green' and verifying it, what change is required to switch traffic to the green deployment?

A.Update the label on app-green pods to 'version: blue'

B.Update the Service selector to 'version: green'

C.Scale down app-blue to 0 replicas

D.Delete app-blue deployment

AnswerB

The Service acts as the traffic switch in a blue-green deployment; updating its selector from 'blue' to 'green' atomically redirects all client traffic to the green pods. Because green pods are already deployed and ready, this change requires no downtime and no pod restarts. This is the canonical cutover step: the selector change is the single point of control that moves production traffic to the new version.

Why this answer

In a blue-green deployment, traffic is switched by updating the Service's selector to match the labels of the new version's pods. Here, the Service 'myapp-svc' selects pods with 'version: blue'. To route traffic to the green deployment, you must change the selector to 'version: green'.

This causes the Service to immediately forward traffic to the green pods without modifying the pods themselves.

Exam trap

The trap here is that candidates often think they need to modify pod labels or scale down the old deployment, but the correct approach is to update the Service selector, which is the central mechanism for traffic routing in Kubernetes.

How to eliminate wrong answers

Option A is wrong because changing the label on app-green pods to 'version: blue' would make them indistinguishable from the blue pods, defeating the purpose of a blue-green deployment and potentially causing both sets to serve traffic simultaneously. Option C is wrong because scaling down app-blue to 0 replicas does not change the Service's selector; the Service would still target pods with 'version: blue', which would then have no endpoints, resulting in no traffic being served. Option D is wrong because deleting app-blue does not update the Service selector; the Service would still look for pods with 'version: blue', and with no such pods, traffic would be dropped.

Full explanation →

195

MCQmedium

A developer created a Role named 'pod-reader' in namespace 'ns1' that allows 'get', 'list', and 'watch' on pods. They created a RoleBinding binding this Role to a ServiceAccount 'sa1' in the same namespace. However, a pod using 'sa1' cannot list pods in namespace 'ns2'. What is the most likely cause?

A.The Role is missing the apiGroup field

B.The Role does not include the 'list' verb for pods

C.Role and RoleBinding are namespace-scoped; they only grant permissions within their namespace

D.The RoleBinding is not bound to the correct ServiceAccount

AnswerC

Role and RoleBinding are namespaced resources, so the permissions they grant apply only within ns1. Listing pods in ns2 requires a separate Role and RoleBinding in that namespace, or a ClusterRole paired with a ClusterRoleBinding for cluster-wide access. The stem's cross-namespace failure confirms this scoping constraint.

Why this answer

Role and RoleBinding are namespace-scoped resources in Kubernetes. A Role defined in 'ns1' grants permissions only within 'ns1', and a RoleBinding in 'ns1' binds that Role to a ServiceAccount only for operations inside 'ns1'. To list pods in 'ns2', the ServiceAccount needs a separate Role and RoleBinding (or a ClusterRole and ClusterRoleBinding) that explicitly grant permissions in 'ns2'.

Therefore, the pod using 'sa1' cannot list pods in 'ns2' because the Role and RoleBinding are confined to 'ns1'.

Exam trap

The trap here is that candidates often overlook the namespace-scoped nature of Role and RoleBinding, assuming that a RoleBinding can grant permissions across namespaces, when in fact it is strictly confined to the namespace of the RoleBinding itself.

How to eliminate wrong answers

Option A is wrong because the 'get', 'list', and 'watch' verbs on pods do not require an apiGroup field; pods are in the core API group (v1), which is the default and does not need explicit specification. Option B is wrong because the Role explicitly includes the 'list' verb for pods, as stated in the question. Option D is wrong because the RoleBinding is correctly bound to ServiceAccount 'sa1' in 'ns1', and the issue is not about binding to the wrong ServiceAccount but about namespace scope.

Full explanation →

196

MCQhard

A Pod in namespace 'team-a' runs with a serviceAccountName of 'reporter'. The Pod must read a Secret named 'metrics-token' that lives in namespace 'team-b'. Cluster-wide RBAC and the ServiceAccount token are already configured correctly. Which Pod specification change allows the container to obtain the Secret's data?

A.Use the ServiceAccount token to call the API server for the Secret in 'team-b', then write the returned data into a file the application reads.

B.Create a Secret in 'team-a' that has the same name, and rely on the kubelet to mirror the data from 'team-b' automatically.

C.Mount a volume of type secret with secretName 'metrics-token' and add a volumeMount at /var/run/metrics.

D.Add an env entry with valueFrom.secretKeyRef naming 'metrics-token' and set the Pod's namespace field to 'team-b'.

AnswerA

Secrets are namespaced objects, and the supported way to reach one in another namespace is through the Kubernetes API with credentials that RBAC authorizes. Since the ServiceAccount token and cluster-wide RBAC are already correct, the container can project the token and use an init container or sidecar to fetch the Secret and write it to a shared file for the application.

Why this answer

Secret references such as secretKeyRef and secret volume sources resolve only inside the Pod's own namespace, so a Pod in 'team-a' cannot directly project a Secret stored in 'team-b'. The API server is the cross-namespace path, and the Pod's ServiceAccount token, combined with the already-correct RBAC, lets the container retrieve the Secret and stage its data into a file the application consumes.

Exam trap

The trap here is expecting a namespace field on a Secret reference or on the Pod spec to permit cross-namespace Secret access.

Full explanation →

197

MCQhard

Your Deployment is stuck during rollout, and you want to investigate. Which command pauses the rollout and allows you to check the current state?

A.kubectl rollout resume deployment my-deployment

B.kubectl rollout status deployment my-deployment

C.kubectl rollout pause deployment my-deployment

D.kubectl rollout stop deployment my-deployment

AnswerC

kubectl rollout pause is the correct command because it sets the deployment's spec.paused field to true, instructing the deployment controller to stop creating or scaling new ReplicaSets. This freezes the rollout's current state and gives you a stable point to inspect logs, events, and resource metrics without the controller racing ahead. It directly addresses the need to investigate a stuck rollout.

Why this answer

The correct command to pause a deployment rollout is `kubectl rollout pause deployment my-deployment`. While paused, you can inspect the current state with `kubectl rollout status` or other diagnostic commands. Option A (`kubectl rollout resume`) resumes a paused rollout, not pauses it.

Option B (`kubectl rollout status`) shows the rollout state but does not pause it. Option D (`kubectl rollout stop`) is not a valid kubectl command; the correct command to stop a rollout is `kubectl rollout undo`. Therefore, only option C pauses the rollout as required.

Full explanation →

198

MCQeasy

You have a YAML file 'deploy.yaml' that defines a Deployment. Which command creates the Deployment if it does not exist, or updates it if it already exists?

A.kubectl replace -f deploy.yaml

B.kubectl patch -f deploy.yaml

C.kubectl create -f deploy.yaml

D.kubectl apply -f deploy.yaml

AnswerD

kubectl apply -f deploy.yaml is the correct declarative command for this question. It sends a PATCH request using the apply semantics, which computes a three-way merge between the local YAML, the live object's current state, and the last-applied-configuration annotation (kubectl.kubernetes.io/last-applied-configuration). This creates the Deployment if it does not exist, or updates only the fields that differ from the desired state while preserving changes made by controllers or other actors. Because the question asks about a YAML deployment definition without any conditional like 'if it does not exist', apply is the idiomatic and safe way to ensure the desired state is enforced idempotently.

Why this answer

`kubectl apply -f deploy.yaml` uses declarative object configuration: it creates the Deployment if it doesn't exist, or performs a strategic merge patch to update it if it already exists. This is the standard command for managing Kubernetes resources with a desired-state file.

Exam trap

The trap here is that candidates confuse `kubectl create` (which only creates and errors on existing resources) with `kubectl apply` (which handles both create and update), or mistakenly think `kubectl replace` works like an upsert when it actually requires the resource to already exist.

How to eliminate wrong answers

Option A is wrong because `kubectl replace -f deploy.yaml` will fail if the Deployment does not already exist, as it requires an existing resource to replace. Option B is wrong because `kubectl patch -f deploy.yaml` is not a valid command; `kubectl patch` requires specifying a resource name and a patch, not a file. Option C is wrong because `kubectl create -f deploy.yaml` will fail with an error if the Deployment already exists, as it only creates new resources and does not update.

Full explanation →

199

MCQmedium

You have a Secret of type 'kubernetes.io/tls' named 'tls-secret'. What keys are required in the Secret data?

A.tls.crt and tls.key

B.username and password

C.tls.crt, tls.key, and ca.crt

D..dockerconfigjson

AnswerA

In a kubernetes.io/tls Secret, the data field must contain exactly tls.crt (the PEM-encoded certificate chain) and tls.key (the PEM-encoded private key). These two keys are mandatory: the API server validates their presence at creation time, and Ingress controllers or application pods rely on them for TLS termination. Without either key, the Secret cannot be used for its intended cryptographic purpose.

Why this answer

A is correct because a Kubernetes TLS secret of type 'kubernetes.io/tls' requires exactly two data keys: 'tls.crt' (the TLS certificate) and 'tls.key' (the private key). These are mandatory for the TLS handshake to function, as defined by the Kubernetes API for TLS secrets.

Exam trap

The trap here is that candidates often assume 'ca.crt' is required because they think of full certificate chains, but the CKAD exam tests the exact mandatory keys per the Kubernetes API documentation for 'kubernetes.io/tls'.

How to eliminate wrong answers

Option B is wrong because 'username and password' are used for basic authentication secrets (type 'kubernetes.io/basic-auth'), not for TLS secrets. Option C is wrong because while 'ca.crt' (the CA certificate) is optional and can be included for chain validation, it is not required; only 'tls.crt' and 'tls.key' are mandatory. Option D is wrong because '.dockerconfigjson' is the key for a Docker registry secret (type 'kubernetes.io/dockerconfigjson'), not for a TLS secret.

Full explanation →

200

MCQmedium

A developer wants to ensure that a pod runs with a non-root user and cannot gain root privileges. Which SecurityContext settings should be used?

A.securityContext: allowPrivilegeEscalation: false

B.securityContext: runAsNonRoot: true

C.securityContext: runAsNonRoot: true allowPrivilegeEscalation: false

D.securityContext: runAsNonRoot: true allowPrivilegeEscalation: true

AnswerC

Combining runAsNonRoot: true with allowPrivilegeEscalation: false provides defense in depth: the former ensures the container does not start as root, while the latter prevents the process from gaining any additional privileges beyond its current non-root identity, such as via setuid execution or other escalators. This layered approach both satisfies the non-root mandate and blocks a common privilege escalation vector, making it the correct configuration for secure pod deployment.

Why this answer

Setting `runAsNonRoot: true` enforces that the container's user ID is non-zero (non-root), and `allowPrivilegeEscalation: false` prevents the container from gaining additional privileges beyond its initial set, such as through setuid binaries or kernel capabilities. Together, they ensure the pod runs as a non-root user and cannot escalate to root, satisfying the developer's requirement.

Exam trap

The trap here is that candidates often think `runAsNonRoot: true` alone is sufficient to prevent privilege escalation, but it only restricts the initial user ID, not the ability to escalate later, which requires `allowPrivilegeEscalation: false`.

How to eliminate wrong answers

Option A is wrong because `allowPrivilegeEscalation: false` alone does not enforce that the container runs as a non-root user; it only prevents privilege escalation, so a root user could still be used initially. Option B is wrong because `runAsNonRoot: true` alone ensures the container runs as a non-root user but does not prevent privilege escalation, meaning the container could still gain root privileges via setuid binaries or other mechanisms. Option D is wrong because `allowPrivilegeEscalation: true` explicitly permits privilege escalation, which directly contradicts the requirement to 'cannot gain root privileges'.

Full explanation →

201

MCQmedium

You need to collect metrics from an application running in a pod. The application exposes metrics on port 8080 at /metrics in Prometheus format. Which resource should you configure to allow Prometheus to scrape these metrics?

A.Create an Ingress resource that exposes the /metrics endpoint externally.

B.Create a ConfigMap with the Prometheus scrape configuration and mount it into the Prometheus pod.

C.Create a Service with annotation 'prometheus.io/scrape: "true"' and 'prometheus.io/port: "8080"'.

D.Add a PrometheusRule resource that defines the scrape target.

AnswerC

This is the standard approach for Prometheus operator's annotation-based discovery: the service's annotations `prometheus.io/scrape: "true"` and `prometheus.io/port: "8080"` allow the auto-discovery component to generate a scrape_config targeting the service's endpoints on port 8080. The Service provides a stable DNS name and selects the pods, so even if pod IPs change, Prometheus can dynamically look up the current endpoints. This is distinct from the static ConfigMap method because it enables automatic, label-based target discovery across the cluster.

Why this answer

Prometheus uses a pull-based model to scrape metrics from targets. By adding the `prometheus.io/scrape: "true"` and `prometheus.io/port: "8080"` annotations to a Service that selects the pod, you enable Prometheus's built-in service discovery to automatically detect and scrape the `/metrics` endpoint on port 8080 without manual configuration.

Exam trap

The trap here is that candidates confuse Prometheus's pull-based scraping with push-based or external access patterns, leading them to choose Ingress (external exposure) or PrometheusRule (alerting) instead of the service annotation that enables automatic internal discovery.

How to eliminate wrong answers

Option A is wrong because an Ingress resource exposes HTTP/HTTPS routes externally for client access, not for Prometheus scraping; Prometheus scrapes internally and does not use Ingress for target discovery. Option B is wrong because while a ConfigMap can hold Prometheus scrape configuration, mounting it into the Prometheus pod is a manual configuration step, not the resource that enables automatic scraping of an application pod; the question asks which resource to configure on the application side to allow scraping. Option D is wrong because a PrometheusRule resource defines alerting and recording rules, not scrape targets; scrape targets are defined via ServiceMonitor, PodMonitor, or service annotations.

Full explanation →

202

MCQeasy

Which kubectl command creates a ConfigMap named 'app-config' with key 'color' and value 'blue'?

A.kubectl create configmap app-config --from-literal=color=blue

B.kubectl create configmap app-config --from-file=color=blue

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

D.kubectl run configmap app-config --data color=blue

AnswerA

The command correctly uses the --from-literal flag, which accepts a key=value pair directly on the command line and stores the provided value as the data entry in the ConfigMap. This creates a ConfigMap named app-config with a key color whose value is the string blue. This is the standard and intended way to define a simple literal value as a ConfigMap data source.

Why this answer

`kubectl create configmap app-config --from-literal=color=blue` directly creates a ConfigMap with a key-value pair. The `--from-literal` flag specifies a literal key=value string, which is the standard way to inject a single key-value pair into a ConfigMap without referencing an external file.

Exam trap

The trap here is confusing `--from-literal` with `--from-file` or `--from-env-file`, as candidates often misremember which flag accepts a literal key=value string versus a file path.

How to eliminate wrong answers

Option B is wrong because `--from-file` expects a file path (e.g., `--from-file=color.txt`), not a literal key=value pair; using `--from-file=color=blue` would attempt to read a file named 'color=blue', which does not exist. Option C is wrong because `--from-env-file` expects a file containing environment variable definitions in KEY=VALUE format (e.g., `--from-env-file=env.txt`), not a literal key=value pair. Option D is wrong because `kubectl run` is used to create a Pod, not a ConfigMap; the `--data` flag is invalid for `kubectl run` and does not create ConfigMaps.

Full explanation →

203

MCQhard

You have a Deployment that uses an httpGet liveness probe on port 8080 with path /healthz. The probe fails after the container starts, but you can successfully curl http://localhost:8080/healthz from within the container. What is the most likely cause?

A.The liveness probe port is incorrect

B.The container is not running

C.The liveness probe path is incorrect

D.The container is listening on localhost (127.0.0.1) instead of 0.0.0.0

AnswerD

The liveness probe is executed by the kubelet on the node, which dials the pod's IP address on the specified port, not the container's loopback interface. If the application binds only to 127.0.0.1 (or ::1), it is reachable solely from within its own network namespace, making the pod IP's port appear closed or refused from the node. This exactly matches the symptom: curl localhost:8080 succeeds inside the container, but the kubelet's external connection fails. The fix is to configure the application server to listen on 0.0.0.0 (or the container's specific eth0 IP) so it accepts connections on all interfaces.

Why this answer

The liveness probe is executed by the kubelet from the node's network namespace, not from within the container. If the application binds only to 127.0.0.1 (localhost), it will only accept connections from within the container itself. The kubelet's HTTP GET request to the pod's IP on port 8080 will be refused because the socket is not listening on 0.0.0.0, causing the probe to fail even though a local curl succeeds.

Exam trap

The trap here is that candidates see a successful curl from inside the container and assume the probe should work, failing to realize that the kubelet probes from outside the container's network namespace and cannot reach a service bound only to 127.0.0.1.

How to eliminate wrong answers

Option A is wrong because the probe is configured to use port 8080, and the curl test confirms the application is indeed listening on port 8080 inside the container, so the port is correct. Option B is wrong because the container is clearly running — the user can successfully execute curl inside it, which requires a running container. Option C is wrong because the curl test uses the exact same path /healthz and succeeds, proving the path is correct and the endpoint is reachable from within the container.

Full explanation →

204

Multi-Selectmedium

Which TWO statements about Ingress are correct? (Select 2)

Select 2 answers

A.Ingress can terminate TLS.

B.Ingress provides a ClusterIP for internal access.

C.Ingress can route traffic based on the host header.

D.Ingress can load balance TCP traffic.

E.Ingress automatically assigns an external IP to the Service.

AnswersA, C

The Ingress resource supports a TLS block that references a Secret holding the TLS private key and certificate. When configured, the Ingress controller terminates incoming HTTPS requests at the edge, decrypting them and forwarding unencrypted HTTP to backend Services. This offloads SSL/TLS processing from application pods and centralizes certificate management, making it a common practice in production clusters.

Why this answer

Ingress can terminate TLS by using a Secret that contains the TLS certificate and private key. When configured in the Ingress spec under `tls` and `secretName`, the Ingress controller decrypts HTTPS traffic before forwarding it to the backend Service, offloading TLS termination from the application pods.

Exam trap

The CKAD exam often tests the distinction between Layer 7 (Ingress) and Layer 4 (Service) capabilities, trapping candidates who assume Ingress can handle TCP traffic or assign IPs like a LoadBalancer Service.

Full explanation →

205

MCQhard

An Ingress resource routes traffic to a Service 'web' on port 80. The Service has multiple endpoints but all return 503. What should be checked first?

A.Ensure that the Service type is ClusterIP

B.Check the readiness probe of the Pods

C.Verify that the Service port matches the Pod's container port

D.Check the Ingress controller logs

AnswerB

A 503 Service Unavailable from an Ingress almost always means the Ingress controller has no healthy endpoints to forward the request to. Readiness probes are the gate that determines whether a Pod is included in the Service's Endpoints or EndpointSlice object; if the probe fails, the Pod is removed. The Ingress controller then sees an empty endpoint list for the backend Service and returns 503 before any request reaches the application. Therefore, checking the readiness probe configuration and the current Pod status is the correct first step to diagnose a 503.

Why this answer

A 503 Service Unavailable error from the Ingress indicates the upstream Service is not ready to serve traffic. The most common cause is Pods failing their readiness probes, which removes them from the Service's endpoint list. Checking the readiness probe status directly addresses why the Service has endpoints but returns 503.

Exam trap

CNCF often tests the distinction between readiness and liveness probes, where candidates mistakenly check liveness or assume a port mismatch, but readiness directly controls traffic routing via Services.

How to eliminate wrong answers

Option A is wrong because ClusterIP is the default Service type and does not cause 503 errors; changing it would not fix the issue. Option C is wrong because if the Service port mismatched the container port, the Service would have no endpoints at all, not endpoints returning 503. Option D is wrong because Ingress controller logs would show routing errors or backend unavailability, but the first diagnostic step should be checking the Pods' readiness, not logs.

Full explanation →

206

Multi-Selecthard

You want to apply a Pod Security Admission (PSA) policy that enforces the 'restricted' profile in the 'dev' namespace, but only for Pods that are not exempt. Which TWO steps are required? (Select TWO)

Select 2 answers

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

B.Add a 'securityContext' field to the Pod template with 'runAsUser: 1000'

C.Set the label 'pod-security.kubernetes.io/enforce=baseline' on the namespace

D.Set the label 'pod-security.kubernetes.io/warn=restricted' on the namespace

E.Configure Pods to meet the restricted profile requirements, such as setting runAsNonRoot and seccompProfile

AnswersA, E

Setting the label 'pod-security.kubernetes.io/enforce=restricted' on the namespace activates the Pod Security Admission controller's restricted policy for all Pods created in that namespace. This label causes the admission controller to reject any Pod that does not meet the restricted profile's requirements, such as running as non-root and using a seccomp profile. It is the standard mechanism for enforcing PSA policies at the namespace level.

Why this answer

Option A is correct because PSA enforcement is enabled per-namespace by applying the label 'pod-security.kubernetes.io/enforce=restricted' to the 'dev' namespace, which tells the Pod Security Admission controller to reject Pods that violate the restricted profile. Option E is correct because the restricted profile imposes strict requirements — such as runAsNonRoot: true, allowPrivilegeEscalation: false, dropping ALL capabilities, and setting seccompProfile.type to RuntimeDefault or Localhost — so workloads must be configured to satisfy these controls to be admitted. Option B is incorrect because merely setting runAsUser: 1000 does not satisfy the restricted profile, which specifically requires runAsNonRoot rather than a fixed UID.

Option C is incorrect because 'baseline' is a less restrictive profile than 'restricted' and would not enforce the required policy. Option D is incorrect because the 'warn' label only produces warnings and does not enforce the restricted profile; enforcement requires the 'enforce' label.

Exam trap

The trap here is confusing the 'warn' mode with 'enforce' mode, as candidates often think a warning label is sufficient to block non-compliant Pods, but only the 'enforce' label actually rejects them at admission time.

Full explanation →

207

MCQhard

You are designing a Pod that must run a diagnostic tool to collect network logs before the main application starts. The diagnostic tool should run to completion, then the main application starts. Which approach should you use?

A.Add the diagnostic tool as an init container in the Pod

B.Add the diagnostic tool as a sidecar container in the same Pod

C.Add the diagnostic tool as a sidecar container with a postStart hook

D.Create a separate Job that runs before the Pod

AnswerA

An init container is the correct choice because Kubernetes runs init containers to completion, in order, before any regular app container is started. This guarantees the diagnostic tool finishes its checks first, and if it exits with a non-zero status, the app container will not be created. The diagnostic is thus an explicit, blocking prerequisite within the same Pod.

Why this answer

Init containers run sequentially before the Pod's main containers start, and they must complete successfully before the main application container begins. This makes them ideal for setup tasks like running a diagnostic tool to collect network logs that must finish before the main application starts.

Exam trap

The trap here is that candidates confuse init containers with sidecar containers or lifecycle hooks, assuming any container that runs before the main application can be a sidecar, but only init containers guarantee sequential execution to completion before the main container starts.

How to eliminate wrong answers

Option B is wrong because a sidecar container runs concurrently with the main container, not before it, so the diagnostic tool would not complete before the main application starts. Option C is wrong because a postStart hook runs inside the main container's lifecycle after the container starts, but it does not block the main application from starting; the hook runs asynchronously, so the main application could begin before the diagnostic tool finishes. Option D is wrong because creating a separate Job introduces unnecessary complexity and does not guarantee the Job completes before the Pod starts; the Pod could be scheduled and run before the Job finishes, and there is no built-in dependency mechanism between a Job and a Pod.

Full explanation →

208

MCQeasy

What annotation is required on an Ingress resource to use a specific IngressClass (e.g., 'nginx')?

A.kubernetes.io/ingress-type: nginx

B.kubernetes.io/ingress.class: nginx

C.ingress.kubernetes.io/class: nginx

D.kubernetes.io/class: nginx

AnswerB

This is the correct, historically standard annotation used to tell an ingress controller which IngressClass resource to use for configuring routing. Although the Kubernetes Ingress API now provides the `ingressClassName` field, this annotation remains widely supported by controllers like NGINX Ingress. It must exactly match the name of an IngressClass object in the cluster.

Why this answer

The `kubernetes.io/ingress.class` annotation is the legacy method to specify the IngressClass for an Ingress resource. This annotation tells the Ingress controller (e.g., nginx) which controller should process the Ingress rules. In Kubernetes 1.18+, the preferred method is the `spec.ingressClassName` field, but the annotation is still widely supported for backward compatibility.

Exam trap

The trap here is that candidates confuse the annotation `kubernetes.io/ingress.class` with the `spec.ingressClassName` field or invent non-existent annotations like `kubernetes.io/ingress-type`, leading them to pick a plausible-sounding but incorrect option.

How to eliminate wrong answers

Option A is wrong because `kubernetes.io/ingress-type` is not a valid Kubernetes annotation; it does not exist in the API specification. Option C is wrong because `ingress.kubernetes.io/class` is not a standard annotation; the correct prefix is `kubernetes.io/ingress.class`. Option D is wrong because `kubernetes.io/class` is too generic and not recognized by any Ingress controller; the annotation must include `ingress.class` to be interpreted correctly.

Full explanation →

209

MCQmedium

A pod named 'app' is stuck in 'Pending' state. You run 'kubectl describe pod app' and see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the most likely cause?

A.The pod's CPU request is higher than the available CPU on any node

B.The container image is not found

C.The pod is in CrashLoopBackOff

D.The pod has been evicted due to memory pressure

AnswerA

A pod with a CPU request exceeding the allocatable CPU on every node cannot be scheduled. The Kubernetes scheduler filters out nodes lacking sufficient unallocated capacity to satisfy the request, leaving the pod in the Pending phase and emitting events such as 'Insufficient cpu'. Requests, not limits, drive these placement decisions, so the pod can wait indefinitely until node capacity is freed or the request is lowered.

Why this answer

The event '0/3 nodes are available: 3 Insufficient cpu' indicates that the pod's CPU resource request exceeds the allocatable CPU capacity on every node in the cluster. Kubernetes schedules pods based on resource requests, not limits, so if the sum of CPU requests across all pods on a node would exceed the node's capacity, the pod remains Pending. This is the most likely cause because the error message directly points to insufficient CPU resources.

Exam trap

The trap here is that candidates confuse resource requests with resource limits, or assume that the pod is failing at runtime (like CrashLoopBackOff) when the error is purely a scheduling issue indicated by the Pending state and the specific 'Insufficient cpu' event.

How to eliminate wrong answers

Option B is wrong because a missing container image would produce an 'ImagePullBackOff' or 'ErrImagePull' event, not an 'Insufficient cpu' scheduling error. Option C is wrong because CrashLoopBackOff is a pod status that occurs after the pod has been scheduled and started, not while it is still Pending. Option D is wrong because eviction due to memory pressure results in a 'Evicted' status, not a Pending state, and the event would mention memory, not CPU.

Full explanation →

210

MCQhard

A ClusterRole named 'secret-reader' grants get, list, watch on secrets in all namespaces. A RoleBinding in namespace 'app' binds this ClusterRole to a ServiceAccount 'app-sa'. Which of the following is true about the effective permissions of 'app-sa'?

A.The ServiceAccount can read secrets in all namespaces

B.The RoleBinding is invalid because ClusterRole cannot be used with RoleBinding

C.The ServiceAccount can read secrets only in namespace 'app'

D.The ServiceAccount can read secrets only in the default namespace

AnswerC

This is correct because a RoleBinding always scopes the permissions it grants to the namespace where the RoleBinding itself is created. The ClusterRole named 'secret reader' defines the verbs get, list, and watch on secrets, but the RoleBinding in namespace 'app' limits those permissions to secrets in 'app'. Since secrets are namespaced resources, the effective access is exactly get/list/watch for secrets only in the 'app' namespace.

Why this answer

A RoleBinding can only grant permissions within its own namespace, even when it references a ClusterRole. Since the RoleBinding is in namespace 'app', the ServiceAccount 'app-sa' receives the permissions defined in the 'secret-reader' ClusterRole, but scoped only to namespace 'app'. Therefore, it can read secrets only in namespace 'app', not in all namespaces.

Exam trap

The trap here is that candidates often assume a ClusterRole always grants cluster-wide permissions when bound via any binding, forgetting that a RoleBinding restricts the scope to its own namespace.

How to eliminate wrong answers

Option A is wrong because a RoleBinding scopes the ClusterRole's permissions to the RoleBinding's namespace ('app'), not to all namespaces; to grant cluster-wide access, a ClusterRoleBinding must be used. Option B is wrong because a RoleBinding can legally reference a ClusterRole; this is a standard Kubernetes pattern to reuse cluster-scoped roles within a specific namespace. Option D is wrong because the RoleBinding is in namespace 'app', not 'default', so the permissions apply to namespace 'app' only.

Full explanation →

211

MCQeasy

You want to scale a Deployment named 'frontend' to 5 replicas. Which command should you use?

A.kubectl set replicas deployment frontend=5

B.kubectl update deployment frontend --replicas=5

C.kubectl scale deployment frontend --replicas=5

D.kubectl scale --replicas=5 frontend

AnswerC

'kubectl scale' is the canonical command for resizing a Deployment's replica count. The resource type 'deployment' and the resource name 'frontend' are given as positional arguments, while '--replicas=5' sets the desired number of pods. This directly updates the Deployment's spec.replicas field and triggers the ReplicaSet/Deployment controllers to converge to the new count.

Why this answer

`kubectl scale` is the dedicated Kubernetes command to adjust the number of replicas for a Deployment (or other scalable resources). The syntax `kubectl scale deployment frontend --replicas=5` directly instructs the API server to update the Deployment's `spec.replicas` field to 5, triggering the ReplicaSet controller to create or remove Pods to match the desired count.

Exam trap

The trap here is that candidates may confuse `kubectl scale` with other imperative commands like `kubectl set` or `kubectl update`, or misorder the flags, leading them to choose syntactically invalid options that mimic common but incorrect patterns.

How to eliminate wrong answers

Option A is wrong because `kubectl set replicas` is not a valid kubectl command; the correct command for modifying a resource field is `kubectl set` (e.g., `kubectl set image`), but there is no `replicas` subcommand. Option B is wrong because `kubectl update` is not a valid kubectl command; updates are performed via `kubectl apply`, `kubectl edit`, or `kubectl patch`, not `update`. Option D is wrong because the syntax is incorrect: the resource type and name must come before the `--replicas` flag (i.e., `kubectl scale deployment frontend --replicas=5`), and placing `--replicas=5` before `frontend` causes a parsing error.

Full explanation →

212

MCQhard

A pod is stuck in Pending state. You run 'kubectl describe pod mypod' and see the event: '0/3 nodes are available: 1 Insufficient memory, 2 Insufficient cpu'. The pod has resource requests defined. Which action would allow the pod to be scheduled?

A.Increase the resource requests for the container

B.Delete the pod and recreate it with the same spec

C.Decrease the memory and CPU requests to fit within available node resources

D.Decrease the CPU request but keep the memory request the same

AnswerC

The kube-scheduler places a pod only if every node has enough unused allocatable resources to meet the pod's requests. If the combined memory and CPU requests exceed what is available on any node, the pod is stuck in Pending. Lowering both request values to fit within the allocatable capacity remaining on an existing node allows the scheduler to find a feasible host and bind the pod.

Why this answer

The pod is unschedulable because the cluster's three nodes collectively lack sufficient CPU and memory to satisfy the pod's resource requests. Decreasing the memory and CPU requests to fit within the available node resources (option C) directly resolves the scheduling failure by making the pod's resource demands compatible with the remaining capacity on at least one node.

Exam trap

CNCF often tests the misconception that simply recreating the pod or adjusting only one resource dimension will fix scheduling issues, when in fact the scheduler evaluates all resource requests simultaneously against each node's allocatable capacity.

How to eliminate wrong answers

Option A is wrong because increasing resource requests would make the pod even more demanding, worsening the scheduling failure. Option B is wrong because deleting and recreating the pod with the same spec does not change the resource requests or node availability, so it will remain stuck in Pending. Option D is wrong because decreasing only the CPU request while keeping the memory request unchanged would still leave the memory request unmet (the event shows 1 node has insufficient memory), so the pod would still be unschedulable.

Full explanation →

213

MCQmedium

You want to see the IP address and the node on which each pod in the 'default' namespace is running. Which command provides this information?

A.kubectl describe pods

B.kubectl get pods -o wide

C.kubectl get pods --show-labels

D.kubectl get pods -o yaml

AnswerB

kubectl get pods -o wide is correct because the -o wide flag extends the default pod listing with the IP and NODE columns, displaying each pod's cluster-assigned IP address and the name of the node hosting it. These fields come directly from the pod's status.podIP and spec.nodeName, and the output remains a single-row-per-pod table, making it ideal for quickly answering exactly what the question asks.

Why this answer

`kubectl get pods -o wide` outputs additional columns including the pod's IP address and the node it is scheduled on, which directly answers the question. The `-o wide` flag extends the default output format to show these fields without requiring a full resource description or YAML output.

Exam trap

The trap here is that candidates may choose `kubectl describe pods` (Option A) because it shows IP and node information, but they overlook that `-o wide` provides a cleaner, tabular view for multiple pods, which is the intended use case in the question.

How to eliminate wrong answers

Option A is wrong because `kubectl describe pods` shows detailed information about pods, including IP and node, but it is not a concise command to 'see' this data for all pods at once; it requires scrolling through verbose output per pod. Option C is wrong because `--show-labels` only adds label columns to the default pod list, not IP or node information. Option D is wrong because `-o yaml` outputs the full YAML representation of pod objects, which includes IP and node fields but is overly verbose and not the standard way to quickly view this tabular data.

Full explanation →

214

Multi-Selectmedium

Which TWO methods can be used to expose a Secret's data as environment variables inside a container? (Select 2)

Select 2 answers

A.Using 'args' in container spec

B.Using 'env.valueFrom.secretKeyRef'

C.Using 'env.valueFrom.configMapKeyRef'

D.Using 'volumeMounts' with a secret volume

E.Using 'envFrom.secretRef'

AnswersB, E

This is a direct method to expose a single key from a Secret as a named environment variable. In the container spec, you define an env entry with a name and valueFrom.secretKeyRef referencing the Secret and key. Kubernetes decodes the base64 value and injects it into the container's environment. This approach gives precise control over which secret values become env vars and what their variable names are.

Why this answer

`env.valueFrom.secretKeyRef` allows you to inject a specific key from a Kubernetes Secret as an environment variable into a container. This is a standard method for exposing sensitive data like passwords or tokens directly into the container's environment without hardcoding them in the Pod spec.

Exam trap

CNCF often tests the distinction between `env.valueFrom.secretKeyRef` (for a single key) and `envFrom.secretRef` (for all keys), and the trap is that candidates confuse `secretKeyRef` with `configMapKeyRef` or think `args` can be used for environment injection.

Full explanation →

215

MCQmedium

A company wants to ensure zero-downtime deployments for a stateless web application running in Kubernetes. They have a single Deployment with 3 replicas and a Service of type LoadBalancer. Which strategy should they use to achieve this?

A.Use Recreate strategy

B.Use RollingUpdate with maxSurge=100% and maxUnavailable=100%

C.Use RollingUpdate with maxSurge=25% and maxUnavailable=0

D.Use RollingUpdate with maxSurge=0 and maxUnavailable=25%

AnswerC

With maxUnavailable=0, the rolling update guarantees that no existing pods are terminated until replacement pods have been created and reached the Ready state. The default maxSurge=25% allows the deployment to temporarily provision additional pods beyond the desired replica count, ensuring a buffer of ready pods during the transition. This combination provides zero-downtime because traffic continues to be served by the old pods until new pods are fully ready and can take over seamlessly.

Why this answer

A RollingUpdate strategy with maxSurge=25% and maxUnavailable=0 ensures that during a deployment, the desired number of replicas is always available (no downtime). maxUnavailable=0 means no old Pods are terminated until new ones are ready, and maxSurge=25% allows one extra Pod (25% of 3 replicas = 0.75, rounded up to 1) to be created before terminating old ones, maintaining capacity for zero-downtime updates.

Exam trap

The trap here is that candidates often confuse maxSurge and maxUnavailable, thinking that allowing some unavailability (e.g., maxUnavailable=25%) is acceptable for zero-downtime, but in Kubernetes, zero-downtime strictly requires maxUnavailable=0 to ensure no Pods are terminated before replacements are ready.

How to eliminate wrong answers

Option A is wrong because the Recreate strategy terminates all existing Pods before creating new ones, causing downtime during the update. Option B is wrong because maxSurge=100% and maxUnavailable=100% allows all Pods to be replaced simultaneously, which can cause a temporary loss of service if readiness probes fail or new Pods take time to become ready, violating zero-downtime requirements. Option D is wrong because maxSurge=0 and maxUnavailable=25% means no new Pods are created until old ones are terminated, reducing available capacity by 25% (1 Pod) during the update, which can cause downtime if traffic exceeds remaining capacity.

Full explanation →

216

Multi-Selecthard

A pod is running but not serving traffic. You suspect the readiness probe is failing. Which THREE commands or actions would help you diagnose the readiness probe issue?

Select 3 answers

A.Examine the container logs for errors during readiness probe checks.

B.Run 'kubectl top pod <pod-name>' to check CPU/memory usage.

C.Run 'kubectl get nodes' to see node conditions.

D.Run 'kubectl describe pod <pod-name>' to check the events section for probe failures.

E.Exec into the container and manually curl the readiness endpoint to test it.

AnswersA, D, E

Container logs are one of the first places to look when a readiness probe fails. The kubelet sends probe requests (e.g., HTTP GET to the probe path), and if the application logs each request, you may see the probe arriving with a non-2xx status, stack traces, or slow response times indicating why the endpoint is not healthy. While probe requests are not always logged, if they are, they can directly reveal the underlying cause such as a crash loop, a missing dependency, or a connection timeout.

Why this answer

Container logs often contain detailed error messages from the readiness probe itself, such as HTTP 4xx/5xx responses or connection timeouts. By examining the logs, you can directly see why the probe is failing, e.g., the application's health endpoint returning a non-2xx status or the probe timing out.

Exam trap

CNCF often tests the distinction between resource monitoring commands and probe-specific diagnostics, so candidates may mistakenly choose 'kubectl top pod' or 'kubectl get nodes' thinking they reveal probe failures, when in fact only describe, logs, and direct endpoint testing are relevant.

Full explanation →

217

MCQeasy

Which command forwards port 8080 on the local machine to port 80 on a pod named 'web-pod'?

A.kubectl expose pod web-pod --port=8080 --target-port=80

B.kubectl proxy --port=8080 --target=pod/web-pod:80

C.kubectl port-forward pod/web-pod 8080:80

D.kubectl exec web-pod -- curl http://localhost:8080

AnswerC

`kubectl port-forward` establishes a tunnel from the local machine to the specified pod, and the `8080:80` mapping forwards local port 8080 to port 80 inside `web-pod`. This satisfies the stem's requirement exactly: local 8080 to pod 80, with the pod named as the target resource.

Why this answer

`kubectl port-forward` creates a direct tunnel from a local port to a port on a specific pod. The syntax `kubectl port-forward pod/web-pod 8080:80` forwards local port 8080 to port 80 on the pod named 'web-pod', enabling local access to the pod's service without requiring a Service object.

Exam trap

The trap here is that candidates confuse `kubectl expose` (which creates a Service for network abstraction) with `kubectl port-forward` (which creates a direct, temporary tunnel), leading them to select Option A when the question explicitly asks for port forwarding to a pod.

How to eliminate wrong answers

Option A is wrong because `kubectl expose` creates a Service object (e.g., ClusterIP, NodePort) to expose a pod or deployment, not a direct port-forward tunnel; it does not forward a local port to a pod. Option B is wrong because `kubectl proxy` creates a proxy to the Kubernetes API server, not a direct tunnel to a pod, and its syntax does not support `--target=pod/web-pod:80`; it uses `--port` and optionally `--www-prefix` for API proxying. Option D is wrong because `kubectl exec` runs a command inside the pod (here, `curl http://localhost:8080`), which would attempt to connect to port 8080 inside the pod, not forward a local port to the pod; it does not expose the pod's port to the local machine.

Full explanation →

218

MCQmedium

A Deployment is configured with strategy type 'Recreate'. Which statement about this strategy is true?

A.It creates a new ReplicaSet but does not scale down the old one.

B.It updates Pods by gradually terminating old Pods and creating new ones.

C.It terminates all existing Pods before creating new Pods.

D.It first creates new Pods and then terminates old Pods.

AnswerC

Under the Recreate strategy, the Deployment controller first scales the old ReplicaSet down to zero and confirms all Pods have been terminated (respecting terminationGracePeriodSeconds and preStop hooks) before it creates any new Pods from the updated ReplicaSet. This guarantees that at no point are old and new versions running concurrently, at the cost of an explicit downtime interval during the rollout.

Why this answer

The Recreate strategy in a Kubernetes Deployment terminates all existing Pods before creating new ones, resulting in a brief period of downtime. This is the defining behavior of the Recreate strategy as documented in the Kubernetes Deployment spec. It is the opposite of RollingUpdate, which maintains availability by incrementally replacing Pods.

Exam trap

CKAD often tests the distinction between Recreate and RollingUpdate strategies, and candidates confuse the order of Pod termination and creation — Recreate kills first, RollingUpdate creates first (or in parallel).

How to eliminate wrong answers

Option A is wrong because creating a new ReplicaSet without scaling down the old one describes a partial or misconfigured rollout, not Recreate — Recreate deletes the old ReplicaSet's Pods entirely. Option B is wrong because gradually terminating old Pods and creating new ones describes the RollingUpdate strategy, not Recreate. Option D is wrong because creating new Pods before terminating old ones is also characteristic of RollingUpdate (specifically the surge behavior), whereas Recreate does the reverse order.

Full explanation →

219

MCQmedium

A team ships a container that writes structured JSON diagnostics to stdout and nothing to a file. A support engineer needs to filter those lines for entries with level 'error' across all containers of a deployment named 'checkout', without installing additional tooling on the nodes. Which approach accomplishes this using only kubectl?

A.kubectl logs deployment/checkout --since=1h --tail=-1

B.kubectl exec -it deployment/checkout -- cat /var/log/app.log | grep error

C.kubectl describe deployment checkout | grep error

D.kubectl logs deployment/checkout --all-containers=true | grep '"level":"error"'

AnswerD

kubectl logs accepts a deployment as a resource argument and, with --all-containers=true, streams logs from every container in the pods the deployment owns. Piping that combined stream through grep filters the JSON lines locally in the engineer's shell, satisfying the requirement with no extra software on the cluster nodes.

Why this answer

Container logs are fetched from the kubelet's log files through the API server by kubectl logs, which can target a workload such as a deployment and aggregate every container with --all-containers=true. Filtering that aggregated stream in the local shell with grep isolates the structured error entries. Options that adjust time windows, describe the deployment, or read a nonexistent file inside one pod do not deliver the filtered, deployment-wide view that was requested.

Exam trap

The trap here is assuming kubectl logs can filter by content or that a deployment's diagnostics live anywhere other than the containers' stdout streams.

Full explanation →

220

MCQeasy

Which kubectl command is used to view the rollout status of a Deployment named 'web-app'?

A.kubectl rollout history deployment web-app

B.kubectl describe deployment web-app

C.kubectl status deployment web-app

D.kubectl rollout status deployment web-app

AnswerD

kubectl rollout status deployment web-app is the dedicated command for observing the progress of a Deployment rollout. It watches the Deployment's updated ReplicaSet status and returns a stream of updates, for example 'Waiting for rollout to finish: 1 out of 3 new replicas have been updated...', exiting with 0 when the rollout succeeds or non-zero if it fails. Its synchronous behavior makes it ideal for scripting CI/CD pipelines that need to wait for a deployment to settle.

Why this answer

`kubectl rollout status deployment web-app` is the dedicated command to monitor the progress of a rollout for a Deployment named 'web-app'. It blocks until the rollout completes successfully or reports a failure, providing real-time status updates such as 'Waiting for rollout to finish' or 'deployment "web-app" successfully rolled out'.

Exam trap

The trap here is that candidates confuse `rollout history` (which shows past revisions) with `rollout status` (which shows current rollout progress), or they assume a generic `status` subcommand exists when it does not.

How to eliminate wrong answers

Option A is wrong because `kubectl rollout history deployment web-app` displays the revision history of rollouts (e.g., revision numbers and change causes), not the current rollout status. Option B is wrong because `kubectl describe deployment web-app` shows the full configuration and current state of the Deployment (e.g., replicas, conditions), but it does not actively track or report the progress of an ongoing rollout. Option C is wrong because `kubectl status deployment web-app` is not a valid kubectl command; the correct subcommand for viewing rollout progress is `rollout status`.

Full explanation →

221

MCQeasy

You need to create a ConfigMap named 'app-config' with key 'APP_COLOR' and value 'blue'. Which command creates this ConfigMap?

A.kubectl create configmap app-config --from-env-file=APP_COLOR=blue

B.kubectl create configmap app-config --from-literal=APP_COLOR=blue

C.kubectl create configmap app-config --from-literal=APP_COLOR:blue

D.kubectl create configmap app-config --from-file=APP_COLOR=blue

AnswerB

This is the correct command because --from-literal directly accepts an inline key=value pair and stores it as a single data entry in the ConfigMap. The syntax --from-literal=APP_COLOR=blue precisely defines the key as APP_COLOR and the value as blue, with no filesystem involvement. kubectl then creates the ConfigMap with the specified name 'app-config' containing this literal.

Why this answer

`kubectl create configmap app-config --from-literal=APP_COLOR=blue` uses the `--from-literal` flag, which directly creates a ConfigMap entry from a key-value pair specified in the command line. The syntax `key=value` is required for literal data, and this command correctly maps the key 'APP_COLOR' to the value 'blue'.

Exam trap

The trap here is confusing the `--from-literal` syntax (which requires `=`) with the colon-based syntax used in YAML or environment files, leading candidates to incorrectly choose Option C.

How to eliminate wrong answers

Option A is wrong because `--from-env-file` expects a path to a file containing environment variables in `key=value` format, not a literal key-value pair; using `--from-env-file=APP_COLOR=blue` would attempt to read a file named 'APP_COLOR=blue', which does not exist. Option C is wrong because `--from-literal` requires the `=` sign to separate key and value, not a colon (`:`); using a colon would be interpreted as part of the key name, resulting in a key like 'APP_COLOR:blue' with an empty value. Option D is wrong because `--from-file` expects a file path or a file with a key specified as `key=filepath`, not a literal value; `--from-file=APP_COLOR=blue` would try to read a file named 'blue' and assign its contents to the key 'APP_COLOR', which is not the intended behavior.

Full explanation →

222

MCQhard

A pod's container has securityContext with runAsNonRoot: true but no runAsUser set. The container image has a user 'appuser' with UID 1001. Will the pod run successfully?

A.No, because runAsNonRoot requires an explicit runAsUser

B.No, because the container image user is unknown

C.Yes, because runAsNonRoot is ignored if runAsUser is not set

D.Yes, because the container image user is non-root

AnswerD

This is correct because the container image sets a non-root default user (UID 1001) in its metadata. With runAsNonRoot: true and no explicit runAsUser in the securityContext, the kubelet verifies that the image's effective UID is not 0; since 1001 is non-root, the container is permitted to run. The flag acts as a guard that confirms the actual user the container will run as is safe.

Why this answer

When `runAsNonRoot: true` is set in the pod's security context without an explicit `runAsUser`, Kubernetes checks the container image's user (as defined in the Dockerfile `USER` directive). If that user is non-root (UID 1001 in this case), the container runs as that user, satisfying the non-root requirement. The pod will start successfully because the image user is non-root, and no explicit `runAsUser` is required.

Exam trap

CNCF often tests the misconception that `runAsNonRoot` requires an explicit `runAsUser` field, but the correct behavior is that Kubernetes falls back to the container image's user if no `runAsUser` is set.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot` does not require an explicit `runAsUser`; it can rely on the container image's user if it is non-root. Option B is wrong because the container image user is known (UID 1001) and is non-root, so the pod will run successfully. Option C is wrong because `runAsNonRoot` is not ignored when `runAsUser` is not set; it validates the container image's user instead.

Full explanation →

223

MCQhard

A pod is failing to start with error 'container has runAsNonRoot and image will run as root'. The container image runs as root. Which change allows the pod to run?

A.Remove runAsNonRoot: true from securityContext

B.Add fsGroup: 1000

C.Set allowPrivilegeEscalation: false

D.Set runAsUser to a non-zero UID, e.g., 1000

AnswerD

Setting runAsUser to a non-zero UID (e.g., 1000) explicitly overrides the user ID with which the container's main process runs. When runAsNonRoot: true is set, Kubernetes admission (and the container runtime) verifies that the resulting effective UID is non-zero, so a UID of 1000 satisfies the check. This is the correct fix because it keeps the security safeguard while ensuring the container actually runs as a non-root user, avoiding the immediate error and complying with best practices for container security.

Why this answer

The error 'container has runAsNonRoot and image will run as root' indicates that the pod's securityContext has runAsNonRoot: true, but the container image runs as root (UID 0). To satisfy the runAsNonRoot constraint, you must override the container's user to a non-zero UID by setting runAsUser to a non-zero value (e.g., 1000). This forces the container to run as a non-root user, resolving the conflict.

Exam trap

The trap here is that candidates mistakenly think removing runAsNonRoot (Option A) is the fix, but the exam tests that you must satisfy the security constraint by changing the user, not disabling the check.

How to eliminate wrong answers

Option A is wrong because removing runAsNonRoot: true would bypass the security requirement but does not address the root cause; the image still runs as root, which may violate security policies. Option B is wrong because fsGroup sets the group ID for volume ownership, not the user ID the container runs as, and does not change the effective UID from root. Option C is wrong because allowPrivilegeEscalation: false controls whether a process can gain more privileges than its parent, but it does not change the user the container runs as; the container would still start as root, triggering the same error.

Full explanation →

224

Multi-Selectmedium

Which of the following are valid methods to perform a blue-green deployment? (Choose TWO)

Select 2 answers

A.Create two Deployments for blue and green, and update the Service selector to point to the new version

B.Create a single Deployment and update the pod labels to match the Service selector

C.Use a single Deployment and change the container image, then perform a rolling update

D.Use an Ingress resource to route traffic to different Services, each backing a different version

E.Delete the old Deployment and create a new one

AnswersA, D

Two parallel Deployments let you validate the green version fully before cutover, and switching the Service selector redirects all traffic atomically without recreating pods. This satisfies the requirement for an instant, reversible switch between versions.

Why this answer

Option A is correct because a classic Kubernetes blue-green deployment runs two separate Deployments (blue and green) simultaneously, each with its own pod labels, and the cutover is performed by editing the Service's spec.selector to match the new version's labels, instantly redirecting traffic without downtime. Option D is correct because an Ingress resource can define rules that route requests to different backend Services, each fronting a different version of the app; switching the Ingress rule (or using weighted/canary annotations) shifts traffic from the blue Service to the green Service, achieving the same atomic cutover at layer 7. Option B is invalid because mutating pod labels on a single Deployment to match the Service selector does not create a parallel green environment and would cause the Service to lose its endpoints during the change, not a controlled blue-green switch.

Option C describes a standard rolling update of one Deployment, which gradually replaces pods rather than maintaining two distinct environments. Option E is not blue-green because deleting the old Deployment before creating the new one causes downtime and provides no instant rollback path.

Exam trap

CKAD often tests the misconception that a rolling update or a single Deployment with label changes constitutes blue-green, when true blue-green requires two distinct environments and a traffic-switching mechanism.

Full explanation →

225

MCQhard

You have a Deployment with multiple replicas. You want to expose it via a Service that has a stable IP address and is accessible from outside the cluster on a static port on each node. Which Service type should you use?

A.NodePort

B.LoadBalancer

C.ClusterIP

D.ExternalName

AnswerA

A NodePort Service allocates a static port in the 30000–32767 range on every cluster node, forwarding traffic to the Pods. This satisfies the requirement for a stable, externally accessible IP address on a static port per node, without needing a cloud load balancer. The mechanism maps the node’s IP and that port directly to the Service’s cluster IP, enabling external access from outside the cluster.

Why this answer

A NodePort Service type exposes the application on a static port (in the range 30000-32767) on every node's IP address, making it accessible from outside the cluster. This satisfies the requirement for a stable IP (the node's IP) and a static port on each node, while also providing a stable ClusterIP for internal use.

Exam trap

The trap here is that candidates often choose LoadBalancer thinking it is required for external access, but NodePort suffices when the requirement is only a static port on each node, not a cloud-managed public IP.

How to eliminate wrong answers

Option B (LoadBalancer) is wrong because it relies on an external cloud provider's load balancer to provide a public IP, which is not guaranteed to be a static port on each node and is not required for the given scenario. Option C (ClusterIP) is wrong because it is only reachable from within the cluster, not from outside. Option D (ExternalName) is wrong because it maps a Service to an external DNS name via CNAME records and does not expose any ports or provide a stable cluster IP.

Full explanation →

Certified Kubernetes Application Developer CKAD (CKAD) — Questions 151–225