CKAD Practice Test 14 — 15 Questions

Question 1

A developer creates a headless Service named 'db' to discover all database pod IPs. The Service selects pods with label 'app: db'. The pods are assigned IPs 10.0.0.1, 10.0.0.2, and 10.0.0.3. When a client performs a DNS lookup for 'db', what will it receive?

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

Accepted Answer

All three pod IPs as separate A records. A headless Service (clusterIP: None) does not have a cluster IP. Instead, DNS queries for the Service name return A records for all pods matching the selector. Since the Service selects pods with label 'app: db', the DNS lookup for 'db' returns the three pod IPs (10.0.0.1, 10.0.0.2, 10.0.0.3) as separate A records, allowing direct pod-to-pod communication.

Answer

The IP of the first pod only

Answer

The cluster IP of the Service

Answer

A round-robin list of pod IPs

Question 2

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 3

A Pod is stuck in CrashLoopBackOff. You run 'kubectl logs mypod' and get no output. What is the most likely cause?

Accepted Answer

The application crashes before writing any logs.. When a Pod is in CrashLoopBackOff and `kubectl logs mypod` returns no output, the most likely cause is that the application crashes before it can write any logs to stdout/stderr. The container starts, runs briefly, and exits before the logging framework initializes, so no log data is captured by the container runtime.

Answer

The Pod is not ready yet.

Answer

The liveness probe is failing.

Answer

The container never started due to a missing image.

Question 4

You have a multi-stage Dockerfile. The first stage builds a binary using a large build image. The second stage copies the binary from the first stage into a minimal runtime image. Which Dockerfile instruction is used to copy artifacts from a previous stage?

Accepted Answer

COPY --from=builder /app/artifact /app/. In multi-stage Docker builds, the COPY instruction with the --from flag allows you to copy files from a named previous stage (e.g., 'builder') into the current stage. This is the standard Docker mechanism for selectively transferring build artifacts while discarding intermediate build dependencies, enabling a smaller final image.

Answer

ADD --from=builder /app/artifact /app/

Answer

ENTRYPOINT --from=builder /app/artifact /app/

Answer

CMD --from=builder /app/artifact /app/

Question 5

You are designing a health check strategy for a web application. Which TWO probe types should you configure to ensure that traffic is only sent to pods that are ready to serve?

Accepted Answer

Readiness probe. A Readiness probe (Option A) is specifically designed to determine whether a pod is ready to serve traffic. If the probe fails, the pod is removed from the Service's endpoints, ensuring traffic is only sent to pods that are ready. This directly fulfills the requirement of controlling traffic routing based on pod readiness.

Answer

TCP socket probe

Answer

HTTP GET probe

Answer

Liveness probe

Question 6

What is the primary purpose of an init container in a pod?

Accepted Answer

To perform initialization tasks such as waiting for a database to be ready. Init containers run to completion before the main application containers start, making them ideal for setup tasks like waiting for a database to be ready (e.g., using a `pg_isready` loop). They ensure the main container only runs when its prerequisites are satisfied, which is the core purpose defined in the Kubernetes documentation.

Answer

To provide a debugging shell into the pod

Answer

To handle traffic routing between services

Answer

To run a long-running process alongside the main container

Question 7

A developer creates a headless Service with 'clusterIP: None' for a StatefulSet. What is the primary purpose of using a headless Service?

Accepted Answer

To provide stable network identities and DNS records for each pod in the StatefulSet. A headless Service (with `clusterIP: None`) is used with StatefulSets to provide stable, unique network identities (DNS records) for each pod. Instead of a single virtual IP and round-robin load balancing, the headless Service returns A/AAAA records for each pod's individual IP address, enabling direct pod-to-pod communication based on stable hostnames like `pod-name.service-name.namespace.svc.cluster.local`.

Answer

To prevent DNS resolution of the service

Answer

To enable TLS termination at the service level

Answer

To provide load balancing across the pods

Question 8

Which command creates a Docker registry secret from an existing Docker config file?

Accepted Answer

kubectl create secret generic my-reg --from-file=.dockerconfigjson=config.json. `kubectl create secret generic` with `--from-file=.dockerconfigjson=config.json` creates a generic secret that stores the contents of an existing Docker config file (typically `~/.docker/config.json`) under the key `.dockerconfigjson`. This is the standard method for importing a pre-existing Docker configuration as a Kubernetes secret, which can then be used for image pull authentication.

Answer

kubectl create secret tls my-reg --cert=... --key=...

Answer

kubectl create secret docker-registry my-reg --docker-server=... --docker-username=...

Answer

kubectl create secret docker-registry my-reg --from-file=.dockerconfigjson=config.json

Question 9

Which TWO of the following commands create a ConfigMap named 'my-config' from a file named 'app.properties'? (Choose two.)

Accepted Answer

kubectl create configmap my-config --from-file=app.properties=app.properties. Options B, C, and E are all valid commands that create a ConfigMap named 'my-config' from the file 'app.properties'. Option B uses explicit key mapping (--from-file=app.properties=app.properties). Option C uses --from-env-file to read key-value pairs from the file. Option E uses the default --from-file behavior. Option A is incorrect because it adds an extra literal (--from-literal=extra=value). Option D is invalid syntax.

Answer

kubectl create configmap my-config --from-file=app.properties --from-literal=extra=value

Answer

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

Question 10

You need to run a batch job that processes 100 items. The job should be considered complete when all items are processed successfully. You want to run up to 10 pods concurrently. Which job configuration is correct?

Accepted Answer

.spec.completions: 100, .spec.parallelism: 10. It sets `.spec.completions` to 100 (the total number of items to process) and `.spec.parallelism` to 10 (the maximum number of pods running concurrently). This ensures the Job runs pods in parallel up to the specified limit until all 100 completions are achieved, matching the requirement of processing 100 items with up to 10 concurrent pods.

Answer

.spec.completions: 10, .spec.parallelism: 100

Answer

.spec.backoffLimit: 100, .spec.parallelism: 10

Answer

.spec.completions: 100, .spec.parallelism: 1

Question 11

You want to expose a Deployment 'app' externally on port 30080 on each node. What service type should you use?

Accepted Answer

NodePort. A NodePort service exposes the Deployment on a static port (30080) on each node's IP address, making it accessible externally via <NodeIP>:30080. This is the correct choice because the requirement explicitly asks to expose the app on port 30080 on each node, which matches the NodePort service type's behavior of opening a specific port on every node in the cluster.

Answer

LoadBalancer

Answer

ExternalName

Answer

ClusterIP

Question 12

A container runs as root (UID 0) but the security policy requires the container to run as non-root user 1000. Which pod security context setting should be added?

Accepted Answer

runAsUser: 1000. `runAsUser: 1000` explicitly sets the container's user ID to 1000, ensuring the container process runs as a non-root user. This directly satisfies the security policy requirement to run as UID 1000, overriding the default root (UID 0) behavior.

Answer

runAsNonRoot: true

Answer

fsGroup: 1000

Answer

privileged: false

Question 13

You need to expose a Deployment named 'web' on port 80 internally within the cluster. Which command creates the appropriate Service?

Accepted Answer

kubectl expose deployment web --port=80. The `kubectl expose deployment web --port=80` command creates a Service of type ClusterIP by default, which exposes the Deployment's pods on port 80 internally within the cluster. This matches the requirement to expose the 'web' Deployment on port 80 internally without specifying a target port, as it defaults to the container's port defined in the Deployment.

Answer

kubectl create service clusterip web --tcp=80:80

Answer

kubectl apply -f service.yaml

Answer

kubectl run web --image=nginx --port=80

Question 14

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 pod is in CrashLoopBackOff due to OOMKilled, meaning the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. The most appropriate action is to increase the memory limit in the pod's container resource specification, as this directly addresses the root cause—insufficient memory allocation—without requiring a full redeployment or affecting other workloads.

Answer

Delete and recreate the pod to clear the crash loop

Answer

Increase the CPU request for the container

Answer

Delete the namespace and redeploy all workloads

Question 15

You have a Job that runs a batch process. The Job YAML is as follows:

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-job
spec:
  parallelism: 4
  completions: 12
  backoffLimit: 2
  template:
    spec:
      containers:
      - name: worker
        image: myapp:latest
      restartPolicy: Never

If one pod fails after 3 successful completions, and the Job has already completed 7 successes, how many pods will be running at that point? Assume no other failures.

Accepted Answer

4. The Job is configured with parallelism: 4, meaning up to 4 pods run concurrently. At the moment a pod fails after 3 successful completions and the Job has already achieved 7 successes, the Job controller will still be running pods to reach the target of 12 completions. Since the failure does not reduce the number of running pods below the parallelism limit, and no other failures have occurred, the Job will continue to run 4 pods simultaneously.

Answer

3

Answer

7

Answer

5