CKAD Practice Test 35 — 15 Questions

Question 1

You need to scale a Deployment named 'api' to 10 replicas instantly. Which command should you use?

Accepted Answer

kubectl scale deployment api --replicas=10. `kubectl scale` is the dedicated imperative command to change the replica count of a Deployment instantly. It directly updates the `spec.replicas` field in the Deployment's desired state, causing the controller to immediately create or terminate Pods to match the new count.

Answer

kubectl autoscale deployment api --min=10 --max=10

Answer

kubectl patch deployment api -p '{"spec":{"replicas":10}}'

Answer

kubectl resize deployment api --replicas=10

Question 2

A Service named 'api' has no endpoints. 'kubectl describe svc api' shows the selector 'app: api', but no pods have that label. What is the most likely reason for missing endpoints?

Accepted Answer

No pods match the Service's selector. The most likely reason for missing endpoints is that no pods match the Service's selector. A Kubernetes Service routes traffic to pods that have labels matching its `spec.selector`. If `kubectl describe svc api` shows `Selector: app=api` but no pods carry the label `app: api`, the Service's endpoint controller will not populate any endpoints, resulting in an empty `Endpoints` object. This is the direct cause of the missing endpoints.

Answer

The Service is in a different namespace than the pods

Answer

The Service port is incorrect

Answer

The Service type is ExternalName

Question 3

Which of the following is a valid NetworkPolicy that allows ingress traffic only from pods with label 'role: frontend' in any namespace?

Accepted Answer

ingress:
- from:
  - namespaceSelector: {}
    podSelector:
      matchLabels:
        role: frontend. It uses a `namespaceSelector: {}` (which matches all namespaces) combined with a `podSelector` that selects pods with label `role: frontend`. This combination allows ingress traffic from pods with that label in any namespace, which is exactly what the question requires. In Kubernetes NetworkPolicy, when you want to select pods across all namespaces, you must include an empty `namespaceSelector` alongside the `podSelector`.

Answer

ingress:
- from:
  - ipBlock:
      cidr: 0.0.0.0/0

Answer

ingress:
- from:
  - podSelector:
      matchLabels:
        role: frontend

Answer

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        role: frontend

Question 4

A pod must run with a seccomp profile that only allows specific syscalls. Which SecurityContext field is used to specify the seccomp profile type?

Accepted Answer

seccompProfile. `seccompProfile` is the field within the Pod or container `SecurityContext` that specifies the seccomp profile type (e.g., `RuntimeDefault`, `Localhost`, or `Unconfined`). This field was introduced in Kubernetes v1.19 (beta) and replaces the older annotation-based seccomp configuration, allowing you to define the profile type directly in the pod spec.

Answer

appArmorProfile

Answer

seLinuxOptions

Answer

seccomp

Question 5

You need to perform a blue-green deployment using Deployments and Services. What is the most common approach to switch traffic from the old version (blue) to the new version (green)?

Accepted Answer

Change the Service's label selector to point to the green Deployment's pod labels. In a blue-green deployment, the Service acts as the traffic router by using a label selector to match pods. By updating the Service's selector to match the green Deployment's pod labels (e.g., `version: green`), traffic is instantly switched from blue pods to green pods without any downtime, as Kubernetes Services use label selectors to dynamically route traffic to matching pods.

Answer

Update the Deployment's image field in the blue Deployment to the new version

Answer

Delete the blue Deployment and create the green Deployment

Answer

Scale the blue Deployment to 0 and the green Deployment to desired replicas

Question 6

Which TWO of the following are valid ways to expose a service externally on a Kubernetes cluster? (Select 2)

Accepted Answer

NodePort. A NodePort service exposes the service on a static port on each node's IP address, making it accessible from outside the cluster via `:`. This is a valid method for external exposure, as it opens a port in the node's firewall and routes traffic to the service.

Answer

kubectl port-forward

Answer

ExternalName

Answer

ClusterIP

Question 7

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

Accepted Answer

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

Answer

Parallel

Answer

Serial

Question 8

Which Helm command installs a chart from a repository?

Accepted Answer

helm install . The correct command to deploy a chart from a repository is `helm install `. This command tells Helm to create a release (a running instance of a chart) using the specified chart name or chart reference, which can be a chart from a configured repository, a local path, or a packaged chart archive.

Answer

helm deploy

Answer

helm create

Answer

helm run <release-name> <chart>

Question 9

A pod fails to start with a 'CreateContainerConfigError'. Running 'kubectl describe pod my-pod' reveals: 'Error: container has runAsNonRoot and image will run as root'. The pod definition includes 'securityContext.runAsNonRoot: true'. What is the most likely cause?

Accepted Answer

The container image's default user is root (UID 0), conflicting with runAsNonRoot. The error 'container has runAsNonRoot and image will run as root' occurs because the pod's securityContext sets `runAsNonRoot: true`, but the container image's default user is root (UID 0). Kubernetes checks the image's user at container startup; if the image runs as root and the pod enforces non-root, the container fails to start with a CreateContainerConfigError.

Answer

The container does not have the CAP_SYS_ADMIN capability

Answer

The container's filesystem is read-only

Answer

The runAsUser field is missing, so the pod uses a random UID

Question 10

You have a Pod that runs a web server and you want to add a sidecar container that exposes a Prometheus metrics endpoint by scraping the web server's logs. Which sidecar pattern does this exemplify?

Accepted Answer

Adapter pattern. The Adapter pattern is a sidecar pattern where the sidecar container transforms or adapts the main container's output into a format consumable by an external system. Here, the sidecar scrapes the web server's logs and exposes them as Prometheus metrics, adapting log data into a metrics endpoint. This is a classic example of the Adapter pattern.

Answer

Sidecar pattern (generic)

Answer

Ambassador pattern

Answer

Init container pattern

Question 11

You want to enforce a Pod Security Standard of 'restricted' in a namespace. Which command applies the correct label?

Accepted Answer

kubectl label namespace my-ns pod-security.kubernetes.io/enforce=restricted. Pod Security Standards are enforced by applying a label with the key `pod-security.kubernetes.io/enforce` to a namespace. The value `restricted` sets the most restrictive Pod Security Standard, which prevents pods from running with privileged access or insecure capabilities. This label is part of the built-in Pod Security Admission (PSA) controller, which replaced PodSecurityPolicy in Kubernetes v1.23+.

Answer

kubectl label namespace my-ns psp=restricted

Answer

kubectl annotate namespace my-ns pod-security.kubernetes.io/enforce=restricted

Answer

kubectl label namespace my-ns pod-security.kubernetes.io/audit=restricted

Question 12

A container in your pod takes a long time to start (up to 5 minutes). You want to avoid the container being restarted by the liveness probe during this period. What should you configure?

Accepted Answer

Add a startup probe with a longer failure threshold. A startup probe is designed specifically for slow-starting containers. It runs at initialization and defers the liveness and readiness probes until it succeeds. By setting a high `failureThreshold` (e.g., 30) with a short `periodSeconds` (e.g., 10s), you allow up to 5 minutes for the container to start without the liveness probe killing it.

Answer

Set a long 'initialDelaySeconds' on the liveness probe

Answer

Add a readiness probe

Answer

Increase the failureThreshold on the liveness probe

Question 13

You have a pod 'app-pod' that keeps restarting. You want to see the logs from the previous (crashed) container instance. Which command should you use?

Accepted Answer

kubectl logs app-pod --previous. The `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container in a pod. Option B uses `-prev` which is not a valid shorthand (the correct shorthand is `-p`, which is not listed). Options C and D are incorrect: `-f` is for following logs in real-time, and `describe` shows events and configuration, not logs.

Answer

kubectl logs app-pod -prev

Answer

kubectl logs app-pod -f

Answer

kubectl describe pod app-pod

Question 14

A company runs a web application in a Kubernetes cluster. The application consists of a frontend service and a backend service. The frontend needs to communicate with the backend using a DNS name that does not change even if the backend pods are recreated. Which Kubernetes resource should the frontend use to reach the backend?

Accepted Answer

A regular ClusterIP Service. A regular ClusterIP Service provides a stable virtual IP and DNS name (e.g., ..svc.cluster.local) that remains constant regardless of pod churn. The frontend can use this DNS name to reach the backend, and the service load-balances traffic to the current set of backend pods via its label selector. This meets the requirement of a fixed DNS name that survives pod recreation.

Answer

An EndpointSlice

Answer

An Ingress resource

Answer

A headless Service

Question 15

You have a Deployment called 'web-deploy' with 3 replicas. One of the pods is not receiving traffic, but it shows 'Running' and passes its liveness probe. The readiness probe is configured as a TCP socket check on port 8080. You verify that the application is listening on port 8080. What is a likely reason the pod is not receiving traffic?

Accepted Answer

The readiness probe is succeeding even though the application is not truly ready, because TCP check only verifies the port is open. A TCP readiness probe only confirms that the TCP port is open and accepting connections, not that the application is fully ready to serve traffic. In this scenario, the application is listening on port 8080 (so the TCP check succeeds), but the pod may still be in a state where it cannot process requests (e.g., still initializing internal caches or waiting for dependencies). Since the readiness probe passes, the pod is added to the Service's endpoints, but traffic sent to it may be dropped or fail, causing the pod to not receive traffic effectively.

Answer

The service is configured to use a different port

Answer

The pod's node is cordoned

Answer

The liveness probe is failing and restarting the container