CKAD Practice Test 11 — 15 Questions

Question 1

A Service of type LoadBalancer is created but the external IP remains pending. What is the most likely reason?

Accepted Answer

The cluster does not have a load balancer controller. A Service of type LoadBalancer in Kubernetes requires an external load balancer controller (e.g., cloud-controller-manager for AWS, Azure, GCP, or MetalLB for on-premises) to provision and assign the external IP. If no such controller is running in the cluster, the external IP remains in 'pending' state indefinitely because Kubernetes itself does not implement load balancer logic. This is the most common reason for a stuck pending external IP.

Answer

The service selector does not match any pods

Answer

The service port is already in use

Answer

The namespace has a NetworkPolicy blocking traffic

Question 2

What is the purpose of a readiness probe in Kubernetes?

Accepted Answer

To control whether the pod receives traffic from Services. A readiness probe determines whether a container is ready to serve traffic. If the probe fails, the pod is removed from the endpoints of Services, thus it does not receive traffic. Option B describes a startup probe (to delay liveness/readiness probes for slow-starting containers). Option C describes resource monitoring, not a probe. Option D describes a liveness probe, which restarts the container if unhealthy.

Answer

To delay the start of other probes for slow-starting containers

Answer

To monitor resource usage of the container

Answer

To restart the container if it becomes unhealthy

Question 3

A pod is running with the following SecurityContext:
securityContext:
  runAsUser: 1000
  runAsGroup: 2000
  fsGroup: 3000
What UID and GID does the process inside the container use?

Accepted Answer

UID 1000, GID 2000. The `runAsUser` and `runAsGroup` fields in the Pod's SecurityContext directly set the UID and GID for the container's main process. Here, `runAsUser: 1000` sets the process UID to 1000, and `runAsGroup: 2000` sets the process GID to 2000. The `fsGroup: 3000` field only applies to the group ownership of mounted volumes, not to the process's primary GID.

Answer

UID 1000, GID 3000

Answer

UID 0, GID 2000

Answer

UID 3000, GID 2000

Question 4

A pod uses a ServiceAccount 'my-sa' with a RoleBinding that grants get and list on pods. The pod makes an API call to list pods in its own namespace. Which RBAC resource is necessary?

Accepted Answer

A RoleBinding that binds the Role to the ServiceAccount. The pod uses a ServiceAccount 'my-sa' and the API call is to list pods in its own namespace. A RoleBinding binds a Role (which contains the rules) to a ServiceAccount within a specific namespace, granting the permissions only in that namespace. Since the operation is namespace-scoped and the Role already has the necessary get and list rules, a RoleBinding is the minimal and correct RBAC resource to associate the Role with the ServiceAccount.

Answer

A Role with the appropriate rules

Answer

A ClusterRoleBinding that binds the ClusterRole to the ServiceAccount

Answer

A ClusterRole with the same rules

Question 5

A pod's container needs to run as non-root user with UID 1000 and ensure its filesystem is read-only. Which SecurityContext settings achieve this?

Accepted Answer

spec:
  securityContext:
    runAsUser: 1000
    runAsNonRoot: true
  containers:
  - name: app
    securityContext:
      readOnlyRootFilesystem: true. Ly sets runAsUser and runAsNonRoot at the pod level to enforce non-root execution with UID 1000, and readOnlyRootFilesystem at the container level, which is the correct placement for that field. The other options either use invalid fields (runAsRoot), omit runAsNonRoot, or incorrectly place readOnlyRootFilesystem at the pod level.

Answer

securityContext:
  runAsNonRoot: true
  runAsRoot: false
  readOnlyRootFilesystem: true

Answer

securityContext:
  runAsGroup: 1000
  readOnlyRootFilesystem: true

Answer

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true

Question 6

A pod is running but not responding to traffic. You suspect the application inside the container is unhealthy but the pod is still marked as 'Running'. Which probe should be configured to remove the pod from the service's endpoints automatically?

Accepted Answer

Readiness probe. A Readiness probe determines whether a container is ready to accept traffic. If the probe fails, Kubernetes removes the pod's IP address from the endpoints of all Services that match the pod's labels, effectively stopping traffic from reaching the pod while it remains in the Running state. This is the correct probe for removing an unhealthy pod from Service endpoints without terminating it.

Answer

Resource limits

Answer

Startup probe

Answer

Liveness probe

Question 7

Which kubectl command creates a ConfigMap named 'app-config' from a file called 'config.properties'?

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. The `kubectl create configmap` command with the `--from-file` flag directly creates a ConfigMap from the contents of a specified file, using the filename as the key and the file content as the value. This is the standard method for creating a ConfigMap from a single file like 'config.properties'.

Answer

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

Answer

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

Answer

kubectl apply -f config.properties

Question 8

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The 'OOMKilled' status indicates the pod's container was terminated because it exceeded its memory limit. Since the pod ran successfully for days, a gradual memory leak or increased workload likely caused the usage to spike past the configured limit. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory demand without being killed, resolving the CrashLoopBackOff.

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Answer

Increase the CPU request for the container

Question 9

A DevOps engineer wants to deploy a logging sidecar container that reads log files from the main application container. Which volume type should be used to share files between the two containers?

Accepted Answer

emptyDir. An emptyDir volume is the correct choice because it provides a shared, ephemeral storage space that is created when a Pod is assigned to a node and exists as long as that Pod is running. Both the main application container and the sidecar container can mount the same emptyDir volume at different mount paths, allowing the sidecar to read log files written by the main container. This volume type is ideal for sharing files between containers in the same Pod without requiring persistent storage.

Answer

persistentVolumeClaim

Answer

configMap

Answer

hostPath

Question 10

Which of the following are valid methods to perform a blue-green deployment? (Choose TWO)

Accepted Answer

Create two Deployments for blue and green, and update the Service selector to point to the new version. Blue-green deployment in Kubernetes typically involves running two environments (blue and green) side-by-side and switching traffic from one to the other. Option A directly implements this by maintaining two separate Deployments (blue and green) and updating the Service selector to point to the new version. Option D uses an Ingress resource that can route traffic to different Services, each pointing to a different version of the application; by updating the Ingress rules, traffic can be switched from blue to green. Option B describes a rolling update, not blue-green. Option C is a rolling update using a single Deployment and changing the container image. Option E is a delete/recreate strategy, not blue-green.

Answer

Create a single Deployment and update the pod labels to match the Service selector

Answer

Use a single Deployment and change the container image, then perform a rolling update

Answer

Delete the old Deployment and create a new one

Question 11

An administrator wants to implement Pod Security Admission (PSA) to enforce the 'restricted' policy for pods in the 'secure' namespace, but allow certain pods to use privileged containers by applying an exemption label. Which three steps are required? (Choose three.)

Accepted Answer

Use 'pod-security.kubernetes.io/audit=restricted' to log violations without enforcement.. Setting the audit label to 'restricted' logs violations, which is a common initial step to assess compliance before enforcing the policy. Option C is correct because creating a ServiceAccount and labeling it with 'pod-security.kubernetes.io/enforce=privileged' exempts pods using that ServiceAccount from the restricted policy, allowing them to run privileged containers. Option E is correct because setting the namespace label 'pod-security.kubernetes.io/enforce=restricted' enforces the restricted policy on all pods in that namespace that are not exempted. Option B is not required because the PodSecurity feature gate is enabled by default in Kubernetes v1.23+. Option D is incorrect because PSA uses security context validation, not a custom runtime.

Answer

Enable the PodSecurity feature gate on the API server and kubelet.

Answer

Install a custom container runtime that supports privilege escalation.

Question 12

You want to perform a canary deployment of a new version of your application. You create a Deployment named 'app-canary' with 1 replica and label 'version: canary'. The existing stable Deployment 'app-stable' has 3 replicas and label 'version: stable'. Both Deployments have the selector 'app: myapp'. You have a Service 'app-service' with selector 'app: myapp, track: stable'. How can you route traffic to the canary?

Accepted Answer

Add label 'track: canary' to the canary pod template and set the Service selector to 'app: myapp, track: canary'. To route traffic to the canary, the Service selector must match the canary pods' labels. The current Service selector is 'app: myapp, track: stable', but the canary pods have 'app: myapp, version: canary'. Option B correctly adds the label 'track: canary' to the canary pod template and changes the Service selector to 'app: myapp, track: canary'. This makes the Service select only the canary pods, routing all traffic to the canary. Note: This removes the stable pods from the Service, but among the given choices, B is the only correct approach to achieve traffic to the canary.

Answer

Use a different Service for canary with selector 'app: myapp, track: canary' and keep the original Service unchanged

Answer

Modify the Service selector to 'app: myapp' and rely on the 'version' label to differentiate

Answer

Change the canary Deployment's selector to 'version: canary' and update the Service selector to include 'version: canary'

Question 13

A ClusterIP service named 'db-service' in namespace 'data' is not reachable from a pod in the same namespace. The pod's /etc/resolv.conf shows 'search data.svc.cluster.local svc.cluster.local cluster.local'. Using the pod, which command tests DNS resolution for the service?

Accepted Answer

nslookup db-service.data.svc.cluster.local. `nslookup` is a standard DNS lookup tool that queries the cluster's DNS server (CoreDNS/kube-dns) for the fully qualified domain name (FQDN) of the service. The FQDN `db-service.data.svc.cluster.local` matches the search domains in the pod's `/etc/resolv.conf`, so `nslookup` will resolve the service's ClusterIP, confirming DNS is working. This directly tests DNS resolution, which is the root cause when a service is unreachable by name.

Answer

dig db-service.data.svc.cluster.local

Answer

ping db-service

Answer

curl http://db-service:3306

Question 14

Which TWO statements about kubectl apply vs kubectl create are correct? (Select two)

Accepted Answer

kubectl apply can update existing resources; kubectl create cannot.. The correct options are the statement about kubectl apply storing the last applied configuration in an annotation (the first option) and option C. The annotation `kubectl.kubernetes.io/last-applied-configuration` enables declarative updates with `kubectl apply`. Option C is correct because `kubectl apply` can update existing resources declaratively, while `kubectl create` will fail if the resource already exists. Option A is incorrect because `kubectl create` does not support `--dry-run=client`; only `kubectl apply` does. Options B, D, and E are incorrect as explained.

Answer

Both commands support the --dry-run=client flag.

Answer

Both commands require a full YAML manifest file.

Answer

kubectl create is the recommended way to manage production resources.

Answer

Both commands can only be used to create resources, not update.

Question 15

You have a Deployment 'app' with the following strategy configuration: 'type: RollingUpdate', 'rollingUpdate: {maxSurge: 0, maxUnavailable: 1}'. You update the container image. What is the behavior during the update?

Accepted Answer

One old pod is terminated, then a new pod is created, repeating until all pods are updated.. With `maxSurge: 0` and `maxUnavailable: 1`, the RollingUpdate strategy ensures that during the update, no extra pods beyond the desired replica count are created (surge is zero), and at most one pod can be unavailable at any time. The Deployment controller first terminates an old pod (making one unavailable), then creates a new pod to replace it, repeating this process until all pods are updated. This guarantees a controlled, sequential rollout with minimal disruption.

Answer

A new pod is created first, then the oldest pod is terminated.

Answer

Two old pods are terminated at a time, while new pods are created.

Answer

All old pods are terminated simultaneously, then new pods are created.