CKAD Practice Test 34 — 15 Questions

Question 1

A developer runs 'kubectl run mypod --image=nginx --restart=Never' and the pod is created. However, when the container exits, the pod terminates. Which restart policy ensures the pod does NOT restart after completion?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Never. The `--restart=Never` flag sets the pod's restart policy to `Never`, which means the kubelet will not restart the container when it exits. Since the pod was created with `kubectl run` and `--restart=Never`, it runs as a standalone pod (not managed by a controller), and when the container exits, the pod enters the `Succeeded` or `Failed` phase and is not restarted. This is the only restart policy that guarantees the pod does not restart after completion.

Answer

Always

Answer

OnFailure

Answer

AlwaysFail

Question 2

A Pod is in 'CrashLoopBackOff' state. 'kubectl logs mypod' shows: 'Error: listen tcp :8080: bind: address already in use'. What is the most likely cause?

Accepted Answer

The container's application is attempting to use a port that is already occupied. The error 'listen tcp :8080: bind: address already in use' indicates that the container's application is trying to bind to port 8080, but that port is already occupied by another process within the same network namespace (typically the same Pod or container). This is a classic port conflict, not a resource or permission issue, making option B correct.

Answer

The pod's resource limits are too low

Answer

The pod's ServiceAccount token is not mounted

Answer

The pod is using a readOnlyRootFilesystem

Question 3

You are deploying a Pod that contains two containers: a web server and a file sync agent. The file sync agent needs to run as long as the web server is running and should share the same network namespace. Which design pattern does this represent?

Accepted Answer

Sidecar pattern. The Sidecar pattern (D) is correct because it describes a secondary container that runs alongside a primary container in the same Pod, sharing the same network namespace and lifecycle. In this scenario, the file sync agent is a helper that must run as long as the web server runs and share its network stack, which is exactly what a sidecar container does — it extends or enhances the primary container's functionality without being its own separate Pod.

Answer

Adapter pattern

Answer

Ambassador pattern

Answer

Init container pattern

Question 4

A pod is stuck in Pending state. You run 'kubectl describe pod my-pod' and see the event: '0/4 nodes are available: 1 Insufficient cpu, 3 Insufficient memory'. What is the most likely cause?

Accepted Answer

The pod's resource requests exceed the available node resources. The event '0/4 nodes are available: 1 Insufficient cpu, 3 Insufficient memory' indicates that the Kubernetes scheduler could not find any node that satisfies the pod's resource requests. The pod's resource requests (spec.containers[].resources.requests) define the minimum CPU and memory the pod requires to run. If the sum of requests across all pods on a node exceeds the node's allocatable resources, the scheduler marks the node as unschedulable for that pod, leaving it in Pending state.

Answer

The pod uses too many secrets

Answer

The pod's resource limits are too low

Answer

The pod's container is failing health checks

Question 5

A cluster administrator wants to enforce that no pod in namespace 'prod' uses more than 4Gi of memory. Which Kubernetes resource should be created?

Accepted Answer

LimitRange. A LimitRange resource in the 'prod' namespace can set a default memory limit and a maximum memory limit per container or pod, enforcing that no pod exceeds 4Gi of memory. This is the appropriate Kubernetes primitive for per-pod resource constraints within a namespace, as it applies to all pods that do not specify their own limits.

Answer

PodDisruptionBudget

Answer

NetworkPolicy

Answer

ResourceQuota

Question 6

You need to view the logs of the previous (terminated) instance of a container in a pod. Which command should you use?

Accepted Answer

kubectl logs pod-name -p. `kubectl logs pod-name -p` (or `--previous`) retrieves the logs from the previous terminated container instance in the pod. This flag specifically targets the last container that exited, allowing you to debug crashes or restarts without needing to access the current running container.

Answer

kubectl describe pod pod-name | grep -A 10 'Last State'

Answer

kubectl logs pod-name --tail=100

Answer

kubectl logs pod-name -f

Question 7

A pod needs to run as a non-root user. Which securityContext field should be set to enforce this?

Accepted Answer

runAsNonRoot: true. Setting `runAsNonRoot: true` in the pod's securityContext explicitly enforces that the container must not run as the root user (UID 0). If the container image attempts to run as root, the Pod will fail to start, ensuring compliance with non-root security policies.

Answer

runAsGroup: 3000

Answer

runAsUser: 1000

Answer

readOnlyRootFilesystem: true

Question 8

Which command creates a TLS secret named 'tls-secret' using certificate file 'tls.crt' and key file 'tls.key'?

Accepted Answer

kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key. The `kubectl create secret tls` command is specifically designed to create a TLS secret from a certificate and key pair. The `--cert` and `--key` flags directly reference the PEM-encoded certificate file (`tls.crt`) and private key file (`tls.key`), which Kubernetes stores as `tls.crt` and `tls.key` data entries in the Secret object.

Answer

kubectl create secret docker-registry tls-secret --docker-server=...

Answer

kubectl create secret generic tls-secret --from-file=tls.crt --from-file=tls.key

Answer

kubectl create secret generic tls-secret --from-literal=tls.crt=...

Question 9

Which command attaches an ephemeral container to a running pod for debugging?

Accepted Answer

kubectl debug -it mypod --image=busybox --target=mycontainer. `kubectl debug` with `-it` and `--image=busybox` creates an ephemeral container in the target pod for interactive debugging, while `--target=mycontainer` attaches the ephemeral container to the same network and process namespace as the specified container. This is the only command that adds a new, temporary container to a running pod without restarting it, which is essential when the existing container lacks debugging tools or is in a crash loop.

Answer

kubectl attach mypod

Answer

kubectl exec -it mypod -- sh

Answer

kubectl logs mypod -c mycontainer

Question 10

A pod named 'test-pod' in namespace 'test' has a service account 'my-sa' attached. The service account has a RoleBinding to a Role that allows get/list pods. However, the pod cannot list pods. What is the most likely issue?

Accepted Answer

The RoleBinding is in a different namespace than the pod. RoleBindings in Kubernetes are namespace-scoped and can only grant permissions within the namespace where they are created. If the RoleBinding is in a different namespace than the pod, the service account 'my-sa' will not have the get/list pods permissions in the pod's namespace, causing the pod to fail when trying to list pods.

Answer

The pod is using the default service account instead of 'my-sa'

Answer

RoleBindings cannot grant access to list pods

Answer

The pod has automountServiceAccountToken set to false

Question 11

Which TWO of the following are valid ways to expose a Secret as an environment variable in a pod? (Select two.)

Accepted Answer

envFrom:
  - secretRef:
      name: db-secret. `envFrom` with a `secretRef` allows all key-value pairs from a Secret to be injected as environment variables into a container. This is a concise method to expose multiple secret entries without specifying each one individually.

Answer

volumes:
  - name: secret-volume
    secret:
      secretName: db-secret

Answer

env:
  - secretRef:
      name: db-secret

Answer

envFrom:
  - configMapRef:
      name: db-secret

Question 12

You need to grant a ServiceAccount 'my-sa' read-only access to pods in the 'test' namespace. Which RBAC YAML should you create?

Accepted Answer

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: test
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: test
  name: read-pods
subjects:
- kind: ServiceAccount
  name: my-sa
  namespace: test
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io. It creates a Role in the 'test' namespace with read-only verbs ('get', 'list', 'watch') on pods, and binds that Role to the ServiceAccount 'my-sa' in the same namespace via a RoleBinding. This grants the ServiceAccount scoped, namespace-level read-only access to pods, which matches the requirement precisely.

Answer

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
subjects:
- kind: ServiceAccount
  name: my-sa
  namespace: test
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Answer

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: test
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create", "delete"]

Answer

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader
  namespace: default
rules: ...
---
kind: RoleBinding ...

Question 13

A pod uses a liveness probe with exec command 'cat /tmp/healthy'. The file /tmp/healthy exists initially but is deleted by the application after 60 seconds. Which behavior will occur?

Accepted Answer

The liveness probe will fail and the container will be restarted. The liveness probe in Kubernetes periodically checks the health of a container by executing the specified command. When the file /tmp/healthy is deleted, the 'cat /tmp/healthy' command fails (returns non-zero exit code), causing the liveness probe to fail. After consecutive failures (default threshold is 3), kubelet restarts the container to attempt recovery, which is the expected behavior for a failing liveness probe.

Answer

The pod will continue running because the liveness probe only checks at startup

Answer

The pod will be deleted and recreated by the Deployment

Answer

The pod will be marked as NotReady and removed from the Service

Question 14

You are a platform engineer for a large e-commerce site. The application is deployed on a Kubernetes cluster with 10 worker nodes. Recently, a new deployment 'checkout' was rolled out, and soon after, the cluster experienced network latency and intermittent connectivity issues between services. The 'checkout' pods are configured with a liveness probe that makes an HTTP request to an internal health endpoint. Upon investigation, you find that the kubelet on several nodes is consuming high CPU, and the number of iptables rules has increased significantly. You suspect that the 'checkout' deployment's configuration is causing excessive churn in the network rules. Which aspect of the deployment configuration is most likely the root cause?

Accepted Answer

The liveness probe is configured with a very short periodSeconds (e.g., 1) and a low failureThreshold.. A liveness probe with a very short `periodSeconds` (e.g., 1) and a low `failureThreshold` causes the kubelet to send HTTP requests to the health endpoint at a high frequency. Each probe failure triggers a pod restart, which in turn causes the kubelet to update iptables rules (e.g., for kube-proxy and network policies) to reflect the new pod IP. This rapid churn of pod restarts leads to a significant increase in iptables rules and high CPU consumption on the kubelet, as it must repeatedly reconcile the network state.

Answer

The liveness probe uses a TCP socket check instead of an HTTP GET.

Answer

The deployment sets resource requests and limits that are too low, causing pod throttling.

Answer

The deployment uses a large number of environment variables, causing slow container startup.

Question 15

You have a Deployment named 'web' with label 'app: web'. You want to create a Service that exposes the Deployment on port 80 internally within the cluster. Which kubectl command achieves this?

Accepted Answer

kubectl expose deployment web --port=80. `kubectl expose deployment web --port=80` creates a ClusterIP Service that selects Pods based on the Deployment's label selector (app: web) and exposes port 80 internally within the cluster. This command directly maps the Deployment's Pods to a Service without requiring manual specification of the target port or protocol, defaulting to TCP.

Answer

kubectl create service clusterip web --tcp=80

Answer

kubectl create deployment web --image=nginx --expose --port=80

Answer

kubectl expose pod web --port=80