CKAD Practice Test 41 — 15 Questions

Question 1

Which command is used to scale a Deployment named 'web' to 5 replicas?

Accepted Answer

kubectl scale deployment web --replicas=5. `kubectl scale deployment web --replicas=5` directly updates the `spec.replicas` field of the Deployment to 5, instructing the ReplicaSet controller to adjust the number of Pods to match the desired count. This is the standard imperative command for scaling workloads in Kubernetes.

Answer

kubectl autoscale deployment web --min=5 --max=5

Answer

kubectl set replicas deployment/web 5

Answer

kubectl edit deployment web --replicas=5

Question 2

What is the purpose of the 'kubectl rollout status' command?

Accepted Answer

To check the current status of a rollout. The command 'kubectl rollout status' tracks the progress of a rollout until it completes or fails.

Answer

To roll back a deployment

Answer

To view the rollout history

Answer

To pause a rollout

Question 3

Which TWO of the following are true about headless services? (Select 2)

Accepted Answer

DNS returns multiple A records, one for each pod's IP. Headless services (with clusterIP: None) cause DNS to return multiple A records, one for each pod's IP address, rather than a single virtual IP. This allows direct pod-to-pod DNS resolution, which is essential for stateful applications like databases that need to discover individual pod endpoints.

Answer

They provide a stable virtual IP for load balancing

Answer

They cannot have a selector

Answer

They are used exclusively with Deployments

Question 4

A pod named 'web-app' is running but has no environment variables. The developer wants to inject a variable 'DB_URL=postgres://db:5432' from a ConfigMap named 'db-config'. Which pod spec snippet correctly achieves this?

Accepted Answer

env:
- name: DB_URL
  valueFrom:
    configMapKeyRef:
      name: db-config
      key: DB_URL. It uses the `configMapKeyRef` field under `valueFrom` to inject a specific key from a ConfigMap as an environment variable. This allows the pod to consume the `DB_URL` value from the `db-config` ConfigMap without exposing it as a file or using `envFrom`.

Answer

env:
- name: DB_URL
  value: "postgres://db:5432"

Answer

envFrom:
- configMapRef:
    name: db-config
    key: DB_URL

Answer

env:
- name: DB_URL
  valueFrom:
    secretKeyRef:
      name: db-config
      key: DB_URL

Question 5

A pod is running but the application inside is not serving traffic. The team runs 'kubectl exec -it <pod> -- curl localhost:8080' and gets 'Connection refused'. What is the most likely cause?

Accepted Answer

Application is not listening on port 8080. The 'Connection refused' error from curl indicates that the TCP connection to port 8080 was actively rejected by the kernel, meaning no process is listening on that port inside the container. This is most commonly caused by the application not starting, crashing before binding, or being configured to listen on a different port (e.g., 3000, 8443). The error is immediate and does not suggest a timeout or network-level block.

Answer

Container logs are full and writing to disk is slow

Answer

NetworkPolicy is blocking traffic

Answer

Liveness probe is failing and restarting the container

Question 6

A pod with a startup probe configured is taking longer than usual to start. The startup probe has 'failureThreshold: 10' and 'periodSeconds: 5'. What is the maximum time the pod has to start before it is restarted?

Accepted Answer

50 seconds. The maximum time a pod has to start before being restarted is calculated by multiplying the startup probe's `failureThreshold` (10) by its `periodSeconds` (5), which equals 50 seconds. This is because the startup probe runs every 5 seconds, and after 10 consecutive failures (i.e., the probe never succeeds within that window), the kubelet restarts the container. The startup probe is specifically designed to give slow-starting applications a grace period before the liveness probe takes over.

Answer

10 seconds

Answer

30 seconds

Answer

60 seconds

Question 7

A pod named 'web-app' is experiencing high CPU usage. You want to investigate which process inside the container is consuming the most CPU. Which command should you run?

Accepted Answer

kubectl exec web-app -- top. `kubectl exec web-app -- top` runs the `top` command inside the container of the pod 'web-app', which displays real-time process-level CPU usage. This allows you to identify the specific process consuming the most CPU, directly addressing the question's requirement to investigate inside the container.

Answer

kubectl logs -f web-app

Answer

kubectl describe node

Answer

kubectl top pod web-app

Question 8

A developer needs to expose database credentials to a Pod as environment variables. The credentials are stored in a Kubernetes Secret named 'db-secret' with keys 'username' and 'password'. Which two methods correctly inject these values? (Choose two.)

Accepted Answer

Define an env entry with 'valueFrom' and 'secretKeyRef' for each key.. `valueFrom` with `secretKeyRef` allows you to reference a specific key from a Kubernetes Secret and inject its value as an environment variable. This is the standard method for exposing individual secret keys to a Pod. Option E is correct because `envFrom` with `secretRef` injects all keys from the referenced Secret as environment variables into the container, which is efficient when you need to expose multiple keys without defining each one individually.

Answer

Set 'env.name' to 'db-secret' and 'env.value' from 'secretKeyRef'.

Answer

Use 'valueFrom' with 'configMapKeyRef'.

Answer

Mount the Secret as a volume and source environment variables from the mounted files.

Question 9

Which TWO statements are true about readiness probes? (Select two.)

Accepted Answer

Readiness probes can be configured as httpGet, exec, tcpSocket, or gRPC. Readiness probes support four handler types: httpGet, exec, tcpSocket, and gRPC (since Kubernetes 1.24). These are defined in the container spec under the `readinessProbe` field, allowing the kubelet to check container readiness using HTTP status codes, command exit codes, TCP port connectivity, or gRPC health checks.

Answer

Readiness probes are only executed when the pod is first started

Answer

A failing readiness probe causes the pod to be restarted

Answer

Readiness probes are defined in the pod spec under 'startupProbe'

Question 10

You have a Deployment 'web' with 'maxSurge: 25%' and 'maxUnavailable: 25%'. Current replicas is 4. You update the image. How many pods will be created at most during the rollout?

Accepted Answer

5. With maxSurge: 25% and maxUnavailable: 25%, the maximum number of pods created during a rolling update is calculated as current replicas (4) plus the surge (25% of 4 = 1), resulting in up to 5 pods at any given time. The surge allows extra pods to be created before terminating old ones, ensuring availability while limiting the total to 5.

Answer

8

Answer

4

Answer

6

Question 11

Which THREE of the following are valid reasons to use a startup probe? (Select THREE.)

Accepted Answer

To handle containers that have a variable startup time. A startup probe is specifically designed for containers that have a variable or long initialization time. It allows the kubelet to delay the start of liveness and readiness probes until the application has finished starting up, preventing premature failures.

Answer

To check if the container is healthy after startup

Answer

To remove the pod from service endpoints if it fails

Question 12

You have a Job that should retry up to 3 times if it fails, and should be considered failed after 4 failures total (including retries). Which YAML fields should you set?

Accepted Answer

spec.backoffLimit: 3. The `spec.backoffLimit` field in a Kubernetes Job defines the number of retries before considering the Job as failed. Setting it to 3 means the Job will retry up to 3 times after the initial failure, resulting in a total of 4 failures (1 initial + 3 retries), which matches the requirement.

Answer

spec.activeDeadlineSeconds: 4

Answer

spec.backoffLimit: 4

Answer

spec.restartPolicy: OnFailure and spec.backoffLimit: 3

Question 13

Which API version is correct for a Deployment in Kubernetes v1.29?

Accepted Answer

apps/v1. (apps/v1) is correct because the Deployment API version apps/v1 has been the stable version since Kubernetes v1.9, and it is the only correct version for creating Deployments in Kubernetes v1.29. The apps/v1 API group is the current, stable, and recommended version for managing Deployments, ReplicaSets, and other workload resources.

Answer

extensions/v1beta1

Answer

v1

Answer

apps/v1beta2

Question 14

Which kubectl command is used to view the rollout status of a Deployment named 'web-app'?

Accepted Answer

kubectl rollout status deployment web-app. `kubectl rollout status deployment web-app` is the dedicated command to monitor the progress of a rollout for a Deployment named 'web-app'. It blocks until the rollout completes successfully or reports a failure, providing real-time status updates such as 'Waiting for rollout to finish' or 'deployment "web-app" successfully rolled out'.

Answer

kubectl rollout history deployment web-app

Answer

kubectl describe deployment web-app

Answer

kubectl status deployment web-app

Question 15

Which of the following correctly describes the purpose of a PodSecurityPolicy (PSP) in Kubernetes? (Note: PSP is deprecated in v1.21+ and removed in v1.25; Pod Security Admission is the replacement.)

Accepted Answer

PSP is deprecated; its replacement is Pod Security Admission (PSA). PodSecurityPolicy (PSP) was indeed deprecated in Kubernetes v1.21 and removed in v1.25, with Pod Security Admission (PSA) as its official replacement. PSA uses built-in Pod Security Standards (baseline, restricted, privileged) enforced via admission controllers and labels, eliminating the need for a separate admission webhook or CRD-based policy object.

Answer

PSP is applied automatically to all pods in a cluster without configuration

Answer

PSP is a namespace-scoped resource that defines default security for pods

Answer

PSP cannot be used to control container security contexts