CKAD Application Design and Build — 15 Questions

Question 1

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?

Accepted Answer

Define an init container with the script and mount the shared volume to both init and main containers.. Option C is correct because 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.

Answer

Run the script as a sidecar container that shares the volume with the main container.

Answer

Use a postStart lifecycle hook on the main container to run the script.

Answer

Add a readiness probe to the main container that checks the shared volume.

Question 2

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. Option D (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 3

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-file=app.properties. Option A is correct because `--from-file=app.properties` creates a ConfigMap where each key-value pair from the file becomes a separate data entry, with the key being the filename (app.properties) and the value being the entire file content. This matches the requirement that the ConfigMap keys match the file content, meaning the file itself is stored as a single key-value pair where the key is the filename.

Answer

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

Answer

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

Answer

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

Question 4

Which TWO statements are true about Kubernetes Secrets?

Accepted Answer

Secret data is base64 encoded in YAML manifests.. Option A is correct because 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 5

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 6

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. Option B is correct because 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 7

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 8

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?

Accepted Answer

The Deployment lacks a readiness probe, causing the Service to route traffic to Pods that are not ready.. 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.

Answer

The ClusterIP Service type does not support load balancing.

Answer

The Service is not configured with enough endpoints.

Answer

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

Question 9

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

Question 10

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

Question 11

Match each Kubernetes resource to its primary purpose.

Question 12

Match each Kubernetes Service type to its behavior.

Question 13

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 14

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 app containers start, used for setup tasks like waiting for dependencies or preparing data.

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 15

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 without '--restart=Never' defaults to a Deployment (apps/v1), but with '--restart=Never' it creates a standalone Pod (v1).

Answer

apps/v1

Answer

batch/v1

Answer

networking.k8s.io/v1