CKAD Hard Questions — 25 Difficult Questions

Question 1

During a deployment update, the rollout is stuck and new pods are not becoming ready. The developer checks the events and sees 'Back-off restarting failed container'. What is the most likely cause?

Accepted Answer

The container's entrypoint command fails immediately after start. The 'Back-off restarting failed container' event indicates that the container process exits immediately after starting, causing Kubernetes to repeatedly restart it with increasing back-off delays. This is most commonly caused by a container entrypoint or command that fails at runtime, such as a misconfigured binary, missing dependency, or incorrect startup script. Unlike probe failures, which cause restarts after the container is already running, this error occurs before the container can even become ready.

Answer

The liveness probe is failing

Answer

The image pull secret is missing

Answer

The pod exceeds its memory limit and is OOMKilled

Question 2

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 3

When using Helm, which command installs a chart from a repository into a namespace, overriding a value?

Accepted Answer

helm install myrelease repo/chart --set key=value --namespace ns. `helm install` is the command used to deploy a new release from a chart repository into a specified namespace, and the `--set` flag overrides a default value in the chart's `values.yaml` at install time. The syntax `repo/chart` references a chart from a configured Helm repository, and `--namespace ns` scopes the release to that namespace.

Answer

helm template myrelease repo/chart --set key=value --namespace ns

Answer

helm create myrelease repo/chart --set key=value --namespace ns

Answer

helm upgrade --install --set key=value myrelease repo/chart --namespace ns

Question 4

You have a Deployment with the following strategy: rollingUpdate: maxSurge: 25%, maxUnavailable: 25%. The Deployment has 4 replicas. During an update, what is the minimum number of pods guaranteed to be available?

Accepted Answer

3. With 4 replicas and a rolling update strategy of maxSurge: 25% and maxUnavailable: 25%, the maximum number of pods that can be unavailable during the update is 25% of 4, which is 1. Therefore, the minimum number of pods guaranteed to be available is 4 - 1 = 3. This is calculated by rounding down the maxUnavailable value (1) and ensuring the desired replica count minus unavailable pods equals the minimum available.

Answer

2

Answer

4

Answer

1

Question 5

You are designing a Pod that must run a diagnostic tool to collect network logs before the main application starts. The diagnostic tool should run to completion, then the main application starts. Which approach should you use?

Accepted Answer

Add the diagnostic tool as an init container in the Pod. Init containers run sequentially before the Pod's main containers start, and they must complete successfully before the main application container begins. This makes them ideal for setup tasks like running a diagnostic tool to collect network logs that must finish before the main application starts.

Answer

Add the diagnostic tool as a sidecar container in the same Pod

Answer

Add the diagnostic tool as a sidecar container with a postStart hook

Answer

Create a separate Job that runs before the Pod

Question 6

A pod has a readiness probe using tcpSocket on port 3306. The application listens on port 3306 but returns errors on database queries. What is the effect of the readiness probe?

Accepted Answer

The pod will be considered ready as long as the TCP port is open, even if the application is not fully functional. A readiness probe with tcpSocket only checks whether the TCP port is open and accepting connections. It does not verify application-level health, such as whether the application can process queries or return valid responses. Since port 3306 is open, the probe succeeds, and the pod is considered ready, even though the application returns errors on database queries.

Answer

The pod will be evicted from the node

Answer

The pod will be marked not ready because the application returns errors

Answer

The container will be restarted due to readiness probe failure

Question 7

You run 'kubectl apply -f pod.yaml' but the pod remains in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 Insufficient cpu'. What is the most likely cause?

Accepted Answer

The pod's CPU request exceeds the available CPU capacity on any node. The error '0/1 nodes are available: 1 Insufficient cpu' indicates that the pod's CPU request (specified in the container spec under `resources.requests.cpu`) exceeds the allocatable CPU capacity on any node in the cluster. The scheduler evaluates CPU requests, not limits, for admission decisions; if no node has enough unallocated CPU to satisfy the request, the pod remains Pending.

Answer

The pod's memory limit is too low

Answer

The container image is not found in the registry

Answer

The node is under disk pressure

Question 8

A Pod named `my-pod` in namespace `ns1` tries to resolve `svc-a.ns2.svc.cluster.local`. The DNS query fails. The Service `svc-a` exists in namespace `ns2`. What is the most likely cause?

Accepted Answer

The DNS add-on (e.g., CoreDNS) is not deployed or is misconfigured. The DNS query for `svc-a.ns2.svc.cluster.local` fails despite the Service existing, which points to a cluster-wide DNS resolution issue. CoreDNS is the default DNS add-on in Kubernetes that translates service names to IP addresses; if it is not deployed or misconfigured, all DNS queries (including cross-namespace ones) will fail. The fact that the Service exists and the Pod is in a different namespace does not inherently prevent resolution—CoreDNS handles cross-namespace lookups by default.

Answer

The Service `svc-a` does not have any endpoints

Answer

The Pod cannot resolve names from other namespaces

Answer

The Service type is NodePort

Question 9

You create a ServiceAccount 'my-sa' with automountServiceAccountToken: false. A pod that references this ServiceAccount also sets automountServiceAccountToken: true in its spec. Will the service account token be mounted?

Accepted Answer

Yes, because the pod spec setting takes precedence.. The pod spec's `automountServiceAccountToken: true` takes precedence over the ServiceAccount's `automountServiceAccountToken: false`. Kubernetes merges the ServiceAccount and pod-level settings, with the pod-level setting overriding the ServiceAccount's setting. Therefore, the token will be mounted into the pod.

Answer

No, because the ServiceAccount has automountServiceAccountToken: false, which is a hard block.

Answer

It depends on the namespace default settings.

Answer

No, because the ServiceAccount setting overrides the pod setting.

Question 10

An administrator creates a Pod with an ephemeral container using 'kubectl debug my-pod -it --image=busybox --target=my-container'. The ephemeral container shares the same process namespace as the target container. Which flag enables this?

Accepted Answer

--target. The `--target` flag in `kubectl debug` specifies the target container within the Pod for the ephemeral container. When used, the ephemeral container shares the same process namespace as the target container, allowing tools like `ps` to see processes from the target container. This is essential for debugging scenarios where you need to inspect or interact with the target container's processes.

Answer

--container

Answer

--namespace

Answer

--share-process-namespace

Question 11

A ClusterRole named 'secret-reader' grants get, list, watch on secrets in all namespaces. A RoleBinding in namespace 'app' binds this ClusterRole to a ServiceAccount 'app-sa'. Which of the following is true about the effective permissions of 'app-sa'?

Accepted Answer

The ServiceAccount can read secrets only in namespace 'app'. A RoleBinding can only grant permissions within its own namespace, even when it references a ClusterRole. Since the RoleBinding is in namespace 'app', the ServiceAccount 'app-sa' receives the permissions defined in the 'secret-reader' ClusterRole, but scoped only to namespace 'app'. Therefore, it can read secrets only in namespace 'app', not in all namespaces.

Answer

The ServiceAccount can read secrets in all namespaces

Answer

The RoleBinding is invalid because ClusterRole cannot be used with RoleBinding

Answer

The ServiceAccount can read secrets only in the default namespace

Question 12

A Kubernetes Job with parallelism=3 and completions=6 is created. How many pods will run concurrently at most?

Accepted Answer

3. The `parallelism` field in a Kubernetes Job specifies the maximum number of pods that can run concurrently. With `parallelism=3`, at most 3 pods will run at the same time, regardless of the total number of completions required.

Answer

9

Answer

6

Answer

1

Question 13

You want to perform a canary deployment where 10% of traffic goes to the new version. You have a Deployment 'app-v1' with 10 replicas. You create a second Deployment 'app-v2' with 1 replica and a new Service. What Kubernetes resource is typically used to split traffic between the two Services?

Accepted Answer

Ingress resource with a canary annotation. An Ingress resource with a canary annotation (e.g., `nginx.ingress.kubernetes.io/canary-weight: "10"`) allows you to split traffic between two Services by weight. This is the standard Kubernetes approach for canary deployments, where the Ingress controller (like NGINX) routes a specified percentage of traffic to the canary Service (app-v2) and the rest to the primary Service (app-v1).

Answer

A single Service with multiple selectors

Answer

NetworkPolicy

Answer

HorizontalPodAutoscaler

Question 14

You need to create a Secret of type 'kubernetes.io/tls' for ingress. Which command is correct?

Accepted Answer

kubectl create secret tls my-tls --cert=cert.pem --key=key.pem. `kubectl create secret tls` is the dedicated command for creating a TLS secret, and it uses the `--cert` and `--key` flags to specify the certificate and private key files respectively. This creates a Secret of type `kubernetes.io/tls`, which is required for Ingress resources to terminate HTTPS traffic.

Answer

kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem

Answer

kubectl create secret tls my-tls --certificate=cert.pem --private-key=key.pem

Answer

kubectl create secret tls my-tls --from-file=tls.crt=cert.pem --from-file=tls.key=key.pem

Question 15

Which TWO statements about Kubernetes DNS are correct?

Accepted Answer

A service named 'api' in namespace 'prod' has DNS name 'api.prod.svc.cluster.local'. Kubernetes DNS assigns a fully qualified domain name (FQDN) to services following the pattern `..svc.cluster.local`. For a service named 'api' in the 'prod' namespace, the DNS name is `api.prod.svc.cluster.local`, enabling cluster-internal service discovery via CoreDNS or kube-dns.

Answer

The kube-dns service is responsible for DNS resolution

Answer

Pods with hostNetwork: true automatically get DNS entries

Answer

A pod's DNS name is always 'pod-ip.namespace.pod.cluster.local'

Question 16

A CronJob is configured with concurrencyPolicy: Replace and a job execution takes 10 minutes. The schedule is */5 * * * *. Which statement is true about job executions?

Accepted Answer

Every 5 minutes, a new job is created, and if the previous job is still running, it is killed. With `concurrencyPolicy: Replace`, if a new job is triggered by the schedule (every 5 minutes) while the previous job is still running (it takes 10 minutes), the running job is terminated and replaced by the new one. This ensures only one job runs at a time, and the new job starts immediately, even if the previous one hasn't finished.

Answer

Jobs will never overlap because the schedule is too frequent

Answer

The job will be skipped if the previous one hasn't finished

Answer

Jobs will overlap, with up to two jobs running concurrently

Question 17

A deployment 'api-deploy' has resource limits set but is frequently being OOMKilled. The team suspects the memory limit is too low. Which approach should be taken to confirm this without causing downtime?

Accepted Answer

Increase the memory limit in the deployment spec and apply the change; the rollout will automatically restart pods.. Updating the deployment spec triggers a rolling update, which replaces pods with new ones having the increased memory limit without downtime. This approach leverages Kubernetes' deployment controller to manage the rollout automatically, ensuring service continuity while adjusting resource limits.

Answer

Create a new pod with a higher memory limit and delete the old pods manually.

Answer

Set the memory limit to unlimited by removing the limit section and restart the pod.

Answer

Use 'kubectl set resources' to increase the limit on the running pod dynamically.

Question 18

You have a CronJob that runs every 5 minutes. The job sometimes takes longer than 5 minutes to complete. You want to ensure that while a job is running, the next scheduled job is skipped (not started). Which concurrencyPolicy should you use?

Accepted Answer

Forbid. The `Forbid` concurrencyPolicy ensures that if a previous job instance is still running when the next scheduled time arrives, the new job is simply skipped (not created). This prevents overlapping executions, which is exactly what you need when a CronJob's duration can exceed its schedule interval.

Answer

Skip

Answer

Allow

Answer

Replace

Question 19

You deploy a pod with the following specification:

apiVersion: v1
kind: Pod
metadata:
  name: probe-pod
spec:
  containers:
  - name: app
    image: nginx
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      failureThreshold: 3

The application listens on port 80, not 8080. What will happen to the pod?

Accepted Answer

The container will be restarted repeatedly due to liveness probe failure. The liveness probe is configured to perform an HTTP GET request on port 8080, but the application (nginx) listens on port 80. Since the probe will never receive a successful HTTP response (it will get a connection refused or timeout), it will fail. With a failureThreshold of 3, after three consecutive failures the kubelet will consider the container unhealthy and restart it. This cycle repeats indefinitely, causing the container to be restarted repeatedly.

Answer

The pod will be terminated and not restarted

Answer

The pod will start and run normally

Answer

The pod will be stuck in 'Pending' state

Question 20

Which of the following is a correct Kustomize kustomization.yaml configuration for setting an image tag to 'v2'?

Accepted Answer

images:
- name: my-app
  newTag: v2. In Kustomize, the `images` field in `kustomization.yaml` uses the `newTag` key to override the tag of an existing container image. This allows you to change the image tag to 'v2' without modifying the original YAML manifests, aligning with Kustomize's declarative patching approach.

Answer

images:
- name: my-app
  newName: v2

Answer

patches:
- target:
    kind: Deployment
  patch: |-
    - op: replace
      path: /spec/template/spec/containers/0/image
      value: my-app:v2

Answer

imageTag:
- name: my-app
  tag: v2