Courseiva
Knowledge + Practice
CertificationsVendorsCareer RoadmapsLabs & ToolsStudy GuidesGlossaryPractice Questions
C
Courseiva

Free IT certification practice questions with explained answers for CCNA, CompTIA, AWS, Azure, Google Cloud, and more.

Certification Practice Questions

CCNA practice questionsSecurity+ SY0-701 practice questionsAWS SAA-C03 practice questionsAZ-104 practice questionsAZ-900 practice questionsCLF-C02 practice questionsA+ Core 1 practice questionsGoogle Cloud ACE practice questionsCySA+ CS0-003 practice questionsNetwork+ N10-009 practice questions
View all certifications →

Product

CertificationsCertification PathsExam TopicsPractice TestsExam Dumps vs Practice TestsStudy HubComparisons

Company

AboutContactEditorial PolicyQuestion Writing PolicyTrust Center

Legal

Privacy PolicyTerms of Service

Courseiva is a free IT certification practice platform offering original exam-style practice questions, detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics for Cisco, CompTIA, Microsoft, AWS, and other technology certifications.

© 2026 Courseiva. Courseiva is operated by JTNetSolutions Ltd. All rights reserved.

Courseiva is an independent certification practice platform and is not affiliated with, endorsed by, or sponsored by Cisco, Microsoft, AWS, CompTIA, Google, ISC2, ISACA, or any other certification vendor. Vendor names and certification marks are used only to identify the exams learners are preparing for.

HomeCertificationsCKADExam Questions

CNCF · Free Practice Questions · Last reviewed May 2026

CKAD Exam Questions and Answers

30real exam-style questions organised by domain, each with the correct answer highlighted and a plain-English explanation of why it's right — and why the others are wrong.

120 min time limit
5 exam domains
OverviewDomain BlueprintStudy GuideAll QuestionsSample by Domain
1. Application Design and Build2. Application Deployment3. Application Environment, Configuration and Security4. Application Observability and Maintenance5. Services and Networking
1

Domain 1: Application Design and Build

All Application Design and Build questions
Q1
hardFull explanation →

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?

A

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

B

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

C

Define an init container with the script and mount the shared volume to both init and main containers.

Init containers run to completion before app containers start, and shared volumes persist data.

D

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

Why: 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.
Q2
mediumFull explanation →

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?

A

ExternalName

B

ClusterIP

C

LoadBalancer

D

NodePort

NodePort exposes a port on each node's IP address for external access.

Why: 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.
Q3
easyFull explanation →

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?

A

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

--from-file creates a configmap with a key named 'app.properties' containing file content.

B

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

C

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

D

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

Why: 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.
Q4
mediumFull explanation →

Which TWO statements are true about Kubernetes Secrets?

A

Secret data is base64 encoded in YAML manifests.

Secret values are base64 encoded, not plaintext.

B

Secrets cannot be used as environment variables.

C

Secrets are always encrypted at rest by default.

D

Secrets can be mounted as volumes in a Pod.

Secrets can be mounted as files using volumes.

E

Secrets are limited to 1KB in size.

Why: 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.
Q5
hardFull explanation →

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

A

The application requires rolling updates.

B

Each pod requires a stable, unique network identity.

StatefulSets assign stable hostnames based on ordinal index.

C

Each pod needs its own persistent volume that persists across rescheduling.

StatefulSets can use volumeClaimTemplates to give each pod a unique PVC.

D

The application cannot be scaled down.

E

Pods must be terminated in reverse order during shutdown.

StatefulSets terminate pods from highest to lowest ordinal.

Why: 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.
Q6
easyFull explanation →

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?

A

restartPolicy: Always, backoffLimit: 6

B

restartPolicy: OnFailure, backoffLimit: 4

OnFailure retries within the backoff limit; Job completes when pod succeeds.

C

restartPolicy: Never, backoffLimit: 0

D

restartPolicy: Always, backoffLimit: 0

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

Want more Application Design and Build practice?

Practice this domain
2

Domain 2: Application Deployment

All Application Deployment questions
Q1
easyFull explanation →

A developer wants to deploy a stateless application as a set of identical pods. They need the pods to be distributed across nodes and have stable network identities. Which resource should they use?

A

Job

B

Deployment

Deployments manage stateless pods with rolling updates and scale.

C

DaemonSet

D

StatefulSet

Why: A Deployment is the correct choice for a stateless application that needs identical pods distributed across nodes. It manages a ReplicaSet to ensure the desired number of replicas, supports rolling updates, and provides stable network identities via a headless Service or a regular Service, but the pods themselves do not require stable identities—only the Service provides a stable endpoint. For stateless workloads, Deployments are the standard resource.
Q2
mediumFull explanation →

A team is deploying a microservice that must be reachable within the cluster via a stable DNS name. They also need to distribute traffic among pods. Which Kubernetes resource provides both service discovery and load balancing?

A

Service

Service assigns a stable IP and DNS name, and load balances across pods.

B

ConfigMap

C

Secret

D

Ingress

Why: A Service in Kubernetes provides a stable DNS name (via cluster DNS, e.g., CoreDNS) that resolves to the Service's ClusterIP, and it load-balances traffic across the pods selected by its label selector using iptables or IPVS rules. This directly fulfills the requirement for both service discovery and load balancing within the cluster.
Q3
hardFull explanation →

During a deployment update, the rollout is stuck and new pods are not becoming ready. The developer checks the events and sees 'Back-off restarting failed container'. What is the most likely cause?

A

The liveness probe is failing

B

The container's entrypoint command fails immediately after start

If the command exits, the container crashes, leading to restart back-off.

C

The image pull secret is missing

D

The pod exceeds its memory limit and is OOMKilled

Why: The 'Back-off restarting failed container' event indicates that the container process exits immediately after starting, causing Kubernetes to repeatedly restart it with increasing back-off delays. This is most commonly caused by a container entrypoint or command that fails at runtime, such as a misconfigured binary, missing dependency, or incorrect startup script. Unlike probe failures, which cause restarts after the container is already running, this error occurs before the container can even become ready.
Q4
easyFull explanation →

A developer needs to run a one-time batch job to process data. After completion, the pod should be retained for logs inspection. Which Job configuration parameter should be set?

A

backoffLimit: 0

B

Leave ttlSecondsAfterFinished unset

If not set, the job and pods are retained until manually deleted.

C

ttlSecondsAfterFinished: -1

D

activeDeadlineSeconds: 3600

Why: To retain a Job's Pod after completion for log inspection, the `ttlSecondsAfterFinished` field must be left unset (or set to nil). When this field is unset, the Job controller does not automatically delete the Pod, allowing logs to be inspected. Setting it to any non-negative integer would schedule automatic deletion after that many seconds, which contradicts the requirement.
Q5
mediumFull explanation →

A company wants to deploy a stateful database cluster where each pod has its own persistent storage. They need stable network identities and ordered pod creation. Which resource should they use?

A

Deployment

B

StatefulSet

StatefulSet is designed for stateful apps with stable identities and persistent storage.

C

CronJob

D

DaemonSet

Why: StatefulSet is the correct resource because it provides stable, unique network identities (via headless Services and ordinal hostnames) and ordered, graceful deployment and scaling (pod creation/deletion in sequence). This matches the requirements for a stateful database cluster where each pod requires its own PersistentVolumeClaim (PVC) and stable identity for clustering.
Q6
hardFull explanation →

A Deployment has replicas: 5. During a rolling update, the developer sets maxSurge: 2 and maxUnavailable: 1. What is the maximum number of pods that can be running during the update?

A

7

With maxSurge=2 up to 7 pods can be running simultaneously.

B

5

C

8

D

6

Why: Option A is correct because during a rolling update, the total number of pods running is the sum of the desired replicas (5) plus the maxSurge (2), which equals 7. The maxUnavailable setting (1) controls how many pods can be down, not the upper limit of running pods. Kubernetes ensures that the number of pods above the desired count does not exceed maxSurge, so the maximum running pods is 5 + 2 = 7.

Want more Application Deployment practice?

Practice this domain
3

Domain 3: Application Environment, Configuration and Security

All Application Environment, Configuration and Security questions
Q1
easyFull explanation →

A pod named 'web-app' is running but has no environment variables. The developer wants to inject a variable 'DB_URL=postgres://db:5432' from a ConfigMap named 'db-config'. Which pod spec snippet correctly achieves this?

A

env: - name: DB_URL value: "postgres://db:5432"

B

envFrom: - configMapRef: name: db-config key: DB_URL

C

env: - name: DB_URL valueFrom: secretKeyRef: name: db-config key: DB_URL

D

env: - name: DB_URL valueFrom: configMapKeyRef: name: db-config key: DB_URL

Correctly references ConfigMap key.

Why: Option D is correct because it uses the `configMapKeyRef` field under `valueFrom` to inject a specific key from a ConfigMap as an environment variable. This allows the pod to consume the `DB_URL` value from the `db-config` ConfigMap without exposing it as a file or using `envFrom`.
Q2
mediumFull explanation →

A deployment runs a container that needs to read a file from a host path '/var/log/app' on the node. The file must be available to all pods on that node. Which volume type should be used?

A

emptyDir

B

hostPath

Correctly mounts host node path.

C

persistentVolumeClaim

D

configMap

Why: B is correct because hostPath mounts a file or directory from the host node's filesystem into the pod, making it available to all pods scheduled on that node. This is the only volume type that directly accesses a specific host path like '/var/log/app', ensuring the file is shared across all pods on the same node.
Q3
hardFull explanation →

A pod uses a service account 'my-sa' with a RoleBinding that grants get and list on pods in namespace 'app'. The pod runs a process that calls the Kubernetes API to list pods. However, the API call returns 403. What is the most likely cause?

A

The API server is not running.

B

The RoleBinding is in the wrong namespace.

C

The pod does not have the service account token mounted.

If automountServiceAccountToken is false, no token is available.

D

The Role does not include list permission.

Why: Option C is correct because the pod must have the service account token mounted to authenticate to the Kubernetes API server. By default, Kubernetes automatically mounts the service account token into pods via a projected volume at /var/run/secrets/kubernetes.io/serviceaccount/token. If the pod is configured with automountServiceAccountToken: false or the token is not mounted, the API client cannot authenticate, resulting in a 403 Forbidden error even if the RoleBinding grants the correct permissions.
Q4
mediumFull explanation →

A developer wants to restrict network traffic so that only pods with label 'app: frontend' can communicate with pods labeled 'app: backend' on port 8080. Which Kubernetes resource should be used?

A

NetworkPolicy

NetworkPolicy defines ingress/egress rules based on pod labels.

B

ResourceQuota

C

PodSecurityPolicy

D

RoleBinding

Why: A NetworkPolicy is the correct Kubernetes resource because it defines ingress and egress rules to control pod-to-pod communication based on labels, namespaces, and ports. By specifying a podSelector matching 'app: backend', an ingress rule allowing traffic from pods with label 'app: frontend' on port 8080, and a policyTypes field including 'Ingress', this resource enforces the desired restriction at the network layer using iptables or eBPF under the hood.
Q5
easyFull explanation →

A container runs as root (UID 0) but the security policy requires the container to run as non-root user 1000. Which pod security context setting should be added?

A

runAsNonRoot: true

B

runAsUser: 1000

Directly sets the container's user ID to 1000.

C

fsGroup: 1000

D

privileged: false

Why: Option B is correct because `runAsUser: 1000` explicitly sets the container's user ID to 1000, ensuring the container process runs as a non-root user. This directly satisfies the security policy requirement to run as UID 1000, overriding the default root (UID 0) behavior.
Q6
hardFull explanation →

Which TWO of the following are valid ways to mount a Secret into a pod as environment variables? (Select exactly 2)

A

env: - name: SECRET_KEY valueFrom: configMapKeyRef: name: my-secret key: key

B

env: - name: SECRET_KEY valueFrom: secretEnvRef: name: my-secret key: key

C

envFrom: - configMapRef: name: my-secret

D

env: - name: SECRET_KEY valueFrom: secretKeyRef: name: my-secret key: key

Correct: references a specific key from a Secret.

E

envFrom: - secretRef: name: my-secret

Correct: imports all keys as env vars.

Why: Option D is correct because `secretKeyRef` is the standard Kubernetes API field for referencing a specific key from a Secret object and injecting its value as an environment variable. Option E is correct because `envFrom` with `secretRef` allows you to load all key-value pairs from a Secret as environment variables into the pod, which is a valid and common pattern.

Want more Application Environment, Configuration and Security practice?

Practice this domain
4

Domain 4: Application Observability and Maintenance

All Application Observability and Maintenance questions
Q1
mediumFull explanation →

A pod named 'web-app' is experiencing high CPU usage. You want to investigate which process inside the container is consuming the most CPU. Which command should you run?

A

kubectl logs -f web-app

B

kubectl exec web-app -- top

Executes 'top' inside the container, showing per-process CPU usage.

C

kubectl describe node

D

kubectl top pod web-app

Why: Option B is correct because `kubectl exec web-app -- top` runs the `top` command inside the container of the pod 'web-app', which displays real-time process-level CPU usage. This allows you to identify the specific process consuming the most CPU, directly addressing the question's requirement to investigate inside the container.
Q2
hardFull explanation →

A deployment 'api-deploy' has resource limits set but is frequently being OOMKilled. The team suspects the memory limit is too low. Which approach should be taken to confirm this without causing downtime?

A

Create a new pod with a higher memory limit and delete the old pods manually.

B

Set the memory limit to unlimited by removing the limit section and restart the pod.

C

Use 'kubectl set resources' to increase the limit on the running pod dynamically.

D

Increase the memory limit in the deployment spec and apply the change; the rollout will automatically restart pods.

Rolling update applies changes without downtime.

Why: Option D is correct because updating the deployment spec triggers a rolling update, which replaces pods with new ones having the increased memory limit without downtime. This approach leverages Kubernetes' deployment controller to manage the rollout automatically, ensuring service continuity while adjusting resource limits.
Q3
easyFull explanation →

A pod is in CrashLoopBackOff state. You need to view the last few lines of its logs to understand why it is crashing. Which command is most appropriate?

A

kubectl logs -f my-pod

B

kubectl logs my-pod

C

kubectl logs my-pod --tail=20

Shows only the last 20 lines, ideal for recent errors.

D

kubectl get events --field-selector involvedObject.name=my-pod

Why: The `--tail=20` flag limits the output to the last 20 lines of the pod's logs, which is the most efficient way to see the recent crash-related errors without scrolling through the entire log history. In a CrashLoopBackOff state, the pod is repeatedly restarting, so viewing the tail of the logs directly shows the most recent failure messages, which is the standard diagnostic approach.
Q4
hardFull explanation →

You are debugging a network issue: a pod 'frontend' cannot reach a service 'backend' in the same namespace. The service endpoints are empty. What is the most likely cause?

A

The pod 'frontend' is not in the same namespace as the service 'backend'.

B

The service selector does not match the labels of any running pod.

Endpoints are populated by pods matching the selector; if none match, endpoints remain empty.

C

The pod's container port is different from the service port.

D

The kube-proxy is misconfigured and not updating iptables rules.

Why: B is correct because the most common reason for empty endpoints in a Kubernetes service is that the service's selector does not match the labels of any running pod. The service controller continuously monitors pods and updates the Endpoints object to include only those pods whose labels match the service's selector. If no pods match, the endpoints list remains empty, causing the frontend pod to fail to reach the backend service.
Q5
easyFull explanation →

A deployment is configured with a liveness probe that checks an HTTP endpoint. The probe fails intermittently, causing pod restarts. What is the best first step to diagnose the issue?

A

Check the liveness probe events via 'kubectl describe pod' to see the exact probe responses.

B

Run 'kubectl exec' to curl the endpoint from another pod to test network connectivity.

C

Review the liveness probe parameters in the deployment YAML and increase the failureThreshold.

D

Examine the container logs via 'kubectl logs' for error messages around the time of the failures.

Logs provide insight into application behavior during probe failures.

Why: Option D is correct because container logs provide the application's perspective on why the HTTP endpoint is failing intermittently. The liveness probe failure is a symptom; the root cause (e.g., a transient error, resource exhaustion, or a bug) is most directly visible in the application's own log output around the failure timestamps. This aligns with the CKAD domain of Application Observability and Maintenance, where logs are the primary diagnostic tool for application-level issues.
Q6
mediumFull explanation →

A pod is stuck in 'Pending' state. You run 'kubectl describe pod my-pod' and see the event: '0/3 nodes are available: 3 Insufficient cpu.' Which action should you take?

A

Increase the CPU limits on the pod to give it more resources.

B

Reduce the CPU request of the pod and reapply the manifest.

Lowering CPU request may allow the pod to fit on a node with available CPU.

C

Add another node to the cluster to increase overall CPU capacity.

D

Add a nodeSelector to the pod to target a specific node.

Why: The pod is stuck in 'Pending' because the scheduler cannot find a node with enough allocatable CPU to satisfy the pod's CPU request. Reducing the CPU request (the amount guaranteed to the container) makes the pod schedulable on existing nodes. Increasing limits would only worsen the problem, as limits are a cap on usage, not a scheduling constraint.

Want more Application Observability and Maintenance practice?

Practice this domain
5

Domain 5: Services and Networking

All Services and Networking questions
Q1
mediumFull explanation →

A developer deploys a set of Pods labeled app=frontend and wants to expose them internally within the cluster on a stable IP. Which resource should be used?

A

Service of type NodePort

B

Service of type LoadBalancer

C

Service of type ClusterIP

Correct: ClusterIP provides a stable internal IP.

D

Ingress resource

Why: A Service of type ClusterIP exposes the Pods on a stable internal IP address that is only reachable within the cluster. This is the default Service type and is ideal for internal communication between components, such as a frontend being accessed by a backend, without exposing the service outside the cluster.
Q2
hardFull explanation →

A team uses a Service named 'backend' in namespace 'prod' to reach Pods in namespace 'staging'. The Service in 'prod' has no endpoints. What is the most likely cause?

A

The Service port name does not match the container port

B

The Service selector does not match any Pods in the same namespace

Service selects Pods only within its own namespace; no matching Pods in prod means no endpoints.

C

The Service type is ClusterIP but should be NodePort

D

DNS resolution is broken in the staging namespace

Why: The Service in the 'prod' namespace has no endpoints because its selector does not match any Pods in the same namespace. Kubernetes Services only discover Pods within the same namespace via label selectors; cross-namespace access requires a different approach (e.g., ExternalName Service or manual endpoint configuration). Since the Pods are in 'staging', the selector in 'prod' finds no matching Pods, resulting in zero endpoints.
Q3
easyFull explanation →

An application requires Pods to communicate using hostNetwork: true. Which Kubernetes resource is still necessary for stable DNS names?

A

Headless Service

B

Endpoints resource

C

Regular Service (ClusterIP)

Regular Service provides stable DNS and IP; works with hostNetwork.

D

Ingress

Why: When Pods use hostNetwork: true, they share the node's network namespace and bypass the Pod network, so kube-proxy does not set up iptables rules for ClusterIP Services. However, a regular ClusterIP Service still creates stable DNS records (via CoreDNS) that resolve to the Service's virtual IP, which can then be used for stable DNS names even though direct ClusterIP connectivity is lost. This ensures that other components can discover the Pods via DNS without relying on Pod IPs that may change.
Q4
mediumFull explanation →

A Pod needs to access an external database at db.example.com:3306. Which Service type allows Pods to resolve a cluster-local name to this external address?

A

ExternalName

ExternalName returns CNAME to external DNS name.

B

LoadBalancer

C

NodePort

D

ClusterIP

Why: The ExternalName Service type maps a cluster-local DNS name (e.g., `my-db.default.svc.cluster.local`) to an external DNS name (`db.example.com`) using a CNAME record. This allows Pods to resolve the service name to the external database address without needing to modify application code or use an external endpoint.
Q5
hardFull explanation →

A Service of type LoadBalancer is created but the external IP remains <pending>. What is the most likely reason?

A

The Service port is already in use

B

The Service selector does not match any Pods

C

The cluster does not have a cloud provider configured

Without a cloud controller, no LB is provisioned.

D

The Pods are not listening on the container port

Why: A LoadBalancer Service in Kubernetes relies on an external cloud provider (e.g., AWS, GCP, Azure) to provision a real load balancer and assign its external IP. If no cloud provider is configured (e.g., in a bare-metal or Minikube cluster), the external IP will remain <pending> indefinitely because there is no controller to allocate the IP.
Q6
easyFull explanation →

A developer wants to expose a set of Pods on a specific port on each node's IP. Which Service type should be used?

A

LoadBalancer

B

ClusterIP

C

NodePort

NodePort exposes on each node's IP at a static port.

D

ExternalName

Why: NodePort is the correct Service type because it exposes each Pod's port on a static port (the NodePort) on every node's IP address. This allows external traffic to reach the Pods by accessing any node's IP on that specific port, fulfilling the requirement to expose the Pods on a per-node IP basis.

Want more Services and Networking practice?

Practice this domain

Frequently asked questions

How many questions are on the CKAD exam?

The CKAD exam is performance-based — there are no multiple-choice questions. It is a hands-on lab exam completed within 120 minutes. You complete practical tasks in a live or simulated environment. Courseiva practice questions cover the underlying concepts.

What types of questions appear on the CKAD exam?

Hands-on application deployment and management tasks in a live Kubernetes cluster.

How are CKAD questions organised by domain?

The exam covers 5 domains: Application Design and Build, Application Deployment, Application Environment, Configuration and Security, Application Observability and Maintenance, Services and Networking. Questions are weighted by domain — higher-weight domains appear more on your actual exam.

Are these the actual CKAD exam questions?

No. These are original exam-style practice questions written against the official CNCF CKAD exam objectives. They are not copied from the real exam. Courseiva focuses on genuine understanding, not memorisation of braindumps.

Ready to practice CKAD?

Courseiva tracks your accuracy per domain and routes you toward weak areas automatically. Free, no account required.

Browse all CKAD questionsTake a timed practice test