CKAD Practice Questions 2 — 50 Questions

Question 1

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

Accepted Answer

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

Answer

RUN

Answer

EXPOSE

Answer

ENTRYPOINT

Question 2

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

Accepted Answer

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

Answer

Change periodSeconds to 5

Answer

Change timeoutSeconds to 30

Answer

Set initialDelaySeconds to 300

Question 3

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

Accepted Answer

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

Answer

persistentVolumeClaim

Answer

hostPath

Answer

configMap

Question 4

A Pod spec includes 'securityContext' with 'runAsUser: 1000' and 'runAsGroup: 3000'. The container process inside the pod is expected to write to a mounted volume. Which securityContext field should be set to ensure the volume's group ownership is 3000?

Accepted Answer

fsGroup: 3000. The `fsGroup` field in the Pod's `securityContext` specifies the group ID (GID) that Kubernetes should assign to any volume mounted into the Pod. When `fsGroup: 3000` is set, Kubernetes recursively changes the ownership of the volume's files and directories to group ID 3000, and any new files created by the container process will inherit that group ownership. This ensures the container process, which runs with `runAsGroup: 3000`, can write to the volume without permission errors.

Answer

supplementalGroups: [3000]

Answer

fsGroup: 1000

Answer

runAsGroup: 3000

Question 5

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

Accepted Answer

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

Answer

envFrom:
- configMapRef:
    name: app-config

Answer

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

Answer

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

Question 6

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

Accepted Answer

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

Answer

initialDelaySeconds

Answer

periodSeconds

Answer

successThreshold

Question 7

You have a pod with two containers: one runs a web server, and the other is a sidecar that logs the web server's output to a central logging system. Which pattern does this represent?

Accepted Answer

Sidecar pattern. The sidecar pattern involves deploying a helper container alongside the main application container within the same pod. In this scenario, the sidecar container consumes the web server's logs (e.g., by tailing a shared volume or reading stdout/stderr) and forwards them to a central logging system, such as Elasticsearch or Fluentd. This pattern is a core Kubernetes design principle for extending or enhancing the main container without modifying its code.

Answer

Decorator pattern

Answer

Ambassador pattern

Answer

Adapter pattern

Question 8

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

Accepted Answer

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

Answer

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

Answer

kubectl attach mypod

Answer

kubectl exec -it mypod -- /bin/sh

Question 9

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

Accepted Answer

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

Answer

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

Answer

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

Answer

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

Question 10

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?

Accepted Answer

kubectl debug -it pod-name --image=busybox --target=container-name. `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.

Answer

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

Answer

kubectl attach pod-name

Answer

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

Question 11

A Pod is running in a namespace with a ResourceQuota that sets 'limits.memory: 2Gi'. The pod's container spec has 'resources.limits.memory: 1Gi' and 'resources.requests.memory: 512Mi'. The pod is in 'Running' state but consumes 1.5Gi of memory. What happens?

Accepted Answer

The container will be OOMKilled because it exceeds its own memory limit of 1Gi. The container has a hard memory limit of 1Gi set in its resources.limits.memory. When the container's memory usage exceeds this limit (1.5Gi > 1Gi), the Linux kernel's OOM killer terminates the container process. The namespace ResourceQuota of 2Gi is not violated because the pod's limit (1Gi) is within the quota, so the kubelet does not evict the pod.

Answer

The pod will be evicted by the kubelet due to namespace quota violation

Answer

The container will continue running because the namespace quota allows up to 2Gi

Answer

The pod will be throttled by the kernel to stay within 1Gi

Question 12

An Ingress resource is created with the following YAML:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80

Which of the following requests will be routed to the api-svc Service? (Select all that apply.)

Accepted Answer

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

Answer

GET http://example.com/other

Answer

GET http://example.org/api

Answer

GET http://example.com/apix

Question 13

You are performing a canary deployment using two Deployments: 'app-stable' (replicas: 9) and 'app-canary' (replicas: 1), both with label 'app: myapp'. A Service selects pods with 'app: myapp' and 'version: stable'. How can you route traffic to the canary?

Accepted Answer

Add label 'version: stable' to the canary Deployment's pod template, so both Deployments have the same label, and keep the Service selector as is.. Adding the label 'version: stable' to the canary Deployment's pod template makes its pods match the Service's selector ('app: myapp' and 'version: stable'). This allows the Service to include both stable and canary pods, distributing traffic according to the replica ratio (9:1). The canary image can be different from stable, but the label ensures the Service routes traffic to both sets of pods.

Answer

Update the canary Deployment's image to a different version.

Answer

Change the Service's selector to 'version: canary'.

Answer

Add label 'version: canary' to the canary Deployment's template and update the Service selector to 'version: stable || version: canary'.

Question 14

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

Accepted Answer

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

Answer

The IngressClass annotation is missing

Answer

The Ingress controller is not installed

Answer

The TLS certificate is expired

Question 15

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

Accepted Answer

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

Answer

Run the script as a sidecar container that shares the volume with the main container.

Answer

Use a postStart lifecycle hook on the main container to run the script.

Answer

Add a readiness probe to the main container that checks the shared volume.

Question 16

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

Accepted Answer

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

Answer

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

Answer

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

Answer

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

Question 17

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

Accepted Answer

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

Answer

env:
- name: username
  valueFrom:
    secretKeyRef:
      name: db-creds
      key: username

Answer

envFrom:
- configMapRef:
    name: db-creds

Answer

envFrom:
- secretKeyRef:
    name: db-creds

Question 18

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

Accepted Answer

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

Answer

The ClusterIP Service type does not support load balancing.

Answer

The Service is not configured with enough endpoints.

Answer

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

Question 19

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

Accepted Answer

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

Answer

No, because runAsNonRoot requires an explicit runAsUser

Answer

No, because the container image user is unknown

Answer

Yes, because runAsNonRoot is ignored if runAsUser is not set

Question 20

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?

Accepted Answer

Allow. 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.

Answer

Replace

Answer

Forbid

Answer

Ignore