CKAD Practice Test 29 — 15 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 THREE commands can be used to list the endpoints of a Service named 'my-svc'?

Accepted Answer

kubectl describe svc my-svc. `kubectl describe svc my-svc` displays detailed information about the service, including the list of endpoints (IP:Port pairs) that the service routes traffic to. Options D and E are also correct because `kubectl get ep my-svc` and `kubectl get endpoints my-svc` are equivalent commands that directly list the Endpoints resource associated with the service. All three commands provide the endpoint information.

Answer

kubectl get networkpolicy

Answer

kubectl get pods -l app=my-svc

Question 3

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 4

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 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

You run 'kubectl apply -f deployment.yaml' and later 'kubectl replace -f deployment.yaml' on the same file. What is the difference?

Accepted Answer

apply merges changes, replace replaces the entire resource. 'kubectl apply' performs a declarative three-way merge between the last-applied-configuration annotation, the live object, and the new file, so it only changes fields that differ. 'kubectl replace' performs a full replacement of the resource with the contents of the file, overwriting the entire object and failing if the resource does not exist.

Answer

apply is used for Deployments only, replace for any resource

Answer

apply requires --record flag, replace does not

Answer

apply creates, replace updates

Question 9

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 10

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 11

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 12

You have a Dockerfile with 'CMD ["nginx", "-g", "daemon off;"]'. A developer wants to run the container with a different command: 'nginx -t'. How should they run the container?

Accepted Answer

docker run nginx nginx -t. `docker run nginx nginx -t` passes `nginx -t` as the command to override the Dockerfile's `CMD`. The CMD instruction in the Dockerfile is replaced entirely by the command-line arguments after the image name, so the container runs `nginx -t` instead of `nginx -g 'daemon off;'`. This is the standard Docker behavior for overriding the default command.

Answer

docker run nginx ["nginx", "-t"]

Answer

docker run nginx CMD nginx -t

Answer

docker run --entrypoint nginx -t nginx

Question 13

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 14

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 15

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