CKAD Practice Test 3 — 30 Questions

Question 1

A developer wants to containerize a Node.js application. The Dockerfile should first copy only package.json and package-lock.json, run npm install, then copy the rest of the source code. Which Dockerfile best achieves this?

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

Accepted Answer

COPY package*.json /app/
RUN npm install
COPY . /app/. It first copies only package.json and package-lock.json (using a wildcard pattern), runs `npm install` to leverage Docker's layer caching, and then copies the rest of the source code. This ensures that subsequent builds only re-run `npm install` when the dependency files change, not on every source code modification, which is a best practice for efficient Docker builds.

Answer

COPY . /app
RUN npm install

Answer

ADD package*.json /app/
RUN npm install
ADD . /app/

Answer

ADD . /app
RUN npm install

Question 2

Which TWO commands can be used to create a Secret from a file? (Select 2)

Accepted Answer

kubectl create secret generic mysecret --from-file=key=file.txt. Both options A and E are valid commands to create a Secret from a file. Option A uses `--from-file` to read file contents and store them under a specified key. Option E uses `--from-env-file` to parse a file with key=value pairs and create a Secret for environment variables. Option C is incorrect for this question because `kubectl apply -f secret.yaml` applies a YAML manifest that defines a Secret, but it does not create a Secret directly from a file's contents in the same way as the `kubectl create secret` commands. The question asks for two commands that create a Secret from a file, and both A and E meet that criterion.

Answer

kubectl create configmap mysecret --from-file=file.txt

Answer

kubectl apply -f secret.yaml where secret.yaml contains data fields

Answer

kubectl create secret tls mysecret --cert=file.txt

Question 3

A pod needs to run as a non-root user with UID 1000. Which SecurityContext field should be set?

Accepted Answer

runAsUser: 1000. The `runAsUser` field in the PodSecurityContext or container SecurityContext sets the user ID (UID) under which the container's main process runs. Setting `runAsUser: 1000` ensures the container runs as a non-root user with UID 1000, meeting the requirement. This field directly controls the effective UID of the process, overriding the default root (UID 0).

Answer

runAsGroup: 1000

Answer

runAsNonRoot: true

Answer

fsGroup: 1000

Question 4

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 with an OOMKilled message, which indicates the container is being terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it has exceeded its memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause.

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Question 5

You have a Deployment named 'api' with 3 replicas. You need to ensure that new pods are not added to the Service's endpoints until the application is ready to serve traffic. Which probe configuration should you add to the pod spec?

Accepted Answer

Readiness probe. A Readiness probe is the correct choice because it controls whether a pod is added to a Service's endpoints. Kubernetes will only mark a pod as Ready when the probe succeeds, and only Ready pods receive traffic from the Service. This ensures new pods are not added until the application is ready to serve traffic.

Answer

No probe is needed; pods are automatically added when running

Answer

Startup probe

Answer

Liveness probe

Question 6

You have a Deployment running a web server that takes 30 seconds to initialize. You want to ensure that the load balancer does not send traffic to the pod until it is ready. Which probe should you configure?

Accepted Answer

Readiness probe. A Readiness probe is the correct choice because it determines whether a Pod is ready to serve traffic. In this scenario, the web server takes 30 seconds to initialize, so a Readiness probe (e.g., an HTTP GET on the application's health endpoint) will prevent the Service (and thus the load balancer) from sending requests until the probe succeeds, ensuring zero traffic is routed to an uninitialized Pod.

Answer

Resource limit

Answer

Startup probe

Answer

Liveness probe

Question 7

You have a Deployment with multiple replicas. You want to expose it via a Service that has a stable IP address and is accessible from outside the cluster on a static port on each node. Which Service type should you use?

Accepted Answer

NodePort. A NodePort Service type exposes the application on a static port (in the range 30000-32767) on every node's IP address, making it accessible from outside the cluster. This satisfies the requirement for a stable IP (the node's IP) and a static port on each node, while also providing a stable ClusterIP for internal use.

Answer

LoadBalancer

Answer

ClusterIP

Answer

ExternalName

Question 8

Which of the following is the correct way to set an environment variable 'APP_COLOR' from a ConfigMap key 'color'?

Accepted Answer

env:
  - name: APP_COLOR
    valueFrom:
      configMapKeyRef:
        name: my-config
        key: color. It uses the `configMapKeyRef` field under `valueFrom` in the `env` array to inject a specific key from a ConfigMap as an environment variable. This is the standard Kubernetes syntax for referencing a single key from a ConfigMap, where `name` specifies the ConfigMap object and `key` specifies the key within that ConfigMap whose value will be assigned to the environment variable `APP_COLOR`.

Answer

env:
  - name: APP_COLOR
    valueFrom:
      configMapRef:
        name: my-config
        key: color

Answer

envFrom:
  - configMapKeyRef:
      name: my-config
      key: color

Answer

env:
  - name: APP_COLOR
    value: "configMap.color"

Question 9

You are using a canary deployment strategy with Deployments and Services. You have a stable version (v1) and a canary version (v2). Both Deployments have the label 'app: myapp'. The Service selector is 'app: myapp'. How can you route a small percentage of traffic to the canary?

Accepted Answer

Set the canary Deployment replicas to 1 and the stable to 9, and keep the Service selector as 'app: myapp'. The Service selector 'app: myapp' matches both Deployments, and by setting the canary to 1 replica and the stable to 9, the Service's round-robin load balancing (by default) distributes roughly 10% of traffic to the canary Pods and 90% to the stable Pods. This is a simple, native Kubernetes canary pattern that requires no additional components like Ingress controllers.

Answer

Set both Deployments to 10 replicas and use an Ingress with a canary weight annotation (e.g., canary-weight: '10')

Answer

Set the canary Deployment replicas to 1 and the stable to 9, and update the Service selector to include version: v2

Answer

Set the canary Deployment replicas to 10 and the stable to 1

Question 10

A developer creates a Dockerfile with the following content:
FROM alpine:3.18
COPY app.sh /app.sh
RUN chmod +x /app.sh
CMD ["/app.sh"]
They want to override the command to run '/app.sh --debug' when deploying the container in Kubernetes. Which of the following pod spec fields should they use?

Accepted Answer

spec.containers[].args. In Kubernetes, the `args` field overrides the CMD instruction from the Docker image. The Dockerfile's `CMD ["/app.sh"]` is replaced by `args: ["--debug"]`, which is appended to the ENTRYPOINT (defaulting to `/bin/sh -c` if not set, but here the ENTRYPOINT is `/app.sh` from the image's implicit ENTRYPOINT? Actually, the image has no explicit ENTRYPOINT, so the default is `/app.sh` from CMD? Wait — the Dockerfile has no ENTRYPOINT, so the container's entrypoint is the default `/bin/sh -c`? No, in Kubernetes, if no `command` is set, the image's ENTRYPOINT is used; if no ENTRYPOINT, then the image's CMD is used as the command. Here, the image has CMD `["/app.sh"]` and no ENTRYPOINT, so the container's command is `/app.sh`. Setting `args: ["--debug"]` will append `--debug` to that command, resulting in `/app.sh --debug`.

Answer

spec.containers[].entrypoint

Answer

spec.containers[].command

Answer

spec.command

Question 11

You apply the following Ingress manifest:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

The Ingress controller logs show a 404 error when accessing 'http://example.com/api'. The service 'api-service' exists and is reachable via ClusterIP. What is the most likely cause?

Accepted Answer

The IngressClass 'nginx' is not installed or configured. The Ingress controller logs a 404 error because the Ingress resource references `ingressClassName: nginx`, but the NGINX Ingress Controller is not installed or its IngressClass resource is not configured in the cluster. Without a matching IngressClass, the controller ignores this Ingress, so no routing rules are applied, and the default backend (if any) or the controller itself returns a 404. The service exists and is reachable, but the Ingress controller never processes the rules.

Answer

The service 'api-service' is in a different namespace

Answer

The service port (80) does not match the container port

Answer

The path '/api' should be pathType: Exact

Question 12

A Secret named 'db-secret' of type Opaque contains a key 'password'. How do you reference this key as an environment variable named 'DB_PASSWORD' in a pod spec?

Accepted Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password. It uses the `secretKeyRef` field under `valueFrom` to reference a specific key from a Kubernetes Secret of type Opaque. The `secretKeyRef` is the proper mechanism to inject a single key from a Secret as an environment variable, mapping the key 'password' to the environment variable name 'DB_PASSWORD'.

Answer

env:
  - name: DB_PASSWORD
    valueFrom:
      configMapKeyRef:
        name: db-secret
        key: password

Answer

envFrom:
  - secretRef:
      name: db-secret
      key: password

Answer

env:
  - name: DB_PASSWORD
    value: "db-secret.password"

Question 13

What is the purpose of a .dockerignore file in a Docker build context?

Accepted Answer

It excludes files and directories from being sent to the Docker daemon during the build. The .dockerignore file, when placed in the Docker build context, instructs the Docker CLI to exclude specified files and directories from the tar archive that is sent to the Docker daemon during the `docker build` command. This reduces the build context size, speeds up the build, and prevents sensitive files (e.g., .env, .git) from being included in the image layers.

Answer

It limits the number of layers in the final image

Answer

It defines environment variables for the container

Answer

It specifies the order of layers in the Docker image

Question 14

You need to create a Job that runs a single task to completion. Which kubectl command correctly creates a Job named 'data-processor' that runs the image 'myapp/processor:1.0'?

Accepted Answer

kubectl create job data-processor --image=myapp/processor:1.0. `kubectl create job` is the dedicated command to create a Job resource, which runs a pod to completion without restarting the container after success. The Job controller ensures the pod runs exactly once, making it ideal for batch processing tasks.

Answer

kubectl create deployment data-processor --image=myapp/processor:1.0

Answer

kubectl run data-processor --image=myapp/processor:1.0 --restart=Never

Answer

kubectl create cronjob data-processor --image=myapp/processor:1.0

Question 15

You want to ensure your application shuts down gracefully when a pod is terminated. The application needs 30 seconds to clean up. Which field should you set in the pod spec?

Accepted Answer

terminationGracePeriodSeconds: 30. `terminationGracePeriodSeconds` defines the time Kubernetes waits for a pod to shut down gracefully after sending a SIGTERM signal. Setting it to 30 seconds gives the application the required cleanup window before a SIGKILL is forced.

Answer

spec.containers[].livenessProbe.initialDelaySeconds: 30

Answer

spec.containers[].lifecycle.preStop.exec.command: ["sleep", "30"]

Answer

spec.containers[].readinessProbe.periodSeconds: 30

Question 16

A Pod has two containers: one with a liveness probe that fails after 30 seconds. The restartPolicy is 'Never'. What state will the Pod be in after the liveness probe fails?

Accepted Answer

Failed. When a liveness probe fails, Kubernetes terminates the container and, because the restartPolicy is 'Never', does not restart it. The Pod transitions to the 'Failed' phase, as the container has exited with a non-zero exit code and will not be recreated. This is the expected behavior for a Pod with a single container that fails its health check under a 'Never' restart policy.

Answer

Running

Answer

Unknown

Answer

CrashLoopBackOff

Question 17

Which Service type is used to expose a service externally on a static port on each worker node?

Accepted Answer

NodePort. A NodePort service exposes the application on a static port (in the range 30000-32767) on every worker node's IP address. This allows external traffic to reach the service by targeting any node's IP and the assigned NodePort, making it the correct choice for exposing a service externally on a static port per node.

Answer

ExternalName

Answer

ClusterIP

Answer

LoadBalancer

Question 18

You are a platform engineer at a company that runs a microservices architecture on Kubernetes. The application consists of a frontend service (Node.js), a backend API (Go), and a PostgreSQL database. All components are deployed in the same namespace 'production'. Recently, the backend API has been experiencing intermittent 503 errors from the frontend. The backend API Pods have CPU limits set to 500m and memory limits to 256Mi. The backend API exposes metrics at /metrics and has a liveness probe (HTTP GET /healthz) and a readiness probe (HTTP GET /ready). You notice that during traffic spikes, the backend API Pods are restarted frequently. You examine the metrics and see that memory usage spikes to 250Mi during high load. What is the most likely cause of the restarts and 503 errors?

Accepted Answer

The memory limit is set too low; the container is being OOMKilled during traffic spikes.. The backend API Pods are being restarted frequently because the memory limit of 256Mi is too close to the observed memory usage of 250Mi during traffic spikes. When memory usage hits the limit, the Linux kernel's OOM killer terminates the container (OOMKilled), causing the Pod to restart. This restart leads to temporary unavailability, which the frontend sees as 503 errors.

Answer

The liveness probe is misconfigured and should use a TCP check instead.

Answer

The readiness probe is failing because the application is not ready, but the liveness probe keeps it alive.

Answer

The CPU limit is too low, causing the container to be throttled and timeout.

Question 19

You are debugging a pod that is running but not responding to network requests on port 8080. You suspect the application inside the container is faulty. You need to run an interactive shell inside the container to inspect the process. Which command should you use?

Accepted Answer

kubectl exec -it pod-name -- /bin/sh. `kubectl exec -it pod-name -- /bin/sh` opens an interactive shell inside the running container, allowing you to inspect processes, check network listeners, and debug the application directly. This is the standard command for gaining shell access to a container in Kubernetes.

Answer

kubectl describe pod pod-name

Answer

kubectl logs pod-name -f

Answer

kubectl debug -it pod-name --image=busybox

Question 20

A pod is running but not receiving traffic from a Service. The readiness probe is failing. What is the likely effect on the pod?

Accepted Answer

The pod will remain running but will not be included in the Service's endpoints. When a readiness probe fails, Kubernetes marks the pod as not ready. The pod continues running, but the associated Service removes the pod's IP from its Endpoints (or EndpointSlice) list. This ensures the Service does not route traffic to a pod that is not prepared to handle requests, while allowing the pod to remain alive for debugging or other internal operations.

Answer

The pod will be marked as CrashLoopBackOff

Answer

The pod will be terminated and restarted

Answer

The pod will be evicted from the node