Courseiva

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

826 questions total · 12pages · All types, answers revealed

Take a mock examExam hub

Page 1 of 12

Page 2
1
MCQeasy

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

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

The `kubectl create configmap` command with `--from-file` reads the contents of the specified file and stores it as a single key (defaulting to the filename, `config.properties`) in the ConfigMap. This is the idiomatic way to import a configuration file's raw data without parsing or transforming it, making it perfect for arbitrary property files, YAML, or JSON. The resulting ConfigMap can then be mounted as a volume or consumed as environment variables by pods.

Why this answer

`kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named `app-config` with a single key `config.properties` (the filename) and the file's entire content as its value. The `--from-file` flag does not parse the file into separate key-value pairs. To parse lines like KEY=VALUE, you would use `--from-env-file`.

Exam trap

The trap here is confusing `--from-file` with `--from-env-file`, as candidates often assume any file with key-value pairs will be parsed automatically, but `--from-file` treats the entire file as a single value, while `--from-env-file` parses each line as a separate key-value pair.

How to eliminate wrong answers

Option B is wrong because `--from-env-file` is used to import a file in the format of environment variables (e.g., `KEY=VALUE` lines) and creates a ConfigMap with each line as a separate key-value pair, not a single key from the filename. Option C is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `key=value`), not to reference a file. Option D is wrong because `kubectl apply` is used to apply a configuration from a file or stdin, not to create a ConfigMap from a properties file; the correct command for creation is `kubectl create configmap`.

Full explanation →
2
MCQmedium

A developer creates a Deployment with 3 replicas that uses a ConfigMap mounted as a volume. After updating the ConfigMap, the developer expects the pods to pick up the new configuration immediately, but the old configuration is still in use. What is the most likely reason?

A.ConfigMap updates are not propagated to mounted volumes.
B.The kubelet sync interval delays the propagation of ConfigMap changes to pods.
C.The pods must be recreated after a ConfigMap update to see the changes.
D.ConfigMaps are immutable and cannot be updated.
AnswerB

The correct explanation is that the kubelet runs a periodic sync loop (commonly every 1 minute, configurable via `--sync-frequency`) that refreshes ConfigMap data into mounted volumes. Until that sync cycle runs, pods continue reading the previous version of the ConfigMap, which is why updates appear delayed. After the sync, the files are updated in place and subsequent reads see the new data.

Why this answer

When a ConfigMap is mounted as a volume, updates to the ConfigMap are eventually propagated to the pods, but not instantly. The kubelet periodically syncs mounted ConfigMaps (default interval is 60 seconds), so there is a delay before pods see the new configuration. This is the most likely reason the old configuration is still in use.

Exam trap

The trap here is that candidates often assume ConfigMap updates are either instant or require pod recreation, but the CKAD exam tests the nuance that mounted volumes are updated with a kubelet sync delay, while environment variables are not updated at all.

How to eliminate wrong answers

Option A is wrong because ConfigMap updates are propagated to mounted volumes — the kubelet does update the files in the volume, but with a sync delay. Option C is wrong because pods do not need to be recreated; the mounted volume is updated in-place by the kubelet, though some applications may require a restart to reload the configuration. Option D is wrong because ConfigMaps are not immutable by default; they can be updated unless explicitly created with the `immutable: true` field.

Full explanation →
3
Multi-Selectmedium

Which TWO of the following are valid fields in a Job spec? (Select TWO.)

Select 2 answers
A.replicas
B.backoffLimit
C.schedule
D.restartPolicy
E.parallelism
AnswersB, E

backoffLimit is a valid field in the Job spec that determines how many retries the Job controller will attempt before marking the Job as failed. Each time a Pod fails, the controller increments the failure count, and when that count exceeds backoffLimit, the Job is considered failed and no further Pods are created. The default value is 6, and setting it to 0 means the Job fails immediately after the first unsuccessful Pod. This field works in conjunction with activeDeadlineSeconds and pod failure policies to control batch job resilience.

Why this answer

Options B (backoffLimit) and E (parallelism) are correct fields in a Job spec. 'backoffLimit' controls the number of retries before marking the Job as failed, and 'parallelism' specifies the maximum number of Pods running in parallel. Option A (replicas) is a field for Deployments, not Jobs. Option C (schedule) is used in CronJobs.

Option D (restartPolicy) is a Pod-level field; in Jobs, the restartPolicy is defaulted to OnFailure or Never but is not a top-level Job spec field.

Full explanation →
4
MCQhard

A security requirement states: 'The container must drop all capabilities and add only NET_BIND_SERVICE'. Which YAML snippet correctly implements this in the securityContext?

A.securityContext: capabilities: drop: ["NET_BIND_SERVICE"] add: [ALL]
B.securityContext: capabilities: drop: [ALL] add: ["NET_BIND_SERVICE"]
C.securityContext: capabilities: add: [ALL] drop: ["NET_BIND_SERVICE"]
D.securityContext: capabilities: "drop ALL; add NET_BIND_SERVICE"
AnswerB

This is correct because drop: [ALL] first removes every capability from the container's effective and bounding sets, and add: ["NET_BIND_SERVICE"] then explicitly grants only the one capability required for binding to privileged ports such as 80 and 443. The resulting container runs with the minimal capability set possible, adhering to the principle of least privilege and satisfying the security requirement.

Why this answer

It first drops all capabilities with `drop: [ALL]` and then explicitly adds only `NET_BIND_SERVICE` via `add: ["NET_BIND_SERVICE"]`. This matches the security requirement exactly: the container starts with no capabilities and gains only the one needed to bind to privileged ports (<1024). In Kubernetes, the order of `drop` and `add` matters — dropping ALL first ensures a clean slate, then adding the specific capability.

Exam trap

The trap here is that candidates often confuse the order of `add` and `drop`, or mistakenly think that dropping `ALL` includes the capability they want to add, leading them to pick options that either drop the needed capability or add too many.

How to eliminate wrong answers

Option A is wrong because it drops `NET_BIND_SERVICE` (the capability that should be added) and adds `ALL` (all capabilities), which violates the requirement to drop all capabilities. Option C is wrong because it adds `ALL` first and then drops `NET_BIND_SERVICE`, resulting in the container having all capabilities except `NET_BIND_SERVICE` — the opposite of what is required. Option D is wrong because it uses an invalid string syntax; Kubernetes `capabilities` must be a structured object with `add` and `drop` lists, not a semicolon-delimited string.

Full explanation →
5
MCQeasy

Refer to the exhibit. A pod named 'app-backend-6b4c9d8f7-2x4z5' is in CrashLoopBackOff state. What is the MOST likely cause of this issue?

A.The container is crashing due to a misconfiguration or application error.
B.The container has exceeded its memory limit and is being OOMKilled.
C.The node running the pod is down, preventing the container from starting.
D.A network policy is blocking the container from accessing required services.
AnswerA

CrashLoopBackOff means the container has started and exited repeatedly with a non-zero exit code, and the kubelet is applying an exponential backoff between restarts. This is typically caused by a misconfiguration—such as a missing ConfigMap value, incorrect environment variable, bad command-line argument, or a malformed config file—or an application-level error like an unhandled panic. Check kubectl logs with --previous to see the actual error message and exit code.

Why this answer

A CrashLoopBackOff state indicates that the container in the pod is repeatedly crashing and being restarted by the kubelet. The most common cause is a misconfiguration (e.g., incorrect environment variables, missing dependencies, or a faulty entrypoint script) or an application error (e.g., a runtime exception or panic). The kubelet detects the crash via the container runtime (e.g., containerd) and applies an exponential backoff delay before restarting, leading to the CrashLoopBackOff status.

Exam trap

CNCF often tests the distinction between CrashLoopBackOff and other pod failure states like OOMKilled or ImagePullBackOff, and the trap here is that candidates may assume any crash is due to resource limits or network issues without checking the specific exit code or pod events.

How to eliminate wrong answers

Option B is wrong because an OOMKilled container would show a status of 'OOMKilled' in the pod's last state, not CrashLoopBackOff; CrashLoopBackOff is a generic restart loop, not a specific resource limit violation. Option C is wrong because if the node were down, the pod would be in 'NodeLost' or 'Unknown' state, and the kubelet would not be able to restart the container; CrashLoopBackOff requires the kubelet to be actively managing the pod. Option D is wrong because a network policy blocking access would cause the application to fail to connect to services, but the container itself would still start and run (possibly with errors), not crash immediately; CrashLoopBackOff implies the container process exits with a non-zero code at startup.

Full explanation →
6
MCQmedium

A developer deploys a Pod that reads configuration from a ConfigMap named 'app-config' using a volume mount at /etc/config. Later, the ConfigMap is updated with new values. The application running in the Pod is designed to re-read the file periodically but continues to see the old values. What is the most likely reason the application is not seeing the updated configuration?

A.The ConfigMap volume is mounted as read-only, preventing updates from being propagated.
B.The Pod was created with the ConfigMap volume mounted using subPath, which prevents automatic updates.
C.The ConfigMap was updated using kubectl edit, which does not trigger a volume refresh.
D.The application is using an environment variable instead of reading the file from the volume mount.
AnswerB

When a ConfigMap volume is mounted with subPath, the kubelet does not receive update events for that specific file, so the content remains static. Without subPath, the kubelet periodically syncs the volume and updates the files. This is a common pitfall when developers use subPath for convenience. The application will continue to see the original values until the Pod is restarted or the volume is remounted without subPath.

Why this answer

ConfigMap volumes mounted without subPath are periodically updated by the kubelet, but when subPath is used, the kubelet does not sync changes to that file. The application re-reads the file but sees stale data because the file content is never refreshed. Removing subPath or restarting the Pod would resolve the issue.

Exam trap

The trap here is assuming that any ConfigMap volume automatically updates, overlooking that subPath mounts are excluded from the kubelet's sync mechanism.

Full explanation →
7
MCQmedium

You have a Deployment with 'replicas: 3' and the HPA is configured with 'targetCPUUtilizationPercentage: 80'. The current CPU usage is at 60% across all pods, but the HPA has scaled up to 5 replicas. What is the most likely reason?

A.The CPU request in the Deployment's resource spec might be set lower than expected, causing the HPA to perceive higher utilization.
B.The HPA has a behavior policy that scales up aggressively
C.The HPA is using the 'averageUtilization' target type on a custom metric, not CPU
D.The HPA is reading the total CPU usage instead of average
AnswerA

If the container's resource requests are set lower than actual usage, the utilization percentage can be higher. For example, if request is 100m but usage is 200m, utilization is 200% even if absolute CPU is low. This could trigger scaling.

Why this answer

The HPA calculates CPU utilization as the average CPU usage across all pods divided by the CPU request of each pod. If the Deployment's container resource requests are set to a value that is lower than expected (e.g., 0.5 CPU instead of 1.0 CPU), then the same absolute CPU usage results in a higher utilization percentage. With 3 pods at 60% actual usage but a low CPU request, the utilization relative to the request could exceed the 80% target, triggering scale-up to 5 replicas.

Therefore, option A is the most likely reason: a mismatch in the CPU request on the Deployment's resource spec causes the HPA to perceive higher utilization.

Full explanation →
8
MCQmedium

A container needs to run with the NET_ADMIN capability. Which securityContext field should be used?

A.capabilities: drop: ["ALL"]
B.capabilities: add: ["NET_ADMIN"]
C.runAsUser: 0
D.readOnlyRootFilesystem: true
AnswerB

This correctly grants the NET_ADMIN capability, which the kernel checks before allowing network administration operations inside the container's network namespace. The capabilities.add list augments the container's default capability set, permitting actions such as modifying iptables rules, adding or removing routes, and managing interface flags. It supplies the needed privilege with precision, following the least-privilege principle by adding only that specific capability.

Why this answer

The `capabilities.add` field in a container's `securityContext` is specifically designed to grant Linux capabilities like `NET_ADMIN` to a container. This allows the container to perform network administration operations (e.g., configuring iptables, changing interface settings) without running as root or giving full privileged access.

Exam trap

The trap here is that candidates often confuse `capabilities.add` with `capabilities.drop` or assume that running as root (`runAsUser: 0`) is the only way to gain network admin privileges, missing the precise capability-based approach that CKAD expects.

How to eliminate wrong answers

Option A is wrong because `capabilities.drop: ["ALL"]` removes all capabilities, which would prevent the container from using `NET_ADMIN`; it's the opposite of what is needed. Option C is wrong because `runAsUser: 0` runs the container as root, which is an overly broad and insecure approach that grants all capabilities, not just `NET_ADMIN`, and is not the recommended way to add a specific capability. Option D is wrong because `readOnlyRootFilesystem: true` only makes the container's root filesystem read-only for security hardening and has no effect on Linux capabilities or network administration permissions.

Full explanation →
9
MCQmedium

A developer runs `kubectl expose deployment web-deploy --port=80 --target-port=8080 --type=NodePort` and later wants to access the Service from outside the cluster. What is the correct way to find the external port?

A.Run `kubectl get nodes -o wide` and use the node's external IP and port 80.
B.Run `kubectl get pod -l app=web-deploy` and use the pod IP with port 8080.
C.Run `kubectl describe svc web-deploy` and look for the NodePort field.
D.Run `kubectl get svc web-deploy -o yaml` and look for `spec.ports[0].port`.
AnswerC

`kubectl describe svc web-deploy` presents a human-readable summary that includes the NodePort mapping in its 'Port:' section, e.g., `web-deploy 80:31000/TCP`. This shows that the Service listens on port 80 internally and is exposed on port 31000 (NodePort) on every node. Because the NodePort is explicitly labeled and calculated, it is the most direct way to find the externally accessible port.

Why this answer

`kubectl expose` with `--type=NodePort` creates a Service that maps a high-port (30000-32767) on each cluster node to the target container port. The `kubectl describe svc web-deploy` output includes the `NodePort` field, which shows this externally accessible port. To reach the Service from outside the cluster, you must use the node's external IP combined with this NodePort, not the Service's cluster-internal port (80).

Exam trap

The trap here is that candidates confuse the Service's cluster-internal port (80) with the externally accessible NodePort, or mistakenly think pod IPs are stable enough for external access, when in fact the NodePort field in the Service description is the only reliable way to find the external port.

How to eliminate wrong answers

Option A is wrong because it suggests using port 80, which is the Service's cluster-internal port, not the externally accessible NodePort; NodePort services expose a random high port (30000-32767) on each node, not the Service port. Option B is wrong because pod IPs are ephemeral and only reachable from within the cluster; using a pod IP with port 8080 bypasses the Service abstraction and fails if the pod is recreated. Option D is wrong because `spec.ports[0].port` refers to the Service's cluster-internal port (80), not the NodePort; the correct field in the YAML is `spec.ports[0].nodePort`.

Full explanation →
10
MCQeasy

Which command scales a Deployment named 'web' to 5 replicas?

A.kubectl set replicas deployment web 5
B.kubectl scale deployment web --replicas=5
C.kubectl resize deployment web --replicas=5
D.kubectl autoscale deployment web --replicas=5
AnswerB

This is the canonical imperative command to manually change the DesiredReplicas field of a deployment. `kubectl scale` works on deployments, replication controllers, replica sets, and stateful sets, and the `--replicas=` flag explicitly sets the target count. It is the correct way to immediately scale a deployment without altering any other spec.

Why this answer

The correct command to scale a Deployment to a specific number of replicas is `kubectl scale deployment web --replicas=5`. This command directly modifies the `spec.replicas` field of the Deployment object, instructing the Kubernetes controller manager to adjust the number of running Pods to match the desired count.

Exam trap

The trap here is that candidates confuse `kubectl scale` (which sets a static replica count) with `kubectl autoscale` (which creates an HPA for dynamic scaling), or they invent non-existent commands like `kubectl set replicas` or `kubectl resize`.

How to eliminate wrong answers

Option A is wrong because `kubectl set replicas` is not a valid kubectl command; the correct verb is `scale`, not `set`. Option C is wrong because `kubectl resize` does not exist in kubectl; scaling is performed via the `scale` subcommand. Option D is wrong because `kubectl autoscale` creates a HorizontalPodAutoscaler (HPA) that dynamically adjusts replicas based on metrics, not a static replica count; it requires a target metric (e.g., CPU utilization) and does not directly set replicas to 5.

Full explanation →
11
MCQhard

You create a ServiceAccount 'my-sa' with automountServiceAccountToken: false. A pod that references this ServiceAccount also sets automountServiceAccountToken: true in its spec. Will the service account token be mounted?

A.Yes, because the pod spec setting takes precedence.
B.No, because the ServiceAccount has automountServiceAccountToken: false, which is a hard block.
C.It depends on the namespace default settings.
D.No, because the ServiceAccount setting overrides the pod setting.
AnswerA

In Kubernetes, the pod specification is the most authoritative source for pod-level settings. When a pod explicitly sets automountServiceAccountToken, that value overrides the automountServiceAccountToken field defined on the referenced ServiceAccount. This is by design: the ServiceAccount provides defaults, but the pod author retains final control over how the token is mounted. Therefore, even if the ServiceAccount has automountServiceAccountToken: false, a pod with automountServiceAccountToken: true will still have the token mounted.

Why this answer

The pod spec's `automountServiceAccountToken: true` takes precedence over the ServiceAccount's `automountServiceAccountToken: false`. Kubernetes merges the ServiceAccount and pod-level settings, with the pod-level setting overriding the ServiceAccount's setting. Therefore, the token will be mounted into the pod.

Exam trap

CNCF often tests the precedence rule between ServiceAccount and pod-level settings, expecting candidates to incorrectly assume the ServiceAccount setting is authoritative or that the most restrictive setting wins.

How to eliminate wrong answers

Option B is wrong because `automountServiceAccountToken: false` on the ServiceAccount is not a hard block; it is a default that can be overridden by the pod spec. Option C is wrong because namespace default settings (e.g., via an admission controller or defaulting webhook) do not override explicit pod-level settings; the pod spec's explicit value takes precedence. Option D is wrong because the pod-level setting overrides the ServiceAccount setting, not the other way around.

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

The process runs as UID 1000 and GID 2000, satisfying the pod's runAsUser and runAsGroup constraints. fsGroup 3000 only affects volume ownership and supplementary group membership for mounted filesystems; it does not override the primary GID. The container's main process therefore keeps GID 2000 as its primary group.

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 →
13
Matchingmedium

Match each Kubernetes probe to its check behavior.

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

Concepts
Matches

Runs a command inside the container; success if exit 0

Performs an HTTP GET request; success if 2xx-3xx

Attempts to open a TCP socket; success if connection established

Performs a gRPC health check (alpha)

Indicates whether the application has started successfully

Why these pairings

Liveness probes check if a container is running (if they fail, the container is restarted). Readiness probes check if a container is ready to serve traffic (if they fail, traffic is not routed to it). Startup probes check if an application has started, used mainly for slow-starting containers.

Full explanation →
14
MCQmedium

A pod is stuck in 'Pending' state. You run 'kubectl describe pod my-pod' and see the event: '0/3 nodes are available: 3 Insufficient cpu.' Which action should you take?

A.Increase the CPU limits on the pod to give it more resources.
B.Reduce the CPU request of the pod and reapply the manifest.
C.Add another node to the cluster to increase overall CPU capacity.
D.Add a nodeSelector to the pod to target a specific node.
AnswerB

The scheduler places pods on nodes using the CPU request as the reservation; a pending pod with 'Insufficient cpu' events has a request larger than any node's free capacity. Reducing the CPU request in the pod spec to fit within an existing node's available allocatable CPU allows the scheduler to find a suitable node, and reapply the manifest (via kubectl replace -f or delete/recreate) so the pod is re-created with the lowered request. This directly addresses the root cause and is faster than infrastructure changes.

Why this answer

The pod is stuck in 'Pending' because the scheduler cannot find a node with enough allocatable CPU to satisfy the pod's CPU request. Reducing the CPU request (the amount guaranteed to the container) makes the pod schedulable on existing nodes. Increasing limits would only worsen the problem, as limits are a cap on usage, not a scheduling constraint.

Exam trap

The trap here is that candidates confuse CPU requests with CPU limits, assuming that increasing limits gives the pod more resources, when in fact the scheduler only checks requests for admission, and limits are a runtime constraint.

How to eliminate wrong answers

Option A is wrong because increasing CPU limits does not affect scheduling; the scheduler only considers requests, not limits. Option C is wrong because adding a node is an operational overhead and not the immediate fix; the issue is that the pod's request is too high for the current cluster capacity. Option D is wrong because a nodeSelector targets a specific node but does not resolve the underlying resource insufficiency; if no node has enough CPU, the pod will still remain Pending.

Full explanation →
15
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 →
16
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 →
17
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 →
18
MCQhard

A team uses a Service named 'backend' in namespace 'prod' to reach Pods in namespace 'staging'. The Service in 'prod' has no endpoints. What is the most likely cause?

A.The Service port name does not match the container port
B.The Service selector does not match any Pods in the same namespace
C.The Service type is ClusterIP but should be NodePort
D.DNS resolution is broken in the staging namespace
AnswerB

A Kubernetes Service's selector is strictly namespace-scoped: it only matches Pods that have the same labels AND are in the same namespace as the Service. If no Pod in the 'prod' namespace carries the labels defined in the Service's 'spec.selector', the Endpoints and EndpointSlice controllers find zero backing Pods, resulting in an empty endpoints list. As a consequence, even though DNS resolves the Service's ClusterIP, any connection attempt to that IP gets no forwarding target and fails with a connection refused or timeout. This is the correct explanation because it directly addresses why no endpoints exist for the Service.

Why this answer

The Service in the 'prod' namespace has no endpoints because its selector does not match any Pods in the same namespace. Kubernetes Services only discover Pods within the same namespace via label selectors; cross-namespace access requires a different approach (e.g., ExternalName Service or manual endpoint configuration). Since the Pods are in 'staging', the selector in 'prod' finds no matching Pods, resulting in zero endpoints.

Exam trap

The trap here is that candidates assume Services can automatically discover Pods across namespaces, but Kubernetes restricts Service selectors to the same namespace, so a Service in 'prod' cannot select Pods in 'staging' without manual endpoint configuration.

How to eliminate wrong answers

Option A is wrong because a port name mismatch would cause connectivity issues but would not prevent the Service from having endpoints—endpoints are generated based on selector matches, not port names. Option C is wrong because Service type (ClusterIP vs. NodePort) affects external accessibility, not endpoint population; a ClusterIP Service can still have endpoints if the selector matches Pods.

Option D is wrong because DNS resolution is irrelevant to endpoint creation; endpoints are populated by the kube-controller-manager based on selector matching, not DNS.

Full explanation →
19
MCQeasy

A developer needs to create a Kubernetes Secret for Docker registry authentication. The registry URL is 'myregistry.io', username 'user', password 'pass', email 'user@example.com'. Which command creates this Secret?

A.kubectl create secret tls regcred --cert=cert --key=key
B.kubectl create secret generic regcred --from-literal=username=user --from-literal=password=pass
C.kubectl create secret registry regcred --server=myregistry.io --username=user --password=pass
D.kubectl create secret docker-registry regcred --docker-server=myregistry.io --docker-username=user --docker-password=pass --docker-email=user@example.com
AnswerD

This uses the dedicated docker-registry subcommand, which generates a kubernetes.io/dockerconfigjson Secret. Under the hood it constructs a .dockerconfigjson key containing a JSON object with an auths map, where the registry server is mapped to base64-encoded credentials (username:password). The resulting value is exactly what kubelet expects when a pod references this secret via imagePullSecrets, so the private registry becomes accessible for pulling images.

Why this answer

`kubectl create secret docker-registry` is the dedicated command for creating a Docker registry authentication secret, which automatically encodes the provided credentials into a `.dockerconfigjson` format. This secret type is specifically designed for pulling images from private registries, and the flags `--docker-server`, `--docker-username`, `--docker-password`, and `--docker-email` match the required fields for registry authentication.

Exam trap

The trap here is that candidates may confuse the generic `kubectl create secret generic` command with the specialized `docker-registry` subcommand, or they may misremember the exact subcommand name as `registry` instead of `docker-registry`, leading them to pick option B or C.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret tls` creates a TLS secret for storing certificates and keys, not Docker registry credentials. Option B is wrong because `kubectl create secret generic` creates a generic Opaque secret with arbitrary key-value pairs, but it does not produce the `.dockerconfigjson` format required by Kubernetes for image pull secrets, and it lacks the registry server and email fields. Option C is wrong because `kubectl create secret registry` is not a valid kubectl command; the correct subcommand is `docker-registry`, not `registry`.

Full explanation →
20
MCQeasy

A DevOps engineer needs to set up resource monitoring for pods in a namespace. Which built-in Kubernetes resource provides CPU and memory metrics out-of-the-box?

A.Metrics Server
B.Prometheus
C.CoreDNS
D.Kubernetes Dashboard
AnswerA

Metrics Server is the correct choice because it is a built-in cluster addon that aggregates resource usage metrics (CPU and memory) per node and pod from kubelet's Summary API via the Metrics API. It provides these lightweight, in-memory metrics to `kubectl top` and the Horizontal Pod Autoscaler (HPA) without needing external storage. Being cluster-native and automatically available on most managed Kubernetes distributions, it is the standard zero-configuration tool for basic resource monitoring.

Why this answer

The Metrics Server is the built-in Kubernetes resource that collects resource metrics (CPU and memory) from the kubelet on each node via the Summary API and exposes them through the metrics.k8s.io API. It provides these metrics out-of-the-box without requiring any additional configuration or external storage, making it the standard solution for horizontal pod autoscaling and kubectl top commands.

Exam trap

CNCF often tests the distinction between built-in Kubernetes components and third-party add-ons, so candidates may mistakenly choose Prometheus because it is a popular monitoring tool, but the question specifically asks for a built-in resource that provides metrics out-of-the-box.

How to eliminate wrong answers

Option B is wrong because Prometheus is a third-party monitoring system that is not built into Kubernetes; it requires separate installation and configuration, and while it can scrape metrics, it is not the built-in resource for CPU and memory metrics. Option C is wrong because CoreDNS is a DNS server for service discovery within the cluster, not a metrics provider; it has no capability to expose CPU or memory metrics. Option D is wrong because Kubernetes Dashboard is a web UI for managing the cluster, not a metrics source; it relies on the Metrics Server or another backend to display resource usage data.

Full explanation →
21
MCQeasy

Which command creates an Opaque Secret named 'my-secret' with key 'password' and value 'p@ssw0rd'?

A.kubectl create secret tls my-secret --cert=cert.pem --key=key.pem
B.kubectl create secret generic my-secret --from-literal=password
C.kubectl create secret generic my-secret --from-literal=p@ssw0rd=password
D.kubectl create secret generic my-secret --from-literal=password=p@ssw0rd
AnswerD

This is the correct command because `generic` creates the default `Opaque` Secret type, and `--from-literal=password=p@ssw0rd` explicitly defines a data entry with key `password` and value `p@ssw0rd`. Kubectl will automatically base64-encode the literal value when the Secret object is stored in etcd. The syntax follows the required `key=value` format, making it the only valid option.

Why this answer

`kubectl create secret generic` creates an Opaque secret, and the `--from-literal=key=value` syntax correctly assigns the literal value 'p@ssw0rd' to the key 'password'. This produces a secret with the specified key-value pair.

Exam trap

The trap here is that candidates may confuse the order of key and value in the `--from-literal` syntax, or mistakenly use a different secret type like TLS or docker-registry, which have specific purposes and required flags.

How to eliminate wrong answers

Option A is wrong because `kubectl create secret tls` creates a TLS secret (type kubernetes.io/tls), not an Opaque secret, and requires certificate and key files. Option B is wrong because `--from-literal=password` lacks the `=value` part, so it would fail with an error about invalid literal format. Option C is wrong because it reverses the key and value, setting key 'p@ssw0rd' with value 'password', which does not match the requirement.

Full explanation →
22
MCQhard

Given the following NetworkPolicy YAML: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress - Egress What is the effect of this policy?

A.Denies all ingress and egress traffic to and from all pods in the namespace
B.Denies all ingress traffic but allows all egress traffic
C.Allows all traffic to and from pods in the namespace
D.Denies all traffic except traffic that is explicitly allowed by other policies
AnswerA

This NetworkPolicy explicitly sets both policyTypes (Ingress and Egress) but includes no allow rules. In Kubernetes, an empty rules list for a given policyType creates a default-deny for that direction, so all inbound and outbound traffic is blocked. Since the policy's podSelector matches every pod in the namespace, it establishes a complete default-deny boundary for the entire namespace.

Why this answer

This NetworkPolicy uses an empty `podSelector: {}` which selects all pods in the namespace. By specifying both `Ingress` and `Egress` in `policyTypes` without any `ingress` or `egress` rules, the policy defaults to denying all ingress and egress traffic. In Kubernetes, NetworkPolicy rules are additive (allow-listed), so an empty rules list means no traffic is permitted, effectively creating a default-deny for both directions.

Exam trap

The trap here is that candidates often think an empty `podSelector: {}` with no rules means 'no policy' or 'allow all', but in Kubernetes, a NetworkPolicy with an empty rules list defaults to deny, not allow.

How to eliminate wrong answers

Option B is wrong because the policy explicitly includes `Egress` in `policyTypes` with no egress rules, which denies all egress traffic, not just ingress. Option C is wrong because a NetworkPolicy with an empty podSelector and no rules denies traffic, it does not allow it; allowing all traffic would require no NetworkPolicy at all or explicit allow rules. Option D is wrong because NetworkPolicies are additive—if this deny-all policy exists, it blocks all traffic regardless of other policies; other policies can only add exceptions, but the default-deny still applies to any traffic not explicitly allowed.

Full explanation →
23
MCQeasy

A team wants a Pod to expose two containers: a web server container listening on port 8080 and a metrics exporter container listening on port 9100. The Pod manifest must give each container its own containerPort so that monitoring tools can discover them. Which YAML snippet correctly declares both container ports in a single Pod?

A.spec: containers: - name: web image: nginx ports: - containerPort: 8080 - name: metrics image: exporter ports: - containerPort: 9100
B.spec: containers: - name: web image: nginx ports: - name: web port: 8080 - name: metrics image: exporter ports: - name: metrics port: 9100
C.spec: containers: - name: web image: nginx ports: - containerPort: 8080 - containerPort: 9100 - name: metrics image: exporter
D.spec: containers: - name: web image: nginx - name: metrics image: exporter ports: - containerPort: 8080 - containerPort: 9100
AnswerA

Each container in the Pod has its own ports list, and containerPort is declared per container. This snippet defines two containers, each with the appropriate containerPort, which matches the requirement that the web server and metrics exporter advertise ports 8080 and 9100 respectively.

Why this answer

Container ports belong inside each container's ports list under the Pod spec. Declaring containerPort 8080 for the web container and 9100 for the metrics container correctly describes two separate listeners in one Pod, matching the requirement for per-container port declarations.

Exam trap

The trap here is confusing Pod-level or Service-level port fields with the per-container containerPort field required in a Pod manifest.

Full explanation →
24
MCQmedium

Which annotation is used to enforce Pod Security Admission at the 'restricted' level on a namespace?

A.pod-security.kubernetes.io/enforce: restricted
B.pod-security.kubernetes.io/warn: restricted
C.pod-security.kubernetes.io/enforce: baseline
D.pod-security.kubernetes.io/audit: restricted
AnswerA

The `pod-security.kubernetes.io/enforce: restricted` annotation is the correct mechanism to actively enforce the strictest Pod Security Standard. When a namespace carries this label, the Pod Security Admission controller rejects any pod that fails the restricted policy, preventing its creation. This is the only option that both blocks violating resources and mandates the most hardened security posture, covering privileged containers, host namespaces, and other high-risk settings.

Why this answer

The `pod-security.kubernetes.io/enforce` annotation enforces Pod Security Standards (PSS) at the namespace level, and setting it to `restricted` blocks any pod that violates the most stringent set of security controls (e.g., running as root, privileged containers). This is the only annotation that actively prevents non-compliant pods from being created, rather than just warning or logging violations.

Exam trap

The trap here is that candidates confuse the `enforce` mode (which blocks non-compliant pods) with the `warn` or `audit` modes (which only notify or log), and may also mistakenly choose `baseline` thinking it is the highest security level, when in fact `restricted` is the most stringent.

How to eliminate wrong answers

Option B is wrong because `pod-security.kubernetes.io/warn: restricted` only generates a warning message when a pod violates the restricted profile, but does not block the pod from being created. Option C is wrong because `pod-security.kubernetes.io/enforce: baseline` enforces the baseline level, which is less restrictive than restricted (e.g., it allows some privileged capabilities that restricted forbids). Option D is wrong because `pod-security.kubernetes.io/audit: restricted` only logs violations to the audit log without preventing pod creation or issuing warnings.

Full explanation →
25
MCQmedium

You are performing a rolling update of a Deployment. You set maxSurge=2 and maxUnavailable=1. The Deployment has 5 replicas. During the update, how many pods can be running simultaneously?

A.7
B.6
C.10
D.5
AnswerA

7 is correct because during a rolling update with a desired replica count of 5 and a maxSurge set to 2, Kubernetes is allowed to create up to 2 additional pods above the desired count. This surge capacity means the absolute maximum number of pods that can be running simultaneously is 5 + 2 = 7. The deployment controller uses this headroom to bring up new pods before terminating old ones, ensuring zero downtime and a smooth transition.

Why this answer

During a rolling update, maxSurge=2 allows up to 2 extra pods beyond the desired replicas, and maxUnavailable=1 allows at most 1 pod to be unavailable. With a desired count of 5, the maximum running pods is 5 (desired) + 2 (surge) = 7, because the surge pods are created before old ones are terminated, and the unavailable limit does not cap the total running count.

Exam trap

The trap here is that candidates often confuse maxUnavailable as a cap on total running pods, when in fact it only limits how many pods can be in a non-running state (e.g., terminating or pending), while maxSurge independently controls the extra pods above the desired count.

How to eliminate wrong answers

Option B (6) is wrong because it underestimates the surge capacity; maxSurge=2 adds 2 extra pods, not 1. Option C (10) is wrong because it incorrectly assumes maxSurge and maxUnavailable are additive limits on total pods, but maxUnavailable caps unavailable pods, not total running pods. Option D (5) is wrong because it ignores the maxSurge setting entirely, treating the update as if no extra pods are allowed.

Full explanation →
26
Multi-Selectmedium

Which two statements about ConfigMaps and Secrets are correct? (Select TWO.)

Select 2 answers
A.Secrets store data in base64-encoded form, while ConfigMaps store plaintext
B.Both ConfigMaps and Secrets can be consumed as environment variables or mounted as volumes
C.ConfigMaps are immutable and cannot be updated after creation
D.ConfigMaps are suitable for storing sensitive data like passwords
E.Secrets are encrypted at rest by default in Kubernetes
AnswersA, B

Secrets use base64 encoding on their data fields, which is simply an encoding scheme, not encryption—anyone with access to the Secret object can decode it trivially. ConfigMaps store their data as literal plaintext strings in the API object, making them readable directly. This distinction is a primary reason why Secrets are intended for sensitive data, even though base64 does not provide real confidentiality by itself.

Why this answer

Secrets store data as base64-encoded strings, which is not encryption but a simple encoding that obscures the data. ConfigMaps store data in plaintext (UTF-8) without any encoding. This distinction is fundamental: base64 encoding is reversible and provides no security, while plaintext is human-readable.

Exam trap

CNCF often tests the misconception that base64 encoding is a form of encryption, leading candidates to think Secrets are secure by default, or that ConfigMaps are immutable — the trap is assuming default immutability or confusing encoding with encryption.

Full explanation →
27
MCQmedium

A Pod is in 'CrashLoopBackOff' state. 'kubectl logs mypod' shows: 'Error: listen tcp :8080: bind: address already in use'. What is the most likely cause?

A.The pod's resource limits are too low
B.The container's application is attempting to use a port that is already occupied
C.The pod's ServiceAccount token is not mounted
D.The pod is using a readOnlyRootFilesystem
AnswerB

The logs for the container show an error such as 'listen tcp :8080: bind: address already in use' (or EADDRINUSE), which means the application process could not bind to its configured port because another process on the same network namespace already holds that port. Each pod shares one network namespace among its containers, so either another container in the pod, a host process at the node layer, or a previous instance still in the namespace is occupying the socket. This prevents the application from starting and causes the container to exit, leading Kubernetes to restart it with an exponential backoff, producing CrashLoopBackOff.

Why this answer

The error 'listen tcp :8080: bind: address already in use' indicates that the container's application is trying to bind to port 8080, but that port is already occupied by another process within the same network namespace (typically the same Pod or container). This is a classic port conflict, not a resource or permission issue, making option B correct.

Exam trap

The trap here is that candidates may confuse 'CrashLoopBackOff' with resource exhaustion (option A) or filesystem issues (option D), but the specific error message 'bind: address already in use' directly points to a port conflict, not resource limits or permissions.

How to eliminate wrong answers

Option A is wrong because resource limits (CPU/memory) cause OOMKilled or CPU throttling, not a 'bind: address already in use' error. Option C is wrong because a missing ServiceAccount token would cause authentication failures (e.g., 403 Forbidden) when accessing the Kubernetes API, not a port binding error. Option D is wrong because readOnlyRootFilesystem prevents writing to the container's filesystem, leading to errors like 'read-only file system', not port binding conflicts.

Full explanation →
28
MCQmedium

When using 'kubectl expose', which flag creates a NodePort service?

A.--node-port
B.--type=NodePort
C.--type=ClusterIP
D.--port
AnswerB

Passing --type=NodePort to kubectl expose creates a Service of type NodePort, which opens a high-numbered port (default 30000-32767) on every node in the cluster and forwards traffic from that nodePort to the Service's clusterIP and then to the selected pods. This makes the workload reachable externally via any node's IP and that designated port, which is the only correct flag for the stated goal.

Why this answer

The `--type=NodePort` flag explicitly sets the service type to NodePort when using `kubectl expose`. This creates a service that exposes the application on a static port (30000-32767) on each cluster node, making it accessible externally via `<NodeIP>:<NodePort>`. Without this flag, the default service type is ClusterIP, which is only reachable within the cluster.

Exam trap

The trap here is that candidates often confuse `--node-port` (which sets the specific port number) with the flag that actually creates the NodePort service type, or they assume `--port` alone changes the service type, when in fact `--type=NodePort` is required to override the default ClusterIP.

How to eliminate wrong answers

Option A is wrong because `--node-port` is not a valid flag for `kubectl expose`; the correct flag to specify the NodePort number is `--node-port` only when combined with `--type=NodePort`, but it does not create a NodePort service by itself. Option C is wrong because `--type=ClusterIP` creates a ClusterIP service, which is the default and only exposes the service internally within the cluster, not externally. Option D is wrong because `--port` specifies the container port the service will forward traffic to, not the service type; it is a required flag for `kubectl expose` but does not determine whether the service is NodePort.

Full explanation →
29
Multi-Selecthard

Which THREE of the following are true about the 'kubectl describe pod' output? (Select 3)

Select 3 answers
A.It shows the exact resource requests and limits of each container
B.It shows the last few lines of the container logs
C.It shows recent events related to the pod
D.It shows the current CPU and memory usage of the pod
E.It shows the node name where the pod is scheduled
AnswersA, C, E

In the 'Containers' section of 'kubectl describe pod', you'll find a 'Limits' and 'Requests' line for each container, mirroring the resource requirements defined in the pod's YAML. These show the CPU and memory requests and limits that affect scheduling decisions and QoS class. Hence, this is a true capability of describe.

Why this answer

kubectl describe pod provides static configuration details and recent events. It shows resource requests and limits per container (A), recent pod events (C), and the node name where the pod is scheduled (E). It does not show container logs (B) or current CPU/memory usage (D).

Exam trap

The CKAD exam often tests the distinction between static configuration (requests/limits) shown in `describe` and dynamic metrics (CPU/memory usage) shown in `top` or `metrics-server`, causing candidates to confuse the two.

Full explanation →
30
Multi-Selecteasy

Which TWO of the following are valid Ingress path types? (Select 2)

Select 2 answers
A.Glob
B.Exact
C.Wildcard
D.Regex
E.Prefix
AnswersB, E

Exact is one of the two valid standard pathType values in the Kubernetes Ingress spec. It matches only the precise URL path, and matching is case-sensitive, meaning /foo does not match /Foo or /foo/. This pathType is ideal for explicit API endpoints where a route must be limited to a single URI without inadvertently catching deeper subpaths.

Why this answer

In Kubernetes Ingress, the `spec.rules.http.paths[].pathType` field supports two valid types: `Exact` and `Prefix`. `Exact` matches the URL path exactly, case-sensitive, and is used when you need a precise match without any wildcard or prefix behavior.

Exam trap

The CKAD exam often tests the distinction between path types and host-based routing, leading candidates to confuse wildcard hostnames (e.g., `*.example.com`) with path types, or to assume regex/glob patterns are supported when they are not.

Full explanation →
31
MCQeasy

You have a Deployment with the following strategy: type: Recreate. What happens when you update the pod template?

A.Old pods are terminated first, then new pods are created
B.New pods are created first, then old pods are terminated
C.Pods are updated in-place without termination
D.The update is rejected because Recreate is not a valid strategy
AnswerA

In a Recreate strategy, the Deployment controller first scales the old ReplicaSet down to zero and waits for all old pods to terminate completely. Only after a clean shutdown does it create the new ReplicaSet and its pods. This guarantees that no two versions of the application ever run concurrently, but it intentionally introduces downtime during the transition.

Why this answer

The Recreate strategy in a Kubernetes Deployment first terminates all existing Pods before creating new ones. When the pod template is updated, the Deployment controller scales down the ReplicaSet to 0 replicas, waits for all Pods to terminate, then scales up the new ReplicaSet to the desired number of replicas. This ensures zero overlap between old and new Pods, which is useful for workloads that cannot run concurrently.

Exam trap

The trap here is that candidates confuse Recreate with RollingUpdate, assuming new Pods are always created first to minimize downtime, but Recreate deliberately sacrifices availability for safety by terminating all old Pods before starting new ones.

How to eliminate wrong answers

Option B is wrong because it describes the RollingUpdate strategy, where new Pods are created first and old Pods are terminated gradually to maintain availability. Option C is wrong because Kubernetes Pods are immutable; updates to the pod template always require Pod recreation, not in-place updates. Option D is wrong because Recreate is a valid and documented Deployment strategy type in Kubernetes, explicitly supported in the apps/v1 API.

Full explanation →
32
MCQmedium

An administrator needs to create a ConfigMap named 'app-config' from a file called 'config.properties'. Which kubectl command accomplishes this?

A.kubectl create configmap app-config --from-literal=config.properties
B.kubectl create configmap app-config --from-file=config.properties
C.kubectl create configmap app-config --from-env-file=config.properties
D.kubectl create configmap app-config --from-file=key1=config.properties
AnswerB

--from-file reads the file and stores its entire content under the key equal to the file's basename (config.properties). This preserves the raw file data as a single entry in the ConfigMap, which is exactly what an application expecting a properties file would read.

Why this answer

`kubectl create configmap app-config --from-file=config.properties` reads the file `config.properties` and creates a ConfigMap where the key is the filename (config.properties) and the value is the file's content. This is the standard way to create a ConfigMap from a single file in Kubernetes.

Exam trap

The trap here is confusing `--from-file` (which stores the file content as a single value) with `--from-env-file` (which parses key-value pairs) or `--from-literal` (which expects inline key=value syntax), leading candidates to choose options that either misinterpret the file format or incorrectly specify the key.

How to eliminate wrong answers

Option A is wrong because `--from-literal` expects a key=value pair directly in the command, not a filename; it would treat 'config.properties' as a literal string, not a file. Option C is wrong because `--from-env-file` is used to import a file containing key=value pairs (one per line) to create multiple entries, not to store the entire file content as a single value. Option D is wrong because `--from-file=key1=config.properties` would create a ConfigMap with the key 'key1' and the content of the file, but the requirement is to use the filename as the key, not a custom key.

Full explanation →
33
MCQeasy

Which command exposes a deployment named 'web' as a ClusterIP service on port 80?

A.kubectl create service clusterip web --port=80
B.kubectl expose deployment web --port=80
C.kubectl run web --expose --port=80
D.kubectl expose deployment web --port=80 --type=NodePort
AnswerB

kubectl expose deployment web --port=80 is correct because kubectl expose is the canonical command for generating a Service from an existing workload resource, and it defaults to type ClusterIP. It automatically reads the deployment's label selector and applies those same labels to the service's spec.selector, ensuring the Service immediately routes traffic to the deployment's pods. The --port=80 flag sets the service port, and since --target-port is omitted, it defaults to the same value (80), so pod port 80 receives the traffic. This provides the simplest, standard way to create a ClusterIP service that exposes the deployment.

Why this answer

`kubectl expose deployment web --port=80` creates a ClusterIP service by default, which exposes the deployment on port 80 within the cluster. The `expose` command automatically selects the deployment's pod labels and creates a service that maps port 80 to the target port (defaulting to the same port).

Exam trap

Candidates often confuse `kubectl expose` with `kubectl create service clusterip`. The key difference: `expose` automatically derives the label selector from the deployment's pod template, ensuring the service matches the deployment's pods. `create service clusterip` sets a generic selector (e.g., `app=<service-name>`) based on the service name; this may or may not match the deployment's labels, so it may not expose the deployment correctly unless the deployment happens to use the same labels.

How to eliminate wrong answers

Option A is wrong because `kubectl create service clusterip web --port=80` creates a ClusterIP service but does not link it to the deployment's pod selectors; it creates an orphaned service without proper label selectors, so it won't route traffic to the deployment's pods. Option C is wrong because `kubectl run web --expose --port=80` is a legacy command that creates a deployment and a service simultaneously, but it is deprecated and not the standard way to expose an existing deployment; it also defaults to creating a ClusterIP service but does not match the requirement of exposing an already existing deployment named 'web'. Option D is wrong because `kubectl expose deployment web --port=80 --type=NodePort` creates a NodePort service, not a ClusterIP service; the question explicitly requires a ClusterIP service, and NodePort is a different service type that also exposes the service externally on a node port.

Full explanation →
34
MCQmedium

A developer wants to ensure that a container runs as a non-root user and the filesystem is read-only except for a tmpfs volume. Which fields should be set in the container's securityContext?

A.runAsUser: 1000 and readOnlyRootFilesystem: true
B.runAsNonRoot: true and privileged: false
C.runAsNonRoot: true and readOnlyRootFilesystem: true
D.allowPrivilegeEscalation: false and readOnlyRootFilesystem: true
AnswerC

runAsNonRoot: true instructs Kubernetes to verify that the container's user ID is non-zero before starting, and it rejects the pod if the image would run as root or if no non-root user is specified. readOnlyRootFilesystem: true forces the container's root filesystem to be mounted read-only, so even a compromised non-root process cannot write to system directories. Together these two settings directly address both requirements: a non-root process with a read-only root filesystem.

Why this answer

`runAsNonRoot: true` enforces that the container cannot run as the root user (UID 0), and `readOnlyRootFilesystem: true` makes the container's filesystem read-only except for volumes explicitly mounted as writable, such as a tmpfs volume. Together, these fields satisfy the requirement of a non-root container with a read-only filesystem except for a tmpfs mount.

Exam trap

CNCF often tests the distinction between `runAsUser` (which sets a UID but does not enforce non-root) and `runAsNonRoot` (which enforces non-root but does not set a UID), leading candidates to pick Option A when they only need to ensure non-root, not a specific UID.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` sets a specific UID but does not enforce that the container runs as a non-root user (the image could still run as root if the UID is not respected), and it lacks `runAsNonRoot: true` which is required to guarantee non-root execution. Option B is wrong because `privileged: false` is the default and does not enforce non-root execution, and `runAsNonRoot: true` alone does not make the filesystem read-only. Option D is wrong because `allowPrivilegeEscalation: false` only prevents privilege escalation (e.g., via setuid binaries) but does not ensure the container runs as a non-root user, and while `readOnlyRootFilesystem: true` is correct, the missing `runAsNonRoot: true` fails the non-root requirement.

Full explanation →
35
MCQeasy

What is the purpose of a readiness probe?

A.To restart the container if it becomes unresponsive
B.To indicate whether the container is ready to serve traffic
C.To indicate that the container has started successfully
D.To measure the resource usage of the container
AnswerB

A readiness probe tells the kubelet whether the application inside the container is ready to accept incoming requests. When the probe succeeds, the pod is added to the endpoints of Services that select it; when it fails, the pod is removed from those endpoints without being terminated. This prevents clients from sending traffic to pods that are still starting up or are temporarily overloaded.

Why this answer

A readiness probe determines whether a container is ready to accept traffic. If the probe fails, the Pod's IP address is removed from the Endpoints of the associated Service, preventing traffic from being routed to an unready container. This is distinct from liveness probes, which restart containers, and startup probes, which indicate successful initialization.

Exam trap

The trap here is confusing readiness probes with liveness probes, as both are health checks, but readiness probes control traffic routing while liveness probes trigger container restarts.

How to eliminate wrong answers

Option A is wrong because restarting an unresponsive container is the purpose of a liveness probe, not a readiness probe. Option C is wrong because indicating that the container has started successfully is the purpose of a startup probe, which is used for slow-starting containers to delay liveness checks. Option D is wrong because measuring resource usage is done by metrics servers or resource monitoring tools (e.g., cAdvisor, Prometheus), not by probes.

Full explanation →
36
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 allocates a static port on every node's IP and forwards traffic to the backing Pods, satisfying the requirement to expose Pods on a specific port on each node. ClusterIP and LoadBalancer do not provide per-node port exposure.

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 →
37
MCQhard

You are using Kustomize with a base and an overlay. The base sets a Deployment's replicas to 3. The overlay sets replicas to 5 using a patch. What is the final replica count after running 'kubectl apply -k overlay/'?

A.5
B.The result depends on the merge order
C.8
D.3
AnswerA

Kustomize's overlay patches are applied on top of the base after the base is fully rendered. A patch that sets replicas to 5 will replace the base's value of 3, because overlays are designed to be the final authority for customized values. The kustomize build output therefore contains the patched field, not the base's original value, making 5 the correct and deterministic result.

Why this answer

In Kustomize, overlays override base values through patches. The overlay specifies replicas: 5, so the final replica count is 5. Thus, option A is correct.

Option B is incorrect because Kustomize applies patches in a defined order, not a random merge. Option C is incorrect because values are not summed. Option D is the base value, which is overridden.

Full explanation →
38
MCQmedium

A pod has a container with 'readOnlyRootFilesystem: true' in its securityContext. The container writes to /tmp. What is the expected outcome?

A.The pod runs normally; Kubernetes automatically makes /tmp writable.
B.The container crashes because it tries to write to /tmp but the filesystem is read-only.
C.The pod is rejected by the admission controller because readOnlyRootFilesystem conflicts with writing to /tmp.
D.The container writes successfully because readOnlyRootFilesystem only applies to the container image layers.
AnswerB

This option is correct: with readOnlyRootFilesystem: true, the container's root filesystem is mounted read-only by the container runtime. Any attempt to write to /tmp — a directory on the root filesystem — triggers an EROFS (read-only file system) error on the write syscall. The application, expecting to write temporary files, receives this I/O error and crashes (or exits with an error). This is the direct consequence of a read-only root filesystem without a writable volume mounted at /tmp.

Why this answer

When `readOnlyRootFilesystem: true` is set in the container's securityContext, the root filesystem is mounted as read-only. The container writes to `/tmp`, which is part of the root filesystem by default, so the write fails and the container crashes (e.g., with an error like 'Read-only file system'). Kubernetes does not automatically make `/tmp` writable unless an explicit emptyDir volume is mounted at that path.

Exam trap

The trap here is that candidates assume `/tmp` is always writable or that `readOnlyRootFilesystem` only affects the image layers, but in reality it makes the entire root filesystem read-only, causing runtime failures unless a writable volume is explicitly mounted at the write location.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not automatically make `/tmp` writable; the root filesystem remains read-only as configured. Option C is wrong because the pod is not rejected by an admission controller; the securityContext is valid, and the failure occurs at runtime when the container attempts the write. Option D is wrong because `readOnlyRootFilesystem` applies to the entire root filesystem, including `/tmp`, not just the container image layers; the writable layer is also made read-only.

Full explanation →
39
MCQeasy

Which Kubernetes API version is used for creating a CronJob?

A.batch/v1beta1
B.batch/v1
C.cron/v1
D.apps/v1
AnswerB

batch/v1 is the stable API version for CronJob, promoted to GA in Kubernetes 1.21. It is the only currently served version, so any CronJob manifest must use apiVersion: batch/v1, kind: CronJob. This indicates that the resource is a controller in the batch group that creates Jobs on a schedule.

Why this answer

CronJob is a Kubernetes resource that was promoted to a stable API version in Kubernetes 1.21. The correct API version for creating a CronJob is batch/v1, as it is the current stable version. The batch/v1beta1 version is deprecated and removed in Kubernetes 1.25, so batch/v1 is the correct choice for CKAD exam scenarios.

Exam trap

The trap here is that candidates may recall the older batch/v1beta1 API version from earlier Kubernetes versions or confuse CronJob with other resources like Deployments (apps/v1), leading them to select a deprecated or incorrect API group.

How to eliminate wrong answers

Option A is wrong because batch/v1beta1 is a deprecated beta API version that was removed in Kubernetes 1.25; using it would fail on modern clusters. Option C is wrong because there is no cron/v1 API group in Kubernetes; CronJobs belong to the batch API group. Option D is wrong because apps/v1 is used for Deployments, StatefulSets, and DaemonSets, not for CronJobs.

Full explanation →
40
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 →
41
MCQeasy

Which Helm command installs a chart from a repository?

A.helm deploy <release-name> <chart>
B.helm install <release-name> <chart>
C.helm create <release-name> <chart>
D.helm run <release-name> <chart>
AnswerB

helm install <release-name> <chart> is the correct command to create a Helm release from a chart source. The chart argument can be a repository reference like 'bitnami/nginx', a local directory path, a packaged .tgz file, or a URL. Executing this command renders the chart's templates with the default values and applies them to the cluster, registering the release so that later upgrades or rollbacks can be performed via `helm upgrade` and `helm rollback`.

Why this answer

The correct command to deploy a chart from a repository is `helm install <release-name> <chart>`. This command tells Helm to create a release (a running instance of a chart) using the specified chart name or chart reference, which can be a chart from a configured repository, a local path, or a packaged chart archive.

Exam trap

The trap here is that candidates may confuse `helm install` with other common verbs like `deploy` or `run`, or mistakenly think `helm create` installs a chart, when in fact `helm create` only generates a chart template.

How to eliminate wrong answers

Option A is wrong because `helm deploy` is not a valid Helm command; the correct verb for installing a chart is `install`, not `deploy`. Option C is wrong because `helm create` is used to scaffold a new chart directory structure locally, not to install a chart from a repository. Option D is wrong because `helm run` is not a valid Helm command; Helm does not have a `run` subcommand for chart installation.

Full explanation →
42
MCQmedium

You want to block all ingress traffic to pods labeled 'app=api' except from pods labeled 'app=frontend'. Which NetworkPolicy rule is correct?

A.ingress: - from: - podSelector: matchLabels: app: frontend
B.ingress: - from: - namespaceSelector: matchLabels: app: frontend
C.ingress: - ports: - port: 80
D.ingress: - from: - ipBlock: cidr: 10.0.0.0/8
AnswerA

This rule is correct because it creates an ingress allow rule whose source is limited to pods that carry the label app=frontend. In a NetworkPolicy, any podSelector in a from element selects source pods in the policy's namespace, so traffic from all other pods is not explicitly allowed and will be blocked once this policy exists (default deny). Thus it satisfies the requirement to block all ingress to pods labeled app=a except from frontend pods.

Why this answer

A NetworkPolicy with an ingress rule using a podSelector with matchLabels: app: frontend allows traffic only from pods that have that label. By default, when no NetworkPolicy selects the pods, all ingress traffic is allowed; once a policy selects them, only explicitly allowed traffic is permitted. This rule therefore blocks all ingress except from pods labeled app=frontend.

Exam trap

The trap here is that candidates often confuse podSelector with namespaceSelector, thinking namespaceSelector can filter by pod labels, when in fact podSelector is required to match pods by their labels within the same namespace.

How to eliminate wrong answers

Option B is wrong because namespaceSelector selects entire namespaces, not pods; it would allow traffic from all pods in any namespace with that label, which is too broad and does not restrict to pods labeled app=frontend. Option C is wrong because it only specifies ports without any from selector, which would allow all ingress traffic on port 80 from any source, not just from frontend pods. Option D is wrong because ipBlock selects traffic based on source IP ranges, not pod labels; it would allow traffic from any pod in the 10.0.0.0/8 range, regardless of labels, and does not restrict to frontend pods.

Full explanation →
43
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 →
44
MCQmedium

You run 'kubectl run debug-pod --image=busybox -it --restart=Never -- sh' but the pod starts and immediately exits. You want to keep the container running to execute commands later. What flag should you add?

A.--stdin=true
B.--command
C.-- sleep infinity
D.--attach
AnswerC

By placing `--` followed by `sleep infinity` after the image name, you tell `kubectl run` to use that as the container's command, replacing the default `sh` from busybox. `sleep` is a process that suspends execution for the given interval; `infinity` means it never returns, so the main process never exits and the container remains in Running state indefinitely. This gives you a stable debug Pod you can `kubectl exec` into to run troubleshooting commands without worrying about the container dying.

Why this answer

Adding `-- sleep infinity` to the `kubectl run` command overrides the default entrypoint (`sh`) with a command that runs `sleep infinity`, which keeps the container alive indefinitely. Without this, the interactive shell (`sh`) exits immediately when it has no input, causing the pod to terminate. The `--` separator passes the command to the container image's entrypoint, ensuring the process runs in the foreground and does not exit.

Exam trap

The CKAD exam often tests the misconception that `--stdin=true` or `-it` alone keeps the pod running, but without a long-running command, the shell exits immediately, and the pod terminates.

How to eliminate wrong answers

Option A is wrong because `--stdin=true` (or `-i`) keeps STDIN open but does not prevent the shell from exiting when no input is provided; the pod still terminates immediately. Option B is wrong because `--command` is used to override the default command in the container spec, but without specifying a long-running process like `sleep infinity`, the pod will still exit. Option D is wrong because `--attach` (or `-a`) attaches to the container's STDIN/STDOUT/STDERR but does not change the fact that the shell exits immediately; it only affects how the client interacts with the pod.

Full explanation →
45
Multi-Selecteasy

Which TWO are valid ways to debug a pod using ephemeral containers?

Select 2 answers
A.kubectl debug -it <pod> --image=busybox -- sh
B.kubectl run debug --image=busybox -- sh
C.Adding an ephemeral container to the pod's spec under ephemeralContainers
D.kubectl exec -it <pod> -- sh
E.kubectl attach to the pod
AnswersA, C

kubectl debug -it <pod> --image=busybox -- sh is the standard command to create an ephemeral debug container in the target pod. It injects a busybox container into the pod's namespace and attaches your terminal to it, allowing you to inspect the pod's shared network, storage, and process state. This is the sanctioned workflow for adding a temporary troubleshooting container.

Why this answer

`kubectl debug -it <pod> --image=busybox -- sh` creates an ephemeral container in the target pod and attaches an interactive terminal to it. This is the standard Kubernetes mechanism for debugging a running pod without modifying its original container spec, using the ephemeral container feature (alpha in v1.16, stable in v1.23).

Exam trap

The trap here is that candidates confuse `kubectl exec` (which runs a command in an existing container) with `kubectl debug` (which creates a new ephemeral container), and also mistakenly think `kubectl run` or `kubectl attach` can inject a debug container into a running pod.

Full explanation →
46
Multi-Selectmedium

Which THREE of the following are correct statements about the terminationGracePeriodSeconds field? (Select 3)

Select 3 answers
A.The default value is 30 seconds
B.It gives the container time to shut down gracefully after receiving SIGTERM
C.After the grace period expires, the container is forcefully killed with SIGKILL
D.The default value is 0 seconds
E.It is used to configure the readiness probe timeout
AnswersA, B, C

The `terminationGracePeriodSeconds` field in a Pod spec defaults to 30 seconds when omitted. This value sets how long Kubernetes waits after sending SIGTERM to a container's main process before sending SIGKILL. It is a deliberate default to allow most workloads enough time to shut down cleanly without forcing an immediate hard kill.

Why this answer

The Kubernetes documentation specifies that the default value for terminationGracePeriodSeconds is 30 seconds. This field is part of the PodSpec and controls the duration between sending SIGTERM to the container and forcefully killing it with SIGKILL. If not set, Kubernetes applies this default to ensure a reasonable window for graceful shutdown.

Exam trap

CNCF often tests the exact default value (30 seconds) and the distinction between SIGTERM (graceful) and SIGKILL (forceful), so candidates must not confuse terminationGracePeriodSeconds with probe settings like readiness or liveness probe timeouts.

Full explanation →
47
MCQmedium

A PodSecurityPolicy (PSP) has been replaced by Pod Security Admission. Which of the following commands applies a baseline pod security standard to the namespace 'dev'?

A.kubectl label ns dev pod-security.kubernetes.io/warn=baseline
B.kubectl label ns dev pod-security.kubernetes.io/enforce=privileged
C.kubectl label ns dev pod-security.kubernetes.io/audit=baseline
D.kubectl label ns dev pod-security.kubernetes.io/enforce=baseline
AnswerD

Setting `enforce=baseline` configures the Pod Security Admission controller to actively reject any pod in the `dev` namespace that violates the baseline Pod Security Standard. The baseline standard is the minimal set of restrictions designed to prevent privilege escalation and covers key security contexts like `allowPrivilegeEscalation` and `privileged`. This label is the correct way to enforce the baseline standard, as it makes the admission controller deny non-compliant pods at creation time.

Why this answer

Pod Security Admission uses labels on namespaces to enforce pod security standards. The label `pod-security.kubernetes.io/enforce=baseline` applies the baseline standard, which prevents known privilege escalations while allowing the default minimal pod configuration. This replaces the deprecated PodSecurityPolicy (PSP) with a built-in admission controller.

Exam trap

The trap here is that candidates confuse the three modes (enforce, warn, audit) and pick a mode that does not actually apply the standard, or they mistakenly select `privileged` thinking it is the baseline standard.

How to eliminate wrong answers

Option A is wrong because the `warn` mode only generates a warning for non-compliant pods but does not enforce the standard; it is not the correct mode for applying a standard. Option B is wrong because it sets the enforce mode to `privileged`, which allows all capabilities and is the least restrictive standard, not the baseline standard. Option C is wrong because the `audit` mode logs violations but does not block or enforce the standard; it is used for auditing purposes only.

Full explanation →
48
MCQeasy

What is the effect of setting 'readOnlyRootFilesystem: true' in a container's securityContext?

A.The container can only read from the root filesystem, but can still write to /tmp.
B.The container's root filesystem is mounted as read-only.
C.The container cannot write to any mounted volumes.
D.The container will be killed if it attempts to write to the root filesystem.
AnswerB

This is the correct behavior: setting readonlyRootFilesystem to true in the pod's securityContext causes the container's root filesystem to be mounted with the read-only flag. As a result, all write operations to any file or directory within the container's image filesystem (including the upper layer) will fail with a read-only file system error. This is a common security hardening measure to prevent runtime tampering of the container's filesystem.

Why this answer

Setting `readOnlyRootFilesystem: true` in a container's securityContext mounts the container's root filesystem as read-only. This prevents any process inside the container from writing to the root filesystem, enhancing security by reducing the attack surface and ensuring immutability of the container image layers. It does not affect writable volumes mounted at other paths, such as emptyDir or hostPath volumes.

Exam trap

The trap here is that candidates often confuse 'readOnlyRootFilesystem' with making all volumes read-only, or assume the container is terminated on write attempts, when in reality only the root filesystem is affected and writes fail with an error, not silently.

How to eliminate wrong answers

Option A is wrong because while the root filesystem is read-only, the container cannot write to /tmp unless /tmp is a separate writable volume mount; the root filesystem includes /tmp by default, so writing there would also be blocked. Option C is wrong because mounted volumes (e.g., emptyDir, hostPath, PVC) are not part of the root filesystem and can still be written to unless they are explicitly mounted read-only. Option D is wrong because the container is not killed on a write attempt; instead, the write operation fails with an error (e.g., 'Read-only file system'), and the container continues running.

Full explanation →
49
MCQhard

You deploy a pod with the following specification: apiVersion: v1 kind: Pod metadata: name: probe-pod spec: containers: - name: app image: nginx livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10 failureThreshold: 3 The application listens on port 80, not 8080. What will happen to the pod?

A.The pod will be terminated and not restarted
B.The pod will start and run normally
C.The container will be restarted repeatedly due to liveness probe failure
D.The pod will be stuck in 'Pending' state
AnswerC

Correct. The liveness probe checks a health endpoint or TCP port on the container; when that probe fails continuously, the kubelet kills the container and restarts it according to restartPolicy (Always by default). Each subsequent restart is followed by another failing probe, so the container enters a restart loop with exponential backoff, visible as CrashLoopBackOff in container status. This matches the expected behavior for a misconfigured or broken liveness probe on port 8080.

Why this answer

The liveness probe is configured to perform an HTTP GET request on port 8080, but the application (nginx) listens on port 80. Since the probe will never receive a successful HTTP response (it will get a connection refused or timeout), it will fail. With a failureThreshold of 3, after three consecutive failures the kubelet will consider the container unhealthy and restart it.

This cycle repeats indefinitely, causing the container to be restarted repeatedly.

Exam trap

The trap here is that candidates assume the pod will be terminated or stuck, but they forget that liveness probes cause container restarts (not pod deletion) and that the pod will still reach 'Running' state initially, only to be repeatedly restarted.

How to eliminate wrong answers

Option A is wrong because the liveness probe failure triggers a container restart, not pod termination; the pod is not deleted, and the restart policy (default Always) ensures the container is restarted. Option B is wrong because the probe will fail due to the port mismatch, so the container will not run normally; it will be restarted repeatedly. Option D is wrong because the pod will transition to 'Running' state (the container starts successfully), but the liveness probe failures cause restarts; 'Pending' indicates the pod cannot be scheduled or images cannot be pulled, which is not the case here.

Full explanation →
50
MCQmedium

You have installed a Helm chart for 'wordpress' using 'helm install my-wordpress bitnami/wordpress'. Later, you want to check the status of the release. Which command lists the status of all releases?

A.helm list
B.helm status my-wordpress
C.helm history my-wordpress
D.helm show status
AnswerA

`helm list` is the correct command here because it enumerates every Helm release installed in the current namespace, displaying each release's name, status, chart version, app version, and revision number. It also indicates whether a release is deployed, failed, pending, or uninstalled, giving a concise overview similar to how `kubectl get pods` lists pods. Since you installed a WordPress chart via Helm, running `helm list` will confirm that the release exists and show its current lifecycle state.

Why this answer

The `helm list` command is the correct way to list all releases in the current namespace, showing their status (deployed, failed, pending, etc.). It provides a summary of each release, including the name, revision, update time, and status. This directly answers the question of listing the status of all releases.

Exam trap

A common pitfall is confusing commands that operate on a single release (like `helm status` or `helm history`) with the command that lists all releases (`helm list`). Candidates may also invent non-existent commands like `helm show status`.

How to eliminate wrong answers

Option B is wrong because `helm status my-wordpress` shows the detailed status of a single, specific release (my-wordpress), not all releases. Option C is wrong because `helm history my-wordpress` displays the revision history (rollback points) for a specific release, not the current status of all releases. Option D is wrong because `helm show status` is not a valid Helm command; `helm show` is used for chart information (e.g., `helm show chart`, `helm show values`), not release status.

Full explanation →
51
MCQeasy

You have a pod 'app-pod' that keeps restarting. You want to see the logs from the previous (crashed) container instance. Which command should you use?

A.kubectl logs app-pod --previous
B.kubectl logs app-pod -prev
C.kubectl logs app-pod -f
D.kubectl describe pod app-pod
AnswerA

The `--previous` flag is the long form of `-p` and retrieves the logs from the last terminated instance of the container. In a crash loop, the currently running container may be brand new with little/no output, while the previous instance's logs contain the stack trace or error that caused the exit. This is the standard way to inspect logs from a crashed container that has since restarted. The command returns logs to stdout, making them easy to review or pipe to tools.

Why this answer

The `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container in a pod. Option B uses `-prev` which is not a valid shorthand (the correct shorthand is `-p`, which is not listed). Options C and D are incorrect: `-f` is for following logs in real-time, and `describe` shows events and configuration, not logs.

Exam trap

The trap here is that candidates might confuse `-prev` with `-p`, which is the actual correct shorthand for `--previous`. However, `-prev` is invalid. Additionally, `-f` is for following logs and `describe` shows events, not logs, which could lead candidates to pick wrong options when the pod is restarting.

How to eliminate wrong answers

Option B is wrong because `-p` is the shorthand for `--previous`, so it is functionally identical to option A and not incorrect; however, the question asks for the command to use, and both A and B are valid, but A is listed as correct. Option C is wrong because `-f` (or `--follow`) streams logs from the current container instance, not the previous crashed one, so it would show no output if the current container has no logs or is restarting. Option D is wrong because `kubectl describe pod` shows pod metadata, events, and status, but not the container logs from a previous instance; it can show restart counts and reasons but not the actual log output.

Full explanation →
52
MCQmedium

A pod named 'web-app' is experiencing high CPU usage. You want to investigate which process inside the container is consuming the most CPU. Which command should you run?

A.kubectl logs -f web-app
B.kubectl exec web-app -- top
C.kubectl describe node
D.kubectl top pod web-app
AnswerB

kubectl exec web-app -- top is correct because it runs the top utility inside the container, which reads /proc to display a live view of processes with their PID, CPU usage, memory usage, and command name. This directly identifies the process consuming the most CPU from the perspective of the container's PID namespace. Note that top must exist in the container image, or you may need an alternative like kubectl exec web-app -- ps aux or /bin/sh -c 'top -b -n 1'.

Why this answer

`kubectl exec web-app -- top` runs the `top` command inside the container of the pod 'web-app', which displays real-time process-level CPU usage. This allows you to identify the specific process consuming the most CPU, directly addressing the question's requirement to investigate inside the container.

Exam trap

The trap here is that candidates confuse `kubectl top pod` (which shows pod-level resource usage) with the ability to inspect processes inside the container, leading them to choose Option D instead of using `kubectl exec` to run a process inspection command like `top`.

How to eliminate wrong answers

Option A is wrong because `kubectl logs -f web-app` streams the container's stdout/stderr logs, which do not show process-level CPU usage or running processes. Option C is wrong because `kubectl describe node` provides node-level resource allocation and conditions, not process-level details inside a specific pod's container. Option D is wrong because `kubectl top pod web-app` shows aggregate CPU and memory usage of the pod's containers, but does not reveal individual processes inside the container.

Full explanation →
53
MCQmedium

A user runs 'kubectl run nginx --image=nginx --restart=Never' and the pod goes into 'Pending' state. What is a likely reason?

A.The image name is incorrect
B.The pod is missing a readiness probe
C.The pod's restart policy is set to Never
D.The node has insufficient resources to schedule the pod
AnswerD

Pending is the PodPhase Kubernetes uses while the scheduler attempts to bind the pod to a suitable node. If every node in the cluster lacks the CPU, memory, or other resources requested (or if no node meets the pod's resource requirements), the scheduler leaves the pod unschedulable, and it remains Pending. Running `kubectl describe pod` would show pod events with messages like `0/1 nodes are available: 1 Insufficient cpu/memory`, confirming this cause.

Why this answer

Pending often indicates resource constraints like insufficient CPU or memory.

Full explanation →
54
Multi-Selectmedium

Which TWO practices optimize Docker image size? (Select 2)

Select 2 answers
A.Running 'apt-get upgrade' in the Dockerfile
B.Using a full OS base image like ubuntu:latest
C.Including a .dockerignore file to exclude unnecessary files
D.Using multi-stage builds to copy only necessary artifacts
E.Installing all packages in one layer without cleanup
AnswersC, D

Including a .dockerignore file excludes unnecessary files such as .git, node_modules, or build outputs from the Docker build context, so the daemon never sends them. This prevents those bulky files from being accidentally copied into the image with COPY or ADD, directly reducing final image size and also substantially speeding up the build by shrinking context.

Why this answer

A `.dockerignore` file prevents unnecessary files (e.g., local logs, node_modules, .git) from being sent to the Docker daemon during the `docker build` context, reducing the build context size and avoiding bloating the image with irrelevant data. Option D is correct because multi-stage builds allow you to compile or install dependencies in a temporary stage and then copy only the final runtime artifacts (e.g., compiled binaries) into a minimal final image, discarding build tools and intermediate layers.

Exam trap

A common pitfall tested in the CKAD exam is that running cleanup commands like `apt-get clean` in a separate RUN layer is ineffective; cleanup must occur in the same layer as the install to avoid persisting cached data in the intermediate layer.

Full explanation →
55
MCQhard

You have a CronJob that runs every 5 minutes. The previous job is still running when the next scheduled time arrives. You want the new job to be skipped if the previous one is still running. Which concurrencyPolicy should you set?

A.Skip
B.Allow
C.Replace
D.Forbid
AnswerD

Setting `concurrencyPolicy: Forbid` on the CronJob ensures that if a previous Job instance is still actively running when the next scheduled time arrives, the new Job is simply skipped rather than queued or allowed to overlap. This directly satisfies the constraint in the stem that the new job must be skipped when the previous one is still executing, preventing concurrent runs without blocking future schedules.

Why this answer

The `Forbid` concurrency policy in Kubernetes CronJobs ensures that if a previous job instance is still running when the next scheduled time arrives, the new job is skipped entirely. This prevents overlapping executions, which is exactly the requirement in the question.

Exam trap

The trap here is that candidates may confuse 'Skip' with 'Forbid' because 'skip' sounds like it means 'do not start the new job,' but Kubernetes uses the term 'Forbid' for this behavior, and 'Skip' is not a valid concurrency policy value.

How to eliminate wrong answers

Option A (Skip) is wrong because there is no 'Skip' concurrency policy in Kubernetes CronJobs; the valid values are Allow, Forbid, and Replace. Option B (Allow) is wrong because it allows concurrent job runs, meaning the new job would start even if the previous one is still running, which contradicts the requirement. Option C (Replace) is wrong because it cancels the currently running job and starts a new one, rather than skipping the new job if the previous is still running.

Full explanation →
56
MCQmedium

Which kubectl command can you use to pause a rolling update of a Deployment?

A.kubectl rollout pause deployment/my-deployment
B.kubectl rollout suspend deployment/my-deployment
C.kubectl rollout stop deployment/my-deployment
D.kubectl rollout halt deployment/my-deployment
AnswerA

`kubectl rollout pause deployment/my-deployment` is the correct command because it updates the Deployment's `.spec.paused` field to `true`, signaling the deployment controller to stop progressing the current rollout. The running Pods and existing ReplicaSets remain untouched, but any template changes you've made are held back until you run `kubectl rollout resume`. This gives you a controlled window to verify or modify configuration mid-stream.

Why this answer

The correct command to pause a rolling update of a Deployment is `kubectl rollout pause deployment/my-deployment`. This command temporarily halts the rollout process, allowing you to make changes or investigate issues without triggering a new revision. The `kubectl rollout` subcommand is specifically designed for managing Deployment rollouts, and `pause` is the correct verb to suspend the update.

Exam trap

The CKAD exam often tests the distinction between `pause` and `suspend` or `stop`, expecting candidates to know that `kubectl rollout pause` is the only valid command for temporarily halting a rolling update.

How to eliminate wrong answers

Option B is wrong because `kubectl rollout suspend` is not a valid kubectl command; the correct verb for pausing a rollout is `pause`, not `suspend`. Option C is wrong because `kubectl rollout stop` does not exist; stopping a rollout is done with `kubectl rollout undo` to roll back to a previous revision. Option D is wrong because `kubectl rollout halt` is not a valid kubectl command; Kubernetes uses `pause` and `resume` for controlling rollout progress.

Full explanation →
57
MCQhard

A developer wants to perform a canary deployment where 10% of traffic goes to a new version (v2) of an application. They create two Deployments (app-v1 and app-v2) and a Service. The Service selector is configured to match labels: 'app: myapp, version: v1'. How can they route 10% of traffic to v2 with minimal changes?

A.Use kubectl rollout pause on the v2 Deployment.
B.Set the v2 Deployment's spec.replicas to 10% of the total replicas and keep the Service selector unchanged.
C.Change the Service selector to 'app: myapp' (remove version label) and set v1 replicas to 9 and v2 replicas to 1.
D.Add a NetworkPolicy to limit traffic to v2 pods to 10%.
AnswerC

This works because removing the version label from the Service selector makes it match every pod labeled app: myapp, including both v1 and v2. With v1 replicas=9 and v2 replicas=1, the Service sees 10 ready endpoints, and the default load-balancing behavior sends roughly one-tenth of requests to v2. This replica ratio is the standard lightweight canary technique for a single Service, as long as both Deployments share the same app label and no other version-specific selector remains.

Why this answer

To achieve a canary deployment with 10% traffic to v2, the Service selector must match pods from both versions. By changing the selector to 'app: myapp' (removing the version label), the Service will load-balance across all pods with that label. Then, by setting v1 replicas to 9 and v2 replicas to 1, the total pods are 10, so v2 receives approximately 10% of traffic.

This requires minimal changes: one selector update and replica adjustments.

Exam trap

CKAD often tests the misconception that changing replica counts alone can route traffic to a new version when the Service selector still filters by version label, leading candidates to overlook the need to modify the selector.

How to eliminate wrong answers

Option A is wrong because pausing a Deployment only stops rolling updates; it does not affect traffic routing, and the Service selector still points only to v1, so v2 receives no traffic. Option B is wrong because setting v2 replicas to 10% while keeping the Service selector unchanged means the Service still selects only v1 pods (due to the version label), so v2 gets zero traffic. Option D is wrong because NetworkPolicy controls network access based on IP addresses and ports, not traffic splitting by percentage; it cannot route a specific proportion of traffic to a version.

Full explanation →
58
Multi-Selecthard

Which TWO of the following are valid approaches to debug a pod that is in a CrashLoopBackOff state? (Select 2)

Select 2 answers
A.Exec into the pod with 'kubectl exec -it' to inspect the environment
B.Check resource usage with 'kubectl top pod'
C.Use 'kubectl debug' to start an ephemeral container for troubleshooting
D.View logs from the previous container instance with 'kubectl logs --previous'
E.Create a new pod with 'kubectl run' using the same image
AnswersC, D

kubectl debug attaches an ephemeral container to the target pod without restarting or modifying the original container, so you can inspect the shared filesystem, environment variables, and network namespace even while the main container is crash-looping. Ephemeral containers are managed by the kubelet and are not subject to the pod's restart policy, allowing them to remain available for interactive troubleshooting when the main container keeps failing. This is the direct, supported way to debug a crashing pod when exec is impossible.

Why this answer

'kubectl debug' can start an ephemeral container in the same pod as the crashing container, allowing you to inspect the environment (e.g., filesystem, network, processes) without the main container running. This is especially useful when the main container crashes immediately and you cannot exec into it. Ephemeral containers share the pod's namespaces (e.g., network, PID) and can mount the same volumes, giving you a live debugging environment.

Exam trap

CNCF often tests the distinction between 'kubectl exec' (requires a running container) and 'kubectl debug' (works even when the container is crashing), and candidates mistakenly think exec can be used on a CrashLoopBackOff pod.

Full explanation →
59
MCQeasy

You create a Service with `kubectl expose deployment web --port=80 --target-port=8080`. What type of Service is created by default?

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

ClusterIP is the default Service type because the Service API's `type` field defaults to `ClusterIP` when omitted, so `kubectl expose deployment web p` creates a stable virtual IP reachable only inside the cluster. It assigns an internal cluster IP and load balances TCP/UDP across the selected pod endpoints through kube-proxy's iptables or IPVS rules, with no external exposure.

Why this answer

When you run `kubectl expose deployment web --port=80 --target-port=8080` without specifying the `--type` flag, Kubernetes defaults to creating a Service of type ClusterIP. This is because ClusterIP is the default Service type in Kubernetes, providing internal cluster-only access to the pods via a stable virtual IP address.

Exam trap

The trap here is that candidates often assume `kubectl expose` creates a NodePort or LoadBalancer Service by default because they associate 'expose' with external access, but Kubernetes defaults to ClusterIP for internal-only exposure.

How to eliminate wrong answers

Option B (LoadBalancer) is wrong because it requires the `--type=LoadBalancer` flag or a cloud provider integration to provision an external load balancer; it is not the default. Option C (NodePort) is wrong because it requires the `--type=NodePort` flag or is only created when explicitly requested; NodePort exposes the service on each node's IP at a static port, but it is not the default type. Option D (ExternalName) is wrong because it maps a service to a DNS name via the `externalName` field and is never created by `kubectl expose` without explicit configuration; it is a special type for external DNS resolution.

Full explanation →
60
MCQeasy

A deployment 'web-app' is running with 3 replicas. Users report that the application is slow. The team suspects a memory leak. Which command provides the most immediate insight into the memory usage of the pods?

A.kubectl describe deployment web-app
B.kubectl get events
C.kubectl logs <pod>
D.kubectl top pod
AnswerD

kubectl top pod is the correct choice because it directly queries the metrics-server (via the metrics.k8s.io API) for live CPU and memory usage data per pod and per container. It returns a compact table of instantaneous resource usage, such as MEMORY and MEMORY% columns, which is exactly what a user needs to inspect memory consumption across the three replicas. This command requires the metrics-server to be deployed and properly configured in the cluster to function.

Why this answer

`kubectl top pod` directly queries the metrics server to display real-time CPU and memory usage for each pod, providing the most immediate insight into whether a pod is consuming excessive memory due to a suspected leak. Unlike logs or events, it gives quantitative resource utilization data without requiring additional configuration or parsing.

Exam trap

The trap here is that candidates may choose `kubectl logs` thinking application logs will reveal memory leak details, but logs only show application output, not raw memory metrics, and `kubectl top pod` is the standard tool for immediate resource usage insight.

How to eliminate wrong answers

Option A is wrong because `kubectl describe deployment web-app` shows the deployment's configuration and status, not the actual runtime memory usage of individual pods. Option B is wrong because `kubectl get events` lists cluster events (e.g., scheduling failures, restarts) but does not provide memory usage metrics. Option C is wrong because `kubectl logs <pod>` outputs application logs, which may contain memory-related error messages but do not give direct, real-time memory consumption numbers.

Full explanation →
61
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 →
62
MCQhard

A developer is writing a multi-stage Dockerfile for a Go application. The builder stage compiles the binary, and the final stage uses a minimal base image. The developer wants the final image to contain only the compiled binary and CA certificates, and wants to copy the binary from the builder stage. Which Dockerfile instruction correctly copies the compiled binary from the builder stage into the final stage?

A.RUN cp --from=builder /app/server /usr/local/bin/server
B.COPY --from=builder /app/server /usr/local/bin/server
C.COPY /app/server /usr/local/bin/server
D.ADD --stage=builder /app/server /usr/local/bin/server
AnswerB

The COPY --from flag references an earlier build stage by name, allowing files to be copied from that stage's filesystem into the current stage. This brings only the compiled binary into the final image, which matches the goal of a minimal image containing the binary and certificates.

Why this answer

Multi-stage builds allow later stages to copy artifacts from earlier stages using COPY --from=<stage>. Referencing the builder stage by name copies only the compiled binary into the minimal final image, keeping it small and free of build tooling while still including the binary.

Exam trap

The trap here is assuming a regular COPY or RUN can reach files from another build stage, when only COPY --from (or the older --from=0 index form) can access a previous stage.

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

The --from-file flag reads config.properties and stores its contents as a single key named after the file, producing the ConfigMap app-config. This matches the required name and file source exactly, unlike literal or directory-based alternatives.

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 →
64
MCQeasy

A pod is running with the default service account. An administrator wants to prevent the pod from automatically mounting the service account token. Which field in the pod spec accomplishes this?

A.serviceAccountName: ""
B.automountServiceAccountToken: false
C.serviceAccountToken: none
D.securityContext.readOnlyRootFilesystem: true
AnswerB

automountServiceAccountToken: false is the correct way to prevent automatic mounting of the service account token into a pod. This boolean field, defined in the PodSpec, tells the kubelet not to project the service account token at /var/run/secrets/kubernetes.io/serviceaccount. It can also be set on a ServiceAccount to apply the same behavior to all pods that use that account. This is a security best practice for workloads that do not need to interact with the Kubernetes API.

Why this answer

Setting `automountServiceAccountToken: false` in the pod spec explicitly prevents the automatic mounting of the service account token into the pod. By default, Kubernetes mounts a projected service account token into every pod at `/var/run/secrets/kubernetes.io/serviceaccount`; this field overrides that default behavior at the pod level.

Exam trap

The trap here is that candidates often confuse `automountServiceAccountToken` with `serviceAccountName` or assume that setting an empty service account name removes the token, but only the explicit boolean field controls the mounting behavior.

How to eliminate wrong answers

Option A is wrong because setting `serviceAccountName: ""` does not prevent token mounting; it simply assigns the pod to the default service account in the namespace, which still results in automatic token mounting. Option C is wrong because `serviceAccountToken: none` is not a valid field in the pod spec; Kubernetes does not recognize this field. Option D is wrong because `securityContext.readOnlyRootFilesystem: true` only makes the container's root filesystem read-only, which does not prevent the service account token from being mounted (the token is still mounted and accessible, just on a read-only filesystem).

Full explanation →
65
MCQmedium

A company wants to deploy a stateful database on Kubernetes. The database requires stable network identities and persistent storage per pod. Which resource should be used?

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

StatefulSet is the correct controller because it gives each pod a stable ordinal identity (e.g., db-0, db-1) and stable, dedicated PersistentVolumeClaims via volumeClaimTemplates. It supports ordered startup, shutdown, and scaling, which is critical for database clustering and failover. The stable network DNS names enable database nodes to discover and communicate with each other reliably across rescheduling. Thus, it matches the requirements of a stateful database deployment.

Why this answer

StatefulSet is the correct resource because it provides stable, unique network identities (via headless Services and ordinal pod names like `db-0`, `db-1`) and persistent storage per pod (via PersistentVolumeClaims that are retained across rescheduling). This matches the requirement for a stateful database where each pod must maintain its identity and data independently.

Exam trap

The trap here is that candidates often choose Deployment because they associate it with scaling and rolling updates, but they overlook the critical need for stable network identities and per-pod persistent storage, which only StatefulSet provides.

How to eliminate wrong answers

Option A is wrong because a Job is designed for batch processing or one-off tasks, not for long-running stateful workloads that require stable identities and persistent storage. Option C is wrong because a Deployment creates pods with random, ephemeral names and does not guarantee stable network identities or per-pod persistent storage; it is suited for stateless applications. Option D is wrong because a DaemonSet ensures one pod per node, typically for node-level services like logging or monitoring, and does not provide ordered deployment, stable identities, or per-pod persistent storage for a database.

Full explanation →
66
MCQmedium

You have a Deployment with replicas: 5 and update strategy type: RollingUpdate with maxSurge: 25% and maxUnavailable: 25%. During a rolling update, what is the maximum number of pods that can be unavailable at any given time?

A.2
B.5
C.1
D.0
AnswerC

Correct. The maxUnavailable value is derived by taking 25% of the desired replicas: 0.25 × 5 = 1.25. Since the number of pods must be an integer, Kubernetes rounds this up to 1, ensuring at most one pod is unavailable at a time. This leaves at least 4 replicas running throughout the update, matching the configured tolerance.

Why this answer

With maxUnavailable: 25% on a Deployment of 5 replicas, the maximum number of unavailable pods is 25% of 5 = 1.25, and Kubernetes rounds down for maxUnavailable, resulting in 1. Therefore, at most 1 pod can be unavailable at any given time during the rolling update.

Exam trap

The trap here is that candidates often round 25% of 5 (1.25) to 2 instead of 1, forgetting that Kubernetes rounds down for maxUnavailable and rounds up for maxSurge, leading to incorrect answers like option A.

How to eliminate wrong answers

Option A is wrong because 2 would be the result if 25% of 5 were rounded up (1.25 → 2), but Kubernetes rounds down for maxUnavailable, so the correct value is 1. Option B is wrong because 5 represents the total number of replicas, not the maximum unavailable pods; maxUnavailable limits how many can be down simultaneously, not the total count. Option D is wrong because 0 would imply no pods can be unavailable during the update, which contradicts the rolling update strategy that allows some pods to be taken down gradually; maxUnavailable: 25% explicitly permits a portion to be unavailable.

Full explanation →
67
Multi-Selectmedium

Which THREE of the following are valid parameters for configuring probes? (Select 3)

Select 3 answers
A.retryIntervalSeconds
B.timeoutSeconds
C.cooldownSeconds
D.initialDelaySeconds
E.periodSeconds
AnswersB, D, E

timeoutSeconds is a valid Kubernetes probe parameter. It defines the maximum time in seconds that the kubelet waits for a probe to complete after starting it. If the probe exceeds this duration, it is considered failed, and the failure is counted toward failureThreshold. To be effective, timeoutSeconds should be less than periodSeconds to avoid overlapping probe executions.

Why this answer

In Kubernetes, probe configuration parameters are defined in the container spec within a Pod. `timeoutSeconds` is a valid parameter that specifies the number of seconds after which the probe times out, defaulting to 1 second if not set. It is used in liveness, readiness, and startup probes to control how long kubelet waits for a probe response before considering it failed.

Exam trap

The CKAD exam often tests the distinction between valid probe parameters and common-sounding but non-existent fields like `retryIntervalSeconds` or `cooldownSeconds`, tricking candidates into selecting them because they seem logical for retry or cooldown behavior.

Full explanation →
68
Multi-Selecthard

Which THREE of the following are best practices for configuring readiness probes?

Select 3 answers
A.Use the same endpoint as the liveness probe
B.Configure the probe to restart the container if it fails
C.Set initialDelaySeconds to avoid startup race conditions
D.Use a separate endpoint from the liveness probe
E.Use an HTTP GET request to a lightweight endpoint
AnswersC, D, E

Setting initialDelaySeconds gives the application a grace period to finish startup tasks such as loading configuration, connecting to databases, or opening listen sockets before the kubelet begins sending probe requests. Without this delay, a still-initializing container may fail its first probes and be repeatedly restarted, creating a crash loop instead of a healthy pod.

Why this answer

Setting `initialDelaySeconds` in a readiness probe prevents the probe from starting before the container's application has had time to initialize. Without this delay, the probe might fail immediately during startup, causing the container to be prematurely marked as not ready and removed from service, even though the application would have become ready given a few more seconds. This avoids race conditions between container startup and probe evaluation.

Exam trap

The trap here is that candidates confuse readiness probes with liveness probes, mistakenly thinking readiness probes can restart containers or that sharing the same endpoint is acceptable, when in fact readiness probes only control traffic routing and should use a separate, dependency-aware endpoint.

Full explanation →
69
MCQhard

Which of the following is a correct Kustomize kustomization.yaml configuration for setting an image tag to 'v2'?

A.images: - name: my-app newName: v2
B.images: - name: my-app newTag: v2
C.patches: - target: kind: Deployment patch: |- - op: replace path: /spec/template/spec/containers/0/image value: my-app:v2
D.imageTag: - name: my-app tag: v2
AnswerB

The `images` field with `newTag` is the purpose-built transformer for overriding container image tags in Kustomize. It preserves the original image name and replaces only the tag with the specified value, making it the simplest and most declarative way to pin a new version across all matching containers. This is why this option is the correct answer.

Why this answer

In Kustomize, the `images` field in `kustomization.yaml` uses the `newTag` key to override the tag of an existing container image. This allows you to change the image tag to 'v2' without modifying the original YAML manifests, aligning with Kustomize's declarative patching approach.

Exam trap

The CKAD exam often tests the distinction between `newName` and `newTag` in Kustomize, trapping candidates who confuse the two or assume `newName` can set a tag, or who overcomplicate the solution with JSON patches when a simpler built-in field exists.

How to eliminate wrong answers

Option A is wrong because `newName` is used to change the image name (e.g., from 'my-app' to 'my-app2'), not the tag; using it to set a tag like 'v2' would incorrectly replace the image name. Option C is wrong because it uses a JSON Patch (RFC 6902) with `op: replace` to directly modify the Deployment manifest, which is a valid but non-Kustomize-native approach; Kustomize's `images` field is the idiomatic way to set image tags, and this patch would work but is not a `kustomization.yaml` configuration for setting an image tag. Option D is wrong because `imageTag` is not a valid field in Kustomize's `kustomization.yaml`; the correct field is `images`, and the key for the tag is `newTag`, not `tag`.

Full explanation →
70
MCQhard

You have a NetworkPolicy named 'deny-all' in namespace 'secure' that selects all pods and has no ingress rules. You need to allow incoming traffic to pods with label 'app: db' on port 5432 from pods with label 'app: api' in the same namespace. Which NetworkPolicy should you create?

A.A NetworkPolicy with podSelector matching 'app: db' and ingress rule allowing from namespaceSelector matching 'secure' on port 5432.
B.A NetworkPolicy with podSelector matching 'app: db' and ingress rule allowing from podSelector 'app: api' on port 5432.
C.A NetworkPolicy with podSelector matching 'app: db' and ingress rule allowing from ipBlock 0.0.0.0/0 on port 5432.
D.A NetworkPolicy with podSelector matching 'app: api' and egress rule allowing to podSelector 'app: db' on port 5432.
AnswerB

This policy selects the target pods (app: db) and defines an ingress rule that allows traffic from pods with label app: api on TCP port 5432. Since NetworkPolicies are additive, this will allow the specified traffic while the deny-all policy continues to block everything else. It correctly implements the least privilege requirement.

Why this answer

NetworkPolicies are additive, and a deny-all policy blocks all ingress unless explicitly allowed. To allow specific traffic, you must create a policy that selects the target pods ('app: db') and defines an ingress rule that matches the source pods ('app: api') on the correct port. Policies that control egress on the source, allow all IPs, or allow the entire namespace do not meet the precise restriction.

Exam trap

The trap here is applying the NetworkPolicy to the source pods instead of the destination pods; ingress rules must be on the pods receiving the traffic.

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

The `kubectl create secret tls` subcommand builds a Kubernetes TLS secret directly from a certificate and private key pair, storing them under the required `tls.crt` and `tls.key` data keys that an Ingress controller expects. Supplying `--cert` and `--key` satisfies the stem's requirement to create the secret from both files.

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 →
72
Multi-Selecthard

Which TWO of the following are correct methods to implement a canary deployment using Kubernetes resources?

Select 2 answers
A.Use a Deployment with 'strategy.type: Canary' in the spec.
B.Create two Services and use a header-based routing to send specific users to canary.
C.Create two Deployments (stable and canary) with a shared Service that selects both based on a common label. Initially, canary has 1 replica while stable has many. Gradually increase canary replicas.
D.Create two separate Services, one for stable and one for canary, and use DNS to route a percentage of traffic.
E.Use an Ingress controller that supports traffic splitting (like Nginx Ingress with canary annotation) to route a percentage of requests to the canary Deployment.
AnswersC, E

This is the classic Kubernetes-native canary pattern: both Deployments' pods share a common label (e.g., app: myapp, version: stable/canary) and the same Service selects on that common label, so the Service's Endpoints automatically include pods from both versions. The proportion of requests reaching the canary is approximately the ratio of canary replicas to total replicas, so starting with 1 canary replica and many stable replicas delivers a small traffic share. Incrementally scaling up canary replicas shifts more traffic incrementally, allowing monitoring for regressions without needing any additional routing components.

Why this answer

Option C is correct because a native Kubernetes approach to canary deployment is to run two Deployments (stable and canary) that share a common label selected by a single Service; by starting the canary with 1 replica versus many stable replicas, the Service load-balances across all matching pods, so the canary receives a small fraction of traffic that grows as you scale its replicas up. Option E is correct because an Ingress controller such as NGINX Ingress supports canary traffic splitting via annotations (e.g., nginx.ingress.kubernetes.io/canary: "true" with canary-weight or canary-by-header), letting you route a defined percentage of requests to a separate canary Deployment/Service without touching the stable path. Option A is wrong because Kubernetes Deployment strategy.type only supports Recreate and RollingUpdate; there is no built-in 'Canary' strategy type.

Option B is wrong because plain Kubernetes Services do not perform header-based routing; that requires an Ingress controller or service mesh, and the option as stated misattributes the capability to Services. Option D is wrong because DNS-based percentage routing is not a Kubernetes resource mechanism and DNS cannot reliably split traffic by percentage at the request level.

Exam trap

CKAD often tests the misconception that Kubernetes has a built-in 'Canary' Deployment strategy — candidates must recognize that canary is a pattern built from primitives (Deployments, Services, Ingress), not a native strategy.type value.

Full explanation →
73
Multi-Selecthard

Which TWO of the following conditions must be met for a RollingUpdate to proceed?

Select 2 answers
A.The new pod must pass its readiness probe
B.The number of unavailable pods must not exceed maxUnavailable
C.The new ReplicaSet must have the desired number of pods
D.The old ReplicaSet must be scaled to zero
E.The old ReplicaSet must be deleted
AnswersA, B

During a rolling update, the Deployment controller creates a new ReplicaSet and scales it up. Before it proceeds to terminate old pods and scale up further, it must confirm that newly created pods are actually Ready by passing their readiness probes. If a new pod fails its readiness probe, the rollout stalls to protect availability, preventing traffic from being routed to unhealthy pods and avoiding cascading failures.

Why this answer

A is correct because during a RollingUpdate, the new pod must pass its readiness probe before the old pod is terminated. This ensures the new pod is capable of serving traffic, preventing service disruption. The readiness probe is checked by the kubelet, and only when it succeeds does the ReplicaSet controller proceed with the update.

Exam trap

The trap here is that candidates often confuse the conditions for a RollingUpdate to proceed with the final state of the update, mistakenly thinking the old ReplicaSet must be scaled to zero or deleted, when in fact the update proceeds incrementally and the old ReplicaSet is only scaled down as new pods become ready.

Full explanation →
74
Multi-Selectmedium

A team is deploying a multi-container pod with a main application container and a sidecar container for logging. Which THREE statements about pod design are correct?

Select 3 answers
A.Containers in a pod share the same filesystem root.
B.Containers in a pod share the same network namespace.
C.Containers in a pod can share the same volume mounts.
D.The sidecar container must use the same image as the main container.
E.The sidecar container should be designed to not block the main container from starting.
AnswersB, C, E

Containers in a pod share the same network namespace, meaning they have a single IP address, a shared port space, and a common loopback interface. This allows the main application and sidecar to communicate directly on localhost without additional service discovery. However, they do not automatically share a filesystem unless a volume is explicitly mounted into both.

Why this answer

Containers within the same Kubernetes pod share the same network namespace, including the same IP address and port space. This allows them to communicate via localhost and share network resources, which is essential for sidecar patterns like logging agents that need to intercept or monitor the main container's traffic.

Exam trap

CNCF often tests the misconception that containers in a pod share the same filesystem root, but in reality they only share volumes via explicit mounts, not the entire root filesystem.

Full explanation →
75
MCQeasy

Which probe type is used to indicate that a container is ready to serve traffic and should be added to Service endpoints?

A.Readiness probe
B.Liveness probe
C.Startup probe
D.Both liveness and readiness probes
AnswerA

Readiness probes are the mechanism Kubernetes uses to decide if a container is ready to serve traffic. When a readiness probe fails, the pod is removed from all backing Service endpoints, so no requests are forwarded to it, but the container is not killed or restarted. This makes readiness probes the direct indicator of whether a container is prepared to handle incoming traffic, including dependencies like database connectivity or loaded configuration.

Why this answer

A Readiness probe determines whether a container is ready to accept traffic. If the probe fails, the container is removed from all Service endpoints, ensuring only healthy pods receive requests. This is the correct probe for indicating readiness to serve traffic.

Exam trap

The CKAD exam often tests the distinction between readiness and liveness probes, trapping candidates who confuse 'is the container alive?' with 'is the container ready to serve?'.

How to eliminate wrong answers

Option B is wrong because a Liveness probe indicates whether a container is running, not whether it is ready to serve traffic; a failed liveness probe restarts the container. Option C is wrong because a Startup probe checks if the container's application has started successfully, used for slow-starting containers, and does not control Service endpoint membership. Option D is wrong because both probes together serve different purposes: liveness for restarting dead containers, readiness for traffic routing; only the readiness probe controls Service endpoints.

Full explanation →

Page 1 of 12

Page 2

All pages

123456789101112

Practice CKAD by domain

Target a specific domain to shore up weak areas.

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