CKAD Application Design and Build — 100 Questions

Question 1

A developer needs to expose a deployment named 'web-app' running on port 8080 to external traffic. The cluster is on-premises with no cloud load balancer. Which service type should be used?

Accepted Answer

NodePort. (NodePort) is correct because it exposes a service on a static port on each node's IP address, allowing external traffic to reach the 'web-app' deployment on port 8080 without requiring a cloud load balancer. In on-premises clusters, NodePort is the standard service type for external access when no cloud LB is available, as it opens a high-port (30000-32767) on every node that forwards traffic to the ClusterIP service.

Answer

ExternalName

Answer

ClusterIP

Answer

LoadBalancer

Question 2

A developer is creating a ConfigMap from a file named 'app.properties'. The file contains key-value pairs. Which command correctly creates the ConfigMap with keys matching the file content?

Accepted Answer

kubectl create configmap my-config --from-env-file=app.properties. The file 'app.properties' contains key-value pairs. To create a ConfigMap with keys that match the keys in the file, use `kubectl create configmap my-config --from-env-file=app.properties`. This parses the file and creates one data entry per key=value line. Option A (`--from-file=app.properties`) stores the entire file content as a single value under the key 'app.properties', which does not produce keys matching the file content. Option B uses `--from-literal` incorrectly, and option C reads from stdin but still treats the input as a single file, not as key-value pairs.

Answer

kubectl create configmap my-config --from-file=app.properties

Answer

kubectl create configmap my-config --from-literal=app.properties

Answer

cat app.properties | kubectl create configmap my-config --from-file=-

Question 3

Which TWO statements are true about Kubernetes Secrets?

Accepted Answer

Secret data is base64 encoded in YAML manifests.. 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.

Answer

Secrets cannot be used as environment variables.

Answer

Secrets are always encrypted at rest by default.

Answer

Secrets are limited to 1KB in size.

Question 4

Which THREE are valid reasons to use a StatefulSet instead of a Deployment?

Accepted Answer

Each pod requires a stable, unique network identity.. StatefulSet assigns each pod a stable, unique network identity (e.g., a hostname like `web-0`, `web-1`) via a headless Service, which is critical for stateful applications like databases that rely on consistent DNS names for clustering and discovery. Deployments create pods with random, ephemeral hostnames, making them unsuitable for workloads requiring predictable network identities.

Answer

The application requires rolling updates.

Answer

The application cannot be scaled down.

Question 5

A developer is designing a Job that should run exactly once and then stop. The Job runs a batch process that is expected to complete within one hour. Which restartPolicy and backoffLimit are appropriate?

Accepted Answer

restartPolicy: OnFailure, backoffLimit: 4. A Job designed to run exactly once and stop should use `restartPolicy: OnFailure` or `Never`, and `backoffLimit: 4` provides a reasonable number of retries (up to 4) before the Job is marked as Failed, ensuring the batch process can recover from transient errors within the expected one-hour completion window. The `restartPolicy: Always` is invalid for Jobs (only `OnFailure` or `Never` are allowed), and `backoffLimit: 0` would prevent any retries, which is too restrictive for a batch process that may encounter temporary failures.

Answer

restartPolicy: Always, backoffLimit: 6

Answer

restartPolicy: Never, backoffLimit: 0

Answer

restartPolicy: Always, backoffLimit: 0

Question 6

A developer creates a Deployment with 3 replicas that uses a ConfigMap mounted as a volume. After updating the ConfigMap, the developer expects the pods to pick up the new configuration immediately, but the old configuration is still in use. What is the most likely reason?

Accepted Answer

The kubelet sync interval delays the propagation of ConfigMap changes to pods.. When a ConfigMap is mounted as a volume, updates to the ConfigMap are eventually propagated to the pods, but not instantly. The kubelet periodically syncs mounted ConfigMaps (default interval is 60 seconds), so there is a delay before pods see the new configuration. This is the most likely reason the old configuration is still in use.

Answer

ConfigMap updates are not propagated to mounted volumes.

Answer

The pods must be recreated after a ConfigMap update to see the changes.

Answer

ConfigMaps are immutable and cannot be updated.

Question 7

Arrange the steps to create a Kubernetes Deployment with a rolling update strategy.

Accepted Answer

1. Define the Deployment in YAML, 2. Apply the YAML using kubectl apply, 3. Modify the YAML for the update, 4. Re-apply the modified YAML using kubectl apply. First, define the Deployment in YAML. Then apply it. After an update, modify the YAML and re-apply; kubectl performs rolling update automatically.

Answer

1. Define the Deployment in YAML, 2. Modify the YAML for the update, 3. Apply the YAML using kubectl apply

Answer

1. Define the Deployment in YAML, 2. Apply the YAML using kubectl apply, 3. Delete the existing Pods manually, 4. Re-apply the modified YAML using kubectl apply

Answer

1. Apply an empty or placeholder YAML, 2. Define the Deployment in YAML, 3. Modify the YAML for the update, 4. Re-apply the YAML using kubectl apply

Question 8

Sequence the steps to expose a Kubernetes Service using a NodePort for external access.

Accepted Answer

Create the Deployment, define the Service (NodePort type) manifest, apply the Service manifest, retrieve the NodePort from the Service, then access externally via nodeIP:NodePort.. Deployment first, then define NodePort Service, apply, retrieve port, then access externally.

Answer

Define the Service manifest, retrieve the NodePort, create the Deployment, apply the Service, then access externally.

Answer

Create the Deployment, apply the Service manifest, define the Service manifest, retrieve the NodePort, then access externally.

Answer

Create the Deployment, define the Service manifest, retrieve the NodePort, apply the Service, then access externally.

Question 9

Match each Kubernetes resource to its primary purpose.

Accepted Answer

Pod: Runs one or more containers as a cohesive unit of compute. These are core Kubernetes resources with distinct roles. Pods are the smallest deployable units; Services provide networking abstractions; Deployments manage scaling and updates; ConfigMaps handle configuration data.

Answer

Pod: Provides load-balanced access to a set of Pods

Answer

Service: Manages rolling updates of Pods

Question 10

Match each Kubernetes Service type to its behavior.

Accepted Answer

ClusterIP: Exposes the service on a cluster-internal IP.. Common Kubernetes service types: ClusterIP (internal), NodePort (static port on nodes), LoadBalancer (cloud LB), ExternalName (DNS alias). Here, correct matches are A and C.

Answer

ClusterIP: Exposes the service externally via a cloud load balancer.

Answer

NodePort: Exposes the service on a cluster-internal IP only.

Question 11

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

Accepted Answer

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

Answer

Combine all RUN commands into a single layer

Answer

Add a .dockerignore file to exclude unnecessary files

Answer

Use a smaller base image like alpine:3.19

Question 12

What is the primary purpose of an Init Container in a Pod?

Accepted Answer

Perform initialization tasks such as waiting for a database to be ready. Init containers run to completion before the main application containers start, making them ideal for blocking or delaying the main container until prerequisites like a database readiness check succeed. They execute sequentially and can use different container images, allowing setup tasks without bloating the main app image or requiring special permissions.

Answer

Run a sidecar proxy alongside the main container

Answer

Provide a health check endpoint for the main container

Answer

Collect logs and metrics from the main container

Question 13

A user runs: kubectl run my-pod --image=nginx --restart=Never --dry-run=client -o yaml. Which apiVersion is used in the generated YAML?

Accepted Answer

v1. The `kubectl run` command, when used with `--restart=Never`, creates a standalone Pod. Pods are the most basic Kubernetes resource and belong to the core API group, which uses the `v1` apiVersion (i.e., `apiVersion: v1`). Options like `apps/v1` or `batch/v1` are for higher-level controllers such as Deployments or Jobs, not for a direct Pod creation.

Answer

apps/v1

Answer

batch/v1

Answer

networking.k8s.io/v1

Question 14

A CronJob is configured with concurrencyPolicy: Replace and a job execution takes 10 minutes. The schedule is */5 * * * *. Which statement is true about job executions?

Accepted Answer

Every 5 minutes, a new job is created, and if the previous job is still running, it is killed. With `concurrencyPolicy: Replace`, if a new job is triggered by the schedule (every 5 minutes) while the previous job is still running (it takes 10 minutes), the running job is terminated and replaced by the new one. This ensures only one job runs at a time, and the new job starts immediately, even if the previous one hasn't finished.

Answer

Jobs will never overlap because the schedule is too frequent

Answer

The job will be skipped if the previous one hasn't finished

Answer

Jobs will overlap, with up to two jobs running concurrently

Question 15

Which command builds a Docker image from the current directory and tags it as 'myapp:v1'?

Accepted Answer

docker build -t myapp:v1 .. The `docker build` command with the `-t` flag (short for `--tag`) is the standard way to build an image from a Dockerfile in the current directory (`.`) and assign it a tag `myapp:v1`. The `-t` flag specifies the repository and tag in the format `name:tag`, and the `.` indicates the build context (the current directory).

Answer

docker image build --name myapp:v1 .

Answer

docker build myapp:v1 .

Answer

docker tag myapp:v1 .

Question 16

A developer wants to create a Job that runs exactly 3 pods in parallel. Which field should be set in the Job spec?

Accepted Answer

spec.parallelism: 3. `spec.parallelism` in a Kubernetes Job spec defines the desired number of Pods that should run concurrently. Setting `spec.parallelism: 3` tells the Job controller to run exactly 3 Pods in parallel, meeting the requirement of running 3 pods simultaneously.

Answer

spec.ttlSecondsAfterFinished: 3

Answer

spec.backoffLimit: 3

Answer

spec.completions: 3

Question 17

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

Accepted Answer

ENTRYPOINT defines the executable and CMD provides default arguments. 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.

Answer

CMD always runs, ENTRYPOINT can be overridden

Answer

There is no difference; they are interchangeable

Answer

CMD is used for shell form, ENTRYPOINT for exec form

Question 18

A user runs: kubectl apply -f job.yaml. The Job spec has backoffLimit: 0. The pod fails immediately. What happens?

Accepted Answer

The Job enters a Failed state. When `backoffLimit: 0` is set in a Job spec and the pod fails immediately, the Job controller does not retry the pod because the backoff limit is zero. According to Kubernetes Job semantics, the Job is considered failed once the number of failures reaches the `backoffLimit` (0 in this case), so the Job transitions to a Failed state without any further pod creation or retries.

Answer

The Job is retried indefinitely

Answer

The pod is restarted until it succeeds

Answer

A new pod is created automatically

Question 19

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?

Accepted Answer

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

Answer

--container

Answer

--namespace

Answer

--share-process-namespace

Question 20

Which Kubernetes API version is used for creating a CronJob?

Accepted Answer

batch/v1. CronJob is a Kubernetes resource that was promoted to a stable API version in Kubernetes 1.21. The correct API version for creating a CronJob is batch/v1, as it is the current stable version. The batch/v1beta1 version is deprecated and removed in Kubernetes 1.25, so batch/v1 is the correct choice for CKAD exam scenarios.

Answer

batch/v1beta1

Answer

cron/v1

Answer

apps/v1