CKAD Practice Test 7 — 10 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