CKAD Timed Practice Test 3 — 10 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?

10 minute time limit — choose an answer to begin.

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

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

Accepted Answer

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

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Question 9

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 10

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