CKAD Practice Test 30 — 15 Questions

Question 1

What is the purpose of the 'kubectl describe pod' command?

Accepted Answer

Display detailed information about a pod, including recent events. The 'kubectl describe pod' command retrieves detailed metadata about a specific pod, including its current state, labels, annotations, container specifications, volumes, and a chronological list of recent events (e.g., image pull failures, container restarts, scheduling decisions). This aggregated information is essential for debugging pod lifecycle issues because it surfaces both static configuration and dynamic cluster-level events that are not shown in the pod's YAML manifest or logs.

Answer

Execute a command inside a pod

Answer

Display resource usage of a pod

Answer

Show the logs of a pod

Question 2

You need to create a Job that runs a single task to completion. Which kubectl command correctly creates a Job named 'data-processor' that runs the image 'myapp/processor:1.0'?

Accepted Answer

kubectl create job data-processor --image=myapp/processor:1.0. `kubectl create job` is the dedicated command to create a Job resource, which runs a pod to completion without restarting the container after success. The Job controller ensures the pod runs exactly once, making it ideal for batch processing tasks.

Answer

kubectl create deployment data-processor --image=myapp/processor:1.0

Answer

kubectl run data-processor --image=myapp/processor:1.0 --restart=Never

Answer

kubectl create cronjob data-processor --image=myapp/processor:1.0

Question 3

You want to ensure your application shuts down gracefully when a pod is terminated. The application needs 30 seconds to clean up. Which field should you set in the pod spec?

Accepted Answer

terminationGracePeriodSeconds: 30. `terminationGracePeriodSeconds` defines the time Kubernetes waits for a pod to shut down gracefully after sending a SIGTERM signal. Setting it to 30 seconds gives the application the required cleanup window before a SIGKILL is forced.

Answer

spec.containers[].livenessProbe.initialDelaySeconds: 30

Answer

spec.containers[].lifecycle.preStop.exec.command: ["sleep", "30"]

Answer

spec.containers[].readinessProbe.periodSeconds: 30

Question 4

A Pod has two containers: one with a liveness probe that fails after 30 seconds. The restartPolicy is 'Never'. What state will the Pod be in after the liveness probe fails?

Accepted Answer

Failed. When a liveness probe fails, Kubernetes terminates the container and, because the restartPolicy is 'Never', does not restart it. The Pod transitions to the 'Failed' phase, as the container has exited with a non-zero exit code and will not be recreated. This is the expected behavior for a Pod with a single container that fails its health check under a 'Never' restart policy.

Answer

Running

Answer

Unknown

Answer

CrashLoopBackOff

Question 5

Which Service type is used to expose a service externally on a static port on each worker node?

Accepted Answer

NodePort. A NodePort service exposes the application on a static port (in the range 30000-32767) on every worker node's IP address. This allows external traffic to reach the service by targeting any node's IP and the assigned NodePort, making it the correct choice for exposing a service externally on a static port per node.

Answer

ExternalName

Answer

ClusterIP

Answer

LoadBalancer

Question 6

You are a platform engineer at a company that runs a microservices architecture on Kubernetes. The application consists of a frontend service (Node.js), a backend API (Go), and a PostgreSQL database. All components are deployed in the same namespace 'production'. Recently, the backend API has been experiencing intermittent 503 errors from the frontend. The backend API Pods have CPU limits set to 500m and memory limits to 256Mi. The backend API exposes metrics at /metrics and has a liveness probe (HTTP GET /healthz) and a readiness probe (HTTP GET /ready). You notice that during traffic spikes, the backend API Pods are restarted frequently. You examine the metrics and see that memory usage spikes to 250Mi during high load. What is the most likely cause of the restarts and 503 errors?

Accepted Answer

The memory limit is set too low; the container is being OOMKilled during traffic spikes.. The backend API Pods are being restarted frequently because the memory limit of 256Mi is too close to the observed memory usage of 250Mi during traffic spikes. When memory usage hits the limit, the Linux kernel's OOM killer terminates the container (OOMKilled), causing the Pod to restart. This restart leads to temporary unavailability, which the frontend sees as 503 errors.

Answer

The liveness probe is misconfigured and should use a TCP check instead.

Answer

The readiness probe is failing because the application is not ready, but the liveness probe keeps it alive.

Answer

The CPU limit is too low, causing the container to be throttled and timeout.

Question 7

You are debugging a pod that is running but not responding to network requests on port 8080. You suspect the application inside the container is faulty. You need to run an interactive shell inside the container to inspect the process. Which command should you use?

Accepted Answer

kubectl exec -it pod-name -- /bin/sh. `kubectl exec -it pod-name -- /bin/sh` opens an interactive shell inside the running container, allowing you to inspect processes, check network listeners, and debug the application directly. This is the standard command for gaining shell access to a container in Kubernetes.

Answer

kubectl describe pod pod-name

Answer

kubectl logs pod-name -f

Answer

kubectl debug -it pod-name --image=busybox

Question 8

A pod is running but not receiving traffic from a Service. The readiness probe is failing. What is the likely effect on the pod?

Accepted Answer

The pod will remain running but will not be included in the Service's endpoints. When a readiness probe fails, Kubernetes marks the pod as not ready. The pod continues running, but the associated Service removes the pod's IP from its Endpoints (or EndpointSlice) list. This ensures the Service does not route traffic to a pod that is not prepared to handle requests, while allowing the pod to remain alive for debugging or other internal operations.

Answer

The pod will be marked as CrashLoopBackOff

Answer

The pod will be terminated and restarted

Answer

The pod will be evicted from the node

Question 9

Which of the following commands creates a ClusterIP service named 'my-service' that exposes port 80 on the pod with label 'app=web'?

Accepted Answer

kubectl expose deployment my-deployment --port=80 --name=my-service. `kubectl expose deployment my-deployment --port=80 --name=my-service` creates a ClusterIP service by default, which selects pods based on the labels of the deployment (e.g., `app=web` if the deployment has that label). The `--port=80` flag sets the service port, and the service automatically maps to the container port (defaults to the same port if `--target-port` is omitted). This command satisfies the requirement of exposing port 80 on pods with label `app=web`.

Answer

kubectl expose pod my-pod --port=80 --target-port=8080 --name=my-service

Answer

kubectl create service clusterip my-service --tcp=80:8080 --cluster-ip=10.0.0.1

Answer

kubectl expose deployment my-deployment --type=NodePort --port=80 --name=my-service

Question 10

An Ingress resource is defined as:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
  tls:
  - hosts:
    - example.com
    secretName: tls-secret
What must exist in the cluster for TLS termination to work?

Accepted Answer

A Secret named tls-secret of type kubernetes.io/tls in the same namespace. C is correct because TLS termination requires the actual TLS certificate and key to be stored in a Kubernetes Secret of type `kubernetes.io/tls`. The Ingress controller reads this Secret to terminate HTTPS connections, decrypting traffic before forwarding it to the backend service. Without this Secret, the Ingress controller cannot present a valid certificate to clients.

Answer

An IngressClass annotation specifying the ingress controller

Answer

A ServiceAccount named tls-secret

Answer

A ConfigMap named tls-secret with certificate data

Question 11

You are a Kubernetes administrator responsible for a production cluster. A development team has deployed a Pod named 'app-pod' that runs a container with a PostgreSQL database. The team reports that the Pod is failing to start with an error: 'Error: container has runAsNonRoot and image will run as root (runtime error)'. The Pod YAML is as follows:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: db
    image: postgres:latest
    securityContext:
      runAsNonRoot: true
```

The team wants to ensure the container runs securely without running as root. What is the BEST course of action?

Accepted Answer

Add `runAsUser: 999` to the container's securityContext to run the container as the postgres user.. The PostgreSQL official image runs as the 'postgres' user with UID 999 by default. Adding `runAsUser: 999` to the container's securityContext overrides the user to a non-root UID, satisfying the `runAsNonRoot: true` constraint and allowing the container to start without the runtime error.

Answer

Remove `runAsNonRoot: true` from the securityContext to allow the container to run as root.

Answer

Increase the Pod's resource limits because the error is due to insufficient memory.

Answer

Create a PodSecurityPolicy that allows running as root.

Question 12

You want to restrict ingress traffic to pods with label 'app: web' in namespace 'frontend' to only come from pods in namespace 'backend'. Which NetworkPolicy YAML is correct?

Accepted Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: backend. It defines a NetworkPolicy in the 'frontend' namespace that selects pods with label 'app: web' and allows ingress traffic only from pods in the 'backend' namespace. The key is the `namespaceSelector` with `kubernetes.io/metadata.name: backend`, which matches the namespace named 'backend' (this label is automatically added by Kubernetes to every namespace). The `policyTypes: [Ingress]` explicitly enables ingress rules, and the `from` rule restricts traffic to only those originating from the 'backend' namespace.

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: backend
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: frontend

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0

Answer

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
  namespace: frontend
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

Question 13

You want to debug a pod that is failing to start. The pod does not have a shell installed. Which command can you use to attach an ephemeral debug container to the running (or failed) pod?

Accepted Answer

kubectl debug -it --image=busybox --target=. `kubectl debug` allows you to attach an ephemeral debug container to a running or failed pod, even if the pod lacks a shell. The `--target` parameter specifies the container in the pod to which the debug container attaches, enabling network namespace sharing and process inspection without modifying the original container.

Answer

kubectl attach <pod>

Answer

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

Answer

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

Question 14

A pod manifest includes the following securityContext: securityContext: { runAsUser: 1000, runAsGroup: 3000, fsGroup: 2000 }. What UID will be used for processes in the container?

Accepted Answer

1000. The `runAsUser` field in the pod's securityContext explicitly sets the user ID (UID) for all processes in the container. In this manifest, `runAsUser: 1000` overrides the default UID (usually 0, root) and ensures that the container's main process runs with UID 1000. The `runAsGroup` and `fsGroup` fields affect group IDs and file ownership, not the process UID.

Answer

0 (root)

Answer

3000

Answer

2000

Question 15

A pod with the following security context is in CrashLoopBackOff. The container image runs as user 1000.

securityContext:
  runAsUser: 2000
  runAsGroup: 3000
  fsGroup: 4000

What is the most likely cause?

Accepted Answer

runAsUser is set to 2000, but the container expects to run as user 1000. The container image is built to run as user 1000, but the Pod's securityContext overrides this with runAsUser: 2000. When the container starts, it attempts to access files or resources that require user 1000 permissions, causing it to fail and enter CrashLoopBackOff. The mismatch between the image's default user and the securityContext's runAsUser is the most direct cause of the crash.

Answer

runAsGroup is set to 3000, but the container expects group 1000

Answer

The pod does not have enough CPU resources

Answer

fsGroup is set to 4000, causing volume mount permission issues