CKAD Application Design and Build Practice Test 8 — 15 Questions

Question 1

You are writing a Dockerfile and want to ensure that the CMD instruction is overridable when running the container, but the ENTRYPOINT should not be easily overridden. Which combination should you use?

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

Accepted Answer

ENTRYPOINT ["myapp"]; CMD ["--help"]. It uses the exec form for ENTRYPOINT, which makes ENTRYPOINT the main command that cannot be easily overridden by simply appending arguments to `docker run`. The CMD instruction provides default arguments that can be overridden by passing arguments to `docker run`. This satisfies both requirements: ENTRYPOINT is not easily overridden, and CMD is overridable. Option D lacks a CMD instruction, so there is nothing to override; arguments passed to `docker run` become arguments to ENTRYPOINT, not a replacement of CMD. Option B uses only CMD, so ENTRYPOINT defaults to the shell and is easily overridden via --entrypoint. Option C uses shell form for ENTRYPOINT, which causes CMD and runtime arguments to be ignored, so CMD cannot be overridden — that violates the requirement.

Answer

CMD ["myapp", "--help"]

Answer

ENTRYPOINT myapp; CMD --help

Answer

ENTRYPOINT ["myapp"]

Question 2

You have a Deployment with 3 replicas. You need to perform a rolling update with a 10-second delay between each Pod replacement to ensure stability. Which kubectl command is correct?

Accepted Answer

kubectl set image deployment/myapp myapp=myapp:v2 --record. To achieve a 10-second delay between Pod replacements during a rolling update, you must set `spec.minReadySeconds: 10` in the Deployment. The `kubectl set image` command only updates the container image and triggers the rolling update; it does not introduce any delay. The correct approach would be to first patch the Deployment to set `minReadySeconds` (e.g., `kubectl patch deployment myapp -p '{"spec":{"minReadySeconds":10}}'`) and then update the image (e.g., `kubectl set image deployment/myapp myapp=myapp:v2`). Since neither option provides both steps, and no single command can enforce this delay, the question as written has no valid correct answer.

Answer

kubectl rollout restart deployment/myapp

Answer

kubectl edit deployment/myapp and change the image manually

Answer

kubectl patch deployment/myapp -p '{"spec":{"template":{"spec":{"containers":[{"name":"myapp","image":"myapp:v2"}]}}}}'

Question 3

Which TWO statements about init containers are true?

Accepted Answer

Init containers can have resource limits different from app containers.. Init containers are specialized containers that run before any app containers in a Pod start. They are designed to perform setup tasks, such as waiting for a service to be ready or initializing data. Because they run sequentially and must complete successfully before app containers begin, they can have their own resource limits and requests, which are independent from those of the app containers. This allows you to allocate different CPU/memory resources for initialization tasks without affecting the app containers' resource guarantees.

Answer

Init containers can run in parallel with each other.

Answer

Init containers are restarted if they fail, using the same restart policy as the app containers.

Answer

Init containers must use the same container image as the app containers.

Question 4

Which TWO options are valid ways to tag an image when building with Docker?

Accepted Answer

docker tag myapp:1.0 myrepo/myapp:1.0. The `docker tag` command explicitly creates a new tag referencing an existing image, allowing you to assign a new name and tag (e.g., `myrepo/myapp:1.0`) to an already built image (e.g., `myapp:1.0`). This is a standard way to prepare an image for pushing to a registry without rebuilding.

Answer

docker build --name myapp:1.0 .

Answer

docker commit myapp:1.0 myrepo/myapp:1.0

Answer

docker run -t myapp:1.0 myrepo/myapp:1.0

Question 5

Which THREE are valid patterns for multi-container Pods?

Accepted Answer

Ambassador. (Ambassador) is correct because the Ambassador pattern uses a proxy container that mediates network traffic between the main application container and external services, allowing the main container to connect to localhost while the ambassador handles protocol translation or service discovery. This is a valid multi-container Pod design pattern in Kubernetes, commonly implemented with tools like Envoy or a custom sidecar proxy.

Answer

Init

Answer

Replicator

Question 6

A developer runs 'kubectl run mypod --image=nginx --restart=Never' and the pod is created. However, when the container exits, the pod terminates. Which restart policy ensures the pod does NOT restart after completion?

Accepted Answer

Never. The `--restart=Never` flag sets the pod's restart policy to `Never`, which means the kubelet will not restart the container when it exits. Since the pod was created with `kubectl run` and `--restart=Never`, it runs as a standalone pod (not managed by a controller), and when the container exits, the pod enters the `Succeeded` or `Failed` phase and is not restarted. This is the only restart policy that guarantees the pod does not restart after completion.

Answer

Always

Answer

OnFailure

Answer

AlwaysFail

Question 7

You need to run a batch job that processes a queue and must ensure exactly 5 pods run successfully in parallel. Which Job configuration field should be set?

Accepted Answer

spec.parallelism: 5. `spec.parallelism` controls the maximum number of Pods that can run concurrently for a Job. Setting `parallelism: 5` ensures exactly 5 Pods run in parallel, which matches the requirement to process a queue with five simultaneous workers.

Answer

spec.backoffLimit: 5

Answer

spec.ttlSecondsAfterFinished: 5

Answer

spec.completions: 5

Question 8

A CronJob is configured with 'concurrencyPolicy: Forbid'. What happens if the scheduled time arrives while the previous job is still running?

Accepted Answer

The new job is skipped until the next scheduled time. When `concurrencyPolicy: Forbid` is set on a CronJob, Kubernetes ensures that no new Job is created if the previous Job is still running. The CronJob controller checks the status of the most recent Job; if it has not completed, the scheduled execution is skipped entirely, and the next run occurs at the next scheduled time. This prevents overlapping executions, which is critical for workloads that must not run concurrently.

Answer

The new job starts immediately, running concurrently

Answer

The running job is terminated and the new job starts

Answer

The CronJob enters an error state

Question 9

Consider the following partial Dockerfile:
FROM alpine:3.18 AS builder
RUN apk add --no-cache curl
COPY src /app/src
RUN make /app/bin

FROM alpine:3.18
COPY --from=builder /app/bin /app/bin
CMD ["/app/bin"]
What is the primary benefit of this multi-stage build?

Accepted Answer

Reduced final image size by excluding build dependencies. Multi-stage builds allow copying only the compiled binary from the builder stage, leaving behind build tools and intermediate files, resulting in a smaller final image.

Answer

Faster builds because the builder stage runs in parallel

Answer

Automatic caching of the builder stage

Answer

Improved security by running the builder as a non-root user

Question 10

A pod named 'app' has a container that logs to stdout. You want to add a sidecar container that streams these logs to a centralized logging service. Which pattern does this represent?

Accepted Answer

Sidecar pattern. The sidecar pattern involves adding a secondary container (the sidecar) to the same pod as the primary container to extend or enhance its functionality without altering the primary container itself. In this scenario, the sidecar container reads the logs from the primary container's stdout (typically via a shared volume or by tailing the container's log file) and forwards them to a centralized logging service, such as Elasticsearch, Fluentd, or a cloud logging endpoint. This pattern is a core Kubernetes design pattern for modular, non-invasive extensions.

Answer

Ambassador pattern

Answer

Adapter pattern

Answer

Init container pattern

Question 11

Which kubectl command creates a deployment named 'web' from the image 'nginx:1.25' and exposes it on port 80?

Accepted Answer

kubectl create deployment web --image=nginx:1.25 --expose. The correct command should include both `--port=80` and `--expose`, e.g., `kubectl create deployment web --image=nginx:1.25 --port=80 --expose`. The current option A only has `--expose`, which is insufficient because `--expose` requires `--port` to specify the container and Service port. Therefore, none of the provided options fully satisfies the requirement.

Answer

kubectl apply -f deployment.yaml

Answer

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

Answer

kubectl create deployment web --image=nginx:1.25

Question 12

You have a YAML file for a Job named 'data-processor' with 'spec.backoffLimit: 4'. After 3 retries, one pod fails. How many more retries will Kubernetes attempt on that pod?

Accepted Answer

1 retry. The Job's `backoffLimit` is set to 4, meaning Kubernetes will retry the Job up to 4 times before marking it as failed. After 3 retries have already occurred, only 1 more retry is allowed before reaching the limit. Each retry corresponds to a new Pod attempt, and the counter resets only when the Job succeeds.

Answer

0 retries; the job is marked as failed

Answer

Unlimited retries until success

Answer

4 retries

Question 13

A pod with an init container and a main container has 'restartPolicy: Always'. The init container exits with code 0. What happens next?

Accepted Answer

The main container starts; if it fails, it will be restarted. When an init container exits with code 0, it indicates successful completion. With `restartPolicy: Always`, the pod's main container then starts. If the main container fails, Kubernetes restarts it according to the `restartPolicy`, which is `Always` in this case, so the main container will be restarted indefinitely.

Answer

The pod enters CrashLoopBackOff because the init container should not exit

Answer

The pod is considered complete and enters Succeeded phase

Answer

The init container restarts and runs again

Question 14

Which of the following is a valid schedule for a CronJob that runs every day at midnight?

Accepted Answer

0 0 * * *. A CronJob schedule uses standard cron syntax: minute, hour, day of month, month, day of week. '0 0 * * *' means minute=0, hour=0 (midnight), and the asterisks for day of month, month, and day of week match any value, so the job runs every day at midnight.

Answer

0 0 1 * *

Answer

* * * * *

Answer

0 * * * *

Question 15

You run 'kubectl run debug-pod --image=busybox -it --restart=Never -- sh' but the pod starts and immediately exits. You want to keep the container running to execute commands later. What flag should you add?

Accepted Answer

-- sleep infinity. Adding `-- sleep infinity` to the `kubectl run` command overrides the default entrypoint (`sh`) with a command that runs `sleep infinity`, which keeps the container alive indefinitely. Without this, the interactive shell (`sh`) exits immediately when it has no input, causing the pod to terminate. The `--` separator passes the command to the container image's entrypoint, ensuring the process runs in the foreground and does not exit.

Answer

--stdin=true

Answer

--command

Answer

--attach