CKAD Practice Exam 56 — 20 Questions

Question 1

Which command forwards port 8080 on the local machine to port 80 on a pod named 'web-pod'?

Accepted Answer

kubectl port-forward pod/web-pod 8080:80. `kubectl port-forward` creates a direct tunnel from a local port to a port on a specific pod. The syntax `kubectl port-forward pod/web-pod 8080:80` forwards local port 8080 to port 80 on the pod named 'web-pod', enabling local access to the pod's service without requiring a Service object.

Answer

kubectl expose pod web-pod --port=8080 --target-port=80

Answer

kubectl proxy --port=8080 --target=pod/web-pod:80

Answer

kubectl exec web-pod -- curl http://localhost:8080

Question 2

To create a service that will be accessible from outside the cluster using a cloud provider's load balancer, what type should be used?

Accepted Answer

LoadBalancer. The LoadBalancer service type (D) provisions an external load balancer from the cloud provider (e.g., AWS ELB, GCP TCP/UDP Load Balancer) and assigns a public IP or DNS name, making the service accessible from outside the cluster. This is the correct choice when the requirement explicitly states using a cloud provider's load balancer for external access.

Answer

NodePort

Answer

ClusterIP

Answer

ExternalName

Question 3

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?

Accepted Answer

kubectl debug <pod> --image=busybox --stdin --tty. `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.

Answer

kubectl create pod debug --image=busybox --attach

Answer

kubectl exec -it <pod> -- /bin/sh

Answer

kubectl run debug --image=busybox --attach

Question 4

What is the purpose of a readiness probe in Kubernetes?

Accepted Answer

To control whether the pod receives traffic from Services. A readiness probe determines whether a container is ready to serve traffic. If the probe fails, the pod is removed from the endpoints of Services, thus it does not receive traffic. Option B describes a startup probe (to delay liveness/readiness probes for slow-starting containers). Option C describes resource monitoring, not a probe. Option D describes a liveness probe, which restarts the container if unhealthy.

Answer

To delay the start of other probes for slow-starting containers

Answer

To monitor resource usage of the container

Answer

To restart the container if it becomes unhealthy

Question 5

A Pod in namespace 'team-a' runs with a serviceAccountName of 'reporter'. The Pod must read a Secret named 'metrics-token' that lives in namespace 'team-b'. Cluster-wide RBAC and the ServiceAccount token are already configured correctly. Which Pod specification change allows the container to obtain the Secret's data?

Accepted Answer

Use the ServiceAccount token to call the API server for the Secret in 'team-b', then write the returned data into a file the application reads.. Secret references such as secretKeyRef and secret volume sources resolve only inside the Pod's own namespace, so a Pod in 'team-a' cannot directly project a Secret stored in 'team-b'. The API server is the cross-namespace path, and the Pod's ServiceAccount token, combined with the already-correct RBAC, lets the container retrieve the Secret and stage its data into a file the application consumes.

Answer

Create a Secret in 'team-a' that has the same name, and rely on the kubelet to mirror the data from 'team-b' automatically.

Answer

Mount a volume of type secret with secretName 'metrics-token' and add a volumeMount at /var/run/metrics.

Answer

Add an env entry with valueFrom.secretKeyRef naming 'metrics-token' and set the Pod's namespace field to 'team-b'.

Question 6

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?

Accepted Answer

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

Answer

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.

Answer

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.

Answer

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.

Question 7

A CKAD candidate must make a container's exit code observable after a crash so that a monitoring agent reading pod status can distinguish an application error from an out-of-memory kill. The container has terminated and restarted several times. Which command shows the exit code and termination reason of the most recent terminated instance of the container?

Accepted Answer

kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[*].lastState.terminated}'. Container termination facts are persisted on the pod's status under containerStatuses, where lastState.terminated holds the exitCode, reason, and timing of the previous instance. Extracting that subtree with jsonpath or a custom-columns output gives the monitoring agent the precise reason value, such as OOMKilled, that distinguishes a memory kill from an ordinary application failure. Logs and node descriptions do not carry this structured field.

Answer

kubectl describe node <node> | grep -i exit

Answer

kubectl logs <pod> --previous

Answer

kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[*].state.running}'

Question 8

A team wants a Pod to expose two containers: a web server container listening on port 8080 and a metrics exporter container listening on port 9100. The Pod manifest must give each container its own containerPort so that monitoring tools can discover them. Which YAML snippet correctly declares both container ports in a single Pod?

Accepted Answer

spec:
  containers:
  - name: web
    image: nginx
    ports:
    - containerPort: 8080
  - name: metrics
    image: exporter
    ports:
    - containerPort: 9100. Container ports belong inside each container's ports list under the Pod spec. Declaring containerPort 8080 for the web container and 9100 for the metrics container correctly describes two separate listeners in one Pod, matching the requirement for per-container port declarations.

Answer

spec:
  containers:
  - name: web
    image: nginx
    ports:
    - name: web
      port: 8080
  - name: metrics
    image: exporter
    ports:
    - name: metrics
      port: 9100

Answer

spec:
  containers:
  - name: web
    image: nginx
    ports:
    - containerPort: 8080
    - containerPort: 9100
  - name: metrics
    image: exporter

Answer

spec:
  containers:
  - name: web
    image: nginx
  - name: metrics
    image: exporter
  ports:
  - containerPort: 8080
  - containerPort: 9100

Question 9

A developer deploys a Pod that reads configuration from a ConfigMap named 'app-config' using a volume mount at /etc/config. Later, the ConfigMap is updated with new values. The application running in the Pod is designed to re-read the file periodically but continues to see the old values. What is the most likely reason the application is not seeing the updated configuration?

Accepted Answer

The Pod was created with the ConfigMap volume mounted using subPath, which prevents automatic updates.. ConfigMap volumes mounted without subPath are periodically updated by the kubelet, but when subPath is used, the kubelet does not sync changes to that file. The application re-reads the file but sees stale data because the file content is never refreshed. Removing subPath or restarting the Pod would resolve the issue.

Answer

The ConfigMap volume is mounted as read-only, preventing updates from being propagated.

Answer

The ConfigMap was updated using kubectl edit, which does not trigger a volume refresh.

Answer

The application is using an environment variable instead of reading the file from the volume mount.

Question 10

A production pod named 'api-pod' runs a single container whose liveness probe has begun failing after a configuration change, causing repeated restarts. An engineer must determine whether the failures are caused by the probe configuration itself or by the application inside the container. Which TWO actions best provide that evidence? (Choose two.)

Accepted Answer

Run kubectl describe pod api-pod and inspect the Events section for Liveness probe failed messages with the probe's reported error and port.. Separating a bad probe definition from a broken application requires evidence from two directions. Pod events show what the kubelet observed when the probe ran, including the failing endpoint and error text, which exposes misconfigured ports, paths, or thresholds. Testing the same endpoint from inside the container shows whether the application actually responds, which rules the application in or out. Together they localize the fault; resource metrics, image pull policy, and a forced restart do not.

Answer

Run kubectl get pod api-pod -o yaml and confirm the container's imagePullPolicy is set to Always.

Answer

Run kubectl rollout restart deployment api-pod to force a fresh container image pull and clear the restart counter.

Answer

Run kubectl top pod api-pod to compare CPU and memory consumption against the container's declared limits.

Question 11

A Pod is configured with a securityContext that sets runAsUser: 1000 and runAsGroup: 3000 at the pod level. A container within that Pod has its own securityContext that sets runAsUser: 2000 but does not set runAsGroup. The container process attempts to create a file in a directory owned by group 3000 with group write permissions. Which two statements are true regarding the effective user and group of the container process? (Choose two.)

Accepted Answer

The container process runs with UID 2000.. Container-level securityContext overrides pod-level for the same field, so runAsUser: 2000 applies. For runAsGroup, the container does not specify it, so it inherits the pod-level runAsGroup: 3000. Thus the process runs as UID 2000 and GID 3000, allowing write access to the group-writable directory.

Answer

The container process runs with UID 1000 because pod-level settings take precedence.

Answer

The container process runs with GID 2000 because the container's runAsUser implies a matching group.

Answer

The container process cannot write to the directory because the group ID does not match the directory's group owner.

Question 12

A Pod is running in a namespace with a default LimitRange that sets a default CPU request of 100m and a default CPU limit of 200m. The Pod's container spec does not specify any CPU requests or limits. What will be the effective CPU request and limit for the container?

Accepted Answer

CPU request: 100m, CPU limit: 200m. A LimitRange with default CPU request and limit values automatically applies those to containers that do not specify their own. The defaultRequest becomes the request, and the default becomes the limit. Thus, the container gets a CPU request of 100m and a limit of 200m, as defined in the LimitRange.

Answer

CPU request: 200m, CPU limit: 200m

Answer

CPU request: 0, CPU limit: 0

Answer

CPU request: 100m, CPU limit: 100m

Question 13

You manage a Deployment named 'web' in namespace 'prod' whose pods mount a ConfigMap named 'web-config' as a volume at /etc/web. You update the ConfigMap data, but the running pods still serve the old configuration because the application only reads the mounted file at startup. You must roll out the new configuration to all pods with zero downtime and preserve the ability to roll back. What is the MOST appropriate action?

Accepted Answer

Run 'kubectl rollout restart deployment/web -n prod', which adds a restartedAt annotation to the pod template and triggers a new revision.. A rollout restart is the standard CKAD pattern for forcing pods to reload configuration that is consumed only at process start. It creates a new ReplicaSet revision by mutating the pod template annotation, so the rolling update proceeds with zero downtime and the previous ReplicaSet remains for rollback. Deleting the ConfigMap, changing the image, or manually signaling processes do not produce a clean, reversible rollout.

Answer

Edit the Deployment and change the container image tag to a new value, forcing Kubernetes to recreate all pods with the refreshed ConfigMap.

Answer

Use 'kubectl exec' into each pod and run a command to signal the application process to re-read /etc/web, then wait for the kubelet to sync the volume.

Answer

Delete the ConfigMap and recreate it with the updated data so the kubelet re-syncs the projected volume contents immediately.

Question 14

A team ships a container that writes structured JSON diagnostics to stdout and nothing to a file. A support engineer needs to filter those lines for entries with level 'error' across all containers of a deployment named 'checkout', without installing additional tooling on the nodes. Which approach accomplishes this using only kubectl?

Accepted Answer

kubectl logs deployment/checkout --all-containers=true | grep '"level":"error"'. Container logs are fetched from the kubelet's log files through the API server by kubectl logs, which can target a workload such as a deployment and aggregate every container with --all-containers=true. Filtering that aggregated stream in the local shell with grep isolates the structured error entries. Options that adjust time windows, describe the deployment, or read a nonexistent file inside one pod do not deliver the filtered, deployment-wide view that was requested.

Answer

kubectl logs deployment/checkout --since=1h --tail=-1

Answer

kubectl exec -it deployment/checkout -- cat /var/log/app.log | grep error

Answer

kubectl describe deployment checkout | grep error

Question 15

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

Accepted Answer

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

Answer

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

Answer

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

Answer

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.

Question 16

You are deploying a stateful application as a StatefulSet named 'db' with three replicas and a headless Service named 'db-headless'. The application requires each pod to have a stable network identity and its own persistent storage that survives pod rescheduling. Which combination of StatefulSet fields ensures this behavior?

Accepted Answer

Set serviceName to 'db-headless' and define volumeClaimTemplates so each pod gets a uniquely named PVC.. Stable identity and per-pod storage in a StatefulSet come from two fields working together. serviceName must point to a headless Service so each pod gets a predictable DNS name, and volumeClaimTemplates generates a distinct PVC per replica that is retained across rescheduling. Parallel pod management or a shared PVC do not satisfy both requirements simultaneously.

Answer

Set podManagementPolicy to Parallel and define volumeClaimTemplates so all pods start simultaneously with their own PVCs.

Answer

Set serviceName to a ClusterIP Service named 'db-svc' and define volumeClaimTemplates for per-pod storage.

Answer

Set serviceName to 'db-headless' and use a single shared PersistentVolumeClaim mounted by all three pods.

Question 17

You have a Service named 'web-svc' of type ClusterIP. You want to test connectivity to it from a temporary pod. Which command would you use to launch a temporary interactive pod with the image 'busybox' and then run 'wget' against the Service?

Accepted Answer

kubectl run tmp --image=busybox --restart=Never --rm -it -- wget -qO- http://web-svc. The correct command uses 'kubectl run' with '--restart=Never' to create a standalone pod, '--rm' to delete it after exit, and '-it' for interactive terminal. The '--' separates kubectl flags from the command to run in the container. Other options misuse 'kubectl exec', use an invalid restart policy, or use a non-existent 'kubectl create pod' command.

Answer

kubectl run tmp --image=busybox --restart=Always --rm -it -- wget -qO- http://web-svc

Answer

kubectl exec -it tmp --image=busybox -- wget -qO- http://web-svc

Answer

kubectl create pod tmp --image=busybox --rm -it -- wget -qO- http://web-svc

Question 18

You have a NetworkPolicy named 'deny-all' in namespace 'secure' that selects all pods and has no ingress rules. You need to allow incoming traffic to pods with label 'app: db' on port 5432 from pods with label 'app: api' in the same namespace. Which NetworkPolicy should you create?

Accepted Answer

A NetworkPolicy with podSelector matching 'app: db' and ingress rule allowing from podSelector 'app: api' on port 5432.. NetworkPolicies are additive, and a deny-all policy blocks all ingress unless explicitly allowed. To allow specific traffic, you must create a policy that selects the target pods ('app: db') and defines an ingress rule that matches the source pods ('app: api') on the correct port. Policies that control egress on the source, allow all IPs, or allow the entire namespace do not meet the precise restriction.

Answer

A NetworkPolicy with podSelector matching 'app: db' and ingress rule allowing from namespaceSelector matching 'secure' on port 5432.

Answer

A NetworkPolicy with podSelector matching 'app: db' and ingress rule allowing from ipBlock 0.0.0.0/0 on port 5432.

Answer

A NetworkPolicy with podSelector matching 'app: api' and egress rule allowing to podSelector 'app: db' on port 5432.

Question 19

A developer needs to run a one-off batch job that processes a queue and must complete exactly once before the pod is terminated. The container image is 'registry.example.com/worker:1.4'. Which resource should be created to meet this requirement?

Accepted Answer

A Job with a pod template that sets restartPolicy to Never or OnFailure and a backoffLimit controlling retries.. A Job is purpose-built for run-to-completion workloads. Setting restartPolicy to Never or OnFailure and configuring backoffLimit gives controlled retries on failure, while a successful exit marks the Job complete without restarting the pod. Deployments restart containers indefinitely, CronJobs repeat on a schedule, and bare Pods lack controller-managed completion and rescheduling.

Answer

A CronJob with a schedule of '* * * * *' so the worker runs every minute and eventually processes the queue.

Answer

A Deployment with replicas set to 1 and a restartPolicy of Always so the worker restarts if it exits.

Answer

A bare Pod manifest with no controller, relying on the kubelet to restart the container if it fails.

Question 20

A developer is writing a multi-stage Dockerfile for a Go application. The builder stage compiles the binary, and the final stage uses a minimal base image. The developer wants the final image to contain only the compiled binary and CA certificates, and wants to copy the binary from the builder stage. Which Dockerfile instruction correctly copies the compiled binary from the builder stage into the final stage?

Accepted Answer

COPY --from=builder /app/server /usr/local/bin/server. Multi-stage builds allow later stages to copy artifacts from earlier stages using COPY --from=<stage>. Referencing the builder stage by name copies only the compiled binary into the minimal final image, keeping it small and free of build tooling while still including the binary.

Answer

RUN cp --from=builder /app/server /usr/local/bin/server

Answer

COPY /app/server /usr/local/bin/server

Answer

ADD --stage=builder /app/server /usr/local/bin/server