CKAD Practice Exam 51 — 20 Questions

Question 1

You deploy a pod with resource requests: cpu: 500m, memory: 256Mi and limits: cpu: 1, memory: 512Mi. The container tries to allocate 600Mi of memory. What happens?

Accepted Answer

The container is OOMKilled because it exceeds the memory limit. The container's memory allocation of 600Mi exceeds its configured memory limit of 512Mi. Kubernetes enforces memory limits using the cgroup memory controller; when a container attempts to allocate more memory than its limit, the kernel's Out-Of-Memory (OOM) killer terminates the container process. This results in the container being OOMKilled, as recorded in the pod status.

Answer

The container runs normally, but memory usage is throttled

Answer

The container runs normally because requests are the only constraints

Answer

The container is evicted from the node

Question 2

You need to debug a pod that has no shell installed. You want to add a temporary container with debugging tools to the pod. Which command should you use?

Accepted Answer

kubectl debug mypod -it --image=busybox -- /bin/sh. `kubectl debug mypod -it --image=busybox -- /bin/sh` creates an ephemeral container in the existing pod `mypod`, attaching it interactively with a shell. This allows you to debug a pod that lacks a shell or debugging tools without modifying the original container's image or restarting the pod.

Answer

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

Answer

kubectl debug mypod --image=busybox --target=debug -n default

Answer

kubectl exec -it mypod -- /bin/sh

Question 3

Which TWO statements about Kustomize are true?

Accepted Answer

Kustomize supports overlays that allow different configurations for different environments.. Kustomize supports overlays, which are layered patches applied on top of a base configuration. This allows you to define a common base set of Kubernetes resources and then use different overlay directories (e.g., dev, staging, prod) to customize settings like replicas, image tags, or namespaces for each environment without duplicating the entire manifest.

Answer

Kustomize can be used to perform canary deployments.

Answer

Kustomize requires Helm to manage dependencies.

Answer

Kustomize can only be used with kubectl apply -k.

Question 4

A Pod is stuck in CrashLoopBackOff. You run 'kubectl logs mypod' and get no output. What is the most likely cause?

Accepted Answer

The application crashes before writing any logs.. When a Pod is in CrashLoopBackOff and `kubectl logs mypod` returns no output, the most likely cause is that the application crashes before it can write any logs to stdout/stderr. The container starts, runs briefly, and exits before the logging framework initializes, so no log data is captured by the container runtime.

Answer

The Pod is not ready yet.

Answer

The liveness probe is failing.

Answer

The container never started due to a missing image.

Question 5

You apply a Pod Security Admission label 'pod-security.kubernetes.io/enforce: restricted' to a namespace. A pod with the following securityContext is created:
securityContext:
  runAsUser: 1000
  runAsNonRoot: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
Will the pod be admitted?

Accepted Answer

Yes, the pod satisfies all restricted profile requirements. The Pod Security Admission (PSA) restricted profile requires that pods drop all capabilities, set `runAsNonRoot: true`, set `seccompProfile.type` to `RuntimeDefault` or `Localhost`, set `allowPrivilegeEscalation: false`, and restrict `runAsUser` to a non-root user (which is satisfied by `runAsUser: 1000`). The provided pod meets all these requirements, so it will be admitted. The `runAsUser` field is allowed as long as the user ID is not 0 (root), and the `seccompProfile.type` is correctly set to `RuntimeDefault`, which is one of the permitted values.

Answer

No, because runAsUser must not be set

Answer

No, because seccompProfile type must be 'Localhost'

Answer

No, because the pod must not set capabilities at all

Question 6

A deployment runs a container that needs to read a file from a host path '/var/log/app' on the node. The file must be available to all pods on that node. Which volume type should be used?

Accepted Answer

hostPath. B is correct because hostPath mounts a file or directory from the host node's filesystem into the pod, making it available to all pods scheduled on that node. This is the only volume type that directly accesses a specific host path like '/var/log/app', ensuring the file is shared across all pods on the same node.

Answer

emptyDir

Answer

persistentVolumeClaim

Answer

configMap

Question 7

Which TWO items are required for Ingress to work correctly in a Kubernetes cluster?

Accepted Answer

At least one rule specifying either host or path. For Ingress to work correctly, the cluster must have a running Ingress controller to process Ingress resources. At least one rule specifying a host or path is required to define routing logic. A TLS secret is optional for HTTPS termination, not mandatory. Without these two components, the Ingress will not route traffic.

Answer

A TLS secret for HTTPS termination

Answer

A LoadBalancer service for the backend

Answer

A default backend service

Question 8

You have a Deployment that uses the 'Recreate' strategy. What happens when you update the pod template (e.g., change the image)?

Accepted Answer

All existing pods are terminated before new pods are created. The 'Recreate' strategy in a Kubernetes Deployment terminates all existing pods before creating new ones when the pod template is updated. This ensures zero overlapping pods during the update, which is useful for applications that cannot handle multiple versions running simultaneously.

Answer

The update is not allowed; you must delete the Deployment first

Answer

New pods are created gradually while old pods are terminated

Answer

Pods are updated in-place without restart

Question 9

Based on the exhibit, what should you do to determine why the container is failing?

Accepted Answer

Run 'kubectl logs backend' to view the container's stdout/stderr.. The container is failing, and the most direct way to determine why is to inspect its stdout/stderr logs using 'kubectl logs backend'. This command retrieves the container's log output, which typically contains error messages, stack traces, or application-level failure reasons. In CKAD scenarios, when a pod is in CrashLoopBackOff or Error state, logs are the first diagnostic step to identify the root cause.

Answer

Run 'kubectl describe pod backend' to see the pod's status.

Answer

Run 'kubectl get events' with a different filter to capture more details.

Answer

Check if the image tag '1.0' exists in the registry.

Question 10

You have a multi-stage Dockerfile. The first stage builds a binary using a large build image. The second stage copies the binary from the first stage into a minimal runtime image. Which Dockerfile instruction is used to copy artifacts from a previous stage?

Accepted Answer

COPY --from=builder /app/artifact /app/. In multi-stage Docker builds, the COPY instruction with the --from flag allows you to copy files from a named previous stage (e.g., 'builder') into the current stage. This is the standard Docker mechanism for selectively transferring build artifacts while discarding intermediate build dependencies, enabling a smaller final image.

Answer

ADD --from=builder /app/artifact /app/

Answer

ENTRYPOINT --from=builder /app/artifact /app/

Answer

CMD --from=builder /app/artifact /app/

Question 11

A developer runs 'kubectl run nginx --image=nginx --port=80' and then creates a Service with the following YAML:

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

However, the Service has no endpoints. What is the most likely cause?

Accepted Answer

The Service selector 'app: nginx' does not match the pod's label 'run: nginx'. The `kubectl run nginx --image=nginx --port=80` command creates a pod with a default label `run: nginx`, not `app: nginx`. The Service's selector `app: nginx` therefore does not match any pod's labels, so the Service's endpoint controller finds no pods to add to the endpoints list. Without matching labels, the Service cannot route traffic to any pod, resulting in zero endpoints.

Answer

The Service and pod are in different namespaces

Answer

The Service must have a selector defined in order to have endpoints

Answer

The pod is not listening on port 80

Question 12

An Ingress is configured for host-based routing with two hosts: 'app1.example.com' and 'app2.example.com'. A request to 'app1.example.com' should go to service 'svc1'. Which field in the Ingress spec specifies the host?

Accepted Answer

spec.rules.host. In Kubernetes Ingress, host-based routing is configured by specifying the `host` field directly under `spec.rules`. Each rule can define a `host` (e.g., `app1.example.com`) and the corresponding backend service. Option D correctly identifies `spec.rules.host` as the field that specifies the host for routing traffic to the appropriate service.

Answer

spec.rules.http.paths.host

Answer

spec.rules.http.host

Answer

spec.tls.hosts

Question 13

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?

Accepted Answer

The file /tmp/healthy does not exist or is not being updated by the application. 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.

Answer

The readiness probe is misconfigured and is shutting down the pod

Answer

The liveness probe is using the wrong HTTP endpoint

Answer

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

Question 14

A pod has securityContext with capabilities.add: ['NET_ADMIN'] and capabilities.drop: ['ALL']. What effective capabilities does the container have?

Accepted Answer

Only NET_ADMIN. When a container's securityContext specifies both `capabilities.drop: ['ALL']` and `capabilities.add: ['NET_ADMIN']`, the `drop: ['ALL']` first removes all capabilities, and then `add: ['NET_ADMIN']` adds back only the NET_ADMIN capability. The final effective set is exactly `[NET_ADMIN]`. This is the intended Kubernetes behavior: `drop` is processed before `add` within the same container spec.

Answer

No capabilities

Answer

All capabilities

Answer

All capabilities except NET_ADMIN

Question 15

You want to view the events related to a specific pod named 'my-pod' in the 'default' namespace. Which command filters events to show only those pertaining to this pod?

Accepted Answer

kubectl get events --field-selector involvedObject.name=my-pod. `kubectl get events --field-selector involvedObject.name=my-pod` uses a field selector to filter events by the `involvedObject.name` field, which directly matches the pod's name. This approach is precise and avoids parsing unstructured output, ensuring only events related to that specific pod are returned.

Answer

kubectl describe pod my-pod

Answer

kubectl get events | grep my-pod

Answer

kubectl logs my-pod

Question 16

A developer deploys a set of Pods labeled app=frontend and wants to expose them internally within the cluster on a stable IP. Which resource should be used?

Accepted Answer

Service of type ClusterIP. A Service of type ClusterIP exposes the Pods on a stable internal IP address that is only reachable within the cluster. This is the default Service type and is ideal for internal communication between components, such as a frontend being accessed by a backend, without exposing the service outside the cluster.

Answer

Service of type NodePort

Answer

Service of type LoadBalancer

Answer

Ingress resource

Question 17

Which TWO of the following commands can be used to view events related to a specific pod? (Select TWO.)

Accepted Answer

kubectl get events --field-selector involvedObject.name=. `kubectl get events --field-selector involvedObject.name=` filters events by the `involvedObject.name` field, which directly corresponds to the pod's name. This command retrieves all events where the pod is the involved object, such as scheduling, pulling images, or container restarts. Option C is correct because `kubectl describe pod ` includes a dedicated 'Events' section at the bottom of its output, showing recent events for that specific pod in chronological order.

Answer

kubectl events --pod=<pod>

Answer

kubectl logs <pod>

Answer

kubectl get events

Question 18

You have a headless Service for a StatefulSet. What is the DNS resolution behavior for the StatefulSet pods?

Accepted Answer

Each pod gets a DNS A record pointing to its individual IP.. For a headless Service (clusterIP: None) associated with a StatefulSet, DNS resolution returns individual A records for each pod, mapping the pod's hostname (e.g., pod-name.service-name.namespace.svc.cluster.local) to its unique pod IP. This is because headless Services disable load-balanced cluster IPs and instead rely on DNS to provide direct pod-to-pod connectivity, which is essential for StatefulSet workloads like databases that require stable network identities.

Answer

DNS is disabled for headless Services.

Answer

The Service name resolves to the IP of the first pod only.

Answer

All pods share a single cluster IP via the Service.

Question 19

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

Accepted Answer

To provide stable network identities and DNS records for each pod in the StatefulSet. 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`.

Answer

To prevent DNS resolution of the service

Answer

To enable TLS termination at the service level

Answer

To provide load balancing across the pods

Question 20

You run 'kubectl run nginx --image=nginx --restart=Never --dry-run=client -o yaml'. What is the output?

Accepted Answer

A Pod manifest with apiVersion: v1. The command `kubectl run nginx --image=nginx --restart=Never --dry-run=client -o yaml` creates a Pod manifest because `--restart=Never` explicitly sets the restart policy to Never, which is a Pod-level field. The `kubectl run` command without `--restart=Never` defaults to creating a Deployment, but with `--restart=Never`, it generates a standalone Pod. The output uses `apiVersion: v1`, which is the correct and stable API version for Pods.

Answer

A Pod manifest with apiVersion: v1beta1

Answer

A Job manifest with apiVersion: batch/v1

Answer

A Deployment manifest with apiVersion: apps/v1