Certified Kubernetes Application Developer CKAD CKAD Questions 301–375 | Page 5/12

301

MCQmedium

Which of the following is true about the CMD instruction in a Dockerfile?

A.CMD is always executed during the image build process

B.CMD is used to expose ports

C.CMD cannot be used in conjunction with ENTRYPOINT

D.CMD provides a default command that can be overridden at runtime

AnswerD

This is correct. CMD defines the default command and parameters that run when the container starts, but it is intentionally overridable. For example, docker run image <command> replaces the CMD entirely. This flexibility makes CMD useful for providing sensible defaults while allowing users to supply their own command.

Why this answer

The CMD instruction in a Dockerfile provides default arguments for the container's main process, which can be overridden when the container is started with a command-line argument (e.g., `docker run <image> <command>`). It is not executed during the image build (that's RUN), it does not expose ports (that's EXPOSE), and it can be used with ENTRYPOINT to supply default parameters that are overridable.

Exam trap

The trap here is that candidates often confuse CMD with RUN, thinking CMD runs during build, or mistakenly believe CMD and ENTRYPOINT are mutually exclusive, when in fact they are designed to work together.

How to eliminate wrong answers

Option A is wrong because CMD is not executed during the image build process; it only defines the default command for the container at runtime, while RUN executes commands during the build. Option B is wrong because exposing ports is done with the EXPOSE instruction, not CMD. Option C is wrong because CMD can be used in conjunction with ENTRYPOINT; when both are present, CMD provides default arguments to the ENTRYPOINT executable, which can be overridden at runtime.

Full explanation →

302

MCQeasy

You have a Deployment named 'web' with label 'app: web'. You want to create a Service that exposes the Deployment on port 80 internally within the cluster. Which kubectl command achieves this?

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

B.kubectl create deployment web --image=nginx --expose --port=80

C.kubectl expose pod web --port=80

D.kubectl expose deployment web --port=80

AnswerD

kubectl expose deployment web --port=80 creates a ClusterIP Service by reading the Deployment's label selector (app=web) and generating an Endpoints object that includes all matching Pods. Because the Deployment manages the Pods, the Service automatically follows rolling updates and scaling, providing a stable virtual IP for clients. This is the canonical command to expose a Deployment's port 80 without specifying a targetPort explicitly.

Why this answer

`kubectl expose deployment web --port=80` creates a ClusterIP Service that selects Pods based on the Deployment's label selector (app: web) and exposes port 80 internally within the cluster. This command directly maps the Deployment's Pods to a Service without requiring manual specification of the target port or protocol, defaulting to TCP.

Exam trap

The trap here is that candidates confuse `kubectl expose` with `kubectl create service`, not realizing that `expose` automatically inherits the selector from the specified resource, while `create service` requires explicit selector configuration to bind to existing Pods.

How to eliminate wrong answers

Option A is wrong because `kubectl create service clusterip web --tcp=80` creates a Service named 'web' but does not automatically link it to the Deployment's Pods; it requires a separate `--selector` flag or manual label matching, and without it the Service will have no endpoints. Option B is wrong because `kubectl create deployment web --image=nginx --expose --port=80` creates both a Deployment and a Service in one command, but the question assumes the Deployment already exists, and this command would create a duplicate Deployment or fail if the name conflicts. Option C is wrong because `kubectl expose pod web --port=80` targets a Pod named 'web' directly, not the Deployment, and Pods are ephemeral; a Service should target a higher-level resource like a Deployment or ReplicaSet to ensure stable endpoint selection.

Full explanation →

303

Multi-Selecthard

Which THREE are valid reasons to use a StatefulSet instead of a Deployment?

Select 3 answers

A.The application requires rolling updates.

B.Each pod requires a stable, unique network identity.

C.Each pod needs its own persistent volume that persists across rescheduling.

D.The application cannot be scaled down.

E.Pods must be terminated in reverse order during shutdown.

AnswersB, C, E

StatefulSet pods are assigned a stable, unique network identity based on their ordinal index (e.g., my-statefulset-0, my-statefulset-1). This hostname remains consistent across pod rescheduling, and when paired with a headless Service, each pod has a stable DNS name that other components can rely on. Deployments, by contrast, create pods with random suffixes and no guarantee of stable hostnames.

Why this answer

StatefulSet assigns each pod a stable, unique network identity (e.g., a hostname like `web-0`, `web-1`) via a headless Service, which is critical for stateful applications like databases that rely on consistent DNS names for clustering and discovery. Deployments create pods with random, ephemeral hostnames, making them unsuitable for workloads requiring predictable network identities.

Exam trap

CNCF often tests the misconception that only StatefulSets support rolling updates, but both controllers do; the trap is confusing a shared feature with a unique StatefulSet capability.

Full explanation →

304

MCQhard

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

A.The Pod will have its limits overridden by the LimitRange defaults because limits must be set

B.The Pod will be admitted because it respects both the ResourceQuota and the LimitRange

C.The Pod will be rejected because the limits exceed the LimitRange default

D.The Pod will be rejected because requests must equal limits

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

305

Multi-Selecthard

Which THREE are valid fields in a NetworkPolicy spec? (Choose three.)

Select 3 answers

A.podSelector

B.ingress

C.ports

D.policyTypes

E.ipBlock

AnswersA, B, D

podSelector is a required field under spec. It uses label selectors to identify the pods to which this NetworkPolicy applies. An empty podSelector ({} ) matches all pods in the namespace, making the policy namespace-wide. Without it, the API rejects the policy because the policy would have no selected workload.

Why this answer

`podSelector` is a required field in a NetworkPolicy spec that defines which pods the policy applies to, using standard Kubernetes label selectors. It must be present to target specific pods within a namespace, and an empty `podSelector` selects all pods in the namespace.

Exam trap

A common mistake in Kubernetes is to confuse top-level spec fields with nested subfields. Candidates often select `ports` or `ipBlock` as direct spec fields, but they are only valid within `ingress` or `egress` rules in a NetworkPolicy.

Full explanation →

306

MCQhard

You have a CronJob that runs every 5 minutes. The job sometimes takes longer than 5 minutes to complete. You want to ensure that while a job is running, the next scheduled job is skipped (not started). Which concurrencyPolicy should you use?

A.Forbid

B.Skip

C.Allow

D.Replace

AnswerA

Forbid is the correct concurrencyPolicy for a CronJob that must not overlap runs. When set, the controller skips the next scheduled invocation if a previous Job created by this CronJob is still active (i.e., has not completed successfully or failed). This guarantees serial execution, which is critical for jobs that mutate shared state or cannot safely run in parallel.

Why this answer

The `Forbid` concurrencyPolicy ensures that if a previous job instance is still running when the next scheduled time arrives, the new job is simply skipped (not created). This prevents overlapping executions, which is exactly what you need when a CronJob's duration can exceed its schedule interval.

Exam trap

The trap here is that candidates confuse the 'Skip' option (which is not a valid Kubernetes value) with the correct 'Forbid' policy, or they mistakenly think 'Replace' will skip the next job instead of killing the current one.

How to eliminate wrong answers

Option B (Skip) is wrong because 'Skip' is not a valid concurrencyPolicy value in Kubernetes; the correct term is 'Forbid'. Option C (Allow) is wrong because it permits multiple job instances to run concurrently, which would allow overlapping executions even if the previous job hasn't finished. Option D (Replace) is wrong because it would cancel the currently running job and start a new one, which is not the same as skipping the next scheduled run.

Full explanation →

307

MCQhard

You run 'kubectl apply -f pod.yaml' but the pod remains in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 Insufficient cpu'. What is the most likely cause?

A.The pod's memory limit is too low

B.The container image is not found in the registry

C.The node is under disk pressure

D.The pod's CPU request exceeds the available CPU capacity on any node

AnswerD

The exact scheduler event 'Insufficient cpu' means no node in the cluster satisfies the pod's CPU request after accounting for the allocatable CPU and existing pod requests. The pod remains Pending because the scheduler cannot find a feasible node, and it does not even attempt to bind the pod. This is the correct interpretation because the message directly indicates a lack of available CPU capacity, not memory, disk, or image issues.

Why this answer

The error '0/1 nodes are available: 1 Insufficient cpu' indicates that the pod's CPU request (specified in the container spec under `resources.requests.cpu`) exceeds the allocatable CPU capacity on any node in the cluster. The scheduler evaluates CPU requests, not limits, for admission decisions; if no node has enough unallocated CPU to satisfy the request, the pod remains Pending.

Exam trap

Candidates often confuse resource requests and limits. The scheduler uses CPU requests, not limits, to determine node capacity. Limits are for resource enforcement after scheduling.

How to eliminate wrong answers

Option A is wrong because memory limits do not affect CPU scheduling; the error specifically mentions 'Insufficient cpu', not memory. Option B is wrong because an image pull failure would result in an 'ErrImagePull' or 'ImagePullBackOff' event, not a Pending state with a CPU insufficiency message. Option C is wrong because disk pressure is a node condition that would be reported as 'Insufficient disk space' or 'DiskPressure', not 'Insufficient cpu'.

Full explanation →

308

MCQmedium

A NetworkPolicy denies all ingress traffic to a namespace. Which rule would allow traffic only from pods in the same namespace?

A.from: - namespaceSelector: {} podSelector: {}

B.from: - ipBlock: cidr: 0.0.0.0/0

C.from: - podSelector: {}

D.from: - namespaceSelector: matchLabels: name: mynamespace

AnswerC

An empty podSelector with no namespaceSelector correctly limits the source to pods in the same namespace as the NetworkPolicy. In Kubernetes NetworkPolicy semantics, when only podSelector is specified, it implicitly selects pods within the policy's own namespace and does not affect other namespaces. Therefore, this rule allows ingress from all pods in that namespace while blocking traffic from other namespaces and external sources, matching the requirement precisely.

Why this answer

A `podSelector: {}` in a NetworkPolicy ingress rule selects all pods in the same namespace as the policy, effectively allowing traffic only from pods within that namespace. This works because the empty podSelector matches all pods in the namespace where the NetworkPolicy is applied, and no namespaceSelector is specified, so the rule is scoped to the local namespace only.

Exam trap

The trap here is that candidates often confuse the empty `podSelector: {}` (which matches all pods in the local namespace) with a `namespaceSelector: {}` (which matches all namespaces), leading them to choose Option A, which inadvertently allows traffic from all namespaces instead of only the same namespace.

How to eliminate wrong answers

Option A is wrong because it includes both a `namespaceSelector: {}` (which matches all namespaces) and a `podSelector: {}` (which matches all pods), thereby allowing traffic from any pod in any namespace, not just the same namespace. Option B is wrong because an `ipBlock` with `0.0.0.0/0` allows traffic from any IP address, including external sources, which violates the requirement to restrict traffic to pods in the same namespace. Option D is wrong because it uses a `namespaceSelector` with a label match, which selects pods from a specific namespace (e.g., 'mynamespace') but does not restrict traffic to pods within the same namespace as the policy; it could allow traffic from a different namespace if that namespace has the matching label.

Full explanation →

309

MCQeasy

To prevent a container from running as root, which field should be set in the securityContext?

A.runAsUser: 1000

B.runAsNonRoot: true

C.allowPrivilegeEscalation: false

D.readOnlyRootFilesystem: true

AnswerB

runAsNonRoot: true is the correct field because it actively enforces a security requirement that the container must not run as root. When set, the kubelet checks the user the image would run as: if that user is root (UID 0) or the image does not define a non-root user, the container is not started and the Pod fails. This provides a strong guarantee that the container process never executes with root privileges, regardless of the image's default configuration.

Why this answer

The `runAsNonRoot: true` field in the securityContext explicitly prevents the container from running as the root user (UID 0). When set, Kubernetes will refuse to start the container if the image is configured to run as root, enforcing a non-root execution policy at the pod or container level. This is the direct and intended mechanism for ensuring the container does not run with root privileges.

Exam trap

The trap here is that candidates often confuse `runAsNonRoot: true` with `runAsUser: 1000`, mistakenly thinking that setting a non-zero user ID alone guarantees the container does not run as root, when in fact `runAsUser` only sets the UID and does not enforce a root check, leaving the container vulnerable if the image defaults to root.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 1000` sets a specific user ID for the container process but does not prevent running as root; if the image runs as root, this field overrides it only if explicitly set, and it does not enforce a non-root check. Option C is wrong because `allowPrivilegeEscalation: false` controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), but it does not prevent the container from initially running as root. Option D is wrong because `readOnlyRootFilesystem: true` makes the container's root filesystem read-only, which is a security hardening measure but does not affect the user identity under which the container runs.

Full explanation →

310

MCQmedium

A developer needs to run a one-off task that processes a queue and then exits. The task must run exactly once per invocation, and if the Pod fails, Kubernetes should restart it until it succeeds. The task should not be restarted after it completes successfully. Which Kubernetes resource should the developer create?

A.A Job with a restartPolicy of OnFailure and no completions or parallelism settings.

B.A bare Pod with a restartPolicy of OnFailure and no controller managing it.

C.A CronJob with a schedule that runs every minute and a restartPolicy of Never.

D.A Deployment with a single replica and a restartPolicy of Always.

AnswerA

A Job is designed for run-to-completion workloads. With restartPolicy OnFailure, the Pod is restarted only if the container exits with a non-zero code, and no restart occurs after a successful exit. Default completions and parallelism of one ensure the task runs a single time.

Why this answer

A Job is the correct resource for run-to-completion tasks. Setting restartPolicy to OnFailure restarts the Pod only on failure, and the default single completion with no parallelism ensures the task runs once and stops after success, matching the requirement.

Exam trap

The trap here is choosing a Deployment or bare Pod for a task that should stop after success, when only a Job provides run-to-completion semantics with failure retries.

Full explanation →

311

MCQmedium

Which Pod spec snippets correctly achieve this?

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

B.volumes: - name: secret-volume secret: secretName: db-secret volumeMounts: - mountPath: /etc/secret name: secret-volume

C.env: - name: USERNAME valueFrom: secretKeyRef: name: db-secret key: username - name: PASSWORD valueFrom: secretKeyRef: name: db-secret key: password

D.env: - name: db-secret valueFrom: configMapKeyRef: name: db-secret key: username

AnswerA, C

The envFrom directive with secretRef is a clean, idiomatic way to inject every key-value pair from the Secret db-secret as individual environment variables. Each key in the Secret (e.g., username, password) becomes an environment variable name, and its value is populated automatically. This is correct when you want to expose the entire Secret without manually mapping each key, and it requires no additional per-key configuration.

Why this answer

This question has multiple correct answers. Both options A and C are correct ways to expose Secret keys as environment variables in a Pod. Option A uses `envFrom` with `secretRef` to inject all keys from the Secret as environment variables in a single declaration.

Option C uses individual `env` entries with `secretKeyRef` to map each key explicitly. Both achieve the same result; option A is more concise for exposing all keys, while option C provides explicit control over each environment variable name. Options B and D are incorrect: B mounts the Secret as files, not environment variables, and D uses `configMapKeyRef`, which is for ConfigMaps, not Secrets.

Exam trap

A common trap is that candidates might think only the bulk `envFrom` method (option A) is correct, but the individual `env` with `secretKeyRef` (option C) is also perfectly valid. The key distinction is that both are acceptable methods for exposing Secrets as environment variables.

How to eliminate wrong answers

Option B is wrong because it mounts the Secret as files in a volume at `/etc/secret`, not as environment variables; the question specifically asks for environment variables. Option C is wrong because while it correctly uses `secretKeyRef` to expose individual keys as environment variables, it requires explicit enumeration of each key ('username' and 'password'), which is not the most efficient approach when the goal is to expose all keys from the Secret; the question asks for the snippet that 'correctly achieves this', and A is more direct and concise. Option D is wrong because it uses `configMapKeyRef` instead of `secretKeyRef`, and references a ConfigMap named 'db-secret' rather than a Secret, which would fail to read the Secret's data and would not expose the correct values.

Full explanation →

312

MCQhard

You have a Deployment that uses the Recreate strategy. You update the container image. What happens to the existing pods?

A.Existing pods are not affected; you must manually delete them

B.Existing pods are terminated first, then new pods are created

C.Existing pods are gradually terminated while new pods are created

D.New pods are created alongside existing pods, then old pods are terminated

AnswerB

With the Recreate strategy, the Deployment controller first scales the old ReplicaSet to zero, ensuring all existing pods are terminated and removed. Only after all old pods have reached a terminated state does it scale up the new ReplicaSet, creating replacement pods. This guarantees that there is no overlap between old and new pod versions during the update.

Why this answer

The Recreate strategy terminates all existing pods before creating new ones, causing a brief outage. This is the defining behavior of Recreate and contrasts with RollingUpdate, which replaces pods gradually.

Exam trap

CKAD often tests the confusion between Recreate and RollingUpdate strategies, catching candidates who assume all Deployments roll out gradually by default.

How to eliminate wrong answers

Option A is wrong because the Deployment controller automatically terminates and recreates pods on image update — manual deletion is not required. Option C is wrong because gradual termination while new pods are created describes the RollingUpdate strategy, not Recreate. Option D is wrong because creating new pods alongside existing ones before terminating old ones is also RollingUpdate behavior (or blue/green), not Recreate.

Full explanation →

313

MCQmedium

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

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

B.The pod has a liveness probe configured incorrectly.

C.The namespace has a ResourceQuota that blocks the pod.

D.The pod's memory limit is set too low.

AnswerA

The Kubernetes scheduler selects a node for a pod based on the pod's resource requests, comparing them to each node's allocatable capacity minus the requests of existing workloads. If every node lacks the unallocated memory needed to satisfy this pod's memory request, the pod remains Pending with scheduler events such as 'Insufficient memory'. This is a scheduling failure, not a runtime issue, and it persists until the request is lowered, nodes are added, or other workloads are removed to free capacity.

Why this answer

The '0/1 nodes are available: 1 Insufficient memory' message indicates that the Kubernetes scheduler could not find a node with enough allocatable memory to satisfy the pod's memory request. The pod's memory request (spec.containers[].resources.requests.memory) must be less than or equal to a node's allocatable memory for the pod to be scheduled. Since no node meets this requirement, the pod remains in Pending state.

Exam trap

The trap here is that candidates confuse memory requests with memory limits, assuming a low limit causes scheduling failure, when in fact the scheduler only evaluates requests, and limits only affect runtime OOM behavior.

How to eliminate wrong answers

Option B is wrong because a misconfigured liveness probe would cause the pod to be restarted or marked as unhealthy after it starts, not prevent it from being scheduled; scheduling failures occur before the pod runs. Option C is wrong because a ResourceQuota would cause an error like 'exceeded quota' or 'forbidden' when creating the pod, not a node-level 'Insufficient memory' message from the scheduler. Option D is wrong because a memory limit that is set too low would affect the pod's runtime behavior (e.g., OOMKill) but does not impact scheduling; the scheduler only considers the memory request, not the limit, when determining node fit.

Full explanation →

314

Multi-Selecteasy

Which TWO of the following are valid reasons to use a readiness probe? (Select 2)

Select 2 answers

A.To prevent traffic from being sent to a pod that is not ready due to a dependency

B.To ensure the pod is not added to a Service until the application is ready

C.To monitor resource usage and scale the pod

D.To delay the start of the application until a database is available

E.To restart the container if it becomes unresponsive

AnswersA, B

A readiness probe determines whether a pod can accept requests by periodically executing a check (HTTP, TCP, or command) inside the container; if the check fails because a required dependency, such as a database or configuration service, is not yet available, the pod is marked NotReady. The kubelet then removes the pod's IP from all backing Service EndpointSlices, so live traffic is never forwarded to a container that would fail the request. This prevents users from hitting a pod that is running but still initializing its dependent components.

Why this answer

A readiness probe is used to determine whether a pod is ready to serve traffic. Option A is correct because it prevents traffic from being sent to a pod that is not ready due to a dependency, such as a database or cache that hasn't fully initialized. The kubelet uses the probe's success or failure to control whether the pod's IP address is added to the endpoints of a Service, ensuring only ready pods receive requests.

Exam trap

CNCF often tests the distinction between readiness, liveness, and startup probes; the trap here is confusing the purpose of a readiness probe (traffic routing) with that of a liveness probe (container restart) or a startup probe (delaying other probes).

Full explanation →

315

MCQmedium

A Helm chart has the following template snippet: '{{ .Values.replicaCount }}'. You want to set replicaCount to 5 during installation. Which command should you use?

A.helm install my-release mychart --name replicaCount=5

B.helm install my-release mychart --values replicaCount=5

C.helm install my-release mychart --set replicaCount=5

D.helm install my-release mychart --set-string replicaCount=5

AnswerC

Using `--set replicaCount=5` is the correct and idiomatic way to override a single chart value from the CLI. Helm parses the value using YAML type inference, so `5` is interpreted as an integer, which aligns with the expected type for a Deployment's `replicas` field. This avoids the need to create a separate values file and gives the highest precedence among value sources, taking precedence over the chart's default `values.yaml` and any `-f` files. The `--set` flag also supports comma-separated key/value pairs and complex structures with dots.

Why this answer

The `--set` flag in Helm allows you to directly override a single value in a chart's `values.yaml` file from the command line. This is the standard way to set `replicaCount` to 5 during installation without modifying the chart or using a separate values file.

Exam trap

The trap here is that candidates confuse `--set` with `--values` or mistakenly use deprecated `--name` syntax from Helm v2, but the CKAD exam tests Helm v3 where `--set` is the correct flag for inline value overrides.

How to eliminate wrong answers

Option A is wrong because `--name` is not a valid Helm flag; Helm uses positional arguments for release name and chart, and `--name` is from older Helm v2 syntax (deprecated in Helm v3). Option B is wrong because `--values` (or `-f`) expects a file path or URL containing YAML values, not a key=value pair; it would fail to parse 'replicaCount=5' as a file. Option D is wrong because `--set-string` forces the value to be interpreted as a string, but `replicaCount` is typically an integer; using `--set-string` would pass the string '5' instead of the integer 5, which could cause type mismatch errors in templates expecting numeric operations.

Full explanation →

316

Multi-Selecthard

Which TWO of the following are valid ways to mount a Secret into a pod as environment variables? (Select exactly 2)

Select 2 answers

A.env: - name: SECRET_KEY valueFrom: configMapKeyRef: name: my-secret key: key

B.env: - name: SECRET_KEY valueFrom: secretEnvRef: name: my-secret key: key

C.envFrom: - configMapRef: name: my-secret

D.env: - name: SECRET_KEY valueFrom: secretKeyRef: name: my-secret key: key

E.envFrom: - secretRef: name: my-secret

AnswersD, E

This correctly uses secretKeyRef to reference a specific key from a Secret. The name field identifies the Secret resource, and key specifies which entry to extract; the value is base64-decoded before being set as the environment variable. This is the standard, explicit method for injecting a single secret value into a container.

Why this answer

`secretKeyRef` is the standard Kubernetes API field for referencing a specific key from a Secret object and injecting its value as an environment variable. Option E is correct because `envFrom` with `secretRef` allows you to load all key-value pairs from a Secret as environment variables into the pod, which is a valid and common pattern.

Exam trap

The trap here is that candidates often confuse `configMapKeyRef`/`configMapRef` with `secretKeyRef`/`secretRef`, or invent non-existent fields like `secretEnvRef`, because the syntax for Secrets and ConfigMaps is nearly identical except for the resource-specific keyword.

Full explanation →

317

MCQeasy

What is the purpose of the 'spec.externalName' field in a Service of type ExternalName?

A.To expose the service on a static port on each node

B.To expose the service using an external load balancer

C.To return a CNAME record pointing to an external domain

D.To assign a static cluster IP

AnswerC

ExternalName is a special Service type that maps the Service's in-cluster DNS name to an external canonical name by returning a CNAME record from CoreDNS or kube-dns. When a client resolves the Service name from inside the cluster, DNS replies with the target external domain (for example, mydb.example.com) instead of a virtual IP, and since no selectors or endpoints exist, there is no proxying or port mapping. This is ideal for providing a stable in-cluster alias to an external database or SaaS endpoint that lives outside Kubernetes.

Why this answer

The 'spec.externalName' field in a Service of type ExternalName is used to map the service to a DNS name (e.g., 'api.example.com') rather than to a set of pods. When a client resolves the service's DNS name, Kubernetes returns a CNAME record pointing to the external domain, effectively aliasing the service to an external endpoint. This allows internal applications to access external services using a local Kubernetes service name without needing to manage endpoints manually.

Exam trap

The trap here is that candidates confuse ExternalName with other service types (NodePort, LoadBalancer, ClusterIP) and think it exposes the service externally, when in fact it only provides a DNS-level alias without any network proxy or external exposure.

How to eliminate wrong answers

Option A is wrong because exposing a service on a static port on each node is the purpose of a NodePort service, not an ExternalName service. Option B is wrong because exposing a service using an external load balancer is the purpose of a LoadBalancer service, which provisions a cloud load balancer, not an ExternalName service. Option D is wrong because assigning a static cluster IP is the purpose of a ClusterIP service (or a headless service with a specific cluster IP), whereas ExternalName services do not have a cluster IP and instead return a CNAME record.

Full explanation →

318

MCQhard

You have a Deployment with the following strategy: rollingUpdate: maxSurge: 25%, maxUnavailable: 25%. The Deployment has 4 replicas. During an update, what is the minimum number of pods guaranteed to be available?

A.3

B.2

C.4

D.1

AnswerA

With a Deployment of 4 replicas and the default rolling update strategy, maxUnavailable is 25% of 4, which equals 1 (Kubernetes rounds up for maxUnavailable). This means at any point during the rollout, at most one Pod can be taken down or become unhealthy, so at least 3 replicas remain available to serve traffic. Thus the minimum guaranteed availability is 3, not 2 or 4.

Why this answer

With 4 replicas and a rolling update strategy of maxSurge: 25% and maxUnavailable: 25%, the maximum number of pods that can be unavailable during the update is 25% of 4, which is 1. Therefore, the minimum number of pods guaranteed to be available is 4 - 1 = 3. This is calculated by rounding down the maxUnavailable value (1) and ensuring the desired replica count minus unavailable pods equals the minimum available.

Exam trap

The trap here is that candidates often misinterpret the percentage calculation, incorrectly rounding up maxUnavailable (e.g., 25% of 4 = 1, but some might think it's 2 due to rounding up or misapplying the surge logic), leading them to choose 2 or 1 instead of the correct 3.

How to eliminate wrong answers

Option B (2) is wrong because it assumes maxUnavailable is 50% (2 pods), but 25% of 4 is 1, not 2. Option C (4) is wrong because it ignores the maxUnavailable setting, implying no pods can be unavailable during the update, which contradicts the rolling update strategy. Option D (1) is wrong because it assumes maxUnavailable is 75% (3 pods), which is far beyond the configured 25% limit.

Full explanation →

319

Multi-Selecthard

Which THREE statements are true about init containers? (Select 3)

Select 3 answers

A.Init containers support liveness and readiness probes

B.Init containers cannot have resource limits

C.Init containers must complete successfully before any main container starts

D.Init containers run sequentially in the order they are defined

E.If an init container fails, it will restart until it succeeds, regardless of the pod's restartPolicy

AnswersC, D, E

This is the fundamental purpose of an init container: the kubelet will not start any main container until every init container has exited with a zero exit code. The main containers are held in a pending state while init containers execute. If any init container fails, the entire pod's startup is blocked, and the failed init container is retried according to the restart policy, so the main containers never see the failed state.

Why this answer

Init containers are specialized containers that run to completion before any main application containers in the pod start. They must exit with a zero status (success) for the pod to proceed to the next init container or to start the main containers. This ensures prerequisite setup tasks are completed before the application runs.

Exam trap

The trap here is that candidates confuse init containers with regular containers, assuming they support probes or cannot have resource limits, when in fact init containers are a distinct type with different lifecycle rules and full support for resource constraints.

Full explanation →

320

MCQeasy

What is the default type of a Kubernetes Service when no type is specified in the YAML manifest?

A.NodePort

B.LoadBalancer

C.ClusterIP

D.ExternalName

AnswerC

ClusterIP is the default service type when the `type` field is not declared in the Service definition. It assigns a stable virtual IP address accessible only within the cluster, making it ideal for internal pod-to-pod communication. Unlike NodePort or LoadBalancer, it does not expose the service to external traffic without additional configuration, which is why it is the safe, private default.

Why this answer

When no `type` field is specified in a Kubernetes Service YAML manifest, the default type is `ClusterIP`. This is defined in the Kubernetes API specification: the `spec.type` field defaults to `ClusterIP` if omitted. A ClusterIP service exposes the service on a cluster-internal IP address, making it only reachable from within the cluster, which is the fundamental behavior for internal service discovery.

Exam trap

The trap here is that candidates often assume a Service must be explicitly typed to work, or they confuse the default with `NodePort` because they commonly use `NodePort` for external access in minikube or kind environments, but the Kubernetes default is always `ClusterIP` unless overridden.

How to eliminate wrong answers

Option A is wrong because `NodePort` is not the default; it must be explicitly set, and it exposes the service on a static port on each node's IP, which is a higher-level type that builds on ClusterIP. Option B is wrong because `LoadBalancer` is not the default; it requires explicit specification and typically integrates with external cloud provider load balancers, also building on NodePort and ClusterIP. Option D is wrong because `ExternalName` is not the default; it maps a service to a DNS name (via CNAME records) and is used for external service integration, not for internal cluster networking.

Full explanation →

321

MCQeasy

Which command shows the CPU and memory usage of all pods in the current namespace?

A.kubectl top node

B.kubectl top --all

C.kubectl top pod pod-name

D.kubectl top pod

AnswerD

kubectl top pod — correct because it directly invokes the top command with the pod resource type, without a specific pod name, which causes it to retrieve CPU and memory usage for all pods running in the current namespace from the metrics API. This is the exact syntax required to get a namespace-wide view of pod resource consumption.

Why this answer

`kubectl top pod` without a specific pod name retrieves CPU and memory usage metrics for all pods in the current namespace, as the command defaults to listing all pods when no pod name is provided. This relies on the metrics-server collecting resource usage data from the kubelet's cAdvisor endpoint via the Resource Metrics API.

Exam trap

CNCF often tests the misconception that `kubectl top pod` requires a pod name to show metrics, but omitting the pod name lists all pods in the current namespace, which is the correct syntax for the question's requirement.

How to eliminate wrong answers

Option A is wrong because `kubectl top node` shows resource usage for nodes, not pods, and does not filter by namespace. Option B is wrong because `kubectl top --all` is not a valid kubectl command; the `--all` flag is used with `kubectl get` to select resources across all namespaces, but `kubectl top` does not support that flag. Option C is wrong because `kubectl top pod pod-name` shows metrics for a single specific pod, not all pods in the namespace.

Full explanation →

322

MCQmedium

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

A.To prevent DNS resolution of the service

B.To enable TLS termination at the service level

C.To provide load balancing across the pods

D.To provide stable network identities and DNS records for each pod in the StatefulSet

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

323

MCQmedium

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

A.COPY . /app\nRUN npm install

B.ADD package*.json /app/\nRUN npm install\nADD . /app/

C.COPY package*.json /app/\nRUN npm install\nCOPY . /app/

D.ADD . /app\nRUN npm install

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

324

MCQhard

You have a Deployment with a liveness probe using an exec command. The probe currently runs 'cat /tmp/healthy' and fails after 3 failures. You notice the pod is being restarted even though the application is healthy. What is the most likely cause?

A.The readiness probe is misconfigured and is shutting down the pod

B.The liveness probe is using the wrong HTTP endpoint

C.The file /tmp/healthy does not exist or is not being updated by the application

D.The probe timeoutSeconds is set too low, causing the probe to fail before the command completes

AnswerC

The exec command 'cat /tmp/healthy' succeeds only if that file exists and is readable. If the application fails to create or regularly update this file, the command exits with a non-zero status, causing the liveness probe to fail. After the configured failureThreshold is exceeded, kubelet kills and restarts the container, matching the symptom of a restarting Deployment. This is the expected failure mode for this probe definition.

Why this answer

The liveness probe executes 'cat /tmp/healthy' and fails after 3 consecutive failures. If the file /tmp/healthy does not exist or is not being updated by the application, the command returns a non-zero exit code, causing the probe to fail and Kubernetes to restart the container even though the application process itself is running and healthy.

Exam trap

The trap here is that candidates confuse the liveness probe's exec command with an HTTP probe or assume the probe is failing due to timing, when the real issue is the command's exit code reflecting the absence or staleness of the file.

How to eliminate wrong answers

Option A is wrong because a readiness probe does not shut down pods; it only controls whether the pod receives traffic from Services. Option B is wrong because the liveness probe is explicitly configured as an exec command, not an HTTP endpoint, so the HTTP endpoint is irrelevant. Option D is wrong because if the command completes quickly (e.g., 'cat /tmp/healthy'), a low timeoutSeconds would not cause failure; the issue is the command's exit code, not its execution time.

Full explanation →

325

MCQmedium

A developer wants to restrict network traffic so that only pods with label 'app: frontend' can communicate with pods labeled 'app: backend' on port 8080. Which Kubernetes resource should be used?

A.NetworkPolicy

B.ResourceQuota

C.PodSecurityPolicy

D.RoleBinding

AnswerA

NetworkPolicy is the correct Kubernetes resource for restricting network traffic to and from pods. It uses label selectors to match pods and defines ingress/egress rules in the spec, allowing you to control traffic at the IP/port level. For example, you can default-deny all ingress and then allow only from specific pod labels.

Why this answer

A NetworkPolicy is the correct Kubernetes resource because it defines ingress and egress rules to control pod-to-pod communication based on labels, namespaces, and ports. By specifying a podSelector matching 'app: backend', an ingress rule allowing traffic from pods with label 'app: frontend' on port 8080, and a policyTypes field including 'Ingress', this resource enforces the desired restriction at the network layer using iptables or eBPF under the hood.

Exam trap

The trap here is that candidates confuse NetworkPolicy with RBAC or security context controls, mistakenly thinking RoleBinding or PodSecurityPolicy can restrict network traffic, when in fact only NetworkPolicy (with a compatible CNI) provides pod-level network access control.

How to eliminate wrong answers

Option B is wrong because ResourceQuota limits aggregate resource consumption (CPU, memory, storage) per namespace, not network traffic between pods. Option C is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21, removed in 1.25) controls security context constraints for pods, such as privileged mode or host namespaces, not network connectivity. Option D is wrong because RoleBinding grants RBAC permissions to users or service accounts within a namespace, but does not affect network traffic between pods.

Full explanation →

326

MCQmedium

You have a Deployment with 3 replicas. You run 'kubectl rollout pause deployment/app'. Which command would you use to resume the rollout?

A.kubectl rollout resume deployment/app

B.kubectl rollout continue deployment/app

C.kubectl rollout undo deployment/app

D.kubectl rollout restart deployment/app

AnswerA

kubectl rollout resume deployment/app is the correct command because it exits the paused state created by `kubectl rollout pause`, allowing the Deployment controller to proceed with the current rollout revision. When a rollout is paused, the controller stops creating new ReplicaSets or scaling them until resumed; this command explicitly tells the controller to continue reconciling the desired state, picking up any pending changes that occurred during the pause.

Why this answer

`kubectl rollout resume deployment/app` is the specific command to resume a paused rollout, allowing the Deployment controller to continue processing updates to the Pod template. When a rollout is paused with `kubectl rollout pause`, the controller stops applying changes to the ReplicaSet; `resume` re-enables that reconciliation loop.

Exam trap

The trap here is that candidates confuse 'resume' with 'continue' or 'restart', assuming any verb that implies 'go forward' works, but Kubernetes has a precise `resume` subcommand for unpausing a rollout.

How to eliminate wrong answers

Option B is wrong because `kubectl rollout continue` is not a valid kubectl command; the correct verb for resuming a paused rollout is `resume`, not `continue`. Option C is wrong because `kubectl rollout undo` rolls back the Deployment to a previous revision, which is unrelated to pausing or resuming the current rollout process. Option D is wrong because `kubectl rollout restart` triggers a new rollout by restarting all Pods (e.g., to pick up new ConfigMaps), but it does not resume a previously paused rollout.

Full explanation →

327

MCQeasy

A developer wants to expose a Deployment named 'web-app' (with label 'app: web') as a ClusterIP service on port 80. Which command achieves this?

A.kubectl expose service web-app --port=80

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

C.kubectl expose deployment web-app --port=80

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

AnswerC

kubectl expose deployment web-app --port=80 is the correct imperative command because it creates a Service from the Deployment resource, automatically inheriting the Deployment's pod selector and setting the Service's target port to the container port. This ensures the Service has endpoints that match the pods managed by the Deployment, providing a stable DNS name and load-balanced access to the application.

Why this answer

`kubectl expose deployment web-app --port=80` creates a ClusterIP Service that selects Pods based on the labels of the specified Deployment (in this case, `app: web`). The `expose` command automatically reads the Pod template labels from the Deployment and applies them as the Service's selector, then maps the Service's port 80 to the target port of the containers in the selected Pods.

Exam trap

The trap here is that candidates confuse `kubectl expose` with `kubectl create service`; `expose` automatically derives selectors from the resource (Deployment, Pod, etc.), while `create service` creates a bare Service without selectors unless explicitly provided.

How to eliminate wrong answers

Option A is wrong because `kubectl expose service` attempts to expose an existing Service, but the Service 'web-app' does not exist yet; this command would fail with a 'not found' error. Option B is wrong because `kubectl create service clusterip web-app --tcp=80` creates a ClusterIP Service with no selector, meaning it will not automatically route traffic to the Pods of the 'web-app' Deployment; it requires manual selector configuration. Option D is wrong because `kubectl expose pod web-app --port=80` creates a Service that selects only that specific Pod by name, not the Deployment's Pods; if the Pod is recreated (e.g., during a rolling update), the Service's selector will no longer match, breaking connectivity.

Full explanation →

328

Multi-Selectmedium

Which TWO statements are true about readiness probes? (Select two.)

Select 2 answers

A.Readiness probes are only executed when the pod is first started

B.Readiness probes can be configured as httpGet, exec, tcpSocket, or gRPC

C.A failing readiness probe causes the pod to be restarted

D.Readiness probes are defined in the pod spec under 'startupProbe'

E.A failing readiness probe removes the pod from the Service's endpoints

AnswersB, E

This statement is correct because readiness probes support the exact same four handler types as liveness probes: `httpGet` (sending an HTTP GET request to a specific path/port), `exec` (running a command in the container), `tcpSocket` (attempting a TCP connection to a port), and `gRPC` (performing a gRPC health check, available as a beta feature in recent Kubernetes versions). Each handler has its own configuration fields, but all are valid for determining container readiness. The readiness probe is defined under the `readinessProbe` key in the container spec.

Why this answer

Readiness probes support four handler types: httpGet, exec, tcpSocket, and gRPC (since Kubernetes 1.24). These are defined in the container spec under the `readinessProbe` field, allowing the kubelet to check container readiness using HTTP status codes, command exit codes, TCP port connectivity, or gRPC health checks.

Exam trap

The trap here is confusing readiness probes with liveness probes: candidates often think a failing readiness probe restarts the pod, but it only affects traffic routing, while liveness probes handle restarts.

Full explanation →

329

Multi-Selectmedium

Which THREE of the following are valid Kustomize features? (Select THREE)

Select 3 answers

A.serviceAccount

B.resources

C.ingress

D.patchesStrategicMerge

E.configMapGenerator

AnswersB, D, E

The 'resources' field is a foundational Kustomize feature that declares all the YAML manifests (files or directories) to be included in the final rendered output. These resources can be local files, remote URLs, or other kustomization directories, and Kustomize will merge, patch, and transform them according to the other directives in kustomization.yaml. Without 'resources', a kustomization has nothing to process, making it the core entry point for defining what your application consists of.

Why this answer

`resources` is a core Kustomize field used to list the YAML files (or directories) that form the base set of Kubernetes resources to be customized. Without `resources`, Kustomize has no manifests to process, making it essential for defining the input to the kustomization build.

Exam trap

The exam often tests the distinction between Kubernetes resource kinds (like `serviceAccount` or `ingress`) and Kustomize-specific directives (like `resources`, `patchesStrategicMerge`, or `configMapGenerator`), trapping candidates who confuse the two categories.

Full explanation →

330

Multi-Selectmedium

Which TWO resources are used to enforce resource quotas at the namespace level? (Select TWO.)

Select 2 answers

A.HorizontalPodAutoscaler

B.NetworkPolicy

C.ResourceQuota

D.PodDisruptionBudget

E.LimitRange

AnswersC, E

ResourceQuota is a namespace-scoped admission control object that sets aggregate limits on compute resources (e.g., cpu, memory) and on the number of certain objects (e.g., pods, services, PVCs) that can be created within that namespace. When any creation or update would exceed the quota, the API server rejects it with a 403 Forbidden, preventing resource exhaustion. This makes ResourceQuota one of the two core tools for enforcing namespace-level resource quotas.

Why this answer

ResourceQuota (C) is correct because it is the Kubernetes object that enforces aggregate quotas on a namespace, capping total CPU/memory requests and limits, pod counts, and object counts such as services, secrets, and PVCs. LimitRange (E) is correct because it enforces per-container or per-pod defaults and min/max constraints within a namespace, ensuring individual workloads cannot exceed or bypass the namespace's quota boundaries. HorizontalPodAutoscaler (A) only scales replica counts based on metrics and does not enforce quotas.

NetworkPolicy (B) governs pod-level ingress/egress traffic rules, not resource consumption. PodDisruptionBudget (D) limits voluntary disruptions to maintain availability, not resource usage.

Exam trap

CNCF often tests the distinction between cluster-level and namespace-level resource controls, and the trap here is that candidates confuse HorizontalPodAutoscaler (which scales pods) with ResourceQuota (which caps total usage), or think NetworkPolicy enforces resource limits due to its 'policy' name.

Full explanation →

331

MCQmedium

You manage a Deployment named 'web' in namespace 'prod' whose pods mount a ConfigMap named 'web-config' as a volume at /etc/web. You update the ConfigMap data, but the running pods still serve the old configuration because the application only reads the mounted file at startup. You must roll out the new configuration to all pods with zero downtime and preserve the ability to roll back. What is the MOST appropriate action?

A.Edit the Deployment and change the container image tag to a new value, forcing Kubernetes to recreate all pods with the refreshed ConfigMap.

B.Use 'kubectl exec' into each pod and run a command to signal the application process to re-read /etc/web, then wait for the kubelet to sync the volume.

C.Delete the ConfigMap and recreate it with the updated data so the kubelet re-syncs the projected volume contents immediately.

D.Run 'kubectl rollout restart deployment/web -n prod', which adds a restartedAt annotation to the pod template and triggers a new revision.

AnswerD

Running kubectl rollout restart patches the Deployment's pod template with a kubectl.kubernetes.io/restartedAt annotation, creating a new ReplicaSet revision. Because volume-mounted ConfigMaps are refreshed asynchronously but the app reads only at startup, restarting pods forces them to load the new values. The old ReplicaSet is retained, so kubectl rollout undo remains available for rollback.

Why this answer

A rollout restart is the standard CKAD pattern for forcing pods to reload configuration that is consumed only at process start. It creates a new ReplicaSet revision by mutating the pod template annotation, so the rolling update proceeds with zero downtime and the previous ReplicaSet remains for rollback. Deleting the ConfigMap, changing the image, or manually signaling processes do not produce a clean, reversible rollout.

Exam trap

The trap here is assuming that because mounted ConfigMap volumes are eventually updated on disk, the application will automatically pick up new values without any pod restart.

Full explanation →

332

Multi-Selecthard

You run 'kubectl get pods' and see a pod in 'CrashLoopBackOff' state. Which TWO conditions could cause this state?

Select 2 answers

A.The node is out of disk space

B.The container exits immediately with a non-zero exit code

C.The readiness probe is failing

D.The pod is pending because of insufficient resources

E.The liveness probe is failing and restarting the container

AnswersB, E

CrashLoopBackOff is the Kubernetes state when a container repeatedly starts, exits with an error, and is restarted by the kubelet. A non-zero exit code from the main process signals that the application failed during startup or at runtime, prompting a restart. After each successive failure, the kubelet applies an exponential backoff (10s, 20s, 40s, up to 5m) to prevent tight restart loops, and this cycle produces the CrashLoopBackOff status. This option is correct because an immediate non-zero exit is the direct mechanism driving the crash loop.

Why this answer

A container that exits immediately with a non-zero exit code causes Kubernetes to restart it repeatedly, leading to the CrashLoopBackOff state. The kubelet detects the exit code and increments the restart counter, applying an exponential backoff delay. This is the classic symptom of an application crash or misconfiguration.

Exam trap

The CKAD exam often tests the distinction between probe failures (which may or may not cause restarts) and immediate container exits (which always cause CrashLoopBackOff), so candidates mistakenly think any restart leads to CrashLoopBackOff, but only repeated restarts with backoff produce that specific state.

Full explanation →

333

MCQmedium

You have a Service named 'api' with selectors that match pods. However, curl to the Service cluster IP times out. 'kubectl get endpoints api' shows no endpoints. What is the most likely cause?

A.The Service's selector does not match any pod labels.

B.The Service is of type ExternalName.

C.The pods are not listening on the target port.

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

AnswerA

A Kubernetes Service selector is evaluated by the endpoint controller, which builds the Endpoints object from Pods in the same namespace whose labels exactly match the key-value pairs in the selector. When no running Pod has all the required labels, the Endpoints object has no addresses (subsets are empty), so there is nothing for the Service to route traffic to. This is the classic cause of empty endpoints, distinct from a wrong targetPort, which would still populate endpoints with Pod IPs.

Why this answer

When a Service has no endpoints, it means the Service's selector query returned zero matching pods. Since `kubectl get endpoints api` shows no endpoints, the most likely cause is that the selector labels defined in the Service do not match the labels on any running pods. This is the first thing to check when a Service is unreachable.

Exam trap

The trap here is that candidates often assume the issue is a port mismatch or namespace problem, but the absence of endpoints directly points to a selector mismatch, which is the first diagnostic step in Kubernetes networking troubleshooting.

How to eliminate wrong answers

Option B is wrong because an ExternalName Service does not use selectors or endpoints; it returns a CNAME record, so it would never show endpoints via `kubectl get endpoints`. Option C is wrong because if pods exist but are not listening on the target port, the endpoints would still be populated (the Service would have endpoints pointing to the pods), but the connection would fail at the pod level, not result in zero endpoints. Option D is wrong because a Service can only select pods in the same namespace; if the pods were in a different namespace, the selector would simply not match them, which is actually a subset of the correct answer (selector mismatch), but the question asks for the 'most likely cause' and the direct reason is the selector mismatch itself, not the namespace difference per se.

Full explanation →

334

MCQmedium

A pod is stuck in 'Pending' state. You run 'kubectl describe pod' and see '0/1 nodes are available: 1 Insufficient cpu, 1 Insufficient memory.' What does this mean?

A.The container image is not available

B.The liveness probe is failing

C.The pod's resource requests exceed available resources on any node

D.The container is crashing due to an error

AnswerC

The scheduler filters nodes by checking whether each node's allocatable CPU and memory can accommodate the pod's declared requests. When every node fails that check, the events on the pod show '0/N nodes are available' with 'Insufficient cpu' or 'Insufficient memory', and the pod remains Pending until resources free up or the request is lowered.

Why this answer

The 'Pending' state indicates the pod has been accepted by the Kubernetes API server but cannot be scheduled onto a node. The message '0/1 nodes are available: 1 Insufficient cpu, 1 Insufficient memory' means the scheduler evaluated all nodes and found that none had enough allocatable CPU and memory to satisfy the pod's resource requests. This is a scheduling failure caused by the pod's requests exceeding the available resources on any node.

Exam trap

CNCF often tests the distinction between pod lifecycle phases (Pending, Running, CrashLoopBackOff) and the specific error messages in 'kubectl describe pod', leading candidates to confuse scheduling failures with runtime issues like image pull errors or probe failures.

How to eliminate wrong answers

Option A is wrong because an unavailable container image would cause the pod to stay in 'Pending' or 'ImagePullBackOff' state, but the error message would reference 'ImagePullBackOff' or 'ErrImagePull', not resource insufficiency. Option B is wrong because a failing liveness probe would cause the pod to be restarted (CrashLoopBackOff) or become 'Running' but unhealthy, not stuck in 'Pending' — liveness probes are only checked after the container starts. Option D is wrong because a container crashing due to an error would result in 'CrashLoopBackOff' or 'Error' state, not 'Pending', and the describe output would show crash loop backoff or exit code details, not resource insufficiency.

Full explanation →

335

Multi-Selecteasy

Which TWO of the following are valid strategies for updating a Deployment?

Select 2 answers

A.Canary

B.RollingUpdate

C.Ramped

D.Blue/Green

E.Recreate

AnswersB, E

RollingUpdate is the default Deployment strategy, which replaces old pods with new ones incrementally to maintain availability. It uses two parameters: `maxSurge` (number of extra pods allowed above desired count) and `maxUnavailable` (number of pods allowed to be down during update). This strategy is ideal for stateless applications that can tolerate multiple versions running briefly during the rollout.

Why this answer

RollingUpdate is the default update strategy in Kubernetes Deployments. It gradually replaces old Pods with new ones, ensuring zero downtime by incrementally scaling down old ReplicaSets and scaling up new ones based on configurable parameters like maxSurge and maxUnavailable.

Exam trap

CNCF often tests the distinction between built-in Kubernetes Deployment strategies (RollingUpdate, Recreate) and external deployment patterns (Canary, Blue/Green, Ramped) that require additional tooling or manual steps.

Full explanation →

336

Multi-Selecthard

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

Select 3 answers

A.fsGroup

B.capabilities

C.seccompProfile

D.runAsNonRoot

E.allowPrivilegeEscalation

AnswersA, C, D

fsGroup is a valid PodSecurityContext field. It sets the supplementary group ID applied to all containers in the pod, and Kubernetes recursively changes ownership of mounted volumes to that group, enabling shared volume access across containers.

Why this answer

fsGroup (A) is a valid PodSecurityContext field that sets a supplemental group ID applied to all containers in the pod, used for volume ownership and permissions. seccompProfile (C) is valid at the pod level and defines the seccomp profile applied to all containers in the pod. runAsNonRoot (D) is a valid PodSecurityContext field that ensures containers run as a non-root user by validating the image's USER directive. capabilities (B) and allowPrivilegeEscalation (E) are not PodSecurityContext fields; they belong to the container-level SecurityContext, not the pod-level one.

Exam trap

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

Full explanation →

337

MCQmedium

A container in a pod is expected to shut down gracefully within 30 seconds when it receives SIGTERM. How should you configure the pod to ensure the container is given enough time to shut down before being forcefully killed?

A.Set spec.terminationGracePeriod: 35

B.Set spec.terminationGracePeriodSeconds: 35

C.Set spec.terminationGracePeriodSeconds: 300

D.Set spec.terminationGracePeriodSeconds: 20

AnswerB

Setting spec.terminationGracePeriodSeconds to 35 is appropriate because this pod-level field defines the maximum time allowed between the kubelet sending SIGTERM and forcibly sending SIGKILL. With an expected shutdown time around 35 seconds, this value gives the container sufficient time to complete graceful cleanup without delaying cluster operations.

Why this answer

terminationGracePeriodSeconds defines the time Kubernetes waits after sending SIGTERM before sending SIGKILL. Setting it to 35 seconds gives the container a 5-second buffer beyond the expected 30-second shutdown time. Option B is correct because 35 seconds provides sufficient time without being excessive.

Option A uses an invalid field name (terminationGracePeriod instead of terminationGracePeriodSeconds). Option C sets the grace period to 300 seconds, which is excessively long and could delay pod termination. Option D sets the grace period to 20 seconds, which is too short and may not allow the container to shut down gracefully within the expected 30 seconds.

Full explanation →

338

MCQhard

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

A.Set both Deployments to 10 replicas and use an Ingress with a canary weight annotation (e.g., canary-weight: '10')

B.Set the canary Deployment replicas to 1 and the stable to 9, and update the Service selector to include version: v2

C.Set the canary Deployment replicas to 10 and the stable to 1

D.Set the canary Deployment replicas to 1 and the stable to 9, and keep the Service selector as 'app: myapp'

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

339

MCQeasy

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

A.runAsNonRoot: true

B.runAsUser: 1000

C.fsGroup: 1000

D.privileged: false

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

340

MCQhard

Refer to the exhibit. A Pod is defined with security contexts at both the container and Pod level. Which of the following statements accurately describes the effective security configuration?

A.The Pod will fail to start because runAsNonRoot conflicts with the container's runAsUser.

B.The container runs as user 1000, but the Pod-level runAsNonRoot overrides the container's runAsUser to enforce non-root.

C.The container runs as user 1000, group 2000, with NET_ADMIN capability added, and the Pod-level runAsNonRoot: true is also enforced.

D.The container runs as root because the Pod-level runAsNonRoot is ignored when container-level capabilities are set.

AnswerC

The container's effective identity is user 1000 and group 2000 as defined by its securityContext, and the NET_ADMIN capability is added unambiguously. The Pod-level runAsNonRoot: true is a separate, compatible gate that the kubelet checks; because the container runs as UID 1000, the gate passes. Both levels of securityContext are enforced, with container-level fields supplying the specifics and pod-level fields adding global constraints.

Why this answer

Kubernetes merges Pod-level and container-level security contexts, with the container-level settings taking precedence for fields that overlap, but Pod-level settings that are not overridden (like runAsNonRoot) remain enforced. In this case, the container runs as user 1000, group 2000, with NET_ADMIN capability added, and the Pod-level runAsNonRoot: true is also enforced, ensuring the container does not run as root.

Exam trap

CNCF often tests the misconception that Pod-level runAsNonRoot overrides container-level runAsUser, when in fact they are complementary checks, and the container's runAsUser must be non-root for the Pod to start.

How to eliminate wrong answers

Option A is wrong because runAsNonRoot: true does not conflict with runAsUser: 1000; it only prevents the container from running as UID 0, and user 1000 is non-root, so the Pod starts successfully. Option B is wrong because runAsNonRoot does not override runAsUser; it is an additional check that the container's effective UID is not 0, and user 1000 satisfies that condition. Option D is wrong because Pod-level runAsNonRoot is not ignored when container-level capabilities are set; capabilities like NET_ADMIN do not affect the user ID, and runAsNonRoot remains enforced.

Full explanation →

341

MCQmedium

A user runs: kubectl apply -f job.yaml. The Job spec has backoffLimit: 0. The pod fails immediately. What happens?

A.The Job is retried indefinitely

B.The pod is restarted until it succeeds

C.The Job enters a Failed state

D.A new pod is created automatically

AnswerC

The Job controller evaluates the failure count against backoffLimit after a Pod fails; because the limit is 0, the first failure already equals the maximum allowed retries. As a result, the controller marks the Job with the Failed condition, records the failed Pod in status, and stops any further reconciliation. No pending retries remain, so the Job cannot be Active or Complete; its terminal state is Failed.

Why this answer

When `backoffLimit: 0` is set in a Job spec and the pod fails immediately, the Job controller does not retry the pod because the backoff limit is zero. According to Kubernetes Job semantics, the Job is considered failed once the number of failures reaches the `backoffLimit` (0 in this case), so the Job transitions to a Failed state without any further pod creation or retries.

Exam trap

The trap here is that candidates often confuse `backoffLimit` with pod restart policies (e.g., `restartPolicy: OnFailure`), but `backoffLimit` controls the number of retries at the Job level, not pod restarts, and a value of 0 means no retries, not infinite retries.

How to eliminate wrong answers

Option A is wrong because `backoffLimit: 0` means the Job will not retry at all, not indefinitely; indefinite retries would require a negative value or no limit. Option B is wrong because the pod is not restarted; the Job controller does not restart pods—it creates new pods, and with `backoffLimit: 0`, no new pod is created after the first failure. Option D is wrong because a new pod is not created automatically; the Job controller only creates a new pod if the failure count is below the `backoffLimit`, which is 0, so it stops immediately.

Full explanation →

342

MCQhard

A pod spec has terminationGracePeriodSeconds: 30. The main process ignores SIGTERM. After 30 seconds, what happens?

A.The pod remains running indefinitely

B.The pod enters a CrashLoopBackOff state

C.The pod is rescheduled to another node

D.SIGKILL is sent to forcefully terminate the container

AnswerD

Once the grace period has elapsed, the kubelet sends SIGKILL (signal 9) to the container’s main process to force immediate termination. SIGKILL cannot be caught, handled, or ignored by the application, so the process dies instantly and the container is removed. This is the final step in the termination sequence: SIGTERM is sent first, and SIGKILL is the escalation when the process has not voluntarily exited within the configured terminationGracePeriodSeconds.

Why this answer

When the main process in a container ignores SIGTERM, Kubernetes waits for the duration specified in `terminationGracePeriodSeconds` (30 seconds) and then sends SIGKILL to forcefully terminate the container. This ensures that pods do not hang indefinitely during shutdown, as SIGKILL cannot be ignored by any process.

Exam trap

The trap here is that candidates assume a process ignoring SIGTERM will cause the pod to hang forever, but Kubernetes enforces a hard kill after the grace period, making D the only correct answer.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not allow a pod to run indefinitely after the grace period expires; it enforces termination with SIGKILL. Option B is wrong because CrashLoopBackOff is a state for pods that repeatedly crash after starting, not for pods that are gracefully terminated or killed. Option C is wrong because rescheduling to another node occurs only if the pod is deleted or evicted, not during a normal termination where the pod is simply stopped.

Full explanation →

343

MCQhard

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

A.Add the label 'version: canary' to the canary Deployment's pod template and update the Service's selector to 'app: web, version in (stable, canary)'.

B.Use kubectl rollout canary on the stable Deployment.

C.Create a new Service with selector 'app: web, version: canary' and use an ingress to split traffic.

D.Change the Service selector to 'app: web' only (remove version label).

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

344

MCQhard

You are deploying a stateful application as a StatefulSet named 'db' with three replicas and a headless Service named 'db-headless'. The application requires each pod to have a stable network identity and its own persistent storage that survives pod rescheduling. Which combination of StatefulSet fields ensures this behavior?

A.Set serviceName to 'db-headless' and define volumeClaimTemplates so each pod gets a uniquely named PVC.

B.Set podManagementPolicy to Parallel and define volumeClaimTemplates so all pods start simultaneously with their own PVCs.

C.Set serviceName to a ClusterIP Service named 'db-svc' and define volumeClaimTemplates for per-pod storage.

D.Set serviceName to 'db-headless' and use a single shared PersistentVolumeClaim mounted by all three pods.

AnswerA

The serviceName field binds the StatefulSet to a headless Service, giving each pod a stable DNS name like db-0.db-headless. volumeClaimTemplates creates a PersistentVolumeClaim per replica, named by combining the template name with the pod name, so storage is dedicated and persists across rescheduling. Together these provide the stable identity and per-pod storage the application needs.

Why this answer

Stable identity and per-pod storage in a StatefulSet come from two fields working together. serviceName must point to a headless Service so each pod gets a predictable DNS name, and volumeClaimTemplates generates a distinct PVC per replica that is retained across rescheduling. Parallel pod management or a shared PVC do not satisfy both requirements simultaneously.

Exam trap

The trap here is assuming any Service reference works for serviceName, when StatefulSet specifically requires a headless Service to produce per-pod DNS records.

Full explanation →

345

MCQmedium

A ClusterIP Service named 'db' in namespace 'data' is not reachable from a pod in namespace 'app'. Which DNS name should the pod use to resolve the service?

A.data.db.svc.cluster.local

B.db.app.svc.cluster.local

C.db.svc.cluster.local

D.db.data.svc.cluster.local

AnswerD

This is the correct DNS name for the db Service. In Kubernetes, the fully qualified domain name for a ClusterIP Service follows the pattern <service-name>.<namespace>.svc.<cluster-domain>, so db (the Service name) comes first, followed by data (the namespace), then the svc and cluster.local suffixes. This FQDN resolves to the Service's ClusterIP and is the standard way to reach the db Service from any namespace within the cluster.

Why this answer

A pod in namespace 'app' must use the fully qualified DNS name 'db.data.svc.cluster.local' to resolve a ClusterIP Service named 'db' in namespace 'data'. Kubernetes DNS appends the service's namespace before 'svc.cluster.local', so the format is <service>.<namespace>.svc.cluster.local. This allows cross-namespace service discovery.

Exam trap

The trap here is that candidates often forget to include the service's namespace in the DNS name when accessing a service from a different namespace, mistakenly using the short form or the pod's own namespace.

How to eliminate wrong answers

Option A is wrong because it reverses the namespace and service name (data.db instead of db.data), which does not match the required DNS format. Option B is wrong because it uses the pod's own namespace 'app' instead of the service's namespace 'data', so it would only resolve if the service were in the same namespace. Option C is wrong because it omits the namespace entirely, which is only valid for services in the same namespace as the pod, not for cross-namespace access.

Full explanation →

346

MCQmedium

You want to debug a running pod by starting a temporary container that has network access to the pod's containers. Which kubectl command should you use?

A.kubectl debug -it <pod> --image=debian --target=<container>

B.kubectl attach <pod>

C.kubectl run debug --image=debian --restart=Never

D.kubectl exec -it <pod> -- /bin/bash

AnswerA

kubectl debug -it <pod> --image=debian --target=<container> creates an ephemeral container in the same pod, sharing the pod's network and storage volumes, and uses --target to attach to the process namespace of the specified existing container. This injects a fresh Debian image with debugging tools directly into the running pod's context without restarting the workload or modifying its spec.

Why this answer

`kubectl debug` creates an ephemeral container in the same pod, sharing the pod's network namespace (including localhost and the same IP address) with the target container. The `--target` flag specifies which existing container's namespaces (network, PID, etc.) the ephemeral container should join, enabling direct network debugging of that container without modifying its process.

Exam trap

The trap here is that candidates often confuse `kubectl exec` (which runs inside an existing container) with `kubectl debug` (which creates a new, separate container in the same pod), and fail to recognize that `exec` cannot add a different image or provide network isolation from the target container's process environment.

How to eliminate wrong answers

Option B is wrong because `kubectl attach` connects to an already running container's stdin/stdout/stderr; it does not create a new container and provides no network debugging capabilities beyond what the existing container offers. Option C is wrong because `kubectl run debug --image=debian --restart=Never` creates a separate standalone pod with its own network namespace, so it cannot access the target pod's network stack (e.g., localhost services). Option D is wrong because `kubectl exec -it <pod> -- /bin/bash` runs a command inside an existing container, which may lack debugging tools (like `tcpdump`, `curl`, or `netcat`) and cannot add a separate container with a different image.

Full explanation →

347

Multi-Selectmedium

Which TWO of the following are valid ways to inject configuration data into a Kubernetes Pod?

Select 2 answers

A.Mounting a ServiceAccount token as a volume.

B.Using a ConfigMap to set environment variables in the Pod spec.

C.Using a PersistentVolumeClaim to store configuration files.

D.Referencing a NetworkPolicy in the Pod spec.

E.Mounting a Secret as a volume in the Pod.

AnswersB, E

A ConfigMap is an API object purpose-built for non-confidential configuration data, and its key-value pairs can be referenced in a container's env block with configMapKeyRef. Kubernetes then translates each referenced key into an environment variable inside the container, which is a declarative and image-independent way to inject config. Because the Pod spec references the ConfigMap by name, you can change configuration without rebuilding the container image.

Why this answer

A ConfigMap is specifically designed to inject configuration data into Pods, and one of the primary methods is by setting environment variables in the Pod spec using `envFrom` or `valueFrom: configMapKeyRef`. This allows decoupling configuration from container images, enabling environment-specific settings without rebuilding images.

Exam trap

The trap here is that candidates often confuse 'injecting configuration data' with 'providing storage' or 'network policies', leading them to select PersistentVolumeClaim or NetworkPolicy as valid options, when in fact only ConfigMaps and Secrets (for sensitive data) are the native Kubernetes resources for injecting configuration into Pods.

Full explanation →

348

MCQeasy

Which command builds a Docker image from the current directory and tags it as 'myapp:v1'?

A.docker image build --name myapp:v1 .

B.docker build -t myapp:v1 .

C.docker build myapp:v1 .

D.docker tag myapp:v1 .

AnswerB

The `docker build -t myapp:v1 .` command is the correct syntax. The `-t` (or `--tag`) flag assigns the name and tag `myapp:v1` to the built image, while the `.` specifies the current directory as the build context, containing the Dockerfile and any files needed for the build. This command reads the Dockerfile from the context, builds the image, and tags it accordingly.

Why this answer

The `docker build` command with the `-t` flag (short for `--tag`) is the standard way to build an image from a Dockerfile in the current directory (`.`) and assign it a tag `myapp:v1`. The `-t` flag specifies the repository and tag in the format `name:tag`, and the `.` indicates the build context (the current directory).

Exam trap

The trap here is that candidates confuse the `docker build` syntax with `docker tag` or misplace the tag argument, thinking it can be passed as a positional parameter instead of using the `-t` flag.

How to eliminate wrong answers

Option A is wrong because `docker image build` is a valid subcommand, but the `--name` flag does not exist; the correct flag for tagging is `-t` or `--tag`. Option C is wrong because `docker build myapp:v1 .` places the tag argument in the wrong position — the tag must follow the `-t` flag, not be the first positional argument. Option D is wrong because `docker tag` is used to tag an existing image, not to build one; it requires an existing image ID or source tag as the first argument, not a build context.

Full explanation →

349

MCQmedium

You want to run a command inside an existing container 'app-container' in pod 'my-pod'. The pod has only one container. Which command enters an interactive shell?

A.kubectl exec my-pod -c app-container /bin/sh

B.kubectl exec -it my-pod -- /bin/sh

C.kubectl run -it my-pod --image=busybox

D.kubectl attach my-pod

AnswerB

kubectl exec -it my-pod -- /bin/sh attaches an interactive TTY to the pod's sole container and launches a shell, satisfying the stem's requirement to run a command inside the existing container. Omitting -c is valid because the pod has only one container, so no container name is needed.

Why this answer

The correct command is `kubectl exec -it my-pod -- /bin/sh` because it provides an interactive shell session within the only container of the pod. The `-it` flags are essential for interactive mode, allocating a pseudo-TTY and connecting stdin, while `--` delimits the command from kubectl arguments.

Exam trap

The trap here is that candidates often forget the `-it` flags for interactive sessions, or they confuse `kubectl exec` with `kubectl run` or `kubectl attach`, thinking those can also start an interactive shell in an existing container.

How to eliminate wrong answers

Option A is wrong because it omits the `-it` flags, so it runs `/bin/sh` without allocating a TTY or attaching stdin, resulting in a non-interactive session that will likely exit immediately. Option C is wrong because `kubectl run -it my-pod --image=busybox` attempts to create a new pod named 'my-pod', which will fail if the pod already exists, and it does not execute a command inside the existing container. Option D is wrong because `kubectl attach my-pod` attaches to the main process of the container (e.g., the process with PID 1), but if that process is not a shell, it will not provide an interactive shell; it only connects to the container's standard streams.

Full explanation →

350

MCQeasy

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

A.volumes: - name: secret-volume secret: secretName: db-secret

B.volumes: - name: secret-volume secretVolumeSource: secretName: db-secret

C.volumes: - name: db-secret secret: secretName: db-secret

D.volumes: - name: secret-volume secret: name: db-secret

AnswerA

The pod spec's volumes stanza declares a volume named secret-volume sourced from the Secret db-secret via the secret.secretName field. A matching volumeMount referencing that volume name then projects the Secret's keys as files into the container at /etc/secret.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

351

MCQmedium

A developer creates a Deployment with 3 replicas and a Service with `clusterIP: None`. What is the primary use case for this headless Service?

A.To assign a static IP address to the Service

B.To automatically create an Ingress resource

C.To expose the Service externally via a load balancer

D.To enable direct pod-to-pod communication without load balancing

AnswerD

A headless Service, configured with `clusterIP: None`, tells Kubernetes to omit the virtual IP and instead make DNS return individual A records (or AAAA records) for every ready pod that matches the Service's label selector. This allows clients to connect directly to a pod's IP address, bypassing the kube-proxy VIP and enabling direct pod-to-pod communication without any load balancing. It is particularly useful for stateful applications like a database cluster that requires each pod to be discovered by its unique hostname and IP.

Why this answer

A headless Service (clusterIP: None) disables the kube-proxy load balancer and DNS round-robin, returning A/AAAA records for all ready pod IPs. This allows client applications to perform direct pod-to-pod communication for stateful workloads like databases or messaging systems that require custom load balancing or leader election.

Exam trap

The trap here is that candidates confuse a headless Service with a regular ClusterIP Service, assuming it still provides load balancing or a stable virtual IP, when in fact it removes both to enable direct pod addressing.

How to eliminate wrong answers

Option A is wrong because a headless Service does not assign a static IP; it explicitly sets clusterIP to None, meaning no virtual IP is allocated. Option B is wrong because a headless Service does not automatically create an Ingress resource; Ingress requires a separate manifest and typically targets a ClusterIP or NodePort Service. Option C is wrong because a headless Service cannot be exposed externally via a load balancer; external exposure requires a Service type of LoadBalancer or NodePort, not clusterIP: None.

Full explanation →

352

MCQeasy

Which kubectl command is used to view the rollout status of a Deployment?

A.kubectl status deployment mydeployment

B.kubectl get rollout deployment mydeployment

C.kubectl describe rollout mydeployment

D.kubectl rollout status deployment mydeployment

AnswerD

This is the correct command. 'kubectl rollout status' tracks the lifecycle of a Deployment's rollout (or DaemonSet/StatefulSet) in real time, blocking until the desired number of pods are available. It prints progress messages such as 'Waiting for deployment spec update to be observed' and 'deployment "mydeployment" successfully rolled out', and its exit code indicates success or failure, making it ideal for scripted CI/CD pipelines.

Why this answer

The 'kubectl rollout status' command is specifically designed to show the status of a rollout for a Deployment, DaemonSet, or StatefulSet.

Full explanation →

353

MCQmedium

You have a LimitRange in namespace 'ns' that sets default limits.cpu to 500m and default requests.cpu to 200m. You create a pod without specifying any CPU resources. What CPU values will be applied to the container?

A.The pod will be rejected by the admission controller

B.request: 200m, limit: 500m

C.request: 0, limit: 0 (no limits enforced)

D.request: 500m, limit: 500m

AnswerB

Correct. When a container in the pod has no resources field, the LimitRange defaults apply during admission: the defaultRequest value fills the request and the default value fills the limit. The effective pod spec therefore contains request: 200m and limit: 500m, and these values are used for scheduling, QoS classification, and kubelet enforcement.

Why this answer

When a LimitRange is configured in a namespace with default CPU limits and requests, any pod created without specifying CPU resources will have those defaults injected by the admission controller. The LimitRange sets default limits.cpu to 500m and default requests.cpu to 200m, so the container will receive request: 200m and limit: 500m. This is enforced by the LimitRanger admission plugin during pod creation.

Exam trap

The trap here is that candidates often assume a pod without resource specs will be rejected or have no limits, but the LimitRange admission controller silently applies defaults, making option B correct.

How to eliminate wrong answers

Option A is wrong because the pod is not rejected; the LimitRange admission controller applies defaults rather than rejecting the pod. Option C is wrong because the LimitRange explicitly sets default values, so the container will not have zero CPU requests and limits; the defaults are applied automatically. Option D is wrong because it confuses default limits with default requests; the default request is 200m, not 500m, and the limit is 500m, not equal to the request.

Full explanation →

354

MCQmedium

You want to undo a rollout to the previous revision. Which command should you use?

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

B.kubectl rollout undo deployment/myapp

C.kubectl set image deployment/myapp app=myapp:previous

D.kubectl rollout history deployment/myapp --revision=2

AnswerB

`kubectl rollout undo deployment/myapp` is the correct way to revert a Deployment to its previous revision. It inspects the Deployment's rollout history (stored in the ReplicaSets it manages), identifies the most recent revision's pod template, and creates a new ReplicaSet with that template while scaling down the current one—effectively undoing the last change. This is a standard, safe operation that preserves rollout history and can be repeated to continue stepping backward.

Why this answer

`kubectl rollout undo deployment/myapp` reverts the deployment to the previous revision by default, using the rollout history stored in the deployment's ReplicaSet annotations. This command directly triggers a new rollout that matches the pod template of the prior revision, effectively undoing the last change.

Exam trap

The trap here is that candidates may confuse `rollout undo` with `set image` or `rollout history`, thinking they can manually revert by specifying a tag like 'previous' or by viewing history, but only `rollout undo` performs the actual rollback to a prior revision.

How to eliminate wrong answers

Option A is wrong because `kubectl delete deployment/myapp --cascade=orphan` deletes the deployment but leaves its ReplicaSets and pods orphaned, which does not undo a rollout but rather removes the deployment controller. Option C is wrong because `kubectl set image deployment/myapp app=myapp:previous` is not a valid command; the `set image` command requires an explicit image tag or digest, and `previous` is not a recognized reference—rollback is handled by `rollout undo`, not by image manipulation. Option D is wrong because `kubectl rollout history deployment/myapp --revision=2` only displays the details of revision 2 without performing any rollback action; it is a read-only command for inspection.

Full explanation →

355

MCQeasy

Which of the following best describes the purpose of an init container?

A.Init containers run in parallel with the main containers to provide auxiliary functionality

B.Init containers run to completion before the main containers start, and are used for setup tasks

C.Init containers share the same lifecycle as the main containers

D.Init containers are restarted if they exit with a non-zero exit code

AnswerB

This is the core purpose of an init container: it runs to completion before any application container in the pod is launched. Init containers are perfect for setup tasks such as database schema migrations, waiting for dependent services, or preparing configuration files. They are guaranteed to finish successfully before the pod transitions to its Running phase, making them a reliable bootstrap mechanism.

Why this answer

Init containers are specialized containers that run and complete to exit before any pod's main containers start. They are ideal for performing setup tasks such as waiting for a service to be ready, populating configuration files, or running database migrations. This ensures the main application containers start in a fully prepared environment.

Exam trap

The trap here is that candidates confuse init containers with sidecar containers, thinking they run concurrently or share the same lifecycle, when in fact init containers run to completion before any main containers start and are not part of the main container's runtime.

How to eliminate wrong answers

Option A is wrong because init containers run sequentially, not in parallel with main containers, and they complete before main containers start. Option C is wrong because init containers have a separate lifecycle: they run to completion and are not restarted unless the pod is recreated, while main containers run continuously. Option D is wrong because init containers are restarted if they exit with a non-zero exit code only if the restart policy is set to Always or OnFailure; with the default restart policy (Always), they are restarted regardless of exit code, but the key point is that they are restarted until they succeed, not that they are restarted only on non-zero exit.

Full explanation →

356

MCQmedium

You need to ensure that a Pod always runs on a node with an SSD. Which node selector mechanism should you use?

A.Tolerations

B.Pod affinity

C.nodeName

D.nodeSelector with a label matching nodes with SSD

AnswerD

This is the correct approach. By labeling nodes that have SSDs (e.g., disktype=ssd), you can set pod.spec.nodeSelector to {disktype: ssd}, which directs the scheduler to place the pod only on nodes carrying that label. This is a simple, declarative, and supported mechanism for node-level constraints based on node labels. It works even across multiple nodes and integrates with the scheduler's filtering phase, ensuring the pod runs on an SSD-equipped node as requested.

Why this answer

`nodeSelector` is the simplest and most direct mechanism for scheduling a Pod onto nodes that possess a specific label, such as `ssd=true`. By labeling nodes that have SSDs and adding the corresponding `nodeSelector` in the Pod spec, Kubernetes ensures the Pod is only scheduled on those nodes. This approach is declarative, requires no additional controllers, and is the recommended method for simple node-level constraints.

Exam trap

The trap here is that candidates often confuse tolerations with node selection, mistakenly thinking tolerations can actively choose nodes, when in fact tolerations only permit scheduling on tainted nodes and do not enforce placement on nodes with specific hardware labels.

How to eliminate wrong answers

Option A is wrong because tolerations are used to allow Pods to schedule onto nodes that have taints, not to select nodes based on labels or hardware attributes; they enable scheduling on tainted nodes but do not actively select nodes with SSDs. Option B is wrong because Pod affinity is designed to co-locate Pods relative to other Pods (e.g., schedule near a database Pod), not to match node-level hardware characteristics like SSD presence. Option C is wrong because `nodeName` bypasses the scheduler entirely and directly assigns the Pod to a specific node by name, which is inflexible, does not use labels, and cannot dynamically select nodes based on attributes like SSD availability.

Full explanation →

357

MCQmedium

You need to debug a Pod that is in CrashLoopBackOff. Which command should you run first?

A.kubectl get events --sort-by=.lastTimestamp

B.kubectl logs <pod-name>

C.kubectl exec -it <pod-name> -- sh

D.kubectl describe pod <pod-name>

AnswerB

kubectl logs <pod-name> streams the container's stdout and stderr, which is exactly where a crashing application typically writes the error or stack trace before exiting. Because CrashLoopBackOff means the process starts, fails, and restarts, the logs usually contain the root cause, such as a missing dependency or a failed readiness check. If the container has already restarted, you must add --previous to retrieve the crashed instance's output, making this the first, most direct diagnostic step.

Why this answer

When a Pod is in CrashLoopBackOff, the immediate priority is to see why the container is failing. `kubectl logs <pod-name>` retrieves the container's stdout/stderr output, which typically contains the error message (e.g., missing config, runtime exception, or startup failure). This is the fastest way to get the root cause without modifying the Pod state.

Exam trap

CNCF often tests the misconception that `kubectl describe pod` provides enough debugging information, but it only shows the exit code and a brief termination message, not the full application logs that reveal the actual error.

How to eliminate wrong answers

Option A is wrong because `kubectl get events --sort-by=.lastTimestamp` shows cluster-level events (e.g., scheduling, pulling images) but does not show the container's application logs, which are essential for debugging a crash loop. Option C is wrong because `kubectl exec -it <pod-name> -- sh` attempts to start an interactive shell inside a running container, but if the Pod is in CrashLoopBackOff, the container is not running, so exec will fail with an error like 'error: unable to upgrade connection: container not found'. Option D is wrong because `kubectl describe pod <pod-name>` provides metadata, status, and events, but it does not include the container's stdout/stderr logs; it only shows the last termination state and exit code, which is less detailed than the actual logs.

Full explanation →

358

MCQeasy

Which command creates a generic secret named 'db-secret' with key 'password' and value 'p@ss'?

A.kubectl create secret generic db-secret --from-file=password=p@ss

B.kubectl create secret generic db-secret --from-literal=password=p@ss

C.kubectl create secret tls db-secret --from-literal=password=p@ss

D.kubectl create secret docker-registry db-secret --from-literal=password=p@ss

AnswerB

This is the correct syntax for creating an Opaque secret named db-secret with a literal key-value pair. The --from-literal flag takes 'key=value' directly from the command line and stores it as the secret data. Since 'generic' is the default and only type that accepts arbitrary literals, this matches the requirement for storing a database password. The resulting secret will have type 'Opaque' and contain password: p@ss.

Why this answer

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

Exam trap

The trap here is that candidates often confuse `--from-file` with `--from-literal`, mistakenly thinking `--from-file=key=value` will treat the value as a literal string, when in fact it treats it as a file path.

How to eliminate wrong answers

Option A is wrong because `--from-file=password=p@ss` treats 'p@ss' as a filename, not a literal value; it would attempt to read a file named 'p@ss' and store its contents under the key 'password', which is not the intended behavior. Option C is wrong because `kubectl create secret tls` is used specifically for TLS certificates and keys, not for arbitrary key-value pairs; it expects `--cert` and `--key` flags, not `--from-literal`. Option D is wrong because `kubectl create secret docker-registry` is used for Docker registry authentication credentials and requires flags like `--docker-username`, `--docker-password`, and `--docker-email`; `--from-literal` is not supported for this secret type.

Full explanation →

359

MCQmedium

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

A.The IP of the first pod only

B.The cluster IP of the Service

C.All three pod IPs as separate A records

D.A round-robin list of pod IPs

AnswerC

A headless Service has no cluster IP, so DNS returns the pod IPs directly. With the default ClusterIP setting, the lookup yields three separate A records, one per selected pod, satisfying the requirement to discover all database pod IPs.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

360

MCQmedium

You need to view events for a specific pod named 'web-1' in the 'default' namespace. Which command shows events related to this pod?

A.kubectl get events

B.kubectl describe pod web-1 --events

C.kubectl get events --field-selector involvedObject.name=web-1

D.kubectl get events --selector name=web-1

AnswerC

This command correctly narrows the event stream by using the field selector `involvedObject.name=web-1`, which matches the `involvedObject` metadata that every event carries about the resource it references. Field selectors operate on object fields, not labels, so this targets events whose involved object has exactly the name `web-1`. Since pod names are unique within a namespace, this returns all events for that pod, and you can further scope it with `--namespace` or `involvedObject.kind=Pod` if needed.

Why this answer

`kubectl get events --field-selector involvedObject.name=web-1` filters events by the `involvedObject.name` field, which directly matches the pod name. This is the precise way to retrieve only events related to a specific pod in Kubernetes, as events are associated with objects via the `involvedObject` field, not labels.

Exam trap

The trap here is that candidates confuse label selectors (`--selector`) with field selectors (`--field-selector`), assuming pod names are labels, when in fact events use the `involvedObject` field for association, not metadata labels.

How to eliminate wrong answers

Option A is wrong because `kubectl get events` returns all events in the namespace without any filtering, which is too broad and not specific to the pod 'web-1'. Option B is wrong because `kubectl describe pod web-1 --events` is not a valid command; the `--events` flag does not exist for `kubectl describe`, and even if it did, `describe` shows pod details but not a filtered list of events. Option D is wrong because `--selector name=web-1` uses label selectors, but events are not labeled with the pod's name; the pod name is stored in the `involvedObject.name` field, not as a label, so this selector would return no events or incorrect ones.

Full explanation →

361

Matchingmedium

Match each Kubernetes concept to its definition.

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

Concepts

Matches

Virtual cluster for resource isolation

Runs one pod per node for system services

Runs a pod to completion; for batch processing

Automatically scales pods based on CPU/memory

Controls traffic flow between pods

Why these pairings

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

Full explanation →

362

MCQeasy

A developer needs to run a one-time batch job to process data. After completion, the pod should be retained for logs inspection. Which Job configuration parameter should be set?

A.backoffLimit: 0

B.Leave ttlSecondsAfterFinished unset

C.ttlSecondsAfterFinished: -1

D.activeDeadlineSeconds: 3600

AnswerB

Leaving ttlSecondsAfterFinished unset is the correct way to ensure the Job and its Pods remain after completion. By default, the Kubernetes Job controller does not automatically delete finished Pods or the Job object; they stay in the cluster indefinitely until a human or an automated process removes them. This gives the developer time to inspect the Pod's logs, output files, or status, which is exactly what is needed for a one-time batch job.

Why this answer

To retain a Job's Pod after completion for log inspection, the `ttlSecondsAfterFinished` field must be left unset (or set to nil). When this field is unset, the Job controller does not automatically delete the Pod, allowing logs to be inspected. Setting it to any non-negative integer would schedule automatic deletion after that many seconds, which contradicts the requirement.

Exam trap

CNCF often tests the misconception that `ttlSecondsAfterFinished` must be set to a positive value to retain Pods, when in fact leaving it unset (nil) achieves indefinite retention, while setting it to any non-negative integer triggers automatic deletion.

How to eliminate wrong answers

Option A is wrong because `backoffLimit: 0` prevents the Job from retrying on failure, but does not affect Pod retention after completion; the Pod would still be deleted if `ttlSecondsAfterFinished` is set. Option C is wrong because `ttlSecondsAfterFinished: -1` is an invalid value; the field expects a non-negative integer or nil, and setting it to -1 would cause the Job to be rejected or ignored. Option D is wrong because `activeDeadlineSeconds: 3600` sets a maximum duration for the Job to run, after which it is terminated, but does not control Pod retention after completion; the Pod would still be deleted according to `ttlSecondsAfterFinished`.

Full explanation →

363

MCQeasy

A container in your pod takes a long time to start (up to 5 minutes). You want to avoid the container being restarted by the liveness probe during this period. What should you configure?

A.Set a long 'initialDelaySeconds' on the liveness probe

B.Add a readiness probe

C.Increase the failureThreshold on the liveness probe

D.Add a startup probe with a longer failure threshold

AnswerD

A startup probe is designed exactly for this scenario: it runs until it succeeds, and while it is active, the kubelet disables liveness and readiness probes. Configure failureThreshold high enough (e.g., 30) with a short periodSeconds, so the total startup allowance is failureThreshold * periodSeconds; once the startup probe succeeds, liveness and readiness probes resume normal operation. This cleanly decouples startup duration from liveness/readiness tuning and prevents restarts during slow initialization.

Why this answer

A startup probe is designed specifically for slow-starting containers. It runs at initialization and defers the liveness and readiness probes until it succeeds. By setting a high `failureThreshold` (e.g., 30) with a short `periodSeconds` (e.g., 10s), you allow up to 5 minutes for the container to start without the liveness probe killing it.

Exam trap

The trap here is that candidates confuse `initialDelaySeconds` (a static delay) with the startup probe (a dynamic, failure-tolerant mechanism), leading them to pick option A, which does not handle variable or long startup times reliably.

How to eliminate wrong answers

Option A is wrong because `initialDelaySeconds` only delays the start of the liveness probe by a fixed time, but if the container takes up to 5 minutes and the probe starts after that delay, it may still fail and restart the container before startup completes. Option B is wrong because a readiness probe controls traffic routing, not container restarts; it does not prevent the liveness probe from restarting the container during startup. Option C is wrong because increasing `failureThreshold` on the liveness probe only increases the number of consecutive failures allowed after the probe has started, but it does not prevent the probe from starting too early and potentially restarting the container before it is ready.

Full explanation →

364

MCQeasy

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

A.It limits the number of layers in the final image

B.It excludes files and directories from being sent to the Docker daemon during the build

C.It defines environment variables for the container

D.It specifies the order of layers in the Docker image

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

365

Multi-Selecteasy

Which TWO of the following are required for Ingress to route HTTP traffic to a backend Service?

Select 2 answers

A.Pod readiness probes

B.An Ingress controller deployed in the cluster

C.A Service of type LoadBalancer

D.A Service (any type) that matches the Ingress backend

E.A TLS certificate for HTTPS

AnswersB, D

An Ingress controller is the actual reverse proxy that watches Ingress resources and implements the rules (e.g., mapping hosts/paths to Services). Without a controller running, the Ingress resource is inert and no traffic is routed, even if the resource exists and references valid Services. Common controllers include NGINX, Traefik, and Contour; they are essential for Ingress to function.

Why this answer

An Ingress controller is required because the Ingress resource itself is just a set of routing rules; it does not process traffic. The Ingress controller, typically a pod running a reverse proxy like nginx or Envoy, watches the Ingress API and configures itself to route external HTTP/HTTPS traffic to the appropriate backend Services. Without a running Ingress controller, the Ingress resource has no effect.

Exam trap

CNCF often tests the misconception that an Ingress resource alone can route traffic without a controller, or that a LoadBalancer Service is mandatory for Ingress to work, when in fact the controller handles external exposure and any Service type suffices for the backend.

Full explanation →

366

MCQmedium

You create a Role named 'pod-reader' in the 'default' namespace with rules to get, list, and watch pods. A ServiceAccount 'app-sa' in the same namespace needs to be bound to this role. Which YAML snippet correctly creates the RoleBinding?

A.kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io

B.kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa apiGroup: '' roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

C.kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa roleRef: kind: ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io

D.kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods subjects: - kind: ServiceAccount name: app-sa namespace: default roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io

AnswerB

This manifest is correct because it binds the ServiceAccount 'app-sa' to the namespaced Role 'pod-reader' in the default namespace. The roleRef uses kind: Role with the matching apiGroup rbac.authorization.k8s.io, and the subject explicitly sets apiGroup: '' to indicate a core ServiceAccount. This grants the ServiceAccount the permissions of the Role only within its namespace, exactly as intended.

Why this answer

It creates a RoleBinding in the 'default' namespace that binds the ServiceAccount 'app-sa' to the Role 'pod-reader' using the correct 'kind: Role' in the roleRef. The RoleBinding must reference a Role (not a ClusterRole) when the Role exists in the same namespace, and the apiGroup for the roleRef must be 'rbac.authorization.k8s.io'.

Exam trap

CNCF often tests the distinction between Role and ClusterRole in the roleRef of a RoleBinding, where candidates mistakenly use 'kind: ClusterRole' when the actual resource is a namespaced Role, or use 'kind: ClusterRoleBinding' for a namespaced binding.

How to eliminate wrong answers

Option A is wrong because the roleRef uses 'kind: ClusterRole' instead of 'kind: Role', but the Role 'pod-reader' is a namespaced Role, not a ClusterRole. Option C is wrong for the same reason as A: it incorrectly references a ClusterRole instead of a Role. Option D is wrong because it uses 'kind: ClusterRoleBinding' which is cluster-scoped and cannot bind a namespaced Role; also, a ClusterRoleBinding requires a ClusterRole, not a Role.

Full explanation →

367

MCQmedium

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

A.kubectl create pod debug --image=busybox --attach

B.kubectl exec -it <pod> -- /bin/sh

C.kubectl debug <pod> --image=busybox --stdin --tty

D.kubectl run debug --image=busybox --attach

AnswerC

The debug subcommand injects an ephemeral container into the existing pod's namespaces, using the busybox image to supply a shell. This works when the original container lacks a shell, satisfying the debugging requirement without restarting the pod.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

368

MCQhard

An administrator wants to enforce that all pods in namespace 'secured' must run with a seccomp profile set to 'RuntimeDefault' at the container level. Which Pod Security Admission policy standard achieves this?

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

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

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

D.Set the namespace label 'pod-security.kubernetes.io/enforce=seccomp'

AnswerC

The restricted Pod Security Standard is the most stringent preset, and its policy explicitly requires every container to define a seccompProfile of either RuntimeDefault or Localhost. Setting the namespace label to restricted forces the Pod Security admission controller to reject any pod or update that lacks a compliant seccomp profile. This is precisely what the administrator needs, as it enforces seccomp at the namespace level and aligns with the recommended default for production workloads.

Why this answer

The 'restricted' Pod Security Admission (PSA) policy standard enforces the most stringent security controls, including requiring that pods use a seccomp profile set to 'RuntimeDefault' at the container level. This is defined in the Kubernetes Pod Security Standards documentation, where the restricted profile mandates 'seccomp: RuntimeDefault' as a baseline requirement. Therefore, option C is correct because it directly matches the policy that enforces this specific seccomp constraint.

Exam trap

The trap here is that candidates often confuse the 'baseline' standard with 'restricted', assuming baseline covers seccomp requirements, but baseline only addresses basic privilege escalation and does not mandate a specific seccomp profile.

How to eliminate wrong answers

Option A is wrong because the 'privileged' PSA standard imposes no restrictions on seccomp profiles, allowing any profile or no profile at all. Option B is wrong because the 'baseline' PSA standard only prevents known privilege escalations but does not mandate a specific seccomp profile like 'RuntimeDefault'. Option D is wrong because 'pod-security.kubernetes.io/enforce=seccomp' is not a valid PSA standard; the valid standards are 'privileged', 'baseline', and 'restricted', and seccomp is a control within the restricted standard, not a standalone policy level.

Full explanation →

369

MCQeasy

You need to view the logs of the previous (terminated) instance of a container in a pod. Which command should you use?

A.kubectl describe pod pod-name | grep -A 10 'Last State'

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

C.kubectl logs pod-name -p

D.kubectl logs pod-name -f

AnswerC

The -p (or --previous) flag is the correct way to retrieve logs from the previous container instance, as it explicitly instructs kubectl to read from the retained log buffer of the last terminated container. This is the standard diagnostic step when a container is in CrashLoopBackOff, and it works because the kubelet preserves the terminated container's logs until the pod is deleted; note that if no previous instance exists, this command returns an error.

Why this answer

`kubectl logs pod-name -p` (or `--previous`) retrieves the logs from the previous terminated container instance in the pod. This flag specifically targets the last container that exited, allowing you to debug crashes or restarts without needing to access the current running container.

Exam trap

The CKAD exam often tests the distinction between `kubectl logs` with `-p` (previous) and `kubectl describe pod` (which shows state but not logs), leading candidates to mistakenly choose `describe` when they need actual log output.

How to eliminate wrong answers

Option A is wrong because `kubectl describe pod` shows the pod's metadata and last state details (e.g., exit code, reason), but it does not display the actual container logs — it only shows a summary of the termination state, not the log output. Option B is wrong because `kubectl logs pod-name --tail=100` fetches the last 100 lines from the current running container, not from a terminated instance; it has no mechanism to access previous container logs. Option D is wrong because `kubectl logs pod-name -f` streams logs from the current container in real time (follow mode), which is irrelevant for viewing logs of a terminated container.

Full explanation →

370

MCQmedium

You have a Service named 'myservice' in namespace 'default'. A pod in the same cluster but different namespace 'other' wants to resolve the service's IP. What DNS name should it use?

A.myservice.default.svc.cluster.local

B.default.myservice.svc.cluster.local

C.myservice.svc.cluster.local

D.myservice.other.svc.cluster.local

AnswerA

This is the correct fully qualified domain name (FQDN) for the service. The Kubernetes DNS naming convention is <service-name>.<namespace>.svc.cluster.local, so 'myservice' in namespace 'default' maps to this exact string. Because it includes the namespace 'default', the name resolves from any namespace in the cluster, making it suitable for cross-namespace access.

Why this answer

Kubernetes DNS resolves services using the format `<service>.<namespace>.svc.cluster.local`. Since the service 'myservice' is in the 'default' namespace, a pod in the 'other' namespace must include the namespace in the DNS name to reach it. This fully qualified domain name (FQDN) ensures the DNS query resolves to the service's cluster IP, regardless of the pod's namespace.

Exam trap

The trap here is that candidates often forget to include the namespace when the pod is in a different namespace, or they mistakenly swap the order of service and namespace, leading them to choose option B or C.

How to eliminate wrong answers

Option B is wrong because it reverses the order of service and namespace (namespace.service instead of service.namespace), which does not match the Kubernetes DNS naming convention. Option C is wrong because it omits the namespace, so it would only work if the pod were in the same namespace as the service; a pod in a different namespace cannot resolve it without the namespace qualifier. Option D is wrong because it uses the pod's own namespace 'other' instead of the service's namespace 'default', which would not resolve to the correct service.

Full explanation →

371

MCQhard

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

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

B.kubectl attach pod-name

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

372

Multi-Selecthard

Which THREE are valid ways to expose a Service externally in Kubernetes?

Select 3 answers

A.Headless service

B.Type: NodePort

C.Type: LoadBalancer

D.Ingress resource

E.Type: ClusterIP

AnswersB, C, D

A Service of type NodePort allocates a static port (default range 30000-32767) and listens on that port on every node in the cluster. External clients can reach the Service by connecting to any node's IP at that port, and kube-proxy forwards traffic to the backing pods. This works in any environment without a cloud provider, but it requires opening node ports and exposes the node's IP rather than a dedicated external endpoint.

Why this answer

(Type: NodePort) is correct because it exposes a Service on a static port on each Node's IP address, allowing external traffic to reach the Service by targeting <NodeIP>:<NodePort>. Option C (Type: LoadBalancer) is correct because it provisions an external load balancer in cloud environments that directs traffic to the Service. Option D (Ingress resource) is correct because it provides HTTP/HTTPS routing to Services, often using a load balancer or other entry point.

Option A (Headless service) is incorrect because it is used for service discovery without a cluster IP and does not provide external access. Option E (Type: ClusterIP) is incorrect because ClusterIP is internal-only and not exposed externally.

Exam trap

A common mistake is assuming ClusterIP or Headless Services provide external access. ClusterIP is internal-only, and Headless Services are for service discovery without load balancing, not external exposure.

Full explanation →

373

MCQmedium

A CronJob has concurrencyPolicy set to 'Forbid'. At the scheduled time, if the previous job is still running, what happens?

A.The new job is delayed until the previous job completes

B.The new job is skipped (does not run)

C.Both jobs run concurrently

D.The previous job is terminated and the new job starts

AnswerB

With concurrencyPolicy: Forbid, the CronJob controller checks for any active Jobs from the same CronJob at the scheduled start time. If one exists, the controller deliberately does not create the new Job, and the scheduled invocation is skipped entirely without being queued or retried. The CronJob can then run again only at its next configured schedule, assuming no overlapping Job is still active.

Why this answer

When a CronJob has `concurrencyPolicy: Forbid`, Kubernetes ensures that if a previous job instance is still running at the next scheduled time, the new job is simply skipped (does not run). This prevents overlapping executions, which is critical for workloads that must not run concurrently, such as database migrations or batch processing that would cause data corruption.

Exam trap

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

How to eliminate wrong answers

Option A is wrong because 'Forbid' does not delay the new job; it skips it entirely, unlike `concurrencyPolicy: Allow` which would queue or run concurrently. Option C is wrong because 'Forbid' explicitly prevents concurrent runs, which is the opposite of running both jobs concurrently. Option D is wrong because 'Forbid' does not terminate the previous job; termination would require a custom controller or manual intervention, and Kubernetes CronJobs do not automatically kill running jobs when a new one is skipped.

Full explanation →

374

MCQmedium

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

A.kubectl create secret generic regcred --type=kubernetes.io/dockercfg --from-literal=.dockercfg=...

B.kubectl create secret generic regcred --from-file=.dockerconfigjson=/root/.docker/config.json

C.kubectl create secret tls regcred --cert=cert.crt --key=key.key

D.kubectl create secret docker-registry regcred --docker-server=my-registry.example.com --docker-username=myuser --docker-password=mypassword --docker-email=myemail@example.com

AnswerD

The docker-registry subcommand builds a Secret of type kubernetes.io/dockerconfigjson from the supplied server, username, password and email flags, generating the required .dockerconfigjson key automatically. Manual base64 encoding or generic Secret creation would not satisfy the registry's expected type.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

375

MCQmedium

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

A.Allow

B.Replace

C.Forbid

D.Ignore

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

Certified Kubernetes Application Developer CKAD (CKAD) — Questions 301–375