CKAD Practice Test 3 — 30 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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

Question 11

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

Accepted Answer

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

Answer

Increase the resource requests for the container

Answer

Delete the pod and recreate it with the same spec

Answer

Decrease the CPU request but keep the memory request the same

Question 12

You have a Deployment that uses a ConfigMap. You update the ConfigMap, but the pods are not picking up the changes. What is the MOST efficient way to force the pods to use the new ConfigMap values without downtime?

Accepted Answer

Run 'kubectl rollout restart deployment/deployment-name'. A is correct because `kubectl rollout restart deployment/deployment-name` triggers a new ReplicaSet and gracefully terminates old pods while creating new ones, which will mount the updated ConfigMap. This avoids downtime by leveraging the Deployment's rolling update strategy, ensuring the new pods read the current ConfigMap data from the volume mount or environment variable reference.

Answer

Delete the pods manually and let the ReplicaSet recreate them

Answer

Delete the ConfigMap and recreate it with the same name

Answer

Edit the Deployment to add an annotation, triggering a rollout

Question 13

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

Accepted Answer

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

Answer

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

Answer

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

Answer

Add a PrometheusRule resource that defines the scrape target.

Question 14

You have a Service that exposes a Deployment. Some pods are not receiving traffic. 'kubectl get endpoints my-service' shows only 2 out of 3 pod IPs. What is the most likely cause?

Accepted Answer

One pod is not ready (readiness probe failing). The most likely cause is that one pod is not ready because its readiness probe is failing. Services only forward traffic to pods that are in the Ready state, as reflected in the Endpoints object. If a pod fails its readiness probe, it is removed from the list of endpoints, even if it is running and has the correct labels.

Answer

The Deployment has a wrong targetPort

Answer

The Service type is NodePort

Answer

One pod has a different label than the Service selector

Question 15

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?

Accepted Answer

The Pod will be admitted because it respects both the ResourceQuota and the LimitRange. 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.

Answer

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

Answer

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

Answer

The Pod will be rejected because requests must equal limits

Question 16

Which Pod spec snippets correctly achieve this?

Accepted Answer

envFrom:
  - secretRef:
      name: db-secret. 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.

Answer

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

Answer

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

Question 17

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

Accepted Answer

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

Answer

The container image is not found

Answer

The pod is in CrashLoopBackOff

Answer

The pod has been evicted due to memory pressure

Question 18

A developer configures a liveness probe for a container that takes a long time to start (about 120 seconds). The probe uses httpGet on port 8080 with a path '/healthz'. The probe is configured with initialDelaySeconds=10, periodSeconds=10, failureThreshold=3. The pod enters CrashLoopBackOff. What is the MOST likely cause?

Accepted Answer

The liveness probe is failing too early because initialDelaySeconds is too low for the slow-starting container. The liveness probe is configured with initialDelaySeconds=10, which means Kubernetes will start probing 10 seconds after the container starts. Since the application takes about 120 seconds to become healthy, the probe will fail immediately. With failureThreshold=3 and periodSeconds=10, the probe will fail after 30 seconds (3 * 10s), causing Kubernetes to restart the container before it has finished initializing, leading to CrashLoopBackOff.

Answer

The failureThreshold should be increased to 10

Answer

The httpGet path '/healthz' is incorrect and should be '/ready'

Answer

The readiness probe is misconfigured and should be used instead of a liveness probe

Question 19

Which of the following is a valid schedule for a CronJob that runs every day at midnight?

Accepted Answer

0 0 * * *. A CronJob schedule uses standard cron syntax: minute, hour, day of month, month, day of week. '0 0 * * *' means minute=0, hour=0 (midnight), and the asterisks for day of month, month, and day of week match any value, so the job runs every day at midnight.

Answer

0 0 1 * *

Answer

* * * * *

Answer

0 * * * *

Question 20

Which kubectl command creates a Secret from literal username and password values?

Accepted Answer

kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secret123. `kubectl create secret generic` with `--from-literal` is the proper syntax for specifying literal key-value pairs directly in the command. Each literal must be prefixed with `--from-literal=key=value`, and multiple literals can be provided to create a Secret containing both the username and password keys.

Answer

kubectl create secret generic my-secret --literal username=admin password=secret123

Answer

kubectl create secret generic my-secret --from-file=username --from-file=password

Answer

kubectl create secret generic my-secret --from-env-file=creds.txt