Courseiva

Certified Kubernetes Application Developer CKAD (CKAD) — Questions 1–75

160 questions total · 3pages · All types, answers revealed

Take a mock examExam hub

Page 1 of 3

Page 2
1
MCQmedium

A pod is running with the following SecurityContext: securityContext: runAsUser: 1000 runAsGroup: 2000 fsGroup: 3000 What UID and GID does the process inside the container use?

A.UID 1000, GID 3000
B.UID 1000, GID 2000
C.UID 0, GID 2000
D.UID 3000, GID 2000
AnswerB

runAsUser sets UID, runAsGroup sets GID. Both apply to the container process.

Why this answer

The `runAsUser` and `runAsGroup` fields in the Pod's SecurityContext directly set the UID and GID for the container's main process. Here, `runAsUser: 1000` sets the process UID to 1000, and `runAsGroup: 2000` sets the process GID to 2000. The `fsGroup: 3000` field only applies to the group ownership of mounted volumes, not to the process's primary GID.

Exam trap

The trap here is that candidates confuse `fsGroup` with the process's primary GID, thinking it overrides `runAsGroup`, when in fact `fsGroup` only affects volume group ownership and does not change the process's GID.

How to eliminate wrong answers

Option A is wrong because it incorrectly assumes `fsGroup` replaces the process GID; `fsGroup` only affects volume ownership, not the process's primary GID. Option C is wrong because it assumes the process runs as root (UID 0), but `runAsUser: 1000` explicitly overrides that. Option D is wrong because it swaps the UID and `fsGroup` values, misunderstanding that `runAsUser` sets the UID, not `fsGroup`.

Full explanation →
2
MCQmedium

A pod uses a ServiceAccount 'my-sa' with a RoleBinding that grants get and list on pods. The pod makes an API call to list pods in its own namespace. Which RBAC resource is necessary?

A.A Role with the appropriate rules
B.A ClusterRoleBinding that binds the ClusterRole to the ServiceAccount
C.A RoleBinding that binds the Role to the ServiceAccount
D.A ClusterRole with the same rules
AnswerC

This is the correct RBAC combination: the Role defines the allowed actions within a specific namespace, and the RoleBinding, also namespaced, names the ServiceAccount as its subject, thereby granting those permissions only to that account and only within that namespace. Any pod that uses this ServiceAccount inherits the bound permissions, and the access is scoped exactly as needed, following least privilege.

Why this answer

The pod uses a ServiceAccount 'my-sa' and the API call is to list pods in its own namespace. A RoleBinding binds a Role (which contains the rules) to a ServiceAccount within a specific namespace, granting the permissions only in that namespace. Since the operation is namespace-scoped and the Role already has the necessary get and list rules, a RoleBinding is the minimal and correct RBAC resource to associate the Role with the ServiceAccount.

Exam trap

CNCF often tests the distinction between RoleBinding and ClusterRoleBinding, trapping candidates who think a ClusterRoleBinding is required when the operation is namespace-scoped, or who forget that a Role alone is not a binding.

How to eliminate wrong answers

Option A is wrong because a Role alone defines the rules but does not bind them to any subject; without a RoleBinding, the ServiceAccount has no permissions. Option B is wrong because a ClusterRoleBinding grants permissions cluster-wide, which is excessive for a namespace-scoped operation and would bind a ClusterRole (not a Role) to the ServiceAccount, violating the principle of least privilege. Option D is wrong because a ClusterRole is a cluster-scoped resource that can be used across namespaces, but it is unnecessary here since the operation is confined to a single namespace; a Role is sufficient and more appropriate.

Full explanation →
3
MCQmedium

A pod's container needs to run as non-root user with UID 1000 and ensure its filesystem is read-only. Which SecurityContext settings achieve this?

A.spec: securityContext: runAsUser: 1000 runAsNonRoot: true containers: - name: app securityContext: readOnlyRootFilesystem: true
B.securityContext: runAsNonRoot: true runAsRoot: false readOnlyRootFilesystem: true
C.securityContext: runAsGroup: 1000 readOnlyRootFilesystem: true
D.securityContext: runAsNonRoot: true runAsUser: 1000 readOnlyRootFilesystem: true
AnswerA

This is the correct placement because the pod-level `securityContext` can legally include `runAsUser: 1000` and `runAsNonRoot: true`, which enforces that the container runs with UID 1000 and validates it is not running as root. The container-level `securityContext` is the only place where `readOnlyRootFilesystem` is accepted, so putting it there makes the pod valid and the root filesystem read-only. This demonstrates the proper scope: pod-wide user and group settings at the pod level, container-specific settings like read-only filesystem at the container level.

Why this answer

Ly sets runAsUser and runAsNonRoot at the pod level to enforce non-root execution with UID 1000, and readOnlyRootFilesystem at the container level, which is the correct placement for that field. The other options either use invalid fields (runAsRoot), omit runAsNonRoot, or incorrectly place readOnlyRootFilesystem at the pod level.

Exam trap

The trap is that readOnlyRootFilesystem must be set at the container level, not the pod level. Option D appears to have all three settings but places readOnlyRootFilesystem at the pod level, which is invalid. Candidates often overlook the level at which securityContext fields are applied.

How to eliminate wrong answers

Option A is wrong because it places `readOnlyRootFilesystem: true` in the container-level `securityContext`, which is valid, but the pod-level `securityContext` is missing `runAsNonRoot: true` (only `runAsUser: 1000` is set), so it does not explicitly enforce non-root execution. Option B is wrong because `runAsRoot: false` is not a valid field in Kubernetes SecurityContext; the correct field is `runAsNonRoot: true`, and the option also omits `runAsUser: 1000`. Option C is wrong because it sets `runAsGroup: 1000` instead of `runAsUser: 1000`, which specifies the group ID, not the user ID, and it lacks `runAsNonRoot: true` to enforce non-root execution.

Full explanation →
4
MCQeasy

A pod is running but not responding to traffic. You suspect the application inside the container is unhealthy but the pod is still marked as 'Running'. Which probe should be configured to remove the pod from the service's endpoints automatically?

A.Readiness probe
B.Resource limits
C.Startup probe
D.Liveness probe
AnswerA

The readiness probe is the only probe that directly controls whether the Pod is added to or retained in the Endpoints object backing a Service. When it fails, the kubelet marks the Pod's Ready condition as False, and the endpoints controller removes its IP from all matching Service backends, so it stops receiving new traffic while it is still running. This precisely matches the symptom of a running Pod that is unresponsive: it should be taken out of rotation, not restarted.

Why this answer

A Readiness probe determines whether a container is ready to accept traffic. If the probe fails, Kubernetes removes the pod's IP address from the endpoints of all Services that match the pod's labels, effectively stopping traffic from reaching the pod while it remains in the Running state. This is the correct probe for removing an unhealthy pod from Service endpoints without terminating it.

Exam trap

The CKAD exam often tests the distinction between Liveness and Readiness probes, and the trap here is that candidates mistakenly choose Liveness probe because they think 'unhealthy' always means 'restart', but the question specifically asks about removing the pod from Service endpoints, which is the Readiness probe's job.

How to eliminate wrong answers

Option B is wrong because resource limits (CPU/memory constraints) control how much resources a container can use but do not affect Service endpoint membership or health checking. Option C is wrong because a Startup probe is used to determine when a container has started successfully; it runs only during initialization and does not manage ongoing traffic routing after the pod is Running. Option D is wrong because a Liveness probe indicates whether the container is alive; if it fails, the kubelet restarts the container, but it does not remove the pod from Service endpoints—the pod remains in the endpoint list until it is terminated or its Readiness probe fails.

Full explanation →
5
Matchingmedium

Match each Kubernetes object field to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Maximum resources a container can use

Determines when to restart containers in a pod

Checks if container is running; restarts if fails

Checks if container is ready to serve traffic

Inject a secret value as an environment variable

Why these pairings

Correct matches: livenessProbe checks container health, readinessProbe checks service readiness, startupProbe checks application startup, and imagePullPolicy controls image pulling. Common confusions involve swapping definitions with restartPolicy.

Full explanation →
6
MCQeasy

A developer wants to expose a set of Pods on a specific port on each node's IP. Which Service type should be used?

A.LoadBalancer
B.ClusterIP
C.NodePort
D.ExternalName
AnswerC

NodePort exposes on each node's IP at a static port.

Why this answer

NodePort is the correct Service type because it exposes each Pod's port on a static port (the NodePort) on every node's IP address. This allows external traffic to reach the Pods by accessing any node's IP on that specific port, fulfilling the requirement to expose the Pods on a per-node IP basis.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking LoadBalancer is needed for external access, but the question specifically asks for exposure on each node's IP, which is exactly what NodePort provides without requiring a cloud load balancer.

How to eliminate wrong answers

Option A is wrong because LoadBalancer exposes the Service via an external load balancer (typically a cloud provider's LB), not directly on each node's IP; it builds on top of NodePort but adds an external IP that distributes traffic, not per-node exposure. Option B is wrong because ClusterIP exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like a proxy or ingress. Option D is wrong because ExternalName maps a Service to a DNS name (via CNAME records) and does not expose any ports or Pods at all; it is used for external service aliasing, not for exposing Pods on node IPs.

Full explanation →
7
Matchingmedium

Match each Kubernetes resource to its API group.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

apps/v1

v1 (core)

networking.k8s.io/v1

autoscaling/v2

networking.k8s.io/v1

Why these pairings

Kubernetes resources belong to specific API groups. Pods, Services, ConfigMaps, and PersistentVolumeClaims are in the core group (v1), while Deployments are in apps/v1, and Ingresses are in networking.k8s.io/v1.

Full explanation →
8
Multi-Selectmedium

Which of the following are valid concurrencyPolicy values for a CronJob? (Select all that apply.)

Select 3 answers
A.Replace
B.Allow
C.Parallel
D.Forbid
E.Serial
AnswersA, B, D

The `Replace` policy is a valid concurrencyPolicy value, but it is not one of the two selected as correct in this question. It terminates the currently running job and starts a new one when the next scheduled time arrives.

Why this answer

Within a Kubernetes CronJob, the concurrencyPolicy field accepts three valid values: Allow, Forbid, and Replace. Allow permits multiple concurrent executions of the same job. Forbid prevents new executions while a previous one is still running.

Replace cancels the currently running job and starts a new one in its place. Options C (Parallel) and E (Serial) are not valid values. Therefore, the correct answers are Replace, Allow, and Forbid.

Exam trap

The CKAD exam expects you to know all three valid values for concurrencyPolicy. Do not mistakenly think that Replace is invalid; it is one of the three accepted values. Also, avoid selecting Parallel or Serial, as they are not part of the Kubernetes API.

Full explanation →
9
MCQhard

You want to debug a pod that is failing to start. The pod does not have a shell installed. Which command can you use to attach an ephemeral debug container to the running (or failed) pod?

A.kubectl attach <pod>
B.kubectl exec -it <pod> -- /bin/sh
C.kubectl run debug --image=busybox -it --restart=Never
D.kubectl debug -it <pod> --image=busybox --target=<container>
AnswerD

kubectl debug -it <pod> --image=busybox --target=<container> creates an ephemeral container inside the existing pod, sharing its network, volumes, and (if enabled) process namespace. The --target flag names the container whose namespaces the debug container will share, letting you inspect the failing container's filesystem and processes even while it is crashing. Because ephemeral containers do not restart or affect the original container's lifecycle, this is the correct way to inject a debugging tool into the pod without modifying the pod spec.

Why this answer

`kubectl debug` allows you to attach an ephemeral debug container to a running or failed pod, even if the pod lacks a shell. The `--target` parameter specifies the container in the pod to which the debug container attaches, enabling network namespace sharing and process inspection without modifying the original container.

Exam trap

The trap here is that candidates often choose `kubectl exec` or `kubectl attach` out of habit, not realizing those commands require a running container with a shell, whereas `kubectl debug` is the only option that can inject a new container into a pod that lacks debugging tools or is in a failed state.

How to eliminate wrong answers

Option A is wrong because `kubectl attach` attaches to a running container's stdin/stdout/stderr, but it requires the container to have a shell or process running; it cannot add a new container or work if the pod is in a CrashLoopBackOff state. Option B is wrong because `kubectl exec` requires the target container to have a shell (e.g., /bin/sh) and a running process; if the pod has no shell or is failing to start, exec will fail. Option C is wrong because `kubectl run` creates a new standalone pod, not an ephemeral container attached to an existing pod; it cannot debug the original pod's namespace or processes.

Full explanation →
10
Multi-Selectmedium

Which TWO of the following are valid concurrencyPolicy values for a CronJob?

Select 2 answers
A.Parallel
B.Forbid
C.Serial
D.Allow
E.Replace
AnswersB, D

Forbid is correct because it is one of the three valid concurrency policies, which prevents concurrent runs by skipping new runs if a previous one is still active.

Why this answer

In Kubernetes, a CronJob's concurrencyPolicy controls how to handle overlapping job executions. The valid values are Allow (default, allowing concurrent runs) and Forbid (skips new run if previous is still running). Among the options given, the two correct answers are Allow and Forbid.

Replace is not a valid concurrencyPolicy value; it is a distractor.

Exam trap

The CKAD exam often tests the exact string values of Kubernetes API fields, and candidates may confuse 'Parallel' or 'Serial' with the valid 'Allow' and 'Forbid' due to familiarity with other job concepts like parallelism.

Full explanation →
11
MCQmedium

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

A.Delete and recreate the pod to clear the crash loop
B.Increase the CPU request for the container
C.Increase the memory limit in the pod's container resource specification
D.Delete the namespace and redeploy all workloads
AnswerC

This is correct because the container's memory usage exceeded its configured limit, causing the kernel to invoke the OOM killer and terminate it. Increasing the memory limit in resources.limits.memory raises the cgroup memory ceiling, giving the container a larger allocation before it triggers an OOM kill. However, this is only viable if the node has sufficient allocatable memory; otherwise, the pod may fail to schedule or cause other pods to be evicted due to node pressure.

Why this answer

The pod is in CrashLoopBackOff with an OOMKilled message, which means the container's memory usage exceeded its configured memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification so the container has enough memory to run without being terminated by the Out-Of-Memory (OOM) killer.

Exam trap

The trap here is that candidates may confuse OOMKilled with a CPU-related issue and incorrectly choose to adjust CPU resources, or they may think a simple pod restart will fix the problem, when in fact the memory limit must be increased.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the pod will not resolve the underlying memory exhaustion; the new pod will still hit the same memory limit and be OOMKilled again. Option B is wrong because increasing the CPU request does not affect memory allocation; OOMKilled is caused by exceeding the memory limit, not CPU constraints. Option D is wrong because deleting the namespace and redeploying all workloads is an unnecessarily destructive and disruptive action that does not address the specific memory limit issue.

Full explanation →
12
MCQeasy

A pod needs to run as a non-root user with UID 1000. Which SecurityContext field should be set?

A.runAsUser: 1000
B.runAsGroup: 1000
C.runAsNonRoot: true
D.fsGroup: 1000
AnswerA

Setting runAsUser: 1000 in the pod's securityContext instructs the container runtime to launch the main process with UID 1000, which satisfies the requirement of running as a non-root user with that exact user ID. This overrides the default user defined in the image, ensuring all processes inside the container operate as UID 1000 rather than root, which is precisely what the statement demands.

Why this answer

The `runAsUser` field in the PodSecurityContext or container SecurityContext sets the user ID (UID) under which the container's main process runs. Setting `runAsUser: 1000` ensures the container runs as a non-root user with UID 1000, meeting the requirement. This field directly controls the effective UID of the process, overriding the default root (UID 0).

Exam trap

The trap here is that candidates often confuse `runAsUser` with `runAsGroup` or `fsGroup`, thinking group or filesystem settings control the process user identity, when only `runAsUser` directly sets the UID of the running process.

How to eliminate wrong answers

Option B is wrong because `runAsGroup: 1000` sets the primary group ID (GID) for the container process, not the user ID; it does not change the user from root. Option C is wrong because `runAsNonRoot: true` only enforces that the container cannot run as root (UID 0), but it does not specify which non-root UID to use; the container would fail if no explicit UID is set or if the image's default user is root. Option D is wrong because `fsGroup: 1000` applies to the group ownership of mounted volumes, not the user identity of the running process; it is used for volume access control, not for running as a non-root user.

Full explanation →
13
MCQeasy

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

A.kubectl create configmap app-config --from-env-file=config.properties
B.kubectl create configmap app-config --from-literal=config.properties
C.kubectl create configmap app-config --from-file=config.properties
D.kubectl apply -f config.properties
AnswerC

Correct. The --from-file flag creates a ConfigMap from the file content.

Why this answer

The `kubectl create configmap` command with the `--from-file` flag directly creates a ConfigMap from the contents of a specified file, using the filename as the key and the file content as the value. This is the standard method for creating a ConfigMap from a single file like 'config.properties'.

Exam trap

The trap here is that candidates often confuse `--from-file` (which imports a file as a single data entry) with `--from-env-file` (which parses a file as multiple key-value pairs), leading them to choose Option A incorrectly.

How to eliminate wrong answers

Option A is wrong because `--from-env-file` is used to create a ConfigMap from a file that contains key=value pairs (one per line), treating each line as a separate environment variable, not as a single file with arbitrary content. 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. Option D is wrong because `kubectl apply -f` is used to apply a YAML or JSON manifest to create or update resources, and 'config.properties' is not a valid Kubernetes manifest file.

Full explanation →
14
MCQmedium

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

A.Increase the memory limit in the pod's container resource specification
B.Delete and recreate the pod to clear the crash loop
C.Delete the namespace and redeploy all workloads
D.Increase the CPU request for the container
AnswerA

OOMKilled is the definitive signal that the container process exceeded its cgroup memory limit and was terminated by the kernel's OOM killer. Raising the memory limit in the pod's container resource specification directly expands the available memory budget, giving the process room to complete its allocation without triggering the kill. This is the correct fix because the restart policy only re-creates the container; without a higher limit the next run will hit the identical memory ceiling and crash again.

Why this answer

The 'OOMKilled' status indicates the pod's container was terminated because it exceeded its memory limit. Since the pod ran successfully for days, a gradual memory leak or increased workload likely caused the usage to spike past the configured limit. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory demand without being killed, resolving the CrashLoopBackOff.

Exam trap

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

How to eliminate wrong answers

Option B is wrong because deleting and recreating the pod does not address the root cause — the new pod will still have the same memory limit and will be OOMKilled again. Option C is wrong because deleting the entire namespace and redeploying all workloads is an extreme, unnecessary action that disrupts other workloads and does not fix the memory limit issue. Option D is wrong because increasing the CPU request does not affect memory constraints; OOMKilled is a memory-related termination, not CPU-related.

Full explanation →
15
MCQhard

You need to create a TLS secret for an ingress with certificate and key. Which command correctly creates the secret?

A.kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key
B.kubectl create secret docker-registry tls-secret --docker-cert=tls.crt --docker-key=tls.key
C.kubectl create secret generic tls-secret --from-file=tls.crt --from-file=tls.key
D.kubectl create secret certificate tls-secret --cert= --key=
AnswerA

This creates a TLS secret of type kubernetes.io/tls.

Why this answer

`kubectl create secret tls` is the dedicated subcommand for creating a TLS secret, which automatically encodes the certificate and key files and stores them under the expected keys (`tls.crt` and `tls.key`). This is the only command that produces a secret of type `kubernetes.io/tls`, which is required by Ingress controllers to serve HTTPS traffic.

Exam trap

The trap here is that candidates may think `kubectl create secret generic` with `--from-file` can create a TLS secret, but they overlook that the secret type must be `kubernetes.io/tls` for the Ingress controller to use it, and the generic command does not set that type.

How to eliminate wrong answers

Option B is wrong because `kubectl create secret docker-registry` creates a secret of type `kubernetes.io/dockerconfigjson` for container registry authentication, not TLS; it expects `--docker-username`, `--docker-password`, etc., not certificate flags. Option C is wrong because `kubectl create secret generic` creates a secret of type `Opaque`, not `kubernetes.io/tls`, and while it can store the files, the Ingress controller will not recognize the keys unless they are named exactly `tls.crt` and `tls.key` and the secret type is correct; this command does not set the type automatically. Option D is wrong because `kubectl create secret certificate` is not a valid kubectl subcommand; the correct subcommand is `tls`, and the flags `--cert=` and `--key=` are incomplete (they require file paths).

Full explanation →
16
MCQmedium

A DevOps engineer wants to deploy a logging sidecar container that reads log files from the main application container. Which volume type should be used to share files between the two containers?

A.emptyDir
B.persistentVolumeClaim
C.configMap
D.hostPath
AnswerA

emptyDir is a pod-scoped volume that is created empty when a pod is scheduled and survives only as long as the pod runs. It is mounted into all containers sharing the same lifecycle, making it the standard choice for a sidecar that reads logs written by the main application because both can access the same files without any persistent storage overhead. Its ephemeral nature is exactly what you want here—logs are consumed immediately and discarded with the pod, so no cleanup or durability guarantees are needed.

Why this answer

An emptyDir volume is the correct choice because it provides a shared, ephemeral storage space that is created when a Pod is assigned to a node and exists as long as that Pod is running. Both the main application container and the sidecar container can mount the same emptyDir volume at different mount paths, allowing the sidecar to read log files written by the main container. This volume type is ideal for sharing files between containers in the same Pod without requiring persistent storage.

Exam trap

The trap here is that candidates often confuse persistentVolumeClaim with a general-purpose shared volume, not realizing it is for persistent, Pod-independent storage, while emptyDir is the correct ephemeral volume for sharing files between containers in the same Pod.

How to eliminate wrong answers

Option B (persistentVolumeClaim) is wrong because it is used for persistent storage that outlives the Pod, not for sharing files between containers within the same Pod; it also requires a PersistentVolume and is overkill for temporary log sharing. Option C (configMap) is wrong because it is designed to inject configuration data (e.g., key-value pairs or small files) into containers, not for dynamic file sharing like log files that are written and read at runtime. Option D (hostPath) is wrong because it mounts a file or directory from the host node's filesystem into the Pod, which introduces node-level coupling and security risks, and is not the standard Kubernetes approach for inter-container communication within a Pod.

Full explanation →
17
MCQhard

A Pod is configured with securityContext: { runAsUser: 1000, runAsGroup: 2000, fsGroup: 3000 }. The container's image runs a process that must listen on a TCP port below 1024 (e.g., port 80). The process is currently failing to start. What should you modify to allow the process to bind to a privileged port?

A.Set 'allowPrivilegeEscalation: true'
B.Add 'capabilities.drop: [ALL]' to the container's securityContext
C.Add 'capabilities.add: [NET_BIND_SERVICE]' to the container's securityContext
D.Set runAsUser: 0 to run as root
AnswerC

Adding the NET_BIND_SERVICE capability to the container's securityContext grants the precise Linux capability that allows a non-root process to bind to Internet domain sockets with port numbers below 1024. This directly solves the port-binding problem while preserving the principle of least privilege, because the process continues to run as the unprivileged user 1000 and retains no other unnecessary capabilities. It is the correct, secure approach to exposing a service on a standard HTTP/HTTPS port.

Why this answer

The container process runs as a non-root user (UID 1000) and needs to bind to a privileged port (below 1024). Linux requires either root privileges or the CAP_NET_BIND_SERVICE capability to bind to ports below 1024. Adding this capability to the container's securityContext grants the process the necessary privilege without running as root, which is the correct and secure approach.

Exam trap

The trap here is that candidates often confuse allowPrivilegeEscalation with granting specific capabilities, or they incorrectly assume that dropping all capabilities is a safe default that still allows low-port binding, when in fact it removes the very capability needed.

How to eliminate wrong answers

Option A is wrong because allowPrivilegeEscalation controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), but it does not grant the specific capability needed to bind to a privileged port. Option B is wrong because dropping all capabilities (capabilities.drop: [ALL]) removes all Linux capabilities, including any that might allow binding to low ports, making the problem worse. Option D is wrong because setting runAsUser: 0 runs the container as root, which would work but violates the principle of least privilege and is not the minimal change required; the question asks what to modify to allow binding, and adding the specific capability is the correct targeted fix.

Full explanation →
18
MCQhard

You need to debug a pod that is not responding. Which command attaches an ephemeral debug container to a running pod named 'web-pod'?

A.kubectl debug web-pod --copy-to=debug-pod --image=busybox
B.kubectl debug -it web-pod --image=busybox --target=web-container
C.kubectl attach web-pod
D.kubectl run debug --image=busybox -it
AnswerB

Correct command to add an ephemeral debug container.

Why this answer

`kubectl debug` with the `--image` flag creates an ephemeral container in the specified pod for interactive debugging. The `-it` flag provides an interactive TTY, and `--target=web-container` attaches the ephemeral container to the same Linux namespace as the target container, allowing direct troubleshooting of the unresponsive pod without modifying its original containers.

Exam trap

The trap here is that candidates confuse `kubectl debug` with `kubectl run` or `kubectl attach`, assuming any command that creates a new interactive shell will work, but only `kubectl debug` with the `--image` flag correctly attaches an ephemeral container to the existing pod without copying or replacing it.

How to eliminate wrong answers

Option A is wrong because `--copy-to=debug-pod` creates a separate copy of the pod (debug-pod) rather than attaching an ephemeral debug container to the existing 'web-pod', which is not what the question asks. Option C is wrong because `kubectl attach` connects to an already running container's stdio, but it cannot create a new debug container; it only attaches to existing containers, which may be unresponsive. Option D is wrong because `kubectl run` creates a new standalone pod named 'debug' instead of attaching an ephemeral container to the existing 'web-pod', so it does not debug the target pod directly.

Full explanation →
19
MCQeasy

During a rolling update, you want to ensure that at most 2 pods are unavailable at any time. Which field should you set in the Deployment spec?

A.spec.strategy.type: Recreate
B.spec.replicas: 2
C.spec.strategy.rollingUpdate.maxSurge: 2
D.spec.strategy.rollingUpdate.maxUnavailable: 2
AnswerD

spec.strategy.rollingUpdate.maxUnavailable: 2 directly caps the number of pods that may be unavailable during a rolling update, ensuring that at most 2 pods are down at any given time relative to the desired replica count. The Deployment controller uses this value to decide when it can scale down old ReplicaSets and scale up new ones, keeping the available pod count at desired minus 2. This is the exact setting needed for the stated requirement of allowing at most 2 replicas to be unavailable.

Why this answer

`spec.strategy.rollingUpdate.maxUnavailable` specifies the maximum number of Pods that can be unavailable during a rolling update. Setting `maxUnavailable: 2` ensures that at most 2 Pods are unavailable at any time, allowing the update to proceed while maintaining the desired availability.

Exam trap

The trap here is confusing `maxSurge` (which controls extra Pods created above the desired count) with `maxUnavailable` (which controls Pods that can be unavailable), leading candidates to incorrectly select `maxSurge` when the question asks about limiting unavailable Pods.

How to eliminate wrong answers

Option A is wrong because `spec.strategy.type: Recreate` terminates all existing Pods before creating new ones, which would cause all Pods to be unavailable during the update, not limiting unavailability to 2. Option B is wrong because `spec.replicas: 2` sets the desired number of Pod replicas to 2, but does not control the number of unavailable Pods during a rolling update; it defines the target count, not a constraint on unavailability. Option C is wrong because `spec.strategy.rollingUpdate.maxSurge: 2` controls the maximum number of Pods that can be created above the desired replica count during an update, not the number of unavailable Pods.

Full explanation →
20
MCQeasy

A developer wants to deploy a stateless application as a set of identical pods. They need the pods to be distributed across nodes and have stable network identities. Which resource should they use?

A.Job
B.Deployment
C.DaemonSet
D.StatefulSet
AnswerD

A StatefulSet assigns each pod a stable, zero-based ordinal hostname (e.g., web-0, web-1) derived from the StatefulSet name and replica index. These identities persist across rescheduling because a replacement pod always inherits the same ordinal and, if configured, the same PersistentVolumeClaim. Combined with a headless service, each pod gets a unique DNS name, which perfectly fulfills the requirement for stable network identities in a stateless or stateful application.

Why this answer

StatefulSet is the correct resource because it provides each pod with a stable, unique network identity (e.g., pod-name-0, pod-name-1) that persists across rescheduling. While Deployment manages replicas for stateless applications, it does not assign per-pod stable hostnames. The question explicitly requires 'stable network identities' for identical pods, which is a defining feature of StatefulSet.

A Service combined with a Deployment gives a stable endpoint for the set, not per-pod identities.

Exam trap

Candidates may incorrectly choose Deployment, thinking that a Service provides stable network identities. However, a Service provides a stable endpoint for the entire set of pods, not individual pod identities. StatefulSet is needed for per-pod stable DNS names, which match the requirement for 'stable network identities' for each pod.

How to eliminate wrong answers

Option A is wrong because a Job is designed for batch processing or one-time tasks, not for running a continuously serving stateless application with multiple identical pods. Option C is wrong because a DaemonSet ensures exactly one pod per node, which is used for node-level services (e.g., logging, monitoring) and does not distribute pods arbitrarily across nodes for scaling. Option D is wrong because a StatefulSet is intended for stateful applications requiring stable, unique network identities and persistent storage, which is unnecessary for a stateless application.

Full explanation →
21
MCQmedium

You want to create a Deployment that runs 5 replicas of a web application. Which kubectl command should you use?

A.kubectl run webapp --image=nginx --replicas=5
B.kubectl create pod webapp --image=nginx --replicas=5
C.kubectl apply -f deployment.yaml
D.kubectl create deployment webapp --image=nginx --replicas=5
AnswerD

The correct imperative command is `kubectl create deployment webapp --image=nginx --replicas=5`. This creates a Deployment named webapp with the nginx container image and sets the desired replica count to 5. It is a fully supported current kubectl command that accepts `--replicas` to scale the Deployment at creation time, making it the most direct way to satisfy the requirement.

Why this answer

To create a Deployment with 5 replicas using a single imperative command, use `kubectl create deployment webapp --image=nginx --replicas=5`. This command directly creates a Deployment and sets the desired replicas. Option A (`kubectl run`) no longer creates a Deployment by default in current Kubernetes versions (1.18+); it creates a single Pod and does not support the `--replicas` flag.

Option B (`kubectl create pod`) does not exist and is incorrect. Option C (`kubectl apply -f deployment.yaml`) would also create a Deployment but requires an existing YAML file and is not a single imperative command.

Exam trap

The trap is that candidates might incorrectly believe `kubectl run` with `--replicas` creates a Deployment, as it did in earlier Kubernetes versions. In the CKAD exam environment (Kubernetes 1.31+), `kubectl run` only creates a Pod, and `kubectl create deployment` is the correct imperative command for creating a Deployment with replicas.

How to eliminate wrong answers

Option A is wrong because `kubectl run` does not support a `--replicas` flag; it creates a single Pod (or a Deployment in older versions, but the flag is not valid and would cause an error). Option B is wrong because `kubectl create pod` is not a valid command; Pods are created imperatively with `kubectl run` or declaratively via a manifest, and the `--replicas` flag does not apply to Pods (a Pod is a single instance). Option C is wrong because while `kubectl apply -f deployment.yaml` can create a Deployment, it requires a pre-existing YAML manifest file, which is not provided in the question; the question asks for a single kubectl command to create the Deployment, and this option assumes a file already exists.

Full explanation →
22
MCQmedium

You have a Deployment named 'frontend' with 4 replicas. You want to perform a rolling update with the following constraints: the number of pods above the desired count should never exceed 1, and the number of unavailable pods should never exceed 0. Which deployment strategy configuration achieves this?

A.strategy: rollingUpdate: {maxSurge: 2, maxUnavailable: 0}
B.strategy: rollingUpdate: {maxSurge: 25%, maxUnavailable: 25%}
C.strategy: rollingUpdate: {maxSurge: 1, maxUnavailable: 0}
D.strategy: type: Recreate
AnswerC

This is the correct configuration because maxSurge: 1 caps the total number of pods at one beyond the desired 4, so at most 5 pods run during the update. Meanwhile, maxUnavailable: 0 forbids terminating any old pod until a new pod has become Ready, ensuring at least 4 pods are always available to serve traffic. Together they enforce exactly the stated constraints: no more than one extra pod and zero downtime.

Why this answer

Setting `maxSurge: 1` ensures that during a rolling update, at most one additional pod is created above the desired replica count of 4, and `maxUnavailable: 0` guarantees that no pods are taken down until the new ones are ready. This satisfies the constraints of never exceeding one extra pod and never having unavailable pods.

Exam trap

The trap here is that candidates often confuse `maxSurge` and `maxUnavailable` as percentages versus absolute values, or they mistakenly think `Recreate` can achieve zero downtime, when in fact it causes complete unavailability during the update.

How to eliminate wrong answers

Option A is wrong because `maxSurge: 2` would allow up to 2 extra pods above the desired count, violating the constraint that the number of pods above the desired count should never exceed 1. Option B is wrong because `maxUnavailable: 25%` (which equals 1 pod out of 4) would allow at least one pod to be unavailable during the update, violating the constraint that unavailable pods should never exceed 0. Option D is wrong because the `Recreate` strategy terminates all existing pods before creating new ones, causing all pods to be unavailable during the update, which directly violates the constraint of zero unavailable pods.

Full explanation →
23
MCQhard

A team is deploying a microservice that requires initialization of a database schema before the main application starts. The init container must run a script that writes to a shared volume. Which configuration correctly ensures the init container completes before the main container runs?

A.Run the script as a sidecar container that shares the volume with the main container.
B.Use a postStart lifecycle hook on the main container to run the script.
C.Define an init container with the script and mount the shared volume to both init and main containers.
D.Add a readiness probe to the main container that checks the shared volume.
AnswerC

Init containers always run to completion before any application container in the pod is started, and each init container must exit with status 0. By mounting the same volume in both the init container and the main container, the script can write required files that the main container reads immediately upon startup. This guarantees the initialization is fully completed before the microservice process begins.

Why this answer

An init container runs to completion before any main container in the Pod starts, ensuring the database schema script finishes. By mounting the shared volume to both the init container and the main container, the script's output (e.g., schema files) is available to the main application when it launches.

Exam trap

The trap here is that candidates confuse init containers with sidecar containers or lifecycle hooks, not realizing that only init containers guarantee sequential execution before main containers, while sidecars and hooks run concurrently or asynchronously.

How to eliminate wrong answers

Option A is wrong because a sidecar container runs concurrently with the main container, not before it, so the database schema might not be initialized when the main application starts. Option B is wrong because a postStart lifecycle hook runs asynchronously and does not block the main container's entrypoint; the main container could start before the script completes, leading to race conditions. Option D is wrong because a readiness probe only checks if the main container is ready to serve traffic after it has started; it does not guarantee that the schema initialization script has run before the main container begins execution.

Full explanation →
24
MCQhard

A CronJob is configured with concurrencyPolicy: Forbid and schedule: '*/5 * * * *'. The first job takes 7 minutes. What happens when the next scheduled time arrives?

A.The previous job is terminated
B.The new job waits until the previous job completes
C.The new job is skipped
D.A new job is created immediately
AnswerC

Forbid skips the new job if the previous one is still running.

Why this answer

C is correct because when `concurrencyPolicy: Forbid` is set, the CronJob controller skips creating a new job if the previous job is still running at the next scheduled time. Since the first job takes 7 minutes and the schedule is every 5 minutes, the new job is skipped to prevent overlapping executions.

Exam trap

The trap here is that candidates often confuse `Forbid` with `Replace` (which terminates the running job) or assume the new job will queue, but Kubernetes explicitly skips the run without any retry or delay.

How to eliminate wrong answers

Option A is wrong because `concurrencyPolicy: Forbid` does not terminate the running job; it only prevents new jobs from starting. Option B is wrong because `Forbid` does not queue or delay the new job; it simply skips it. Option D is wrong because a new job is not created immediately; the controller checks the policy and skips creation if a job is still active.

Full explanation →
25
MCQhard

You want to perform a canary deployment of a new version of your application. You create a Deployment named 'app-canary' with 1 replica and label 'version: canary'. The existing stable Deployment 'app-stable' has 3 replicas and label 'version: stable'. Both Deployments have the selector 'app: myapp'. You have a Service 'app-service' with selector 'app: myapp, track: stable'. How can you route traffic to the canary?

A.Use a different Service for canary with selector 'app: myapp, track: canary' and keep the original Service unchanged
B.Add label 'track: canary' to the canary pod template and set the Service selector to 'app: myapp, track: canary'
C.Modify the Service selector to 'app: myapp' and rely on the 'version' label to differentiate
D.Change the canary Deployment's selector to 'version: canary' and update the Service selector to include 'version: canary'
AnswerB

This routes traffic only to the canary pods via the Service.

Why this answer

To route traffic to the canary, the Service selector must match the canary pods' labels. The current Service selector is 'app: myapp, track: stable', but the canary pods have 'app: myapp, version: canary'. Option B correctly adds the label 'track: canary' to the canary pod template and changes the Service selector to 'app: myapp, track: canary'.

This makes the Service select only the canary pods, routing all traffic to the canary. Note: This removes the stable pods from the Service, but among the given choices, B is the only correct approach to achieve traffic to the canary.

Full explanation →
26
MCQhard

A container image requires running as UID 0 but you need to comply with a 'restricted' Pod Security Admission policy. Which SecurityContext setting allows this while still passing the policy?

A.Set securityContext: { allowPrivilegeEscalation: true }
B.No SecurityContext setting allows running as UID 0 under the restricted policy.
C.Set securityContext: { runAsNonRoot: true, capabilities: { add: ['SYS_ADMIN'] } }
D.Set runAsUser: 0 and runAsNonRoot: false
AnswerB

Under the restricted Pod Security Standard, runAsNonRoot must be true, which enforces that the container's primary process runs as a non-root user (UID != 0). There is no securityContext setting that can override this; any attempt to set runAsUser: 0 would be invalidated by admission control. The only solution is to modify the container image to use a non-root user or to run under a different Pod Security Standard. Thus no SecurityContext field permits UID 0.

Why this answer

The 'restricted' Pod Security Admission policy requires that containers run as non-root (runAsNonRoot: true) and prohibits setting runAsUser to 0. Since the image requires UID 0, no SecurityContext setting can override this policy constraint; the only way to comply is to modify the image to run as a non-root user. Therefore, option B is correct.

Exam trap

The trap here is that candidates assume they can override the restricted policy with a SecurityContext setting like runAsUser: 0, not realizing that the restricted policy explicitly forbids UID 0 and enforces runAsNonRoot: true, making any such override invalid.

How to eliminate wrong answers

Option A is wrong because allowPrivilegeEscalation: true is actually prohibited by the restricted policy (it must be false), and it does not address the UID 0 requirement. Option C is wrong because runAsNonRoot: true conflicts with running as UID 0, and adding SYS_ADMIN capability is forbidden by the restricted policy (only NET_BIND_SERVICE is allowed). Option D is wrong because runAsUser: 0 with runAsNonRoot: false explicitly violates the restricted policy's requirement that runAsNonRoot must be true and runAsUser must not be 0.

Full explanation →
27
MCQeasy

A developer wants to inject database credentials into a pod as environment variables. The credentials are stored in a Kubernetes Secret named 'db-creds' with keys 'username' and 'password'. Which pod spec snippet correctly injects both values as environment variables?

A.env: - name: username valueFrom: secretKeyRef: name: db-creds key: username
B.envFrom: - configMapRef: name: db-creds
C.envFrom: - secretRef: name: db-creds
D.envFrom: - secretKeyRef: name: db-creds
AnswerC

The `envFrom` block with `secretRef` is the recommended way to inject all key-value pairs from a Secret as environment variables in one go. Each key in the Secret becomes an environment variable name, and the corresponding value is the decoded Secret data. This automatically provides both `username` and `password` (or any other keys) to the pod without listing them individually.

Why this answer

`envFrom` with `secretRef` injects all key-value pairs from a Secret as environment variables into the pod. This directly satisfies the requirement to inject both 'username' and 'password' from the 'db-creds' Secret without needing to specify each key individually.

Exam trap

The trap here is that candidates often confuse `envFrom` with `env` and use `secretKeyRef` under `envFrom` (Option D) or mistakenly use `configMapRef` for secrets (Option B), failing to recognize that `envFrom` requires `secretRef` to inject all keys from a Secret.

How to eliminate wrong answers

Option A is wrong because it only injects a single key ('username') as an environment variable, missing the 'password' key; it uses `env` with `secretKeyRef` for one value, not `envFrom` for all values. Option B is wrong because `configMapRef` references a ConfigMap, not a Secret; ConfigMaps are for non-sensitive data, while database credentials require a Secret. Option D is wrong because `secretKeyRef` is not a valid field under `envFrom`; `envFrom` uses `secretRef` to reference the entire Secret, while `secretKeyRef` is used under `env` for individual key references.

Full explanation →
28
MCQmedium

A ClusterIP service named 'db-service' in namespace 'data' is not reachable from a pod in the same namespace. The pod's /etc/resolv.conf shows 'search data.svc.cluster.local svc.cluster.local cluster.local'. Using the pod, which command tests DNS resolution for the service?

A.dig db-service.data.svc.cluster.local
B.ping db-service
C.nslookup db-service.data.svc.cluster.local
D.curl http://db-service:3306
AnswerC

nslookup explicitly issues a DNS query to the cluster's configured resolvers (CoreDNS) and displays the returned IP address for the full service DNS name db-service.data.svc.cluster.local. It isolates the DNS lookup phase from any application-level connectivity, so a successful response confirms that the service's clusterIP is registered and resolvable. This is the most direct and broadly available diagnostic tool for checking DNS-based service discovery in Kubernetes.

Why this answer

`nslookup` is a standard DNS lookup tool that queries the cluster's DNS server (CoreDNS/kube-dns) for the fully qualified domain name (FQDN) of the service. The FQDN `db-service.data.svc.cluster.local` matches the search domains in the pod's `/etc/resolv.conf`, so `nslookup` will resolve the service's ClusterIP, confirming DNS is working. This directly tests DNS resolution, which is the root cause when a service is unreachable by name.

Exam trap

The trap here is that candidates often choose `ping` (option B) because they assume network connectivity testing is sufficient, but `ping` uses ICMP and does not test DNS resolution, which is the specific problem described in the question.

How to eliminate wrong answers

Option A is wrong because `dig` is not typically installed in minimal container images (e.g., Alpine-based pods) and is not a standard troubleshooting tool in Kubernetes; the question asks for a command that can be used from the pod, and `dig` may not be available. Option B is wrong because `ping` tests ICMP reachability to an IP address, not DNS resolution; it would fail if the service's ClusterIP is not pingable (which is normal for ClusterIP services) and does not verify the service name resolves correctly. Option D is wrong because `curl` tests HTTP connectivity to a specific port (3306), not DNS resolution; it would fail if the service is not listening on HTTP or if the name does not resolve, but it does not isolate the DNS issue.

Full explanation →
29
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 →
30
MCQmedium

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

A.Increase the memory limit in the pod's container resource specification
B.Delete and recreate the pod to clear the crash loop
C.Increase the CPU request for the container
D.Delete the namespace and redeploy all workloads
AnswerA

Raising the memory limit in the container's resource spec is the direct fix because the OOMKilled status means the kernel's OOM killer terminated the process when its cgroup memory usage exceeded the configured limit. Increasing the limit allocates more memory to the pod's cgroup, giving the container sufficient headroom to complete its work and preventing the OOM killer from triggering. However, verify that the container's memory footprint is legitimate; if the app has a memory leak, a higher limit only delays the inevitable and masks the underlying issue.

Why this answer

The 'OOMKilled' message indicates the container was terminated because it exceeded its memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory, resolving the out-of-memory condition and preventing future crashes.

Exam trap

The trap here is that candidates may confuse memory and CPU resource issues, or think that simply restarting the pod (Option B) will fix the problem, when the OOMKilled status clearly indicates a persistent memory limit violation that requires a configuration change.

How to eliminate wrong answers

Option B is wrong because deleting and recreating the pod does not address the underlying memory exhaustion; the new pod will crash again with the same OOMKilled error. Option C is wrong because increasing the CPU request does not affect memory allocation; OOMKilled is a memory-related issue, not CPU-related. Option D is wrong because deleting the namespace and redeploying all workloads is an extreme, unnecessary action that does not fix the memory limit and disrupts all other workloads in the namespace.

Full explanation →
31
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 →
32
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 →
33
MCQmedium

You are debugging a pod that is crashing immediately on startup. You want to run an ephemeral container for debugging while the pod is running. Which command should you use?

A.kubectl debug -it pod --image=busybox --target=crashing-container
B.kubectl run debug --image=busybox -it --rm
C.kubectl attach pod
D.kubectl exec -it pod -- /bin/sh
AnswerA

This creates an ephemeral container in the same pod for debugging, even if the main container is failing.

Why this answer

`kubectl debug` with the `--target` flag allows you to attach an ephemeral container to a running pod that is crashing on startup, targeting the specific container that is failing. Ephemeral containers are designed for troubleshooting when `kubectl exec` is not possible (e.g., the container has no shell or crashes immediately), and they run in the pod's namespaces without restarting the pod.

Exam trap

The trap here is that candidates assume `kubectl exec` works on any pod, but it fails when the target container is not running, and they overlook `kubectl debug` as the correct tool for attaching ephemeral containers to crashing pods.

How to eliminate wrong answers

Option B is wrong because `kubectl run debug --image=busybox -it --rm` creates a standalone pod, not an ephemeral container inside the existing crashing pod, so it cannot access the same network or filesystem as the target pod. Option C is wrong because `kubectl attach pod` attaches to the main process of a running container, but if the container is crashing immediately on startup, there is no running process to attach to. Option D is wrong because `kubectl exec -it pod -- /bin/sh` requires the target container to be running and have a shell, which is not the case when the container crashes on startup.

Full explanation →
34
Multi-Selectmedium

Which TWO of the following are valid ways to consume a ConfigMap in a pod? (Select 2)

Select 3 answers
A.Mounting the ConfigMap as a volume
B.Using configMapKeyRef in env.valueFrom
C.Using configMapRef in env.valueFrom
D.Using secretKeyRef in env.valueFrom
E.Using envFrom with configMapRef
AnswersA, B, E

Correct. Mounting a ConfigMap as a volume makes its data available as files.

Why this answer

Although the question instructs to select two, all three options A, B, and E are actually valid ways to consume a ConfigMap in a pod. Option A is correct because a ConfigMap can be mounted as a volume, making each key a file in the container's filesystem. Option B is correct because `configMapKeyRef` in `env.valueFrom` allows loading a specific key from a ConfigMap as an environment variable.

Option E is correct because `envFrom` with `configMapRef` loads all keys from a ConfigMap as environment variables. Options C and D are incorrect: `configMapRef` in `env.valueFrom` is not a valid construct (the correct syntax is `configMapKeyRef`), and `secretKeyRef` is used for Secrets, not ConfigMaps.

Exam trap

Candidates often confuse configMapRef (used in envFrom, which is a valid method) with configMapKeyRef (used in env.valueFrom). They may also mistakenly believe that envFrom is not a valid method for ConfigMaps.

Full explanation →
35
MCQeasy

Which kubectl command creates a pod named 'nginx' from the image 'nginx:latest'?

A.kubectl run nginx --image=nginx:latest
B.kubectl apply -f pod.yaml
C.kubectl run nginx --image=nginx:latest --restart=Never
D.kubectl create pod nginx --image=nginx:latest
AnswerA, C

Correct: This command creates a Pod named 'nginx' from the specified image in recent Kubernetes versions.

Why this answer

`kubectl run nginx --image=nginx:latest` creates a Pod named 'nginx' by default in recent Kubernetes versions (1.18+). Option C is also correct: adding `--restart=Never` explicitly creates a Pod and is a common practice to ensure a Pod is created rather than a Deployment. Option B is wrong because `kubectl apply -f` requires a YAML file.

Option D is wrong because `kubectl create pod` is not a valid subcommand; the correct imperative command is `kubectl run`.

Exam trap

The CKAD exam often tests the misconception that `kubectl run` always creates a Deployment, but in recent Kubernetes versions (1.18+) the default behavior creates a Pod directly. Additionally, both `kubectl run nginx --image=nginx:latest` and `kubectl run nginx --image=nginx:latest --restart=Never` create a Pod, so either is acceptable. Candidates may incorrectly assume only one is correct.

How to eliminate wrong answers

Option B is wrong because `kubectl apply -f pod.yaml` requires a pre-existing YAML manifest file named `pod.yaml` to be present, and it does not create a Pod from the command line using the `--image` flag. Option C is wrong because `kubectl run nginx --image=nginx:latest --restart=Never` explicitly sets the restart policy to Never, which is unnecessary for a basic Pod creation and deviates from the default behavior; the question does not specify any custom restart policy. Option D is wrong because `kubectl create pod nginx --image=nginx:latest` is not a valid kubectl command — the correct syntax for creating a Pod imperatively is `kubectl run`, not `kubectl create pod`.

Full explanation →
36
Multi-Selectmedium

Which TWO of the following are valid ways to create a ConfigMap from a file named 'app.properties'? (Select two.)

Select 2 answers
A.kubectl create configmap app-config --from-file=app.properties
B.kubectl create configmap app-config --from-literal=app.properties
C.kubectl create configmap app-config --from-env=app.properties
D.kubectl create configmap app-config --from-file=app.properties=app.properties
E.kubectl create configmap app-config --from-env-file=app.properties
AnswersA, E

--from-file uses the filename as the key and the file content as the value.

Why this answer

`--from-file=app.properties` creates a ConfigMap with a single key-value pair, where the key defaults to the filename (app.properties) and the value is the entire file content. Option E is correct because `--from-env-file=app.properties` imports each line of the file as a separate key-value pair, treating the file as an environment variable definition file (key=value format).

Exam trap

CNCF often tests the confusion between `--from-file` (which creates a single key with the file content) and `--from-env-file` (which creates multiple keys from key=value lines), and candidates mistakenly think `--from-env` is a valid flag.

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

Correct. Role and RoleBinding are scoped to a single namespace. To grant access across namespaces, you need ClusterRole and ClusterRoleBinding.

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 →
38
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 →
39
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 →
40
Multi-Selectmedium

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

Select 3 answers
A.kubectl create service clusterip my-svc --tcp=80:80
B.kubectl apply -f service.yaml
C.kubectl create deployment my-svc --image=nginx
D.kubectl run my-svc --image=nginx --port=80
E.kubectl expose deployment my-deploy --port=80
AnswersA, B, E

Valid: `kubectl create service clusterip` creates a Service directly.

Why this answer

Options A, B, and E are all valid methods to create a Service. Option A uses `kubectl create service clusterip` to directly create a ClusterIP Service. Option B uses the declarative approach with `kubectl apply -f service.yaml` to create a Service from a YAML definition.

Option E (`kubectl expose deployment`) creates a Service that exposes an existing deployment. Although the question asks for two answers, in fact three of the options are valid methods.

Exam trap

Candidates often think that only imperative commands like `kubectl create service` or `kubectl expose` are valid, overlooking declarative methods like `kubectl apply`. They may also incorrectly assume `kubectl run` with `--port` creates a Service. Note that `kubectl expose` is indeed a valid method, so all three (A, B, E) are correct.

Full explanation →
41
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 →
42
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 →
43
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

Correct syntax for port-forward.

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 →
44
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 →
45
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

Classic blue-green with Service selector.

Why this answer

Blue-green deployment in Kubernetes typically involves running two environments (blue and green) side-by-side and switching traffic from one to the other. Option A directly implements this by maintaining two separate Deployments (blue and green) and updating the Service selector to point to the new version. Option D uses an Ingress resource that can route traffic to different Services, each pointing to a different version of the application; by updating the Ingress rules, traffic can be switched from blue to green.

Option B describes a rolling update, not blue-green. Option C is a rolling update using a single Deployment and changing the container image. Option E is a delete/recreate strategy, not blue-green.

Full explanation →
46
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 →
47
Multi-Selectmedium

Which TWO are valid Service types? (Choose two.)

Select 2 answers
A.NodePort
B.Headless
C.Ingress
D.ClusterIP
E.Pod
AnswersA, D

Valid type.

Why this answer

A is correct because NodePort is a standard Kubernetes Service type that exposes a Service on a static port (30000-32767) on each Node's IP address, allowing external traffic to reach the Service. It works by opening that port on every node and routing traffic to the ClusterIP Service, which then forwards to the Pods.

Exam trap

The trap here is that candidates confuse Ingress or Headless as separate Service types, when in fact Ingress is a separate resource and Headless is a ClusterIP variant, not a distinct type.

Full explanation →
48
MCQhard

You are a platform engineer managing a Kubernetes cluster version 1.28. A development team has deployed a microservice application called 'order-processor' in the 'prod' namespace. The application consists of a frontend Pod 'frontend' and a backend Pod 'backend', each with a single container. The frontend needs to communicate with the backend using a headless Service named 'backend-svc' that selects Pods with label 'app:backend'. The backend Pods are expected to scale horizontally, and the frontend uses a DNS lookup to discover all backend Pod IPs for client-side load balancing. However, after deploying, the frontend is unable to resolve 'backend-svc' to any IP addresses. The backend Pod is running and has the correct label 'app:backend'. The Service 'backend-svc' is defined as a ClusterIP with clusterIP: None. The frontend container has the 'default' DNS policy. What is the most likely cause of the failure?

A.The headless Service must have the 'publishNotReadyAddresses: true' field to include not-ready Pods.
B.The Service and frontend are in different namespaces; the DNS name must be fully qualified.
C.The backend Pod does not have a readiness probe defined, so it is not considered ready and not added to DNS records.
D.The frontend Pod's DNS policy is set to 'None' which disables DNS resolution.
AnswerA

In a headless Service (`clusterIP: None`), DNS records are generated per ready Pod rather than for a single virtual IP. By default, Kubernetes excludes Pods whose readiness condition is false from DNS A/AAAA record lists, which means a not-ready backend Pod will not appear as a DNS entry and the frontend cannot reach it by name. Adding `publishNotReadyAddresses: true` to the Service spec instructs the cluster DNS to publish the addresses of all backing Pods regardless of readiness, enabling the frontend to discover even not-ready backends. This is the only correct option because it identifies the missing configuration attribute that directly affects DNS population.

Why this answer

A headless Service (clusterIP: None) creates DNS A/AAAA records only for Pods that are in the Ready state. If the backend Pod is running but not ready (e.g., due to a failing readiness probe or other conditions), the Service excludes it from DNS. Setting publishNotReadyAddresses: true on the Service would include all matching Pods regardless of readiness, allowing the frontend to discover the backend IPs.

Since the frontend cannot resolve any IPs, the most likely cause is that the Service is not configured to serve not-ready Pods.

Exam trap

The trap here is that candidates assume a headless Service always returns all matching Pod IPs regardless of readiness, but Kubernetes only publishes ready Pods to DNS unless explicitly configured otherwise.

How to eliminate wrong answers

Option A is wrong because 'publishNotReadyAddresses: true' is a legacy field (deprecated in 1.25) that forces inclusion of not-ready Pods in DNS; it is not required for headless Services and is not the default cause of the issue. Option B is wrong because the question states both the frontend and backend are in the 'prod' namespace, so no cross-namespace DNS qualification is needed; a simple service name resolves within the same namespace. Option D is wrong because the frontend container has the 'default' DNS policy (not 'None'), so DNS resolution is enabled and not disabled.

Full explanation →
49
MCQhard

A pod is running with a service account that has been granted a Role to get pods. The pod's code uses the Kubernetes API from within the container. However, the API call fails with a 403 Forbidden error. Which file should the pod read to obtain the authentication token?

A./var/run/secrets/kubernetes.io/serviceaccount/token
B./etc/kubernetes/admin.conf
C./var/run/secrets/kubernetes.io/serviceaccount/namespace
D./var/run/secrets/kubernetes.io/serviceaccount/ca.crt
AnswerA

Correct. The token file is mounted at that path.

Why this answer

The pod's service account token is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. This token is a signed JWT that the pod uses to authenticate to the Kubernetes API server. Without reading this file, the pod cannot present valid credentials, resulting in a 403 Forbidden error.

Exam trap

CNCF often tests the distinction between the token file, the CA certificate, and the namespace file — candidates confuse the token with the CA cert or think the admin kubeconfig is accessible inside the pod.

How to eliminate wrong answers

Option B is wrong because /etc/kubernetes/admin.conf is the kubeconfig file for the cluster administrator, not for a pod's service account; it contains admin-level credentials and is not mounted inside pods. Option C is wrong because /var/run/secrets/kubernetes.io/serviceaccount/namespace contains only the namespace name, not an authentication token. Option D is wrong because /var/run/secrets/kubernetes.io/serviceaccount/ca.crt is the CA certificate used to verify the API server's TLS certificate, not an authentication token.

Full explanation →
50
MCQeasy

To create a service that will be accessible from outside the cluster using a cloud provider's load balancer, what type should be used?

A.NodePort
B.ClusterIP
C.ExternalName
D.LoadBalancer
AnswerD

Correct. LoadBalancer provisions a cloud load balancer and assigns an external IP.

Why this answer

The LoadBalancer service type (D) provisions an external load balancer from the cloud provider (e.g., AWS ELB, GCP TCP/UDP Load Balancer) and assigns a public IP or DNS name, making the service accessible from outside the cluster. This is the correct choice when the requirement explicitly states using a cloud provider's load balancer for external access.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking NodePort alone provides external access via a cloud load balancer, but NodePort only opens a port on each node and requires manual configuration of an external load balancer or direct node access.

How to eliminate wrong answers

Option A (NodePort) is wrong because it exposes the service on a static port on each node's IP, requiring the client to know a node's IP and port, and does not integrate with a cloud provider's load balancer. Option B (ClusterIP) is wrong because it exposes the service only on a cluster-internal IP, making it unreachable from outside the cluster. Option C (ExternalName) is wrong because it maps the service to an external DNS name (via CNAME) and does not expose any ports or provide external access through a load balancer.

Full explanation →
51
MCQeasy

You are a Kubernetes administrator responsible for a production cluster. A development team has deployed a Pod named 'app-pod' that runs a container with a PostgreSQL database. The team reports that the Pod is failing to start with an error: 'Error: container has runAsNonRoot and image will run as root (runtime error)'. The Pod YAML is as follows: ```yaml apiVersion: v1 kind: Pod metadata: name: app-pod spec: containers: - name: db image: postgres:latest securityContext: runAsNonRoot: true ``` The team wants to ensure the container runs securely without running as root. What is the BEST course of action?

A.Add `runAsUser: 999` to the container's securityContext to run the container as the postgres user.
B.Remove `runAsNonRoot: true` from the securityContext to allow the container to run as root.
C.Increase the Pod's resource limits because the error is due to insufficient memory.
D.Create a PodSecurityPolicy that allows running as root.
AnswerA

Setting `runAsUser: 999` explicitly instructs the kubelet to start the container process with UID 999, which is non-zero. This satisfies the `runAsNonRoot: true` validation because the runtime verifies that the effective UID is not 0. Since the Postgres image commonly defines a `postgres` user with UID 999, this aligns with the image's intended user and avoids running as root. This is the standard, least-privilege fix for a `runAsNonRoot` enforcement failure.

Why this answer

The PostgreSQL official image runs as the 'postgres' user with UID 999 by default. Adding `runAsUser: 999` to the container's securityContext overrides the user to a non-root UID, satisfying the `runAsNonRoot: true` constraint and allowing the container to start without the runtime error.

Exam trap

The trap here is that candidates may think removing `runAsNonRoot` is the simplest fix, but the question explicitly requires the container to run securely without root, so the correct action is to specify a non-root user ID rather than disabling the security constraint.

How to eliminate wrong answers

Option B is wrong because removing `runAsNonRoot: true` would allow the container to run as root, which violates the security requirement to run securely without running as root. Option C is wrong because the error message explicitly states a security context violation (runAsNonRoot vs. root image), not a resource constraint; increasing resource limits would not resolve a security context error. Option D is wrong because a PodSecurityPolicy (PSP) is a cluster-level admission controller that can enforce policies, but it does not change the container's user ID; the immediate fix is to set a non-root user in the Pod spec, and PSPs are deprecated in Kubernetes 1.21+ and removed in 1.25.

Full explanation →
52
MCQmedium

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

A.Increase the memory limit in the pod's container resource specification
B.Increase the CPU request for the container
C.Delete and recreate the pod to clear the crash loop
D.Delete the namespace and redeploy all workloads
AnswerA

OOMKilled is the error Kubernetes records when the kernel's out-of-memory killer terminates a process because the container exceeded its `spec.containers[].resources.limits.memory` cgroup allotment. Raising that memory limit gives the container more headroom before the cgroup's OOM killer triggers, directly addressing the crash loop. Keep the limit below the node's allocatable memory and adjust the request proportionally so scheduling remains valid.

Why this answer

The pod is in CrashLoopBackOff due to OOMKilled, meaning the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly resolving the OOM condition.

Exam trap

The trap here is that candidates may confuse OOMKilled with a general crash and choose to delete/recreate the pod, not realizing the OOMKilled status specifically indicates a memory limit violation that requires adjusting resource limits.

How to eliminate wrong answers

Option B is wrong because increasing CPU request does not affect memory allocation; OOMKilled is a memory issue, not a CPU issue. Option C is wrong because deleting and recreating the pod will not resolve the underlying memory limit; the pod will crash again with the same OOMKilled error. Option D is wrong because deleting the namespace and redeploying all workloads is an extreme, unnecessary action that does not address the specific memory limit misconfiguration and would disrupt all workloads in the namespace.

Full explanation →
53
MCQhard

You apply the following Ingress manifest: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app-ingress spec: ingressClassName: nginx rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 The Ingress controller logs show a 404 error when accessing 'http://example.com/api'. The service 'api-service' exists and is reachable via ClusterIP. What is the most likely cause?

A.The service 'api-service' is in a different namespace
B.The service port (80) does not match the container port
C.The IngressClass 'nginx' is not installed or configured
D.The path '/api' should be pathType: Exact
AnswerC

This is the correct explanation. The Ingress resource specifies 'ingressClassName: nginx', but if no IngressClass named 'nginx' exists, or the NGINX Ingress controller is not installed and configured to watch that class, the Ingress will have no active controller to reconcile it. As a result, no forwarding rules are programmed into any reverse proxy, and requests to '/api' produce a 404. Without a matching IngressClass and running controller, the Ingress is effectively inert.

Why this answer

The Ingress controller logs a 404 error because the Ingress resource references `ingressClassName: nginx`, but the NGINX Ingress Controller is not installed or its IngressClass resource is not configured in the cluster. Without a matching IngressClass, the controller ignores this Ingress, so no routing rules are applied, and the default backend (if any) or the controller itself returns a 404. The service exists and is reachable, but the Ingress controller never processes the rules.

Exam trap

The CKAD exam often tests the misconception that a 404 error from an Ingress controller implies a missing service or wrong path, when in fact the Ingress resource itself is not being processed due to a missing or misconfigured IngressClass.

How to eliminate wrong answers

Option A is wrong because Ingress resources can route traffic to services in any namespace, and the question does not specify a namespace mismatch; the service is reachable via ClusterIP, so namespace is not the issue. Option B is wrong because the service port (80) is used for routing within the cluster, and the container port is irrelevant as long as the service targets the correct pod port; the error is a 404 from the Ingress controller, not a connection timeout or refused connection. Option D is wrong because pathType: Prefix with path /api correctly matches requests starting with /api, and changing to Exact would only match the literal path /api, which would still not resolve the 404 if the Ingress controller is not processing the resource.

Full explanation →
54
MCQeasy

You have a Deployment running a web server that takes 30 seconds to initialize. You want to ensure that the load balancer does not send traffic to the pod until it is ready. Which probe should you configure?

A.Readiness probe
B.Resource limit
C.Startup probe
D.Liveness probe
AnswerA

The readiness probe is the correct mechanism because it directly controls whether a pod is added to or removed from the endpoints of a Service. When the probe fails, the kubelet marks the pod as NotReady, and the endpoints controller immediately removes its IP from all backing Services, stopping new traffic. This is essential for deployments where the application needs time to warm up or load data before accepting requests, and it also enables zero-downtime rolling updates by holding back new pods until they are fully operational.

Why this answer

A Readiness probe is the correct choice because it determines whether a Pod is ready to serve traffic. In this scenario, the web server takes 30 seconds to initialize, so a Readiness probe (e.g., an HTTP GET on the application's health endpoint) will prevent the Service (and thus the load balancer) from sending requests until the probe succeeds, ensuring zero traffic is routed to an uninitialized Pod.

Exam trap

The trap here is that candidates confuse Startup probes with Readiness probes, thinking a Startup probe alone will gate traffic, but only the Readiness probe controls whether the Service routes traffic to the Pod.

How to eliminate wrong answers

Option B is wrong because a Resource limit (CPU/memory) controls resource usage and scheduling, not traffic routing; it does not prevent the load balancer from sending traffic to an unready Pod. Option C is wrong because a Startup probe checks if the application has started successfully and is used for slow-starting containers, but it does not control traffic routing from the load balancer; once the Startup probe succeeds, the Liveness and Readiness probes take over, and the Readiness probe is the one that gates traffic. Option D is wrong because a Liveness probe restarts the container if it fails, but it does not prevent traffic from being sent to an unready Pod; a Pod can be alive but not ready, and the Liveness probe would not stop traffic.

Full explanation →
55
MCQmedium

You have a Deployment 'app' with the following strategy configuration: 'type: RollingUpdate', 'rollingUpdate: {maxSurge: 0, maxUnavailable: 1}'. You update the container image. What is the behavior during the update?

A.A new pod is created first, then the oldest pod is terminated.
B.Two old pods are terminated at a time, while new pods are created.
C.One old pod is terminated, then a new pod is created, repeating until all pods are updated.
D.All old pods are terminated simultaneously, then new pods are created.
AnswerC

With maxSurge=0, the desired replica count cannot be exceeded, and with maxUnavailable=1, at most one pod may be down during the update. This configuration forces a strictly sequential pattern: the controller first terminates an old pod, which counts as one unavailable pod, then creates a new pod to restore the replica count to the desired number. It then repeats this cycle for each remaining old replica, so one old pod is terminated, a new pod is created, and this continues until all pods are rolled over. This approach maintains availability without any temporary scaling up.

Why this answer

With `maxSurge: 0` and `maxUnavailable: 1`, the RollingUpdate strategy ensures that during the update, no extra pods beyond the desired replica count are created (surge is zero), and at most one pod can be unavailable at any time. The Deployment controller first terminates an old pod (making one unavailable), then creates a new pod to replace it, repeating this process until all pods are updated. This guarantees a controlled, sequential rollout with minimal disruption.

Exam trap

The trap is that candidates often confuse the Kubernetes rolling update parameters: `maxSurge: 0` means no extra pods can be created above the desired count, and `maxUnavailable: 1` means at most one pod can be unavailable at a time. This results in a sequential termination-then-creation process, not parallel or batch updates.

How to eliminate wrong answers

Option A is wrong because it describes a behavior where a new pod is created before terminating an old one, which would require `maxSurge: 1` or higher; with `maxSurge: 0`, no new pod can be created until an old pod is terminated. Option B is wrong because terminating two old pods at a time would violate `maxUnavailable: 1`, which limits the number of unavailable pods to one during the update. Option D is wrong because terminating all old pods simultaneously would make all pods unavailable at once, far exceeding the `maxUnavailable: 1` limit and causing a full service disruption.

Full explanation →
56
Multi-Selecthard

Which THREE configurations are part of Pod Security Admission's 'restricted' profile? (Select THREE.)

Select 3 answers
A.runAsNonRoot: true
B.seccompProfile.type: RuntimeDefault
C.capabilities must drop ALL
D.allowPrivilegeEscalation: true
E.Privileged containers allowed
AnswersA, B, C

Correct. Containers must run as non-root.

Why this answer

The 'restricted' profile in Pod Security Admission enforces the most stringent security standards. Option A is correct because `runAsNonRoot: true` is a required field in the restricted profile, ensuring containers cannot run as the root user, which mitigates privilege escalation risks.

Exam trap

The trap here is that candidates often confuse the 'restricted' profile with the 'baseline' profile, mistakenly thinking that options like `allowPrivilegeEscalation: true` or privileged containers are acceptable, when in fact the restricted profile explicitly prohibits them.

Full explanation →
57
MCQeasy

You want to view the logs of a pod named 'web-pod' that has two containers: 'nginx' and 'sidecar'. Which command correctly retrieves the logs from the 'nginx' container?

A.kubectl logs -c nginx web-pod
B.kubectl logs web-pod -c nginx
C.kubectl logs web-pod nginx
D.kubectl logs web-pod --container nginx
AnswerB

Correctly specifies the container with -c, but lacks -f flag to stream logs.

Why this answer

The correct command uses the proper syntax: `kubectl logs <pod-name> -c <container-name>`. Option B follows this syntax correctly. Option A places the container flag before the pod name, which is invalid.

Option C omits the -c flag, which is required when the pod has multiple containers. Option D uses the long form --container, which is valid but the question expects the short form as seen in B. Therefore, B is the best answer.

Full explanation →
58
MCQmedium

You need to allow ingress traffic to pods in namespace 'api' only from pods in namespace 'frontend' that have label 'role: proxy'. Which NetworkPolicy ingress rule correctly implements this?

A.ingress: - from: - namespaceSelector: matchLabels: name: frontend
B.ingress: - from: - namespaceSelector: matchLabels: name: frontend podSelector: matchLabels: role: proxy
C.ingress: - from: - ipBlock: cidr: 0.0.0.0/0 - podSelector: matchLabels: role: proxy
D.ingress: - from: - podSelector: matchLabels: role: proxy
AnswerB

This rule correctly combines a namespaceSelector and a podSelector within the same ingress peer, and in NetworkPolicy semantics, these two selectors are ANDed when they appear together in a single peer. Thus, only pods that simultaneously satisfy both labels—role=proxy on the pod itself, and the pod's namespace having name=frontend—are allowed as sources. This exactly matches the stated requirement, ensuring no other pods from the frontend namespace, and no proxies from other namespaces, can connect.

Why this answer

It combines a namespaceSelector (to match the 'frontend' namespace) with a podSelector (to match pods with label 'role: proxy') in the same ingress rule. This ensures that only traffic from pods in the 'frontend' namespace that also have the label 'role: proxy' is allowed, fulfilling the requirement precisely.

Exam trap

The trap here is that candidates often forget that when namespaceSelector and podSelector are combined in the same 'from' block, they are ANDed, not ORed, leading them to pick options that are too broad (like A or D) or that mix unrelated rules (like C).

How to eliminate wrong answers

Option A is wrong because it only uses a namespaceSelector to match the 'frontend' namespace, allowing all pods in that namespace regardless of their labels, which is too permissive. Option C is wrong because it includes an ipBlock rule for 0.0.0.0/0 (all traffic) combined with a podSelector for 'role: proxy', which would allow traffic from any source IP (including outside the cluster) as long as the source pod has that label, violating the namespace restriction. Option D is wrong because it only uses a podSelector for 'role: proxy' without a namespaceSelector, which would allow traffic from any namespace (including the same namespace) as long as the source pod has that label, failing to restrict to the 'frontend' namespace.

Full explanation →
59
MCQhard

A Pod in a namespace with a ResourceQuota that sets 'limits.cpu: 4' and 'limits.memory: 8Gi' is being created with the following container resources: requests: cpu: 2, memory: 4Gi; limits: cpu: 4, memory: 8Gi. The namespace also has a LimitRange with default limits of cpu: 500m, memory: 512Mi. Which statement is true about this resource configuration?

A.The Pod will have its limits overridden by the LimitRange defaults because limits must be set
B.The Pod will be admitted because it respects both the ResourceQuota and the LimitRange
C.The Pod will be rejected because the limits exceed the LimitRange default
D.The Pod will be rejected because requests must equal limits
AnswerB

The Pod is admitted because its declared resource limits fall within the maximum allowed by the ResourceQuota and, if a LimitRange exists, the Pod's own limits satisfy any minimum or maximum constraints defined there. As the Pod explicitly sets its limits, the LimitRange's default section is irrelevant. Admission only fails when a resource request would violate quota or a mandatory range constraint.

Why this answer

B is correct because the Pod explicitly sets its own limits (cpu: 4, memory: 8Gi) and requests (cpu: 2, memory: 4Gi), which are within the ResourceQuota's 'limits.cpu: 4' and 'limits.memory: 8Gi' constraints. The LimitRange default limits only apply to containers that do not specify limits; since this Pod specifies limits, the defaults are ignored. The Pod is admitted as it satisfies both admission controllers.

Exam trap

The trap here is that candidates assume LimitRange defaults always override Pod specifications, but in reality defaults only apply when the Pod does not set its own limits, and the Pod's explicit limits take precedence.

How to eliminate wrong answers

Option A is wrong because LimitRange defaults only apply to containers that do not have limits set; here limits are explicitly defined, so no override occurs. Option C is wrong because the Pod's limits exactly match the ResourceQuota's maximum (4 CPU, 8Gi memory), not exceed it, and the LimitRange default is irrelevant when limits are set. Option D is wrong because Kubernetes does not require requests to equal limits; they can differ, and the ResourceQuota only enforces the maximum limits, not equality.

Full explanation →
60
MCQmedium

A developer creates a headless Service with 'clusterIP: None' for a StatefulSet. What is the primary purpose of using a headless Service?

A.To prevent DNS resolution of the service
B.To enable TLS termination at the service level
C.To provide load balancing across the pods
D.To provide stable network identities and DNS records for each pod in the StatefulSet
AnswerD

When a headless service is paired with a StatefulSet, each pod receives a unique, stable DNS record of the form <pod-name>.<service-name>.<namespace>.svc.cluster.local. Because pods are created with deterministic ordinal names (e.g., web-0, web-1), the headless service creates these per-pod DNS entries, giving each pod a stable network identity that remains reachable directly by name even if pods are rescheduled.

Why this answer

A headless Service (with `clusterIP: None`) is used with StatefulSets to provide stable, unique network identities (DNS records) for each pod. Instead of a single virtual IP and round-robin load balancing, the headless Service returns A/AAAA records for each pod's individual IP address, enabling direct pod-to-pod communication based on stable hostnames like `pod-name.service-name.namespace.svc.cluster.local`.

Exam trap

The trap here is that candidates confuse 'headless' with 'no DNS' or 'no networking', when in fact headless Services provide DNS records for individual pods, which is essential for stateful workloads that need stable identities.

How to eliminate wrong answers

Option A is wrong because a headless Service does not prevent DNS resolution; it changes the DNS behavior to return pod IPs directly rather than a single cluster IP. Option B is wrong because TLS termination is a feature of Ingress controllers or load balancers, not headless Services, which operate at Layer 4 and do not handle TLS. Option C is wrong because a headless Service explicitly disables load balancing; it returns all pod IPs, leaving the client to perform its own selection (e.g., via SRV records or direct pod hostnames).

Full explanation →
61
MCQmedium

A developer wants to containerize a Node.js application. The Dockerfile should first copy only package.json and package-lock.json, run npm install, then copy the rest of the source code. Which Dockerfile best achieves this?

A.COPY . /app\nRUN npm install
B.ADD package*.json /app/\nRUN npm install\nADD . /app/
C.COPY package*.json /app/\nRUN npm install\nCOPY . /app/
D.ADD . /app\nRUN npm install
AnswerC

This is the recommended pattern: copying only `package*.json` first makes the `RUN npm install` layer depend solely on dependency manifests, so it remains cached unless those files change. After install, the remaining application code is copied in a separate layer, letting source-code edits rebuild quickly without reinstalling dependencies. Using `COPY` for both operations is correct for local build-context files, and if the source contains a `node_modules` directory, a `.dockerignore` entry should exclude it to avoid overwriting the freshly installed dependencies.

Why this answer

It first copies only package.json and package-lock.json (using a wildcard pattern), runs `npm install` to leverage Docker's layer caching, and then copies the rest of the source code. This ensures that subsequent builds only re-run `npm install` when the dependency files change, not on every source code modification, which is a best practice for efficient Docker builds.

Exam trap

In the CKAD exam, candidates often mistakenly use `ADD` instead of `COPY`, but `COPY` is the recommended command for copying local files to a Docker image without unnecessary side effects. The exam emphasizes efficient layer caching, so using `COPY` for local files and separating dependency installation from source code copying is a best practice.

How to eliminate wrong answers

Option A is wrong because it copies the entire source code before running `npm install`, which defeats Docker layer caching — any source code change invalidates the npm install cache, causing unnecessary re-installations. Option B is wrong because it uses `ADD` instead of `COPY`; while `ADD` can copy files, it has additional behaviors like automatic tar extraction and remote URL fetching, which are unnecessary here and violate the principle of using `COPY` for local file copies unless extra features are needed. Option D is wrong because it copies the entire source code before running `npm install`, similar to option A, and uses `ADD` instead of `COPY`, introducing unnecessary complexity and potential side effects.

Full explanation →
62
Multi-Selecthard

Which THREE of the following are valid fields in a PodSecurityContext?

Select 3 answers
A.fsGroup
B.capabilities
C.seccompProfile
D.runAsNonRoot
E.allowPrivilegeEscalation
AnswersA, C, D

Valid at pod level; sets group ownership of volumes.

Why this answer

`fsGroup` is a valid field in a PodSecurityContext. It specifies the supplemental group ID applied to all containers in the pod when accessing volumes, ensuring proper file ownership and permissions for shared storage.

Exam trap

CNCF often tests the distinction between PodSecurityContext and container SecurityContext, trapping candidates who assume all security-related fields (like capabilities or allowPrivilegeEscalation) are valid at the pod level when they are actually container-specific.

Full explanation →
63
MCQhard

You are using a canary deployment strategy with Deployments and Services. You have a stable version (v1) and a canary version (v2). Both Deployments have the label 'app: myapp'. The Service selector is 'app: myapp'. How can you route a small percentage of traffic to the canary?

A.Set both Deployments to 10 replicas and use an Ingress with a canary weight annotation (e.g., canary-weight: '10')
B.Set the canary Deployment replicas to 1 and the stable to 9, and update the Service selector to include version: v2
C.Set the canary Deployment replicas to 10 and the stable to 1
D.Set the canary Deployment replicas to 1 and the stable to 9, and keep the Service selector as 'app: myapp'
AnswerD

Keeping the Service selector as 'app: myapp' while setting canary replicas to 1 and stable to 9 ensures that both Deployments' pods match the selector. The Service then performs round-robin or random load balancing across all matching endpoints, so traffic is distributed proportionally to pod counts—approximately 10% to canary and 90% to stable. This is the correct method because it uses the natural endpoint-count-based weighting of a Service without introducing label restrictions that would isolate one version.

Why this answer

The Service selector 'app: myapp' matches both Deployments, and by setting the canary to 1 replica and the stable to 9, the Service's round-robin load balancing (by default) distributes roughly 10% of traffic to the canary Pods and 90% to the stable Pods. This is a simple, native Kubernetes canary pattern that requires no additional components like Ingress controllers.

Exam trap

The trap is to overcomplicate the solution by introducing a specialized Ingress controller or modifying the Service selector, when the simplest approach is to adjust replica counts while keeping the selector unchanged.

How to eliminate wrong answers

Option A is wrong because it relies on an Ingress with a canary-weight annotation, which is specific to the NGINX Ingress Controller and not a core Kubernetes feature; the question does not specify that an Ingress controller is in use, and the scenario only mentions Deployments and Services. Option B is wrong because updating the Service selector to include 'version: v2' would cause the Service to only match Pods with that label, thus routing 100% of traffic to the canary and none to the stable version. Option C is wrong because setting the canary to 10 replicas and the stable to 1 would route approximately 91% of traffic to the canary, not a small percentage.

Full explanation →
64
MCQeasy

A container runs as root (UID 0) but the security policy requires the container to run as non-root user 1000. Which pod security context setting should be added?

A.runAsNonRoot: true
B.runAsUser: 1000
C.fsGroup: 1000
D.privileged: false
AnswerB

runAsUser: 1000 directly sets the container process's user ID to 1000, overriding any default user defined in the image's Dockerfile or container runtime configuration. This makes the process run as UID 1000 regardless of the image's original settings, and it is the only way to deterministically satisfy a policy that explicitly requires UID 1000. It is the exact, explicit control needed when the container starts as root by default.

Why this answer

`runAsUser: 1000` explicitly sets the container's user ID to 1000, ensuring the container process runs as a non-root user. This directly satisfies the security policy requirement to run as UID 1000, overriding the default root (UID 0) behavior.

Exam trap

The trap here is that candidates often confuse `runAsNonRoot: true` with setting a specific user ID, not realizing it only enforces non-root but does not guarantee UID 1000, which the question explicitly requires.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot: true` only prevents the container from running as root (UID 0) but does not specify which non-root UID to use; it relies on the container image's default user, which may not be UID 1000. Option C is wrong because `fsGroup: 1000` sets the group ID for volume ownership, not the user ID the container process runs as. Option D is wrong because `privileged: false` is the default setting and only disables privileged mode; it does not enforce a specific non-root user.

Full explanation →
65
MCQhard

You are using a canary deployment pattern with two Deployments: 'web-stable' (version 1) and 'web-canary' (version 2). Both have the label 'app: web'. The Service 'web-svc' selects pods with 'app: web' and 'version: stable'. How do you route traffic to the canary?

A.Add the label 'version: canary' to the canary Deployment's pod template and update the Service's selector to 'app: web, version in (stable, canary)'.
B.Use kubectl rollout canary on the stable Deployment.
C.Create a new Service with selector 'app: web, version: canary' and use an ingress to split traffic.
D.Change the Service selector to 'app: web' only (remove version label).
AnswerA

Adding the 'version: canary' label to the canary pod template and updating the Service selector to a set-based requirement (version in (stable, canary)) allows the existing Service to include both stable and canary pods in its endpoints. Kubernetes Services load-balance across all ready endpoints, so traffic is distributed proportionally to the replica counts of each Deployment. You can then carefully scale the canary Deployment up to increase its traffic share, making this a native, controlled canary strategy.

Why this answer

The Service 'web-svc' currently selects pods with 'app: web' and 'version: stable'. To route traffic to the canary pods (version 2), you need to add the label 'version: canary' to the canary Deployment's pod template so that those pods are created with that label. Then, updating the Service's selector to 'app: web, version in (stable, canary)' allows the Service to match both stable and canary pods, distributing traffic between them according to the Service's default round-robin behavior.

Exam trap

The trap here is that candidates often think they need to create a separate Service or use a special command for canary deployments, when in fact Kubernetes supports canary routing simply by updating the Service's selector to include both versions' labels, leveraging the built-in load balancing.

How to eliminate wrong answers

Option B is wrong because 'kubectl rollout canary' is not a valid kubectl command; Kubernetes does not have a built-in 'rollout canary' subcommand — canary deployments are implemented manually using multiple Deployments and Service selectors. Option C is wrong because creating a separate Service for the canary and using an ingress to split traffic is an overcomplicated approach that is not required for a simple canary pattern; the question asks how to route traffic to the canary using the existing Service, and a single Service with a combined selector is the standard method. Option D is wrong because changing the Service selector to 'app: web' only (removing the version label) would cause the Service to select all pods with 'app: web', including both stable and canary, but it would also select any other pods with that label, potentially including unintended pods; more importantly, it does not provide a controlled way to gradually shift traffic — it immediately sends traffic to all matching pods without the ability to limit the canary's exposure.

Full explanation →
66
MCQeasy

A pod needs to mount a Secret named 'db-secret' as a volume at /etc/secret. Which volume mount definition is correct?

A.volumes: - name: secret-volume secret: secretName: db-secret
B.volumes: - name: secret-volume secretVolumeSource: secretName: db-secret
C.volumes: - name: db-secret secret: secretName: db-secret
D.volumes: - name: secret-volume secret: name: db-secret
AnswerA

This is the correct syntax: 'secret' with 'secretName' field.

Why this answer

It uses the proper `secret` key under the `volumes` field to reference a Secret object by its `secretName`. When this volume is mounted at `/etc/secret`, Kubernetes automatically creates a file for each key in the Secret, with the file content being the decoded value of the key. This is the standard syntax for mounting a Secret as a volume.

Exam trap

The trap here is that candidates often confuse the `secret` volume source with the `configMap` volume source, or incorrectly use `secretVolumeSource` (which is not a valid field) instead of the correct `secret` key, leading them to choose option B.

How to eliminate wrong answers

Option B is wrong because `secretVolumeSource` is not a valid field in the volume definition; the correct field is `secret`. Option C is wrong because the volume name is `db-secret`, which is not technically invalid but is misleading — the volume name should be a descriptive identifier (e.g., `secret-volume`) and is not required to match the Secret name. Option D is wrong because it uses `name: db-secret` under the `secret` block, but the correct key is `secretName`, not `name`.

Full explanation →
67
MCQmedium

A developer creates a headless Service named 'db' to discover all database pod IPs. The Service selects pods with label 'app: db'. The pods are assigned IPs 10.0.0.1, 10.0.0.2, and 10.0.0.3. When a client performs a DNS lookup for 'db', what will it receive?

A.The IP of the first pod only
B.The cluster IP of the Service
C.All three pod IPs as separate A records
D.A round-robin list of pod IPs
AnswerC

DNS returns all pod IPs as A records for the headless Service.

Why this answer

A headless Service (clusterIP: None) does not have a cluster IP. Instead, DNS queries for the Service name return A records for all pods matching the selector. Since the Service selects pods with label 'app: db', the DNS lookup for 'db' returns the three pod IPs (10.0.0.1, 10.0.0.2, 10.0.0.3) as separate A records, allowing direct pod-to-pod communication.

Exam trap

The trap here is that candidates confuse headless Services with regular Services, assuming DNS returns a single cluster IP or a round-robin list, when in fact headless Services return all pod IPs as separate A records with no load balancing.

How to eliminate wrong answers

Option A is wrong because a headless Service does not return only the first pod's IP; it returns all matching pod IPs as separate A records. Option B is wrong because a headless Service has no cluster IP (clusterIP is set to None), so DNS does not return a cluster IP. Option D is wrong because DNS for a headless Service returns all pod IPs in an unordered list; the client's DNS resolver may rotate them, but the Service itself does not implement round-robin — that behavior depends on the client's DNS caching and resolution logic.

Full explanation →
68
Matchingmedium

Match each Kubernetes concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Virtual cluster for resource isolation

Runs one pod per node for system services

Runs a pod to completion; for batch processing

Automatically scales pods based on CPU/memory

Controls traffic flow between pods

Why these pairings

Correct matches are Pod with smallest deployable unit, Service with logical set and access policy, Deployment with declarative updates, and Ingress with external HTTP access. Common confusions include swapping Pod and Service definitions.

Full explanation →
69
MCQeasy

What is the purpose of a .dockerignore file in a Docker build context?

A.It limits the number of layers in the final image
B.It excludes files and directories from being sent to the Docker daemon during the build
C.It defines environment variables for the container
D.It specifies the order of layers in the Docker image
AnswerB

A .dockerignore file defines patterns that exclude files and directories from the build context before it is transmitted to the Docker daemon. This reduces the amount of data sent, shortens build times, and prevents sensitive information like .env, SSH keys, or large local caches such as node_modules from being uploaded. Ignored files are not available for COPY or ADD within the Dockerfile, but the exclusion is purely at the context-transmission stage.

Why this answer

The .dockerignore file, when placed in the Docker build context, instructs the Docker CLI to exclude specified files and directories from the tar archive that is sent to the Docker daemon during the `docker build` command. This reduces the build context size, speeds up the build, and prevents sensitive files (e.g., .env, .git) from being included in the image layers.

Exam trap

The CKAD exam often tests the distinction between build-time and runtime configuration; the trap here is confusing the .dockerignore file (which affects the build context sent to the daemon) with files that control image layers or container runtime behavior, leading candidates to select options about layer count or environment variables.

How to eliminate wrong answers

Option A is wrong because the number of layers in a Docker image is determined by the number of RUN, COPY, and ADD instructions in the Dockerfile, not by the .dockerignore file. Option C is wrong because environment variables for a container are defined using the ENV instruction in the Dockerfile or the --env flag at runtime, not by a .dockerignore file. Option D is wrong because the order of layers in a Docker image is dictated by the sequence of instructions in the Dockerfile, not by any ignore file.

Full explanation →
70
Matchingmedium

Match each volume type to its use case.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Temporary storage that shares a pod's lifecycle

Mounts a file or directory from the host node

Requests durable storage from a PersistentVolume

Inject configuration data as files or env vars

Inject sensitive data as files or env vars

Why these pairings

The correct matches are: emptyDir - temporary storage, hostPath - host node directory, PVC - persistent storage, ConfigMap - configuration data. Common confusions involve mixing hostPath and PVC, or emptyDir with hostPath.

Full explanation →
71
MCQmedium

You need to debug a running pod that does not have a shell installed. Which kubectl command allows you to start an ephemeral container with a shell?

A.kubectl create pod debug --image=busybox --attach
B.kubectl exec -it <pod> -- /bin/sh
C.kubectl debug <pod> --image=busybox --stdin --tty
D.kubectl run debug --image=busybox --attach
AnswerC

kubectl debug adds an ephemeral container to the pod with the specified image and attaches to it.

Why this answer

`kubectl debug` is specifically designed to add an ephemeral container to a running pod for troubleshooting purposes, even when the original container lacks a shell. The `--image=busybox` flag provides a lightweight image with common debugging tools, and `--stdin --tty` allocates an interactive terminal, allowing you to run commands like `/bin/sh` inside the ephemeral container without modifying the original pod's containers.

Exam trap

The trap here is that candidates often confuse `kubectl exec` (which requires a shell in the existing container) with `kubectl debug` (which adds a new container with a shell), or mistakenly think `kubectl run` or `kubectl create pod` can attach to an existing pod's context.

How to eliminate wrong answers

Option A is wrong because `kubectl create pod debug --image=busybox --attach` creates a new standalone pod, not an ephemeral container attached to an existing running pod, so it cannot debug the target pod's environment. Option B is wrong because `kubectl exec -it <pod> -- /bin/sh` attempts to execute a shell inside the existing container, which fails if the container does not have a shell installed (e.g., a distroless or minimal image). Option D is wrong because `kubectl run debug --image=busybox --attach` launches a new pod in the cluster, not an ephemeral container in the target pod, and thus cannot access the target pod's filesystem, processes, or network namespace.

Full explanation →
72
MCQhard

You need to debug a pod that has no running containers because it is in a CrashLoopBackOff state. You want to start an ephemeral container with debugging tools in the same namespace. Which command accomplishes this?

A.kubectl run debug --image=busybox -it --restart=Never
B.kubectl attach pod-name
C.kubectl debug -it pod-name --image=busybox --target=container-name
D.kubectl exec -it pod-name -- /bin/sh
AnswerC

kubectl debug -it pod-name --image=busybox --target=container-name creates an ephemeral container inside the existing Pod's sandbox, so it shares the same network namespace, IPC namespace, and (when --target is specified) the target container's process namespace. The ephemeral container includes the provided busybox image, giving you a shell (via -it) and common debugging tools even though the original container lacks a shell or has crashed. Because ephemeral containers are managed by the kubelet, the original Pod's spec and lifecycle are unaffected, and if the Pod is not running, kubectl debug will create a copy, so this is the right tool when no containers are running. The --target flag is what lets you see the crashed container's processes, but for ordinary filesystem inspection the ephemeral container also mounts the Pod's volumes.

Why this answer

`kubectl debug` allows you to start an ephemeral container in an existing pod that is in a CrashLoopBackOff state. The `--target` flag attaches the ephemeral container to the same Linux namespace as the specified container, enabling debugging without restarting the pod. This is the only command that works when the pod has no running containers and `kubectl exec` fails.

Exam trap

The trap here is that candidates assume `kubectl exec` is the standard debugging tool, but it fails when no container is running; `kubectl debug` with `--target` is the correct approach for CrashLoopBackOff scenarios.

How to eliminate wrong answers

Option A is wrong because `kubectl run` creates a new standalone pod, not an ephemeral container in the existing pod, so it cannot debug the specific pod's namespace or filesystem. Option B is wrong because `kubectl attach` only connects to a running container's stdin/stdout/stderr, and it fails when the pod is in CrashLoopBackOff with no running containers. Option D is wrong because `kubectl exec` requires at least one running container in the pod to execute a command, which is not available in CrashLoopBackOff.

Full explanation →
73
MCQmedium

A pod is using a Secret to authenticate to a private registry. The Secret type must be 'kubernetes.io/dockerconfigjson'. Which of the following is the correct way to create such a Secret using kubectl?

A.kubectl create secret generic regcred --type=kubernetes.io/dockercfg --from-literal=.dockercfg=...
B.kubectl create secret generic regcred --from-file=.dockerconfigjson=/root/.docker/config.json
C.kubectl create secret tls regcred --cert=cert.crt --key=key.key
D.kubectl create secret docker-registry regcred --docker-server=my-registry.example.com --docker-username=myuser --docker-password=mypassword --docker-email=myemail@example.com
AnswerD

This correctly creates a dockerconfigjson Secret.

Why this answer

`kubectl create secret docker-registry` is the dedicated command to create a Secret of type `kubernetes.io/dockerconfigjson`. It automatically generates the required `.dockerconfigjson` field with the base64-encoded Docker credentials in the correct JSON format, which the kubelet uses to authenticate to a private registry when pulling images.

Exam trap

The trap here is that candidates may think any Secret with a `.dockerconfigjson` key works, but without the correct `kubernetes.io/dockerconfigjson` type, the kubelet will not interpret the data properly, leading to image pull failures.

How to eliminate wrong answers

Option A is wrong because it uses `--type=kubernetes.io/dockercfg` (which corresponds to the legacy `.dockercfg` format) instead of `kubernetes.io/dockerconfigjson`, and `--from-literal=.dockercfg=...` does not produce the required `.dockerconfigjson` key. Option B is wrong because `--from-file=.dockerconfigjson` would create a generic Secret with that key, but the Secret type would remain `Opaque` unless explicitly set to `kubernetes.io/dockerconfigjson`; the command does not specify the required type. Option C is wrong because `kubectl create secret tls` creates a Secret of type `kubernetes.io/tls` for TLS certificates and keys, not for Docker registry authentication.

Full explanation →
74
MCQmedium

You need to schedule a task that runs every day at 2:00 AM. The task should be allowed to run even if a previous instance is still running. Which concurrencyPolicy should you set in the CronJob spec?

A.Allow
B.Replace
C.Forbid
D.Ignore
AnswerA

The concurrencyPolicy Allow (which is also the default) permits a new Job to be created even if a previous Job from the same CronJob is still running. For a daily 02:00 schedule, this ensures the task starts at the scheduled time regardless of whether the prior run completed. Since the requirement only says the task should run every day and imposes no restriction on overlapping execution, Allow is the correct and standard policy.

Why this answer

Setting `concurrencyPolicy: Allow` in a CronJob spec permits a new job instance to start even if a previous instance is still running. This is the default behavior when the field is omitted, and it directly satisfies the requirement that the task must run at 2:00 AM regardless of any overlapping executions.

Exam trap

The trap here is that candidates may confuse concurrencyPolicy with restartPolicy or assume 'Ignore' is a valid option, but Kubernetes only supports Allow, Forbid, and Replace, and the default is Allow.

How to eliminate wrong answers

Option B (Replace) is wrong because it would cancel the currently running job and start a new one, which violates the requirement to allow the previous instance to continue. Option C (Forbid) is wrong because it would skip the new job if a previous instance is still running, preventing the scheduled execution. Option D (Ignore) is not a valid value for the concurrencyPolicy field in Kubernetes; the only valid values are Allow, Forbid, and Replace.

Full explanation →
75
MCQhard

A Pod has two containers: one with a liveness probe that fails after 30 seconds. The restartPolicy is 'Never'. What state will the Pod be in after the liveness probe fails?

A.Running
B.Failed
C.Unknown
D.CrashLoopBackOff
AnswerB

A liveness probe failure makes the kubelet kill the container; with restartPolicy: Never the kubelet will not restart it. The container's exit is processed as a terminal status, and the Pod is marked Failed (the phase is exactly Failed when all containers in a Pod have terminated and at least one has exited non-zero or was killed). This is the expected result in this scenario rather than a crash loop.

Why this answer

When a liveness probe fails, Kubernetes terminates the container and, because the restartPolicy is 'Never', does not restart it. The Pod transitions to the 'Failed' phase, as the container has exited with a non-zero exit code and will not be recreated. This is the expected behavior for a Pod with a single container that fails its health check under a 'Never' restart policy.

Exam trap

The trap here is that candidates often confuse the restartPolicy 'Never' with 'OnFailure' and assume the Pod will enter CrashLoopBackOff, but CrashLoopBackOff only applies when the restartPolicy allows restarts; with 'Never', the Pod fails permanently.

How to eliminate wrong answers

Option A is wrong because 'Running' indicates that all containers in the Pod are operational, but the liveness probe failure causes the container to be terminated, so the Pod cannot remain in the Running state. Option C is wrong because 'Unknown' is a transient state used when the node cannot report the Pod's status (e.g., due to network partition), not the final state after a liveness probe failure. Option D is wrong because 'CrashLoopBackOff' only occurs when the restartPolicy is 'Always' or 'OnFailure' and the container repeatedly crashes; with 'Never', no restart is attempted, so the Pod goes directly to 'Failed'.

Full explanation →

Page 1 of 3

Page 2

All pages

123

Practice CKAD by domain

Target a specific domain to shore up weak areas.

Application Design and BuildApplication DeploymentApplication Environment, Configuration and SecurityApplication Observability and MaintenanceServices and Networking
See all domains with question counts →