Courseiva

CCNA Ckad Design Build Questions

31 questions · Ckad Design Build topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
Multi-Selectmedium

Which of the following are valid concurrencyPolicy values for a CronJob? (Select all that apply.)

Select 3 answers
A.Replace
B.Allow
C.Parallel
D.Forbid
E.Serial
AnswersA, B, D

The `Replace` policy is a valid concurrencyPolicy value, but it is not one of the two selected as correct in this question. It terminates the currently running job and starts a new one when the next scheduled time arrives.

Why this answer

Within a Kubernetes CronJob, the concurrencyPolicy field accepts three valid values: Allow, Forbid, and Replace. Allow permits multiple concurrent executions of the same job. Forbid prevents new executions while a previous one is still running.

Replace cancels the currently running job and starts a new one in its place. Options C (Parallel) and E (Serial) are not valid values. Therefore, the correct answers are Replace, Allow, and Forbid.

Exam trap

The CKAD exam expects you to know all three valid values for concurrencyPolicy. Do not mistakenly think that Replace is invalid; it is one of the three accepted values. Also, avoid selecting Parallel or Serial, as they are not part of the Kubernetes API.

Practice this question →
2
Multi-Selectmedium

Which TWO of the following are valid concurrencyPolicy values for a CronJob?

Select 2 answers
A.Parallel
B.Forbid
C.Serial
D.Allow
E.Replace
AnswersB, D

Forbid is correct because it is one of the three valid concurrency policies, which prevents concurrent runs by skipping new runs if a previous one is still active.

Why this answer

In Kubernetes, a CronJob's concurrencyPolicy controls how to handle overlapping job executions. The valid values are Allow (default, allowing concurrent runs) and Forbid (skips new run if previous is still running). Among the options given, the two correct answers are Allow and Forbid.

Replace is not a valid concurrencyPolicy value; it is a distractor.

Exam trap

The CKAD exam often tests the exact string values of Kubernetes API fields, and candidates may confuse 'Parallel' or 'Serial' with the valid 'Allow' and 'Forbid' due to familiarity with other job concepts like parallelism.

Practice this question →
3
MCQmedium

A DevOps engineer wants to deploy a logging sidecar container that reads log files from the main application container. Which volume type should be used to share files between the two containers?

A.emptyDir
B.persistentVolumeClaim
C.configMap
D.hostPath
AnswerA

emptyDir is a pod-scoped volume that is created empty when a pod is scheduled and survives only as long as the pod runs. It is mounted into all containers sharing the same lifecycle, making it the standard choice for a sidecar that reads logs written by the main application because both can access the same files without any persistent storage overhead. Its ephemeral nature is exactly what you want here—logs are consumed immediately and discarded with the pod, so no cleanup or durability guarantees are needed.

Why this answer

An emptyDir volume is the correct choice because it provides a shared, ephemeral storage space that is created when a Pod is assigned to a node and exists as long as that Pod is running. Both the main application container and the sidecar container can mount the same emptyDir volume at different mount paths, allowing the sidecar to read log files written by the main container. This volume type is ideal for sharing files between containers in the same Pod without requiring persistent storage.

Exam trap

The trap here is that candidates often confuse persistentVolumeClaim with a general-purpose shared volume, not realizing it is for persistent, Pod-independent storage, while emptyDir is the correct ephemeral volume for sharing files between containers in the same Pod.

How to eliminate wrong answers

Option B (persistentVolumeClaim) is wrong because it is used for persistent storage that outlives the Pod, not for sharing files between containers within the same Pod; it also requires a PersistentVolume and is overkill for temporary log sharing. Option C (configMap) is wrong because it is designed to inject configuration data (e.g., key-value pairs or small files) into containers, not for dynamic file sharing like log files that are written and read at runtime. Option D (hostPath) is wrong because it mounts a file or directory from the host node's filesystem into the Pod, which introduces node-level coupling and security risks, and is not the standard Kubernetes approach for inter-container communication within a Pod.

Practice this question →
4
MCQhard

You need to debug a pod that is not responding. Which command attaches an ephemeral debug container to a running pod named 'web-pod'?

A.kubectl debug web-pod --copy-to=debug-pod --image=busybox
B.kubectl debug -it web-pod --image=busybox --target=web-container
C.kubectl attach web-pod
D.kubectl run debug --image=busybox -it
AnswerB

Correct command to add an ephemeral debug container.

Why this answer

`kubectl debug` with the `--image` flag creates an ephemeral container in the specified pod for interactive debugging. The `-it` flag provides an interactive TTY, and `--target=web-container` attaches the ephemeral container to the same Linux namespace as the target container, allowing direct troubleshooting of the unresponsive pod without modifying its original containers.

Exam trap

The trap here is that candidates confuse `kubectl debug` with `kubectl run` or `kubectl attach`, assuming any command that creates a new interactive shell will work, but only `kubectl debug` with the `--image` flag correctly attaches an ephemeral container to the existing pod without copying or replacing it.

How to eliminate wrong answers

Option A is wrong because `--copy-to=debug-pod` creates a separate copy of the pod (debug-pod) rather than attaching an ephemeral debug container to the existing 'web-pod', which is not what the question asks. Option C is wrong because `kubectl attach` connects to an already running container's stdio, but it cannot create a new debug container; it only attaches to existing containers, which may be unresponsive. Option D is wrong because `kubectl run` creates a new standalone pod named 'debug' instead of attaching an ephemeral container to the existing 'web-pod', so it does not debug the target pod directly.

Practice this question →
5
MCQmedium

You want to create a Deployment that runs 5 replicas of a web application. Which kubectl command should you use?

A.kubectl run webapp --image=nginx --replicas=5
B.kubectl create pod webapp --image=nginx --replicas=5
C.kubectl apply -f deployment.yaml
D.kubectl create deployment webapp --image=nginx --replicas=5
AnswerD

The correct imperative command is `kubectl create deployment webapp --image=nginx --replicas=5`. This creates a Deployment named webapp with the nginx container image and sets the desired replica count to 5. It is a fully supported current kubectl command that accepts `--replicas` to scale the Deployment at creation time, making it the most direct way to satisfy the requirement.

Why this answer

To create a Deployment with 5 replicas using a single imperative command, use `kubectl create deployment webapp --image=nginx --replicas=5`. This command directly creates a Deployment and sets the desired replicas. Option A (`kubectl run`) no longer creates a Deployment by default in current Kubernetes versions (1.18+); it creates a single Pod and does not support the `--replicas` flag.

Option B (`kubectl create pod`) does not exist and is incorrect. Option C (`kubectl apply -f deployment.yaml`) would also create a Deployment but requires an existing YAML file and is not a single imperative command.

Exam trap

The trap is that candidates might incorrectly believe `kubectl run` with `--replicas` creates a Deployment, as it did in earlier Kubernetes versions. In the CKAD exam environment (Kubernetes 1.31+), `kubectl run` only creates a Pod, and `kubectl create deployment` is the correct imperative command for creating a Deployment with replicas.

How to eliminate wrong answers

Option A is wrong because `kubectl run` does not support a `--replicas` flag; it creates a single Pod (or a Deployment in older versions, but the flag is not valid and would cause an error). Option B is wrong because `kubectl create pod` is not a valid command; Pods are created imperatively with `kubectl run` or declaratively via a manifest, and the `--replicas` flag does not apply to Pods (a Pod is a single instance). Option C is wrong because while `kubectl apply -f deployment.yaml` can create a Deployment, it requires a pre-existing YAML manifest file, which is not provided in the question; the question asks for a single kubectl command to create the Deployment, and this option assumes a file already exists.

Practice this question →
6
MCQhard

A team is deploying a microservice that requires initialization of a database schema before the main application starts. The init container must run a script that writes to a shared volume. Which configuration correctly ensures the init container completes before the main container runs?

A.Run the script as a sidecar container that shares the volume with the main container.
B.Use a postStart lifecycle hook on the main container to run the script.
C.Define an init container with the script and mount the shared volume to both init and main containers.
D.Add a readiness probe to the main container that checks the shared volume.
AnswerC

Init containers always run to completion before any application container in the pod is started, and each init container must exit with status 0. By mounting the same volume in both the init container and the main container, the script can write required files that the main container reads immediately upon startup. This guarantees the initialization is fully completed before the microservice process begins.

Why this answer

An init container runs to completion before any main container in the Pod starts, ensuring the database schema script finishes. By mounting the shared volume to both the init container and the main container, the script's output (e.g., schema files) is available to the main application when it launches.

Exam trap

The trap here is that candidates confuse init containers with sidecar containers or lifecycle hooks, not realizing that only init containers guarantee sequential execution before main containers, while sidecars and hooks run concurrently or asynchronously.

How to eliminate wrong answers

Option A is wrong because a sidecar container runs concurrently with the main container, not before it, so the database schema might not be initialized when the main application starts. Option B is wrong because a postStart lifecycle hook runs asynchronously and does not block the main container's entrypoint; the main container could start before the script completes, leading to race conditions. Option D is wrong because a readiness probe only checks if the main container is ready to serve traffic after it has started; it does not guarantee that the schema initialization script has run before the main container begins execution.

Practice this question →
7
MCQhard

A CronJob is configured with concurrencyPolicy: Forbid and schedule: '*/5 * * * *'. The first job takes 7 minutes. What happens when the next scheduled time arrives?

A.The previous job is terminated
B.The new job waits until the previous job completes
C.The new job is skipped
D.A new job is created immediately
AnswerC

Forbid skips the new job if the previous one is still running.

Why this answer

C is correct because when `concurrencyPolicy: Forbid` is set, the CronJob controller skips creating a new job if the previous job is still running at the next scheduled time. Since the first job takes 7 minutes and the schedule is every 5 minutes, the new job is skipped to prevent overlapping executions.

Exam trap

The trap here is that candidates often confuse `Forbid` with `Replace` (which terminates the running job) or assume the new job will queue, but Kubernetes explicitly skips the run without any retry or delay.

How to eliminate wrong answers

Option A is wrong because `concurrencyPolicy: Forbid` does not terminate the running job; it only prevents new jobs from starting. Option B is wrong because `Forbid` does not queue or delay the new job; it simply skips it. Option D is wrong because a new job is not created immediately; the controller checks the policy and skips creation if a job is still active.

Practice this question →
8
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.Increase the memory limit in the pod's container resource specification
B.Delete and recreate the pod to clear the crash loop
C.Increase the CPU request for the container
D.Delete the namespace and redeploy all workloads
AnswerA

Raising the memory limit in the container's resource spec is the direct fix because the OOMKilled status means the kernel's OOM killer terminated the process when its cgroup memory usage exceeded the configured limit. Increasing the limit allocates more memory to the pod's cgroup, giving the container sufficient headroom to complete its work and preventing the OOM killer from triggering. However, verify that the container's memory footprint is legitimate; if the app has a memory leak, a higher limit only delays the inevitable and masks the underlying issue.

Why this answer

The 'OOMKilled' message indicates the container was terminated because it exceeded its memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory, resolving the out-of-memory condition and preventing future crashes.

Exam trap

The trap here is that candidates may confuse memory and CPU resource issues, or think that simply restarting the pod (Option B) will fix the problem, when the OOMKilled status clearly indicates a persistent memory limit violation that requires a configuration change.

How to eliminate wrong answers

Option B is wrong because deleting and recreating the pod does not address the underlying memory exhaustion; the new pod will crash again with the same OOMKilled error. Option C is wrong because increasing the CPU request does not affect memory allocation; OOMKilled is a memory-related issue, not CPU-related. Option D is wrong because deleting the namespace and redeploying all workloads is an extreme, unnecessary action that does not fix the memory limit and disrupts all other workloads in the namespace.

Practice this question →
9
MCQeasy

Which kubectl command creates a pod named 'nginx' from the image 'nginx:latest'?

A.kubectl run nginx --image=nginx:latest
B.kubectl apply -f pod.yaml
C.kubectl run nginx --image=nginx:latest --restart=Never
D.kubectl create pod nginx --image=nginx:latest
AnswerA, C

Correct: This command creates a Pod named 'nginx' from the specified image in recent Kubernetes versions.

Why this answer

`kubectl run nginx --image=nginx:latest` creates a Pod named 'nginx' by default in recent Kubernetes versions (1.18+). Option C is also correct: adding `--restart=Never` explicitly creates a Pod and is a common practice to ensure a Pod is created rather than a Deployment. Option B is wrong because `kubectl apply -f` requires a YAML file.

Option D is wrong because `kubectl create pod` is not a valid subcommand; the correct imperative command is `kubectl run`.

Exam trap

The CKAD exam often tests the misconception that `kubectl run` always creates a Deployment, but in recent Kubernetes versions (1.18+) the default behavior creates a Pod directly. Additionally, both `kubectl run nginx --image=nginx:latest` and `kubectl run nginx --image=nginx:latest --restart=Never` create a Pod, so either is acceptable. Candidates may incorrectly assume only one is correct.

How to eliminate wrong answers

Option B is wrong because `kubectl apply -f pod.yaml` requires a pre-existing YAML manifest file named `pod.yaml` to be present, and it does not create a Pod from the command line using the `--image` flag. Option C is wrong because `kubectl run nginx --image=nginx:latest --restart=Never` explicitly sets the restart policy to Never, which is unnecessary for a basic Pod creation and deviates from the default behavior; the question does not specify any custom restart policy. Option D is wrong because `kubectl create pod nginx --image=nginx:latest` is not a valid kubectl command — the correct syntax for creating a Pod imperatively is `kubectl run`, not `kubectl create pod`.

Practice this question →
10
MCQhard

You are designing a Pod that must run a diagnostic tool to collect network logs before the main application starts. The diagnostic tool should run to completion, then the main application starts. Which approach should you use?

A.Add the diagnostic tool as an init container in the Pod
B.Add the diagnostic tool as a sidecar container in the same Pod
C.Add the diagnostic tool as a sidecar container with a postStart hook
D.Create a separate Job that runs before the Pod
AnswerA

An init container is the correct choice because Kubernetes runs init containers to completion, in order, before any regular app container is started. This guarantees the diagnostic tool finishes its checks first, and if it exits with a non-zero status, the app container will not be created. The diagnostic is thus an explicit, blocking prerequisite within the same Pod.

Why this answer

Init containers run sequentially before the Pod's main containers start, and they must complete successfully before the main application container begins. This makes them ideal for setup tasks like running a diagnostic tool to collect network logs that must finish before the main application starts.

Exam trap

The trap here is that candidates confuse init containers with sidecar containers or lifecycle hooks, assuming any container that runs before the main application can be a sidecar, but only init containers guarantee sequential execution to completion before the main container starts.

How to eliminate wrong answers

Option B is wrong because a sidecar container runs concurrently with the main container, not before it, so the diagnostic tool would not complete before the main application starts. Option C is wrong because a postStart hook runs inside the main container's lifecycle after the container starts, but it does not block the main application from starting; the hook runs asynchronously, so the main application could begin before the diagnostic tool finishes. Option D is wrong because creating a separate Job introduces unnecessary complexity and does not guarantee the Job completes before the Pod starts; the Pod could be scheduled and run before the Job finishes, and there is no built-in dependency mechanism between a Job and a Pod.

Practice this question →
11
MCQmedium

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

A.COPY . /app\nRUN npm install
B.ADD package*.json /app/\nRUN npm install\nADD . /app/
C.COPY package*.json /app/\nRUN npm install\nCOPY . /app/
D.ADD . /app\nRUN npm install
AnswerC

This is the recommended pattern: copying only `package*.json` first makes the `RUN npm install` layer depend solely on dependency manifests, so it remains cached unless those files change. After install, the remaining application code is copied in a separate layer, letting source-code edits rebuild quickly without reinstalling dependencies. Using `COPY` for both operations is correct for local build-context files, and if the source contains a `node_modules` directory, a `.dockerignore` entry should exclude it to avoid overwriting the freshly installed dependencies.

Why this answer

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

Exam trap

In the CKAD exam, candidates often mistakenly use `ADD` instead of `COPY`, but `COPY` is the recommended command for copying local files to a Docker image without unnecessary side effects. The exam emphasizes efficient layer caching, so using `COPY` for local files and separating dependency installation from source code copying is a best practice.

How to eliminate wrong answers

Option A is wrong because it copies the entire source code before running `npm install`, which defeats Docker layer caching — any source code change invalidates the npm install cache, causing unnecessary re-installations. Option B is wrong because it uses `ADD` instead of `COPY`; while `ADD` can copy files, it has additional behaviors like automatic tar extraction and remote URL fetching, which are unnecessary here and violate the principle of using `COPY` for local file copies unless extra features are needed. Option D is wrong because it copies the entire source code before running `npm install`, similar to option A, and uses `ADD` instead of `COPY`, introducing unnecessary complexity and potential side effects.

Practice this question →
12
MCQeasy

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

A.It limits the number of layers in the final image
B.It excludes files and directories from being sent to the Docker daemon during the build
C.It defines environment variables for the container
D.It specifies the order of layers in the Docker image
AnswerB

A .dockerignore file defines patterns that exclude files and directories from the build context before it is transmitted to the Docker daemon. This reduces the amount of data sent, shortens build times, and prevents sensitive information like .env, SSH keys, or large local caches such as node_modules from being uploaded. Ignored files are not available for COPY or ADD within the Dockerfile, but the exclusion is purely at the context-transmission stage.

Why this answer

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

Exam trap

The CKAD exam often tests the distinction between build-time and runtime configuration; the trap here is confusing the .dockerignore file (which affects the build context sent to the daemon) with files that control image layers or container runtime behavior, leading candidates to select options about layer count or environment variables.

How to eliminate wrong answers

Option A is wrong because the number of layers in a Docker image is determined by the number of RUN, COPY, and ADD instructions in the Dockerfile, not by the .dockerignore file. Option C is wrong because environment variables for a container are defined using the ENV instruction in the Dockerfile or the --env flag at runtime, not by a .dockerignore file. Option D is wrong because the order of layers in a Docker image is dictated by the sequence of instructions in the Dockerfile, not by any ignore file.

Practice this question →
13
MCQmedium

You need to debug a running pod that does not have a shell installed. Which kubectl command allows you to start an ephemeral container with a shell?

A.kubectl create pod debug --image=busybox --attach
B.kubectl exec -it <pod> -- /bin/sh
C.kubectl debug <pod> --image=busybox --stdin --tty
D.kubectl run debug --image=busybox --attach
AnswerC

kubectl debug adds an ephemeral container to the pod with the specified image and attaches to it.

Why this answer

`kubectl debug` is specifically designed to add an ephemeral container to a running pod for troubleshooting purposes, even when the original container lacks a shell. The `--image=busybox` flag provides a lightweight image with common debugging tools, and `--stdin --tty` allocates an interactive terminal, allowing you to run commands like `/bin/sh` inside the ephemeral container without modifying the original pod's containers.

Exam trap

The trap here is that candidates often confuse `kubectl exec` (which requires a shell in the existing container) with `kubectl debug` (which adds a new container with a shell), or mistakenly think `kubectl run` or `kubectl create pod` can attach to an existing pod's context.

How to eliminate wrong answers

Option A is wrong because `kubectl create pod debug --image=busybox --attach` creates a new standalone pod, not an ephemeral container attached to an existing running pod, so it cannot debug the target pod's environment. Option B is wrong because `kubectl exec -it <pod> -- /bin/sh` attempts to execute a shell inside the existing container, which fails if the container does not have a shell installed (e.g., a distroless or minimal image). Option D is wrong because `kubectl run debug --image=busybox --attach` launches a new pod in the cluster, not an ephemeral container in the target pod, and thus cannot access the target pod's filesystem, processes, or network namespace.

Practice this question →
14
MCQmedium

You need to schedule a task that runs every day at 2:00 AM. The task should be allowed to run even if a previous instance is still running. Which concurrencyPolicy should you set in the CronJob spec?

A.Allow
B.Replace
C.Forbid
D.Ignore
AnswerA

The concurrencyPolicy Allow (which is also the default) permits a new Job to be created even if a previous Job from the same CronJob is still running. For a daily 02:00 schedule, this ensures the task starts at the scheduled time regardless of whether the prior run completed. Since the requirement only says the task should run every day and imposes no restriction on overlapping execution, Allow is the correct and standard policy.

Why this answer

Setting `concurrencyPolicy: Allow` in a CronJob spec permits a new job instance to start even if a previous instance is still running. This is the default behavior when the field is omitted, and it directly satisfies the requirement that the task must run at 2:00 AM regardless of any overlapping executions.

Exam trap

The trap here is that candidates may confuse concurrencyPolicy with restartPolicy or assume 'Ignore' is a valid option, but Kubernetes only supports Allow, Forbid, and Replace, and the default is Allow.

How to eliminate wrong answers

Option B (Replace) is wrong because it would cancel the currently running job and start a new one, which violates the requirement to allow the previous instance to continue. Option C (Forbid) is wrong because it would skip the new job if a previous instance is still running, preventing the scheduled execution. Option D (Ignore) is not a valid value for the concurrencyPolicy field in Kubernetes; the only valid values are Allow, Forbid, and Replace.

Practice this question →
15
MCQhard

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

A.Running
B.Failed
C.Unknown
D.CrashLoopBackOff
AnswerB

A liveness probe failure makes the kubelet kill the container; with restartPolicy: Never the kubelet will not restart it. The container's exit is processed as a terminal status, and the Pod is marked Failed (the phase is exactly Failed when all containers in a Pod have terminated and at least one has exited non-zero or was killed). This is the expected result in this scenario rather than a crash loop.

Why this answer

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

Exam trap

The trap here is that candidates often confuse the restartPolicy 'Never' with 'OnFailure' and assume the Pod will enter CrashLoopBackOff, but CrashLoopBackOff only applies when the restartPolicy allows restarts; with 'Never', the Pod fails permanently.

How to eliminate wrong answers

Option A is wrong because 'Running' indicates that all containers in the Pod are operational, but the liveness probe failure causes the container to be terminated, so the Pod cannot remain in the Running state. Option C is wrong because 'Unknown' is a transient state used when the node cannot report the Pod's status (e.g., due to network partition), not the final state after a liveness probe failure. Option D is wrong because 'CrashLoopBackOff' only occurs when the restartPolicy is 'Always' or 'OnFailure' and the container repeatedly crashes; with 'Never', no restart is attempted, so the Pod goes directly to 'Failed'.

Practice this question →
16
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.Increase the CPU request for the container
B.Delete and recreate the pod to clear the crash loop
C.Increase the memory limit in the pod's container resource specification
D.Delete the namespace and redeploy all workloads
AnswerC

OOMKilled specifically indicates that the container's memory usage hit the memory limit set in its resources.limits field, causing the kernel's out-of-memory killer to terminate the process. Increasing the memory limit grants the container a larger memory cgroup allowance, so it can continue running with its actual memory footprint without being killed, which directly addresses the root cause.

Why this answer

The 'OOMKilled' message indicates the container was terminated because it exceeded its memory limit. Increasing the memory limit in the container's resource specification allows the container to use more memory, preventing the out-of-memory kill. This directly addresses the root cause without losing the pod's state or affecting other workloads.

Exam trap

The trap here is that candidates confuse CPU and memory resource issues, or think that restarting the pod (Option B) will fix the underlying resource constraint, when in fact the OOMKilled status persists until the memory limit is increased.

How to eliminate wrong answers

Option A is wrong because increasing CPU request does not affect memory usage; OOMKilled is a memory issue, not a CPU issue. Option B is wrong because deleting and recreating the pod will not change the memory limit; the new pod will still be killed with OOMKilled if the memory limit remains unchanged. Option D is wrong because deleting the entire namespace is an extreme, unnecessary action that destroys all workloads and does not fix the memory limit for the specific pod.

Practice this question →
17
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 →
18
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 →
19
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 →
20
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 →
21
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 →
22
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 →
23
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

Correct: init containers are restarted on failure until they succeed.

Why this answer

Init containers must run successfully (exit 0) before the main containers start. If an init container fails, Kubernetes restarts it (if restartPolicy is Always or OnFailure) until it succeeds. The pod will remain in Init:Error state until the init container succeeds.

Practice this question →
24
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 →
25
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 →
26
MCQeasy

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

A.To provide a debugging shell into the pod
B.To handle traffic routing between services
C.To run a long-running process alongside the main container
D.To perform initialization tasks such as waiting for a database to be ready
AnswerD

Init containers are purpose-built for one-time setup tasks that must finish before the application starts. They run sequentially, and each must complete successfully before the next one starts, ensuring prerequisites like database readiness, schema migrations, or configuration downloads are met. This makes them ideal for blocking the app container until its dependencies are ready, rather than burdening the app itself with retry logic.

Why this answer

Init containers run to completion before the main application containers start, making them ideal for setup tasks like waiting for a database to be ready (e.g., using a `pg_isready` loop). They ensure the main container only runs when its prerequisites are satisfied, which is the core purpose defined in the Kubernetes documentation.

Exam trap

The trap here is confusing init containers with sidecar containers, as both run in the same pod, but init containers are strictly for one-time setup tasks and exit, while sidecars run continuously alongside the main container.

How to eliminate wrong answers

Option A is wrong because a debugging shell is provided by a sidecar container or ephemeral container (e.g., `kubectl debug`), not an init container, which runs to completion and cannot be accessed interactively. Option B is wrong because traffic routing between services is handled by Kubernetes Services, Ingress controllers, or network policies, not by init containers, which have no network proxy or routing logic. Option C is wrong because a long-running process alongside the main container is the role of a sidecar container (e.g., a logging agent), whereas init containers are designed to run to completion and exit before the main container starts.

Practice this question →
27
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 →
28
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 →
29
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 →
30
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 →
31
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 →

Ready to test yourself?

Try a timed practice session using only Ckad Design Build questions.

Start 20-question session