CKAD Application Deployment Practice Test 2 — 15 Questions

Question 1

A team is deploying a microservice that requires a ConfigMap mounted as a volume. The ConfigMap is expected to be updated frequently, and the application should read the latest values without restarting. Which volume type should be used?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Projected volume. A Projected volume allows you to mount multiple existing volume sources, including ConfigMaps, Secrets, and others, into the same directory. When the ConfigMap is updated, the contents of the Projected volume are automatically updated via the kubelet's periodic sync (default every 60 seconds), enabling the application to read the latest values without restarting the pod.

Answer

hostPath

Answer

persistentVolumeClaim

Answer

emptyDir

Question 2

A company wants to deploy a stateful database on Kubernetes. The database requires stable network identities and persistent storage per pod. Which resource should be used?

Accepted Answer

StatefulSet. StatefulSet is the correct resource because it provides stable, unique network identities (via headless Services and ordinal pod names like `db-0`, `db-1`) and persistent storage per pod (via PersistentVolumeClaims that are retained across rescheduling). This matches the requirement for a stateful database where each pod must maintain its identity and data independently.

Answer

Job

Answer

Deployment

Answer

DaemonSet

Question 3

The exhibit shows a Deployment configuration. The application's /health endpoint returns HTTP 200 only after 30 seconds, while /ready returns 200 immediately. After applying this Deployment, what is the expected behavior?

Accepted Answer

Pods will become ready quickly but will be restarted repeatedly until the liveness probe starts succeeding after 30 seconds.. The readiness probe passes immediately (since /ready returns 200), so the Pod is marked Ready and added to the Service. However, the liveness probe fails initially (since /health returns non-200 for the first 30 seconds), causing the kubelet to restart the container repeatedly until the liveness probe starts succeeding after 30 seconds. This behavior is defined by Kubernetes: a failing liveness probe triggers container restarts, while a failing readiness probe only removes the Pod from Service endpoints.

Answer

Pods will become ready after 30 seconds when both probes pass.

Answer

Pods will never become ready because the liveness probe fails initially.

Answer

Pods will never become ready because the readiness probe fails initially.

Question 4

A developer is creating a Deployment with 4 replicas. The application requires a rolling update with zero downtime. Which TWO strategies ensure zero downtime during an update?

Accepted Answer

Set maxSurge=1. Setting maxSurge=1 allows Kubernetes to spin up one new Pod before terminating any old Pod during a rolling update. This ensures that the total number of available Pods never drops below the desired replica count, maintaining service capacity and achieving zero downtime.

Answer

Set maxUnavailable=1

Answer

Use Recreate strategy

Answer

Set maxSurge=0

Question 5

A team is deploying a multi-container pod with a main application container and a sidecar container for logging. Which THREE statements about pod design are correct?

Accepted Answer

Containers in a pod share the same network namespace.. Containers within the same Kubernetes pod share the same network namespace, including the same IP address and port space. This allows them to communicate via localhost and share network resources, which is essential for sidecar patterns like logging agents that need to intercept or monitor the main container's traffic.

Answer

Containers in a pod share the same filesystem root.

Answer

The sidecar container must use the same image as the main container.

Question 6

A developer is deploying a web application that requires 2 GiB of memory and 0.5 CPU cores. The cluster nodes have 4 GiB of memory and 2 CPU cores each. The developer wants to ensure the pod gets guaranteed QoS class. Which resource specification should be used?

Accepted Answer

requests: memory: 2Gi, cpu: 500m; limits: memory: 2Gi, cpu: 500m. For a pod to receive the Guaranteed QoS class, every container in the pod must have both resource requests and limits set, and the requests must equal the limits for each resource (memory and CPU). This configuration ensures the pod is not overcommitted and gets the highest priority under resource pressure.

Answer

requests: memory: 2Gi, cpu: 500m; no limits

Answer

requests: memory: 2Gi, cpu: 500m; limits: memory: 4Gi, cpu: 1

Answer

requests: memory: 1Gi, cpu: 250m; limits: memory: 2Gi, cpu: 500m

Question 7

You are deploying a microservice application on a Kubernetes cluster. The application consists of a frontend service (type: ClusterIP) and a backend service (type: ClusterIP). The frontend needs to communicate with the backend via DNS name 'backend-service'. The backend service runs three replicas, each listening on port 8080. You have created the backend service and deployment, and verified that pods are running. However, when you deploy the frontend pod and attempt to curl http://backend-service:8080 from within the frontend, you get 'connection refused'. The frontend pod is in the same namespace as the backend. You check the backend pods and they are all running and ready, and the endpoints object shows the correct pod IPs. You suspect a misconfiguration in the service definition. Which of the following is the most likely cause of the issue?

Accepted Answer

The backend deployment's containerPort is set to 8081, but the service's targetPort is 8080, causing a mismatch.. The stem states each backend pod listens on port 8080. If the service's port is 8080 and targetPort is unspecified, targetPort defaults to 8080, which matches the actual listening port. Option D's claim that the deployment's containerPort is 8081 contradicts the stem and, more importantly, containerPort is informational only; it does not determine which port the service targets. The connection refused error is most likely due to a targetPort that does not match the actual listening port, but none of the provided options correctly describe this misconfiguration. Therefore, no option is correct as written.

Answer

The backend pods are not running on the nodes because the cluster has insufficient resources.

Answer

The frontend pod is using the wrong service name; it should be 'backend-service.default.svc.cluster.local'.

Answer

The backend service's port field is set to 8080, but the targetPort is not specified, so it defaults to the port field value, which is correct.

Question 8

You are deploying a microservice that reads from a ConfigMap and a Secret. The application logs show 'Failed to read configuration: missing key' on startup. Which TWO are likely causes?

Accepted Answer

The ConfigMap does not exist in the namespace. If the ConfigMap does not exist in the namespace, any pod referencing it will fail to start or the application will be unable to read the configuration data. Kubernetes validates ConfigMap existence at pod creation time, and missing ConfigMaps cause the pod to remain in a pending state or the application to log errors like 'missing key' when attempting to access the configuration.

Answer

The Secret data is base64 encoded in the manifest, but the application expects decoded values

Answer

The ServiceAccount used by the pod does not have permissions to access Secrets

Answer

The ConfigMap was updated but the pod was not restarted

Question 9

The exhibit shows a Deployment manifest. When applied, the pods are created but show 'CrashLoopBackOff'. What is the most likely cause?

Accepted Answer

The liveness probe targets port 8080, but the container only listens on port 80. The liveness probe is configured to check port 8080, but the container (nginx) only listens on port 80 by default. Since the probe never receives a successful HTTP response, Kubernetes restarts the container repeatedly, causing the CrashLoopBackOff state. The probe must target the same port the application is serving on.

Answer

The selector does not match the pod labels

Answer

The initialDelaySeconds is too short, starting probes before the app is ready

Answer

The container image nginx:1.21 does not exist

Question 10

Order the steps to expose a Kubernetes Deployment as a ClusterIP Service.

Accepted Answer

Step 1: Ensure Deployment exists and is running. Step 2: Create a ClusterIP Service YAML manifest. Step 3: Apply the Service manifest using kubectl apply. Step 4: Verify the Service endpoints are populated. Step 5: Test DNS resolution of the Service name from a pod.. A Service requires a running Deployment. Define and apply the Service, then verify endpoints and test DNS resolution.

Answer

Step 1: Create a ClusterIP Service YAML manifest. Step 2: Apply the Service manifest. Step 3: Ensure Deployment exists and is running. Step 4: Test DNS resolution. Step 5: Verify endpoints.

Answer

Step 1: Ensure Deployment exists and is running. Step 2: Test DNS resolution. Step 3: Create the Service YAML. Step 4: Apply the Service. Step 5: Verify endpoints.

Answer

Step 1: Apply the Service manifest. Step 2: Create the Service YAML. Step 3: Ensure Deployment exists. Step 4: Verify endpoints. Step 5: Test DNS.

Question 11

Arrange the steps to create a PersistentVolumeClaim and use it in a Pod.

Accepted Answer

Create PVC, then verify PVC is bound to a PV, then create Pod referencing PVC in volumes.. Create PVC first, ensure it's bound, then define Pod with volume referencing PVC.

Answer

Create Pod referencing PVC first, then create PVC.

Answer

Create PVC, then create Pod referencing PVC, without verifying binding.

Answer

Create Pod with inline volume, then convert to PVC-based volume.

Question 12

Match each kubectl command to its function.

Accepted Answer

kubectl get: Retrieve resource information from the cluster. The correct matches are: kubectl get retrieves information, kubectl describe shows details, kubectl apply creates/updates, and kubectl delete removes. Common confusions include misattributing 'apply' to 'get' or 'delete' to 'describe'.

Answer

kubectl get: Create or update resources from a file

Answer

kubectl describe: Remove resources from the cluster

Question 13

You are implementing a canary deployment for a microservice named 'api'. The stable version is deployed as 'api-stable' with label 'version: stable'. You create a canary Deployment 'api-canary' with label 'version: canary'. Both Deployments have the same label 'app: api'. You want a Service 'api-svc' to route 90% of traffic to stable and 10% to canary. Which Service configuration achieves this?

Accepted Answer

selector: {app: api} and adjust the number of replicas in each Deployment to achieve the desired ratio (e.g., 9 stable, 1 canary). Kubernetes Services distribute traffic based on the number of ready Pods matching the selector. By setting 9 replicas for 'api-stable' and 1 replica for 'api-canary', both with the same selector 'app: api', the Service will route approximately 90% of requests to stable and 10% to canary, achieving the desired canary deployment ratio without native traffic splitting.

Answer

Add annotation 'traffic-weight: 90' to stable and 'traffic-weight: 10' to canary

Answer

selector: {app: api, version: stable}

Answer

Create two separate Services, each targeting one version, and rely on DNS weighting

Question 14

You have installed a Helm chart for 'wordpress' using 'helm install my-wordpress bitnami/wordpress'. Later, you want to check the status of the release. Which command lists the status of all releases?

Accepted Answer

helm list. The `helm list` command is the correct way to list all releases in the current namespace, showing their status (deployed, failed, pending, etc.). It provides a summary of each release, including the name, revision, update time, and status. This directly answers the question of listing the status of all releases.

Answer

helm status my-wordpress

Answer

helm history my-wordpress

Answer

helm show status

Question 15

A Deployment has 3 replicas. You run 'kubectl scale deployment mydeploy --replicas=5'. What happens?

Accepted Answer

The Deployment is updated to have 5 replicas, and the ReplicaSet creates 2 additional pods.. `kubectl scale` updates the Deployment's `spec.replicas` field to 5, which triggers the existing ReplicaSet to adjust its pod count. The ReplicaSet controller creates 2 additional pods to match the desired state, resulting in a total of 5 pods. The Deployment itself is not replaced, and no new ReplicaSet is created unless the pod template changes.

Answer

The command fails because you must edit the YAML directly.

Answer

A new Deployment is created with 5 replicas.

Answer

The current ReplicaSet is deleted and a new one is created with 5 replicas.