CCNA Ckad Design Build Questions — Page 2 of 2

MCQeasy

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

A.0 0 1 * *

B.* * * * *

C.0 * * * *

D.0 0 * * *

AnswerD

The five-field cron format is minute, hour, day-of-month, month, day-of-week. All zeros in the first two fields mean minute zero of hour zero, i.e. midnight daily, while the asterisks leave every day and month unrestricted.

Why this answer

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.

Exam trap

A common trap is the subtle difference between '0 0 * * *' (every day at midnight) and '0 0 1 * *' (first day of the month at midnight), exploiting the confusion that the third field is day of month, not 'every day'.

How to eliminate wrong answers

Option A is wrong because '0 0 1 * *' runs at midnight on the first day of every month, not every day. Option B is wrong because '* * * * *' runs every minute, which is not 'every day at midnight'. Option C is wrong because '0 * * * *' runs at the start of every hour (minute 0 of every hour), not specifically at midnight.

Practice this question →

MCQeasy

Which Dockerfile instruction sets a command that can be overridden when running the container?

A.RUN

B.EXPOSE

C.ENTRYPOINT

D.CMD

AnswerD

CMD is the instruction that sets the default command and parameters for the container. When you run 'docker run <image> <command>', the command you supply entirely overrides the CMD value. This is precisely why CMD is the correct answer: it provides a runtime default that can be easily replaced without any special flags. CMD can also supply default arguments to an ENTRYPOINT if both are defined, but in the absence of ENTRYPOINT, CMD is the executable that runs.

Why this answer

The CMD instruction provides default arguments for the container's entrypoint, which can be overridden by supplying command-line arguments when running the container with `docker run`. This makes CMD the correct choice for a command that is intended to be overridden at runtime.

Exam trap

The trap here is that candidates often confuse ENTRYPOINT and CMD, mistakenly thinking ENTRYPOINT is overridable by default, when in fact CMD is the instruction specifically designed to be overridden by runtime arguments.

How to eliminate wrong answers

Option A is wrong because RUN executes commands during the image build process, creating new layers in the image, and its effects are baked into the image and cannot be overridden at container runtime. Option B is wrong because EXPOSE only documents which ports the container listens on; it does not execute any command and cannot be overridden. Option C is wrong because ENTRYPOINT defines the main executable for the container, and while it can be overridden with `--entrypoint` flag, it is designed to be the fixed command that is not easily replaced by simple command-line arguments—unlike CMD, which is specifically intended to be overridden.

Practice this question →

Multi-Selectmedium

Which TWO statements about Init Containers are correct? (Select exactly 2.)

Select 2 answers

A.Init containers run in parallel to reduce startup time

B.Init containers run to completion sequentially before any app containers start

C.Init containers can use a different container image than the app containers

D.If an init container fails, Kubernetes restarts it until it succeeds regardless of restartPolicy

E.Init containers can have liveness and readiness probes

AnswersB, C

Init containers are always started before any application containers in the pod. Each init container must run to completion successfully before the next one is launched, and if one fails, Kubernetes applies the pod's restartPolicy to determine whether to restart it; only after all init containers succeed does the kubelet start the main app containers.

Why this answer

Option B is correct because Kubernetes executes init containers one at a time, in the order defined in the pod spec, and each must run to completion successfully before the next init container or any app container starts. Option C is correct because each init container is defined with its own image field in the pod spec, so it can use a completely different container image (and different tooling) than the app containers. Option A is wrong because init containers run sequentially, not in parallel, which is the opposite of what the statement claims.

Option D is wrong because if an init container fails, Kubernetes restarts it according to the pod's restartPolicy (Always, OnFailure, or Never), not unconditionally regardless of restartPolicy. Option E is wrong because init containers do not support liveness, readiness, or startup probes; they are only expected to run to completion.

Exam trap

A common trap is thinking that init containers always restart on failure regardless of the Pod's restartPolicy. In fact, with a restartPolicy of Never, the Pod will be marked as failed and the init container will not be restarted.

Practice this question →

MCQmedium

You are tasked with deploying a stateless web application on a Kubernetes cluster. The application is containerized and listens on port 8080. You have created a Deployment named 'webapp' with 3 replicas, and a ClusterIP Service named 'webapp-svc' exposing port 80 targeting the application's port 8080. During testing, you notice that some requests to the service return errors while others succeed. You have verified that all Pods are running and ready. The application logs show no errors. What is the most likely cause of the intermittent failures?

A.The ClusterIP Service type does not support load balancing.

B.The Service is not configured with enough endpoints.

C.The Service's targetPort is set incorrectly, causing traffic to be misrouted.

D.The Deployment lacks a readiness probe, causing the Service to route traffic to Pods that are not ready.

AnswerD

Without a readiness probe, kube-proxy considers a Pod 'Ready' as soon as its containers are running, even if the application inside is still initializing, warming up, or temporarily unable to handle traffic. This causes the Service to include such Pods as endpoints, so some requests get routed to a Pod that will sporadically return 5xx errors or drop the connection. A readiness probe solves this by marking the Pod Ready only when it responds successfully to a health check, ensuring the Service’s endpoint list contains only truly available Pods.

Why this answer

The intermittent failures are most likely caused by the absence of a readiness probe in the Deployment. Without a readiness probe, the Service's EndpointSlice controller considers all Pods with a matching label selector as ready endpoints, even if the application inside the container has not finished initializing or is temporarily unable to serve traffic. This results in the ClusterIP Service load-balancing requests to Pods that are not actually ready, causing some requests to fail while others succeed.

Exam trap

CNCF often tests the distinction between 'Pod is Running' (container process started) and 'Pod is Ready' (application is healthy and can serve traffic), trapping candidates who assume that a Running Pod is automatically ready to receive Service traffic.

How to eliminate wrong answers

Option A is wrong because ClusterIP Services do provide internal load balancing via kube-proxy using iptables or IPVS rules, distributing traffic across ready endpoints. Option B is wrong because the Service is configured with a label selector matching the Deployment's Pods, and with 3 replicas all running and ready (as verified), there are exactly 3 endpoints — enough for load balancing. Option C is wrong because the targetPort is set to 8080, which matches the container's listening port, so traffic is correctly routed to the application.

Practice this question →

MCQeasy

Which of the following is the correct way to create a simple Pod named 'nginx' running the nginx:1.25 image using kubectl?

A.kubectl create nginx --image=nginx:1.25

B.kubectl create pod nginx --image=nginx:1.25

C.kubectl apply nginx --image=nginx:1.25

D.kubectl run nginx --image=nginx:1.25

AnswerD

The correct command is 'kubectl run nginx --image=nginx:1.25'. This is the standard imperative command for creating a single Pod: it generates a Pod object named 'nginx' with the specified container image and submits it to the cluster. 'kubectl run' is specifically designed for this purpose, whereas 'kubectl create' and 'kubectl apply' have different roles.

Why this answer

`kubectl run nginx --image=nginx:1.25` is the imperative command to create a Pod directly without a Deployment. The `run` subcommand is specifically designed to create a Pod (or other resources like Deployments) from an image, and when no resource type is specified, it defaults to creating a Pod. This is the standard CKAD approach for quickly launching a standalone Pod.

Exam trap

The trap here is that candidates confuse `kubectl run` (which creates a Pod or Deployment) with `kubectl create` (which requires a resource type and is often used with files), leading them to incorrectly assume `kubectl create pod` is valid syntax.

How to eliminate wrong answers

Option A is wrong because `kubectl create nginx` is invalid syntax; `kubectl create` requires a resource type (e.g., `deployment`, `pod`) and does not accept a name directly after `create`. Option B is wrong because `kubectl create pod` is not a valid subcommand; `kubectl create` can create a Pod using `kubectl create -f <file>` or `kubectl run`, but `kubectl create pod` is not recognized by kubectl. Option C is wrong because `kubectl apply` is used for declarative management with YAML/JSON files, not for imperative creation with `--image`; `kubectl apply` expects a file or stdin, not inline image arguments.

Practice this question →

Multi-Selectmedium

Which TWO fields are required in a CronJob manifest? (Select 2)

Select 2 answers

A.startingDeadlineSeconds

B.successfulJobsHistoryLimit

C.schedule

D.concurrencyPolicy

E.jobTemplate

AnswersC, E

schedule is mandatory because it defines the cron expression that tells the CronJob controller when to create a new Job. Without this value, the controller has no time-based trigger, and the Kubernetes API server will reject the manifest as invalid. The expression uses the standard five-field cron format, for example '*/30 * * * *' for every thirty minutes.

Why this answer

The `schedule` field defines the cron expression that determines when the CronJob runs (e.g., `*/5 * * * *`). This is a mandatory field in a CronJob manifest as per the Kubernetes API specification, without which the controller cannot determine the execution timing.

Exam trap

Candidates often mistakenly think that `concurrencyPolicy` or `startingDeadlineSeconds` are required because they appear frequently in examples, but the only mandatory fields in a CronJob manifest are `schedule` and `jobTemplate`.

Practice this question →

MCQeasy

What is the purpose of the '.dockerignore' file?

A.To specify which files to include in the image

B.To ignore files during docker push

C.To exclude files from the build context

D.To list environment variables to ignore

AnswerC

The correct purpose is to exclude files and directories from the build context that the Docker client sends to the Docker daemon, shrinking the upload size and preventing sensitive or irrelevant data from reaching layer builds. Any path listed in .dockerignore is absent from the context, meaning COPY/ADD cannot access those files at all, and changes to them won't invalidate the build cache. This is the intended, documented behavior of the file.

Why this answer

The `.dockerignore` file is used to exclude files and directories from the build context sent to the Docker daemon during a `docker build` operation. By specifying patterns in this file, you prevent unnecessary or sensitive files (like local development artifacts, `.git` directories, or node_modules) from being included, which speeds up the build and reduces the image size. Option C correctly identifies this purpose.

Exam trap

The CKAD exam often tests the distinction between build-time context exclusion (`.dockerignore`) and runtime image content (Dockerfile instructions), so candidates may mistakenly think `.dockerignore` controls what goes into the final image rather than what is sent to the Docker daemon.

How to eliminate wrong answers

Option A is wrong because the `.dockerignore` file excludes files from the build context, not includes them; inclusion is controlled by the Dockerfile's `COPY` or `ADD` instructions. Option B is wrong because `.dockerignore` has no effect on `docker push`, which uploads built image layers to a registry, not files from the build context. Option D is wrong because environment variables are managed via the Dockerfile `ENV` instruction or `--env` flags at runtime, not by `.dockerignore`.

Practice this question →

Multi-Selecthard

Which THREE of the following are valid fields in the '.spec' of a Job manifest?

Select 3 answers

A.replicas

B.parallelism

C.strategy

D.completions

E.backoffLimit

AnswersB, D, E

parallelism specifies the maximum number of Job Pods that can run simultaneously. It does not define the total number of Pods; it only sets the concurrency cap for the Job. For a non-parallel Job, parallelism is implicitly 1, but for a parallel Job, you can set it higher to process multiple work items at once. This field is useful for controlling resource usage and throttling the rate at which work is processed.

Why this answer

'parallelism' is a valid field in the '.spec' of a Job manifest. It controls the maximum number of Pods that can run concurrently for the Job, allowing you to manage parallel execution. This field is part of the Job specification in the Kubernetes API, distinct from Deployments or other controllers.

Exam trap

The trap here is that candidates often confuse Job fields with Deployment fields, assuming 'replicas' or 'strategy' apply to Jobs, when in fact Jobs use 'completions' and 'parallelism' to manage batch execution.

Practice this question →

MCQmedium

What is the correct schedule expression for a CronJob that runs every 5 minutes?

A.*/5 * * * *

B.* * * * *

C.0 */5 * * *

D.5 * * * *

AnswerA

This is the valid schedule for every 5 minutes: the minute field uses the */5 step syntax, meaning the job fires at minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55. All remaining fields (hour, day of month, month, day of week) are wildcards, so no further restriction is applied. With no seconds field, standard cron has a minute resolution.

Why this answer

The CronJob schedule expression `*/5 * * * *` uses the step syntax (`*/5`) in the minute field, which tells the CronJob to run every 5 minutes. In Kubernetes CronJobs, the schedule follows standard cron syntax: minute, hour, day of month, month, day of week. The asterisk means 'every' and the slash with a number means 'every N units', so `*/5` in the minute field triggers the job at minutes 0, 5, 10, 15, etc., effectively every 5 minutes.

Exam trap

The trap here is that candidates often confuse the step syntax placement: putting `*/5` in the hour field (as in option C) instead of the minute field, mistakenly thinking it means 'every 5 minutes' when it actually means 'every 5 hours'.

How to eliminate wrong answers

Option B is wrong because `* * * * *` means 'every minute' (run at every minute of every hour), not every 5 minutes. Option C is wrong because `0 */5 * * *` means 'at minute 0 of every 5th hour' (i.e., runs at 00:00, 05:00, 10:00, etc.), which is every 5 hours, not every 5 minutes. Option D is wrong because `5 * * * *` means 'at minute 5 of every hour' (i.e., runs once per hour at the 5th minute), not every 5 minutes.

Practice this question →

MCQhard

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

A.The pod enters CrashLoopBackOff because the init container should not exit

B.The main container starts; if it fails, it will be restarted

C.The pod is considered complete and enters Succeeded phase

D.The init container restarts and runs again

AnswerB

Once all init containers have exited successfully, Kubernetes proceeds to start the main application container. From that point, the pod's restartPolicy (Always, in this case) governs the main container: any failure or non-zero exit triggers a restart by the kubelet, possibly with an exponential backoff. The init container will not be re-executed when the main container restarts, so the pod remains active until the main container exits cleanly.

Why this answer

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.

Exam trap

The trap here is that candidates confuse init container behavior with main container behavior, assuming that `restartPolicy: Always` applies to init containers or that a successful init container causes the pod to complete.

How to eliminate wrong answers

Option A is wrong because init containers are designed to run to completion (exit 0) before the main container starts; they are not expected to keep running. Option C is wrong because a pod with `restartPolicy: Always` never enters the Succeeded phase; that phase is reserved for pods with `restartPolicy: OnFailure` or `Never` that complete successfully. Option D is wrong because an init container that exits with code 0 is considered successful and will not restart; only init containers that fail (non-zero exit) are retried.

Practice this question →

MCQeasy

Which of the following is the correct apiVersion for a Kubernetes Job in v1.29?

A.batch/v1

B.apps/v1

C.v1

D.batch/v1beta1

AnswerA

The batch API group manages job-like workloads, and batch/v1 is its stable version, available since Kubernetes 1.21. This version supersedes batch/v1beta1 and is the correct choice for Jobs, supporting features such as ttlSecondsAfterFinished, parallelism, and completions. Always specify batch/v1 for Jobs to ensure compatibility with current and future cluster versions.

Why this answer

In Kubernetes v1.29, the correct apiVersion for a Job is `batch/v1`. The `batch/v1` API version has been stable since Kubernetes 1.21, and Jobs are part of the batch API group. Using `batch/v1` ensures compatibility with the current stable release and provides access to all Job features, including parallelism, completions, and backoff limits.

Exam trap

The trap here is that candidates may confuse the `batch/v1` apiVersion with the older `batch/v1beta1` (which is no longer valid) or incorrectly assume Jobs are part of the core `v1` or `apps/v1` API groups, leading to a wrong answer.

How to eliminate wrong answers

Option B (`apps/v1`) is wrong because `apps/v1` is used for workloads like Deployments, StatefulSets, DaemonSets, and ReplicaSets, not for Jobs. Option C (`v1`) is wrong because `v1` is the core API group (e.g., Pods, Services, ConfigMaps), and Jobs belong to the `batch` API group, not the core group. Option D (`batch/v1beta1`) is wrong because the `batch/v1beta1` version was deprecated in Kubernetes 1.21 and removed in 1.25; using it in v1.29 would result in an API error.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid ways to expose a container port in a pod spec?

Select 2 answers

A.spec.containers[].ports[].hostPort

B.spec.containers[].hostPort

C.spec.containers[].containerPort

D.EXPOSE 8080 in Dockerfile

E.spec.containers[].ports[].containerPort

AnswersA, E

spec.containers[].ports[].hostPort is valid because it explicitly maps a container port to a port on the host node's network interface, enabling external traffic to reach the container via the node's IP without requiring a separate Service object. This field must be nested inside a port entry, alongside containerPort, and comes with operational caveats such as port conflicts and node scheduling constraints.

Why this answer

`spec.containers[].ports[].hostPort` is a valid field in the Pod spec that maps a container port to the host node's network interface. This allows external traffic to reach the container via the host's IP address and specified port, though it is typically used for daemon sets or host-networking scenarios rather than general service exposure.

Exam trap

In the CKAD exam, the trap is that candidates confuse `containerPort` as a top-level field under `containers[]` instead of recognizing it must be nested inside `ports[]`, and they may mistakenly think Dockerfile `EXPOSE` has any effect in Kubernetes.

Practice this question →

Multi-Selecthard

A team wants to deploy a multi-container Pod with a sidecar pattern. Which THREE statements are true about sidecar containers? (Select exactly 3.)

Select 3 answers

A.Sidecar containers are always started before the main container

B.Sidecar containers are used for tasks like log collection, service mesh proxies, or data synchronization

C.Sidecar containers can be updated independently without restarting the main container

D.Sidecar containers run in the same Pod as the main container

E.Sidecar containers share the same network namespace as the main container

AnswersB, D, E

A sidecar container is an auxiliary process that deploys alongside the main container to provide supporting functionality without being the primary workload. Common use cases include collecting and shipping logs (e.g., Fluentd), acting as a service mesh proxy (e.g., Envoy), or synchronizing data volumes between local and remote storage. This pattern encapsulates cross-cutting concerns into a separate, co-located process that shares the Pod's lifecycle.

Why this answer

Sidecar containers are auxiliary containers that enhance or extend the functionality of the main application container. Common use cases include log collection (e.g., Fluentd), service mesh proxies (e.g., Envoy), and data synchronization (e.g., rsync or a Git sync sidecar). These tasks support the primary workload without altering its code.

Exam trap

The trap here is that candidates confuse the sidecar pattern with init containers, which do run to completion before main containers start, or assume sidecar containers can be updated independently like separate Deployments.

Practice this question →

MCQeasy

Which Dockerfile instruction is used to specify the base image for a container image?

A.COPY

B.FROM

C.CMD

D.RUN

AnswerB

FROM is the only instruction that identifies the base image for a build, either by pulling a tag from a registry (e.g., node:20-alpine) or by referencing a previous build stage by name (e.g., FROM builder AS runtime). This instruction initializes a new build stage and establishes the filesystem, default environment, and runtime libraries that subsequent instructions inherit. Without a valid FROM, Docker will reject the Dockerfile as having no base layer.

Why this answer

The FROM instruction initializes a new build stage and sets the base image for subsequent instructions. It must be the first non-comment instruction in a Dockerfile, pulling a specified image from a registry (e.g., Docker Hub) to provide the filesystem and runtime environment for the container.

Exam trap

The trap here is that candidates confuse RUN (which executes build-time commands) with FROM (which sets the base image), especially when they see RUN apt-get update and assume it defines the environment, but FROM is the mandatory first instruction that establishes the image foundation.

How to eliminate wrong answers

Option A is wrong because COPY is used to copy files from the build context into the container filesystem, not to specify the base image. Option C is wrong because CMD provides default command arguments for the container at runtime, not the base image. Option D is wrong because RUN executes commands in a new layer on top of the current image during build, not to define the base image.

Practice this question →

MCQhard

You have a pod that runs a single container with the following resource limits: memory: 256Mi, cpu: 500m. The container is consistently using 300Mi of memory and 300m of CPU. The pod is running but you want to avoid OOMKilled. Which change should you make?

A.Increase memory limit to 512Mi

B.Set memory request to 128Mi and keep limit at 256Mi

C.Decrease memory limit to 128Mi

D.Increase CPU limit to 1000m

AnswerA

The container is being OOMKilled because its memory usage exceeds the current limit, triggering the kernel OOM killer. Raising the limit to 512Mi provides sufficient headroom for the container's observed usage, allowing the process to continue running. This is only safe if the node has enough allocatable memory to accommodate the new limit.

Why this answer

The container is consistently using 300Mi of memory, which exceeds the current memory limit of 256Mi. When a container exceeds its memory limit, the kernel's OOM killer terminates the process (OOMKilled). Increasing the limit to 512Mi provides headroom above the actual usage, preventing OOM kills while allowing the container to continue running.

Exam trap

The trap here is that candidates often confuse CPU and memory resource management, thinking that increasing CPU limits can solve memory-related OOM kills, or that requests alone (without adjusting limits) can prevent termination.

How to eliminate wrong answers

Option B is wrong because setting a memory request of 128Mi does not prevent OOMKilled; the limit remains at 256Mi, which is still below the actual 300Mi usage, so the container will still be killed when it exceeds the limit. Option C is wrong because decreasing the memory limit to 128Mi would make the problem worse, as the container would exceed the limit even more frequently, leading to immediate OOMKilled. Option D is wrong because increasing the CPU limit to 1000m does not address the memory exhaustion issue; CPU limits affect CPU throttling, not memory, and OOMKilled is triggered by memory limit violations, not CPU.

Practice this question →

MCQmedium

A user creates a Job with '.spec.completions=5' and '.spec.parallelism=2'. How many pods will run at the same time?

A.5

B.10

C.7

D.2

AnswerD

The parallelism field in a Job spec directly sets the maximum number of pods that can run at the same time. With parallelism=2, the Job controller ensures no more than 2 pods are active concurrently, regardless of the completions count being 5.

Why this answer

`.spec.parallelism=2` directly specifies the maximum number of Pods that can run concurrently for the Job. The `.spec.completions=5` value only sets the total number of successful completions required, not the parallelism. Therefore, at any given time, only 2 Pods will run simultaneously.

Exam trap

The trap here is that candidates often confuse `.spec.completions` with parallelism, assuming the total number of completions equals the number of concurrent Pods, or they mistakenly multiply or add the two values.

How to eliminate wrong answers

Option A is wrong because it confuses `.spec.completions=5` (total required completions) with parallelism; 5 Pods would only run at once if parallelism were set to 5. Option B is wrong because it incorrectly multiplies completions by parallelism (5 × 2 = 10), which is not how Kubernetes schedules Job Pods. Option C is wrong because it adds completions and parallelism (5 + 2 = 7), which has no basis in Job scheduling logic.

Practice this question →

MCQeasy

Which Dockerfile instruction is used to define a mount point for a volume?

A.ADD

B.VOLUME

C.EXPOSE

D.MOUNT

AnswerB

VOLUME is the correct Dockerfile instruction because it explicitly creates a mount point and marks it as a location for external storage volumes. When a container is run, Docker automatically creates an anonymous volume at that path unless a named volume or bind mount is supplied via the run command or compose file. This instruction is essential for defining persistent data locations, as it tells Docker that the specified directory should be preserved independently of the container's writable layer and can be shared between containers.

Why this answer

The VOLUME instruction in a Dockerfile creates a mount point at the specified path within the container, marking it as holding externally mounted volumes from the host or other containers. This is the correct way to declare a volume in the Dockerfile, ensuring data persistence and enabling volume sharing between containers.

Exam trap

The trap here is that candidates confuse the Dockerfile VOLUME instruction with the `docker run -v` or `--mount` runtime flags, or mistakenly think EXPOSE or ADD can define volumes, when only VOLUME in the Dockerfile declares the mount point.

How to eliminate wrong answers

Option A is wrong because ADD is used to copy files, directories, or remote URLs into the image, not to define volume mount points. Option C is wrong because EXPOSE documents which ports the container listens on at runtime, but does not create or define volumes. Option D is wrong because MOUNT is not a valid Dockerfile instruction; the correct instruction is VOLUME.

Practice this question →

MCQmedium

You have a multi-stage Dockerfile. You want to copy artifacts from the builder stage to the final stage. Which instruction should you use in the final stage?

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

B.RUN --from=builder cp /app/artifact /app/

C.COPY --from=builder /app/artifact /app/

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

AnswerC

COPY --from=builder /app/artifact /app/ is the standard multi-stage mechanism: it tells the current build stage to take the file or directory at /app/artifact from the stage named builder and place it at /app in the new image layer. This instruction is explicit about the source stage, avoids ADD's archive-extraction side effects, and lets you keep build-only tools out of the final runtime image. The artifact is copied directly from the builder stage's filesystem into the next stage's filesystem.

Why this answer

The COPY instruction with the --from flag is specifically designed for multi-stage builds to copy files from a previous build stage (or an external image) into the current stage. It only copies local files or directories from the specified stage, making it the correct and efficient way to transfer artifacts like compiled binaries. This avoids including unnecessary build dependencies in the final image.

Exam trap

CKAD often tests the misconception that ADD or RUN can be used with --from to copy from another stage, but only COPY supports the --from flag for multi-stage artifact transfer.

How to eliminate wrong answers

Option A is wrong because ADD does not support the --from flag; ADD is used for adding files from a URL or extracting tarballs, but it cannot reference other build stages. Option B is wrong because RUN executes a command in the current stage's shell, and the --from flag is not valid for RUN; you cannot directly copy from another stage using RUN without first mounting or using a multi-stage copy. Option D is wrong because CMD sets the default command for the container at runtime and does not perform any file copying; it cannot reference build stages.

Practice this question →

MCQmedium

What is the default restart policy for a pod created with 'kubectl run nginx --image=nginx'?

A.Always

B.OnFailure

C.Never

D.Restart

AnswerA

The default restart policy for a pod is Always. When you create a pod using `kubectl run` (or any command that doesn't explicitly set `restartPolicy`), the API server defaults the field to `Always`. This means the kubelet will automatically restart the pod's containers whenever they exit, regardless of the exit code, ensuring the pod remains running indefinitely. This is the expected behavior for long-running workloads like Deployments.

Why this answer

The default restart policy for a Pod created with `kubectl run` is `Always`. This is because `kubectl run` generates a deployment-like controller (or a standalone Pod in older versions) that defaults to the `Always` policy, meaning the kubelet will automatically restart the container regardless of its exit code. This ensures the Pod maintains a running state unless explicitly deleted or scaled down.

Exam trap

A common misconception is that `kubectl run` creates a bare Pod with no default restart policy, leading candidates to incorrectly assume `OnFailure` or `Never` is the default, when in fact `Always` is the implicit default for any Pod created without an explicit `--restart` flag.

How to eliminate wrong answers

Option B is wrong because `OnFailure` is not the default; it is a specific policy that restarts the container only when it exits with a non-zero exit code, and must be explicitly set via `--restart=OnFailure`. Option C is wrong because `Never` is not the default; it prevents any automatic restart and must be explicitly set via `--restart=Never`. Option D is wrong because `Restart` is not a valid restart policy in Kubernetes; the valid policies are `Always`, `OnFailure`, and `Never`.

Practice this question →

MCQmedium

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?

A.Delete and recreate the pod to clear the crash loop

B.Delete the namespace and redeploy all workloads

C.Increase the memory limit in the pod's container resource specification

D.Increase the CPU request for the container

AnswerC

OOMKilled is the kubelet's signal that the container's memory usage exceeded its specified limit, prompting the kernel OOM killer to terminate the process. Raising the memory limit in the container's resource specification permits the container to consume more memory before that threshold is reached, directly addressing the root cause and allowing the pod to remain running. This is the expected fix when the application's nominal memory footprint is larger than the old limit but still fits within node capacity.

Why this answer

The pod is in CrashLoopBackOff due to OOMKilled, which means the container's memory usage exceeded its configured memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to allocate more memory without being terminated by the Out-of-Memory (OOM) killer.

Exam trap

The trap here is that candidates often confuse OOMKilled with a general crash and choose to delete and recreate the pod (Option A), not realizing that the resource limit itself must be adjusted to prevent recurrence.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the pod will not resolve the underlying memory limit issue; the new pod will still have the same resource constraints and will be OOMKilled again. Option B is wrong because deleting the entire namespace and redeploying all workloads is an extreme, disruptive action that does not address the specific memory limit problem and would cause unnecessary downtime. Option D is wrong because increasing the CPU request does not affect memory allocation; the OOMKilled status is caused by exceeding the memory limit, not CPU constraints.

Practice this question →

Multi-Selecthard

A developer is defining a Pod that uses an init container to prepare a shared volume before the main application container starts. The init container must download configuration files into an emptyDir volume, and the main container must read them. Which TWO statements about this Pod design are correct? (Choose two.)

Select 2 answers

A.If an init container fails, Kubernetes restarts the entire Pod on a new node, discarding the emptyDir contents and any partially downloaded files.

B.The main container can start in parallel with the init container if the init container declares a readinessProbe, allowing faster startup.

C.An emptyDir volume declared in the Pod spec can be mounted by both the init container and the main container, allowing files written by the init container to be visible to the main container.

D.Init containers share the same network namespace as the main container, so they can bind to the same port the main container will use without conflict.

E.Init containers run to completion one at a time before any app container starts, so the main container will not begin until the init container exits successfully.

AnswersC, E

emptyDir is a Pod-scoped volume that exists for the Pod's lifetime and can be mounted into multiple containers. Mounting it in both the init container and the main container lets the init container write configuration files that the main container later reads, satisfying the shared-volume requirement.

Why this answer

Init containers run sequentially to completion before app containers start, ensuring the shared emptyDir is populated first. Because emptyDir is Pod-scoped and can be mounted by multiple containers, the init container can write files that the main container reads.

Exam trap

The trap here is assuming init containers can run in parallel with app containers or that readiness probes apply to them, when they must complete before any app container starts.

Practice this question →

MCQeasy

Which 'kubectl' command creates a pod named 'test-pod' using the nginx image and outputs the YAML manifest without actually creating it?

A.kubectl apply -f pod.yaml

B.kubectl run test-pod --image=nginx --dry-run=client -o yaml

C.kubectl run test-pod --image=nginx --dry-run=server

D.kubectl run test-pod --image=nginx --dry-run=client -o json

AnswerB

This is the canonical imperative command for manifest generation: `kubectl run` creates a Pod object from flags, `--dry-run=client` tells kubectl to only print the object locally without sending anything to the API server, and `-o yaml` formats that object as YAML on stdout. It gives you a complete Pod spec (with default values and a generated name) that you can review, edit, or pipe to `kubectl apply -f -`. This is precisely what the question asks for — a command that generates a Pod manifest without creating the Pod.

Why this answer

`kubectl run test-pod --image=nginx --dry-run=client -o yaml` generates the YAML manifest for a pod named 'test-pod' using the nginx image without actually creating it. The `--dry-run=client` flag simulates the request locally and prevents API server submission, while `-o yaml` formats the output as YAML.

Exam trap

The CKAD exam often tests the distinction between `--dry-run=client` and `--dry-run=server`, and the requirement for output format (`-o yaml` vs `-o json`), tricking candidates into choosing an option that either does not output the manifest or outputs it in the wrong format.

How to eliminate wrong answers

Option A is wrong because `kubectl apply -f pod.yaml` creates resources from a file and does not output a manifest without creation; it actually applies the manifest to the cluster. Option C is wrong because `--dry-run=server` sends the request to the API server for validation but still does not create the resource, but the question specifically requires outputting the YAML manifest, which `-o yaml` is missing in this option. Option D is wrong because `-o json` outputs the manifest in JSON format, not YAML, which does not meet the requirement for YAML output.

Practice this question →

MCQhard

You are tasked with running a batch job that processes 100 items in parallel, using a Kubernetes Job. The Job should ensure that all items are processed even if some pods fail, and the total number of pod failures should be limited to 3. Which Job configuration is correct?

A.Set spec.parallelism: 100, spec.completions: 100, spec.backoffLimit: 3

B.Set spec.parallelism: 1, spec.completions: 100, spec.backoffLimit: 3

C.Set spec.parallelism: 100, spec.completions: 1, spec.backoffLimit: 3

D.Set spec.parallelism: 100, spec.completions: 100, spec.activeDeadlineSeconds: 300

AnswerA

This configuration correctly matches the workload: spec.parallelism: 100 lets up to 100 pods run simultaneously to process the 100 items in parallel, while spec.completions: 100 ensures the Job is not marked successful until each of the 100 items is handled by a successful pod completion. Adding spec.backoffLimit: 3 caps the number of retries for failing pods to 3, providing a sane bound on wasted work. Together these fields encode the exact concurrency and completion requirements for a 100-item batch without any time-based preemption.

Why this answer

Setting `spec.parallelism: 100` allows 100 pods to run concurrently, `spec.completions: 100` ensures all 100 items are processed (each pod handles one item), and `spec.backoffLimit: 3` limits the total number of pod failures to 3 before the Job is marked as failed. This configuration guarantees that even if some pods fail, the Job will retry them up to the specified backoff limit, ensuring all items are processed.

Exam trap

The trap here is confusing `backoffLimit` (which limits pod failures) with `activeDeadlineSeconds` (which limits the overall Job runtime), leading candidates to pick Option D, which fails to cap failures and instead imposes a time constraint.

How to eliminate wrong answers

Option B is wrong because `spec.parallelism: 1` forces pods to run sequentially, not in parallel, which defeats the requirement to process 100 items in parallel. Option C is wrong because `spec.completions: 1` means the Job only needs one successful pod completion, so it will not process all 100 items. Option D is wrong because `spec.activeDeadlineSeconds: 300` sets a time limit for the Job, but does not limit the number of pod failures; the `backoffLimit` field is required to cap failures at 3.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid uses of init containers? (Select 2)

Select 2 answers

A.Running a log collection agent continuously

B.Performing health checks on the main container

C.Setting ownership and permissions on a shared volume before the main container uses it

D.Serving HTTP traffic to the main container

E.Waiting for an external database to be ready before starting the main application

AnswersC, E

Before the main application container starts, an init container can mount a shared volume and apply file ownership, permissions, or SELinux labels using familiar Unix tools like chown and chmod. Because init containers execute sequentially to completion, any changes it makes on the volume persist for main containers, a pattern that is especially useful with persistent volumes or emptyDir mounts.

Why this answer

Init containers run to completion before any pod containers start, making them ideal for filesystem setup tasks like changing ownership (chown) or permissions (chmod) on a shared volume. This ensures the main container can access the volume without requiring privileged mode or extra security context settings.

Exam trap

Kubernetes often tests the misconception that init containers can run continuously or serve as sidecars, but the key trap is that init containers must terminate successfully before the main containers start, so only one-time setup tasks are valid.

Practice this question →

100

MCQmedium

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

A.The new job is skipped until the next scheduled time

B.The new job starts immediately, running concurrently

C.The running job is terminated and the new job starts

D.The CronJob enters an error state

AnswerA

With concurrencyPolicy set to Forbid, the CronJob controller checks whether any Job created from this CronJob is currently active. If a previous Job is still running at the scheduled time, the controller simply skips the newly triggered execution. The missed run is not queued or retried; it is permanently lost until the next schedule fires.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse `concurrencyPolicy: Forbid` with `concurrencyPolicy: Replace`, which would terminate the running job; or they assume that a skipped job will be retried immediately, but Kubernetes does not automatically retry skipped executions under the `Forbid` policy.

How to eliminate wrong answers

Option B is wrong because `concurrencyPolicy: Forbid` explicitly prevents concurrent runs; the new job does not start immediately. Option C is wrong because `concurrencyPolicy: Forbid` does not terminate the running job; it only skips the new execution. Option D is wrong because the CronJob does not enter an error state; it simply logs a skip event and continues to monitor future schedules.

Practice this question →

101

MCQmedium

You need to run a database migration as a container before the main application container starts. Which Kubernetes concept should you use?

A.Job

B.Init container

C.Sidecar container

D.Ephemeral container

AnswerB

An init container is defined in the same pod spec as the application and runs sequentially to completion before any main container starts. The kubelet executes init containers in order, and the main containers are blocked until all init containers exit successfully. This makes it the correct, native way to run a database migration as a prerequisite: the app container does not even start until the migration container finishes.

Why this answer

Init containers run sequentially before the main application container starts and are designed for setup tasks like database migrations. They complete successfully before any regular containers in the Pod begin, ensuring the migration finishes before the main app starts.

Exam trap

The trap here is that candidates confuse init containers with Jobs, thinking both run to completion, but Jobs are independent objects while init containers are tightly coupled to a Pod's lifecycle and must complete before the main container starts.

How to eliminate wrong answers

Option A is wrong because a Job is a standalone resource that runs a task to completion independently of a Pod's lifecycle, not as a prerequisite for a specific Pod's main container. Option C is wrong because a sidecar container runs alongside the main container, not before it, and is used for supporting functions like logging or proxying. Option D is wrong because an ephemeral container is an ad-hoc container injected into a running Pod for debugging, not for pre-start initialization.

Practice this question →

102

MCQmedium

A developer wants to tag a local image 'myapp:latest' with the tag 'v1.0.0' for pushing to a registry. Which command does this?

A.docker push myapp:v1.0.0

B.docker tag myapp:latest myapp:v1.0.0

C.kubectl tag myapp:latest myapp:v1.0.0

D.kubectl set image myapp:v1.0.0

AnswerB

docker tag creates an additional tag for an existing local image without altering the underlying image layers or content. Its syntax is 'docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]', so 'docker tag myapp:latest myapp:v1.0.0' assigns v1.0.0 as a new alias to the same image ID as the latest tag. This is the standard way to version a local image before pushing or referencing it outside the local daemon. The original latest tag remains intact, and both tags now point to the same image digest.

Why this answer

The `docker tag` command is used to tag an existing local image with a new tag. After tagging, the image can be pushed to a registry using `docker push`. There is no `kubectl tag` command; Kubectl does not manage local image tagging. `kubectl set image` is used to update the image of a deployment, not to tag a local image.

Exam trap

The trap is that candidates might think they need to use kubectl for image operations, but tagging a local image is a Docker operation. Also, they might confuse `kubectl set image` with tagging, but that command updates a deployment's container image, not a local image tag.

How to eliminate wrong answers

Option A is wrong because `docker push` uploads an image to a registry, but it does not create a new tag; it would attempt to push an image tagged `myapp:v1.0.0` that does not exist locally. Option C is wrong because `kubectl tag` is not a valid kubectl command; kubectl does not have a `tag` subcommand for Docker images. Option D is wrong because `kubectl set image` is used to update the container image of a Kubernetes resource (e.g., a deployment), not to tag a local Docker image.

Practice this question →

103

MCQhard

A CronJob is configured with concurrencyPolicy: Forbid. The scheduled job takes longer than the interval between schedules to complete. What happens when the next scheduled time arrives while the previous job is still running?

A.The running job is killed to make room for the new one

B.The new job starts immediately, overriding the running one

C.The CronJob controller skips the new execution and logs a warning

D.The new job is queued and starts after the running job completes

AnswerC

When the scheduler fires and concurrencyPolicy: Forbid is set, the CronJob controller inspects the CronJob's .status.active list for Job references that still exist and have not completed. If at least one is found, the controller skips creating a new Job and emits an event (often surfaced as a warning, e.g., 'skipped' or 'already active') to record the missed schedule. No retry is made at that point; the next scheduled time governs future executions.

Why this answer

When `concurrencyPolicy: Forbid` is set, the CronJob controller ensures that only one instance of the job runs at a time. If the previous job is still running when the next scheduled time arrives, the controller skips the new execution entirely and logs a warning (e.g., 'job already running'). This prevents overlapping executions, which is critical for workloads that must not run concurrently.

Exam trap

The trap here is that candidates often assume Kubernetes will queue or delay the job (Option D) because that seems logical, but the CronJob controller does not implement queuing — it strictly follows the concurrencyPolicy (Allow, Forbid, or Replace) without any built-in retry or backlog mechanism.

How to eliminate wrong answers

Option A is wrong because the CronJob controller does not kill running jobs when concurrencyPolicy is Forbid; it simply skips the new execution. Option B is wrong because the new job does not start immediately or override the running one; the controller respects the Forbid policy and does not launch a second job. Option D is wrong because the controller does not queue jobs; it either allows concurrent runs (Allow), replaces the running job (Replace), or skips the new one (Forbid) — queuing is not a supported behavior.

Practice this question →

104

MCQeasy

In a Dockerfile, what is the difference between CMD and ENTRYPOINT?

A.CMD always runs, ENTRYPOINT can be overridden

B.There is no difference; they are interchangeable

C.ENTRYPOINT defines the executable and CMD provides default arguments

D.CMD is used for shell form, ENTRYPOINT for exec form

AnswerC

Correct: ENTRYPOINT sets the main executable for the container, and CMD merely supplies default arguments that can be replaced at runtime. For example, `ENTRYPOINT ["nginx"]` with `CMD ["-g", "daemon off;"]` starts nginx and allows you to run `docker run nginx -t` to test config, where `-t` replaces CMD entirely. If you override with `docker run nginx -v`, the ENTRYPOINT stays `nginx` and receives `-v`, not CMD. This separation gives image authors a stable command with flexible defaults.

Why this answer

C is correct because in a Dockerfile, ENTRYPOINT specifies the executable that will always run when the container starts, while CMD provides default arguments that can be overridden. When both are defined, CMD arguments are appended to the ENTRYPOINT command, allowing flexible default behavior that users can modify at runtime via the command line.

Exam trap

The trap here is that candidates often confuse CMD and ENTRYPOINT as interchangeable or think CMD always runs, but the CKAD exam tests the precise relationship where ENTRYPOINT defines the executable and CMD provides default arguments that can be overridden.

How to eliminate wrong answers

Option A is wrong because CMD can be overridden by providing command-line arguments at container startup, while ENTRYPOINT is the instruction that always runs unless explicitly overridden with the --entrypoint flag. Option B is wrong because CMD and ENTRYPOINT have distinct roles: ENTRYPOINT sets the main executable, and CMD supplies default arguments or a default command if ENTRYPOINT is not defined. Option D is wrong because both CMD and ENTRYPOINT support both shell form and exec form; the choice of form affects signal handling and shell processing, not the distinction between the two instructions.

Practice this question →

105

MCQhard

You need to debug a pod that is running but not serving traffic. You want to add a temporary container with networking tools to the pod. Which command should you use?

A.kubectl run debug --image=busybox -it --restart=Never -- /bin/sh

B.kubectl attach mypod

C.kubectl exec -it mypod -- /bin/sh

D.kubectl debug mypod --image=busybox -it

AnswerD

kubectl debug mypod --image=busybox -it adds an ephemeral container to the same pod, sharing the pod's network namespace, filesystem mounts, and IPC. This gives you a fresh multitool environment (busybox) without disturbing the original container, ideal for inspecting network endpoints, DNS, or routing from the pod's point of view. It is the standard, non-invasive way to debug a running pod that is not serving traffic as expected.

Why this answer

`kubectl debug` allows you to add an ephemeral container (a temporary container with networking tools) to an existing running pod without restarting it. This is the only command that directly injects a new container into the pod's network namespace, enabling debugging of network issues while the original container continues running.

Exam trap

The trap here is that candidates confuse `kubectl exec` (which runs a command in an existing container) with `kubectl debug` (which adds a new container), and they forget that `kubectl exec` requires the target container to have the necessary tools installed, which is often not the case in production images.

How to eliminate wrong answers

Option A is wrong because `kubectl run debug --image=busybox -it --restart=Never -- /bin/sh` creates a completely new, standalone pod, not a temporary container attached to the existing pod. Option B is wrong because `kubectl attach mypod` attaches to the main process of an existing container in the pod, but it does not add a new container or provide networking tools; it only connects to the container's stdin/stdout/stderr. Option C is wrong because `kubectl exec -it mypod -- /bin/sh` runs a command inside an existing container of the pod, but if that container lacks networking tools (e.g., a minimal distroless image), you cannot install them without modifying the image.

Practice this question →

106

MCQeasy

Which file prevents certain files from being copied into a Docker image during a build?

A..kubeignore

B.Dockerfile.ignore

C..dockerignore

D..gitignore

AnswerC

.dockerignore is the correct file: when running docker build, the Docker CLI reads .dockerignore from the root of the build context and excludes any matching files or directories from the context tar sent to the daemon. This prevents secrets, local caches, and unwanted files from being copied into image layers via COPY or ADD, and also shrinks the context to speed up the build. Patterns support globbing and negation with !.

Why this answer

The `.dockerignore` file is used to specify patterns for files and directories that should be excluded from the Docker build context when running `docker build`. This prevents unnecessary or sensitive files (e.g., `node_modules`, `.git`, secrets) from being sent to the Docker daemon and copied into the image, reducing build time and image size.

Exam trap

The trap here is that candidates confuse `.dockerignore` with `.gitignore` due to their similar purpose and syntax, but `.gitignore` has no effect on Docker builds, and the CKAD exam expects you to know the exact Docker-specific filename.

How to eliminate wrong answers

Option A is wrong because `.kubeignore` is not a standard file in Docker or Kubernetes; Kubernetes uses `.kubeignore` only in the context of `kubectl cp` operations to exclude files, not during Docker image builds. Option B is wrong because `Dockerfile.ignore` is not a recognized filename; Docker only supports `.dockerignore` for build context exclusion. Option D is wrong because `.gitignore` is used by Git to exclude files from version control, not by Docker to exclude files from the build context; while similar in syntax, `.gitignore` has no effect on Docker builds.

Practice this question →

107

MCQhard

You need to debug a pod that has no shell installed. You want to add a temporary container with debugging tools to the pod. Which command should you use?

A.kubectl debug mypod -it --image=busybox -- /bin/sh

B.kubectl run debug --image=busybox -it -- /bin/sh

C.kubectl debug mypod --image=busybox --target=debug -n default

D.kubectl exec -it mypod -- /bin/sh

AnswerA

kubectl debug with --image creates an ephemeral container inside the existing pod, sharing its process namespace and network, so busybox tools can inspect the running workload. This works when the original container lacks a shell, satisfying the debugging constraint.

Why this answer

`kubectl debug mypod -it --image=busybox -- /bin/sh` creates an ephemeral container in the existing pod `mypod`, attaching it interactively with a shell. This allows you to debug a pod that lacks a shell or debugging tools without modifying the original container's image or restarting the pod.

Exam trap

The trap here is that candidates confuse `kubectl debug` (which adds a container to an existing pod) with `kubectl run` (which creates a new pod), or mistakenly think `kubectl exec` can work on any container regardless of whether a shell is present.

How to eliminate wrong answers

Option B is wrong because `kubectl run debug --image=busybox -it -- /bin/sh` creates a completely new, standalone pod named `debug` rather than adding a container to the existing pod `mypod`. Option C is wrong because `--target=debug` is not a valid flag for `kubectl debug`; the `--target` flag is used for attaching to a specific container within a pod, not for specifying a debug image name. Option D is wrong because `kubectl exec -it mypod -- /bin/sh` attempts to run a shell inside an existing container, which fails if the container has no shell installed (e.g., a scratch-based image).

Practice this question →

108

MCQeasy

Which of the following Dockerfile instructions sets the working directory for any subsequent RUN, CMD, ENTRYPOINT, COPY, and ADD instructions?

A.EXPOSE

B.WORKDIR

C.COPY

D.USER

AnswerB

WORKDIR sets the working directory for all subsequent Dockerfile instructions, including RUN, CMD, ENTRYPOINT, COPY, and ADD. It automatically creates the directory if it does not exist, and it can be used multiple times to change the directory for later steps. At runtime, this becomes the initial working directory of the container process, so any relative paths or shell commands execute from that location.

Why this answer

The WORKDIR instruction sets the working directory for any subsequent RUN, CMD, ENTRYPOINT, COPY, and ADD instructions in the Dockerfile. If the directory does not exist, it will be created automatically, and it persists across all subsequent instructions until changed by another WORKDIR.

Exam trap

This question tests understanding that WORKDIR sets the working directory for subsequent instructions, distinguishing it from USER (which sets the runtime user) and COPY (which copies files).

How to eliminate wrong answers

Option A is wrong because EXPOSE is used to document which ports the container listens on at runtime; it does not affect the working directory or the execution context of subsequent instructions. Option C is wrong because COPY is a file-copying instruction that copies files from the build context into the image; it does not set or change the working directory. Option D is wrong because USER sets the user name or UID to use when running the image and for any subsequent RUN, CMD, or ENTRYPOINT instructions, but it does not set the working directory.

Practice this question →

109

MCQmedium

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?

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

B.docker run nginx CMD nginx -t

C.docker run nginx nginx -t

D.docker run --entrypoint nginx -t nginx

AnswerC

This is the correct syntax because anything after the image name in docker run becomes the command that overrides the Dockerfile's CMD instruction. The image's CMD is nginx -g daemon off, but here nginx -t replaces it entirely, causing the container to run nginx's configuration test and exit with a status indicating success or failure. This runtime override is the standard mechanism for changing the default command of a container.

Why this answer

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

Exam trap

The trap here is that candidates confuse the Docker CLI syntax with Dockerfile instructions, thinking they need to include 'CMD' or use JSON array syntax on the command line, when in reality the command is simply appended as a string after the image name.

How to eliminate wrong answers

Option A is wrong because `docker run nginx ["nginx", "-t"]` uses JSON array syntax on the command line, which Docker does not interpret as a command override; it treats the brackets and quotes as literal arguments, leading to an error or unexpected behavior. Option B is wrong because `docker run nginx CMD nginx -t` incorrectly includes the keyword 'CMD', which is not a valid Docker CLI argument; Docker expects the command directly after the image name, not a Dockerfile instruction. Option D is wrong because `docker run --entrypoint nginx -t nginx` sets the entrypoint to `nginx` and passes `-t` as an argument to the entrypoint, but this does not override the CMD correctly; it results in running `nginx -t` but also leaves the original CMD (`nginx -g 'daemon off;'`) as default arguments, which can cause conflicts or unexpected behavior depending on the entrypoint handling.

Practice this question →

110

Multi-Selectmedium

Which TWO statements are true about Kubernetes Secrets?

Select 2 answers

A.Secret data is base64 encoded in YAML manifests.

B.Secrets cannot be used as environment variables.

C.Secrets are always encrypted at rest by default.

D.Secrets can be mounted as volumes in a Pod.

E.Secrets are limited to 1KB in size.

AnswersA, D

Secret data is base64 encoded in YAML manifests. Base64 encoding is not encryption; it is an encoding scheme that converts arbitrary binary data into ASCII text, making secrets safe to include in YAML without formatting issues. However, anyone who can read the manifest can trivially decode the base64 string, so a base64-encoded secret provides no confidentiality whatsoever.

Why this answer

Kubernetes Secrets store data as base64-encoded strings in YAML manifests. This encoding is not encryption; it simply converts binary or non-printable data into an ASCII string format for safe inclusion in YAML. The base64 encoding is a standard practice for representing arbitrary data in Kubernetes resource definitions.

Exam trap

The trap here is that candidates often confuse base64 encoding with encryption, assuming it provides security, or they mistakenly believe Secrets are encrypted at rest by default, when in fact they are stored in plaintext in etcd unless explicitly configured otherwise.

Practice this question →

111

MCQhard

You have a CronJob that runs a backup every hour. Due to a network issue, some backups take longer than an hour, causing overlapping executions. You want to ensure that if a new job is scheduled while the previous one is still running, the new job is skipped. Which concurrencyPolicy should you set?

A.ConcurrencyPolicy: Skip

B.ConcurrencyPolicy: Allow

C.ConcurrencyPolicy: Forbid

D.ConcurrencyPolicy: Replace

AnswerC

Forbid is the correct concurrencyPolicy because it makes the CronJob controller check whether there is an active Job belonging to this CronJob before creating a new one. If the previous backup Job is still running, the controller skips the scheduled invocation entirely and does not start a new Job, so there is no overlap. The next backup is created at the subsequent scheduled time, exactly matching the requirement that backups stay non-overlapping.

Why this answer

Setting `concurrencyPolicy: Forbid` on a CronJob prevents a new job from being created if the previous job from the same CronJob is still running. This directly addresses the requirement to skip overlapping executions when a backup takes longer than the scheduled interval.

Exam trap

The trap here is that candidates might confuse `Forbid` with `Skip` (which is not a valid value) or incorrectly choose `Replace` thinking it will skip the new job, when in fact it kills the running job and starts a new one.

How to eliminate wrong answers

Option A is wrong because `ConcurrencyPolicy: Skip` is not a valid value; the correct keyword is `Forbid`. Option B is wrong because `ConcurrencyPolicy: Allow` is the default policy that permits concurrent job runs, which would allow overlapping executions and not solve the problem. Option D is wrong because `ConcurrencyPolicy: Replace` would terminate the currently running job and start a new one, which is not the desired behavior (the requirement is to skip, not replace).

Practice this question →

112

Multi-Selecteasy

Which TWO instructions are commonly used to add files to a Docker image during build? (Select 2)

Select 2 answers

A.COPY

B.ADD

C.ENTRYPOINT

D.RUN

E.CMD

AnswersA, B

COPY is the standard instruction for copying files or directories from the build context into the image filesystem. It performs a literal, predictable copy without additional processing, making it the recommended choice for adding local build artifacts, configuration files, and application code. Its behavior is limited to the build context, which avoids the surprises that can come from ADD's URL and tar-extraction features.

Why this answer

The COPY instruction is used to copy files and directories from the build context into the Docker image filesystem. It is the preferred method for adding local files because it is explicit and does not perform any automatic extraction or URL fetching, making builds more predictable and secure.

Exam trap

The trap here is that candidates may confuse ADD with COPY, thinking ADD is always better because of its extra features, but the CKAD exam expects you to know that COPY is the safer, more predictable choice for adding local files, and ADD should be used only when its specific behaviors (like tar extraction) are needed.

Practice this question →

113

MCQhard

You have a multi-container pod with two containers: container-A and container-B. container-B needs to access the network of container-A. Which configuration is required?

A.Define a ServiceAccount for container-B to access container-A

B.No additional configuration is needed; they share the same network namespace

C.Set hostNetwork: true in the pod spec

D.Expose the port in container-A and map it in container-B

AnswerB

Containers in a Pod share the same network namespace by design, meaning they all use the same IP address, loopback interface, and network stack. This allows container-B to simply connect to container-A's port using 127.0.0.1 or localhost. Kubernetes automatically configures this shared namespace, so no additional YAML settings, port mappings, or service definitions are required for inter-container communication.

Why this answer

In Kubernetes, containers within the same pod share the same network namespace by default, including the same IP address and port space. This means container-B can reach container-A via localhost and the port that container-A is listening on, without any additional configuration. The shared network namespace is a fundamental property of pod design, enabling direct inter-container communication.

Exam trap

The trap here is that candidates often think inter-container communication requires services or explicit port exposure, forgetting that containers in the same pod inherently share the network stack and can communicate via localhost.

How to eliminate wrong answers

Option A is wrong because a ServiceAccount controls authentication and authorization for API access, not network connectivity between containers in the same pod; network namespace sharing is independent of RBAC. Option C is wrong because setting hostNetwork: true makes the pod use the node's network stack, which is unnecessary and changes the pod's IP to the node's IP, breaking the default shared pod network namespace. Option D is wrong because port mapping is not required; containers in the same pod communicate via localhost and the target container's port directly, as they share the same network namespace without any port forwarding.

Practice this question →

114

Multi-Selecthard

Which THREE of the following are correct about init containers? (Select THREE.)

Select 3 answers

A.They run to completion before the main application containers start

B.They cannot have resource limits set

C.If an init container fails, the pod restarts according to the pod's restartPolicy

D.They run after the main application containers have started

E.They are defined in the spec.initContainers field of a Pod

AnswersA, C, E

Init containers run sequentially and are executed by the kubelet before any container in the regular spec.containers list starts. Each init container must exit with status 0; only after all init containers have completed successfully will the main application containers be launched. This ensures required setup, like waiting for a database or applying schema migrations, is finished before app processes begin.

Why this answer

Init containers are designed to run sequentially to completion before any of the pod's regular application containers start. This ensures that prerequisites, such as database schema migrations or configuration file generation, are completed before the main application begins execution.

Exam trap

The CKAD exam often tests the misconception that init containers cannot have resource limits or that they run after main containers, but the key is that they run before and can have resource constraints just like regular containers.

Practice this question →

115

MCQeasy

An init container in a pod runs a database migration script. The init container fails and exits with a non-zero exit code. What will happen to the pod?

A.The main containers will start anyway

B.The pod will enter CrashLoopBackOff

C.The init container will be restarted until it succeeds

D.The pod will be deleted and recreated

AnswerC

Init containers run to completion before app containers start, so a non-zero exit triggers the pod's restart policy. With the default Always, kubelet reruns that init container until it succeeds, satisfying the stem's requirement that the migration script complete before the pod proceeds.

Why this answer

Init containers run to completion before any app containers start, and Kubernetes treats a non-zero exit as a failure of that init container. The kubelet will restart the failed init container according to the pod's restartPolicy (default Always), retrying until it succeeds. Only after all init containers exit 0 will the main containers be started.

Exam trap

CKAD often tests the confusion between init-container retry behavior (Init:CrashLoopBackOff, retried until success) and main-container CrashLoopBackOff, leading candidates to pick the generic CrashLoopBackOff answer.

How to eliminate wrong answers

Option A is wrong because main containers never start until every init container completes successfully — that is the defining behavior of init containers. Option B is wrong because CrashLoopBackOff describes repeated crashes of main containers (or the pod sandbox), not the init-container retry loop; the pod shows Init:CrashLoopBackOff or Init:Error, which is a distinct status. Option D is wrong because the pod object is not deleted and recreated by the kubelet on init failure; the same pod is retried in place unless a controller (Deployment/Job) replaces it under its own policy.

Practice this question →

116

MCQmedium

You have a Pod with two containers: a main application and a sidecar that handles logging. The sidecar needs access to the same log files as the main application. Which volume type allows both containers to share files?

A.persistentVolumeClaim

B.hostPath

C.configMap

D.emptyDir

AnswerD

emptyDir creates an empty directory when a pod is assigned to a node, and it remains available as long as the pod runs, allowing all containers in the pod to mount the same volume and share files seamlessly. It is the standard Kubernetes mechanism for inter-container communication via the filesystem, and it requires no persistent storage provisioning or external dependencies. Because the log files only need to exist for the pod's lifetime and must be shared between the main application and the logging sidecar, emptyDir exactly matches the requirement.

Why this answer

An `emptyDir` volume is created when a Pod is assigned to a node and exists as long as the Pod runs, allowing both containers in the same Pod to mount and share the same directory. This is the simplest and most appropriate volume type for sharing ephemeral data, such as log files, between a main application and a sidecar container within the same Pod.

Exam trap

The trap here is that candidates often confuse `emptyDir` with `hostPath` or `persistentVolumeClaim` because they think of 'shared storage' in terms of persistent or host-level volumes, but the CKAD exam specifically tests the Pod-level ephemeral sharing pattern using `emptyDir` for sidecar containers.

How to eliminate wrong answers

Option A is wrong because a `persistentVolumeClaim` is used to request persistent storage that survives Pod restarts and is typically used for data that must persist beyond the Pod's lifecycle, not for sharing files between containers within the same Pod. Option B is wrong because a `hostPath` volume mounts a file or directory from the host node's filesystem into the Pod, which introduces node-specific dependencies and is not recommended for sharing data between containers in a multi-container Pod; it also violates Pod portability. Option C is wrong because a `ConfigMap` is designed to inject configuration data (key-value pairs or small files) into containers, not for sharing dynamic, writable log files between containers; it is read-only by default and cannot be used for runtime file sharing.

Practice this question →

117

Multi-Selectmedium

Which TWO of the following are true about .dockerignore files?

Select 2 answers

A.They are optional and have no effect on the build

B.They are placed in the root of the build context

C.They can exclude files from being sent to the Docker daemon during build

D.They can be used to ignore files only for specific build stages

E.They can include files that are in parent directories

AnswersB, C

Docker expects the .dockerignore file to be located at the root of the build context—the same directory from which you run the `docker build` command (often the directory containing the Dockerfile). It is not discovered automatically if placed in a subdirectory or parent directory; the daemon reads it from the root of the context archive it receives. This placement lets Docker apply the ignore rules before any files are sent over the daemon API.

Why this answer

The .dockerignore file must be placed in the root of the build context (the directory specified as the build context in the `docker build` command). The Docker client reads this file to determine which files and directories to exclude from the build context before sending it to the Docker daemon. Without it in the correct location, the ignore rules are not applied.

Exam trap

The trap in this question is that candidates often think .dockerignore is optional and has no effect (option A) or that it can limit to specific build stages (option D). However, in the CKAD exam context, you must know that .dockerignore is a single global file placed at the root of the build context. It reduces the size of the context sent to the Docker daemon, improving build performance.

It cannot be scoped to individual stages; any ignore rules apply to the entire build context.

Practice this question →

118

MCQmedium

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?

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

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

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

D.COPY --from=builder /app/artifact /app/

AnswerD

This is the correct multi-stage copy directive: the --from=builder flag tells Docker to retrieve /app/artifact from the filesystem of the stage named 'builder' (created with FROM ... AS builder) and place it at /app/ in the current stage. COPY preserves permissions and is the standard way to transplant compiled artifacts between stages without including the entire build environment in the final image.

Why this answer

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.

Exam trap

This question tests the distinction between COPY and ADD in multi-stage builds. The trap is that candidates may confuse ADD's additional features (like URL fetching or tar extraction) with the --from flag, or mistakenly think ENTRYPOINT or CMD can be used for file operations.

How to eliminate wrong answers

Option A is wrong because ADD does support --from for multi-stage builds, but it is not the idiomatic or recommended instruction for copying artifacts; COPY is preferred for its simplicity and predictability. Option B is wrong because ENTRYPOINT defines the container's entry point command, not a file copy operation, and does not support --from. Option C is wrong because CMD provides default command arguments for the container, not file copying, and also lacks --from support.

Practice this question →

119

MCQhard

An administrator creates a Pod with an ephemeral container using 'kubectl debug my-pod -it --image=busybox --target=my-container'. The ephemeral container shares the same process namespace as the target container. Which flag enables this?

A.--target

B.--container

C.--namespace

D.--share-process-namespace

AnswerA

--target is the correct flag because it tells kubectl debug which container within the target Pod should serve as the namespace source for the ephemeral container. Without --target, the ephemeral container is created with its own network and process namespaces, so it cannot see the processes or network interfaces of other containers, severely limiting debugging. The flag's value must match a container name in the Pod spec, and it is supported only in kubectl debug, not in kubectl exec.

Why this answer

The `--target` flag in `kubectl debug` specifies the target container within the Pod for the ephemeral container. When used, the ephemeral container shares the same process namespace as the target container, allowing tools like `ps` to see processes from the target container. This is essential for debugging scenarios where you need to inspect or interact with the target container's processes.

Exam trap

The CKAD exam often tests the distinction between Pod-level process namespace sharing (via `shareProcessNamespace` in the Pod spec) and the ephemeral container's `--target` flag, leading candidates to mistakenly choose `--share-process-namespace` when the question specifically asks about `kubectl debug`.

How to eliminate wrong answers

Option B is wrong because `--container` is used to specify the container name when attaching or executing commands in a Pod, not to enable process namespace sharing with an ephemeral container. Option C is wrong because `--namespace` is a kubectl flag for specifying the Kubernetes namespace of the resource, not for process namespace sharing. Option D is wrong because `--share-process-namespace` is a Pod-level field in the Pod spec (not a kubectl debug flag) that enables process namespace sharing between regular containers in the same Pod, not specifically for ephemeral containers created via `kubectl debug`.

Practice this question →

120

Multi-Selecthard

Which THREE are valid patterns for multi-container Pods?

Select 3 answers

A.Init

B.Ambassador

C.Replicator

D.Adapter

E.Sidecar

AnswersB, D, E

The Ambassador pattern deploys a sidecar container that proxies all inbound and outbound network traffic for the main application container, abstracting service discovery, load balancing, and circuit-breaking logic away from the application code. This satisfies the CKAD requirement for multi-container Pods that handle cross-cutting infrastructure concerns without modifying the primary process.

Why this answer

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

Exam trap

The trap here is that candidates may confuse Init containers (which run to completion) with multi-container patterns that run concurrently, or they may invent patterns like 'Replicator' that sound plausible but are not defined in Kubernetes documentation.

Practice this question →

121

MCQmedium

Which of the following is the correct way to set a memory limit of 512Mi for a container in a pod spec?

A.resources.requests.memory: 512Mi

B.resources.limits.memory: 512Mi

C.resources.requests.limits.memory: 512Mi

D.resources.limits.cpu: 512Mi

AnswerB

This is correct because resources.limits.memory defines the hard upper bound on memory that the container can use. When the container's memory usage exceeds this value, the kernel will terminate the container with an OOMKilled error (if memory pressure exists) or the container will be evicted. It also affects the pod's Quality-of-Service class, especially when paired with a matching request.

Why this answer

`resources.limits.memory` is the Kubernetes field used to set the maximum amount of memory a container is allowed to use. When a container exceeds this limit, it may be terminated or OOM-killed. The value `512Mi` specifies 512 mebibytes, which is a binary-based unit commonly used in Kubernetes resource specifications.

Exam trap

The trap here is that candidates often confuse `requests` (guarantees) with `limits` (caps), or misplace the `limits` field as a subfield of `requests`, leading them to pick option C or A instead of the correct B.

How to eliminate wrong answers

Option A is wrong because `resources.requests.memory` sets the minimum guaranteed memory for the container, not a hard limit; the container can burst above this value if the node has spare memory. Option C is wrong because `resources.requests.limits.memory` is an invalid path — `limits` is not a subfield of `requests`; the correct hierarchy places `limits` and `requests` as siblings under `resources`. Option D is wrong because `resources.limits.cpu` sets a CPU limit, not a memory limit, and `512Mi` is a memory unit, not a valid CPU unit (CPU uses millicores like `500m` or whole cores).

Practice this question →

122

MCQmedium

You run 'kubectl run nginx --image=nginx --restart=Never --dry-run=client -o yaml'. What is the output?

A.A Pod manifest with apiVersion: v1beta1

B.A Pod manifest with apiVersion: v1

C.A Job manifest with apiVersion: batch/v1

D.A Deployment manifest with apiVersion: apps/v1

AnswerB

Running `kubectl run nginx --image=nginx --restart=Never` generates a standalone Pod manifest with `apiVersion: v1` and `kind: Pod`, because `--restart=Never` explicitly disables controller-managed restart behavior. The core `v1` API is the correct, stable group/version for Pods. This single-container manifest simply declares the nginx image and a `restartPolicy: Never` in the Pod spec.

Why this answer

The command `kubectl run nginx --image=nginx --restart=Never --dry-run=client -o yaml` creates a Pod manifest because `--restart=Never` explicitly sets the restart policy to Never, which is a Pod-level field. The `kubectl run` command without `--restart=Never` defaults to creating a Deployment, but with `--restart=Never`, it generates a standalone Pod. The output uses `apiVersion: v1`, which is the correct and stable API version for Pods.

Exam trap

The trap here is that candidates often assume `kubectl run` always creates a Deployment, forgetting that the `--restart` flag changes the resource type, and they may also mistakenly think Pods use a beta API version.

How to eliminate wrong answers

Option A is wrong because Pods use `apiVersion: v1`, not `v1beta1`; `v1beta1` was deprecated and removed in Kubernetes 1.22, and Pods have been stable at v1 since early Kubernetes versions. Option C is wrong because a Job manifest would require `apiVersion: batch/v1` and a different command (e.g., `kubectl create job` or `kubectl run` with `--restart=OnFailure`), but `--restart=Never` forces a Pod, not a Job. Option D is wrong because a Deployment manifest uses `apiVersion: apps/v1` and is generated only when `--restart` is not specified (defaults to `Always`), but `--restart=Never` overrides that default to produce a Pod.

Practice this question →

123

MCQmedium

You are tasked with building a container image for a Node.js application. The Dockerfile must first install system dependencies, then copy application code, and finally run the app. Which of the following Dockerfiles is correct?

A.FROM node:14\nCMD apt-get update && apt-get install -y build-essential\nCOPY . /app\nCMD ["node","app.js"]

B.FROM node:14\nRUN apt-get update && apt-get install -y build-essential\nCOPY . /app\nRUN ["node","app.js"]

C.FROM node:14\nRUN apt-get update && apt-get install -y build-essential\nCOPY . /app\nCMD ["node","app.js"]

D.FROM node:14\nRUN apt-get update && apt-get install -y build-essential\nCOPY . /app\nENTRYPOINT ["node","app.js"]

AnswerC

The Dockerfile orders instructions correctly: FROM sets the base image, RUN installs system dependencies, then COPY brings in application code, and CMD starts the app. This satisfies the stem's required sequence of installing dependencies before copying code and running the app.

Why this answer

It follows the required order: first installs system dependencies using RUN (which executes at build time), then copies application code with COPY, and finally uses CMD to define the default command that runs the Node.js app at container runtime. CMD is the appropriate instruction for specifying the executable when the container starts, as opposed to RUN which would execute during image build and fail to run the app.

Exam trap

In the CKAD exam, candidates often confuse RUN (build-time execution) with CMD (runtime command). For this Dockerfile, using RUN for the final app command would execute during build, not at container start. Placing CMD before COPY or using ENTRYPOINT incorrectly can cause build errors or unexpected behavior.

How to eliminate wrong answers

Option A is wrong because it uses CMD instead of RUN for installing dependencies, so apt-get commands are not executed during image build and will run at container start, potentially failing due to missing package lists or incorrect order. Option B is wrong because it uses RUN ["node","app.js"] which attempts to execute the Node.js app during image build, but the app code is copied after the RUN instruction in the Dockerfile, so the file does not exist at that point, causing a build failure. Option D is wrong because it uses ENTRYPOINT instead of CMD; while ENTRYPOINT can also run the app, the question specifically asks for CMD to run the app, and using ENTRYPOINT changes the container's behavior (e.g., it cannot be overridden by command-line arguments without --entrypoint flag), making it incorrect for this scenario.

Practice this question →

124

MCQeasy

Which YAML snippet correctly defines a CronJob that runs a task every 5 minutes?

A.schedule: "*/5 * * *"

B.schedule: "*/5 * * * *"

C.schedule: "0 */5 * * *"

D.schedule: "* * * * *"

AnswerB

This is the standard five-field cron expression where the minute field uses the step operator */5, meaning it matches minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55. Since all other fields (hour, day of month, month, day of week) are wildcards, the job executes every five minutes around the clock, exactly as required.

Why this answer

The standard cron expression for 'every 5 minutes' is `*/5 * * * *`, which matches the required five fields (minute, hour, day of month, month, day of week). Kubernetes CronJob uses this exact format, where `*/5` in the minute field means 'every 5 minutes' and the four asterisks mean 'every hour, every day, every month, every weekday'.

Exam trap

The CKAD exam often tests the distinction between `*/5 * * * *` (every 5 minutes) and `0 */5 * * *` (every 5 hours), which is a classic trap where candidates confuse the minute and hour fields in cron syntax.

How to eliminate wrong answers

Option A is wrong because it has only five asterisk-like fields but is missing the fifth field (day of week), which makes it an invalid cron expression for Kubernetes; the correct format requires exactly five fields. Option C is wrong because `0 */5 * * *` means 'at minute 0 of every 5th hour' (i.e., every 5 hours at the top of the hour), not every 5 minutes. Option D is wrong because `* * * * *` means 'every minute', not every 5 minutes.

Practice this question →

125

MCQeasy

What is the correct apiVersion for a Kubernetes Job in v1.29?

A.batch/v1beta1

B.apps/v1

C.batch/v1

D.v1

AnswerC

Since Kubernetes v1.21, Jobs are served by the stable batch/v1 API version, and this remains true in v1.29. batch/v1 is the only non-deprecated, enabled version for Jobs, offering full production functionality including parallelism, backoffLimit, and TTL cleanup. Any current cluster requires apiVersion: batch/v1 for Job resources.

Why this answer

Kubernetes Jobs are part of the batch API group, and starting from Kubernetes v1.21, the batch/v1 API version is stable and the only supported version for Jobs. In v1.29, batch/v1beta1 has been removed, so batch/v1 is the correct and required apiVersion.

Exam trap

The trap here is that candidates may recall older Kubernetes versions where batch/v1beta1 was still available, or confuse the batch API group with apps/v1 or core v1, leading them to select an incorrect apiVersion for a Job in v1.29.

How to eliminate wrong answers

Option A is wrong because batch/v1beta1 was deprecated in Kubernetes v1.21 and removed in v1.25, so it is not valid for v1.29. Option B is wrong because apps/v1 is used for workloads like Deployments, StatefulSets, and DaemonSets, not for Jobs. Option D is wrong because v1 is the core API group (e.g., Pods, Services) and does not include Job resources.

Practice this question →

126

MCQmedium

You have a Dockerfile that uses a multi-stage build. Which of the following statements about multi-stage builds is correct?

A.Multi-stage builds require a single FROM statement

B.Multi-stage builds increase the final image size

C.Each stage must have a unique name

D.Artifacts from earlier stages can be copied to later stages using COPY --from

AnswerD

COPY --from=<stage> is the mechanism that makes multi-stage builds effective, letting you select a named stage or a numeric index and copy specific files or directories into the current build stage. This allows the final stage to contain only the runtime and essential artifacts, not the compiler, headers, or source code from earlier stages. This is a correct statement and is the core feature of multi-stage builds.

Why this answer

Multi-stage builds allow you to copy artifacts from a previous stage using the `COPY --from=<stage_name_or_index>` instruction. This enables you to keep only the necessary runtime artifacts in the final image, significantly reducing image size by discarding build-time dependencies and intermediate layers.

Exam trap

The trap here is that candidates often assume all stages must have unique names or that multi-stage builds increase image size, when in fact the key benefit is size reduction and stages can be referenced by index without names.

How to eliminate wrong answers

Option A is wrong because multi-stage builds require at least two FROM statements, not a single one; each FROM starts a new stage. Option B is wrong because multi-stage builds are specifically designed to reduce the final image size by excluding build tools and intermediate files from the final stage. Option C is wrong because stages can be referenced by their index (e.g., FROM 0) or by an optional name assigned with AS, but names are not required; unnamed stages are allowed.

Practice this question →

127

MCQmedium

A developer is building an image for a Node.js application. The Dockerfile currently copies package.json and package-lock.json, runs npm ci, then copies the rest of the source code. They want to ensure that rebuilding the image after only editing application source files does not re-run npm ci. Which statement about Docker layer caching explains why this Dockerfile ordering achieves that goal?

A.Docker caches the result of every RUN instruction globally in the local image store keyed by the command string, so npm ci is skipped whenever the same command appears in any Dockerfile on the host.

B.The COPY instruction always invalidates all subsequent layers, so placing COPY package.json before npm ci forces npm ci to run only when the source code changes.

C.Docker automatically detects that npm ci is a dependency installation step and caches its output separately from the image layers, independent of Dockerfile instruction order.

D.Each Dockerfile instruction creates a layer; a layer is reused from cache if its instruction and the contents of files it references are unchanged, so npm ci is only invalidated when the dependency manifests change.

AnswerD

Docker builds images layer by layer, and a cached layer is reused when the instruction text and the copied file contents are identical. Since package.json and package-lock.json are copied before the source, editing only source files does not invalidate the earlier npm ci layer, so dependencies are not reinstalled.

Why this answer

Docker layer caching reuses a layer when its instruction and referenced file contents match the previous build. Copying dependency manifests first and running npm ci before copying source code means source edits do not invalidate the dependency layer, so npm ci is skipped and rebuilds are faster.

Exam trap

The trap here is assuming Docker understands package managers or caches command results globally, rather than caching layers keyed by instruction and file content.

Practice this question →

128

MCQmedium

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?

A.spec.containers[].entrypoint

B.spec.containers[].command

C.spec.containers[].args

D.spec.command

AnswerC

The `spec.containers[].args` field is correct because it directly overrides the Dockerfile's CMD instruction—the default argument list passed to the image's ENTRYPOINT. In this image, the ENTRYPOINT is `/app.sh`, and setting `args` to `['--debug']` replaces the default CMD arguments with `--debug`, resulting in the container process `/app.sh --debug`. This preserves the original entrypoint while changing its arguments, which is exactly what the developer intends.

Why this answer

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

Exam trap

The CKAD exam often tests the confusion between `command` (overrides ENTRYPOINT) and `args` (overrides CMD), leading candidates to incorrectly choose `command` when they only need to append arguments to the existing command.

How to eliminate wrong answers

Option A is wrong because `spec.containers[].entrypoint` is not a valid Kubernetes field; the correct field to override the image's ENTRYPOINT is `command`. Option B is wrong because `spec.containers[].command` overrides the image's ENTRYPOINT, not the CMD; using it would replace the entire command, not just append `--debug`. Option D is wrong because `spec.command` is not a valid field at the pod spec level; the correct path is `spec.containers[].command`.

Practice this question →

129

MCQmedium

A pod named 'webapp' is stuck in 'Pending' state. 'kubectl describe pod webapp' shows '0/1 nodes are available: 1 Insufficient memory'. What is the most likely cause?

A.The node has insufficient CPU

B.The container was killed due to out-of-memory

C.The pod's memory request exceeds available node memory

D.The container image does not exist

AnswerC

When a pod requests more memory than is allocatable on any node in the cluster, the Kubernetes scheduler cannot find a suitable placement and leaves the pod in `Pending` with an event such as `0/3 nodes are available: insufficient memory`. Memory is a non-compressible resource, so the scheduler treats a memory request as a hard guarantee and refuses to place the pod where satisfying it would overcommit available allocatable memory. Since no candidate node can accommodate the specified memory request, the pod remains unscheduled until capacity is freed or the request is reduced.

Why this answer

The error message '0/1 nodes are available: 1 Insufficient memory' directly indicates that the pod's memory request exceeds the allocatable memory on the node. The scheduler cannot place the pod because no node has enough unallocated memory to satisfy the pod's memory request. This is a scheduling failure, not a runtime issue.

Exam trap

Kubernetes certification exams often test the distinction between scheduling failures (Pending state) and runtime failures (CrashLoopBackOff, OOMKilled) to see if candidates confuse resource requests with limits or confuse scheduling with execution.

How to eliminate wrong answers

Option A is wrong because the error explicitly mentions 'Insufficient memory', not CPU; insufficient CPU would produce a different message like 'Insufficient cpu'. Option B is wrong because a container killed due to out-of-memory (OOM) would result in a CrashLoopBackOff or OOMKilled state, not a Pending state; Pending means the pod has not yet been scheduled to a node. Option D is wrong because a missing container image would cause an ErrImagePull or ImagePullBackOff event, not a Pending state with a scheduling failure message.

Practice this question →

130

MCQmedium

You have a pod with two containers: one runs a web server, and the other is a sidecar that logs the web server's output to a central logging system. Which pattern does this represent?

A.Sidecar pattern

B.Decorator pattern

C.Ambassador pattern

D.Adapter pattern

AnswerA

The sidecar pattern adds a helper container to the same pod as the main application container. The helper extends or enhances the main container's behavior, such as by collecting logs, forwarding metrics, or managing file synchronization. Both containers share the pod lifecycle, so they start and stop together, and can communicate via localhost or a shared volume. This matches a web server paired with a logging agent or similar enhancement.

Why this answer

The sidecar pattern involves deploying a helper container alongside the main application container within the same pod. In this scenario, the sidecar container consumes the web server's logs (e.g., by tailing a shared volume or reading stdout/stderr) and forwards them to a central logging system, such as Elasticsearch or Fluentd. This pattern is a core Kubernetes design principle for extending or enhancing the main container without modifying its code.

Exam trap

In the CKAD exam, the sidecar pattern is often tested by describing a helper container that performs a supporting function (like logging, monitoring, or proxying), and the trap is confusing it with the ambassador pattern, which specifically handles network proxying or service discovery, not log forwarding.

How to eliminate wrong answers

Option B (Decorator pattern) is wrong because the decorator pattern typically involves attaching additional responsibilities to an object dynamically, not deploying a separate container to handle cross-cutting concerns like logging. Option C (Ambassador pattern) is wrong because an ambassador container acts as a proxy for network traffic to or from the main container (e.g., for service discovery or rate limiting), not for log forwarding. Option D (Adapter pattern) is wrong because an adapter container standardizes interfaces or data formats between the main container and external systems (e.g., converting metrics output), whereas logging is a sidecar responsibility.

Practice this question →

131

MCQeasy

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

A.To check the health of the main container and restart it if necessary

B.To run alongside the main container and provide additional services

C.To run to completion before the main containers start, often for initialization tasks

D.To run a command after the main container starts

AnswerC

Init containers run sequentially to completion before the main containers start, performing setup such as fetching configuration, waiting for dependencies or setting permissions. Because they finish first, the main containers begin only once initialisation succeeds, which is their defining purpose within the pod lifecycle.

Why this answer

Init containers run to completion sequentially before any main containers in the pod start. They are designed for initialization tasks such as setting up databases, waiting for external services, or populating configuration files. Unlike sidecar containers, they do not run alongside the main containers and must exit successfully before the pod transitions to the Running phase.

Exam trap

CKAD often tests the distinction between init containers and sidecar containers, where candidates mistakenly think init containers run alongside main containers or perform health checks, when in fact they run to completion before any main containers start.

How to eliminate wrong answers

Option A is wrong because health checks (liveness probes) are performed by the kubelet on the main container, not by an init container. Option B is wrong because containers that run alongside the main container are sidecar containers, not init containers. Option D is wrong because init containers run before the main containers start, not after; a postStart lifecycle hook runs a command after the main container starts, but that is not an init container.

Practice this question →

132

MCQeasy

Which field in a CronJob spec specifies the maximum number of successful jobs that should be retained?

A..spec.jobTemplate.spec.backoffLimit

B..spec.successfulJobsHistoryLimit

C..spec.jobHistory.succeeded

D..spec.history.successfulJobsLimit

AnswerB

The correct field is .spec.successfulJobsHistoryLimit, a top-level CronJob spec attribute that sets the maximum number of successfully completed Job objects to keep. Its default value is 3, and setting it to zero disables retention entirely, causing the CronJob controller to delete each successful Job as soon as it finishes. This field directly controls the number of historical Job objects visible in the cluster, distinct from failedJobsHistoryLimit which governs failed Jobs.

Why this answer

The `.spec.successfulJobsHistoryLimit` field in a CronJob spec explicitly controls the number of successful jobs that are retained after completion. This field defaults to 3 and, when set to 0, suppresses the retention of any successful job history, directly managing cluster resource usage by limiting the accumulation of completed Pods.

Exam trap

The trap here is that candidates confuse `backoffLimit` (retry logic) with history limits, or invent plausible-sounding field paths like `.spec.jobHistory.succeeded` that mimic the correct field but use incorrect nesting or naming.

How to eliminate wrong answers

Option A is wrong because `.spec.jobTemplate.spec.backoffLimit` defines the number of retries for a failed Job (default 6), not the retention of successful jobs. Option C is wrong because `.spec.jobHistory.succeeded` is not a valid field in the CronJob API; the correct field path is `.spec.successfulJobsHistoryLimit`. Option D is wrong because `.spec.history.successfulJobsLimit` does not exist in the Kubernetes API; the proper field uses `successfulJobsHistoryLimit` under the spec, not a nested `history` object.

Practice this question →

133

MCQhard

You are deploying a Pod that contains two containers: a web server and a file sync agent. The file sync agent needs to run as long as the web server is running and should share the same network namespace. Which design pattern does this represent?

A.Adapter pattern

B.Ambassador pattern

C.Init container pattern

D.Sidecar pattern

AnswerD

The sidecar pattern is precisely the design where an additional container is deployed in the same Pod alongside the main application container to augment its capabilities without changing its code. Sidecars share the Pod lifecycle and can provide functionality such as log collection, metrics scraping, health endpoints, or service mesh traffic handling. This matches the described scenario of a web container being paired with a supporting service, making the sidecar pattern the correct answer.

Why this answer

The Sidecar pattern (D) is correct because it describes a secondary container that runs alongside a primary container in the same Pod, sharing the same network namespace and lifecycle. In this scenario, the file sync agent is a helper that must run as long as the web server runs and share its network stack, which is exactly what a sidecar container does — it extends or enhances the primary container's functionality without being its own separate Pod.

Exam trap

The trap here is confusing the Sidecar pattern with the Init container pattern, because both involve multiple containers in a Pod, but Init containers run to completion before the main containers start and do not share the network namespace during the main container's runtime.

How to eliminate wrong answers

Option A is wrong because the Adapter pattern standardizes interfaces between containers (e.g., converting logs or metrics formats), not sharing a network namespace or running alongside for the entire lifecycle. Option B is wrong because the Ambassador pattern proxies network traffic to external services (e.g., a Redis proxy), not synchronizing files locally with the primary container. Option C is wrong because the Init container pattern runs to completion before the main containers start and does not share the network namespace with the main containers during runtime; it exits after initialization, whereas the file sync agent must run continuously.

Practice this question →

134

MCQmedium

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?

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

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

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

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

AnswerD

This is the correct configuration because .spec.completions specifies the exact number of Pods that must finish successfully (100), and .spec.parallelism limits how many of those Pods can run simultaneously (10). The Job controller creates Pods in waves, using the parallelism value as an upper bound on concurrent execution, while tracking cumulative completions until the target of 100 is reached. This matches the requirement of processing 100 items with up to 10 Pods running at once.

Why this answer

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.

Exam trap

The trap here is confusing the roles of `.spec.completions` and `.spec.parallelism`, where candidates often swap the values (e.g., setting completions to the concurrency limit) or omit completions entirely, not realizing that both fields are needed to define a parallel Job with a fixed total number of completions.

How to eliminate wrong answers

Option A is wrong because it sets `.spec.completions` to 10 and `.spec.parallelism` to 100, which would only require 10 successful completions (not 100 items) and allow up to 100 concurrent pods, exceeding the limit of 10. Option B is wrong because `.spec.backoffLimit` controls retries on failure, not the number of completions or parallelism; setting it to 100 does not define the total items to process, and `.spec.parallelism` alone without `.spec.completions` defaults to 1 completion, so only one pod would run. Option C is wrong because `.spec.parallelism` is set to 1, which runs pods sequentially, not concurrently, failing the requirement to run up to 10 pods at once.

Practice this question →

135

MCQhard

A Pod with an init container and a main container is created. The init container runs a script that takes 10 seconds. The main container's startupProbe has initialDelaySeconds: 5. When does the startupProbe begin?

A.5 seconds after the pod is created

B.10 seconds after the pod is created

C.Immediately after the pod is created

D.After the init container completes, then plus 5 seconds

AnswerD

The startupProbe begins only after the main container has entered the Running state, which is possible only after all init containers complete successfully. At that point, the kubelet waits the configured initialDelaySeconds—here, 5 seconds—before performing the first probe. Hence the first probe occurs at the init container's total runtime plus 5 seconds, not at pod creation plus 5 seconds.

Why this answer

The startupProbe does not begin until the Pod's containers are actually running. Init containers must complete successfully before any main containers start. Therefore, the startupProbe's initialDelaySeconds of 5 is counted from the moment the main container starts, which is after the init container finishes its 10-second script.

The probe begins 5 seconds after the main container starts, not from Pod creation.

Exam trap

The trap here is that candidates mistakenly think probes start counting from Pod creation time, ignoring the sequential blocking nature of init containers, which must complete before any main container probes are scheduled.

How to eliminate wrong answers

Option A is wrong because it assumes the startupProbe begins 5 seconds after Pod creation, ignoring that init containers must finish first. Option B is wrong because it assumes the probe begins immediately after the init container completes, but the initialDelaySeconds of 5 is still applied after the main container starts. Option C is wrong because probes never begin immediately upon Pod creation; they wait for the container to start and respect any initialDelaySeconds.

Practice this question →

136

MCQhard

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?

A.Faster builds because the builder stage runs in parallel

B.Reduced final image size by excluding build dependencies

C.Automatic caching of the builder stage

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

AnswerB

The final image is produced by the last `FROM` line, which in this pattern is a fresh minimal base image. Only specific files copied from the builder stage (e.g., compiled binary, configs) are preserved, while compilers, package managers, and intermediate layer caches from the builder are discarded. This slims the image and simultaneously reduces the number of packages that could contain vulnerabilities.

Why this answer

The primary benefit of a multi-stage build is reduced final image size by excluding build dependencies. The builder stage installs build tools like curl and compiles the application, but only the compiled binary is copied to the final stage, leaving behind the build tools and intermediate files. This results in a smaller, more secure production image.

Exam trap

CKAD often tests the misconception that multi-stage builds primarily improve build speed or security, when the core benefit is reducing final image size by excluding build dependencies.

How to eliminate wrong answers

Option A is wrong because Docker build stages do not run in parallel by default; they run sequentially unless BuildKit is used with specific optimizations, and the primary benefit is not faster builds. Option C is wrong because while Docker layer caching can speed up builds, it is not the primary benefit of multi-stage builds and requires proper layer ordering. Option D is wrong because the Dockerfile does not specify a non-root user for the builder stage, and improved security is a secondary benefit, not the primary one.

Practice this question →

137

MCQeasy

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

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

B.kubectl create job data-processor --image=myapp/processor:1.0

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

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

AnswerB

kubectl create job data-processor --image=myapp/processor:1.0 explicitly creates a Job resource, which is the designated controller for finite tasks that must run to completion. The Job controller will create a Pod from the specified image and monitor it; with default settings, it runs a single Pod and marks the Job as complete when that Pod exits with code 0. It also provides automatic retries on failure up to the backoffLimit, making it the correct imperative command for a one-time batch task.

Why this answer

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

Exam trap

The trap here is that candidates often confuse `kubectl run` with `--restart=Never` as a valid way to create a Job, but it only creates a Pod, missing the Job controller's automatic retry and completion tracking.

How to eliminate wrong answers

Option A is wrong because `kubectl create deployment` creates a Deployment, which manages a ReplicaSet to maintain a desired number of pods running continuously, not a single task to completion. Option C is wrong because `kubectl run` with `--restart=Never` creates a standalone Pod, not a Job; the Pod will not be automatically retried if it fails, and it lacks the Job controller's lifecycle management. Option D is wrong because `kubectl create cronjob` creates a CronJob, which schedules Jobs on a recurring basis, not a one-time task.

Practice this question →

138

Multi-Selecthard

Which THREE statements about Dockerfile CMD and ENTRYPOINT are correct?

Select 3 answers

A.CMD is always ignored if ENTRYPOINT is defined.

B.CMD can be overridden at container runtime by specifying a command after the image name.

C.ENTRYPOINT can be overridden at container runtime using the --entrypoint flag.

D.If both CMD and ENTRYPOINT are specified, CMD provides default arguments to ENTRYPOINT.

E.If neither CMD nor ENTRYPOINT is specified, the container will run but exit immediately.

AnswersB, C, D

When you run a container, any command-line arguments you place after the image name are passed to the image's entrypoint and replace the CMD instruction entirely. This behavior is fundamental to how Docker separates the immutable executable (ENTRYPOINT) from the default parameters (CMD), allowing runtime flexibility without rebuilding the image. For example, `docker run nginx -v` overrides the CMD (e.g., `nginx -g daemon off;`) with `-v`, which would be interpreted by the entrypoint.

Why this answer

Only three statements are correct. Option A is false because CMD is not ignored when ENTRYPOINT is defined; CMD provides default arguments to ENTRYPOINT. Option B is correct: specifying a command after the image name at runtime overrides CMD.

Option C is correct: ENTRYPOINT can be overridden with `--entrypoint` flag. Option D is correct: CMD provides default arguments to ENTRYPOINT when both are present. Option E is incorrect because if neither CMD nor ENTRYPOINT is specified, the container inherits the base image's default command, which may keep it running (e.g., a shell) or cause it to exit; it does not always run and exit immediately.

Exam trap

A common misconception is that CMD is ignored when ENTRYPOINT is present, but the correct behavior is that CMD becomes default arguments for ENTRYPOINT unless overridden.

Practice this question →

139

MCQhard

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.

A.4

B.3

C.7

D.5

AnswerA

The correct answer is 4 because the Job's `parallelism` field is set to 4, which defines the desired number of pods the Job controller keeps running concurrently. Even if a pod fails, the controller immediately creates a replacement pod to restore the count to 4, provided the `backoffLimit` has not been exceeded. Thus, at any given time (except for transient moments during pod termination), up to 4 pods are actively running.

Why this answer

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.

Exam trap

The trap here is that candidates mistakenly think a pod failure reduces the number of running pods or that the Job stops or scales down, but the parallelism remains constant and the controller continues to run pods up to that limit.

How to eliminate wrong answers

Option B is wrong because it assumes the Job reduces parallelism after a failure, but the parallelism setting remains 4 regardless of failures. Option C is wrong because it confuses the total number of successful completions (7) with the number of currently running pods; the Job runs pods up to the parallelism value, not the success count. Option D is wrong because it suggests a specific number like 5, which is not derived from any Job field; the parallelism is fixed at 4, and failures do not dynamically adjust it.

Practice this question →

140

MCQmedium

A pod has two containers: a web server and a sidecar that scrapes logs. The sidecar container needs to read log files written by the web server. How should the logs be shared between the containers?

A.Use a ConfigMap to store logs

B.Use a hostPath volume mounted in both containers

C.Use a shared emptyDir volume mounted into both containers at the same path

D.Use a PersistentVolumeClaim

AnswerC

An emptyDir volume is created when the pod starts and exists for the pod's lifetime, and mounting it into both containers at the same path gives the sidecar direct filesystem access to the log files the web server writes, satisfying the sharing requirement.

Why this answer

An emptyDir volume is a shared, ephemeral volume that is created when a Pod is assigned to a node and exists as long as that Pod is running. Both containers in the same Pod can mount the same emptyDir volume at the same or different paths, allowing the sidecar to read log files written by the web server without any external storage dependency. This is the standard Kubernetes pattern for inter-container log sharing within a Pod.

Exam trap

A common misconception is that hostPath is the default or simplest way to share files between containers, but the correct Kubernetes-native pattern for ephemeral, intra-Pod log sharing is an emptyDir volume, which is portable and automatically lifecycle-managed.

How to eliminate wrong answers

Option A is wrong because ConfigMaps are designed to store configuration data (e.g., key-value pairs, small files) and are not suitable for dynamic, growing log files; they are read-only when mounted and cannot be written to by containers. Option B is wrong because hostPath volumes tie the Pod to a specific node's filesystem, which breaks portability and is not recommended for simple log sharing; it also introduces security risks and is not the idiomatic Kubernetes approach for sidecar log scraping. Option D is wrong because a PersistentVolumeClaim (PVC) is intended for persistent storage that survives Pod restarts and is typically used for stateful workloads, not for ephemeral log sharing between containers in the same Pod; it adds unnecessary complexity and overhead.

Practice this question →

141

Multi-Selectmedium

Which THREE of the following are valid patterns for multi-container pods?

Select 3 answers

A.Init

B.Ambassador

C.Adapter

D.Sidecar

E.Daemon

AnswersB, C, D

The ambassador pattern places a proxy container in the same pod as the main container, intercepting all network traffic destined for external services. The main container only needs to connect to localhost, while the ambassador transparently handles remote connectivity, TLS termination, authentication, or load balancing, enabling the application to be simpler and more portable.

Why this answer

The Ambassador pattern is a valid multi-container pod pattern where a proxy container handles network communication on behalf of the main application container, abstracting external service connectivity. This pattern is commonly implemented with tools like Envoy or a custom sidecar proxy that manages TLS termination, service discovery, or circuit breaking, allowing the main container to connect to localhost while the ambassador handles remote connections.

Exam trap

The CKAD exam often tests the distinction between pod-level patterns (sidecar, ambassador, adapter) and cluster-level controllers (DaemonSet, Job, ReplicaSet), leading candidates to confuse 'Daemon' as a multi-container pattern when it is actually a controller for running pods across nodes.

Practice this question →

142

MCQeasy

Which Dockerfile instruction sets a default command that can be overridden by arguments passed to 'docker run'?

A.ENTRYPOINT

B.EXPOSE

C.CMD

D.RUN

AnswerC

The CMD instruction specifies a default command and optional parameters that Docker executes when the container starts, providing a baseline behavior for the image. It is designed to be overridden easily: when you run the container and supply your own command-line arguments, they replace the CMD entirely. Thus CMD precisely matches the requirement of setting a default command that can be overridden.

Why this answer

The CMD instruction in a Dockerfile sets a default command that runs when a container starts. This default can be overridden by providing arguments directly to 'docker run' after the image name, making it the correct choice for a command that is intended to be easily replaced.

Exam trap

The CKAD exam often tests the distinction between CMD and ENTRYPOINT, and the trap here is that candidates confuse CMD (which can be overridden) with ENTRYPOINT (which requires the --entrypoint flag to override), leading them to incorrectly select ENTRYPOINT as the instruction that accepts overrides from 'docker run'.

How to eliminate wrong answers

Option A is wrong because ENTRYPOINT defines a fixed command that cannot be overridden by 'docker run' arguments unless the --entrypoint flag is used; it is designed to set the main executable. Option B is wrong because EXPOSE only documents which ports the container listens on at runtime; it does not execute any command. Option D is wrong because RUN executes commands during the image build process, not at container startup, so it cannot be overridden by 'docker run'.

Practice this question →

143

Multi-Selectmedium

Which TWO commands can be used to create a resource from a YAML file?

Select 2 answers

A.kubectl create -f pod.yaml

B.kubectl delete -f pod.yaml

C.kubectl get -f pod.yaml

D.kubectl run -f pod.yaml

E.kubectl apply -f pod.yaml

AnswersA, E

kubectl create -f pod.yaml is correct because it directly reads the YAML manifest and sends an imperative create request to the API server. It will successfully create the Pod if no same-named Pod already exists, but it will fail with an error if the resource is already present, since it only performs creation and cannot reconcile changes. This command is ideal for one-time, explicit resource provisioning from a file.

Why this answer

The `kubectl create -f pod.yaml` command is correct because it instructs Kubernetes to create a resource (in this case, a Pod) defined in the specified YAML file. This is a declarative command that submits the resource manifest to the API server, which validates and stores it in etcd, resulting in the resource being created in the cluster.

Exam trap

The trap here is that candidates may confuse `kubectl run` (which is an imperative command for creating pods or deployments without a file) with a file-based creation command, or they may think `kubectl get` can create resources, when in fact it only retrieves them.

Practice this question →

144

MCQmedium

A developer has a Dockerfile that builds a Go application. The final image size is 800MB. Which improvement would MOST reduce the image size?

A.Combine all RUN commands into a single layer

B.Add a .dockerignore file to exclude unnecessary files

C.Use a smaller base image like alpine:3.19

D.Use multi-stage builds with a scratch final stage

AnswerD

Multi-stage builds are the correct approach because they allow the Dockerfile to use a full Go toolchain in a builder stage, produce the compiled binary, and then copy that artifact into a fresh scratch final stage. Scratch is an empty image with no OS, no shell, and no libraries, so all build-time dependencies, compilers, and unnecessary files are discarded, leaving only the static executable. This drastically reduces image size and attack surface, and since Go can produce statically linked binaries with CGO_ENABLED=0, the binary runs perfectly on scratch without any runtime dependencies.

Why this answer

Multi-stage builds allow copying only the binary from the build stage to a minimal base image, drastically reducing final image size.

Practice this question →

145

MCQmedium

You run the following command: 'kubectl run nginx --image=nginx --restart=Never'. What Kubernetes resource is created?

A.CronJob

B.Deployment

C.Job

D.Pod

AnswerD

When --restart=Never is specified, kubectl run creates a standalone Pod directly rather than handing the Pod to a controller. This Pod is the smallest deployable unit and has a restart policy of Never, meaning if its container exits, the kubelet will not restart it and no higher-level controller will recreate it. Therefore the resulting object is exactly a Pod.

Why this answer

The `kubectl run nginx --image=nginx --restart=Never` command creates a Pod directly, because the `--restart=Never` flag sets the restart policy to Never, which instructs Kubernetes to run the container as a standalone Pod rather than wrapping it in a higher-level controller like a Deployment or Job. The `kubectl run` command, when used without a controller flag, defaults to creating a Pod when `--restart=Never` is specified, as per the Kubernetes API behavior.

Exam trap

The trap here is that candidates often assume `kubectl run` always creates a Deployment by default, but the `--restart=Never` flag changes the behavior to create a Pod, and they may confuse the restart policy with the resource type, leading them to incorrectly select Job or Deployment.

How to eliminate wrong answers

Option A is wrong because a CronJob requires the `--schedule` flag and a restart policy of OnFailure or Never, but the command does not include a schedule, and CronJobs are for recurring tasks, not a single run. Option B is wrong because a Deployment requires a restart policy of Always (the default), but `--restart=Never` overrides this, and Deployments manage ReplicaSets for rolling updates, not a single Pod. Option C is wrong because a Job requires a restart policy of OnFailure or Never, but the command does not include the `--restart=OnFailure` flag; while `--restart=Never` can create a Job, the `kubectl run` command with `--restart=Never` and no `--job` flag creates a Pod, not a Job, as Jobs are only created when explicitly specified or when using `--restart=OnFailure`.

Practice this question →

146

MCQmedium

A Job must run exactly 3 Pods in parallel. Which Job manifest field achieves this?

A..spec.activeDeadlineSeconds

B..spec.completions

C..spec.parallelism

D..spec.backoffLimit

AnswerC

The .spec.parallelism field is the correct way to control how many Pods run concurrently. Setting parallelism to 3 instructs the Job controller to launch three Pods simultaneously, ensuring the Job runs exactly three Pods in parallel. It directly defines the maximum number of active Pods at any moment, independent of the total completion count. If completions is also set, parallelism determines how many of the total completions are processed at a time.

Why this answer

`.spec.parallelism` in a Kubernetes Job manifest specifies the maximum number of Pods that should run concurrently. Setting this field to 3 ensures exactly 3 Pods run in parallel, as required by the question.

Exam trap

A common mistake in the CKAD exam is confusing `.spec.parallelism` (the number of Pods to run concurrently) with `.spec.completions` (the total number of successful Pods required to complete the Job). Candidates often select `.spec.completions` thinking it controls parallelism.

How to eliminate wrong answers

Option A is wrong because `.spec.activeDeadlineSeconds` sets a time limit for the Job's total execution duration, not the number of parallel Pods. Option B is wrong because `.spec.completions` defines the total number of successful Pod completions required for the Job to be considered complete, not the parallelism count. Option D is wrong because `.spec.backoffLimit` controls the number of retries for a failing Pod before marking the Job as failed, unrelated to parallel execution.

Practice this question →

147

Multi-Selecthard

Which THREE of the following are correct about the .dockerignore file? (Select 3)

Select 3 answers

A.It supports wildcard patterns to exclude files

B.It is a replacement for .gitignore

C.It can be used to exclude .git directory from the build context

D.It allows comments starting with #

E.It affects the files available in the running container

AnswersA, C, D

The .dockerignore file supports glob-based wildcard patterns, such as * for any sequence of characters and ? for a single character, to match files and directories within the build context. These patterns use Go's filepath.Match semantics, so * does not cross directory boundaries unless you use ** for recursive matches. This allows developers to exclude multiple files or directories with a single rule, keeping the build context lean and avoiding unnecessary data transfer to the Docker daemon.

Why this answer

The .dockerignore file supports wildcard patterns (e.g., *, ?, []) to exclude files and directories from the build context, similar to .gitignore. This allows you to define patterns like *.log or temp/* to skip unwanted files during the Docker build process.

Exam trap

The trap here is that candidates often confuse the scope of .dockerignore with runtime container files, thinking it affects the final container, when in reality it only filters the build context sent to the Docker daemon.

Practice this question →

148

MCQeasy

Which instruction in a Dockerfile sets the default command to run when the container starts, but allows overriding?

A.START

B.RUN

C.CMD

D.ENTRYPOINT

AnswerC

CMD sets the default command to execute when the container starts. It provides a default that can be easily overridden by passing a command as an argument to `docker run` (e.g., `docker run myimage echo hi` replaces the CMD). If multiple CMD instructions are present in a Dockerfile, only the last one takes effect, making it flexible for users.

Why this answer

The CMD instruction in a Dockerfile defines the default command to execute when a container starts from the image. It can be overridden by providing a command at the end of the `docker run` command, making it the correct choice for a default command that allows user override.

Exam trap

The trap here is that candidates often confuse CMD with ENTRYPOINT, thinking both are interchangeable, but CMD is designed for override while ENTRYPOINT is for a fixed command that requires `--entrypoint` to change.

How to eliminate wrong answers

Option A is wrong because START is not a valid Dockerfile instruction; Dockerfile uses instructions like CMD, ENTRYPOINT, RUN, etc. Option B is wrong because RUN executes commands during image build time, not at container startup, and its results are committed to the image layers. Option D is wrong because ENTRYPOINT sets the command that runs at container startup and is not easily overridden without the `--entrypoint` flag; it is designed for a fixed executable, not a default that can be replaced by a simple command argument.

Practice this question →

149

Multi-Selectmedium

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

Select 2 answers

A.docker build --name myapp:1.0 .

B.docker commit myapp:1.0 myrepo/myapp:1.0

C.docker tag myapp:1.0 myrepo/myapp:1.0

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

E.docker build -t myapp:1.0 .

AnswersC, E

docker tag is the direct command for assigning an additional tag to an existing image. It creates a new mutable alias (myrepo/myapp:1.0) that points to the same underlying image ID as the source image (myapp:1.0), without modifying the image's filesystem or layers. This is the standard mechanism for preparing a local image to be pushed to a different repository or registry.

Why this answer

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.

Exam trap

The trap here is that candidates confuse `docker tag` with `docker commit` or `docker build` flags, mistakenly thinking `--name` or `docker run` can assign tags, when only `docker tag` and `docker build -t` are valid for tagging images.

Practice this question →