CKAD Practice Test 50 — 15 Questions

Question 1

You want to use Kustomize to apply a patch that adds a sidecar container to all pods in a Deployment. Which Kustomize feature should you use?

Accepted Answer

patchesStrategicMerge. `patchesStrategicMerge`, is correct because it allows you to apply a strategic merge patch to a Kubernetes resource, such as adding a sidecar container to all pods in a Deployment. This feature merges the patch into the base resource definition, enabling modifications like appending containers to the pod spec without overwriting the entire resource.

Answer

namePrefix

Answer

replicas

Answer

images

Question 2

What is the correct command to forward a local port to a pod for debugging?

Accepted Answer

kubectl port-forward pod/my-pod 8080:80. `kubectl port-forward` creates a tunnel from a local port (8080) to a target port (80) on a pod, enabling direct network access for debugging without exposing the pod externally. This command is specifically designed for forwarding traffic to pods, services, or deployments in Kubernetes.

Answer

kubectl expose pod my-pod --port=8080

Answer

kubectl attach pod/my-pod

Answer

kubectl proxy pod/my-pod 8080:80

Question 3

You need to create a ConfigMap named 'app-config' from a file 'config.properties'. Which kubectl command should you use?

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. `kubectl create configmap app-config --from-file=config.properties` reads the file `config.properties` and creates a ConfigMap named `app-config` with a data key equal to the filename (`config.properties`) and the value set to the file's contents. This is the standard way to create a ConfigMap from a single file in Kubernetes.

Answer

kubectl create configmap app-config config.properties

Answer

kubectl create configmap app-config --from-literal=config.properties

Answer

kubectl create configmap app-config --from-env-file=config.properties

Question 4

A pod is failing to start with error 'container has runAsNonRoot and image will run as root'. The container image runs as root. Which change allows the pod to run?

Accepted Answer

Set runAsUser to a non-zero UID, e.g., 1000. The error 'container has runAsNonRoot and image will run as root' indicates that the pod's securityContext has runAsNonRoot: true, but the container image runs as root (UID 0). To satisfy the runAsNonRoot constraint, you must override the container's user to a non-zero UID by setting runAsUser to a non-zero value (e.g., 1000). This forces the container to run as a non-root user, resolving the conflict.

Answer

Remove runAsNonRoot: true from securityContext

Answer

Add fsGroup: 1000

Answer

Set allowPrivilegeEscalation: false

Question 5

You need to debug a Pod that is in CrashLoopBackOff. Which command should you run first?

Accepted Answer

kubectl logs . When a Pod is in CrashLoopBackOff, the immediate priority is to see why the container is failing. `kubectl logs ` retrieves the container's stdout/stderr output, which typically contains the error message (e.g., missing config, runtime exception, or startup failure). This is the fastest way to get the root cause without modifying the Pod state.

Answer

kubectl get events --sort-by=.lastTimestamp

Answer

kubectl exec -it <pod-name> -- sh

Answer

kubectl describe pod <pod-name>

Question 6

A Pod is running but not responding to requests. The liveness probe is a TCP check on port 8080. What is the most likely issue?

Accepted Answer

The application is listening on port 8080 but not processing requests correctly.. A is correct because a TCP liveness probe only checks if the port is open and accepting connections, not whether the application is actually processing requests. If the application is listening on port 8080 but is stuck or not handling HTTP traffic correctly, the TCP probe will still succeed, and Kubernetes will not restart the container. This is a common scenario where the application is 'alive' at the socket level but not 'healthy' at the application layer.

Answer

The container is being throttled due to CPU limits.

Answer

The probe's initial delay is too short.

Answer

The liveness probe is misconfigured and should be an HTTP GET.

Question 7

You need to run a one-time batch job that processes 10 work items in parallel, with a maximum of 3 pods running at the same time. Which Job YAML fields should you set?

Accepted Answer

spec.parallelism: 3 and spec.completions: 10. `spec.parallelism: 3` limits the maximum number of pods running concurrently, and `spec.completions: 10` ensures the Job runs 10 work items to completion. This combination processes all 10 items in parallel batches of 3, meeting the requirement of a one-time batch job with a maximum of 3 pods at a time.

Answer

spec.template.spec.containers and spec.completions

Answer

spec.parallelism: 10 and spec.completions: 3

Answer

spec.backoffLimit: 3 and spec.completions: 10

Question 8

You apply the following NetworkPolicy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

After applying, pods in the namespace cannot reach the kube-dns service. What is the most likely reason?

Accepted Answer

The policy blocks all egress traffic, including DNS. The NetworkPolicy explicitly includes `Egress` in `policyTypes` and uses an empty `podSelector: {}`, which selects all pods in the namespace. With no `egress` rules defined, the default behavior is to deny all egress traffic. DNS resolution for kube-dns typically uses UDP/TCP on port 53, and since all egress traffic is blocked, pods cannot reach the kube-dns service, causing DNS failures.

Answer

The policy does not have a namespaceSelector

Answer

The policy blocks all ingress traffic only

Answer

The kube-dns service is not running

Question 9

A NetworkPolicy with the following spec is applied to a namespace. What is the effect? spec: podSelector: {} policyTypes: - Ingress - Egress ingress: - from: - ipBlock: cidr: 10.0.0.0/8 except: - 10.0.1.0/24 egress: - to: - ipBlock: cidr: 0.0.0.0/0

Accepted Answer

Deny all ingress traffic except from 10.0.0.0/8 excluding 10.0.1.0/24; allow all egress. The NetworkPolicy selects all pods in the namespace (empty podSelector matches all pods) and explicitly defines both Ingress and Egress policy types. The ingress rule allows traffic only from the 10.0.0.0/8 range, except 10.0.1.0/24, effectively denying all other ingress. The egress rule allows all outbound traffic to 0.0.0.0/0, so egress is unrestricted.

Answer

Deny all ingress and egress traffic

Answer

Allow all ingress and egress traffic

Answer

Allow ingress from 10.0.1.0/24 only

Question 10

A pod is stuck in 'Pending' state. You run 'kubectl describe pod pending-pod' and see the following condition: 'Status: False, Type: PodScheduled, Reason: Unschedulable, Message: 0/4 nodes are available: 1 node(s) had taint {node.kubernetes.io/disk-pressure: }, 1 node(s) had taint {node.kubernetes.io/memory-pressure: }, 2 node(s) didn't match Pod's node affinity/selector.' What is the most specific reason the pod cannot be scheduled?

Accepted Answer

Node taints and/or affinity rules prevent scheduling. The pod is in 'Pending' state because the scheduler cannot find a node that satisfies both the taint tolerations and the node affinity/selector rules. The condition 'Unschedulable' with the message explicitly states that 1 node has disk-pressure taint, 1 node has memory-pressure taint, and 2 nodes don't match the pod's node affinity/selector. This means the pod lacks tolerations for the taints and/or its affinity rules exclude all available nodes, so the scheduler cannot place it.

Answer

Container image pull failure

Answer

Pod is in CrashLoopBackOff

Answer

Insufficient CPU resources

Question 11

A pod in a namespace with a ResourceQuota that sets 'requests.cpu: 2' is failing to schedule. The pod manifest specifies 'resources: { requests: { cpu: "500m" } }'. What is the likely cause?

Accepted Answer

The namespace has already used all its CPU request quota.. The ResourceQuota sets a hard limit of 2 CPU cores for total requests across all pods in the namespace. If the sum of CPU requests from all pods already reaches or exceeds 2, a new pod with a 500m CPU request cannot be scheduled because it would exceed the quota. The pod's request (500m) is well within the quota limit, so the issue is that the namespace has exhausted its CPU request budget.

Answer

The ResourceQuota applies to limits, not requests.

Answer

The pod does not specify a CPU limit.

Answer

The pod's CPU request exceeds the ResourceQuota limit.

Question 12

You have a LimitRange in namespace 'ns' that sets default limits.cpu to 500m and default requests.cpu to 200m. You create a pod without specifying any CPU resources. What CPU values will be applied to the container?

Accepted Answer

request: 200m, limit: 500m. When a LimitRange is configured in a namespace with default CPU limits and requests, any pod created without specifying CPU resources will have those defaults injected by the admission controller. The LimitRange sets default limits.cpu to 500m and default requests.cpu to 200m, so the container will receive request: 200m and limit: 500m. This is enforced by the LimitRanger admission plugin during pod creation.

Answer

The pod will be rejected by the admission controller

Answer

request: 0, limit: 0 (no limits enforced)

Answer

request: 500m, limit: 500m

Question 13

You have a multi-stage Docker build. The first stage compiles a binary, and the second stage copies the binary from the first stage. What is the correct COPY syntax to copy a file named 'app' from the first stage named 'builder'?

Accepted Answer

COPY --from=builder app /app/. The `--from=builder` flag in the COPY instruction allows you to copy files from a specific build stage (named 'builder') in a multi-stage Docker build. This syntax is essential for multi-stage builds, where the first stage compiles artifacts and the second stage copies only the necessary binaries, reducing final image size.

Answer

COPY app /app/

Answer

COPY --stage=builder app /app/

Answer

COPY source=builder app /app/

Question 14

You have a Deployment running a web application that takes 60 seconds to start up. You need to configure probes so that Kubernetes waits for the application to fully start before checking its health and directing traffic to it. Which combination of probes should you use?

Accepted Answer

Startup probe with failureThreshold=30 and periodSeconds=2, plus liveness and readiness probes. A startup probe with a low failureThreshold and periodSeconds allows Kubernetes to wait up to 60 seconds (30 failures × 2 seconds) for the application to start, after which the liveness and readiness probes begin. This ensures the liveness probe does not kill the container prematurely during the slow startup, and the readiness probe only directs traffic once the app is fully ready.

Answer

Liveness probe with initialDelaySeconds=10 and readiness probe without delay

Answer

Readiness probe with initialDelaySeconds=60 only

Answer

Liveness probe with initialDelaySeconds=60 and readiness probe with initialDelaySeconds=60

Question 15

Which of the following is a valid method to perform a blue-green deployment in Kubernetes?

Accepted Answer

Create two Deployments and a Service, then change the Service's selector to point to the new version.. A blue-green deployment in Kubernetes is achieved by running two separate Deployments (blue and green) and using a Service to route traffic to the active version. By updating the Service's selector to match the labels of the new Deployment (green), traffic is instantly switched without downtime. This method does not rely on any built-in Deployment strategy, as Kubernetes does not have a native 'BlueGreen' strategy type.

Answer

Use kubectl rollout undo to switch between revisions.

Answer

Set spec.strategy.type: BlueGreen in the Deployment.

Answer

Use a DaemonSet to run both versions.