CKAD Timed Hard Questions — 25 Difficult Questions

Question 1

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?

15 minute time limit — choose an answer to begin.

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 2

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 3

Which THREE are valid patterns for multi-container Pods?

Accepted Answer

Ambassador. (Ambassador) is correct because the Ambassador pattern uses a proxy container that mediates network traffic between the main application container and external services, allowing the main container to connect to localhost while the ambassador handles protocol translation or service discovery. This is a valid multi-container Pod design pattern in Kubernetes, commonly implemented with tools like Envoy or a custom sidecar proxy.

Answer

Init

Answer

Replicator

Question 4

An Ingress resource has the following spec. What is the effect?

spec:
  tls:
  - hosts:
    - myapp.example.com
    secretName: myapp-tls
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp
            port:
              number: 80

Accepted Answer

Ingress terminates TLS using the secret and routes to the service.. The Ingress spec defines TLS termination at the ingress controller using the secret `myapp-tls` for the host `myapp.example.com`. The `tls` block configures the ingress to decrypt HTTPS traffic using the certificate and key stored in that secret, and then forward the decrypted HTTP traffic to the backend service `myapp` on port 80. This is the standard behavior for securing traffic with TLS in Kubernetes Ingress.

Answer

Ingress uses the secret for client authentication.

Answer

Ingress redirects HTTP to HTTPS automatically.

Answer

Ingress passes the TLS connection through to the service.

Question 5

A developer reports that a container in a pod is not responding correctly. You need to get an interactive shell in the container to investigate. Which command should you run?

Accepted Answer

kubectl exec -it -- /bin/bash. `kubectl exec -it -- /bin/bash` attaches an interactive terminal to a running container within an existing pod, allowing direct shell access for debugging. The `-it` flags enable interactive mode with a TTY, and `/bin/bash` starts a shell if available in the container image. This is the standard method for troubleshooting a container that is already deployed and running.

Answer

kubectl run -it --rm debug --image=busybox

Answer

kubectl exec <pod> -- /bin/bash

Answer

kubectl debug -it --image=busybox --target=

Question 6

You have a pod that takes 2 minutes to start its application. You want to avoid the liveness probe from killing the pod during startup, but still have it active afterward. Which probe should you add to the pod spec?

Accepted Answer

Add a startup probe with a failureThreshold high enough to cover the startup time. A startup probe is designed specifically for slow-starting containers. It runs before the liveness probe and, if it fails, the container is killed. By setting a high failureThreshold (e.g., 12 with a 10-second period gives 120 seconds), you allow the application up to 2 minutes to start without the liveness probe interfering. Once the startup probe succeeds, the liveness probe takes over normally.

Answer

Increase the timeoutSeconds on the liveness probe

Answer

Set periodSeconds on the liveness probe to 120

Answer

Set initialDelaySeconds on the liveness probe to 120

Question 7

You need to create a Pod that runs with a specific non-root user (UID 1000), prevents privilege escalation, and mounts the container's filesystem as read-only. Which securityContext field is NOT required to achieve these requirements?

Accepted Answer

runAsGroup: 1000. (runAsGroup: 1000) is not required because the requirement only specifies a non-root user (UID 1000) and does not mandate a specific group ID. The runAsGroup field sets the primary group for the container's processes, but it is optional; without it, the container will use the default group associated with the user or the container's default group. The other options are necessary: runAsUser: 1000 sets the user, readOnlyRootFilesystem: true makes the filesystem read-only, and allowPrivilegeEscalation: false prevents privilege escalation.

Answer

runAsUser: 1000

Answer

readOnlyRootFilesystem: true

Answer

allowPrivilegeEscalation: false

Question 8

Which THREE of the following are correct about init containers? (Select THREE.)

Accepted Answer

They run to completion before the main application containers start. Init containers are designed to run sequentially to completion before any of the pod's regular application containers start. This ensures that prerequisites, such as database schema migrations or configuration file generation, are completed before the main application begins execution.

Answer

They cannot have resource limits set

Answer

They run after the main application containers have started

Question 9

Which THREE commands can be used to get detailed information about a pod named 'my-pod'? (Choose three.)

Accepted Answer

kubectl get pod my-pod -o json. `kubectl get pod my-pod -o json` retrieves the full object representation of the pod in JSON format, which includes all fields such as metadata, spec, status, and annotations. This provides detailed, machine-readable information about the pod's current state and configuration.

Answer

kubectl logs my-pod

Answer

kubectl exec my-pod -- env

Question 10

A NetworkPolicy is applied to a namespace with the following rules:
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
```
What is the effect on pods in that namespace?

Accepted Answer

All inbound traffic is denied, outbound traffic is allowed. This NetworkPolicy selects all pods in the namespace (podSelector: {}) and specifies only Ingress in policyTypes. By default, if any NetworkPolicy selects a pod, all traffic not explicitly allowed by a rule is denied. Since no ingress rules are defined, all inbound traffic is denied. Outbound traffic is not restricted because Egress is not listed in policyTypes and no egress rules are defined, so it remains allowed by default.

Answer

All traffic is allowed

Answer

Only traffic from specific namespaces is allowed

Answer

All inbound and outbound traffic is denied

Question 11

An Ingress has two rules:
- host: app.example.com, path: /api -> service-a:80
- host: api.example.com, path: / -> service-b:80
A request to `app.example.com/api/v1` reaches which service?

Accepted Answer

service-a. Ingress rules match the longest prefix of the request path for the given host. For `app.example.com/api/v1`, the path `/api` is a prefix match (since `/api/v1` starts with `/api`), so it routes to service-a:80. The second rule requires host `api.example.com`, which does not match, so service-b is not considered.

Answer

Both services

Answer

Neither service

Answer

service-b

Question 12

Which THREE of the following are true about Kubernetes Services? (Select 3)

Accepted Answer

The NodePort range is 30000-32767 by default.. The default NodePort range in Kubernetes is 30000-32767, as defined by the kube-apiserver's --service-node-port-range flag. This range ensures that NodePorts do not conflict with well-known or ephemeral ports used by system services.

Answer

Headless Services have a ClusterIP assigned.

Answer

Services can only expose one port.

Question 13

Which THREE of the following are valid fields for configuring a probe in Kubernetes? (Select 3)

Accepted Answer

initialDelaySeconds. `initialDelaySeconds` is a valid field in a Kubernetes probe configuration (e.g., livenessProbe, readinessProbe, startupProbe). It defines the number of seconds after the container has started before the probe is initiated, allowing the application time to initialize before health checks begin.

Answer

retrySeconds

Answer

intervalSeconds

Question 14

Which TWO of the following are valid ways to mount a Secret into a pod as environment variables? (Select exactly 2)

Accepted Answer

env:
- name: SECRET_KEY
  valueFrom:
    secretKeyRef:
      name: my-secret
      key: key. `secretKeyRef` is the standard Kubernetes API field for referencing a specific key from a Secret object and injecting its value as an environment variable. Option E is correct because `envFrom` with `secretRef` allows you to load all key-value pairs from a Secret as environment variables into the pod, which is a valid and common pattern.

Answer

env:
- name: SECRET_KEY
  valueFrom:
    configMapKeyRef:
      name: my-secret
      key: key

Answer

env:
- name: SECRET_KEY
  valueFrom:
    secretEnvRef:
      name: my-secret
      key: key

Answer

envFrom:
- configMapRef:
    name: my-secret

Question 15

A pod has a startup probe with failureThreshold: 30 and periodSeconds: 10. The application takes up to 5 minutes to start. What should be changed to ensure the startup probe does not kill the container prematurely?

Accepted Answer

Increase failureThreshold to 40. Increasing failureThreshold to 40 (from 30) with periodSeconds: 10 gives a total timeout of 40 × 10 = 400 seconds (6 minutes 40 seconds), which exceeds the 5-minute startup time. Setting initialDelaySeconds (Option D) would also delay the first probe execution, but best practices recommend adjusting the probe's failure threshold and interval instead of using an initial delay for startup probes, as the purpose of a startup probe is to start probing immediately and replace the need for an initial delay.

Answer

Change periodSeconds to 5

Answer

Change timeoutSeconds to 30

Answer

Set initialDelaySeconds to 300

Question 16

You have a Deployment with a liveness probe that fails intermittently, causing the pod to restart. You want to reduce the sensitivity of the probe so that it only restarts after 3 consecutive failures. Which probe parameter should you adjust?

Accepted Answer

failureThreshold. The `failureThreshold` parameter defines the number of consecutive probe failures required before Kubernetes considers the probe to have failed and triggers the configured action (e.g., restarting the container). By default, this value is 3, but if it is set lower (e.g., 1), a single failure causes a restart. Increasing `failureThreshold` to 3 (or higher) ensures that the liveness probe only restarts the pod after three consecutive failures, thereby reducing sensitivity to transient issues.

Answer

initialDelaySeconds

Answer

periodSeconds

Answer

successThreshold

Question 17

An application pod is logging sensitive data (e.g., passwords) to stdout. The security team requires that these logs be redacted before they are stored. Which approach should you recommend?

Accepted Answer

Modify the application code to stop logging sensitive data before redeploying.. The most reliable way to ensure sensitive data is never stored is to prevent it from being logged in the first place. Option D directly achieves the security requirement without introducing complex infrastructure or relying on a sidecar that cannot intercept stdout logs as described. The sidecar pattern is indeed useful for log processing, but it requires the main container to write logs to a file that is shared via a volume; it cannot read the stdout of another container. Node-level filtering (C) may introduce latency or leave brief on-disk exposure.

Answer

Set the log level to ERROR only to reduce verbosity and avoid logging sensitive data.

Answer

Add a sidecar container that reads the application's log file, redacts sensitive data, and writes to stdout.

Answer

Configure a LogCollector DaemonSet to filter logs at the node level.

Question 18

You need to debug a pod that is running but not serving traffic. You want to add a temporary container with networking tools to the pod. Which command should you use?

Accepted Answer

kubectl debug mypod --image=busybox -it. `kubectl debug` allows you to add an ephemeral container (a temporary container with networking tools) to an existing running pod without restarting it. This is the only command that directly injects a new container into the pod's network namespace, enabling debugging of network issues while the original container continues running.

Answer

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

Answer

kubectl attach mypod

Answer

kubectl exec -it mypod -- /bin/sh

Question 19

You are tasked with running a batch job that processes 100 items in parallel, using a Kubernetes Job. The Job should ensure that all items are processed even if some pods fail, and the total number of pod failures should be limited to 3. Which Job configuration is correct?

Accepted Answer

Set spec.parallelism: 100, spec.completions: 100, spec.backoffLimit: 3. Setting `spec.parallelism: 100` allows 100 pods to run concurrently, `spec.completions: 100` ensures all 100 items are processed (each pod handles one item), and `spec.backoffLimit: 3` limits the total number of pod failures to 3 before the Job is marked as failed. This configuration guarantees that even if some pods fail, the Job will retry them up to the specified backoff limit, ensuring all items are processed.

Answer

Set spec.parallelism: 1, spec.completions: 100, spec.backoffLimit: 3

Answer

Set spec.parallelism: 100, spec.completions: 1, spec.backoffLimit: 3

Answer

Set spec.parallelism: 100, spec.completions: 100, spec.activeDeadlineSeconds: 300

Question 20

You need to debug a pod that has no running containers because it is in a CrashLoopBackOff state. You want to start an ephemeral container with debugging tools in the same namespace. Which command accomplishes this?

Accepted Answer

kubectl debug -it pod-name --image=busybox --target=container-name. `kubectl debug` allows you to start an ephemeral container in an existing pod that is in a CrashLoopBackOff state. The `--target` flag attaches the ephemeral container to the same Linux namespace as the specified container, enabling debugging without restarting the pod. This is the only command that works when the pod has no running containers and `kubectl exec` fails.

Answer

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

Answer

kubectl attach pod-name

Answer

kubectl exec -it pod-name -- /bin/sh